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).
1 Like
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.
Thanks to all of you for your interesting, useful and educative inputs. I learnt a lot.
It is indeed likely that I confused TTN-branded “Things Uno” node board with TTN.
I apologize for that confusion, but I hope that the community is also meant to help unskilled people.
In great part thanks to your comments, I finally solved my problem (see at the end of the message). In spite of the numerous suggestions that you made I unfortunately could not identify the origin of the problem. For sure I am not expert enough. I have however been very surprised that the community would not consider “possible” that a LoRa connection might be interrupted for many uncontrollable and possibly unresolvable reasons. When I make a phone call, I sometimes face an unexpected interruption although there should be no reason for that.
So, instead of climbing the steep mountain, I walked around it. This may not be satisfactorily as some of you mentioned, but at least I ascertained that it works.
The ttn_response_t toto = ttn.sendBytes(payload, sizeof(payload)); command seems to both send the payload and put the feedback from the gateway into the toto variable, with values being 1 when the transmission is successful, -10 when there is a problem, -1 when the payload could not be sent, and maybe other values in other situations.
Thus I added a test on the toto value to restart the join procedure when the value of toto is different from 1. And it works finely.
I still do not know how to close a discussion (is it my responsibility ? or the responsibility of any authorized member of the community ?), but as far as I am concerned, the discussion can be closed.
There is not really any such thing as a “connection” in LoRaWAN. Certainly not in the way there is between your mobile and its network.
It’s important to understand that the node’s module really has no idea if any gateway is listening or not. There is no “connection”. Hence an error here likely indicates that the module is still busy with a previous request, that it is refusing to transmit because it believes the regulatory duty cycle has been exceeded, or because it believes that it does not have any currently valid OTAA session address/keys set.
In the first two cases, doing a rejoin is a severe mistake, and will only make things even worse.
In the latter case, you should probably not command a restart of the join process unless you know for a fact that no join attempt is still in progress. You can only join a limited number of times, and if you abort an attempt after the network has heard you, not only will you have to start over, but you will have uselessly used up one of those join allowances.
1 Like
no problem 
see you next time