[hpsdr] Radio (Board) Identification

[Joe Martin K5SO]

Hi Doug, 

Interesting proposal that deserves some thought.   I don’t disagree that our present system is not a perfect arrangement.  

Keep in mind however that the Board ID is not the only ID parameter ID that is passed in the packets, the actual firmware version is also passed in the packets in a different byte, so that in itself gives more information than you imply, I believe.  The board ID is currently used, among other uses perhaps, by the HPSDR Programmer to determine how long to make the time out limit for the EEPROM erase process; some FPGAs are small (e.g., Metis, Mercury, Penny(Lane), Hermes) and erase quickly compared to the larger (Angelia and Orion) FPGAs that take a while to erase.  Dave KV0S didn’t think (and I agree) that it was necessary, nor beneficial, to use a long time out delay for erasing FPGAs that didn’t need one.  The current ID method works fine for that purpose and needs no additional expansion.  

While I certainly appreciate that we might want to specify which specific board type is in use (which we do already in a general sense with the current coarse board ID value) the firmware is used in many cases in a variety of hardware configurations of the same board type so it would not be possible for the firmware developer to write the more detailed ID number into the firmware without knowing ahead of time which of the several configurations for the board type is going to be used with the firmware.  In the case of Angelia, as one example, the firmware can be used in any radio that uses the Angelia board such as the ANAN-100D or a barefoot Angelia, or an Angelia with an external PA, or with an Angelia with Alex filters, etc.  In your suggestion it would seem that all of those different configurations should ideally have a different board ID value written into the firmware.  The firmware design would be identical for those units but your suggested approach would seek to use a different board “ID” for each of them depending upon how the user wanted to use the Angelia board, which the firmware writer would not know.  

Having a different board ID for each possible board configuration, and thus a different firmware version for each possible configuration, would lead to many versions of Angelia (etc) firmware for a given firmware design needing to be posted for each release and that in itself would undoubtedly prove to be confusing to the users, in my opinion.  

I haven’t thought through your suggestion completely but these points came immediately to my mind upon reading your message.  Maybe others have comments and suggestions that are constructive for this discussion.  

Thanks for your thoughts on how we might improve things!  Perhaps you have already thought through how to address issues such as these.  I’m all for whatever makes the mose sense!  

73,  Joe K5SO

On Aug 11, 2014, at 5:45 AM, Doug Adams wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> I would like to propose a small change to the firmware of all of the OpenHPSDR-derived radios. The purpose of this change would be to make the firmware update process more automatic and foolproof.
> 
> If you look in Metis- How it works_V1.31 you will see that the Discovery packet returns the following:
> The payload of the UDP/IP reply frame is as follows:
> <0xEFFE><Status>< Metis MAC Address><Code Version><Board_ID><49 bytes of 0x00>
> 
> where
> 
> Board_ID = 1 byte, 0x00 = Metis, 0x01 = Hermes, 0x02 = Griffin, 0x04 = Angelia, 0x05 = Orion 
> 
> Currently the Board_ID field (one byte) is not very informative. If it says I have a Hermes (0x01) is it a TAPR Hermes, an ANAN-100, an ANAN-100B, an ANAN-100D, etc. Couldn't we use the 8 bits (256 possibilities) in this field to be more specific about the radio?
> 
> Perhaps to be backward compatible we could reserve the least significant 4 bits for Board ID and use the most significant four bits for a Sub ID indicating which variant of the Board ID is present.
> 
> If we coupled this change with a "gentlemen's agreement" to name all firmware files in some recognizable way, something like RadioName_vN.M.rbf ( e.g. ANAN100B_v2.4.rbf ) then it would be possible to write a programmer application that would only show you firmware choices appropriate for the radio you are trying to program.
> 
> The current arrangement seems uninformative and error prone.
> 
> 73’s 
> Doug - K3TZR
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20140811/8d69da2c/attachment-0003.htm>