Dear Bill
Thank you for your comments about message type 268. My thinking is that until
message type 16 arrives it's OK to only look at one byte in order to save
valuable microseconds. The same with the Schema, do you really need 32 bits?
For detecting the ADIF string surely it's better to look at a single byte per
packet rather than to convert each packet to string and then to search that
string for <EOH> ? The issue I have with that approach is the zero bytes are
seen as end of string markers by the .ToString method in .Net so you have to
convert zeros to something else like spaces in a loop before you convert and
all that takes more time.
Of all the features that I have added to my helper application the one I like
most is this LOTW logger. It works silently and invisibly like the PSK upload
but it is more important to tell the user when it has failed, so there is more
to get right. My initial idea was to strip out all the alerting and
presentation stuff in my program and offer an executable to the WSJT community
that would sit in the background as a service maybe. My current thinking
however is that this is something that the WSJT-X client should do itself as it
is so useful. If you want to see my code you are quite welcome.
Regards and Best 73 de G4SWY Derek +++
On Monday, 18 March 2019, 00:14:15 GMT, Bill Somerville
<[email protected]> wrote:
Hi Derek,
a couple of comments below that will make your application a little more
robust.
On 17/03/2019 23:46, Derek Turner via wsjt-devel wrote:
I do it for real time LOTW uploads in my helper program.
You must only look at type 12 packets.
This is a good way to easily capture logged QSO data, particularly if you
already ADIF parsing routines, which should be fundamental to any logging
application.
Byte eleven of the UDP byte array contains the message type.
That's not quite correct, bytes 9 through 12 contain the message type as a
32-bit unsigned number in normal network byte order. You may be referring to
byte index 11 counting from zero as value 12, but this will also be the same
value for message type 268 (and others), Ok that doesn't exist currently but it
may at some point.
Anyway, see below for a safe option.
The first RX message in your debug is a type five broadcast. Your ?????
strings contain Qt types and you would have to decode them back to the same
logging ADIF string. The type 12 does it for you.
It is more than an ADIF string, it is whole ADIF file which you can take
advantage of if you do not want to be troubled with binary valued fields like
the message type. Instead you can simply ignore all UDP datagrams until you see
one starting with 4 hex bytes 0xadbccbda (ok, that is binary but you only need
to check for a fixed value) and also containing the character string "<EOH>".
Then everything following the <EOH> string up to the end of the datagram is a
single ADIF record of the logged QSO.
If you do .Send(new byte[] { 1 } to WSJT it will not understand it. Incoming
packets need a precise format starting with the magic number and then the ID
etc. In any case for your purpose there is no need to have a dialog with WSJT.
Correct, there is no reply to be sent to a WSJT-X instance. This is a UDP
protocol and delivery is not guaranteed (although virtually 100% reliable on a
local network loopback or same subnet destination). WSJT-X dispatches the UDP
messages and moves on, there is no connected protocol, there is no way to
detect a missed message, nor any way to request a repeat.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
