Re: [wsjt-devel] Tx timing and protocol spec
On 10/08/2017 19:14, Richard Lamont wrote: On 10/08/17 13:21, Bill Somerville wrote: On 10/08/2017 00:22, Richard Lamont wrote: In a perfect station, exactly how soon after the beginning of the 15-second (or whatever) window should the Tx start to radiate RF? Is a nominal amount of delay baked into the protocol(s) to allow for T/R switching, the default 0.2s before audio etc? it depends on the mode. Fast modes start as soon as PTT is asserted and "Tx Delay" has expired. Slow modes apart from FT8 start audio at the later of 1s or PTT asserted plus "Tx Delay". FT8 audio starts after the later of 0.5s or PTT asserted plus "Tx Delay". With the slow modes the start time does not impact the timing of the symbols transmitted, so a late start does not increase the DT seen at a receiving station, it truncates the front symbols of the message (sort of analogous to stopping early). Hi Bill and thanks for the reply. From the above, if I've understood correctly, for FT8: If T=start of any 15-sec UTC period, Then FT8 audio 'starts' at T+0.5 (but audio output to TX may be muted, not delayed, until PTT assertion + Tx Delay); Tx duration = 79/6.25 = 12.64s; So FT8 audio always ends at T+0.5+Tx duration = T+13.14s; The first 7 channel symbols are sync symbols (repeated in the middle and at the end) and the payload begins with the 8th symbol, so we can afford to have up to 1.12 seconds muted at the beginning without compromising the payload; If I've got this right, then to get all 3x7 sync symbols we need audio at T+0.5, and to get all 58 payload symbols we need audio by T+1.62. So the answer to my original question is 0.5s for FT8, and 1.0s for the other slow modes. HI Richard, that's all correct except I would not call a late start past the 8th channel symbol a compromised payload. The LDPC FEC will be able to trivially recover many lost information bits on a strong signal, it is only when the erased bits reach the hard error limit of the code that the message is potentially compromised and soft decision techniques using symbol signal strengths fed into a stochastic process are needed to dig deeper. In fact the loss of one of the three sync arrays may be the real compromise since we must find the candidate signal before *any* decoding can be attempted. Having the sync energy distributed to start, middle and end is to help locate both fading and truncated candidate messages. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Tx timing and protocol spec
On 10/08/17 13:21, Bill Somerville wrote: > On 10/08/2017 00:22, Richard Lamont wrote: >> In a perfect station, exactly how soon after the beginning of the >> 15-second (or whatever) window should the Tx start to radiate RF? Is a >> nominal amount of delay baked into the protocol(s) to allow for T/R >> switching, the default 0.2s before audio etc? > > it depends on the mode. Fast modes start as soon as PTT is asserted and > "Tx Delay" has expired. Slow modes apart from FT8 start audio at the > later of 1s or PTT asserted plus "Tx Delay". FT8 audio starts after the > later of 0.5s or PTT asserted plus "Tx Delay". > > With the slow modes the start time does not impact the timing of the > symbols transmitted, so a late start does not increase the DT seen at a > receiving station, it truncates the front symbols of the message (sort > of analogous to stopping early). Hi Bill and thanks for the reply. >From the above, if I've understood correctly, for FT8: If T=start of any 15-sec UTC period, Then FT8 audio 'starts' at T+0.5 (but audio output to TX may be muted, not delayed, until PTT assertion + Tx Delay); Tx duration = 79/6.25 = 12.64s; So FT8 audio always ends at T+0.5+Tx duration = T+13.14s; The first 7 channel symbols are sync symbols (repeated in the middle and at the end) and the payload begins with the 8th symbol, so we can afford to have up to 1.12 seconds muted at the beginning without compromising the payload; If I've got this right, then to get all 3x7 sync symbols we need audio at T+0.5, and to get all 58 payload symbols we need audio by T+1.62. So the answer to my original question is 0.5s for FT8, and 1.0s for the other slow modes. 73, Richard G4DYA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Tx timing and protocol spec
On 10/08/2017 00:22, Richard Lamont wrote: In a perfect station, exactly how soon after the beginning of the 15-second (or whatever) window should the Tx start to radiate RF? Is a nominal amount of delay baked into the protocol(s) to allow for T/R switching, the default 0.2s before audio etc? Hi Richard, it depends on the mode. Fast modes start as soon as PTT is asserted and "Tx Delay" has expired. Slow modes apart from FT8 start audio at the later of 1s or PTT asserted plus "Tx Delay". FT8 audio starts after the later of 0.5s or PTT asserted plus "Tx Delay". With the slow modes the start time does not impact the timing of the symbols transmitted, so a late start does not increase the DT seen at a receiving station, it truncates the front symbols of the message (sort of analogous to stopping early). 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Tx timing and protocol spec
In a perfect station, exactly how soon after the beginning of the 15-second (or whatever) window should the Tx start to radiate RF? Is a nominal amount of delay baked into the protocol(s) to allow for T/R switching, the default 0.2s before audio etc? 73, Richard G4DYA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel