Hi
I set up a Dragino LG01 with latest firmware and MCU sw, and I also have a RAK831 gateway running in the same house.
What I see is that all msgs from my nodes which are sent on the channel the Dragino is listening to, are presented duplicate as two separate messages (one from each gateway). Most likely because the dragino seems to forward them with a 5-7 (!) second delay.
I know that dragino has a MCU in between lora chip and main processor, however that cannot be the reason it takes up to 7 seconds to pass a lora msg???
I also did not find how to get detailed debug what is going on in the mcu when a packet is received. When I ssh to the Dragino and telnet to localhost:6571, the only msgs I receive are:
END A PACKET, Mode:0
You should probably report that as an issue to Dragino.
It’s likely to receive fairly little help here, given that trying to use node class radios as gateway is known not to be compatible with proper LoRaWAN node behavior in the first place, an additional timing issue only turns a bad idea into a worse one.
Note additionally that if the box does not support downlinks (unsure if it does), then uplink latency is mostly irrelevant, since the reason uplink latency is bad is that it means that the downlink window could pass before a reply could be generated, assigned to the gateway, and transmitted.
I know that dragino has a MCU in between lora chip and main processor
I could be wrong but that was not my impression, ironically the compute-side architecture of Dragino’s abominations seems to have a lot of hardware and software commonality with their actual gateways, which is part of why they are so absurdly expensive for what little functionality you get - there are actual gateways selling at comparable prices. If someone’s finances limit them to starting with single channel approximations, rather than spend their money on an expensive box that is not a gateway, they should just hang a cheap node off a PC or pi to try fill that role as best it can and then turn back into a node when their “gateway fund” reaches the point of being able to fund an actual gateway.
are presented duplicate as two separate messages (one from each gateway)
Presumably you have the frame counter disabled on the network side?
Ordinarily a tardy repeat of a message should be ignored, because the frame counter would be less than expected after the first copy of the packet increments the expectation. Thus it would be dropped as a possible replay attack. The only reason a late message should valid decode is if you have this protection disabled, or if that message has not yet been reported in by another gateway and no subsequent message has either, in which case it is not actually a duplicate, but new information previously unavailable to the network (even if arriving too late to reply to)
thanks for that counter idea, its a problem in my application, currently my experimental node is reset by an external watchdog every send interval, which resets the counter, I will improve that so the lmic stack can increment the counter accordingly, then it should work.
Yes, if I knew before that it is a simple single channel forwarder, I wouldn’t have bought it for that money, since I can easily do the same with a cheap esp32+rfm95.
However I asked dragino about the delay and will report what they reply.
I have Dragino lg01(eui-a840411cce40ffff) and The Things Indoor Gateway(eui-58a0cbfffe800c47) and data sending node in same room …
Dragino is so slow …sometimes data goes second, sometimes 5, sometimes 10… and lots of times lost…) …
Things Indoor Gateway works perfectly
why so?
results that goes to server are :
columns : timestamp data gateway
I will improve that so the lmic stack can increment the counter accordingly, then it should work.
Do do that, or at least something to maintain state, which is a lot more than just the uplink frame count.
Dragino is so slow …sometimes data goes second, sometimes 5, sometimes 10… and lots of times lost…) …
Things Indoor Gateway works perfectly
Given you have another gateway, why don’t you just unplug the Dragino fakeway?
Or if you are having reliability problems, just tolerate the late duplicates. Given that LoRaWAN isn’t reliable to begin with, you can’t really do an analysis (for anything other than a reliability metric) of the data that takes its frequency of arrival into account. If your node is only supposed to transmit infrequently, you can just ignore some value duplicates that are “too closely spaced” in time.
The Dragino is just a simple packet forwarder, its not a proper TTN Gateway, its an end of line product and not recommended for new users (according to Dragino).
There are many threads on that here. Generally most with an actual 8-channel concentrator card are decent though a few have unique issues - for the example your TTIG seems to have some well chronicled bugs and rather uniquely, closed source software which means that anyone who wanted to fix them would have to recreate large parts of the needed software from scratch.