Got Adafruit Feather 32u4 LoRa Radio to work and here is how

End Devices (Nodes)
62

Super! Now everything is working properly :smiley:

Thanks for you help! @wklenk

All the best,
Maria C.

63

Next stop: https://www.thethingsnetwork.org/docs/devices/bytes.html to see how to avoid sending text. :wink:

64

Hey @arjanvanb, thanks so much for the link! Iā€™m already send the paramateres in bytes :smiley:

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

  • Gateway Traffic:
    image

If any of you guys knows why this behavior is presented, or can recommend another way to do it, I will appreciate any feedback!

All the best,
Maria C.

65

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:

    case EV_JOINED:
    Serial.println(F("EV_JOINED"));
66

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! :smiley:

All the best,
Maria C.

67

Hey @arjanvanb,

  • 3 minutes test (SEND_INTERVAL=180):

image

Working okay!

  • 5 minutes test (SEND_INTERVAL=300):
    image

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

image

Now during this test, the node is working okayā€¦ Iā€™m not pretty sure why this behavior is presented! :sweat:

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.

68

Sorry, no solution for your problems, but:

  • 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ā€¦

69

Rightā€¦need a little direction/help please in regard to changing spread factor, bandwith and other factors associated with this type of board (and the BSFrance 32u4II). To be honest Iā€™m a complete begginer in Arduino and Lora so bear with me! Iā€™m experimenting with building a GPS tracker for when out and about running/hiking, it only needs to report very basic map coordinates to allow viewing on something like Cayenne (every 30 min?). Iā€™m following Kerlings Lora Tracker workshop and can probably work around the power/package allowancesā€¦itā€™s just to experiment with the SF, bandwidth etc etc. How do I change these? Are they in the ibm lmic libraries, other files? Iā€™ve searched everwhere and canā€™t see where precisely I can alter these values. Thanks in advance

70

SF can be changed with

LMIC_setDrTxpow(DR_SFXX,14);

I do not you may ā€œchangeā€ bandwidth but you may setup channels with specific bandwidths. Something I would not mess with, honestly.

LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI);

All these things are not specific of this board but of LMIC, so just look at its documentation for details.

Regarding Kerling workshop, if you are fine with mid-level power consumption and you are using u-Blox chips, you may have save power just by software.

71

Thanks, Iā€™ve managed to get the Semtech datasheet for values as well, but thanks for the direction to head in.