Shared configs/data types for LoRa based radios
what do you think if we would use commont data types and configs for all LoRa-based radios (rfm96, rfm59, maybe sometimes sx126x and the hopefully soon to come CubeCell)? It would make maintaining lots easyer.
Same for the two different nrf24 radios (but here I'm not sure if they really got a future).
@eiten clould you expand on what you mean by data types and configs in this context, maybe by examples?
@mfalkvidd of course.
We have a MY_RFM69_FREQUENCY and a MY_RFM95_FREQUENCY. I think it would be easyer for the end user if we just got a MY_FREQUENCY.
Also, for future implementation of other LoRa modules (CubeCell, SX126x...) i think it would be good if we have a
lora.hwhere we define structs like these, to define
lora_sequence_number... as well as defines like
LORA_HEADER_LENand so on.
It would ensure compatibility between lora modules and make maintaining easyer. (I know what I am talking about, I was looking for my error in the CubeCell driver for a half a day only finding that i defined the cubecell sequence number as a uint_8, not being compatible to the rfm95 uint16_t )
Thanks for explaining @eite. Consolidating the frequency setting to MY_FREQUENCY would make it hard to support multiple radios in a straightforward way. If a gateway has a lora radio and a rfm69 radio, they would not necessarily use the same frequency.
For the structs, I'm afraid that is beyond my competence but hopefully someone more skilled in the radio code can contribute.
@mfalkvidd Agree. Another consideration would be that some #defines would be used for multiple radios (but not all), and some would be radio specific. I prefer to have the usage explicit in the name, to prevent confusion on which define is used by each radio.
@mfalkvidd Ah, I did not know that it's possible for a gateway to have multiple radios!
@eiten support for multiple radios is a new feature, only available in the development branch and not well documented yet so no surprise you weren't aware of it.