Hi Derek,
comments in line below.
On 18/03/2019 14:48, Derek Turner via wsjt-devel 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?
We are in a world of 64-bit architectures, using 32-bits for numbers is
FB as to use them they will end up in 32-bit or 64-bit registers anyhow.
The trade off of a couple or three bytes against almost no likelihood of
future overflow is also FB.
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.
I had not thought of crippled language features like that. Even a basic
language library like the C one has memcmp() and strcmp() to
differentiate between fixed length and null terminated sequences. A
quick Google search reveals that there really is no problem, even if you
want the ultimate performance of memcmp():
https://stackoverflow.com/questions/43289/comparing-two-byte-arrays-in-net
Note that taking this approach you can do the search for type 12
messages and their payload directly on the UDP receive buffer with no
copies at all until you find one. That will give you the ultimate
performance you are apparently seeking.
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.
My preference is a competent station logging application since uploading
to LoTW is only the first part of the process, the more important
downloading and recording of matches from LoTW along with maintenance
and housekeeping is necessary to complete the process of using LoTW.
Regards and Best 73 de G4SWY Derek +++
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
