Downlink Data being received on Port 0, resulting in invalid MAC Command errors.

[Ajay K]

Prior to the latest MDot API and the latest conduit firmware, the downlink data was never received over port 0 and I was told explicitly to ignore any packets that are received over port 0 in the custom firmware we have written for the mDot. Also I use the async send operation, and I have subscribed to receive MacEvent to look for downlink data. However since both Mac commands and the custom downlink data is being received over Port 0 we are facing the issues as described below. We end up ignoring the downlink data since its being received on port 0 and the mDot API flags errors indicating the mac command is invalid, since its downlink data. Is there a new configuration step either on the conduit or the mDot API that needs to be done to ensure the downlink packets are not received on port 0?

Here is the log that is being logged in full trace mode.

12/21/2018 11:52:17 AM: [DEBUG] Max Packet Frame Length: 242
12/21/2018 11:52:17 AM: [TRACE] Waiting to Send Packets…..
12/21/2018 11:52:17 AM: [TRACE] Can Send Packets…..
12/21/2018 11:52:17 AM: [TRACE] Sending LORA Packets.
12/21/2018 11:52:17 AM: [DEBUG] Send with tx timeout 20000
12/21/2018 11:52:17 AM: [INFO] Preparing frame
12/21/2018 11:52:17 AM: [DEBUG] ADR ACK CNT: 1 LIMIT: 64 DELAY: 32
12/21/2018 11:52:17 AM: [TRACE] NA: 00fcbb03
12/21/2018 11:52:17 AM: [TRACE] NSK: 14567bcc09d35ea371a4066d545fab2d
12/21/2018 11:52:17 AM: [TRACE] DSK: f4ae2044c8661741e0e5bbc744f78d33
12/21/2018 11:52:17 AM: [TRACE] Adding MIC to frame
12/21/2018 11:52:17 AM: [TRACE] Sending 15 bytes
12/21/2018 11:52:17 AM: [TRACE] Number of available channels: 8
12/21/2018 11:52:17 AM: [DEBUG] Using channel 31 : 908500000
12/21/2018 11:52:17 AM: [INFO] Configure radio for TX
12/21/2018 11:52:17 AM: [DEBUG] Session pwr: 10 ant: 3 max: 21
12/21/2018 11:52:17 AM: [DEBUG] Radio Power index: 9 output: 10 total: 13
12/21/2018 11:52:17 AM: [DEBUG] TX PWR: 9 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
12/21/2018 11:52:17 AM: [INFO] Configure radio for TX
12/21/2018 11:52:17 AM: [DEBUG] Session pwr: 10 ant: 3 max: 21
12/21/2018 11:52:17 AM: [DEBUG] Radio Power index: 9 output: 10 total: 13
12/21/2018 11:52:17 AM: [DEBUG] TX PWR: 9 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
12/21/2018 11:52:17 AM: [DEBUG] mDotEvent – TxStart
12/21/2018 11:52:17 AM: [DEBUG] mDotEvent – TxDone
12/21/2018 11:52:17 AM: [TRACE] Event: OK
12/21/2018 11:52:17 AM: [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
12/21/2018 11:52:17 AM: [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
12/21/2018 11:52:18 AM: [INFO] Rx Window 1
12/21/2018 11:52:18 AM: [INFO] RxDone 15 bytes RSSI: -38 dB SNR: 67 cB
12/21/2018 11:52:18 AM: [TRACE] Payload: a003bbfc0020320000c7e5d9d6437e
12/21/2018 11:52:18 AM: [INFO] Packet for 00fcbb03
12/21/2018 11:52:18 AM: [TRACE] Check downlink counter 00000032
12/21/2018 11:52:18 AM: [TRACE] Ack received
12/21/2018 11:52:18 AM: [INFO] Packet Received : Port: 0 FCnt: 00000032 Size: 2 ACK: 1 DUP: 0

12/21/2018 11:52:18 AM: [DEBUG] mac commands in payload
12/21/2018 11:52:18 AM: [TRACE] CMDS: 1001
12/21/2018 11:52:18 AM: [DEBUG] Mac command index: 0 cmd: 0x10
12/21/2018 11:52:18 AM: [DEBUG] Unknown MAC command index: 255 cmd: 0x10
12/21/2018 11:52:18 AM: [DEBUG] mDotEvent – PacketRx ADDR: 00fcbb03
12/21/2018 11:52:18 AM: [TRACE] Payload: 1001
12/21/2018 11:52:18 AM: [TRACE] Event: OK

12/21/2018 11:52:18 AM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 1 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
12/21/2018 11:52:18 AM: [TRACE] Info: Status: 0 ACK: 1 Retries: 1 TxDR: 3 RxPort: 0 RxSize: 2 RSSI: -38 SNR: 67 Energy: 0 Margin: 0 Gateways: 0
12/21/2018 11:52:18 AM: [DEBUG] Rx 2 bytes
12/21/2018 11:52:18 AM: [INFO] Packet RSSI: -38 dB SNR: 67 cB
12/21/2018 11:52:18 AM: [DEBUG] mDotEvent – RxDone
12/21/2018 11:52:18 AM: [TRACE] Uplink Transmission Complete!

12/21/2018 11:52:18 AM: [INFO] RxDone 15 bytes RSSI: -38 dB SNR: 67 cB
12/21/2018 11:52:18 AM: [TRACE] Payload: a003bbfc0020320000c7e5d9d6437e
12/21/2018 11:52:18 AM: [INFO] Packet for 00fcbb03
12/21/2018 11:52:18 AM: [TRACE] Check downlink counter 00000032
12/21/2018 11:52:18 AM: [TRACE] Ack received
12/21/2018 11:52:18 AM: [INFO] Packet Received : Port: 0 FCnt: 00000032 Size: 2 ACK: 1 DUP: 0
12/21/2018 11:52:18 AM: [DEBUG] mac commands in payload
12/21/2018 11:52:18 AM: [TRACE] CMDS: 1001
12/21/2018 11:52:18 AM: [DEBUG] Mac command index: 0 cmd: 0x10
12/21/2018 11:52:18 AM: [DEBUG] Unknown MAC command index: 255 cmd: 0x10
12/21/2018 11:52:18 AM: [DEBUG] mDotEvent – PacketRx ADDR: 00fcbb03
12/21/2018 11:52:18 AM: [TRACE] Payload: 1001
12/21/2018 11:52:18 AM: [TRACE] Event: OK
12/21/2018 11:52:18 AM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 1 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
12/21/2018 11:52:18 AM: [TRACE] Info: Status: 0 ACK: 1 Retries: 1 TxDR: 3 RxPort: 0 RxSize: 2 RSSI: -38 SNR: 67 Energy: 0 Margin: 0 Gateways: 0
12/21/2018 11:52:18 AM: [DEBUG] Rx 2 bytes
12/21/2018 11:52:18 AM: [INFO] Packet RSSI: -38 dB SNR: 67 cB
12/21/2018 11:52:18 AM: [DEBUG] mDotEvent – RxDone

Thanks,
Ajay

[Ryan Klaassen]

The mDot receives on all ports. Port 0 is reserved for mac cmds only. Other ports such as 224 is dedicated to LoRaWAN Mac layer test protocol.

There are ways on the conduit to set the downlink port. What are you using to send lora packets on the conduit?

[Ajay K]

We have written a custom app that subscribes to the MQTT broker to receive and send messages from and to the radio nodes. This hasn’t changed since we have been using the conduit for a while now. Only after we upgraded the Conduit firmware to 1.6.2 did we start seeing the downlink packets being sent over Port 0.

Thanks,
Ajay.

[Ryan Klaassen]

you can specify a port using MQTT ex:
snprintf(payload, sizeof(payload), "{\"data\":\"%s\",\"ack\":false,\"port\":%u}", buf, 1);

then publish

mq.publish(NULL, topic, (int)strlen(payload), (void*)payload, MQTT_QOS_1)

[Ajay K]

Thanks Ryan for taking the time to respond and providing an example. I am guessing what you have written is using c++ version of the mqtt api. The custom app we have written is built on node.js and we use the mqtt node js library which is also used by the node-red application. Does this node.js version of the mqtt library also have the same api that you have described above?

Also what has changed in the conduit, that all of a sudden it’s also transmitting downlink data over port 0? Is this a bug since I didn’t have to ever control the port# in the previous versions of the conduit firmware?

Thanks,
Ajay

[Ajay K]

Thanks Ryan, I figured out how to do it using node.js in the custom app.

However my original question still remains, is this a new requirement to specify a port#, since if we don’t set it in the custom app, the new conduit firmware could pick port 0. Is this a bug, that needs to be fixed? Since the radio node mDot API would end up throwing an error while attempting to parse the downlink payload as a MAC command and this would result in unnecessary errors. So it would be ideal if we don’t have to pick a port and the conduit assigns a port since the conduit firmware understands which ports are reserved and which are not.

So in the future if for some reason port# 1 is reserved for example then all the customers using this port# to transmit data have to change their custom code to not use port# 1, as I have done to fix this issue.

Thanks,
Ajay

[Jason Reiss]

The default port for a downlink should be 1 if “port” is not provided in the JSON.

What is the JSON provided to the network server when queuing a downlink?

[Ajay K]

Hi Jason,

Thanks for the information. It is not defaulting to “1”, at least not with the latest conduit firmware version we are using.

Here is the code that we use to send the downlink packet. The appSettings.downlinkAppPort configuration setting we use is currently a blank string and this has worked previously on the earlier versions of the conduit firmware.

var eui = arrLoraDownlinkPackets[0].eui;
var payload = arrLoraDownlinkPackets[0].dataPacket;

var msg = { data: new Buffer(payload).toString("base64"), ack: 
      appSettings.downlinkAckRequired, port: appSettings.downlinkAppPort };

mqttClient.publish('lora/' + eui + '/down', JSON.stringify(msg));

Let me know if you have any questions or concerns regarding the way the port value is being set in the code above?

Thanks,
Ajay.

[Jason Reiss]

Expected type for port is an int.

[Ajay K]

Hi Jason,

So would it be okay if pass as json object such as this one below or should we not set the JSON property “port” in the json object? Which method below would default the port to 1?

var msg = {data: new Buffer(payload).toString("base64"), ack:1, port:}

or

var msg = {data: new Buffer(payload).toString("base64"), ack:1}

Thanks,
Ajay

[Jason Reiss]

Did you find that one of your proposed solutions works?

[Author]

Posts