On 16/04/2015 21:59, SM0THU wrote: > Hi Bill, Hi Anders, > > I have now implemented reading what is sent from WSJT-X. I noted a couple of > things. > > The schema says that Delta time (S) is a float (32 bits according to > http://doc.qt.io/qt-5/datastreamformat.html), but it’s sent in 64 bits. OK, since Qt 5.0 the QDataStream class either does all double precision or all single precision for floating point numbers. I had left it at default and this means double precision. I will leave it as such and put a note in the message descriptions. > > Byte array from a decode: > <adbccbda 00000001 00000002 00000006 57534a54 2d580104 6f4100ff fffff83f > b99999a0 00000000 00044d00 00000123 0000000e 52334149 20544136 4158202d 3038> > > Split into schema items: > adbccbda magic number > 00000001 Schema #1 > 00000002 Type 2 “Decode" > 00000006 57534a54 2d58 Id "WSJT-X" > 01 New true > 04 6f4100 Time “74400000" ms since midnight > ff fffff8 snr “-8" > 3f b99999a0 000000 Delta time “0.1” (64 bits) > 00 00044d Delta frequency “1101" > 00 00000123 Mode “#" > 0000000e 52334149 20544136 4158202d 3038 Message "R3AI TA6AX -08" > > > When “QSO Logged” is sent, there are 8 zero-bytes between the id and date & > time. I’m not sure what they are for. Is the date also 64bit? QT document say > Quint32. This one is a bit more messy, having looked at the QDataStream source code it seems that the Qt 5.0 format for QDateTime was implemented incorrectly and serialized all times as UTC. For Qt 5.2 they have switched to adding offset support to the timespec field. Since the Qt 5.0 format appears to be broken I propose to switch to the Qt 5.2 format. This is not yet documented as far as I can see but the QDateTime serialization is:
QDate qint64 Julian day number *** NOTE THIS *** QTime quint32 ms since midnight timespec uint8 the value of this determines the meaning of the next offset qint32 offset from UTC (used when timespec is 2) zone a-whole-mess-of-stuff-we-don't-want (used when timespec=3) The zone part is long and I think we can ignore it because we will always use UTC time and have neither offset nor zone. > > This is a byte array sent when logging a QSO. > <adbccbda 00000001 00000005 00000006 57534a54 2d580000 00000025 7e290438 > 1dc50100 00000655 41314e41 4e000000 044b5037 31000000 0000d6d2 f1000000 > 034a5439 00000003 2d313000 0000032d 31300000 00013500 00000454 65737400 > 00000454 657374> > > Split into schema items: > adbccbda magic number > 00000001 Schema #1 > 00000005 Type 5 “QSO Logged" > 00000006 57534a54 2d58 Id "WSJT-X" > 0000 0000 ???????? > 0025 7e29 Date 2457129 (Todays julian date) > 0438 1dc5 Time 70786501 ms since midnight > 01 Time spec (UTC) > 00 00000655 41314e41 4e DX Call “UA1NAN" > 000000 044b5037 31 DX grid “KP71" > 000000 0000d6d2 f1 Dial Frequency “14078705" > 000000 034a5439 Mode “JT9" > 00000003 2d3130 Report send “-10" > 00 0000032d 3130 Report received “-10" > 0000 000135 TX power “5" > 00 00000454 657374 Comments “Test" > 00 00000454 657374 Name “Test" Sorry for the misinformation, I didn't spot the issues since I only tested with the matching QDataStream readers which of course worked :( I have committed a change to move on to schema number 2 and using the Qt_5_2 serialization formats. The differences for you are that the schema number changes and float is 64-bit IEEE and QDate is 64-bit Julian day number. The last two were there already but the new format is best anyway given the known problems with Qt_5_0. Hopefully the Qt developers will get around to updating the serialization formats web page soon. > > 73 > /Anders - SM0THU 73 Bill G4WJS. > >> On 15 Apr 2015, at 18:50, Bill Somerville <g4...@classdesign.com> wrote: >> >> Hi All, >> >> On 14/04/2015 19:46, Bill Somerville wrote: >>> On 14/04/2015 18:35, SM0THU wrote: >>>> Hi Bill, >>>> >>>> >>>> That sounds great. >> <snip> >>>> I’ll have to look into QDataStream and see how I can do that with Swift. >>> Here is the key information: http://doc.qt.io/qt-5/datastreamformat.html >>> >>> That page lists how the various supported data types are serialized. All >>> the numbers are Big Endian i.e. normal network byte ordering. There will >>> be a header and the message formats are implicit i.e. no type ids or >>> framing, just read the expected fields in the expected order. Simple and >>> compact. Strings will all be encoded as utf-8 and serialized as >>> QByteArray types i.e. 32-bit count followed by the string content >>> converted to utf-8. >>> >>> There will be a C++ header file that documents the message format, >>> headers, various message types and, content. Here is a provisional >>> snapshot of that: >> <snip> >>> So a message will be like: >>> >>> Magic number id: 0xabbccbda >>> Schema number: 0x00000001 >>> followed by the serialized payload. >>> >>> So for example a two field payload of a single string of length 10 that >>> maps to a 10 byte utf-8 sequence and a 32 bit number would form a >>> message of length 26 bytes: >>> >>> the eight byte header above >>> a string count of 10 serialized as a 32 bit unsigned BE number (4 bytes) >>> the 10 utf-8 bytes >>> 4 bytes of the number in BE format. >>> >>> The real messages have a payload header as well which is an unsigned >>> 32-bit number for the message type followed by a utf-8 string that >>> identifies the "arena" of the message. This last field the the same >>> unique string that identifies the instance of WSJT-X i.e. "WSJT-X" for >>> the default instance or "WSJT-X - rigname" for a WSJT-X instance started as: >>> >>> wsjtx --rig-name=rigname >>> >>> The message server (your application) cannot broadcast messages but it >>> can reply to a client (a WSJT-X instance) that it has received messages >>> from beforehand. This is sort of similar to a web server that serves >>> many clients except that the bulk of the data flows from client to >>> server and the protocol is UDP. >> This is now committed to the WSJT-X development branch. For now the demo >> application that shows off the UDP server facilities is built and >> installed along with the rest of the WSJT-X application. It is called >> message_aggregator(.exe) and is fully functional. I intend to remove >> this application from the installed tree for release builds but for >> convenience for now it is in for anyone who wants to investigate this >> new feature. >>>> 73 >>>> /Anders >>> 73 >>> Bill >> 73 >> Bill >> G4WJS. >>> G4WJS. >>>>> On 14 Apr 2015, at 19:23, Bill Somerville <g4...@classdesign.com> wrote: >>>>> >>>>> On 14/04/2015 17:57, Anders Östlund wrote: >>>>>> Hi, >>>>> Hi Anders, >>>>>> I'm writing a program that is kind of a JT-Alert alternative, but for >>>>>> Mac OS X. >>>>>> Being able to trigger a reply to a CQ from externally would be a great >>>>>> feature. >>>>>> >>>>>> I've got Mike's patch to work on r5068. Before trying to get it to work >>>>>> on a >>>>>> more recent commit, I just want to ask if there has been more work done >>>>>> on >>>>>> this already. >>>>> Yes, I am close to committing a full functioning version with a formal >>>>> message protocol that is extensible. I am adding some other messages >>>>> (outgoing from WSJT-X) that should be useful to applications like >>>>> JTAlert and yours such as status updates, WSJT-X closedown and >>>>> notification of QSOs logged. >>>>> >>>>> The protocol is binary and pretty simple, based on the Qt QDataStream >>>>> serialization capability. I am testing my changes right now after a >>>>> final clean up before check in, currently it is broken but I should have >>>>> it all working again shortly. >>>>>> I'd be happy to help out with testing or coding, if needed. >>>>> OK. What is your choice of implementation language and tools for your >>>>> application? I would like to have some reference code for various >>>>> platforms for usage of the message protocol. C++ with Qt I have in hand >>>>> already. >>>>>> 73 >>>>>> /Anders - SM0THU >>>>>> http://jt-bridge.eller.nu >>>>> 73 >>>>> Bill >>>>> G4WJS. ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
