Re: [wsjt-devel] Serialization of Delta Time in Decode Message Type
On 15/05/2019 15:06, Derek Turner via wsjt-devel wrote: The solution was actually quite simple :- reverse the byte order of the eight bytes starting at the 32nd byte and then use .Net BitConverter.ToDouble. Hi Derek, glad you are back on track. Not trying to belittle your project but have you considered using the Meinberg NTP Client to maintain your PC synchronization with UTC, it will do virtually continuous corrections and you will not suffer from the drifting local realtime clock issues that seem to be at the root of your need to track DT values. Note that there will always be a range of observed DT values. Even if every station had perfect UTC synchronization there would be contributions from processing and audio sub-system latencies, DSP latencies transmitters and receivers, propagation delays, and latencies due to desktop PC operating systems not being optimized for real-time deadlines. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Serialization of Delta Time in Decode Message Type
Dear Bill, Paul G4WPA and George WB5JJJ Solved. Thank you Bill for reminding me about endianness and Paul for explaining that 0,0,0,0,0,0,0,0 is indeed zero. The solution was actually quite simple :- reverse the byte order of the eight bytes starting at the 32nd byte and then use .Net BitConverter.ToDouble. My mistake was that I tried to make sense of the byte array pattern rather than use program functions. I am still wondering why there is a ninth byte and must presume that the equalness of the 33rd and 34th byte is some arithmetic artifact. Thank you Bill for reminding me also of assuming fixed positions in the byte array. I had assumed that the ID (unique key) was always "WSJT-X" but you have pointed out that this field reflects command line parameters so I am duly warned. Now some background for George WB5JJJ. I am using Dimension 4 as a service to synchronise my PC clock every nine minutes. However when I scan the DT column in the Band Activity window it seems that there are always more positives than negatives. When I look at the history window in Dimension 4 the situation is the same. I don't know why. The average advance is about 0.2 seconds.but this may occasionally reach 0.5 seconds before synchronisation is triggered. This was not a big deal for me until FT4 arrived where the timing is more critical. I particularly want to know if my time error is affecting my FT4 decodes so I want a histogram or a moving average. Nudging based on a 'follow the herd' principle does not seem like a bad idea to me. 73 de G4SWY Derek +++ On Tuesday, 14 May 2019, 22:54:28 BST, Bill Somerville wrote: On 14/05/2019 22:26, Derek Turner via wsjt-devel wrote: So I know I am looking in the right place, which is the eight bytes starting at (zero base) byte 32 . Here is a screen shot from an Excel worksheet where I compare samples of the Band Activity DT with their Decode byte array bytes:- I have several issues here that I do not understand :- 1. The pattern of bytes for negative and positive Delta Times are identical so the sign is lost. 2. Between SNR and Delta Frequency there are nine bytes, not the eight I expected for a Double. Byte 40 appears to be surplus. 3. DT 0 is suspiciously all zeros when DT 0.1 seems to be a very large number. 4. Bytes 33 and 34 are identical. Please can somebody make sense of this for me. Hi Derek, beware of assuming fixed start positions for fields in the messages, if there are preceding string fields then the following fields will be moved according the length of the string field(s). You will be ok in this case so long as you always start WSJT-X with the same command line parameters. The main issue is that you are not allowing for the fields in the message being stored in network byte order, i.e. Big Endian. If you are receiving on a little Endian architecture then you must swap the bytes of any numeric fields longer than one byte. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Serialization of Delta Time in Decode Message Type
On 14/05/2019 22:26, Derek Turner via wsjt-devel wrote: So I know I am looking in the right place, which is the eight bytes starting at (zero base) byte 32 . Here is a screen shot from an Excel worksheet where I compare samples of the Band Activity DT with their Decode byte array bytes:- Inline image I have several issues here that I do not understand :- 1. The pattern of bytes for negative and positive Delta Times are identical so the sign is lost. 2. Between SNR and Delta Frequency there are nine bytes, not the eight I expected for a Double. Byte 40 appears to be surplus. 3. DT 0 is suspiciously all zeros when DT 0.1 seems to be a very large number. 4. Bytes 33 and 34 are identical. Please can somebody make sense of this for me. Hi Derek, beware of assuming fixed start positions for fields in the messages, if there are preceding string fields then the following fields will be moved according the length of the string field(s). You will be ok in this case so long as you always start WSJT-X with the same command line parameters. The main issue is that you are not allowing for the fields in the message being stored in network byte order, i.e. Big Endian. If you are receiving on a little Endian architecture then you must swap the bytes of any numeric fields longer than one byte. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Serialization of Delta Time in Decode Message Type
If enough users start "nudging" their time one way or the other, the whole reason for external time sync is defeated. It will chasing your tail from the get go. Just sync periodically and forget those that don't/can't. It's not worth the problems it will cause to the normal users that do it right. On Tue, May 14, 2019 at 4:42 PM Derek Turner via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > I was thinking about adding a feature to my FT8/4 Assistant program to > display in a histogram the delta times from the last minute's worth of > decodes and maybe eventually to enable the user to nudge the PC clock > backwards or forwards by a few milliseconds. > > This may or may not be a good idea but my problem is that so far I have > not been able to convert the UDP decode message time offset back to > anything resembling the DT column in the WSJT-X Band Activity window and I > would very much appreciate some help. > > In the specification the Delta Time is described as a float serialised as > a Double. When I examine the eight bytes following the SNR bytes I see a > consistent correlation between the Band Activity DT and the pattern of > bytes. > > So I know I am looking in the right place, which is the eight bytes > starting at (zero base) byte 32 . Here is a screen shot from an Excel > worksheet where I compare samples of the Band Activity DT with their Decode > byte array bytes:- > > [image: Inline image] > > I have several issues here that I do not understand :- > > 1. The pattern of bytes for negative and positive Delta Times are > identical so the sign is lost. > 2. Between SNR and Delta Frequency there are nine bytes, not the eight I > expected for a Double. Byte 40 appears to be surplus. > 3. DT 0 is suspiciously all zeros when DT 0.1 seems to be a very large > number. > 4. Bytes 33 and 34 are identical. > > Please can somebody make sense of this for me. > > 73 de G4SWY Derek +++ > > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Serialization of Delta Time in Decode Message Type
I was thinking about adding a feature to my FT8/4 Assistant program to display in a histogram the delta times from the last minute's worth of decodes and maybe eventually to enable the user to nudge the PC clock backwards or forwards by a few milliseconds. This may or may not be a good idea but my problem is that so far I have not been able to convert the UDP decode message time offset back to anything resembling the DT column in the WSJT-X Band Activity window and I would very much appreciate some help. In the specification the Delta Time is described as a float serialised as a Double. When I examine the eight bytes following the SNR bytes I see a consistent correlation between the Band Activity DT and the pattern of bytes. So I know I am looking in the right place, which is the eight bytes starting at (zero base) byte 32 . Here is a screen shot from an Excel worksheet where I compare samples of the Band Activity DT with their Decode byte array bytes:- I have several issues here that I do not understand :- 1. The pattern of bytes for negative and positive Delta Times are identical so the sign is lost.2. Between SNR and Delta Frequency there are nine bytes, not the eight I expected for a Double. Byte 40 appears to be surplus.3. DT 0 is suspiciously all zeros when DT 0.1 seems to be a very large number.4. Bytes 33 and 34 are identical. Please can somebody make sense of this for me. 73 de G4SWY Derek +++ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
