Shared configs/data types for LoRa based radios
-
Hello there,
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).Regards, Edi
-
Hello there,
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).Regards, Edi
-
@mfalkvidd of course.
Regarding configs:
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 alora.hwhere we define structs like these, to definelora_header_t,lora_ack_t,lora_packet_t,lora_sequence_number... as well as defines likeLORA_MAX_PACKET_LEN,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 :face_palm:)
Regards, Edi -
@mfalkvidd of course.
Regarding configs:
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 alora.hwhere we define structs like these, to definelora_header_t,lora_ack_t,lora_packet_t,lora_sequence_number... as well as defines likeLORA_MAX_PACKET_LEN,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 :face_palm:)
Regards, EdiThanks 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.
-
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.
-
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 Ah, I did not know that it's possible for a gateway to have multiple radios!
-
@mfalkvidd Ah, I did not know that it's possible for a gateway to have multiple radios!