Hello, we got some issues with interrupts on pin PA5 and PA6 on RAK3172-T stamp module.
We are using attachInterrupt(digitalPinToInterupt(pin), ISR, RISING) in Arduino IDE. We got exactly on interrupt after flashing on each pin, but then no others.
Can somebody help?
Hi @jjbunse ,
Can you please provide more details on the issue you encounter so we can assist you better?
AT+VER=?Hello, PA5 and PA6 are wired to Senba Sensing RS412D pir sensor, so external devices.
Interrupt isn’t fast, we have long “high” pulses that need to be driven low by RAK3172.
We are using boards with AT+VER=RUI_4.0.6_RAK3172-T and newest version,but both show same issue.
The issue starts after one interrupt handeld, after that there are no more interrupts. When I register the interrupts again then it works, but shows some strange behaviour with system. The board is a custom design.
Wiring:
PIR RS412D DOCI/INT PIN → 500ohm resistor → RAK 3172-T pin PA5
same wiring for PA6
Hi @jjbunse ,
Thanks for the details. Since this is a slow interrupt, have you look on the signal levels on the IO pins? What are the voltage levels?
If you can share me the code, I can try to emulate the IO trigger and run test on my unit to replicate the issue.
Also, what happens when on the ISR, is there anything there than can affect the triggering of the next interrupt sensing?
Hello Carlo, I think I fixed the main issue with the ISR now. It triggers fine on new RUI3 version, when I am putting the pins in output, low before and then changing them to input and interrupt.
But now I got another issue with api.lorawan.send() now.
It only sends one packet after joining, then all other packets won’t be accepted by send. This is the testing code for extra small packets (low airtime):
void APP::sendStatus(const Event &e) {
if (tx_active) {
Serial.println("Radio busy, skipping send");
return;
}
// TEST LPP 1BYTE
CayenneLPP lpp(4);
lpp.reset();
lpp.addDigitalInput(99, 1);
bool ok = api.lorawan.send(lpp.getSize(), lpp.getBuffer(), 1, false);
Serial.printf("Test‑LPP size=%u → send %s\n", lpp.getSize(), ok?"OK":"FAILED");
if (ok) tx_active = true;
}
We are in EU868 region and using RAK7268CV2 as gateway with central chirpstack server. On other product we used the same code and it sends the data (same payload) just instant, so I don’t know why this keeps happening right now.
If you need to have a look at the code I can share you via DM.
You can send me the code and I can have a look. Though somethings to check:
The function sends 1 payload after join, on next function call it just responds with FAILED, so the api.lorawan.send() returns FALSE instead of true.
I just tried the OTAA example from sketch, this seems to work when I use latest RAK RUI version on RAK3172-T and LoRaWAN stack 1.0.4 on server.
I don’t know why, but in our production batch this seems to be a device fault in like 2/3 devices, there are about 1/3 devices that send their payload just normal.
I sended you our quick draft code via DM. I don’t know wether it is an interrupt issue that stops sending or some race condition that comes up, as I need to check in detail with RUI3 API, as it is very strange that some devices have this fault and other don’t.
Thanks, Jan
Hi, I mainly have problems with the scheduled lorawan heartbeat timer in my code now. It works but after about 200 packets every 2min it stops working permanent, no more packets, even after rejoin, only device restart.
Can you look into this problem?
Example OTAA Code sketch with custom payload:
It seems to stop after about 18-36h and then can not longer send anything from this sensor. Only restart of sensor clears the problem.
What LoRaWAN region are you using?
Can you check if there is any log output from the RAK3172.
If you are using EU868, you might run into duty cycle problems. Your payload looks quite large.
If EU868, make sure on the LNS all 8 channels for EU868 are enabled, otherwise the RAK3172 is sending only on the default 3 channels and will hit duty cycle restriction earlier.
But is it typical that after Duty cycle problem the device stops sending complete? Like even a few days after stopping sending, no more packets will arrive.
Duty cycle is just a guess of me. You need to check the log output of the RAK3172 to know if I am right.
If the duty cycle is hit, the modules LoRaWAN stack implements a “restricted wait” and refuses to send more packets. If you continue trying to send packets, the “restricted wait” timeout is never reached.
Two options
You can check the restricted wait in the debug output of the RAK3172, unfortunately there is no way to know it from API afaik (I will confirm with the R&D team).
If restricted wait is applied, every time you send a packet, there will be a debug output similar to
Restricted_Wait_3335681_ms
The xxxxxxxx is the wait time before you can send the next packet.
Hi @jjbunse ,
How long for you not to be able to send uplink will be shown on the serial logs as mentioned by @beegee .
Like for this one, it tries to join but failing.
I’ve looked into your codes but to trace this issue, we need to look on the LNS, get some logs on the nodes (if possible) or have the ability to check any serial output before it stops transmitting (which can be useful in troubleshooting).
Long time ago, in the early RUI3 version, we have found issue related to timer but that should have been fixed by now.
How can I activate debug output? Like AT+DEBUG=1? I cannot find anything in RUI3 about it.
In production the product will only send about every 4h heartbeat and 10-30min sensor data, so it should be stable there with Duty cycle, or am I missing a point?
The problem is that this even stops after some hours or days and won’t send anything again.
So my questions is if I send packets in Duty cycle and these are blocked, does this reset the timer? Because otherwise it should be send after a few hours normal, just like before.
No need to activate anything.
It will be showing up, same like the +EVT: responses.
Hi, I traced out the error to the send() function that keeps returning false after a while.
Is there anything to fix this probem? I’ve tried multiple waiting timers, but the send() keeps returning false.
When I then send AT+SEND=12:112233 via AT, it returns: AT_BUSY_ERROR.
Other device, same fw version and exact same setup time, no problems, sends just fine. Logs from Chripstack are same for both devices, but one some devices the send() keeps returning false from time to time.
So my question would be how does the send() function behave in detail? Does it blocks every send() request if it is in duty cycle? How can I know if the device is in Duty cycle? Is there any workaround to schedule the packets again, instead of just blocking the send() command in general?
Hi, just to verify. I am using latest RAK3172-T firmware. Which LoRaWAN version and settings should I use in Chirpstack? Is is LoRaWAN 1.0.3 or 1.0.4?
Also there are different Regional Parameter revision, which is to choose?
I still have the problems with the send() function that is blocked after few packtes in interval of a few hours (like every 4h).
Any idea?
