Menu
▾
▴
Re: [wsjt-devel] Decoding UDP without QDataStream?
|
From: Chris K. <xy...@gm...> - 2020-07-04 22:05:45
|
Aha, I had read through most of the header of NetworkMessage.hpp but missed the distinction between empty vs. null strings. I see it works out when interpreted that way. Thanks for sorting me out, Bill and Thomas! On Sat, Jul 4, 2020 at 2:58 PM Bill Somerville <g4...@cl...> wrote: > 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...> 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...> 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 >>> >> > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
