[Jason Reiss]

Are you using the default network server version 1.0.8 in mlinux 3.2.0?

Or did you update to latest packages in both conduits and only see issues with 3.3.12?

What is the distance between gw and node?
What datarate is used?

[Jason Reiss]

Does your node enable CRC for downlink packets? It should not be enabled.

The network server has changed to send downlinks without CRC enabled per Lorawan in version 1.0.26.

[Jason Reiss]

In network server mode a packet forwarder is still used to communicate with the MTAC-LORA card. The packet forwarder is configured to send packets to localhost.

The network server will build a global_conf.json file. The look-up-table (LUT) values in the global_conf.json must match to the installed hardware (MTAC-LORA) version.

[Jason Reiss]

LoRa

[Jason Reiss]

Those should be compatible. You can use a lorawan stack to connect to network server on Conduit. Or handle raw lora packets using packet forwarder depending on your use case.

[Jason Reiss]

The 900 Mhz version would be needed along with a MTAC LoRa card for Conduit.

[Jason Reiss]

The xdot dev libraries have support for multicast sessions. 3 addresses and keys can be registered for downlink.

Event handlers can be set to receive packets for normal and multicast packet with DevAddr.

A method to exchange keys can happen at the application layer.

A protocol for exchanging keys is being developed.

[Jason Reiss]

Lorawan 1.0 join nonce is a random value. I would look at how the RNG is seeded in the stack. Its possible for the same seed being used on reboot causing the same nonce to be generated.

[Jason Reiss]

The sample app at the bottom of this page can get lora packets from MQTT same as node-red does. Python and C++ also have mqtt libraries.

Conduit mLinux: LoRa Communication

[Jason Reiss]

I would use node.js application and skip node-red for your interface.
Python or c++ could also be used.

[Jason Reiss]

The /opt/lora/basic_pkt_fwd file will only connect to a USB card

The /opt/lora/lora_pkt_fwd is needed for SPI cards. This package is also available on downloads or through opkg

Latest mlinux is 3.3.15, you can update the feed url in this file

$ vi /etc/opkg/mlinux-feed.conf

$ opkg update
$ opkg install lora-packet-forwarder

[Jason Reiss]

To stop the network server from sending the first downlink, clear the queue on joined event or when the first uplink is received. Then queue your downlink packet.

Send MQTT message with topic
lora/<DEV-EUI>/clear

• This reply was modified 7 years, 5 months ago by Jason Reiss.
• This reply was modified 7 years, 5 months ago by Jason Reiss.

[Jason Reiss]

Looks like your module may have 4Mb flash?

http://cdn.lairdtech.com/home/brandworld/files/Guide%2520-%2520smartBASIC%2520Extensions%2520-%2520RM1xx.pdf

[Jason Reiss]

Upgrade your lora network server from dowloads page at least.

Best to upgrade mlinux as well.

[Jason Reiss]

How often does the device need to join? Is the session info being saved?

[Jason Reiss]

Did you configure the gateway and device for public mode?

[Jason Reiss]

Data queued for downlink will need to wait for next packet.
The first downlink is sent on port 0 with payload of MAC commands.

[Jason Reiss]

The first downlink contains MAC commands to setup additional channels or the channel mask.

[Jason Reiss]

The scheduling conflict occurred after an uplink was received.

8:15:2:233|INFO| GW:00:80:00:00:a0:00:03:89|FRAME-RX|Parsing 1 packets
8:15:2:234|DEBUG| GW:00:80:00:00:a0:00:03:89|FRAME-RX|DATA: 408400000680f903029cceb0b4e1f4a8a91ed860eb04bc
8:15:2:234|DEBUG| GW:00:80:00:00:a0:00:03:89|FRAME-RX|FREQ: 903.700000 MHz DR0 RSSI: -111 dB SNR: 25 cB
8:15:2:234|DEBUG| GW:00:80:00:00:a0:00:03:89|FRAME-RX|TYPE: Unconfirmed Up
8:15:2:235|DEBUG| GW:00:80:00:00:a0:00:03:89|PACKET-RX|ADDR: 06:00:00:84 FCnt:03f9

Without uplink traffic the class C packets would have been scheduled without conflict.

[Jason Reiss]

Please open a case at support.multitech.com to resolve this issue.

[Jason Reiss]

Mlinux ipk is here, do not install on AEP
http://www.multitech.net/mlinux/feeds/3.3.15/arm926ejste/

For AEP the binary file could be extracted and copied to /opt/lora

We’ll get ipk downloads available shortly.

[Jason Reiss]

1. Looks like current release does not allow update of uplink or downlink counter through commands. Only way currently is for device to send at least two uplinks after joining.

4. US uses 500k channels for downlinks. DR8-DR12 in the LW spec.
Each uplink will schedule two rx slots for possible downlinks. If a downlink does not use the slot another may use it.

5 b.) The packets will be queued for each node immediately, then they will be transmitted by cycling through the node list and transmitting a packet to each one. So i would not expect 6 to the first, then 6 to the second, but 1 to the first, 1 to the second,…

[Jason Reiss]

LoRaWAN defines join back-off with tx duty-cycle of 1% of 1 hour, 0.1% for 1-11 hours and 0.01% beyond 11 hours.

After the 36 seconds of time on air is used it will wait for the rest of the time period until trying again. This is in case large number of devices are power cycled and trying to join simultaneously.

[Jason Reiss]

The payload is binary not ascii. The arg -d is need for base64 decoding.

echo ADUN9ZDRz4IuE9sAAAAAgAA6/FmEmlQ= | base64 -d | hexdump -e ‘/1 “%02x”‘
00350df590d1cf822e13db0000000080003afc59849a54

This specific lorawan decoder is helpful for the packet_recv and packet_sent data.
https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/

Or in node.js
new Buffer("ADUN9ZDRz4IuE9sAAAAAgAA6/FmEmlQ=", "base64").toString("hex")

• This reply was modified 7 years, 5 months ago by Jason Reiss.

[Jason Reiss]

Thomas,

Thanks for the specific questions. I have a few questions about your setup.

How many nodes are registered?
Do they join via OTA or ABP?
Is most traffic meant to be downlink? Is any uplink?

1. The network server will need to know the node is available. After an OTA join the device should send an uplink to confirm it has received the Join Response. Or if the device has been registered the network does not know if it has been powered on until an uplink. It may be possible work around by incrementing the uplink counter to 1.
Also in a larger network it may be necessary for the device to send a periodic uplink so the network knows what gateways are available to reach the device.

2. The us time is from the internal clock of the gw card

3. The values are ms time from start of process used for scheduling downlink packets and avoid collisions.

4. Cannot increase duration mean a packet was scheduled but the payload cannot be added in the available downlink slot. The payload will wait in the queue until a downlink slot is found.

5. a.) A devices are Class A, when an uplink is received the Rx1 Slot can be used for downlink. Class C is additional behavior beyond Class A, it has Rx2 open always. Class A operation is the default behavior of all LoRaWAN end-devices. When the device is registered as Class C the downlinks are scheduled for Rx1 or after the close of Rx1, when an uplink is received.

b.) Scheduling conflict means two transmissions want to use the same time. Only one can be transmitted. Some guard time is added in scheduling, we will have this timing tightened in a coming release. It should reduce conflicts.

6. The payload has been unscheduled to be sent at a later time.

[Jason Reiss]

Login should not be needed to access the directory. Try anonymous.

[Jason Reiss]

Feature is coming soon. Release date has not been finalized.

[Jason Reiss]

Commands can only be sent from application using port 0. They cannot be queued into the fopts.

[Jason Reiss]

The RxDone event should occur on any packet received. Valid or invalid.

The packet has not been processed so the counter is in the payload buffer.

You could compare the devaddr and counter in the received packet with the current counter.

[Jason Reiss]

Security reasons. Reuse of counters gives an attack surface for attempting to gain the session keys by analysis of intercepted packets.

[Author]

Posts