I do not know why this bug still exists. I am 3rd time on St Eustatius and every time here my PJ5/SP9FIH callsign is decoded wrong. This time it is as DP1POL.
Please do not call DP1POL because nobody will answer you! Felix DP1POL is not active now on FT8.
Actually, I am in Antarctica right now and active as DP1POL. But I do not even have to get on the air, I am getting lots of digital QSL cards for contacts that were actually with PJ5/SP9FIH. This is a very unfortunate situation, as many stations are obviously not logging you correctly. I will try to avoid FT8 as much as I can to help clear up the confusion, but there is nothing I can do about wrong decodes in the software of your QSO partners and cards that are erroneously sent to my QSL manager. I hope this information will spread sooner or later: if you’re seeing “DP1POL” on FT8, it is most probably just a bad decode of PJ5/SP9FIH. Nevertheless, have a good stay and lots of DX! 73 from Antarctica!
Thank you Felix for explanation. Unfortunately we cannot do anything. Probably WSJT or MSHV should have big improvement!
Simply *DO NOT USE* MSHV multi-stream on the “common” frequencies. If you must use multi-stream (the “combined” message) use it on a dedicated (F/H) frequency. If you avoid the “combined” message, the 10 bit hash will not come into play and you will avoid the confusion caused by the hash “clash”.
Simply a 10 bit hash can only support 1024 (2^10) callsigns if the algorithm is “perfect”. In practice, the number will be much less than that before calls start to overlap.
Avoid the “combined” message where there are a lot of callsigns – e.g. the “common” frequencies. This is the reason Joe Taylor et al did not enable “tail-end” mode.
Same thing happens on dedicated frequencies and it is always, no metter if I use multi stream or single stream. It is in MSHV and WSJT and also exists in Fox/Hound operation.
The problem exists because authors did not think about longer callsigns and they do not want to rebuild code now. In my opinion FT8 should be in beta testing period and not in common use.
Felix and Janusz,
maybe you can agree on somekind of a scheme for FT8 band using. Antarctica is also wanted and for a lot of stations it is impossible making contacts in phone or cw.
Thanks for your understanding
It appears a similar situation is happening now on 10m FT4 but with YT3PL as well as DP1POL.
163545 -17 0.1 304 + R2AB +08
163600 -10 0.1 303 + R2AB RR73; KM4P -10
No problems in decoding your callsign correctly using the newest WSJT-X version 2.7.0_rc2_improved by DG2YCB.
I’m seeing both the correct callsign PJ5/SP9FIH and the incorrect one DP1POL at different times with WSJT-X 2.7.0_rc3. They’re showing up at the same offset, so appearing as though the two stations were TXing on top of one another.
I’m also occasionally seeing an incorrect decode that appears to be PJ5/SP9FIH calling me but out of sequence (e.g., with “R+00” when it should be just “+00”) when I haven’t even been calling.
Just do not call DP1POL. Leave it as it is.
I never used FT8 or have any experience with it.
But I am a bit curious now. I can understand that a call can be wrongly decoded. It would be decoded as something which is different to the original call. What I cannot understand is how this FT8 programme decodes it as a correct call which is already in use sometimes somewhere else.
I would understand if decoding PJ5/SP9FIH results in CJ3/MP7SIB or something else. But coming up with a perfectly valid other call is a bit of a stretch for me. The chances that something like that happens are not that high.
Am I correct to say that anyone using FT8 has to register first online with his/her call? That there is a data pool available- from which the decoding programme can choose something in case the propagation is difficult? A bit of guesswork? And that this guesswork could go on and on until the “right” call is matched? Which does not have to take too long- since we are talking about machines communicating with each other.
Any thoughts?
Hi Michael,
I am not specialist but I guess that from begining author did not anticipade that 10 signs (or even longer) callsign exists. Probably it is not long enaugh coding space.
This causes that long callsigns are not coded 100% and there is space to decode other callsins.
What I do not understand why every time here wrong decoding of PJ5/SP9FIH is in different callsigns. Before I was decoded as PJ5/SP6… now it is DP1POL and YT3PL…
I use the program but it has so many bugs and nobody wants to clear it up….
We cannot change past but I wished this FT8 would not come to use…
I am curious…Do the decoding problems still happen if AP decoding is disabled?
Just had a QSO from our clubstation F6KKR with Janusz (15m FT8) and everything went fine.
No bad decodings at all. I read Janusz with +10 and +06.
Software in use: WSJT-X 2.6.1
73!
Andreas F4JKH
Operator at F6KKR