Address and other parameters to be stored in EPROM

[pjalocha]

We need to store: Address: 24 bits ICAO flag: 1 bit (if the above address is ICAO assigned) Aircraft type: 4 bits Private/visibility flag: 1 bit This data could be combined in one Acft_ID 32-bit word, like we do already in OGN

Address could be as well generated from the 96-bit unique CPU ID.

Would be good to provide calls to read the Acft_ID from any task and commands in the console to store this data. As well a call to read the unique ID is needed and an algorith to convert it to 24-bit address.

[snip]

Problem of allowing configuration of address and aircraft type is that it require some skills to configure it and also (more problematic) to maintain it (changing from one aircraft to another one, ...). Risks are duplicate IDs and wrong data.

We can use online db to convert OGN ID to OACI ID + other data (reg num, owner, ...). (Flarmnet like) It seems to be easier to maintain it on website that on device.

If we maintain data configuration in device maybe we can override them on ogn web db? Changing aircraft type, changing from public to private the visibility flag (but not in the other way).

[pjalocha]

Here I find how to get the 96-bit unique ID for STM32.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fIs%20there%20a%20unique%20ID%20available%20to%20read%20from%20each%20MCU&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=5149

If we want to make a 24-bit address out of it we would need an algorithm that selects the right part of this ID as it must be different for every tracker. As well the algorithm should allow for other platforms than STM32 to generate their unique 24-bit address.

[pjalocha]

This is likely exact information for STM32L152RB:

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FUnique%20ID%20for%20STM32L-Discovery%20MCU&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=248

Are these addresses specified in some configuration files or we have to find them for every individual MCU type ?

[SylwBar]

STM32L series reference manual: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00240193.pdf

states in chapter 31: The 96-bit unique device identifier provides a reference number which is unique for any device and in any context. These bits can never be altered by the user. Base address: 0x1FF80050 for Cat.1 and Cat.2 devices and 0x1FF800D0 for Cat.3, Cat.4 and Cat.5 devices

[pyrog]

Update link:

RM0038 Reference manual STM32L100xx, STM32L151xx, STM32L152xx and STM32L162xx advanced ARM®-based 32-bit MCUs

[pyrog]

According to ef3c9184af686673239f64fa9f433d5265dd8546, does the 24 bits ID is really unique ?

// set the address to the unique-ID of the CPU
options.AcftID        = 0x07000000 | ((*(uint32_t*)0x1FF80050)&0x00FFFFFF);

This is a 24 bits mask of the 96 bits unique ID. So it could have a lot collisions. 72^2 ??

[pyrog]

Address could be as well generated from the 96-bit unique CPU ID.

Also, we could use the unique serial number of the USB chip or the serial number of the GPS.

• FTDI FT230X (USB to BASIC UART IC)
• u-blox 6 Receiver Description

It's possible to use the EEPROM of the FTDI chip to store parameters, but I don't know if this memory is readable from the UART side?

Also, theses S/N are longer than 24 bits, so trackers could have the same radio ID 🤔

[SylwBar]

STM32 CPU has 96-bit (12 bytes) unique ID, but this is too long for 3-bytes of OGN address. We checked then what part of these 96-bits is changing most frequently and used it as initial address. For trackers released so far it worked fine. To do it better 12-bytes of CPU ID could be combined to 3-bytes. I think this could be done by four XOR operations on each 3-bytes of CPU unique ID. OGN tracker address could be changed by user later initial value calculated above is not permanent. There is no need to use FTDI's EEPROM STM32 has internal 8kB of EEPROM that is used already for storing all options.

[pyrog]

STM32 CPU has 96-bit (12 bytes) unique ID, but this is too long for 3-bytes of OGN address. We checked then what part of these 96-bits is changing most frequently and used it as initial address.

Ok

To do it better 12-bytes of CPU ID could be combined to 3-bytes. I think this could be done by four XOR operations on each 3-bytes of CPU unique ID.

👍

There is no need to use FTDI's EEPROM STM32 has internal 8kB of EEPROM that is used already for storing all options.

The idea was to use FTDI tools to store a new ID. Now I could use one of your tracker, and I see that it's easy to set the value with a terminal 😄