Any plans to support SX126x modules?

dernasherbrezon / sx127x

Library to work with Semtech chips SX1276/77/78/79.

Apache License 2.0

31 stars 4 forks source link

Any plans to support SX126x modules? #6

Closed dizcza closed 8 months ago

dizcza commented 8 months ago

sx1272 and sx1262 are often interchanged and unfortunately, I haven't seen a library that supports both except RadioLib.

Also, are you planning to implement a transport layer on top of the physical layer as it's done in RadioHead (device-to-device communication in a network, encryption, send failure notification and handling via retry)?

dernasherbrezon commented 8 months ago

Hi,

There is little value in having support 2 different chips under the same repository. They won't share anything in common. According to sx126x data sheet it works a little bit differently. Even though it supports both LoRa and FSK.

sx127x need only SPI transport, that already abstracted in ESP32, Linux or any other systems.

Retry, encryption and etc is not implemented in the chip's hardware. Thus must be implemented on the higher abstraction layers.

dizcza commented 7 months ago

Could you recommend any third-party lib for ESP32 that provides HW-agnostic higher abstraction layers as I mentioned? Given hardware send & receive methods implemented in your lib, it'd be nice to bind it with user-friendly APIs that send & receive messages to a particular client rather than just broadcasting, encryption, etc.

dernasherbrezon commented 7 months ago

You most likely need a higher level protocol - LoRa WAN. You can find details and implementation here: https://github.com/Lora-net/LoRaMac-node

dizcza commented 7 months ago

Please consider adding the constant qualifier to arguments that should be constant. In particular, sx127x_lora_tx_set_for_transmission. The spi_transaction_t.tx_buffer is marked constant in ESP-IDF.

dernasherbrezon commented 7 months ago

Fixed in https://github.com/dernasherbrezon/sx127x/commit/17c90a61db21bef16a9195828075a7c38a161363

dizcza commented 6 months ago

When I tighten the Lora SS pin to GND (in software by setting it low with a pull-down) and set dev_cfg.spics_io_num = -1, the module is initialized correctly but the transmission is never completed (DIO0 ISR callback never gets executed). Is it expected behavior? I don't see any reason why one shouldn't tighten the SS to GND.

dernasherbrezon commented 6 months ago

SS pin should be HIGH after transmutation completes according to the specification: