|
From: Bill S. <g4...@cl...> - 2019-03-18 15:07:43
|
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. |