[Jason Reiss]

There is a bug in the lora network server, it is looking for the following configuration item, “maxDatarateEU”.
Add the configuration with this URL or use curl

URL:
https://192.168.2.1/api/loraNetwork?method=PUT&data={"lora":{"maxDatarateEU":0}}&apply=now

Command Line:

> curl 127.0.0.1/api/loraNetwork -X PUT --data '{"lora":{"maxDatarateEU":0}}' -H "Content-Type: application/json"
> /etc/init.d/lora-network-server restart

• This reply was modified 8 years, 4 months ago by Jason Reiss.
• This reply was modified 8 years, 4 months ago by Jason Reiss.

[Jason Reiss]

Lawrence,

1. Yes, two packets on the same frequency using different spreading factors can be received simultaneously.

2. When two packets collide, using same frequency/spreading factor, there may be enough signal to receive the stronger one. The weaker signal will just be noise.

[Jason Reiss]

SF12 is the slowest datarate, most redundancy, longest range.
SF7 is the fastest datarate, least redundancy, shortest range.

What are you looking to increase, datarate or range?

Use the min/max datarate settings to tweak the allowed datarates.

0:SF12BW125
1:SF11BW125
2:SF10BW125
3:SF9BW125
4:SF8BW125
5:SF7BW125
6:SF7BW250
7:FSK

[Jason Reiss]

The network server db is saved in the config partition which can be backed up via Save Config into a tar ball.
When this archive is loaded onto a new Conduit it should act the same as the old one.

Of course you would have to backup the Config after all devices have joined. And depending on the length of time the devices have been running the counters may not be able to rsync without the devices have to re-join.

It is a better practice to have the device be able to detect the loss of network session and re-join.

[Jason Reiss]

This issue is a result of the shared AppKey on all devices.
This key is used to authenticate the Join Accept message. When the devices join at the same time, they will also open RX windows at the same time allow some of the devices to receive the Join Accept messages destined for another device/DevEUI.

However, in the join request is a random 2-byte nonce value sent from the device. This value must be known on the device in order to create a valid session key. The RNG is seeded from an rssi reading on start-up.

Since they all share the same AppKey they will also verify the Join Accept message and and create a session. But only if the device nonce values match on two devices will a valid session be created.

Since the devices have accepted the same session info they will report with the same network address. This may cause an event to be marked with the DevEUI of another device but the message can only be authenticated if the session keys match.

Do you have ACK enabled on the devices?
How are you monitoring the messages coming into the Conduit, mqtt “up” or “packet_recv” event?

If I attempt to join with multiple devices simultaneously I can get both to join and they are assigned the same NetAddr. However the session keys differ because of the nonce values, therefore only one has a valid session. When either device sends a packet only the “packet_recv” event was seen on the Conduit for both devices. The “up” event only happened for the authenticated device with the correct session key.

A packet sent after the join requiring a downlink with ACK or network link check would allow the device to check if it has a valid session. If a response from the network is not received then the device should attempt the join again.

Another option is to use unique keys for each device. The lora-query utility can be used to register devices with the network server.

LoRa Network Server

[Jason Reiss]

Configuring the max datarate in the gui to 0 will keep ADR from increasing the datarate.

It will also keep ADR from increasing the datarate.

[Jason Reiss]

http://stackoverflow.com/questions/6025445/how-likely-are-two-blocks-of-data-likely-to-produce-the-same-crc64-value

[Jason Reiss]

Can you post examples of what you tried?

The packets will be queued until an uplink from the node.
Then it will be sent down in an RX window.

If you connect a lora-in node to lora-out then the sensor should receive in response the payload it sends. Is there any way you could test out this functionality?

[Jason Reiss]

libmpsse and libc6 packages can be found in the feed.

http://www.multitech.net/mlinux/feeds/3.2/arm926ejste/

[Jason Reiss]

Thanks for the update. Glad you were able to find some answers.

[Jason Reiss]

I would be interested to see where you are quoting from. That behavior is not supported. A msg will always need an eui to identify the destination.

Multicast is not explicitly supported.

The packet will be received by all Class C devices. But it will be filtered by the network address.

For multicast to work all devices would need to share a network address and set of session key to verify and decrypt the payload.
The mechanism to share the address and keys does not exist.

[Jason Reiss]

The device is sending data without incrementing the sequence number.
The duplicate packets do not generate “up” mqtt messages.

… Seq# 1 ADR enabled
…
… Seq# 1 ADR enabled

SeqNo: bee27ba0 PrevSeqNo: 00000001 Duplicate: yes

bee27ba0 is uninitialized data and can be ignored

The empty packets on port 0 maybe the ADR MAC commands

[Jason Reiss]

Can you upgrade the unit to 1.3.2?

Otherwise the “test” collection would need to be added to /var/config/db.json “loraNetwork” collection manually and restart the unit.
Then the API can set it.

[Jason Reiss]

Shankar,

In what region are you operating?

A assume the slow device that is restarted is the Conduit and not the lora nodes.

If you using EU868 then then the duty-cycle is also a factor in scheduling downlinks. In the latest versions of AEP you could try to disable the duty-cycle as a test to see if behavior changes. Also the duty-cycle is implemented as a sliding window, time-on-air starts at 0 and is accumulated until a transmission uses it.

CRC errors can be caused by environment or other devices (including distant LORA devices) using the ISM band.
Multipath effects and reflections may also appear on adjacent channels when devices are used in close proximity to the gateway.

[Jason Reiss]

If you direct the output of the lora-in node to a debug node and configure the debug node to show the complete object you will see a correctly formatted packet that is sent as an echo.

Only the eui and data/payload are required for downlink.

A class C device needs to be configured on the network server independently. There is currently not a message the device can send to signal that it is Class C.

LoRa Network Server

[Jason Reiss]

Multicast is not explicitly supported.

The packet will be received by all Class C devices. But it will be filtered by the network address.

AT+SEND is only needed for Class A device to receive.
In Class C AT+RECV will show the last received packet.
However there is not a notification of packet received with the AT Firmware. The AT+DLC can be monitored to see the Frame Counter of the last packet.

A custom firmware using the library can register an event class to handle packets when they are received. It can also receive packets that have been filtered out by the network address, however they will still be encrypted.

[Jason Reiss]

A downlink packet is addressed to a device by the DevEUI.
An uplink from one device can be routed to another by changing the msg.eui field of the packet.

To use the updated firmware you dot needs to be reconfigured for the AU915 band.

Load the following firmware and issue these commands:

AT+FREQ=AU915
AT&WP

http://multitech.net/downloads/mdot-firmware-Set-DevID-FrequencyBand-2.0.16.bin

Then load the normal 2.0.16 firmware.

[Jason Reiss]

Conduit mLinux: Convert to Basic Packet Forwarder

[Jason Reiss]

As long as the lease does not expire the configuration on Conduit will be maintained.

The device can be pre-registered prior to first join if desired.

[Jason Reiss]

Private mode on mDot and Conduit has a difference in downlink frequencies that are not LoraWAN compatible.

Introduction to LoRa

There is not a configuration to do this. But a work around is possible.
Configure the network server for Public mode and start the packet forwarder manually with the Private Sync word 0x12 (18 in json)

[Jason Reiss]

There is an example to setup an echo server on Conduit on this page.

Conduit mPower: LoRa Communication and Node-RED

Configure the debug node to see the complete object.

Using the lora-out node send the dev-eui and payload to schedule a downlink. The mDot will only receive a packet in response to an uplink when in class A mode.

Class C mode is also available with our latest firmwares.
The mDot can be set to class C with AT+DC=C and then configured on the Conduit following these instructions
.

LoRa Network Server

[Jason Reiss]

To start, what version of mbed library and mbed-rtos are being used?

[Jason Reiss]

The duty-cycle in implemented as time-off-air after time-on-air.
If the device transmits for 1.6 seconds than it cannot transmit in the same frequency band for 160 seconds.

Time-on-air for 13 bytes can vary from 0.03 – 1.6 seconds depending on datarate.

There is a band at the top of 863-870 that can be used with 100% duty cycle if ERP is below 7dBm.

[Jason Reiss]

Disable ACK and call cancelRxWindow() after a non-blocking send call to cancel the pending rx windows.

This should allow the next send to succeed.

[Jason Reiss]

For offline application development we suggest using the mbed 5.0 SDK with our updated mdot libraries provided with the following links.

https://developer.mbed.org/platforms/MTS-mDot-F411/

https://developer.mbed.org/teams/MultiTech/code/libmDot-mbed5/

You can use Eclipse offline with mbed-cli by following these instructions.

https://developer.mbed.org/teams/MultiTech/wiki/Using-Eclipse-and-mbed-5-for-MTS-Devices

It is also possible to build offline using mbed-cli, the tool which replaces the mbed 2 (mbed classic) offline SDK.

https://github.com/ARMmbed/mbed-cli#introduction

• This reply was modified 8 years, 5 months ago by Mike Fiore.

[Jason Reiss]

If you are not able to enter the escape sequence then you could make a firmware to either reset the device configuration and save or exit out of the AUTO_OTA mode.

dot->resetConfig();
dot->saveConfig();

dot->setJoinMode(mDot::OTA);
dot->saveConfig();

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

[Jason Reiss]

How is this different from regular downlink messages from Conduit?
Is the receiving device polling for messages or do you want Class C operation?

[Jason Reiss]

The library is waiting for the receive windows to expire before allowing another packet to be sent.

Use this function to cancel the receive windows and allow the library to send again.

mDot.h

void mDot::cancelRxWindow()

[Jason Reiss]

Try updating GCC ARM

I am using:
gcc-arm-none-eabi-4_9-2015q2

[Jason Reiss]

The AEP 1.3.2 firmware has support for AU915.

The LoRaWAN 1.01 protocol defines only 8 downlink frequencies between 915 and 928 MHz for use in AU915. Transmitting outside the range would non-compliant and unexpected by an end-device.

Downloads

[Author]

Posts