Menu
▾
▴
Re: [wsjt-devel] Decoding UDP without QDataStream?
|
From: Bill S. <g4...@cl...> - 2020-07-04 20:54:01
|
Hi Thomas and Chris, the QDataStream serialization format is documented, albeit somewhat divided across documents. The subset we use in WSJT-X is documented apart from the QDateTime fields which we document in our protocol description, along with the QByteArray format. There are no clever run length encoding or similar techniques, its pretty much the same as any other binary serialization format. The two "zero length" byte array byte counts are to represent both zero-length strings (0x00000000) and null string (0xffffffff), they are necessary because Qt distinguishes between empty and null with strings, bytes, and some other types. Note we do not serialize strings as QString, we serialize them as QByteArray containing utf-8 code points. Chris, did you reference the documents and description at the top of the NetworkMessage.hpp file?Everything you need is right there: https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp#l20 73 Bill G4WJS. On 04/07/2020 21:12, Thomas Reynolds wrote: > Hi Chris, > > For about a year we've had an Android app that parses the UDP messages. > > In your data, the zero length DX call is represented by four bytes of > zero, IOW a length field of zero bytes. The DX grid has a length > field of -1, four 0xFF bytes. We've interpreted both to be valid > values. And we expect no further bytes in that DX Grid or DX call. > Similar things happen if the user does not fill in his own call or grid. > > This may not be the exact correct interpretation, but it has worked > through the WSJT-X revs. > > BTW, the app is WSJT-X Monitor Pro > https://play.google.com/store/apps/details?id=com.feotec.wsjt_xmonitor.noads&hl=en_US (paid) > and WSJT-X Monitor, > https://play.google.com/store/apps/details?id=com.feotec.wsjt_xmonitor.ads&hl=en_US , > free (shameless promotion). > > Thomas Reynolds > > > On Sat, Jul 4, 2020 at 12:44 PM Chris Keller <xy...@gm... > <mailto:xy...@gm...>> wrote: > > Those examples look mangled in the mailing list archives viewer; > I'm attaching them here. > > On Sat, Jul 4, 2020 at 1:21 PM Chris Keller <xy...@gm... > <mailto:xy...@gm...>> wrote: > > Hi folks, > > I'm working on a Golang binding for the WSJT-X UDP interface > as described in NetworkMessage.hpp. It's starting pretty well > (https://github.com/xylo04/wsjtx-go), but I'm running into > troubles parsing the Status messages in particular. I'm able > to parse through many blocks of bytes, but at some point I > start running into an unexpected block of 0x00 and 0xff. Then, > after a handful of those bytes, it resumes with the last field. > > Is this maybe some feature of QDataStream that will abbreviate > several adjacent fields with default values? I can't > immediately find documentation about it. (I did find a post > from Thiago Macieira ranting that QDataStream itself was never > meant to be decoded by anything other than QDataStream and is > thus not extensively documented.) > > Here are a couple of example packets: > > With DxCall and DxGrid: > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00000000 ad bc cb da 00 00 00 02 00 00 00 01 00 00 00 06 > |................| > > 00000010 57 53 4a 54 2d 58 00 00 00 00 00 d6 c0 90 00 00 > |WSJT-X..........| > > 00000020 00 03 46 54 38 00 00 00 04 57 30 59 4b 00 00 00 > |..FT8....W0YK...| > > 00000030 03 2d 31 38 00 00 00 03 46 54 38 00 00 00 00 00 > |.-18....FT8.....| > > 00000040 02 74 00 00 06 d6 00 00 00 05 4b 30 53 57 45 00 > |.t........K0SWE.| > > 00000050 00 00 06 44 4d 37 39 4c 56 00 00 00 04 43 4d 39 > |...DM79LV....CM9| > > 00000060 37 00 ff ff ff ff 00 00 ff ff ff ff ff ff ff ff > |7...............| > > 00000070 00 00 00 07 44 65 66 61 75 6c 74 > |....Default | > > > Magic number 00-03 > > Schema number 04-07 > > * Status Out 1 quint32 08-0b > > * Id (unique key) utf8 0c-15 > > * Dial Frequency (Hz) quint64 16-1d > > * Mode utf8 1e-24 > > * DX call utf8 25-2c > > * Report utf8 2d-33 > > * Tx Mode utf8 34-3a > > * Tx Enabled bool 3b > > * Transmitting bool 3c > > * Decoding bool 3d > > * Rx DF quint32 3e-41 > > * Tx DF quint32 42-45 > > * DE call utf8 46-4e > > * DE grid utf8 4f-58 > > * DX grid utf8 59-60 > > * Tx Watchdog bool 61? > > * Sub-mode utf8 ??? > > * Fast mode bool ??? > > * Special Operation Mode quint8 ??? > > * Frequency Tolerance quint32 ??? > > * T/R Period quint32 ??? > > * Configuration Name utf8 70-7a > > > > Without DxCall or DxGrid (note, TxWatchdog is not here, which > makes me question it above): > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00000000 ad bc cb da 00 00 00 02 00 00 00 01 00 00 00 06 > |................| > > 00000010 57 53 4a 54 2d 58 00 00 00 00 00 d6 c0 90 00 00 > |WSJT-X..........| > > 00000020 00 03 46 54 38 00 00 00 00 00 00 00 03 2d 31 38 > |..FT8........-18| > > 00000030 00 00 00 03 46 54 38 00 00 00 00 00 02 74 00 00 > |....FT8......t..| > > 00000040 06 d6 00 00 00 05 4b 30 53 57 45 00 00 00 06 44 > |......K0SWE....D| > > 00000050 4d 37 39 4c 56 ff ff ff ff 00 ff ff ff ff 00 00 > |M79LV...........| > > 00000060 ff ff ff ff ff ff ff ff 00 00 00 07 44 65 66 61 > |............Defa| > > 00000070 75 6c 74 > |ult | > > > Magic number 00-03 > > Schema number 04-07 > > * Status Out 1 quint32 08-0b > > * Id (unique key) utf8 0c-15 > > * Dial Frequency (Hz) quint64 16-1d > > * Mode utf8 1e-24 > > * DX call utf8 25-28 > > * Report utf8 29-2f > > * Tx Mode utf8 30-36 > > * Tx Enabled bool 37 > > * Transmitting bool 38 > > * Decoding bool 39 > > * Rx DF quint32 3a-3d > > * Tx DF quint32 3e-41 > > * DE call utf8 42-4a > > * DE grid utf8 4b-54 > > * DX grid utf8 ??? > > * Tx Watchdog bool ??? > > * Sub-mode utf8 ??? > > * Fast mode bool ??? > > * Special Operation Mode quint8 ??? > > * Frequency Tolerance quint32 ??? > > * T/R Period quint32 ??? > > * Configuration Name utf8 68-72 > > > Any pointers are appreciated! > 73, Chris, K0SWE > |
