I did not change to serial1 yet but I did take out all references to serial. No effect…
I have a rather short connection from DIO1 to D6. Could crosstalk from the RF-signal be a problem?
Victory!!!
Out of frustration, I bought an M0, and I got it running within a minute! So there is definitely a problem with this software running on the 32u4 architecture. It’s not the serial interface, because I took all of that out already and it gives the same issue.
After a lot of debugging and trial and error (and some expletives), I finally got it working on a Feather 32u4 as well:
-
According to the schematics of the Feather 32u4, DIO0 is connected to digital pin 7. For the M0 version, DIO0 is connected to digital pin 3. So in the initialization for the Feather 32u4, I used .dio = {7,6,LMIC_UNUSED_PIN}. I have connected IO1 to digital pin 6 with a wire bridge.
-
My first statement in void setup() is delay(1000). Without this delay, I get the same results as @iot-partners
I got my 32U4 to work as well with this tip!!!
Who would have thought it to be an initialization problem!
Thank’s a lot for this short, but very usefull post !
I’m trying to OTAA a Adafruit 32u4 Feather.
I seem to have the correct pinout with help from this thread:
I’m running into a consistent “EV_JOIN_FAIL” when using OTAA.
When I try and do ABP it prints "EV_TXCOMPLETE (includes waiting for RX Windows)…and then packet queued.
Any suggestions on how to troubleshoot this? Is it likely a problem with the keys?
Thanks!
I also have a Adafruit Feather 32u4 LoRa Radio up and running based on the “IBM LMIC framework” library included via the Arduino IDE. It seems this originates from Matthijs Kooijman’s work for Arduino platforms.
// Pin map for Adafruit Feather 32u4 LoRa
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {7, 6, LMIC_UNUSED_PIN},
};
I have connected IO1 to digital pin 6 with a wire bridge.
I modified the code to join TTN using OTAA.
But now I experience a strange behaviour:
- The node sends join requests, and every single join request arrives at TTN, as I can see the “Activation” messages in TTN console
- However, the node does not receive any response from TTN. As it does not receive responses, it just keeps trying to send join requests.
- Both join receive windows (5s and 5+1s) are missed
- Only the sixth or seventh join request is successful: The node receives the response from TTN.
- I am using a Kerlink LoRa IoT Station as gateway which is located in a room next to me
- Tries in the order of appearance: SF7@867,5 - SF7@868,1 - SF8@868,3 - SF8@868,5 - SF9@867,1 - SF9@867,3 - SF10@867,5
The gateway is located in a room next to me - why does it obviously need SF10 in order to enable the node to actually receive the response from TTN? I would possibly understand if the gateway would be located far away from the node, but it isn’t.
Is this possibly an issue of the timing of the join receive windows in the nodes? It is hard to believe that the code provided by Matthijs Kooijman really works for each and every Arduino based hardware. Is there some place in the code where these receive windows need to be adjusted?
5539776: WK --- IRQ Handler 0 // Join message #1 sent
10548152: WK --- IRQ Handler 1 // Receive timeout in join receive window 1 (5s)
11754072: WK --- IRQ Handler 1 // Receive timeout in join receive window 2 (5+1s)
21323944: WK --- IRQ Handler 0 // Join message #2 sent
26332368: WK --- IRQ Handler 1
27538304: WK --- IRQ Handler 1
42022208: WK --- IRQ Handler 0 // Join message #3 sent
47037272: WK --- IRQ Handler 1
48236584: WK --- IRQ Handler 1
66233032: WK --- IRQ Handler 0 // Join message #4 sent
71248144: WK --- IRQ Handler 1
72447408: WK --- IRQ Handler 1
77584832: WK --- IRQ Handler 0 // Join message #5 sent
82613200: WK --- IRQ Handler 1
83799200: WK --- IRQ Handler 1
113588872: WK --- IRQ Handler 0 // Join message #6 sent
118617336: WK --- IRQ Handler 1
119803320: WK --- IRQ Handler 1
161840632: WK --- IRQ Handler 0 // Join message #7 sent
EV_JOINED
The LMIC code is quite portable.
The only issue I had was when using a less accurate clock.
You could try adding
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
Thank you, adding the following line actually made the “join” work with the first attempt. That’s great.
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
Again, this is my working pin map for Adafruit Feather 32u4 LoRa
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {7, 6, LMIC_UNUSED_PIN},
};
I have connected IO1 to digital pin 6 with a wire bridge.
I need to mention that I also fetched a new clone from https://github.com/matthijskooijman/arduino-lmic as the library I was working with was not up to date, didn’t have built in the MAX_CLOCK_ERROR code.
Strange code: LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
The compiler will optimize out (and therefore ignore) the “* 1” which leaves you with LMIC_setClockError(MAX_CLOCK_ERROR / 100);
Yeah, but it’s okay (if it’s in the right place; have not checked that). It’s just a way of the original author to easily see it’s 1% of the maximum; others may use, say, 10 / 100
to get 10%.
Note the while the compiler optimizes it out (now) if you change the number 1 to something else (3) it will not optimize it out and will save you coding later.
Also remember that you really have to put the "LMICsetClockError(MAX_CLOCK_ERROR * 1 / 100); code after the LMIC_Reset(); !!! Per this post;
https://www.thethingsnetwork.org/forum/t/ev-join-failed-with-adafruit-feather-32u4-and-lmic/7252/4
Example:
LMIC_Reset();
LMICsetClockError(MAX_CLOCK_ERROR * 1 / 100);
Mine worked first time after I did this. Strange though that I had 3 units. One worked without the clock error and 2 would not. Very frustrating.
I also adjusted clock error on my rocketscream board (m0) to improve RX window and it’s working fine with 1%.
What’s the deal increasing all to 3% for example ? Just curious, would heart the Lorawan implementation ? Since the deal is to receive downlink what’s the pb with longer receive window ? (Shift the RX2 may be?)
Another question, my m0 boards (all not only one) experiencing random reset very often, anyone is experiencing this with M0 ? Can be seen with new join request on TTN
I’m using the 32u4 Lora Feather and the 1% works for me.
How often is the reset? I have the v2 of the board running (it has larger decoupling capacitor for the radio, 4.7uF vs 47uF) and it runs smoothly without reset. Maybe that could be it?
@rocketscream
You meant 47uF instead of 4.7uF ?
I suspect it’s coming from debugging to SerialUSB and after a amount of time when USBSerial close this reset the board. When USB is connected to My PC it works, when on USB using a PowerBank or with Lipo it is reseting.
I’ll try to switch all LOG output (including LMIC ones) to Serial1 instead, but I need to connect a FTDI to see logs in this case and put all on a breadboard. I’ll give a try ASAP
I have things running on an M0 based Feather with the RFM69HCW but not very reliably. After a certain amount of time something ends up hanging.I have not been able to debug exactly what the issue is. My solution at the moment is to use the hardware watchdog to reset the unit and then it resumes working for a period of time.
Hi @kylelenk, I have the same EV_TXCOMPLETE ( includes waiting for RX Windows) problem with ABP (using adafruit 32u4). Did you get it to work?
Thanks!