LoraMAC-node does not work

[ilf-S]

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

2018-03-22 01:58:35,294 - INFO # reboot
2018-03-22 01:58:35,304 - INFO # �main(): This is RIOT! (Version: 2018.04-devel-727-g0f07b-ws2)
2018-03-22 01:58:35,307 - INFO # [semtech-loramac] initializing loramac
2018-03-22 01:58:35,312 - INFO # [semtech-loramac] initialize loramac for EU868 region
2018-03-22 01:58:35,316 - INFO # sx127x: peripherals initialized with success
2018-03-22 01:58:35,319 - INFO # SX1276 transceiver detected.
2018-03-22 01:58:35,321 - INFO # All up, running the shell now
> 2018-03-22 01:58:35,339 - INFO #  [DEBUG] Set channel: 868000000
2018-03-22 01:58:35,347 - INFO # [DEBUG] Set channel: 434000000
2018-03-22 01:58:35,350 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 01:58:35,352 - INFO # [DEBUG] set modem: 1
2018-03-22 01:58:35,354 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 01:58:35,357 - INFO # [DEBUG] Set op mode: RECEIVER
2018-03-22 01:58:35,392 - INFO # [DEBUG] Set sleep
2018-03-22 01:58:35,395 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 01:58:35,397 - INFO # [DEBUG] Change state: IDLE
2018-03-22 01:58:35,399 - INFO # [DEBUG] Set syncword: 34
2018-03-22 01:58:35,401 - INFO # [DEBUG] Set sleep
2018-03-22 01:58:35,403 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 01:58:35,406 - INFO # [DEBUG] Change state: IDLE
2018-03-22 01:58:35,410 - INFO # [semtech-loramac] EU868 region: use default channels
2018-03-22 01:58:35,413 - INFO # [semtech-loramac] set dr 0
2018-03-22 01:58:35,415 - INFO # [semtech-loramac] set adr 0
2018-03-22 01:58:35,419 - INFO # [semtech-loramac] set public network 1
2018-03-22 01:58:35,421 - INFO # [DEBUG] Set syncword: 34
2018-03-22 01:58:35,423 - INFO # [semtech-loramac] set class 0
2018-03-22 01:58:35,425 - INFO # [DEBUG] Set sleep
2018-03-22 01:58:35,427 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 01:58:35,430 - INFO # [DEBUG] Change state: IDLE

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

2018-03-22 02:10:02,892 - INFO # loramac join otaa
2018-03-22 02:10:02,895 - INFO # [semtech-loramac] loramac cmd
2018-03-22 02:10:02,898 - INFO # [semtech-loramac] starting OTAA join
2018-03-22 02:10:02,901 - INFO # [DEBUG] already using modem: 1
2018-03-22 02:10:02,904 - INFO # [DEBUG] Set op mode: RECEIVER
2018-03-22 02:10:02,939 - INFO # [DEBUG] Set sleep
2018-03-22 02:10:02,941 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 02:10:02,944 - INFO # [DEBUG] Change state: IDLE
2018-03-22 02:10:02,947 - INFO # [DEBUG] Set channel: 868500000
2018-03-22 02:10:02,950 - INFO # [DEBUG] already using modem: 1
2018-03-22 02:10:02,952 - INFO # [DEBUG] Set freq hop: 0
2018-03-22 02:10:02,954 - INFO # [DEBUG] Set bandwidth: 0
2018-03-22 02:10:02,957 - INFO # [DEBUG] Set coding rate: 1
2018-03-22 02:10:02,959 - INFO # [DEBUG] Set spreading factor: 7
2018-03-22 02:10:02,961 - INFO # [DEBUG] Set CRC: 1
2018-03-22 02:10:02,964 - INFO # [DEBUG] Set freq hop: 0
2018-03-22 02:10:02,966 - INFO # [DEBUG] Set Hop period: 0
2018-03-22 02:10:02,969 - INFO # [DEBUG] Set fixed header length: 0
2018-03-22 02:10:02,971 - INFO # [DEBUG] Set IQ invert: 0
2018-03-22 02:10:02,974 - INFO # [DEBUG] Set payload len: 0
2018-03-22 02:10:02,976 - INFO # [DEBUG] Set power: 13
2018-03-22 02:10:02,979 - INFO # [DEBUG] Set preamble length: 8
2018-03-22 02:10:02,981 - INFO # [DEBUG] Set RX single: 0
2018-03-22 02:10:02,984 - INFO # [DEBUG] Set TX timeout: 3000000
2018-03-22 02:10:02,987 - INFO # [DEBUG] Set max payload len: 23
2018-03-22 02:10:02,989 - INFO # [DEBUG] Set payload len: 23
2018-03-22 02:10:02,991 - INFO # [DEBUG] Set standby
2018-03-22 02:10:02,994 - INFO # [DEBUG] Set op mode: STANDBY
2018-03-22 02:10:02,997 - INFO # [DEBUG] Change state: IDLE
2018-03-22 02:10:03,000 - INFO # [DEBUG] Change state: TX
2018-03-22 02:10:03,003 - INFO # [DEBUG] Set op mode: TRANSMITTER
2018-03-22 02:10:03,067 - INFO # [DEBUG] Change state: IDLE
2018-03-22 02:10:03,069 - INFO # [DEBUG] Set sleep
2018-03-22 02:10:03,071 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 02:10:03,074 - INFO # [DEBUG] Change state: IDLE
2018-03-22 02:10:03,075 - INFO # [DEBUG] Set sleep
2018-03-22 02:10:03,078 - INFO # [DEBUG] Set op mode: SLEEP
2018-03-22 02:10:03,080 - INFO # [DEBUG] Change state: IDLE
2018-03-22 02:10:03,084 - INFO # [semtech-loramac] Transmission completed
2018-03-22 02:10:03,940 - INFO # [semtech-loramac] MAC timer timeout

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

[aabadie]

Thanks for testing RIOT with LoRaWAN. Let's try to find what's wrong with your setup. First, I'm using the loramac-node package daily for almost 3 months and trust me, it works very well.

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 ?

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.

I saw that and it's on my todo list, I just need to find the time to update the package.

[aabadie]

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.

[ilf-S]

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.

[ilf-S]

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.

[aabadie]

Disabling the SX127x debugging did not help either.

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).

What is your hardware setup

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 ?

[ilf-S]

Sure:

2018-03-22 15:41:54,625 - INFO # �main(): This is RIOT! (Version: 2018.04-devel-727-g0f07b-ws2)
2018-03-22 15:41:54,629 - INFO # [semtech-loramac] initializing loramac
2018-03-22 15:41:54,634 - INFO # [semtech-loramac] initialize loramac for EU868 region
2018-03-22 15:41:54,636 - INFO # All up, running the shell now
> 2018-03-22 15:41:54,696 - INFO #  [semtech-loramac] EU868 region: use default channels
2018-03-22 15:41:54,699 - INFO # [semtech-loramac] set dr 0
2018-03-22 15:41:54,701 - INFO # [semtech-loramac] set adr 0
2018-03-22 15:41:54,704 - INFO # [semtech-loramac] set public network 1
2018-03-22 15:41:54,707 - INFO # [semtech-loramac] set class 0

> loramac set deveui 1a60dc8162933738
2018-03-22 15:43:16,420 - INFO #  loramac set deveui 1a60dc8162933738
> loramac set appeui 70b3d54903310994
2018-03-22 15:43:35,196 - INFO #  loramac set appeui 70b3d54903310994
> loramac set appkey 313bfabd277dc12c29fd0ccdad92404f
2018-03-22 15:43:47,574 - INFO #  loramac set appkey 313bfabd277dc12c29fd0ccdad92404f
> 

and after loramac join otaa:

2018-03-22 15:44:17,400 - INFO #  loramac join otaa
2018-03-22 15:44:17,403 - INFO # [semtech-loramac] loramac cmd
2018-03-22 15:44:17,406 - INFO # [semtech-loramac] starting OTAA join
2018-03-22 15:44:17,510 - INFO # [semtech-loramac] Transmission completed
2018-03-22 15:44:18,395 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:19,348 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:20,301 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:21,254 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:22,208 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:22,448 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:22,556 - INFO # [semtech-loramac] RX timer timeout
2018-03-22 15:44:23,162 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:23,265 - INFO # [semtech-loramac] Transmission completed
2018-03-22 15:44:24,152 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:25,104 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:26,058 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:27,011 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:27,965 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:28,204 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:28,311 - INFO # [semtech-loramac] RX timer timeout
2018-03-22 15:44:28,917 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:29,022 - INFO # [semtech-loramac] Transmission completed
2018-03-22 15:44:29,908 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:30,862 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:31,815 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:32,769 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:33,722 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:33,959 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:34,067 - INFO # [semtech-loramac] RX timer timeout
2018-03-22 15:44:34,675 - INFO # [semtech-loramac] MAC timer timeout
2018-03-22 15:44:34,678 - INFO # [semtech-loramac] MLME confirm event
2018-03-22 15:44:34,681 - INFO # [semtech-loramac] join not successful
2018-03-22 15:44:34,683 - INFO # Join procedure failed!
> 2018-03-22 15:44:35,001 - INFO #  [semtech-loramac] MAC timer timeout
2018-03-22 15:44:35,607 - INFO # [semtech-loramac] RX timer timeout

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.

[aabadie]

I guess you don't see the activation message received by the backend server ? Because from the logs eveything looks normal. What is the distance between the device and the gateway ? Maybe it doesn't receive the messages.

[ilf-S]

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.

[ilf-S]

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.

[aabadie]

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).

[ilf-S]

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.

[jia200x]

@ilf-S unfortunately I don't have the hardware to test :/ In case you have another LoRa radio, can you try to sniff TX (ABP) or Join Request (OTA)? To do so, there's a dirty trick of setting the radio channel to a fixed value, and use another node to sniff that channel. With that, at least you can ensure the packet is going to the air. Let me know if it works.

[ilf-S]

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.

[jia200x]

@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).

[ilf-S]

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.

[aabadie]

Just to be sure, have you updated the sx127x_params.h file in drivers/sx127x/include with your pins configuration ? The default values are for nucleo-64 boards with an mbed shield.

[ilf-S]

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.

[aabadie]

are you using the latest code from RIOT in you setup?

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. When you start an OTAA join procedure, no activation message is received by the network server. right ? And the gateway never light up (in orange) briefly 5 seconds after starting the OTAA. You could put a debug statement in pkg/semtech-loramac/contrib/semtech_loramac_radio.c in SX127XSend function (at the beginning) to check if it's called.

[ilf-S]

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.

You could put a debug statement in pkg/semtech-loramac/contrib/semtech_loramac_radio.c in SX127XSend function (at the beginning) to check if it's called.

I will do that now and will report back.

[dylad]

@ilf-S Could you try to modify this variable to 925000000UL and tell us if it's change something for you please ?

[ilf-S]

@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).

> listen
2018-03-22 23:10:30,201 - INFO #  listen
2018-03-22 23:10:30,203 - INFO # [DEBUG] Set RX single: 0
2018-03-22 23:10:30,206 - INFO # [DEBUG] Set RX timeout: 0
2018-03-22 23:10:30,207 - INFO # [DEBUG] Set RX
2018-03-22 23:10:30,210 - INFO # [DEBUG] Change state: RX
2018-03-22 23:10:30,212 - INFO # [DEBUG] Set op mode: RECEIVER
2018-03-22 23:10:30,214 - INFO # Listen mode set
> 2018-03-22 23:10:35,328 - INFO #  {Payload: "" (23 bytes), RSSI: 225, SNR: 6, TOA: 67}
2018-03-22 23:10:53,400 - INFO # {Payload: "" (23 bytes), RSSI: 224, SNR: 6, TOA: 67}
2018-03-22 23:10:54,472 - INFO # {Payload: "" (23 bytes), RSSI: 224, SNR: 6, TOA: 67}
2018-03-22 23:14:48,982 - INFO # {Payload: "" (23 bytes), RSSI: 224, SNR: 6, TOA: 67}
2018-03-22 23:29:26,319 - INFO # {Payload: "" (23 bytes), RSSI: 224, SNR: 6, TOA: 67}

[dylad]

This did the trick. The sniffer reports packets, the node is activated, traffic goes through. I'm very happy.

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 RFO_LF (TX 433 MHz 14 dB max) RFO_HF (TX 868/915 MHz 14 dB max) PA_BOOST (TX dedicated for 20 dB output)

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 ? Probably, because your two nodes were on the same desk at very close distance (e.g < 30 cm) but your gateway was a little bit far away. Since you were trying to send your frame on an unconnected pin of the chip, you may send/receive data at a very very close distance but this could be harmful for the pin.

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 :)

[aabadie]

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 (SX127X_PARAM_PA_SELECT ?) parameters and adapt the sx127x_get_pa_select accordingly. Then it will be up to the user to set this parameter or it can be overridden in the board configuration if needed. What do you think ?

[dylad]

@aabadie I think this is the best option. We must let the users override this parameter if they want to force it. Also, a little note somewhere in a readme or within the documentation to warn users about such cases.

[ilf-S]

@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)

[dylad]

Thank you for your detailed explanation

You're welcome, I ran into the very same issue months ago :)

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!

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.

[geonnave]

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.

[jia200x]

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 tests/driver_sx127x as a reference. There you have a test application that can send/receive raw LoRa packets.

[geonnave]

Thanks @jia200x, I will check it.