Add driver for SX126x modems

[TristanWebber]

Adds driver for SX126x modems.

• Created new driver (radio_sx126x.c). Uses the same functions as radio.c for anything called by LMIC but for 'private' functions it follows the API described in the SX126x Data Sheet
• Renamed radio.c to radio_sx127x.c and added #if to select the correct file
• Modified config.h and lmic_project_config.h to handle the new options
• Minor additions to hal.cpp and hal.h to deal with the slightly different interface on the SX126x family
• Added a new board pinmap for Heltec Lora32 V3 (which is identical to Heltec Wireless Stick Lite V3)

Physical tests - Adding notes here because it's been tested in a relatively narrow set of possible configurations:

• Hardware tested: Heltec Wireless Stick Lite V3 with MCU = ESP32-S3 @ 240MHz and SX1262 modem configured with DC-DC regulator, DIO2 controlling RF Antenna, DIO3 controlling TCXO
• RX window timing was adjusted to account for differences in this modem vs the SX127x family
• Tested on TTN using OTAA join of LoRaWAN 1.0.3 over AU915
• FSK has been implemented but NOT tested

[baranator]

Hi!

I'm currently tinkering around with the Heltec Wireless Stick lite v3 and stumbled across your PR. Somehow i cannot get it to work - neither in platformio nor in Arduino. I set the defines in lmic_project_config.h and also alternatively tried setting a pinmap according to the heltec schematic for this device.

#define CFG_eu868 1
#define CFG_sx1262_radio 1
#define ARDUINO_heltec_wifi_lora_32_V3
#define hal_init LMICHAL_init

I tried the ttn-otaa.ino example of this library in the Arduino IDE, set the Board to Heltec Wireless Stick (v3)

The "best" results i got with this configuration: The device boots, and i get the serial-output Starting but then nothing else happens. Strangely if i then push the user_sw button on the board, i get this, but in the ttn-console i don't see the joining request or any transferred data. This also happens, when i try the LMIC-node example .

Do you have any ideas on this? Would be great to get it running.

[TristanWebber]

Hi Eike,

Thanks for getting in touch. I won't be able to look at this in depth this week but should be able to give it some time next week. However a couple of comments to get you started:

1. I've only tested on the AU915 band, so we may need to have some back and forth to get to issues with EU868 because I don't have the means to directly test that myself. But I'm up for it if you are
2. I have avoided the lmic_project_config.h file and have instead been using platform.ini in my platform.io projects. I doubt this will make any difference but figured I'd mention just in case:

build_flags = 
	-D hal_init=LMICHAL_init
	-D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
	-D CFG_au915=1
	-D CFG_sx1262_radio=1
	-D LMIC_DEBUG_LEVEL=2

3. I suggest you compile the project with #define LMIC_DEBUG_LEVEL 2 or in platform.ini. This should give some logging after the Starting you are currently getting and with any luck this will provide some useful information on where I can start looking for the issue.
4. Do you own or have access to the gateway the node would be connecting to? If so, can you see any logging on the gateway?

I'll get onto this in a week or so but if you can get some debug logs in the interim that would give me a head start!

Tristan

[baranator]

Setting Debug Level 2 does not give that much information either.

20:59:19.886 -> (⸮�I�R⸮p��I��Starting
20:59:51.537 -> Packet queued
20:59:51.570 -> 1978335: EV_JOINING
20:59:51.570 -> 1978341: engineUpdate, opmode=0x4
20:59:56.658 -> 2298138: engineUpdate, opmode=0x4
20:59:56.691 -> 2298155: EV_TXSTART
21:12:58.326 -> 51150091: TXMODE, freq=868100000, len=23, SF=7, BW=125, CR=4/5, IH=0

This is the output; at 20:59:20 i rebooted the wifi stick via reset button, then the Starting message appears, but nothing else happens. At 20:59:51 i pressed the user-Switch which causes the messages from Packet queued to EV_TXSTART , at 21:12:58 i pressed it again and got that TXMODE message. (the behaviour is the same, when i press and hold the userswitch for suspicious 5 seconds.)

The Gateway I'm testing with is mine and works for another TTN-application. However, when trying to use the sx1262 implementation, nothing happens and i don't see any Join-request, confirmation or even a payload-message.

I then tried to use the AU915 frequency, hoping to see some message about a failed join but got this:

21:32:30.889 -> �⸮�⸮A�r�s��⸮�⸮Starting
21:32:58.372 -> 1717369: engineUpdate, opmode=0x8
21:32:58.406 -> Packet queued
21:32:58.439 -> 1717394: EV_JOINING
21:32:58.439 -> 1717400: engineUpdate, opmode=0xc
21:32:58.472 -> 1717417: EV_TXSTART
21:32:58.505 -> 1717520: TXMODE, freq=926800000, len=23, SF=10, BW=125, CR=4/5, IH=0

again, when userswitch was pressed at 21:32:58. In contrast to the EU868 procedure the 5-second-gap when holding the userswitch is gone (as you see at the timestamps)

[TristanWebber]

Thanks for that. The behaviour with the USER switch is strange - I don't recall anything within the example or the LMIC that would be using that pin.

What baud rate are you using for serial output? Can I suggest trying with 115200?

As for a running commentary on what may be happening with those debug messages, after the line:

21:12:58.326 -> 51150091: TXMODE, freq=868100000, len=23, SF=7, BW=125, CR=4/5, IH=0,

if everything was working correctly we would expect to see a debug message from the IRQ to identify if the transmission was completed, such as:

TIME: IRQ handler, dio=0
TIME: IRQ rawFlags=0001
TIME: IRQ flags=08

If we're not seeing the IRQ handler triggering it points to the transmission for the join request not being sent. Is the antenna connected to the board?

[baranator]

Thanks for that. The behaviour with the USER switch is strange - I don't recall anything within the example or the LMIC that would be using that pin.
yep. That is, what i puzzles me the most. I literally don't see any connection between that switch and the code/lib.

I would be ashamed, but did i may simply did the pin-wiring wrong? Checked it many times and see nothing wrong:

const lmic_pinmap lmic_pins = {
    .nss = 8,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 12,
    .dio = {  14 , LMIC_UNUSED_PIN, LMIC_UNUSED_PIN},
        .rxtx_rx_active = 0,
};

and my platformio.ini looks like this:

[mcci_lmic]
lib_deps =
    https://github.com/TristanWebber/arduino-lmic.git#sx126x ; mcci w sx1262

build_flags =
    -D hal_init=LMICHAL_init
    -D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
    -D LMIC_DEBUG_LEVEL=2            
    -D CFG_eu868=1

[env:heltec_wifi_lora_32_V3]
platform = espressif32
board = heltec_wifi_lora_32_V3
framework = arduino
lib_deps =  
    ${mcci_lmic.lib_deps}
build_flags=
    ${mcci_lmic.build_flags}	
    -D CFG_sx1262_radio=1

Do you may have a minimum working example that i could test, just to ensure not a stupidity of mine is the cause of the problem?

What baud rate are you using for serial output? Can I suggest trying with 115200?

had it on 9600, but changing it to 115200 made no difference.

[TristanWebber]

Your pinmap looks fine, as does the platform.ini file. However I have been assigning the pinmap differently - I have been calling a function in the HAL. The minimal example I used for initial testing is almost identical to the ttn-otaa.ino example but with the following changes:

1. Including another hal header file #include <arduino_lmic_hal_boards.h>
2. Instead of explicitly assigning the pinmap I have been assigning a pointer to the pinmap in the hal
   const lmic_pinmap *pPinMap = Arduino_LMIC::GetPinmap_ThisBoard();
3. In setup instead of calling os_init(); I call os_init_ex(pPinMap);
4. I made a couple of other changes that result in better connection but they are likely region specific so I won't suggest those for eu868 at this point

I suspect this difference may result in a couple of horrible little virtual functions I wrote not being called properly. I should probably add this example to the repo if it turns out to work for you!

[baranator]

Your pinmap looks fine, as does the platform.ini file. However I have been assigning the pinmap differently - I have been calling a function in the HAL. The minimal example I used for initial testing is almost identical to the ttn-otaa.ino example but with the following changes:

1. Including another hal header file #include <arduino_lmic_hal_boards.h>
2. Instead of explicitly assigning the pinmap I have been assigning a pointer to the pinmap in the hal const lmic_pinmap *pPinMap = Arduino_LMIC::GetPinmap_ThisBoard();
3. In setup instead of calling os_init(); I call os_init_ex(pPinMap);
4. I made a couple of other changes that result in better connection but they are likely region specific so I won't suggest those for eu868 at this point

I suspect this difference may result in a couple of horrible little virtual functions I wrote not being called properly. I should probably add this example to the repo if it turns out to work for you!

Yes! That worked! The Board instantly joins and sends it's message, everything arrives correctly at the gateway and ttn-application. Thus the IRQ-Messages are shown, too. Let's call it eu868 confirmed ;)

I'll try to have a look at why this workaround is needed and if can rid of it.

[TristanWebber]

Great news! I'm glad it's working for you.

[AndreKR]

@baranator I also have a Heltec Wireless Stick that I would like to use with LoRaWAN. Do you have a project that I can copy as a starting point?

[baranator]

@baranator I also have a Heltec Wireless Stick that I would like to use with LoRaWAN. Do you have a project that I can copy as a starting point?

This is basically the ttn-otaa-Example of the unmodified mcci-catena library with the modifications suggested by @TristanWebber in this Thread and his modified fork added to the platformio.ini :

https://github.com/baranator/sx1262minimal

[TristanWebber]

Thanks Eike!

…

On Fri, 17 May 2024, 2:17 am Eike, ***@***.***> wrote: @baranator <https://github.com/baranator> I also have a Heltec Wireless Stick that I would like to use with LoRaWAN. Do you have a project that I can copy as a starting point? This is basically the ttn-otaa-Example of the unmodified mcci-catena library with the modifications suggested by @TristanWebber <https://github.com/TristanWebber> in this Thread and his modified fork added to the platformio.ini : https://github.com/baranator/sx1262minimal — Reply to this email directly, view it on GitHub <#949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AY6BUJ7MYASTJAVL7TZGNH3ZCTLZRAVCNFSM6AAAAAA3JKYDOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJVGY3DIMRYGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[oseiler2]

Thanks for this, I have successfully got it working on a T-Beam S3 (AU915).
One thing I noticed it that the library configures the DIO[1-3], but not the busy pin returned by queryBusyPin(). Might be helpful to add that, and/or document it.

See TristanWebber#1

[TristanWebber]

Thanks for the feedback. I'll have a look at it next week. Do you mind sharing a link to that board?

…

On Sat, 25 May 2024, 4:34 pm Oliver Seiler, ***@***.***> wrote: Thanks for this, I have successfully got it working on a T-Beam S3 (AU915). One thing I noticed it that the library configures the DIO[1-3], but not the busy pin returned by queryBusyPin(). Might be helpful to add that, and/or document it. — Reply to this email directly, view it on GitHub <#949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AY6BUJ75FOL3XB7OO4TDBT3ZEAWGTAVCNFSM6AAAAAA3JKYDOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZQHEYTCNBSGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[oseiler2]

Sure, here you go
https://www.lilygo.cc/products/softrf-t-beamsupreme?variant=42880905380021

[terrillmoore]

Look like this is still in progress. Let me know when you're ready for a review / merge cycle.

[TristanWebber]

@terrillmoore it's ready when you are. Yesterday's push was a bug fix and otherwise I haven't actively changed the driver for quite a while.

[terrillmoore]

Great! I’ll try to get to this over the next week. Best regards,

…

--Terry

[cyberman54]

I can confirm, this new radio driver works on a SX1262 with TTN (with LoRaWAN 1.0.3) and EU868. Tested on a T-Beam Supreme S3 board today. It did immediately join and transmit. Tested using my paxcounter project, see this branch.

[cyberman54]

ping - is a merge still planned?