Hi, I am doing some test in my BL072Z node because I have to reconfigure it with a downlink, the issue is that sometimes I lose some downlinks, I am retaking a project I had left for some time and as I remember I had no issues with downlinks but maybe I am wrong, I am using a single channel gateway (LoPy4) but I have configured the node to use just one frequency to work (868.1MHz - SF7 and the same parameters are configured in the gateway) and the uplinks work ok, the issue is with the downlinks, in the tests I send a few downlinks (4 or 5) and sometimes all are received but sometimes not, I have to try 4 or 5 times to get it, in the TTN console I can see that the downlink is scheduled and then received in the next uplink but sometimes it is not received by the node, is this an expected behavior or should I be able to always get the downlinks? if this is an expected behavior it means that I should implement a kind of confirmation code to know when a downlink has not been received in the node and re-send it?
The network server will tell the gateway to use one of the official channels, of which you only have one setup - so you have a one in 8 chance - for the first time slot.
More likely is that response will arrive in time for the second slot, which you haven’t got configured.
As well as this causing you problems, you are likely to be causing difficulties for other TTN LoRaWAN devices by using a single channel gateway.
Given the number of gateways that are shown for Madrid, why do you need a gateway that isn’t even vaguely compliant?
Actually it is the node which picks the uplink channel, and where multiple RX1 downlink channels are supported, the one used is dictated by the uplink channel used. If the gateway can only receive uplinks on one channel, then the network sever will only ever try to send RX1 dowlinks through that gateway on the corresponding downlink channel. But there’s no good reason for a single channel abomination to be limited in what frequency it can transmit a downlink on anyway - rather it is limited in what frequency and spreading factor it listens on. Even proper multi-channel concentrator cards used in proper gateways can only transmit on one channel at a given time; they configure the transmitter for the frequency commanded to be used for that particular transmission.
It might be true that transmission for RX2 is not supported, but there is no good reason for it not to be, as a single channel radio is capable of transmitting on any frequency on command. If this were the issue, it would be a trivial software problem. But support of single channel abominations is off-topic here, because as you have correctly observed they are detrimental to the ability of the network to handle other user’s LoRaWAN-compliant nodes.
Ultimately, the fundamental limitations of single channel abominations are in the uplink pathway only. A given example could have implementation errors in the downlink path, but there’s no actual reason it should be any more limited in the downlink direction than a real gateway is. Of course, debugging implementation errors in off-topic devices is off-topic.
This could very well be yet another edge-case timing problem with the node’s RX windows, or mixup with RX2 air settings or similar. But to be on topic, the asker would have to be running tests against a proper gateway, and to provide specific details of the software running on the node.
Ah, understood, never really had to debug the downlinks excepts for an unpleasant session with the Arduino LMIC getting the second channel timing right - will put a copy of the spec in the beach bag for some summer reading.
That entirely depends on what the actual issue is.
Some possibilities are better checked with a known good gateway known to be in range.
Others such as timing or setting errors in your node’s firmware are better check with a gateway you control… even if an imperfect one.
Debuging LoRaWAN issues is quite complex - you need to really understand the software of the node, you need to understand what the network server is doing, and being able to get a log file out of and scope probe onto the gateway’s transmit LED is quite useful, too.
Hi, I thought that get a node and a gateway will help me to understand better what I am doing and I need to show both devices in my presentation, also in the TTN page I saw info about pycom and the LoPy board which I am using as gateway so I thought it would be a device accepted by the server and I did not know what is a single channel gateway
Hi, sorry I had forgotten that I could get access to the single channel gateway terminal, this is the message that shows when a downlink fails:
Downlink timestamp error!
I will ask to Pycom what could be the reason for this and I suspect that could be the firmware update of the gateway but if you have a clue please let me know, thanks
Good plan, best to split it in to two parts - get node working and explore its options. And then complicate your life by adding in a gateway.
You are on your own here with a single channel gateway as they are very detrimental to this community.
If you like the Pycom products, they are actually bringing out a low cost 8 channel gateway, shipping this month (apparently). If you buy a first release one, please consider that you may well be debugging it as much as using it!
@cslorabox I have been doing some tests and I have got this from the TTN terminal and single channel nano gateway:
first case: downlink OK
Nano gateway: downlink received after an uplink send at 23:37:56.62773Z
TTN console: downlink sent at 23:37:56.653Z
second case: downlink timestamp error
Nano gateway: downlink error, uplink send at 23:49:20.811927Z
TTN console: downlink sent at 23:49:21.302Z
And this pattern is constant in every test, a downlink is successful when the uplink time and downlink time are almost the same but if the time between uplink and downlink is near 1 second then I got the timestamp error, is this an error caused by TTN for not deliver the downlink at right time or the issue is the gateway because the rx window is very restrictive?, I read that the rx window 1 should open 1 second after the uplink is sent but it appears that this gateway doesn’t wait this time
For an ordinary RX1 downlink (ordinary traffic not join) the received signal report has to get up to the server, be processed, and a reply generated and sent back to the gateway before a second has elapsed. Otherwise, there’s no way the gateway can transmit it in time for the node to receive a packet which starts exactly one second after the uplink packet ends.
This could fail due to any of network delays, server delays, or gateway software delays, in either direction.
It could also falsely appear to fail due to gateway software bugs. It is “interesting” that your failure cases are very near the rollover of a 32-bit unsigned integer. That rollover is expected, but some mistake in the code such as mixing up signed/unsigned math could cause a problem.
It’s worth noting in one of your logs that there’s a huge time gap between the push ack and the pull ack. This suggests that the backhaul network protocol might not be implemented or working correctly. Such a problem is fixable, but you’re not going to find support here for digging into the internals of code that this community has concluded is code that should not exist.
