I have a problem with my arduino connecting to a LoRa network. I am using the ttn protocol.
Description of the problem: I load the aduino chip with the program. The connection to the LoRa network falls perfectly into place and the payloads are sent as expected, every couple of minutes. But after a while (it can be after half an hour or after several hours of normal exchanges) the connection stops and I get the following message: “Response is not OK: not_joined - Send command failed” instead of the usual “Successful transmission” message. After the first occurrence of unsuccessful transmission, the system never overcomes this blockage and I have to restart the whole thing “manually”.
I suspect that the problem comes from the antenna to which my arduino is connected. That antenna is not under my control.
My question: I would like to introduce a test in my script in order to automatically restart the connection process when there is an interruption in the payload transmission. How can I do ? Obviously, my arduino collects information telling it that the payload could not be sent. How can I catch that information to make a test on it ?
Thanks in advance.
that’s not enough information.
what node
what gateway
what software
’ I suspect that the problem comes from the antenna to which my arduino is connected. That antenna is not under my control. ’
explain that part too please 
do you mean you don’t have your own gateway ?
Whilst the LoRa device has overcurrent protection (OCP) for the transmit output, so potentially could detect antenna faults, I cannot see mention in the datasheet that the device at the firmware level knows when OCP activates and warns the device that transmission has not been completed.
Dear BoRRoZ
I am very far from being an expert. So I cannot answer most of your questions. Thus I give below a couple of additional details which might help, but more importantly, I try to express my question in a different and hopefully more precise way.
My arduino is a The Things Uno product (hope this helps to answer the software question). It is located “in a field in the countryside”. Let’s say that it sends a temperature measurement through an hexadecimal format every 10 minutes. It establishes a connection with an antenna maintained by a phone company (Orange in France, if this may have any relevance) and I collect the data on the company’s web interface (hope this helps to answer the software question). To my knowledge, there is no reference to any node or gateway in my arduino script. And from the web site of the phone company, I only mentioned the Id, DevEui, AppEui, AppKey of the chip and the use of an OTAA protocol for transmission. Again, to my knowledge, there is no mention of any node or gateway in the web site.
In order to overcome the connection interruption occurring at random, I included the ttn.join(appEui, appKey); command into the loop section of the arduino script but this is energy consuming and an inappropriate way to do in my opinion. I would like the ttn.join(appEui, appKey); command to be expressed only when the connection has been interrupted.
Thus, my (very specific) question is about how to retrieve the status of the LoRa connexion as it is perceived by the arduino and translated by the error message “ Response is not OK: not_joined - Send command failed ” in the Serial window.
I read on the https://www.thethingsnetwork.org/docs/devices/arduino/api/network.html web page something about the following ttn command:
ttn_response_t sendBytes(const byte* payload, size_t length, port_t port = 1, bool confirm = false, uint8_t sf = 0);
In that subsection, there is something about
Returns a success or error code and logs the related error message:
-
TTN_ERROR_SEND_COMMAND_FAILED: Send command failed. -
TTN_SUCCESSFUL_TRANSMISSION: Successful transmission. -
TTN_SUCCESSFUL_RECEIVE: Successful transmission. Received bytes -
TTN_ERROR_UNEXPECTED_RESPONSE: Unexpected response:
but I am neither able to know whether exploiting that information is what will help me, nor able to exploit it if it is relevant.
So how can I have access to the information that the arduino catches about the status of the connection, to make a test on it ?
I hope that this helps…
Thanks in advance.
that’s your node 
no not really, please explain … you have an antenna on your ‘node’
That node transmit every 10 minutes data that is received by ? Orange ?
So this is not a TTN question ? … I allready have an idea 
Could you explain that please, antennas are normally permanently connected.
I am sorry not to be able able to explain what occurs. I would like to.
I do not know what happens between the arduino sending the payload and the information that I can read on the website of the phone company. I do not know how the LoRa protocol deals the relationship between an antenna and an arduino chip. I feel that knowing that could at least in part help to solve the problem.
My guess @pierreberthomieu means an Orange gateway.
@pierreberthomieu it helps if you read up on LoRaWAN terminology and use the right words to describe your issue.
From the symptoms it looks like your LoRaWAN module which is part of the Uno is reset, possibly by power issues, possibly by asserting the reset line.
Yes my node transmits data every 10 minutes that are received by Orange. This can work perfectly over several hours. and suddenly, the sending process is interrupted because when the arduino tries to send the payload it gets back “something” which makes it print Response is not OK: not_joined - Send command failed in the Serial window.
I think that it is a ttn question as I think that the ttn.join (or the ttn.sendbyte) function responsible for the connection to the antenna (and the sending of the payload) get an information telling it (them) that the process did not occur normally.
But I may be wrong. If I am wrong, where can I ask the question ?
That message is a response from the LoRaWAN module on the board. That module suddenly thinks it is no longer joined to the Orange network.
Can you share the entire code (in a formatted message or on github) so we can take a look at what might be wrong?
OK for the orange gateway.
I agree that using the appropriate terminology helps. I am going to improve my knowledge. But it is not easy for an ‘old’ French farmer. So please be understanding. 
I am not sure to understand what you precisely mean when you write that the lorawan module is reset. What I observe is that the uno goes on trying to send payloads every 10 minutes. I do not know whether this fits with your hypothesis.
Then if you are right, considering that the Uno is brand new (i.e. buying a new one would not solve the problem), is it possible to add something in the script to restart the lorawan module when it has been resetted ?
That message is a response from the LoRaWAN module on the board. That module suddenly thinks it is no longer joined to the Orange network.
OK, I follow you.
For your information, when I relaunch the connection using the following commands:
loraSerial.begin(57600);
debugSerial.println("-- STATUS");
ttn.showStatus();
debugSerial.println("-- JOIN");
ttn.join(appEui, appKey);
it successfully restarts the connection. So the question is: how to restart it only when it has been resetted ?
OK I am going to try to share the entire code in an upcoming post, but
1- I have to “clean” it as there are more than twice as much comment lines written in French as command lines
2- I have absolutely no idea how to proceed to share the code in a formatted message or on github as I never did that before (and actually do not really know what is github).
So I might be very long.
Here is my code, to send a temperature value:
#include <TheThingsNetwork.h>
const char *appEui = "XXXXXXX";
const char *appKey = "YYYYYYY";
#define loraSerial Serial1
#define debugSerial Serial
#define freqPlan TTN_FP_EU868
TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);
const int broche_sortie_tmp36 = A0; // this is for temperature measurement
int valeur_sortie_tmp36 = 0; // this is for temperature measurement
float temp_tmp36 = 0; // this is for temperature measurement
int compteur = 0; // this is a counter
void setup()
{
loraSerial.begin(57600);
debugSerial.begin(9600);
analogReference(EXTERNAL); // I connect the 3.3V pin to the AREF pin
while (!debugSerial && millis() < 10000)
;
debugSerial.println("-- STATUS");
ttn.showStatus();
debugSerial.println("-- JOIN");
ttn.join(appEui, appKey);
}
void loop()
{
debugSerial.println("-- LOOP");
// Use a counter to relaunch the LoRa connection every 6 turns (60 minutes):
compteur = compteur + 1;
if(compteur == 6)
{
loraSerial.begin(57600);
debugSerial.println("-- STATUS");
ttn.showStatus();
debugSerial.println("-- JOIN");
ttn.join(appEui, appKey);
compteur = compteur - 6;
}
// collecting the raw data and calculating the temperature:
valeur_sortie_tmp36 = analogRead(broche_sortie_tmp36);
temp_tmp36 = ((valeur_sortie_tmp36/1024.0)*3.3 - 0.5) * 100;
// printing of the raw input, calculated temperature and counter values (for control):
Serial.println(valeur_sortie_tmp36);
Serial.println(temp_tmp36);
Serial.println(compteur);
// sending the payload in hexadecimal format:
byte envoi[] = {highByte(valeur_sortie_tmp36), lowByte(valeur_sortie_tmp36)} ;
ttn.sendBytes(envoi, sizeof(envoi));
// repeating the operation every 10 minutes:
delay(600000);
}How is your Arduino powered? Do you keep it connected to your computer at all times?
I still am in a phase of test. Sometimes the arduino is connected to my computer, but most often it is connected to an electric plug as I need my computer for my work.
And in the end, the arduino should be powered by a battery or a solar device as it will be definitively located in a field.
It is not a good practice to join so often like you do. Ideally, you would join once and then save what is needed to avoid joining again.
Said that, you are using TTN software on your device. I am not sure it does not contain any dependency specific of TTN, which is a competitor of Orange. Maybe someone with specific knowledge on the library could help on this (one reason more to ask in Orange forum, if they exist).
I agree with you that is not a good practice. But in order to face sudden, unexpected interruption of the payload transmission, and as I need to have a “continuity” in the payload transmission, I up to now did not find any other way to proceed. While so doing, the interruption lasts one hour at the maximum.
In order to find a better way to proceed, I would like to relauch the join command only after an interruption occurred, and this was the reason of my question to the community.
About the competition between TTN and Orange, you may be right, although Orange does not sell any device to my knowledge, and thus Orange should be able to adapt to any material. I am not sure that an exclusive proprietary technology would be the best way to develop the business, at least as far as Orange is considered. Indeed, Orange has “by construction” a network which covers all the country (since it is a phone company supposed to cover 99.9% of the land), which is far from being the case for TTN for instance.
During the development of the discussion, I went on searching a solution on my own. Indirectly exploiting some of the feedback from the community, I think that I may have found something interesting. I would like to share that idea, if any member of the community can infirm, confirm or improve it.
I plan to use the ‘ttn_response_t’ command as follows:
ttn_response_t toto = ttn.sendBytes(payload, sizeof(payload));
I have no idea of the different values that toto may take. Up to now, when the payload transmission is successful, the value of toto is 0. As soon as possible, I will include that command in the script to check the value of toto when a transmission interruption occurs. I expect toto to take a different value from 0.
Then I plan to make the following test on toto to activate the join command when toto is different from 0.
if(toto != 0)
{
loraSerial.begin(57600);
debugSerial.println("-- STATUS");
ttn.showStatus();
debugSerial.println("-- JOIN");
ttn.join(appEui, appKey);
}
I will tell you whether this works or not.
Meanwhile, any comment is welcome.
The meaning of “joining” in LoRaWAN is not that you are opening a connection to the gateway or network that stays open and that can break. You “just” receive a session key. It is also strange that your device is able to tell that the session key is no more valid.
It is very difficult to debug your issue, however check this issue that is very similar to yours:
Joining every time there is an error is not a substitute for finding where the error is happening. If you join too often, sooner or later your requests will be refused.
TTN is at first an infrastructure provider, like Orange. LoRaWAN by design is neutral, but if one company like TTN wants to provide specific libraries to help its own users, is allowed to. You are using a library that in principle could be made for TTN users (but again, I am not sure - maybe it is sufficiently neutral too, I do not use it).
I think the asker is partially confusing the TTN-branded “Things Uno” node board with TTN.
TTN is really the network; a node board with this branding exists only to support that, it is not really intended to be a distinct product.
While hardware intended for TTN can be used on other networks, that’s not really the point of this forum.
I agree. I can imagine, due to LoRaWAN being a standard, that TTN Uno could be used on other networks, however for example there is one point where TTN is not standard and is RX2 freq/datarate, maybe this could give problems.