LoraMAC-node does not work #8813
Comments
|
Thanks for testing RIOT with LoRaWAN. Let's try to find what's wrong with your setup. From your debug output, I recommend that you disable all debug messages from the driver. You can keep the ones displayed by the semtech-loramac package. The reason for this is that the debug messages introduce extra timing that make the mac failed: the timing are very tight and if the radio misses the preamble, you cannot receive messages from the gateway. At some point, the mac is stuck after sending is done, this is strange. Can you test with the branch of this PR: #8798 ?
I saw that and it's on my todo list, I just need to find the time to update the package. |
|
Thinking of it again, the problem could also come from the xtimer with F4 (since both of your boards are using this model of cpu), and in this case #8807 could help as well. |
aabadie
added
Type: bug
|
Few points, just so we dismiss several reasons: I initially attempted joins without debug enabled, that is why I enabled it. I will now just disable the debugging of the transceiver, but I doubt that is the reason. I will also take a look at PR #8798. I will also take a look at #8807. Also the Nucleo is F4, the bluepill is F1. My first assumption was that the F4 is way to fast and that could be messing things for some reason, but the bluepill is F103 at 72 mhz, also an m3 vs the m4 of the F446. What is your hardware setup. I have some SAMR21 modules, but I would have to make breakout PCBs for those so I can test with them. I also have nrf52dk, but I would prefer not to mess with that. |
|
Quick follow back. Increasing the xtimer backoff, did not help. Disabling the SX127x debugging did not help either. I will test with the PR next. |
Yes, the problem is somewhere else but the transceiver debug has to be disabled in any case (I already lost a lot of time because of this).
Only ST boards: I tested on B-L072Z-LRWAN1 (which embeds an sx1276 radio), nucleo-l073, nucleo-l476 with MBED shields (sx1272 and sx1276). Maybe I tested other nucleo boards with the mbed shields. All worked except the nucleo-l152: this one cannot receive messages at all (even with the driver test application). Maybe @jia200x or @fjmolinas could also help, since they already worked with modtronix radios. Can you post the output of your tests again (with debug enabled in the mac but not in the radio driver), with the xtimer backoff increase ? |
|
Sure: and after loramac join otaa: It essentially cycles through all the EU frequencies but doesn't send anything. I know that the radio works, as it send lora pkts and I get them with the bluepill board. I'm starting to wonder could it be something connected with the fact that all your transceivers have both 433/868 antennas connected or is it something else. I moved around pins and connected to different SPIs. The nucleo is on SPI1, as is the bluepill, but I tried with SPI2 also (on another Nucleo I have AT86RF212b connected there and that works well). I'm completely out of ideas at this point. |
|
I guess you don't see the activation message received by the backend server ? |
|
Distance is 1 meter. Again, I don't have a spectrum analyzer right now, but I'm pretty sure that a packet is not generated at all, i.e. nothing goes through the radio. I can see the concentrator (iC880A), it's right in front of me, when a request (pkt) is received, it hard to miss it, as the LEDs go through most colors of the rainbow :). I'm also looking at the output of lora_pkt_fwd, so, nothing there either. This is even before a message goes to the join server, so I don't think the LoraWAN backend is the issue. I will test tonight with arduino/bluepill+modtronix+lmic, just so I'm sure everything works correctly. That setup has worked flawlessly for me so far, while this is my first time tackling semtech's loramac implementation. |
|
Just applied PR #8798. No difference at all. I'll go through everything again and will switch to the bluepill, to see if I will be able to make that work. |
|
I have no more idea. Hopefully, I have a nucleo-f446 and a modtronix sx1276 radio but I never used them in such a configuration. I'll test them in a week or two (I don't have the time before). |
|
Unfortunately I don't have any STM32Ls to test with. I know that the example implementation relies on STM32Ls. I'm starting to wonder if I can probably attempt a test with mbed, just so I'm sure everything works properly on the hardware side. |
|
@ilf-S unfortunately I don't have the hardware to test :/ |
|
I can do that. I have ~10 Modtronix transceivers, so that wouldn't be a problem. The sniffer is a good idea, I'm still doubtful that any package is actually generated at all, but I'll check with the sniffer. I think the problem is somewhere in between the MAC and PHY, but I can't pinpoint it exactly. |
|
@ilf-S can you give it a try? I think that could help to detect where is the problem. Also, you can try stuff like reading with an oscilloscope SPI pins (or turning on SPI debug). |
|
OK, tested with the sniffer setup. Crickets. I am working from home (which is not even my home, but different topic :) ), i.e. I have a limited access to certain equipment, so no oscilloscope at hand. I will now recheck again all connections and configuration, especially the DIO pins, as obviously the SPI is setup properly, as I'm able to send raw lora packets. On the top of my head I don't remember which DIO was responsible for what, but I think DIOs from 0 to 2 are responsible for lora and 3 to 5 for FSK, so I'll just make sure everything is connected and configured properly. I will try different hardware setups once I have the hardware and will report back. |
|
Just to be sure, have you updated the sx127x_params.h file in drivers/sx127x/include with your pins configuration ? |
|
Yes. Depending on the board I'm using I'm either using SPI(0) - nucleo, or SPI(1) on bluepill. My nucleo setup is a bit different than the default, but it's very close. I'm currently testing with SX127x communication and I'm able to send payloads on different channels with different SF and DRs. This is obviously some problem with the loramac-node package. I'm currently exhausting all available options to sniff on different channels and SF. Silence everywhere. This is either something that is specific to the STM32F1/F4s or it is some bug somewhere else that I'm not able to pinpoint. @aabadie are you using the latest code from RIOT in you setup? I'm currently on the latest commit with your PR cherry-pick-ed. |
in general, yes. So to summarize, you can send and receive packets when using the driver test application, so this means the driver is correctly configured and works with your setup. |
|
Yes, more or less. Nothing goes to the LoraWAN backend, because the gateway never receives a packet, so nothing is forwarded to the join server. SX127x communication works quite well actually, I'm a bit astonished, because it has never been reliable for me in a P2P scenario.
I will do that now and will report back. |
|
@dylad This did the trick. The sniffer reports packets, the node is activated, traffic goes through. I'm very happy. This is on the Nucleo-F446+Modtronix. I will test with the bluepill too, but I think it will work. Would you mind explaining this variable and why it helped? I think this can be closed, at least on my end. Here is the output from the sniffer (I can also post output from the lora_pkt_fwd if it's needed or helpfull). |
Awesome ! But please note that this change is NOT a patch. It can only be used with your Modtronix InAir9b module (This issue is not CPU related) So let's explain what's going on ! SX1276 chip has several pins dedicated to RF TX In addition, user has to select between PA_BOOST and RFO_HF for example (There is a dedicated register in SX1276 for that). So in your case, you are using Modtronix InAir9b module. Looking at the schematic of this module, RFO_HF is NOT connected but PA_BOOST is connected. When we started to work on SX1276 driver for RIOT (even before implementing LoRaMac) I think I've said something about PA_BOOST selection but since almost all (maybe all at this time) SX127X module used only RFO_HF pin. We decided to copy the behavior of PA_BOOST pin selection from Semtech original code. So in the current RIOT state, PA_BOOST cannot be used for 866MHz because we borrow this from Semtech sometimes ago. Now, looking more in details in Semtech code, things have changed, there are new SX1276 modules and some of them used this PA_BOOST pin. As I understand from Semtech code, the PA_BOOST selection is now done differently depending on the module you are using. (Which is not the case of RIOT). Why does the radio driver was working between your nodes and not with the gateway ? Thanks for sharing your issue with us, now that we know this. We'll need to find a better way to manage the PA_BOOST selection within RIOT ! I hope my explanations were clear enough :) |
|
Thanks @dylad for the detailed explanations. I looked at the upstream code (version 4.4.1) and the use of PA_BOOST or PA_RFO is related to the radio used apparently (including region of use 868/915MHz, etc). Thinking of it, the solution would be to add a specific parameter in the driver ( |
|
@aabadie I think this is the best option. We must let the users override this parameter if they want to force it. |
|
@dylad Thank you for your detailed explanation. Indeed both transceivers+MCUs were essentially hanging from the front USBs of my workstation and were very near each other (one was without antenna attached, actually). The gateway was on the other side of the desk (which is about 1.5m away). I was actually examining the schematics of the mbed lora modules and saw that they have their low and high freq pins connected for the antenna and freq diversity. I'm actually planning on custom hardware with SX127x (or even sx126x if Semtech send me samples), but I never actually examined closely the schematics of the InAir9b (which was stupid on my side). Just a sidenote to anyone who might find this issue if they have a similar problem: PA_BOOST actually does not conform to EU ISM 868 rules, and in a normal EU country, if you use such a module, you might get slapped with a fine! @aabadie a parameter seems like a logical solution to me, especially if using badly designed modules (I actually like the Modtronix modules, but the +20dB version should have been designed with both RFO_HF and PA_BOOST connected) |
You're welcome, I ran into the very same issue months ago :)
This might be the reason why there are very few module using PA_BOOST at 868 MHz. But you can still use PA_BOOST output at 14 dB (just like the RFO_HF pin). I guess you can emit at 20 dB on the 433 MHz band but the 868 MHz must have more restrictions. |
|
Hi, I know this is closed, I just want to ask @ilf-S: you said you tested LoRa (not LoRaWAN) communication between 2 devices. Is there any instruction or code that you can share on how to do that? Thank you. |
Hi @geonnave You could use |
|
Thanks @jia200x, I will check it. |
Description
Seems like LoraMAC-node package is not working.
I'm trying to join Nucleo-F446 + Modtronix InAir9b (SX1276 w/ PA_BOOST enabled i.e. +20dB) to a LoRaWAN network.
Similar setup but with bluepill + Modtronix InAir9b does not work either.
This has been done with the pkg_semtech-loramac in tests/.
Extra info:
I did a simple Lora (not LoraWAN) test between the nucleo and the bluepill with the driver_sx127x. One in listen, the other in transmit mode. Payload goes between the transceivers, so it doesn't seem to be a hardware problem.
Usually when an OTAA is attempted a package is send over the air. I don't have my spectrum analyzer with me, but I'm mostly sure that no package is send when either OTAA or TX is attempted, as the gateway usually reacts and I can see both debug on the console and even simple visual ack from the LEDs on the gateway. Nothing like that, so I'm almost certain that no packet is generated at all. I took a look at the code, but I get lost in it and couldn't find out what would be the reason for MAC timer timeout.
Also LoraMAC-node is already on version 4.4.1 but I don't feel like trying to switch to that version on my own.
Steps to reproduce the issue
Connect a bluepill or a Nucleo with SX1276 and attempt to do either an OTAA join, or TX with APB.
Expected results
OTAA Join request send, reply by the LoraWAN gateway, and eventually join in the network
Actual results
loramac set deveui my deveui
loramac set appkey my appkey
loramac set appeui my appeui (by the way this is not required per se, as this should be done by the server for various reasons, it is used only by TTN. In the network here any appeui can be set or just 16 zeros can be used) <- this has no relation to the problem
loramac join otaa
follows the short join request, not all frequencies
Versions
Latest RIOT from master.
Host: Fedora 28 (x86_64)
gcc:
arm-none-eabi-gcc-cs-7.1.0-5.fc27.x86_64
arm-none-eabi-gcc-cs-c++-7.1.0-5.fc27.x86_64
The text was updated successfully, but these errors were encountered: