Hi Reino Thanks for the specifications. I also saw "ONLY RST reports" if they are less than 9 SFH they are surely there ...
------ 2024-08-27 - 14:58:00 UTC - 20m - FT8 ------ 145800 3 0.0 754 ~ WA2EPI CY9C +05 St. Paul Is. 145800 3 0.0 754 ~ K4CN CY9C +02 St. Paul Is. 145800 3 0.0 754 ~ OK1PI CY9C -02 St. Paul Is. 145800 3 0.0 754 ~ HB9RYZ CY9C -02 St. Paul Is. CY9C verified --- Only RR73 I have never seen. Since CY9C always as good RSQ, I can have fun watching it and decoding it for a long time, and do any checks. But with about 60/70 Hound decodings here of those who call it, I rarely see 9 reply anyway. Better to remove the 9th slot and gain bits... or remove the 9 and 8th slots and leave the 7th but always 7 reply... so I find this oddity that goes from 2-3 then to 6-7 and very few times to 9 reply with a very low average, I don't think it depends only on the bits of the package or am I wrong? Uwe also asked himself this question with N5J... I am also always believe that a "reserved frequency" for the answers It would be worth considering. With these strong signals, there are many people, it is very easy to be put on the list and then you can no longer get through when he answers you... even if he receives you strongly, even worse if he receives you weakly... On some bands I had to repeat the procedure even 3 times even though I had good RSQ... After his first reply, because I was probably on the waiting list, he no longer listened to my RSQ report, whether I moved or always fixed without moving (also with me RSQ +05 to +10): the probability that someone in the meantime, somewhere in the world, or Dqrm, would pass over me, was high with all these people. With a frequency dedicated to the reply (such as Normal Fox), it would be much lower and therefore would speed up the connection(s) with a much greater possibility of finishing the QSO. Both in the three RSQ recalls and in the following 2 minutes of "timeout" I did not pass and had to do it again, 3 or 4 time. If we calculate about 60Hz for single reply, maximum 60Hz x 9 = 540Hz first for the three reply, reserved for reply frequency, and another 540Hz maximum for the timeout of the remaining two minutes... the usual 1000Hz from 100 to 1200Hz reserved... If it were really a problem of BIT of the packet, it would be enough to decrease it, with 7 slots, gaining space, BIT and security BW would be 7x60 420x2=840Hz, and we would also be below 1000Hz here as before but with 7 fixed slots at once whitout degrade RSQ to MAX –16! Sin that the bits in the message are so few and limited by the available BW/time... but then there are unfortunately many limits but maintaining a reply order for the SFox and a TX order for the SHound could be implemented not in the TX package but in the soft For the 9 decodings in a few hours, I have seen very few, to count on the fingers of one hand, always from 2/3 to 6/7 and with all those people I don't think it depends only on the limits of the packets because at least an average of 6/7 replies should be able to have them... maybe... ------ 2024-08-27 - 15:08:00 UTC - 20m - FT8 ------ 150800 -5 -0.0 753 ~ DH8GV CY9C RR73 St. Paul Is. 150800 -5 -0.0 753 ~ EA1KE CY9C RR73 St. Paul Is. 150800 -5 -0.0 753 ~ OM2ZZ CY9C RR73 St. Paul Is. 150800 -5 -0.0 753 ~ ES6DO CY9C RR73 St. Paul Is. 150800 -5 -0.0 753 ~ OZ1ING CY9C RR73 St. Paul Is. 150800 -5 -0.0 753 ~ DF7EF CY9C -06 St. Paul Is. 150800 -5 -0.0 753 ~ OZ1LCG CY9C -02 St. Paul Is. 150800 -5 -0.0 753 ~ PA5DX CY9C -04 St. Paul Is. 150800 -5 -0.0 753 ~ OO7P CY9C +03 St. Paul Is. CY9C verified --- In my opinion the problem is not only in the “limits” of the available bit packet... If it were really a problem of packet BIT, it would be enough to decrease it, with 7 slots, gaining space and security! For the DT, I remember that when someone in FT8 was out up to +/-1.7sec compared to my time was not decoded. This morning CY9C was already out by 0.9sec, probably those who had a slightly off PC clock could easily exceed this limit and not be decoded. Today CY9C did CQ only for a long time, a sure problem of RX only his not probable of soft, but at least, sure after reset adjust..., the DT this afternoon had been corrected to DT 0.0... Well we will see in the next modifications after these "official" tests and the "unofficial" ones 73 --- Franco http://radioclub.ddns.net/YaesuCat From: Reino Talarmo via wsjt-devel Sent: Tuesday, August 27, 2024 11:17 AM To: 'WSJT software development' Cc: Reino Talarmo Subject: Re: [wsjt-devel] Superfox 1 to 9 users/slot Hi Franco, you need to wait to see how the SuperFox message is encoded. There are not so many bits available for the message data and some compromises have been done how those 9 possible callsigns and their related info bit are allocated. Not all can be reports or RR73’s at the same time, there simply is not enough bits available. The DT ‘problem’ is solved using correlation and DT limits are simply set by the range used in the correlation calculation, for FT8 it is set to +/-2.5s from the receiver local time. No need to know any average DT for decoding, but the computer time needs to be accurate enough, say +/-1s. The sender’s confirmation method is a temporary solution and a new one is in design.
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel