+ AA6YQ comments below
I would like to propose a small change to the RadioInfo XML Document UDP packet that broadcasts the status of the radios being controlled by logging software.
Add an element to the RadioInfo packet:
The W1TR HFAUTO software that controls the Palstar HF-AUTO ATU uses these broadcasts to preset the L/C tuning solution in the ATU (long story, some other time).
I’m guessing that there many other APPs out there that use this information for various purposes.
The complete syntax and semantics of the information in the RadioInfo packet varies depending on its source.
It would be unreasonable to require standardization of this XML Document…
+ Exactly why would it be unreasonable to maintain a standard format used by all applications? I'm happy to make any changes in DXLab applications required to do that..
But… inclusion of the <app> element would make it easier for 3rd party software using this to properly decode it and identify its source.
+ If you make it easy to introduce gratuitous differences, guess what will happen.
Logger32 has a clever solution for providing the 1 HZ digit… <Freq>1416350.3</Freq> Use a decimal point and additional digit to get 14.163.503 as a frequency.
Too bad that N1MM chose 10 Hz as the frequency resolution, but that ship has sailed.
+ Two decimal points in a number is "clever"? Why not add 3 or 4 more and be "brilliant"? Or switch to hex, that will be even less readily understandable.
+ When I'm telling war stories about the ridiculous "variances" encountered when importing ADIF files from various applications, "frequencies that contain two decimal points" always gets a big laugh. Let's not standardize this nonsense.
At least applications broadcast RadioInfo UDP packets:
1) N1MM / N1MM+
I also broadcast UDP packets from FLDIGI_UDP and W1TR Rig Control, but use a different XML Document Name.
With the use of the <app> element, I could change those to RadioInfo as well.
+ As far as I'm concerned, the N1MM team should continue owning and maintaining the XML specifications; I'm happy to keep following their lead. If there's a need for more precise frequency resolution, ask them to consider providing it.
+ AA6YQ comments below
We are planning on adding the <app> tag to all our XML messages. This will allow a consuming app to know what app they are talking to, thus if an app is only supposed to control a rotor for N1MM+, it can do that.
+ That's fine.
The whole purpose of XML is standardization, but also to allow extension. If another application is in need of a data element not in the standard, and one we are not willing to add, then it can be ignored by consumers who don't need it.
+ Are you willing to include data elements not supported by N1MM+ in the documentation, assuming you are appropriately informed?
Regarding frequency down to the Hz level, I have not yet heard a requirement for that. When/if it needs to be added, I am inclined to add it as a new element as an integer number of Hz as opposed to integer number of tens of Hz. SDRs controlled by extio use integer Hz to set frequency. It would be a new element to prevent all consumers from needing to handle both the current and the new format. They consumer could chose what to support without the need to coordinate with the sender.
+ Sounds good.