Band field to UDP is not in correct format

[ny4i]

The band field in the XML record sent to UDP is in the literal band value (i.e., 80 is sent as 80. While this is certainly logical, the issue is the N1MM specification for band is defined to be as follows:

“band” is composed of 2 or 3 characters that may include localized delimiters. For example, 80 meters may be “3.5” or “3,5”; 160 meters as “1.8” or “1,8” The user’s Windows setting will determine which delimiter is present in the band tag

The causes an issue where the AA0Z dashboard nor the n1mm_view program will process the correct band.

So for 80 meters, the field should be 3.5 or 3,5 depending upon localaziation. 160m would be 1.8, 40 meters would be 7.

Here is an enumeration from a logger program I work on that shows the conversion:

const BandTypeToUDPContactBand : array[Band160..BandLight] of PChar = ( '1.8', '3.5', '7', '14', '21', '28', '5.4', '30', '17', '12', '50', '144', '222', '420', '902', '1.2G', '2.3G', '3.4G', '5.7G', '10G', '24G', 'LIGHT' );

Note I am logging this as a bug versus just fixing it as I am sure there is a very "Python" way to do the conversion rather than a how I would do it. Basically something to convert the 160 to 1.8, 80 to 3.5, 40 to 7, 20 to 14, 15 to 21, 10 to 28 and 6 to 50 in a magic one-liner. I'm curious of the proper way to do the conversion. The rest of the bands in the array above are not valid for FD, but 2m, 440 and 222 would be for Winter FD.

Why band is really sent as frequency is a question for the N1MM development team :)

This was found on a Pi 5 with Bookworm but I suspect the OS is immaterial.

[ny4i]

It looks like a dictionary would do it. Trying it now...

[mbridak]

Merged PR, Thanks.