EV_Join_Failed, but still seen in TTN console, no payload data

I’m using a Dragino Lora Shield on an Arduino Uno with the LMIC library and OTAA.

I’m using the OTAA example, which sends “Hello world!” once connected, but in TTN Console I never get to the point of seeing packets with a payload. Rather, what I see is that the device was spotted x minutes ago, and the signal details. The output in the serial monitor in the Arduino IDE simply states “EV_JOIN_FAILED” at each timestamp interval, and nothing else.

Until I set the below details I couldn’t even get the device to be seen on network, though I must admit I’m not sure if the lsb/msb is correct. It does seem that a few other people have noticed the lsb format being needed, and it’s what finally got my device to be seen, even if I can’t join.

APPEUI: lsb
DEVEUI: lsb
APPKEY: msb

The gateway(s) I’m connecting to are run by other people within a few km of home.

Any suggestions?

Your EUIs/key matches the documentation for the library and if your device’s join request is reaching the device page, that’s good.

This suggests that your device isn’t hearing the join response - can you get outside/higher up/closer so that the gateways have a clearer signal path.

Or try ABP in the first instance - for which it would be useful whilst in development mode to relax the frame counter checks.

Debugging your own devices is made so much easier with a gateway you can see the logs on as well as see the TTN console for. It may be a good investment in saving you time to consider getting one.

Thanks Nick, I’ll try that.

Hmmm.

Parked across the road from the gateway and left my device on whilst in the gym for an hour. The gateway was perhaps 50-60m away. Still the same results. TTN shows “Device last seen”, and picks up what I assume is the first join packet (SF10BW125, etc), but nothing else.

Pretty frustrating.

I have to wonder - is it worth picking up a different dev module and trying that instead. I’ve found the Dragino pretty tough to get going in all honesty.

On the topic of gateways - they’re reasonably expensive for something that’s not a single channel bit of rubbish. I’m holding off on any such purchase until I can reliably get a device talking to the network and wrap in some sensor data. I’m still stuck with “Hello World”, so that might be a while away. Hah.

So, wistched to the latest MCCI library, set my local band plan, changed over to ABP (msb) format, and am not being seen by the local gateways at all.

Is it possible for a gateway to not accept ABP connections?

Debug output from serial monitor:
> Packet queued

Sending packet on frequency: 916800000
19545285: EV_TXCOMPLETE (includes waiting for RX windows)
23295768: EV_TXSTART
Packet queued
Sending packet on frequency: 917600000
23426481: EV_TXCOMPLETE (includes waiting for RX windows)
27176962: EV_TXSTART
Packet queued
Sending packet on frequency: 917400000
27307674: EV_TXCOMPLETE (includes waiting for RX windows)

And one last update:

I’d like to thank whomever decided that there should be two frequency bands in Australia. I’d like to hand a second shout out to whomever decided that gateways on the TTN map could forego a frequency band indicator.

Anyway - ABP is working.

It might well be, however in that case find hardware that does not require LMIC as that (in combination with Atmel controllers with limited flash and ram) is where 95% of people experience issues. The issues are not limited to the Dragino shield.

That usually means your hardware doesn’t receive the downlink. A well known and very often occurring issue with LMIC on small controllers.

No it isn’t. Gateways are just dumb radio to IP (and v.v.) converters that don’t add any intelligence 99% of the time. There are a few exceptions but your are unlikely to run into them while using TTN. (Those gateways will be deployed for private networks)

Glad to see you got ABP working. Keep in mind the frame counters will be reset on the node after a reset of the controller. If you don’t reset the counters on TTN as well packets will be ignored until the counter exceeds the highest value used last time. (A security feature to prevent replay attacks which is a pain while developing your nodes software, that is why TTN added a switch to ‘ignore frame counters’ which you should only use while developing not for deploying nodes)

Thanks for your reply.

This controller really is a struggle. Have you any recommendations on an alternative that’s worthwhile? I’ve been looking, there’s quite a few options.

Basic requirements:

  • Be able to accept input from a few sensors. At least one sensor is known to be analogue.
  • Screw type antenna connector for ease of use.

To be able to offer sensible suggestions some additional information is required.

What programming language/environment do you want to use?
Any (low) power requirements?
Have you considered not messing with the antenna at all but using a module where you just connect a sensor?
What region(s) need to be supported?

I’m open to the programming environment. I’m terrible with C/C++, but reasonably good with Python. Most boards seem to be best on C, except perhaps the PyCom boards. The IDE I’m reasonably agnostic to. Currently using Arduino IDE.

Low power is a consideration. My prototyping project is trying to come up with something I can place in the bush/forest. Solar may be limited.

Have you considered not messing with the antenna at all but using a module where you just connect a sensor? No. Not sure what you mean?

AU915/AU926

Python is only available on the Pycom modules, rather pricy and hard to get working right with low power consumption. Avoiding C/C++ is hard. There are modules with SmartBasic, however they require a break out board and use u.Fl for the antenna connection.

For the Arduino environment with C/C++ you can consider the Heltec CubeCell modules. Specified power usage is excellent.
You could also consider the CubeCell Capsules, the modules with integrated antenna. However these have very limited power with the provided battery so a decent amount of light for the solar panel will be required.

When deploying in a forest, keep in mind trees in leave are excellent RF shields, I’ve seen them reduce LoRaWAN range by a factor 10.

Good advice, thank you. I hadn’t run across the CubeCells before, so I’ll check them out.

The current thinking is that any comms will need to be elevated to canopy level. That would help with the solar. Its all a bit of an experiment at this point.

This works on Arduino / Hope LoRa radio which is what the Dragino shield gives you:

You have to step back in time with your Arduino IDE & the version of the stack. This is because the current versions are too big for an ATMega328P’s flash or RAM or both. And older versions of the stack won’t compile with the new avr-gcc.

There is a gotcha as I’ve just discovered, the right combo appears to work on Windows but the device remains silent. It continues to work beautifully on macOS. I’ve literally working on why Windows doesn’t want to work right now.

I wouldn’t entirely agree with the “only” though it may be the only well known works-out-of-the-box implementing most of LoRaWAN.

To be specific it’s micro python. And it’s part of their customized micropython fork repo, so likely portable to other micropython platforms.

A number of Adafruit’s boards run circuit python which is a similar scheme of related lineage. Pretty sure one of their staffers was doing some LoRaWAN work with that a year ago, but not sure how far he got.

(Oops, on further examination it seems that Adafruit TinyLoRa has still not begun adding any code that attempts to receive, which makes this a bit too limited for real use. Worse, their FAQ seems to imply that the node behavior depends on proximity to a gateway: “If you’re hitting an error, RuntimeError: Timeout during packet send , it’s likely a gateway is not in range, or connected properly. Ensure that there are gateways near you and in-range” - which is to say that the FAQ is written by someone who doesn’t really understand what the code is and isn’t doing. More likely, that error is that the packet transmit complete DIO is never changing or being detected…)

Anyway, ARM Cortex parts with a moderate amount of RAM, or ESP8266 / ESP32 boards, the first two accessorized with an SPI flash they wouldn’t otherwise need, should be able to run one of these compact python things with whoever’s code is furthest along (though for LoRaWAN eeprom or MRAM would be more useful than the SPI flash needed to store the compact python program code)

That I’m not going to disagree with.

Actually low power is almost always “hard”

I will say that even though it’s a bit inelegant at manipulating long binary bit vectors in some ways an encrypted radio system ultimately needs, python has on the whole been great for the network infrastructure, data handling and node test harness sides of things.

To pick nits, it was the only known working implementation I could find when I spent 4 hours looking for an option a few months ago. I found multiple repositories of people working on something but all stated work in progress, certainly not something LoRaWAN compliant, and there was not much recent activity at the time.

Some years ago I wrote some python code to drive the RN2483 module that could possibly be used with micropython but I never tried and can recall adding low power functions (sleep and wake) as the module was connected to a full PC so there was no need to save a few microwatts while burning 300W at the other end of the USB cable (with USB-serial module) connecting the two.
Using an circuit python ot micro python board with low power mode driving a RN2483/RN2903 board might well be the way forward for programmers addicted to python. I just as happily use C for my nodes :wink: (or SmartBasic)