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

End Devices (Nodes)
47

Thanks. I had not, but adding it fixed the issues for both the LoRa32U4 and the Pro Mini setups. :+1:

1 Like
48

WARNING

When buying pre-wired JST-PH connector plugs for the LoRa 32U4 battery connector:

Be aware that polarity may not be what you expect.

DON’T BE FOOLED BY THE WIRE COLORS.

When looking at the red and black wires coming out of the connector one can easily assume that red is +3.7V and black is ground and then wire the battery correspondingly (at least I did).
But how the connector is wired may not correspond to how the board is wired. The red and black wires may be reversed on the connector.

If that is the case connecting the battery/connector will toast the LoRa 32U4 board.
When noticing the smoke (and smell) I quickly disconnected the battery, but it was already too late.
The battery controller chip was toasted. The LoRa 32U4 is still working but the power led does not light and the battery controller is damaged (will have to replace it).

So be careful with pre-wired battery connectors, they can toast your board unsuspectingly.
Check first if the connector wiring matches the board before trusting the wire colors.

I used these: JST-PH connectors with wires from AliExpress.
They have red and black wires reversed for LoRa 32U4.
It is not difficult to switch the wires on the connector but better do it before, not after.

2 Likes
49

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?

G

50

https://www.google.de/maps/dir/49.415783,8.7598985/In+der+Aue+20,+69118+Heidelberg/@49.4142399,8.7599525,17z/data=!3m1!4b1!4m8!4m7!1m0!1m5!1m1!1s0x4797c1d88a12d833:0x8bb7f33bf0819a5!2m2!1d8.76404!2d49.41265?hl=de - on this stretch of 500m with no clear line of sight from the gateway at the top of my house to the node with a 8.2cm wire antenna (bent twice) I did get data from the device in average 2 times out of 3 over a 4 day period every 3 minutes. I used the default settings from the apb example ino file. it sometimes did take 20 minutes for the first one to come through (I assume this is where ADR and other channel hoping magic happens between the node and the gateway) but then it was quiet reliable. I’m sure with line of sight I could go much further.

51

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” ?

52

Did you see Adafruit Feather 32u4 LoRa - long transmission time after deep sleep?

53

Thank you! But it looks like nothing can be done (easily)…

54

I’ve not used it, but one of the posts in the topic I linked above claims:

(Emphasis mine. Please post any discussion about that piece of code to that linked topic, not here. I will delete this reply later on.)

55

FYI: The LiPo/Li-ion Battery Charge Management Controller chip on the SBFrance LoRa32U4 is the following type: MCP73831T-2ACI (available here).

I blew it up by accidentally reversing the battery pins. It now works fine again after replacing the chip.

1 Like
56

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… :roll_eyes:

57

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 :wink:
I’m not saying that is your issue but just want to point out that a node not joining might have several causes.

1 Like
58

Hello everyone!

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

Thanks,
Maria C.

59

Hello,

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 …

1 Like
60

Hey @wklenk,

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?

image

Thanks,
Maria C.

61

That’s easy. Check line 180

LMIC_setTxData2(1, mydata, 1, 0);

The third parameter specified the number of bytes to send. In this case, it is set to a fixed value of 1 byte. Change it to

LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);

If you wonder why 1 is subtracted: It is because of the \0 that is added to strings in C.

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.