Hi,
I’m trying to debug a long term issue…
I have a CubeCell AB01 which takes a measure on the ADC, send it over Lora and then deep sleep for 30min (just my test environment)
the system works great but after ~48h of cycles it does not wakeup anymore.
anyone seeing something similar? it’s like we are missing the wakeup signal from the RTC I guess…
if I hit the reset button everything works … but then after a couple of days same story
I haven’t experienced this with the sender but have with the receiver. Do you have an example of your code? Is the receiver a CubeCell or Wireless stick?
I had an issue were after waking the receiver wouldn’t receive. Similar to you waking every 30min. But when I plug in a serial I seen that the sender was actually waking the receiver just wasn’t getting it. It was an issue with how I had set up the delay after radioSleep.
the receiver is actually a ChirpStack Lora Gateway (based on i880a). I trust the gateway since has been running for 3y (24/7) with no issues on other devices.
the sender is a simple CubeCell AB01. Code is based on the lowpower example. I read the ADC every 30min then go to sleep and once I have 12 values I send a lora message.
somehow it works for a couple of days … then it gets stuck and does not wake up.
is there a way to attach a debugger to understand why it is stuck?
same problem here:
after adding a watchdog (which wakes up the device every 2 seconds) it did not hang any more even the watchdog did never trigger.
wow! thanks I missed this post. Definitely seems to be the same issue.
ok, I’ll try to understand if it is hanging during a send … or if it is not even waking up from sleep.
thanks a lot for the hint
Hi everyone,
after some debug and test I think I nailed the problem.
I’m using the CubeCell connected to a ChirpStack gateway, monitoring all the transactions.
This gateway is stable, running from more than 1y with other LoraWAN devices not based on cubecell.
on my cubecell sensor I’m sending one frame every 3h and after few days everything is stuck as I mentioned.
But using an RF scanner I noticed that I was still sending frames over the air, so looking at the logs I got the message:
Dec 01 18:01:56 ttn-gateway chirpstack-network-server[511]: time=“2020-12-01T18:01:56+01:00” level=error msg=“uplink: processing uplink frame error” ctx_id=e4f4aa1c-5fa4-44ff-93f4-4e03c6936497 error=“get device-session error: frame-counter did not increment”
It seems that the problem is on the FRAME COUNTER number of the frames sent by the cubecell.
somehow it is not incrementing anymore (did double check) and so it is failing the FCN check and discarding the new data.
and this explains why if I reset the board everything works fine.
===
I’m sending data to the gateway with ACK and indeed the gateway is responding on each transmission, but then the packet is dropped because of the wrong frame number…
===
where is the code that handles the fame number increment on each transmission?
thanks
and I can confirm my previous post: after few hours my “autoreset” call did trigger and immediately after everything was fine again … (I’m am forcing a sw reset every 24h+random_delay() so that It will also make a re-join just in case the gateway went down…)
So I suspect there is a bug in the way we compute the frame number (at least with the ack mode I’m using).
anyone familiar with that part of the code?
any help/idea is welcome…
hi,
Could you show your tools menu?
BTW, I’m sorry. And I’m a little confused by your description. are you use LoRaWan?
and just to summarize the issue I’m getting:
the system is not stuck, everything is correct. the CubeCell AB01 is alive and is sending data every 30min as usual. the gateway (chirpstack) is always sending ACK back no problem. And I can confirm I can see the whole transmission over the air using an RF spectrum analyzer.
but the problem is that after few days the frame counter in the uplink frames seems NOT to increment anymore, and the gateway is discarding the incoming data.
if I reset the cubecell the FCN is restarting from zero (due to the join…) and everything works fine (gateway is not discarding data because the FCN is incrementing again…)
Hi JasonXu,
I think that the issue is inside the LoraMac we have in the CubeCell core library.
it seems to me that the code is VERY OLD, back to 2017.
looking to the github repo of Lora-Net I can see the most recent version of LoraMac (semtech) is from 2020 and there are few commits that are fixing the frame number increment.
for example:
and also:
===
Is this something you guys can take a look and eventually fix in the current release of the CubeCell github repo?
===
Also, what is the roadmap from Heltec to keep track of the new bugfixes from Semtech and port back to the CubeCell library?
I think that this is quite important for the CubeCell product itself to be successful… after all this is a LoRaWAN communication device…
thanks
i have also some trouble with hhtc ABo1, but i can say that the sensor in EU with OTAA worked for me for more than 6 month, sending every 10 minuites a packet! Arduino IDE and cubecell possible 1.00 or 0,05! With some new sensors i have also a problem, that they work fore same days and then not work but other sensors work fine!
We attach great importance to this issue. And We really want to solve this problem. Do you mind post your code(.ino file)?
I think the problem may be the payload exceed the max allow payload once the node lost downlink ack and reduce DR to DR_3 or lower.
I think you can have a try modify the EU868_TX_MIN_DATARATE to DR_4 to ensure the payload can be send.
Excuse me for coming in here.
Where can I find these settings on The Things Network pages?
E_T
I can try this … but I’m not convinced this is the issue.
in my debugging and logging there is no fallback on lower DR (also because the sensor is positioned at 5meters from the gateway in the same room…)
so imho this is a real bug … and imho the LoRaMac should be updated anyhow … because I see many bugfixes on the original repo that are not included in the version used by CubeCell.
the 10800 option is used as an “expected upload cycle” to monitor a node and declare that node “missing” … nothing related to LoRaWAN … just a server side parameter.
to get this version do not use the “default” raspberry image, do the “ubuntu” installation on your raspberrypi as documented on the ChirpStack website.
the “prebuilt” images are usually older and not updated so often … and I’ve found that few of them had bugs … so I usually stay close to the latest release and do the install on my own on the normal RaspbianOS image.
