Forum Krótkofalarskie PKI

Robert

U mnie pisze tak: (DATA wytłuściłem)

"<Error in 60M or DATA or 20170726 :0>
<APP_LoTW_OWNCALL:6>SQ9JXB<STATION_CALLSIGN:6>SQ9JXB<CALL:5>SP8SN<BAND:3>60M<FREQ:7>5.35780<MODE:4>DATA<APP_LoTW_MODE:4>DATA<APP_LoTW_MODEGROUP:4>DATA
<QSO_DATE:8>20170726<TIME_ON:6>202200<QSL_RCVD:1>Y<QSLRDATE:8>20170728<DXCC:3>269
<COUNTRY:6>POLAND<APP_LoTW_DXCC_ENTITY_STATUS:7>
Current<PFX:3>SP8<APP_LoTW_2xQSL:1>Y<CQZ:2>15<ITUZ:2>28<GRIDSQUARE:6>KO11FI<eor>"

Dziwne.
Zalogowałem się na stronę arrl LOTW i wszedłem w log. Znalazłem potwierdzone QSO jako DATA zrobione w FT8:

Station
Call Sign SP8SN
DXCC POLAND
CQ Zone 15
ITU Zone 28
Grid KO11FI
Worked Station
Worked DD3KF
DXCC FEDERAL REPUBLIC OF GERMANY (230)
CQ Zone 14
ITU Zone 28
Grid JO30BS
Date/Time 2017-07-27 17:47:00
Mode DATA (DATA)
Band 6M
Frequency 50.31300
QSL 2017-07-27 20:00:50
Record ID 851188801 Received: 2017-07-27 20:00:50

Więc z tego wynika, że DATA powinno działać. Nie wiem w czym problem

EDIT: WIEM W CZYM PROBLEM
Mój log ma zapisane FT8. Podczas wysyłki TQSL zamienia na DATA i wysyła do LOTW. Tam wszystko jest ok. Maile z informacją o nowym potwierdzeniu LOTW przychodzą mi za pośrednictwem HRDLOG.net. Tam łączność zapisana jest w FT8. Dlatego pokazuje niezgodność. Jak ściągam potwierdzenia z LOTW moim logiem (Log4om) również pokazuje mi błąd bo zapisane łączności FT8, a nie DATA. W logu trzeba zmienić na DATA i wtedy wysyłać. Wszędzie musi być DATA bo inaczej nie zagra.

Myślę że błąd wynika z przetwarzania danych w LOTW.

Bo dlaczego jest 4 błędy a innym razem 7 lub kilkanaście?

u góry dopisałem w czym jest błąd przynajmniej u mnie na 99%

Robert

to dlaczego jak wysyłam 60 QSO do LOTW to mam tylko 7 błędów a nie 60?

SQ9JXB pisze:

Robert

to dlaczego jak wysyłam 60 QSO do LOTW to mam tylko 7 błędów a nie 60?

Tego nie wiem. Trzeba by było zobaczyć dokładnie czym się różni QSO, które zostało przyjęte od tego z błędem.
Może wrzuć takie porównanie w adi coś może żeśmy przeoczyli.
Wiem, że u mnie już jest ok:

Widzisz, nie bardzo znam UR5EQF, chociaż kilka razy próbowałem się przesiąść.
Nie bardzo widzę QSO w którym nie ma błędu, pokazałeś same błędy.
Zauważ, że w logu masz FT8, a z LOTW ściągasz potwierdzenie DATA i wysyłasz DATA - rozumiem, że przerabiane poprzez mapowanie w TQSL. Ale dlaczego niektóre DATA pokazują błąd - nie bardzo wiem co podpowiedzieć.
Dokładnie przeanalizuj QSO w FT8, którego potwierdzenie ściągnął z LOTW poprawnie tak jak u mnie - log pokazuje potwierdzenie naszej łączności teraz poprawnie.

tak wychodzi bo raporty się nie zgadzają

sq4bjc pisze:

tak wychodzi bo raporty się nie zgadzają

to nie to, u mnie potwierdziło - łączność przeszła weryfikację w LOTW
stawiam na to, że Janek ma w logu MODE: FT8, a ściąga z LOTW potwierdzenie w MODE: DATA
tak przynajmniej było u mnie, zmieniłem w logu na DATA i wtedy przyjął

PS: byłem w czerwcu w Giżycku, na moście ze zdjęcia

Raporty się zgadzają

Ode mnie nadane +8 - Robert odebrał +8
Robert nadał +3 - Ja odebrałem +3

sp8sn pisze:


sq4bjc pisze:

tak wychodzi bo raporty się nie zgadzają


to nie to, u mnie potwierdziło - łączność przeszła weryfikację w LOTW
stawiam na to, że Janek ma w logu MODE: FT8, a ściąga z LOTW potwierdzenie w MODE: DATA
tak przynajmniej było u mnie, zmieniłem w logu na DATA i wtedy przyjął

PS: byłem w czerwcu w Giżycku, na moście ze zdjęcia

Zmieniłem na format ADIF -> DATA i poszło - żadnych błędów

SQ9JXB pisze:


sp8sn pisze:


sq4bjc pisze:

tak wychodzi bo raporty się nie zgadzają


to nie to, u mnie potwierdziło - łączność przeszła weryfikację w LOTW
stawiam na to, że Janek ma w logu MODE: FT8, a ściąga z LOTW potwierdzenie w MODE: DATA
tak przynajmniej było u mnie, zmieniłem w logu na DATA i wtedy przyjął

PS: byłem w czerwcu w Giżycku, na moście ze zdjęcia


Zmieniłem na format ADIF -> DATA i poszło - żadnych błędów

czyli gryzło się FT8 z DATA ?

Robert

Dokładnie tak.

Format ADIF miałem FT8 - zamiast DATA.

Twoje potwierdzenie z LOTW już jest.

SQ9JXB pisze:

Robert

Dokładnie tak.

Format ADIF miałem FT8 - zamiast DATA.

Twoje potwierdzenie z LOTW już jest.

no to super

Teraz z kolei jest problem z eQSL. Tam akceptowane jest FT8. Zamieszanie.
Trzeba wracać do FT8 przy działaniach z eQSL. Do czasu akceptacji w LOTW FT8 będzie trzeba kombinować z logiem.

Robert

Sprawdziłem teraz na stronie eQSL i potwierdzenia są.
Nawet dzisiejsze QSO z KF4BI mam potwierdzone z eQSL.

A mam tak jak wczoraj FT8 -> DATA jako format ADIF

a mi nie ściąga eQSL jak w logu mam DATA - NO QSO
zmieniłem wszystkie łączności w logu na FT8 i poszło

Zobacz wyciąg z adif z ur5eqf_log

<OPERATOR:6>SQ9JXB<CALL:5>KF4BI<QSO_DATE:8>20170730<TIME_ON:4>0342<FREQ:6>7.0751<MODE:4>DATA<RST_SENT:3>-01<RST_RCVD:3>-14<NAME:5>Keith
<QTH:18>Sycamore, Ga 31790<STATE:2>GA<GRIDSQUARE:4>EM81<PFX:2>K4<DXCC_PREF:1>K<CQZ:2>04<ITUZ:2>08
<BAND:3>40M<CONT:2>NA<EQSL_QSL_RCVD:1>Y<QSLMSG:19>TNX For QSO TU 73!.<STATE4:9>GA-TURNER<LOTW_QSL_SENT:1>Y<DXCC:3>291<EOR>

Widzę, że w UR5 jest inna zasada. U mnie w log4om nie ma ustawiania adif. Po prosu zaznaczam np. 50 łączności i zmieniam w nich mode na DATA. Wtedy log ściągając potwierdzenia z LOTW dopasowuje. Natomiast jeśli zapisuję QSO w DATA log nie chce wysłać eQSL, MODE ERROR. Jak wysyłam eQSL zapisane w FT8 to idzie bez problemu. Tylko jak zapiszę w FT8 nie potwierdzę LOTW. Kółko się zamyka. W tej chwili muszę zapisywać qso w DATA, załatwić LOTW, zmienić na FT8 i załatwić eQSL.
Wniosek z tego, że trzeba zmienić na UR5