RFM95/Arduino ProMini/LMIC

End Devices (Nodes)
1

Dear all

I tried to build a node with a RFM95, Arduino ProMini and the LMIC library.

Unfortunately it works not correctly. After I conected the Arduino the a power supply, I got just one message at console.thethingsnetwork.org and then nothing, unless I push the reset button. This message has an orange flash on the left side. Sometimes it works and I get several messages. But also with the orange flash.

If you need some more information to analyse my problem, please let me know.

Thank you for your help.
Patrick

2

This sounds like a voltage drop or something with your voltage regulator.

  1. Perhaps your batteries can’t provide enough power. The node uses more when it transmits and that may just be too much. If this is the case adding a small capacitor (somewhere between 10 and 100 uF) will do. You should connect it in parallel with the battery.

  2. Some pro mini clones have crappy voltage regulators. They sometimes require >4.5v to work. This means if you use 3 non rechargeable batteries you’re just below the treshold, and then you might get this kind of behavior. Solution: add a capacitor on the same way, or remove the voltage regulator and power it with only 2 AA’s straight on the vcc.

3

Hi TijnOnlijn

Thank you for your suggestion.

Actually I have two nodes. One with an Arduino nano and the other one with the Arduino ProMini. Both has the same problem. Because of that, I belive it is a software issue. Most of the time the nodes were pluged in to my computer. So there are enough an stable power.

Here are the current pin mapping of both nodes:
Arduino RFM95
RST RESET
3.3V -> 3.3V
GND -> GND
4 -> DIO0
5 -> DIO1
6 -> DIO5
7 -> DIO2
10 -> NSS
11 -> MOSI
12 -> MISO
13 -> SCK

and on the software side I tried two configuration:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {4,5,LMIC_UNUSED_PIN},
};

and:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {4,5,7},
};

4

I don’t know if there is a relation, but just checking: did you add a level shifter to the nano? If not there is 5v on the signal pins.

5

Hi @chaoscrack, @TijnOnlijn,

This issue is related, probably, with the fact that the Arduino Pro mini is running @ 8MHz, so the clock inaccuracy is enough to exceed the Lmic tolerance on the receiving window. This issue happened to me before.

In order to solve this you will need to add the following expression somewhere in your setup():

LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

This tells LMIC to make the receive windows bigger, in case your clock is 1% faster or slower.
Check how I solved it in the following link:

Hope it solves your issue.

1 Like
6

Hi luisgonc

Thank you for your help.

I added this line and also I soldered the RST to pin 9 and changed the configuration to this pin.

Now I get continuously some messages. But the time between two messages are rising.
2min / 2.5min / 4min / 4min / 7min / 8min / 14min
The orange flash is still there.

7

@TijnOnlijn
Thank you for this hint. No I didn’t.

8

Stupid question

If I’m open a message I read the word Activation.
Do I have something to do to finish the activation? Until now I only put the three addresses into the *.ino and flashed the Arduino.

9

You’re referring to an OTAA message in the Application’s Data page, or in a specific node’s Data page:

image.jpg2216Ă—1766 278 KB

If you see the above then your node successfully registered with TTN (this means the keys you programmed into the node are okay), and TTN will have commanded the gateway to transmit the Join Accept to the node, 5 seconds after it received the Join Request. That Join Accept message holds the secrets that the node needs to send regular data to TTN. So, for OTAA you need a gateway that can send downlinks; some single-channel test gateways cannot send downlinks, hence will not support OTAA.

Now, if all is well, the node was listening at the exact right moment and will have received that radio transmission and now knows the secrets. At that point it will have “joined” the network and is ready to send packets.

But neither the gateway nor TTN will know if the node actually received it. If it didn’t, it will have to try again, using different transmission parameters (such as frequency and spreading factor)… You could validate if you implemented luisgonc’s MAX_CLOCK_ERROR workaround correctly, or maybe increase the 1% to some larger value.

As an aside, in the gateway’s Traffic page, you should see a (yellow) uplink for a Join Request, and a (green) downlink for its Join Response:

image.jpg2836Ă—1036 219 KB

10

Hello arjanvanb

Thank you for your explanation. It looks like that the gateway who receive my messages is a single-gateway.

For an OTAA do I need all the time a gateway who can send downlinks, or is it enough once?

11

Once is enough: the node will (should) remember the secrets. However, many nodes lose their secrets when they lose power or when restarted.

If you’re using a single channel test gateway that does not support downlinks then ABP instead of OTAA might be much easier though. (But for ABP you might want to disable the frame counter check.)

But even if a single channel gateway supports downlinks (like Jaap’s ESP8266/RFM95 single channel gateway), it’s still just that: a single channel gateway, listening to only a single predefined frequency, and often even a single predefined spreading factor. Standard compliant nodes should use multiple channels and might use multiple spreading factors, so a single channel test gateway will not receive all messages, which also makes OTAA hard.

That should be easy to determine; what gateway are you using?

12

Now with ABP it works. Thank you!
Unfortunately I don’t have my own gateway. So, I can’t say what kind of gateway it is who receive my messages.
At our FabLab we use a iC880a concentrator board and a RaspberryPi. But also here I don’t receive a downlink. Maybe the guy who setup the gateway missed to configure the OTAA.