Re: [wsjt-devel] Add generic webservice client to the QSO send program.

[Brian M. <bri...@gm...>]

Hi Derek:

Perhaps others will join in, however, the optimizations that you're talking
about doing might be best to accomplish after you have correct packet
parsing working?

Regarding the scanning-packet aspect, my recollection is that the C#
libraries are rich in their ability to scan byte buffers as well as string
buffers, and there are also methods to process Bytes into strings. Perhaps
keeping the scanning of bytes in the bytes domain until you find the byte
you're looking for would be a better angle of attack?

-Brian N9ADG




On Mon, Mar 18, 2019 at 7:52 AM Derek Turner via wsjt-devel <
wsj...@li...> wrote:

> 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 <
> g4...@cl...> 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
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>