Frame counter counts by 3?

hello everyone…
I have built a single channel packet forwarder (Raspberry pi) and the end-node ( Arduino UNO ) and dragino shield. after receiving the payloads I noticed that the frame counter count by 3 I don’t know why and how to fix it …
please help1

These cannot properly work with a LoRaWAN network such as TTN. The issues they cause are not only for you, but for other users nearby whose nodes can be lead astray but non-functional things pretending to be gateways when they actually are not - this can cause nodes to adjust to proximity to your non-gateway, and start failing to reach more distant actual gateways.

Most likely your node assumes it is dealing with a real gateway, and is cycling through a list of frequencies only one of which your non-gateway can receive. Or it is using multiple spreading factors only one of which can be received.

Use a real gateway.

Otherwise you’d have to hack your node to use only the settings supported by your non-gateway. There were discussion about this here in the past which you can find with a search, but as these devices can never work correctly, they are not supported on this forum now.

2 Likes

Dear cslorabox thanks for the replay … I search a lot but unfortunately, I didn’t find it.
its undelivered messages, and can I suppose it like ( dropped packets ) cause it’s not delivered in my case.
I just want to use it for a research purpose
thanks for your efforts.

From the frame counter, you appear to be sending a packet approximatly every 12 seconds ?

If that is so you will reach the daily fair access limit in a best case scenario (close to the Gateway) in 111 minutes and in a worst case scenario (long distance from the Gateway) in 5 minutes.

So perhaps dont use a 12 second interval for long periods.

yes , you are right I will change it. I just want to operate the technology thanks for your notes

thanks for the response .
the problem there is no other gateway around in my region to send the messages and i must change the lmic library (that i used ) to fix the problem which i have no idea how to fix till now .any suggestion please
i will discover how to disable all the channels and see do you recommend that ?
thanks for the efforts

You cannot be sure of that as if there are GW’s but just marked as private/not public on the TTN console they may not/will not show up on the TTN Map - you will potentially cause problems for anyone using those other GW’s. Also, generally, consider a situation (good line of sght) where there is a GW say 20km away from you and a node is operating between your GW(sorry Single Channel Packet Forwarder!) and the other at say 13km from the full GW and just 7km from yours. The Node may have been happily working (at a stretch on likley on a high SF) with the full GW. Your SCPF comes online and suddenly appears to pick up some packets on a stronger signal and likley on a lower SF. The back end will then switch to sending any downloads (Join Accepts, ADR related MAC/config commands, Conf msgs etc.) via your GW even if not able to fully handle as the NS will not know that you dont have a full LoRaWAN compliant GW installed and will effectively ignore the previously used GW for supporting the node…thats where problems start…

as cslorabox stated:

2 Likes