it continues like that or it stops after 3 times ?
- I see that you’re node and TTIG are very close… probably to close
- you have other gw’s nearby ?
- did you reset framecounters
Thanks for your response:
I see that you’re node and TTIG are very close… probably too close
I didn’t know that too close could be a problem. I’m accustomed to WiFi where I’ve never encountered that issue, so it didn’t occur to me. How does that impact the LoRaWAN communication?
you have other gw’s nearby ?
According to the TTN map, the closest TTN gateway is 14 km away. I don’t know about other LoRaWAN gateways nearby but I don’t think it’s likely. I’ve been watching the 915 Mhz uplink frequencies with an amateur radio receiver and haven’t seen much in my area.
did you reset framecounters
No. I read a little about that but didn’t really understand what problem it solved, and I wasn’t sure if I should be resetting my device at the same time that I reset the frame counters in TTN.
I forgot to answer your first question:
it continues like that or it stops after 3 times ?
It continues until I remove the power.
I’ve move the gateway as far away as I can without losing its WiFi connection. I also tried resetting the framecounters but didn’t see any affect. If I look at my Gateway in TTN it looks like it is sending the Join Accept on different frequencies with different spreading factors (screenshot below). Does my LMiC-based RFM95 need any configuration to be listening at those frequencies? I’m also wondering about the receive window. Does my device need some configuration to make sure it’s listening when the gateway is transmitting to it?
If I’m asking a lot of newbie questions I could answer myself by reading I’d be happy to go learn some more, if you can direct me to the right material.
For OTAA resetting frame counters is not required.
Sending with the devices in close vicinity might cause crosstalk between channels resulting in downlinks at the wrong frequency because TTN instructs the gateway to respond at a frequency based upon the uplink frequency, if that is the wrong one your node won’t receive any answer as it is listening on the wrong frequency.
Can you use something like SDR to check if the gateway is actually sending any data when a join response is generated by the back-end?
Ah, that’s out of your arduino’s node range, I was thinking can your node join through another GW and what happends then.
- What’s the power source of your node
Good idea about the SDR. I just used my RTL-SDR dongle to capture what looks like the gateway transmitting a Join Accept in response to the Join Request from my device. It’s a short burst 500 kHz wide at 923.9 MHz, just as TTN says. Screenshot below:
My power source is the USB-Serial adapter I use to program the Arduino Pro Mini. It normally sits at 3.4V but I just put it on an oscilloscope and can see that it occasionally drops to about 3.1V for a short time. The screenshot below shows one of those drops that lasted for 350ms.
I caught another Join Accept radio transmission. This one was on 923.3 and lasted longer then the last one. I presume that’s because this one used SF10 and the previous one used SF7.
1 Like
Looks like the gateway works. That means the issue is probably in the node, but there is one thing to check first. Take a look at the regional parameters for your location to check if the frequency and spreading factor used for the response match the specification. (They should, but it is better to make sure.)
If the otaa response matches the regional parameters you need to check the node firmware. Best is to start with a basic example configured for your region if you can find one.
BTW, for LMIC on Arduino you might need to relax the timing. Search the forum for the magic on how to do that 
BoRRoZ, I’ve changed power supplies and now the voltage drop (while transmitting?) isn’t as noticeable. Screenshot below. Unfortunately, the behavior hasn’t changed.
1 Like
Jac,
Thanks for the suggestions. I’ve looked at the regional parameters and TTN frequencies for my location (Austin, Texas) and I don’t see any discrepancies. I’ve included a capture of a radio transmission from my device on 904.1 MHz with SF=10. I’m using the basic ttn-otaa example that came with the arduino-lmic library and have only made the minimum required changes. I’ll go investigate the relaxed timing for Arduino.
Sounds like a DIO pins issue to me, triple check DIO0 and DIO1 are correct, also disconnect DIO2 as its not needed and I have seen issues before with it connected.
+1, considering also the platform.
Relaxing the timing fixed the problem! I don’t understand why yet but I’m very happy to see it start working. I’ll go read some posts about that timing. Thanks to everyone who answered and made suggestions.
1 Like
Well, relaxing the timing hasn’t turned out as well as I’d hoped. At first it allowed my device to join pretty quickly but in subsequent tests sometimes it joins and sometimes it doesn’t. Also, after joining it doesn’t seem to send my data consistently. Some uplink transmissions just don’t seem to succeed.
As I’ve been reading more about the timing considerations and reading more about other people’s struggles with the Arduino with 8 Mhz 328p processor I’m starting to wonder if I’m just trying to use the wrong platform. Any opinions? Can the Arduino Pro Mini + HopeRF RFM95 be made to work reliably with TTN? If not I’d like to know now so that I have time to make a better choice.
I think there are a lot of successful experience with this combination or equally light-power ones. Loss of some packets is something that some TTIG owners experienced (me too, having other gateways around I can tell when this happens), so do not blame the node only.
Thanks, that’s very helpful. I wanted to make sure I hadn’t made a platform choice that was going to make it more difficult than necessary. I’m excited about LoRaWAN, but after 2 days of trying to get a basic example program to work I was having doubts. I feel better knowing that there are helpful and experienced people on this forum who can help me if I need it.
After reading the Timing section of the README.md file that comes with the MCCI_LoRaWAN_LMIC_library, I moved DI0 and DI1 to interrupt-enabled Arduino pins 2 and 3 and enabled the use of interrupts in lmic_project_config.h:
#define LMIC_USE_INTERRUPTS
I also set the ‘clock relaxation’ value to 20% right after calling LMIC_reset():
// Reset the MAC state. Session and pending data transfers will be discarded._
LMIC_reset();
// Cause the RX windows to open earlier to accomodate issues caused by the
// Arduino Mini's relatively slow (8 MHz) clock
LMIC_setClockError(MAX_CLOCK_ERROR * 20 / 100);
My device’s uplinks are working much more consistently now. I’ve integrated my TTN Application with IFTTT’s Notification service so that I’ll have a record of any missing data uploads. The 20% clock relaxation may be more than I need, and causing additional airtime and battery use, so I’ll try lowering that value after I feel confident that the radio side of things is working consistently.
Again, thanks to everyone who’s helped me get this far.
1 Like