Re: [RFC net-next 00/15] net: A socket API for LoRa

[Helmut Tschemernjak]

Dear Andreas,

I put the kernel support for the SX1276 LoRa chip in question. I donât 
think that this kind of device should be in the Linux kernel.

Here are a few facts to consider:
- A LoRa transaction is very slow (e.g. SF7 needs about 210 ms, for 
SF12 6280 ms) for 12 bytes user data with acknowledge.

- There are many different implementations for the antenna switch, 
switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know 
SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec 
STM32-L4) they are all different regarding this.

- The LoRa chip device ID is only 8-bit which is not sufficient for 
larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit 
device IDs.

- The chip can do MTU sizes up to 2048 bytes, most protocols use less 
than 250 bytes.

- Applications do on-the-fly channel and spreading factor switching 
which makes it more difficult for the configuration.

- The chip supports Lora modulation as well as FSK, GFSK, MSK, GMSK, 
and OOK modulation, for some use cases the other modulations are of 
interest, e.g. to communicated with other devices.

- Power saving modes, like sleep, suspend may be required for battery 
operation.

- Cad detection is very flexible and can be differently used.

- LoRa preamble may be different depending on the protocol used.

- The new Lora chip SX1262 / 68 (successor of the SX1276) has different 
hardware and all different registers, it is driver incompatible with the 
SX1276. It needs an entire new driver.

- The device is not multi-process capable (only a single process can 
communicate with it).

- There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and 
RAW) via a serial connection only, again complete different API compared 
the SX1276 chip. Software updates for this devices are difficult.

- I am even convinced that the LoRaWAN protocol with the concentrator 
concept is not good, the peer to peer communication and a standard MQTT 
gateway (what we do) is way more flexible.

For all this reasons, I feel a user level driver task implementation is 
way more flexible. I did a lot of work/enhancements on the SX1276 link 
level driver from Semtech, it is available and maintained on mbed.org 
and supports mbed-os, Arduino and is prepared for Linux.
https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/

Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the 
LoRaWAN protocol can run on top of the SX1276GenericLib. We may should 
focus on such a driver library getting supported for multiple OS's (Win, 
Linux, mbed, Ardino, etc.)

Again I feel a Linux kernel device driver for the SX1276 chip make 
little sense for me.

Regards
Helmut Tschemernjak (www.radioshuttle.de, www.helios.de)