Isn’t it a strange thing when the device is sending an uplink data, it is of a UnconfirmedDataDown type.
Question 1) What does it mean?
Question 2) Also at times I get 2 downlinks for the same uplink message, one of them is ConfirmedDataDown and other is UnconfirmedDataDown? Why there is UnconfirmedDataDown as the MacCommands are sent within the ConfirmedDataDown frame.
The message-type (MType) is part of the PHYPayload, so when the device is sending the wrong MType (or the frame is corrupted) you could see things like this. This will be rejected by LoRa Server as this type is not expected for received frames.
Please refer to the LoRaWAN Specifications for more information on possible MType values and their meaning.
While that’s true, it’s suspicious that it has the same coarse timing as an actual downlink packet.
If clicking into it in detail (or watching the MQTT feed) indicates it has the same (base64 encoded and encrypted) payload as the preceding downlink, I’d suspect something is getting looped back in the gateway somehow.
A while back I was doing some experiments of injecting MQTT downlink packets onto the gateway topic to make one of my gateways transmit on an uplink channel and bandwidth to see if another could hear it, and found that sometimes it would also report receiving that itself. Not quite sure of the pathways, but I could see something like Radio A transmitting on a frequency Radio B is set to, and there being enough leakage around the T/R switch to hear it even though that in theory would be isolating the receivers to protect them from the transmitter output.
Or it could be a purely software loop back due to some sort of bug or glitch.
It would be really interesting to compare the full details of that odd uplink with those of the preceding downlink.
The LoRa packets have inverted I/Q settings for uplink and downlink. This flips the direction of the frequency modulation making the two signals orthogonal.
For the gateway to receive a downlink it would need to purposefully sent incorrectly.
I’ll try making the same case scenario for the odd uplink again, will share detailed paylod over Gateway logs and mqtt topic at the server end. I found it suspicious too as the timing of downlink was similar to that of an actual downink.
Can you share how to make that downlink and send it purposefully?
Is there any mean by which downlink can be sent to a specific device(node) even though the “uplink history” is empty?
All the key details that differentiate node transmissions from gateway ones are encoded in the json of the MQTT message that a LoRaServer - style system uses to command a transmission. You can write your own message to the gateway’s transmit topic and it will be honored, as long as there isn’t a time conflict with one coming from something else, like LoRaServer.
You can encode and command a gateway to transmit a packet with a node’s device address, but without having received an uplink it’s very unlikely that the node will be listening, nor is it clear what frequency or spreading factor you should use. The basic idea is that downlinks are sent in reply to uplinks. Class B and C make things more complicated, but you still have to get coordinated to start…
I store the received uplink history, in a separate database having the frequency, SF/DR, modulation, code rate, fcnt and other relevant details about the history. Also have the gateway-mac from where the last uplink came.
I accidentally reactivated all devices of a particular application. And it’s known that the nodes are still listening and waiting for downlinks.
Now how can I send downlink on purpose to specific node?
Again, for class A nodes without an uplink you practically cannot, because that is not how LoRaWan works.
Unless you have class B or C node behavior, no, they are not listening. They only listen in the receive window right after transmission. You can send a downlink request for a node to LoRaServer, but it won’t be sent over the air until the target node transmits, indicating the tiny slice of following time when it will be receiving.
Otherwise, if you still have the device address and session keys you are free (at least bypassing LoRaServer) to encode and transmit a packet addressed to that device - but it will not hear you, unless it is receiving at the time, frequency, and spreading factor you transmit. And a class A node would not be, unless you are transmitting in direct reply to an uplink.
If you have non-standard node behavior, you can do whatever you want - and the topology of having an MQTT broker in the middle which exposes everything at network as well as application level makes it easy to experiment. But then it is up to you to make the pieces of your scheme work together.
Yes you are right, i understand this will work based on the node behaviour.
I have my devices working on Class-C (it will always be receiving, unless its transmitting), I want to know that “How can i update the received uplink history by the parameters that I have already stored in mysql database?”
How to use those parameters for updating the uplink history and how to make a downlink frame so that it will forwarded to the respective gateway stored in the uplink history.
hello @Yash_Pahwa
can you explain me how you did this? store the history data?
i am also interessted in dooing that? can you give me some ideas?
thx
Hi @sil
The uplink data is stored in redis database. You should refer to the key “lora:ns:device:deveui:gwrx” for the uplink history data.
here in place of deveui you write the MAC address of your device which is of 8 bytes.
hi @Yash_Pahwa
Thank you for your help… i checkt the key “lora:ns:device:devEUI:gwrx”
the get of this key gave me the following result:
“\n\bT\x027\x00\x00\x01\x03\xc0\x10\x05\x1a$\n\b\x00\x80\x00\x00\xa0\x00H\xa7\x10\xb7\xff\xff\xff\xff\xff\xff\xff\xff\x01\x19\x9a\x99\x99\x99\x99\x99#@2\x04\xff\x8e\xa93”
you wrote in a earlier post you have the " frequency, SF/DR, modulation, code rate, fcnt and other relevant details about the history". can you help me to get this information out of this “string”
for example gateway mac should be: 00800000a00048a7
but no idea how to find this
Hey @sil,
I mentioned that I store these parameters in a separate database, I use MySQL for the same, and I get this data from the Uplink HTTP Integration.
You can refer to chirpstack-network-server/internal/storage/device_session.go at master · brocaar/chirpstack-network-server · GitHub
This explains all the parameters stored is redis database.
