Thanks for the heads-up @bluejedi, I have some of these wires sitting in our postal system somewhere!
Just a question for other LoRa 32U4II users…?
Range? Is it universally poor?
I have only set up one board which uses LMIC and OTAA. The antenna is one of the small (about 50mm SMA type) 868MHz jobs that ship with some of the AliExpress products. I am finding that the node only connects to my (RAK831) gateway when within say 300m and then with SF7 or occasionally SF8. I am sure I read that ADR doesn’t adjust SF if I am TTNMapping for example but even getting the node to connect with a SF that will work over a few hundred metres seems to be a trick?
I know I should try to eliminate possibly poor antenna and I guess the pig-tail also before I condemn the LoRa 32U4II but any consensus among us or hints to get a more robust connection for longer range?
Hello,
I am testing a piece of similar code and I can see extra 30 seconds of delay on top of my sleep cycle.
Is it related to my version of LMIC library: “1.5.0+arduino+2” ?
anyone else seeing that LMIC_setClockError-correction having no effect anymore lately?
my BSFrance-node just activated fine and nearly instantly for weeks, now it’s again taking a ~dozen or more tries till it’s getting activated - didn’t change anything…
Last week I had issues with joins as well, the backend was sending join replies minutes after the request. The window isn’t that large
I’m not saying that is your issue but just want to point out that a node not joining might have several causes.
I’m writing you guys because regrettably after reading different topics related to the Adafruit Feather 32u4 LoRa radio and making some tests, I’m no able to getting it work.
My goal is have multiples nodes ( Adafruit Feather 32u4 LoRa) sending data over LoRa to a Multitech Conduit Gateway. As I could read in the other topics, I need to build a LoRaWAN stack in the feather and regrettably it takes a huge part of the capacity of the board; this point was not enough clear to me, if someone can give me a little bit more context related to this or can suggest me another way to build the LoRa network using the devices mentioned I would really appreciate it!
From another hand, as first I tried to connect the Feather to TTN following the instructions provided in this repository@wklenk (thanks for sharing it with the community), but the board is not joining properly. The behavior presented in the built-in LED is one blink per second and after a while stop blinking, I’m not sure where can be the issue here. The following steps are the ones that I did:
Setup of the board in the Arduino IDE.
Download & Installation of the library required.
Wire pin connection - IO1 to 6.
Modification of the config.h file:
// Uncomment this to disable all code related to ping
#define DISABLE_PING
// Uncomment this to disable all code related to beacon tracking.
// Requires ping to be disabled too
#define DISABLE_BEACONS
Also, I modified the frequency zone to 915:
//#define CFG_eu868 1
#define CFG_us915 1
// This is the SX1272/SX1273 radio, which is also used on the HopeRF
// RFM92 boards.
//#define CFG_sx1272_radio 1
// This is the SX1276/SX1277/SX1278/SX1279 radio, which is also used on
// the HopeRF RFM95 boards.
#define CFG_sx1276_radio 1
Register a device in TTN.
Assign the Device EUI, App Key, APP EUI generated in the device previously created in TTN to the Arduino Script. The APP EUI and Device EUI are specified in “little endian format”.
Upload the code in the Feather
LED status = once per second, then stop.
I hope all of these points make the issue presented easy to find, I would appreciate any suggest!
I suggest you enable the Serial Monitor in the Arduino IDE at 115200 bps and let us know what the output is. If you do so, it is also a good idea to uncomment these lines in the mentioned sketch: But be aware: The sketch won’t continue if you don’t have the Serial Monitor window open.
/*
while (!Serial) {
// wait for serial port to connect. Needed for native USB
delay(100);
}
*/
If the LED blinks with a rate of 1 blink/second this makes me think everything works as expected and the application tries to join TTN, but after it has joined it should change to a blink rate of 5 blinks/second. But you tell us that it stops blinking? So possibly something weird is returned from the gateway with the “join” response that the LMIC stack cannot handle? Just a guess …
Thanks for the quickly response. I reviewed all the configurations in the TTN side, and I noted that had a wrong configuration in the gateway. Now the device is joining properly!
Other thing that I noted is that the the payload sent by you in the example is static uint8_t mydata[] = "\0", this is properly received in the TTN side. Then, I modified the payload to the message: hello! but I’m just able to received the first byte (see the image below). Do you have any idea about this behavior?
Hey @arjanvanb, thanks so much for the link! I’m already send the paramateres in bytes
After some tests with the basic example provided from @wklenk, I got everything works properly with a send interval equal to 60 (as it is in the example), a message per minute. At this point everything is okay, but if I increase the send interval to 600, in order to send a message every 10 minutes the parameters are not been sent properly. The device is joining properly (different times, see image below), but the message are not been received.
Device Data Traffic (screenshot taken at 12:10 pm):
Gateway Traffic:
If any of you guys knows why this behavior is presented, or can recommend another way to do it, I will appreciate any feedback!
Indeed TTN accepts the Join Request, but you cannot tell by the gateway traffic if the node actually received that. The fact that the device keeps trying to join, probably indicates it never received the Join Accept that the gateway has transmitted.
I wonder why TTN is sometimes sending the Join Accept at a different SF. It’s sending those after about 4 seconds, so I assume it’s intended to be transmitted in RX1 (which is 5 seconds for an OTAA join). Is this US US902-928? Then it seems a downlink is not documented for a 904.6 SF8 uplink; see https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928 Maybe the SF7 is correct then, but for the other frequencies the downlink uses the same SF as the uplink, which it does (like for 11:39:14 and 11:39:45).
So:
Does the device also re-join for every request, when using the 60 seconds interval?
If yes: it should not do that; instead it should keep the secrets, network settings and counters, and use those for months. It should only re-join when, e.g., it has lost power. But when it does the same when using the 60 seconds interval, then that’s probably not your current problem.
If no: maybe the device (or its power source) is falling asleep? Can you still see serial output in the Arduino IDE?
Can you add logging to the device to see if the Join Accept was actually received? Like do you see output for:
After I posted the last comment I noted this too, and I was taking a look of some topics but any luck yet! As you mentioned, this is US902-928. I note that it is just taking the different SF in the joining process, once the node is joined it only use SF7 for the uplink message as it should be!
No, it only re-join at first, after send the first message it does not join again. I check the behavior from the output in the Arduino IDE, but everything seems to be working okay. I’m receiving the following output every minute after the node is joined, and the message is received at TTN:
Packet queued
47602451: EV_TXCOMPLETE (includes waiting for RX windows)
This was the test with the 1 minute interval, now I’m going to make the test increasing the time.
I included the debug option in order to verify it, and I’m receiving the EV_JOINED correctly. After this message I’m start receiving the ones above packet queued ...
Now I’m going to try increasing the interval time, to check how everything goes. Thanks for your comments, I will back to you after the test!
In this case, the node is trying to join with the different SF, and the device is joined as is shown in the output, also is sending the packages but the messages are not been received. Do you have any idea?
10 minutes test (SEND_INTERVAL=600):
Now during this test, the node is working okay… I’m not pretty sure why this behavior is presented!
As I can noted with the tests is that when the join fails the Join Accept is sent in different SF, and for some reason (I don’t know why, sorry!) the messages are not been received.
Your first screenshot shows one EV_JOIN_FAILED in the device’s log, which is not accounted for in the screenshot of TTN Console. Did you see earlier join attempts before 14:41:25 then? If so, then I guess the EV_JOINED refers to the (re)try of 14:41:25, which sends the Join Request at 904.6 SF8 and then apparently successfully gets the Join Accept on 923.9 SF7. So, apparently that’s okay for the US frequency plan. (If you did not see an earlier Join Request, then maybe no gateway received it; I guess the successful one then still refers to what the screenshots show.)
The third screenshot shows downlinks in TTN Console, so I guess the uplinks are confirmed uplinks? (You should not send every uplink as a confirmed uplink.) Then the next uplink is not listed as a retry (I’m sure the frame counters will have increased as well.) So apparently the downlink for the ACK is received as well.
The third screenshot also shows that for a 904.6 SF8 uplink, the 15:15:28 downlink is using 923.3 SF12, but the 15:25:30 downlink uses 923.9 SF7? Maybe one is in RX1 and the other in RX2. But if not, then how would a node know at which frequency to listen?
I find https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928 hard to understand; maybe you should confirm that it is complete and correct (like: what is used for RX2?), and that the device is allowed to use 904.6 SF8 (like: what should be used for downlinks then?). Not my cup of tea, but see also hybrid mode for US 8 channel gateways.
And though downlinks work (for otherwise it would never join), maybe it does not always work? See LMIC_setClockError. But regardless downlinks: once the join succeeded (which needs downlinks too), uplinks should show of course, even without downlinks…
