I have recently purchased some RAK3172 Breakout Board modules. The current version of these module are RUI_4.0.0_RAK3172-E and I am currently testing Class C mode using RUI3. I am sending downlink messages every 1min from TTS but unfortunately, I am not getting consistent downlinks. Sometimes I am getting while most of the time I am not getting the downlinks messages on the RAK3172 Breakout Board module. Can you please help me troubleshoot the same, below is the RUI3 code.
void recv_cb(SERVICE_LORA_RECEIVE_T *data){
Serial.println("Something received!");
for (int i = 0 ; i < data->BufferSize ; i++){
Serial.printf("%x", data->Buffer[i]);
}
Serial.print("\r\n");
}
void join_cb(int32_t status){
Serial.printf("Join status: %d\r\n", status);
}
void send_cb(int32_t status){
Serial.printf("Send status: %d\r\n", status);
}
void setup(){
Serial.begin(115200);
delay(5000);
api.lorawan.deviceClass.set(2); //set to class C mode.
api.lorawan.cfm.set(1);
api.lorawan.band.set(4);
api.lorawan.njm.set(1);
api.lorawan.join();
api.lorawan.registerRecvCallback(recv_cb);
api.lorawan.registerJoinCallback(join_cb);
api.lorawan.registerSendCallback(send_cb);
//wait for Join success
while(api.lorawan.njs.get()==0){
Serial.print("Waiting for Lorawan join...");
api.lorawan.join();
delay(10000);
}
uint8_t payload[] = "example";
api.lorawan.send(sizeof(payload), payload, 129);
}
void loop(){
//waiting for downlinks
}
Note: Data seems to be consistent when tested using AT command below are the simple AT commands used, while the downlink was set on TTN.
Thanks for your swift response, the DataRate used is default to dr=0, any issue regarding the datarate used?. Refer to the snapshot as an example, I am missing the DDDD downlink message.
In addition, I have noticed that after a certain amount of inactivity time, the RAK3172 is not responding to AT commands and each time I have to power cycle the module to be able to use it.
If you are close to your gateway, the SF12 (DR=0) is likely to cause the issue. I strongly suggest not to use SF12 except on special cases (very long distance) with acceptable packet loss. I try to limit up to SF11 the operation of an end-device.
Regarding RAK3172 module that suddenly stops, does the module stopped 100% or there are just delay to its response? Also is the code on that module the Class C code you shared above? Where is the environment where RAK3172 deployed? Do you think there are other external source of EM noises/interference? In my personal experience, the RAK3172 or any other RF sensitive component can react to motors, ignition, etc. Isolation and shielding help if this could be possible reason.
thanks again for your swift response, I will try other SF and will feedback you the outcomes.
there is no delay as such in the response. the module suddenly stopped/froze I cannot send commands nor receive downlink messages when sent from TTS, is there any alternative to find out what happened during that particular time?
For now, this module has not been deployed, it is still under test in our lab prior to integrating the same in our design. Seems weird, we tested the RAK811 RAK4200 and other modules as well without any issues.
It is hard to determine what causes it but it is something we need to find. Are you using RAK3172 with custom firmware or just AT command? If custom firmware, will it be possible to share what it does or what is in the code? Does it do any specific purpose (via custom firmware) but still support AT command?
just now I tried DR=5 but the downlink issue still persists (maybe because of the freezing issue) which is why the module is not able to respond the downlink messages
I used custom firmware initially and then swapped to AT commands in the hope that the downlink and froze issues get fixed with AT commands but unfortunately not.
I am testing with just the below code only and nothing more.
void recv_cb(SERVICE_LORA_RECEIVE_T *data){
/*
Serial.println("Something received!");
for (int i = 0 ; i < data->BufferSize ; i++){
Serial.printf("%x", data->Buffer[i]);
}
Serial.print("\r\n");*/
}
void join_cb(int32_t status){
Serial.printf("Join status: %d\r\n", status);
}
void send_cb(int32_t status){
Serial.printf("Send status: %d\r\n", status);
}
void setup(){
Serial.begin(115200);
while(!Serial){}
api.lorawan.deviceClass.set(2); //set to class C mode.
api.lorawan.njm.set(1);
api.lorawan.cfm.set(0);
api.lorawan.band.set(4);
api.lorawan.dr.set(5);
api.lorawan.registerRecvCallback(recv_cb);
api.lorawan.registerJoinCallback(join_cb);
api.lorawan.registerSendCallback(send_cb);
api.lorawan.join();
//wait for Join success
while(api.lorawan.njs.get()==0){
Serial.print("Waiting for Lorawan join...");
api.lorawan.join();
delay(10000);
}
uint8_t payload[] = "example";
api.lorawan.send(sizeof(payload), payload, 129);
}
void loop(){}
while for AT commands I am using only the below commands.
in fact, the device is still working and still receiving the downlink messages from what I have seen. however, it is just that the serial hangs and each time you have to power cycle the device to be able to use the Serial again.
what you can do is, you can still print the downlink telemetry via Serial1 and that should work without any problem alternatively you can use the latest firmware RUI_4.0.5 (however i have not tested this feature).
Just an FYI i am currently using RUI_4.0.5 and i am still seeing this problem.I have noticied that i can use the reset pin on the module to reset it. i i will proceed to write code to use this reset pin whenever i lose comms with the module. thank you for your help. We can only hope that this can be resolved in a future firmware release.
Resetting means you have to rejoin the network, each time a reset is done, and is not recommended, you may simply use the Serial UART1 instead and that’s it.
I under stand yeah i have tried connecting to the serial UART1 and i get no responses. I will retry again and see . Is there a specific way to enable it for AT commands
I have also tried as a Class A device and it still hangs on downlink after a could of packets have been sent down. I have it working resetting the module but that is not great going forward. Could anyone please help shine a light on how o setup the use of UART1
