Open TristanWebber opened 1 year ago
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.
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:
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
#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.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
Setting Debug Level 2 does not give that much information either.
20:59:19.886 -> (⸮IR⸮pIStarting
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 -> ⸮⸮Ars⸮⸮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)
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?
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.
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:
#include <arduino_lmic_hal_boards.h>
const lmic_pinmap *pPinMap = Arduino_LMIC::GetPinmap_ThisBoard();
os_init();
I call os_init_ex(pPinMap);
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!
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:
- Including another hal header file
#include <arduino_lmic_hal_boards.h>
- 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();
- In setup instead of calling
os_init();
I callos_init_ex(pPinMap);
- 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.
Great news! I'm glad it's working for you.
@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 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
:
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 https://github.com/mcci-catena/arduino-lmic/pull/949#issuecomment-2115664281, or unsubscribe https://github.com/notifications/unsubscribe-auth/AY6BUJ7MYASTJAVL7TZGNH3ZCTLZRAVCNFSM6AAAAAA3JKYDOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJVGY3DIMRYGE . You are receiving this because you were mentioned.Message ID: @.***>
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.
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 https://github.com/mcci-catena/arduino-lmic/pull/949#issuecomment-2130911425, or unsubscribe https://github.com/notifications/unsubscribe-auth/AY6BUJ75FOL3XB7OO4TDBT3ZEAWGTAVCNFSM6AAAAAA3JKYDOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZQHEYTCNBSGU . You are receiving this because you were mentioned.Message ID: @.***>
Look like this is still in progress. Let me know when you're ready for a review / merge cycle.
@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.
Great! I’ll try to get to this over the next week.
Best regards,
--Terry
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.
ping - is a merge still planned?
Adds driver for SX126x modems.
#if
to select the correct filePhysical tests - Adding notes here because it's been tested in a relatively narrow set of possible configurations: