I’ve been trying to send pakets from a node operating in class A to another one in class C (which suppose to be listining most of the time), I have tried the following:
I have set the class A node to send using the Rx2 freq, and Dr and the class C node failed to receive anything
I also tried to set the Rx2 parameters in the class C device to match the normal freq in the other node, but it also failed
Any ideas please on how to set a node in class C to receive anything from another node? not a gateway.
Really appreciate your support…
Thanks @cstratton for your quick response,
you sre absolutely right, but I’m just trying to understand how class C works,
I can’t get the node in class C to receive anything within the second receive window, even when I set everything to default and sent a packet from the server, it fails to get to the node.
within the nodes code, I have inserted a print message at the begining of the function “OnRadioRxDone( )”.
Thus far, the message is only printed when the node receives within the first receive window.
Also on the server side, when I go to the Live Device Data in the device page, I can see the packets I sent from the server as Ack. so does that means the packets are getting to the node but this function is only called when something is recieved at the Rx1?
I’m really confused and will appreciate any help from you guys…
It is not about receiving during RX2, rather it is about having the radio receiving with the air settings of RX2, all of the time except when it needs to be transmitting or briefly listening for something else (like RX1, etc).
Also it is not clear that your gateway is actually transmitting any class C downlinks…
when I go to the Live Device Data in the device page, I can see the packets I sent from the server as Ack.
when I issue the following command from the server:
mosquitto_pub -h localhost -t “application/2/device/1111111111111111/tx” -u user -P user -m ‘{“reference”: “abcd”, “confirmed”: false, “fPort”:7, “data”: “aGVsbG8=”}’
at the gateway it shows up as “UnconfirmedDataDown” and nothing shows up at the device page. However when I change the “confimed” into “true” it will show up as “ConfirmedDataDown” at the gateway and as “Ack” at the device Live Device Data page.
Bottom line, if I want to send a message to the device operating in class C during the listening time (Rx2), what configuration should I use please?
It should not matter, that should only govern if the node transmits an acknowledgement in return, but that can only happen after the packet is received by the node.
It’s a bit odd if an original downlink message is being displayed as an ACK, because it isn’t one.
But the immediate question is if the gateway is actually transmitting or not, and then if the node is not receiving, if the node was actually attempting to receive at that time, and if the settings the node was receiving with (frequency, bandwidth, spreading factor, IQ inversion, etc match those the gateway transmitted with).
Since you are interfacing with the MQTT, monitor the gateway/xxxx/tx channel too and see if a packet send command is issued after your application downlink command…
Note that you have to look into the content of the ack message as it could be either true or false!
@Norman With regards to now seeing the downlink under the device data tab, it only shows the communication from the device to the application (the data that your MQTT subscriber or application integration would receive). If you want to see the downlinks being scheduled, see the LoRaWAN frames tab.
As for the receiving parameters (frequency, bandwidth, spreading factor, IQ inversion, etc) it should be matched between the gateway and the node as I haven’t change them. (using the default)
@brocaar the packet sent from the server, at the device in the Live Lorawan Frames page it shows as “ConfimedDataDown” and within that packet the “ack: false”
and in the Live Device Data page it shows as “ack” again with the “acknowledged: false”
I just want to know how to receive a packet within Rx2 in class C node?
Rather than making assumptions, I would want to see the actual air settings either from the MQTT gateway/…/tx message or from the packet forwarder logs
And I’d like to see a printout from the node firmware that it sets the radio to those settings and was attempting to receive during that same timeframe.
Also evidence from the packet forwarder syslog that it actually transmitted.
Do I know that any of those things are the issue? No, but so far you’ve provided no information which can actually rule them out.