Arduino nano and RFM95 basic test - EV_JOIN_TXCOMPLETE: no JoinAccept

Only if your goal is to permanently destroy the radio!

Driving I/O voltages above the supply rail is bad, but it’s not as bad as driving the supply rail out of spec, because at least the ATmega I/O’s have some source impedance. The source impedance, and the voltage drop and of the radio’s protection diodes would be why the mis-driven I/O’s are ending up loaded to a voltage intermediate between the radio’s 3.3 volts and the Arduino’s 5v. (In the reverse direction, a 3v3 output really is enough for a 5v ATmega, no issue there)

Given the report of successful peer to peer operation, it’s unlikely that the voltage issue is the immediate cause of difficulty, though it may well cause the radio to fail sooner or later. A quick re-check if the peer-to-peer is still working might be in order. Putting some 2.2k series resistors in the lines would help lessen the stress on the radio, though it’s not really a sufficient fix.

In terms of productive directions for the project, given that an ATmega328 is never going to be better than a squeeze for a LoRaWAN stack, switching to an ARM part that solves both the voltage issue and gives some elbow room is probably a better investment of effort than adding voltage translation. Or one could swap out the voltage regulator on the Nano for a 3v3 one and change the crystal for 8 MHz operation - but that’s a lot of work.

The other useful thing to do for productivity is to get one’s own gateway, as being able to see the raw uplink message attempts is very helpful for distinguishing between situations where the node transmitted with appropriate settings, but data that doesn’t correspond to a valid LoRaWAN uplink from its device settings, vs situations where the node didn’t transmit. And similarly in the downlink situation.

Additionally it should be noted that the 3v3 supply rail output of 5v Arduino’s may have very little current capacity, and may not be able to power a LoRa radio transmission and the amount of current required depends on the radio settings used, so it could even be different between the peer to peer and LMiC attempts. Depending on if you have a “real” or “fake” Arduino that 3v3 supply is probably coming from the on-chip regulator of the USB UART solution, which might be an FTDI or a CH340 or who knows what. That on-chip regulator really isn’t intended to supply anything more than the USB chip and a few supporting components.

Really it would be best to build an all-3v3 system around an ARM MCU, with a “real” 3v3 regulator. Alternately get a real 3v3 regulator for power and some proper voltage conversion for the I/O (dividers should work on the Arduino outputs, don’t really need anything on the inputs if careful to never misconfigure them). My gut suspicion is that your current failure to get packets through is actually something else, but the voltage issues do need to be corrected, too.

1 Like

I ordered 3.3V arduino pro mini. Waiting for delivery. I will test the same sketch with a new 3.3V board + the same module RFM95.

Any chance you can cancel that and get something more suitable with an ARM MCU?

You should be able to get the 3v3 pro mini to work if you used a very stripped down codebase, but it’s not a good solution and lack of resources will always be there as a limitation hanging over your efforts and limiting your posssibilities.

Your existing Trinket M0 would probably work; it seems to have comparable flash and RAM resources to the often used Feather M0. It is a different chip, so may require a different BSP, but if you rig up the RFM95 to a breadboardable configuration I’d say it would be worth trying MCCI LMiC as if you had a feather M0, but use the Adafruit Trinket M0 “board” as your target in the Arduino IDE. Any issues are likely then to fall to correctly configuring the pins used for the DIO signals.

1 Like

As the price for the board is less than the price for a beer, I will let it come. Even if my test will fail, this cheap board will be used for another tests.

I asked on Adafruit forum if Trinket M0 can work with RFM95 - silence.
I looked at Trinket M0 pinout and I don’t see NSS pin. I’m blocked here.

On the other hand, many other people get a very good working solution out of a small scale entry level device that they are just starting out with. You don’t buy a race car to learn to drive in.

You’d don’t buy a midget clown car, either.

And for purposes of LoRaWAN, that’s exactly what an ATmega328 is - possible to use with care but always going to be limiting.

Something like a feather M0 is your typical “compact sedan”

Making the Trinket M0 work would require developing some understanding of SPI.

NSS is the chip select for an SPI target; it can be a dedicated pin, or it can be an arbitrary digital pin manipulated by software.

You’d need to start by learning how SPI is supported in the Trinket M0 Arduino setup.

I would like to have feather M0. But for a simple “hello world” test project, 20$ is too much I think.

Everything has its limitations. A mans got know his limitations. Do you feel lucky?

You work with the limitations. Given I can read 4 DS18B20’s, an LDR & moisture sensor via analog, a send now switch and a BME280 on a Pro Mini on 2 x AA batteries that just runs and runs and runs, I’m not sure how this isn’t a good entry level starter device.

Sure, you migrate on to something with more memory early on. But as a starter for ten, something that allows someone to use the Arduino resources, why knock the plucky little MCU that can?

An Adafruit Feather M0 with RFM95 is going to be ~€35 which is food money for a week, sure. And we don’t know if you are a student at school or university or you are employed in a good job, so it’s hard to say if this is a lot of money for you or if you need to rethink your investment in your future.

What are you trying to achieve? What is the purpose of this project?

Are you able to support ADR & OTAA? Your repo you linked up the thread doesn’t seem to use either.

Unfair comparison to re-purchase the radio in one option but none of the others.

In terms of fair hardware comparisons, the Trinket M0 has what is needed and costs $9; granted it’s not clear that anyone has sunk effort into supporting it yet. But that’s a name brand board for less than similarly branded ATmega boards. And there’s actually the $5 Adafruit QT Py with a similar processor with similar resources that could also do it.

The focus on the ATmega328 has really outlived its merits, continuing to sink more effort into it when there are better ARM options from just about everyone and even (as you also noted in your repo) better low-end ATmegas, only perpetuates its anachronism.

I get it, lorauser has already ordered another ATmega328 board, understandably they’ll probably try to use it when it arrives.

But it’s really not a good choice to be steering people towards.

This project is for learning and understanding how Lorawan/TTN works. I don’t have any sensors to send data yet. I want to see if is reliable this network. How packets will be transmitted inside the house and how many time a single node can run from one battery. I understand, to exclude coverage problem (public gateways can appear and dissapear) I would need to buy my own gateway.
For testing purposes, public gateways are OK.
I did some tests with 2 LoRa nodes and I’ve been surprised how many obstacles can penetrate this radio. I have seen a good transmission while between 2 nodes there was some 8 beton walls inside a building. Or, the same distance and walls and I placed the sender inside a metal cabinet for clothes (door closed). I’ve seen the packets coming without loss. It’s amazing. We know the radio waves are reflected by metal surfaces. How the packets escaped from metal enclosure? Maybe through little holes. It’s interesting to repeat the same with TTN. Then, maybe I will implement a sensor inside my letterbox (to be alerted when I’ll get something).

I played this night with Trinket M0 and RFM95. I used this example.
For my board, pins D3 and D4 are free, so I can use them as CS and RESET.
I don’t understand why I get “ValueError: D3 in use”. I can’t find what module is using this pin. I asked Adafruit experts.
If this test will work, maybe I will implement LMIC on this board to be able to communicate with TTN (while arduinos are coming).

The decisive factor is the price I think. That’s why we don’t have many examples with ARM boards.

Resolved. The problem was different pinout. I looked at 3.3v trinket, but the right is M0. Mine board has 3.3V, so it’s confusing.
I found right pinout (my CS is D0 and RESET is D1), resoldered my wires and Trinket M0 + RFM95 can send and receive LoRa packets from/to adruino nano RFM95. Next step is looking forward to LMIC.

1 Like

I have to admit when I looked at a picture of the trinket M0 on the Adafruit site I though it had more available pins than it does. Getting LMiC going is going to be tricky because you don’t really have I/O’s left to monitor the DIO pins typically used for detecting the end of transmission and the success of reception. It is possible to do this by polling, it would require slightly longer receive windows in compensation but that doesn’t cost as much power as one might think. The more practical problem is that this would require some code changes. And you don’t have much left for reading sensors (though you could use the LED pin as another chip select and read SPI things).

They’re really not more expensive in actuality. If you compare something like the ubiquitous STM32F103 “bluepill” to various nano/micro Arduino’s the cost is about the same, but the capability is quite different.

Mostly it’s a matter of inertia - though the point about that to note is that the Arduino-realm inertia of TTN and other LoRaWAN efforts is not and never really has been with ATmega328’s running LoRaWAN stacks. People have either used more capable MCUs also supportable by Arduino, or they’ve used a module with a built in LoRaWAN stack and had an ATmega only to collect and prepare data.

To what end, are you an electronics undergraduate OR already working & want to move up or across in your career?

At worst, you can skip the D1 as reset so you have D0 for NSS/CS and D1/D13 for the DIO0 & 1 and rely on board reset at power up.

Trouble is, that leaves you no I/O for actual sensors unless you start removing the DotStar LED.

1 Like

I like electronics and telecommunications. It’s my hobby.

1 Like

This idea may be useful for debugging actual “no JoinAccept”. I could send a simple “hello world” data. Thanks!