Thank you! But it looks like nothing can be done (easily)…
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.)
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
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.
1 Like
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.hfile:
// 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! 
Thanks,
Maria C.
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
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?
Thanks,
Maria C.
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.
Next stop: https://www.thethingsnetwork.org/docs/devices/bytes.html to see how to avoid sending text.
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!
All the best,
Maria C.
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"));
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! 
All the best,
Maria C.
Hey @arjanvanb,
- 3 minutes test (SEND_INTERVAL=180):
Working okay!
- 5 minutes test (SEND_INTERVAL=300):
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.
Sorry, no solution for your problems, but:
-
Your first screenshot shows one
EV_JOIN_FAILEDin 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 theEV_JOINEDrefers 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…
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
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.
Thanks, I’ve managed to get the Semtech datasheet for values as well, but thanks for the direction to head in.