Hello folks,
I’m working with STM32L432 with I Cube LRWAN V1.2.0.
I’m successfully ported and run the code of STM32L476 on STM32L432 with SX1278 LoRa chip.
Tested means I’m getting the data on my TTN server.
The problem is loosing the packets times for uplink and downlink too, what is the problem behind this or anyone have the idea about this if facing too.
Sometimes It’s behave like deliver the downlink data at node but not getting payload at the server side, it shows only null data.
Thanks in advance!
1 Like
Hello all,
I’m working on I Cube Lrwan with STM32L432KC with SX1278 module.
Everything is working perfectly with the IN frequency band but when I’m trying to implement it on EU868 band it won’t work.
Sometimes it takings long time to join and when if joined I won’t get the data on my TTN application even not in gateway log as per fixed time interval.
I’m continuously pushing the data on 10 seconds but only gets delivered to application.
I’t seems like it follows the fix time to push the next data around 2 minutes.
Does anyone have the idea about this or any suggestion to guide me in proper way.
Thanks in advance!
Without any explanation of the screenshots, all I see is that a packet with frame counter 8 is missing. This is wireless; there’s no guarantee that all transmitted packets will indeed be received. Like maybe it collided with a packet from another node. (You’re sending text, and using SF12 which is the worst, yielding an air time of more than 1.3 seconds. Hence chances for collisions with other nodes using the same SF are high too.)
If you’re saying that your node is refusing to send every 10 seconds: yes, that’s very much to be expected. When sending 4 bytes of application payload on SF12 (requiring 1.318 seconds for each packet), EU868 duty cycle limitations only allow one packet every 131.89 seconds for a 1% duty cycle. If all is well then your node’s software should indeed enforce that and refuse to send more often. But that’s by design, and certainly not referred to as “packet loss”. See https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html
Beware that even one such message every 2 minutes is way too much for TTN; instead only 22 messages per day would be within the limits. See Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy (which also explains: don’t send text).
Finally: I don’t know what “switch to class C done” means, but TTN only supports Class A.
(Please don’t post images for text-only content, such as the node’s log. Please re-read before posting; things like “only gets delivered” are clearly missing something, and “shows only null data” needed much more detail. And please don’t post screenshots that include the same data twice. We’re happy to help, but not too happy to need to decipher your question.)
1 Like
Hello @arjanvanb thanks for your instance response,
I have read that limitation and then after I have just disabled the duty cycle by which I’m successfully get data on application based on my defined time.
Finally: I don’t know what “switch to class C done” means, but TTN only supports Class A.
There is a reason behind this based on my understanding(don’t know I’m right or not) but if I’m not changing the class I’m only getting data to gateway but not getting on the application.
If I’m explaining second case where I’m sending one dummy(null) payload and than after only getting data to application but only uplink no downlink.
But in the case of changing class from A to C both uplink and downlink works properly.
Is there anything that i’ve missed or getting something wrong?
Sure, let’s all do that. 
By sending 1.3 seconds every 10 seconds, your node alone is using more than 10% of the available time. The radio frequencies are shared with other people. What if someone else needs to transmit something too?
You’d better search for ways to not need SF12.
I don’t understand what else you’re trying to say. One more thing I noticed in your screenshot: be careful using port number 0; that’s reserved for uplinks that have no payload, but do have MAC-commands.
“I don’t understand what else you’re trying to say”
If I’m just switching from class A to Class C after joined over OTAA than only I’m getting data on my application, both uplink and downlink.
But If i wouldn’t change from default class that is Class A after joined, I’m not getting my data on my application but it delivers on the gateway.
Now I’m completely blank to resolve this issue. do you have any idea about this??
Thank you!
What exactly does that mean? Are you seeing uplinks in the gateway’s Traffic page in TTN Console, but not in the application’s Data page?
If, instead, you’re trying to say that uplinks work regardless if your node is using Class A or Class C, but downlinks only work when the node uses Class C, then there’s probably a timing issue.
In Class A, if implemented well, the node should be listening for a possible downlink exactly 1 second (RX1) and 2 seconds (RX2) after it has transmitted an uplink. Apparently that fails.
For Class C, even though TTN does not support that yet, the node will be listening for a downlink all the time. This obviously needs a lot of energy, but apparently then the node receives the Class A downlinks that were transmitted in either RX1 or RX2.
(And please don’t ignore my remarks about the duty cycle limits.)
Thanks for your response,
And please don’t ignore my remarks about the duty cycle limits
Yes I understand your point.
If, instead, you’re trying to say that uplinks work regardless if your node is using Class A or Class C, but downlinks only work when the node uses Class C, then there’s probably a timing issue
Yes exactly!
I have tried by increasing the RX1 and RX2 windows timing from 1 and 2 seconds to 3 seconds each but still it’s not working.
After debugging I found that RX1 windows are on data rate of 0(SF12) and RX2 on data rate of 3(SF9), even TTN sends the downlink on SF9 with 869.525 frequency.
But still won’t get on node side.
Do you have any idea about this?
The RX1 and RX2 windows are not used to listen for 1 and 2 seconds. Instead, a Class A device will not listen at all after is has sent an uplink. Then, after 1 second it will listen very briefly, to see if it can detect the start of a downlink. If not, it stops listening and tries again 1 second later (2 seconds after the uplink). So, you should not change it to, e.g., 3 seconds; that is not extending the time it’s listening but it will only start listening at a later time.
You’re missing some basic knowledge here. Please read https://www.thethingsnetwork.org/docs/lorawan/ and also browse the specifications to at least understand the basics.
So, the timing is critical. As for how to solve it in your case: I don’t know. (For LMiC, it would need adjusting MAX_CLOCK_ERROR.)
Yes, all documented. For OTAA on EU868, you will get the correct settings automatically in the OTAA Join Accept message. Your device needs to handle those settings of course.
1 Like
Thanks for your response,
static void LORA_HasJoined( void )
{
#if( OVER_THE_AIR_ACTIVATION != 0 )
PRINTF(“JOINED\n\r”);
#endif
LORA_RequestClass( LORAWAN_DEFAULT_CLASS );//CLASS_A
LORA_TxNeeded();//NULL data
}
Here is the things that i’m not understand,
After JOINED if I’m not calling “LORA_TxNeeded()” I’m not getting data on application(but getting on gateway) and if called getting data on application but not getting downlink.
But in second case i’m getting the downlink data on gateway with SF9 on 869 frequency but not getting on my node.
I don’t know what LORA_TxNeeded() does.
Again: what exactly does that mean? Are you seeing uplinks in the gateway’s Traffic page in TTN Console, but not in the application’s Data page?
Some more thoughts on the downlinks:
If you’re sending on SF11 or SF12, then TTN might prefer RX2 for the downlink, as that uses SF9 and hence reduces the time on air. (When the uplink uses SF11 or SF12, then RX1 would be at SF11 or SF12 as well, but RX2 would use SF9. And as gateways are half-duplex, they cannot listen to any incoming uplink, from any node, while they’re busy sending a downlink to one node. So, to limit the time on air, TTN prefers RX2 in those situations. That’s also why only 10 downlinks per day are allowed.)
As OTAA works, you are sure that the node can actually receive downlinks. (As the OTAA Join Accept is a downlink too.) But while doing OTAA, RX2 still uses the LoRaWAN defaults. Only after the OTAA has succeeded, TTN will use its own specific settings for RX2 for any new downlinks.
So, as OTAA works, maybe the timing is not the problem.
Instead, if all the downlinks are in RX2, and your node always fails to receive those (expect for the Join Accept), then that might indicate that your node is not handling the “CFList” in the OTAA Join Accept, and instead it might still erroneously be expecting the LoRaWAN default. Some options to debug that:
-
Try to make the node use a much better SF, preferably SF7, but at least SF9. This increases the chance that TTN uses RX1 rather than RX2. (And is better than SF12 anyhow.) Put your node outside if the gateway is not your own, to increase the range of the lower SF. If RX1 works but RX2 does not, then the node might not have fully handled the Join Accept response.
-
After a successful join, try to adjust the RX2 settings in code. (I don’t know how. Maybe you can find an example for ABP that does this.)
-
Ask the manufacturer if the CFList in OTAA is supported.
2 Likes
You are right in this.
After a successful join, try to adjust the RX2 settings in code
I have tried, like basically it is on SF12 but after joined I’m changing it to the SF9 but still not able to getting on node, even same SF tried for RX1 too but same problem.
CFList
I saw something like this in my code in same function as you mentioned but I don’t have any idea about this.
You also need to change the frequency. Show us some code?
As an aside: it would be weird to see the handling of the OTAA Join Accept CFList in your code; that should really be handled by the library you’re using. Just seeing some name that looks like CFList does not imply it’s about the OTAA Join Accept.
Okay, that’s all I know; success.
Thanks for your response and valuable time,
Yesterday I’ve tried with new version of I Cube LRWAN i.e 1.2.1 with same configuration as same as my previous code and I’m getting it:thinking:
Don’t know where is the issue,
Now from today I have started to work with ABP but there is a problem while receiving downlink.
My node listen on RX2 with SF9 and 869.525 frequency but won’t get anything.
While it is working properly with local server:smiley: