Hi
I have designed a small board with only a Lora-e5 from seed studio , power supply and an antenna. I got 2 of the boards made exactly the same to compare the communication. I am testing them with a cheap indoor gateway, and the nodes are about 20 feet away from the gateway, sitting next to each other.
I am programming the onboard stm32 that is inside the module, so the circuit is very small, no external processor needed. I took a note of each device ID and added them to TTN, with exactly the same application, and with their own IDs etc. Every 10 seconds a value gets sent from both boards (not exactly the same time). One board transmitted every 10 seconds and I was able to see it on TTN, and the other would sends say 4 10 seconds packets, and miss one (it is sent but not received), then send another 2 and miss the next 3 (its random). If I swap the IDs and reprogram each board with the other IDs, and this time the board that was working as expected had the issues of the second, and the one with the issue was working fine. So I tried with only 1 board only and programmed the chip with one of the device ID, and worked well. I then programmed the chip again with the other ID, and again had the issues. The board position never changed only the IDs. I havent got a clue whats going on. Anyone any idea?
Any request for help that blatantly breaks the FUP is always travelling hopeful. That and the enforcement of the legal limits that the LoRaMAC-node stack will be attempting. If you see blue flashing lights, run …
But this one is so convoluted I think it’s going to take some unravelling. Perhaps an edit to introduce more paragraphs would help along with calling them board A and board B with credentials ɑ and credentials β
Are you using OTAA or ABP? If the latter, how are you managing the frame counter when you restart, nevermind “swap” the ID’s?
What happens if you operate only the “problem ID” with the other device powered off?
What exactly is your gateway? Can you get at raw receipt reports, either via the gateway itself for via the gateway page on TTN, in order to try to distinguish between packets that were never received at all (maybe never transmitted) and those that were received, but rejected by the TTN servers for failing to meet some LoRaWAN requirement?
Also, modify your firmware so that it gives you a definitive UART output when it transmits; though it’s best to do this after the receive windows to avoid breaking their precise timing.
The issue still happens. There is no other board connected. Below is a snapshot from TTN. My software sends constant humidity and temperature values, and also a counter (1 byte) that gets increased. This way I can see all the packets that are sent. Below you can see No.2 packet is missing.
That’s unecessarily redundant, since there’s already the uplink frame count taking space in the headers
As mentioned beforehand, 10 seconds is unacceptably frequent especially on TTN.
And some degree of packet loss is to be expected on shared bands.
But to really debug this, you need to look at the raw gateway traffic and see if the uplinks are being received (only then to be rejected) or perhaps see if traffic from something else is being received.
It would be good to make sure that the node is fairly using all of the available uplink frequencies, and also to have a node’s-eye-view printout of the air settings to make sure that there’s no difference between the successful and failed packets (for example some might use a different spreading factor and bandwidth). Also you want to check that for some goofy reason some aren’t using unallocated channel frequencies.
Since you say that you are reprogramming the device’s MCU, please give details about the exact software you are programming, for example link to the exact git repository state, plus a summary of any and all customizations you’ve made beyond entering the node registration details.
I am fairly new to Lora and still learning, and wont be sending this frequently in the real world. Curiosity , why would this be unacceptable if still within the allowed airtime?
I will have to look into the gateway to see how I can do this. I see the first transmit is SF12, and then goes to SF7 , but cant see what the missing packets are sent unless I see the gateway traffice, which I will take a look at.
Your packet looks like it has a best case, closest to the gateway, air time of circa 60mS. The allowed air time is 30 seconds per day. So at a 10 second interval your allowed 500 of those packets a day. If you send a packet every 10 seconds all day then that would be 8640 packets a day, considerably more than the 500 you would be allowed.
But there is more, if the node were at the limits of reception to the Gateway, the packet air time goes up to 1400mS, so you would only be allowed 21 packets a day, and you could be sending 8640. And then there is the legal limits, at these limits of reception your duty cycle would be 14%, the legal limit is 1%.
If an ACK is not received , is it feesable to resend the packet? And does this count as part of the air time?
I have been looking for the part in the documentation where it explains how to inform the system to send an ack back to the node. I think I seen it someplace, but just cant find it. Anyone pointme to the correct place?
A decent stack will repeat by itself a number of times. And yes, each transmission is included in the airtime calculations (except when not received by a TTN gateway).
HOWEVER you are allowed 10 acks a day at most! So certainly don’t attempt it with the 10 second interval you have been using. Keep in mind a gateway doesn’t receive on any of its 8 channels when transmitting and you understand why it should not be transmitting acks.
Sending ACKs all the time would significantly reduce the receiving capacity of the Gateway.
There is also the issue of legal duty cycle limits applying to transmission of the ACKs. With many nodes requesting ACKs, the duty cylce limit of the Gateway could quickly be reached and if the ACKs cannot (legally) be sent what happens next ?
If you are planning a system that needs conformation ACKs, then you need something else, it sounds like LoRaWAN\TTN is not a good fit for your application…
Im just thinking out loud, as Im new to this and just seeing whats possible. We will use LoRaWAN for projects as we have a few battery projects in mind. But sounds like if its an alarm (important data) to be sent, Lora isnt the best method as the packet might not get through. We do many WiFi/3G/4G projects , and will look at other low power comms for the sending alarms.
