[Jason Reiss]

LoRaWAN 1.0.2rB

[Jason Reiss]

What version of firmware is installed on the gateway?

The Min/Max datarate settings on the Conduit control the datarate to be sent to an end-device in a LinkADRReq MAC command. Setting the Min Datarate to 2 should restrict the network server from sending commands to use DR0 or DR1.

ADR does not control the minimum datarate a device will reach when ACK or ADRACKReq are note received. Although this does sound like an interesting addition to the protocol that may warrant a request to the LoRa-Alliance.

The end-device is responsible for lowering the datarate when connectivity to the network is lost, i.e. when it moves out of range of the current datarate.

I am surprised to see TxParamSetupReq implemented in the reference code as it is specifically called to not be implemented in the specification.

LoRaWAN 1.0.2 and 1.1rA Regional Parameters Page 29

2.5.3 AU915-928 Data Rate and End-point Output Power encoding
The TxParamSetupReq MAC command is not implemented by AU915-928 devices.

[Jason Reiss]

Piia, can you open a ticket at support.multitech.com and share a full log and configuration.

I can recreate the issue with clearing the queue via MQTT.

How often does your application queue messages for downlink?

[Jason Reiss]

The network server in Conduit implements LoRaWAN 1.0.2.

The MTAC-LORA will work with either, it is configured with a set of channels to listen to.

A LoRaWAN 1.1 end-device should be able to connect to a 1.0.2 network server and vice versa. The version is negotiated during OTA join.

[Jason Reiss]

The packet forwarder is a passthough stateless process. It forwards packets between the network server and end-devices over RF.

• This reply was modified 6 years, 10 months ago by Jason Reiss.

[Jason Reiss]

Use deviceQueueSize

[Jason Reiss]

See Channel Mask setting.
http://www.multitech.net/developer/software/aep/lorawan-aep/lorawan-network-settings/

[Jason Reiss]

Can you share an example project via github demonstrating the issue?

[Jason Reiss]

This is the best info I could find. No mention of how to get keys from the device.

https://www.youtube.com/channel/UCPWCmIdERHRi8Undw3gn51g

https://www.thethingsnetwork.org/forum/t/pni-placepod/14297

[Jason Reiss]

Sorry I do not have more information regarding from the PNI device or how it is intended to operate, I have not found docs available publicly.

Please refer to PNI documentation or contact their support for information regarding provisioning and activation.

[Jason Reiss]

The channels are monitored simultaneously.

If the end-device transmits on the correct channel the gateway should receive it. It will not receive packets transmitted on the wrong channels.

One one 500 kHz channel is enabled therefore only one 500 kHz channel will be used,

Max payloads are also available to DR3 using 125 kHz channel with SF7.

[Jason Reiss]

The script is a set of commands specifically for a minicom terminal program.

It is a text file, opening it will show the commands.

[Jason Reiss]

What leads you to believe it isn’t possible?
Is the place pod a LoRaWAN module?
The Conduit can communicate with any LoRaWAN device.

The device will need to be registered to authenticate and decrypt the packets from the device.

Do you have any documentation regarding the activation procedure for the PNI device?
There may be provisioning information available via bluetooth when the sensor is activated using the magnet.

If it is an ABP device look for DevAddr, Network Session Key and Application Session Key.

If it is an OTA device look for DevEUI and AppKey.

Use the info from the sensor to register it with the Conduit.

To start use the embedded network server.

mLinux instructions for provisioning devices.

LoRa Network Server

The lora-query utility can be used to get info from the network server.
$ lora-query -x help
$ lora-query -x packets recent
$ lora-query -x packets join

For AEP use the LoRaWAN UI pages.

To receive messages from network server MQTT can be used on command line.
$ mosquitto_sub -v -t lora/+/+

MQTT Messages

Troubleshooting help and PDF guide

Troubleshooting LoRa Communication

[Jason Reiss]

Python is already installed with the packages needed for UDP communication and JSON parsing.
https://wiki.python.org/moin/UdpCommunication

A network server will be needed to authenticate and decrypt the packets. Are you planning on using a LoRaWAN service provider or the embedded network server on Conduit?

The packet forwarder sends received packets to a network server via UDP.
https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT

To receive packets locally open a listening socket in python on the configured upstream port.

By default the pod my be transmitting on 64 channels where the gateway can only listen on 8. The correct channel mask will need to be configured in the sensor.

Has the place pod been activated?

Is it an ABP or OTA device?

An OTA device will join the network by sending a Join Packet containing an Device EUI. The network server will respond to the device with a Join Accept packet and both sides will create session keys using a pre-shared AppKey.

An ABP device will already have session keys which will need to be provided to the network server out-of-band.

[Jason Reiss]

Start here

Introduction to LoRa

And here

Getting Started with LoRa Conduit AEP (LoRa Configuration)

Data is encrypted so keys need to be exchanged between end device and network server on Conduit.

[Jason Reiss]

The downloads for 1.4.17 zip files contain only the conduit_AEP_1.4.17_upgrade.bin file. Where are you getting the bstrap, uboot, rootfs and uImage files?

Downloads

[Jason Reiss]

The US915 region has defined 64 channels.
The MTAC-LORA cards with a single Sx1301 concentrator support only 8 125 KHz channels and one 500 kHz channel.

The each US915 sub-band defines a channel mask enabling only 8 of the 125 kHz channels and a single 500 kHz channel to be used with a single gateway card.

[Jason Reiss]

Default login for pre-built 4.0.1 image.
u: mtadm
p: root

Some actions will now require sudo access.

Password can be set when building an image.

Building a Custom Linux Image

Password for U-Boot can also be set

Setting administrative passwords

[Jason Reiss]

mLinux firmware does not provide a Web interface.
AEP firmware is needed.

[Jason Reiss]

Please see trouble shooting guide.

Troubleshooting LoRa Communication

[Jason Reiss]

It may not be possible without build tools to compile some dependencies.
Other users have had success with python tools for modbus.
pymodbus may already be available on the system.

admin@mtcdt:~# opkg list | grep modbus
python-pymodbus – 1.3.2+git0+336c46c998-r0.0

[Jason Reiss]

In US915 DR0 can only carry 11 bytes of payload.

When the ERROR is seen the libmDot will send a packet with the MAC commands.
This is why there is a transmit in progress ERROR if you try to send again immediately.

Try waiting for getIsIdle() to be true.

[Jason Reiss]

Both AEP and mDot updates should be available in August to support FUOTA.

[Jason Reiss]

AEP and mDot firmware will include applications for Multicast and FUOTA setup and transmission. Multicast allows multiple devices to receive a firmware simultaneously rather than send to each device.

To make use of the FUOTA application the AEP UI or API can be used by on Conduit.

On mDot the FUOTA application can be enabled through AT commands and will be included in libmDot to be used in a custom firmware.

[Jason Reiss]

A link to the trouble shooting guide is on this page.

Troubleshooting LoRa Communication

See page 19/20 of Trouble shooting guide.
http://www.multitech.net/developer/wp-content/uploads/downloads/2018/04/LoRaWANTroubleShootingGuide-04132018.pdf

[Jason Reiss]

What are the recommended settings for the sensor? Public or Private?
When do you expect the sensors to send join requests?
Can they be forced to send a join request?
Do you have any other end-device you can test with?

The join requests should be sent on the three default frequencies, 868.1, 868.3 and 868.5

You could try to set Additional Channels to 869.5 or 867.5
Although the channels will be sent to the devices in the Join Accept no matter the setting.

CRC errors can be caused by noise, they are not necessarily corrupted LoRa packets. They are not a sure indicator that the end-device is transmitting.

[Jason Reiss]

Did you try to change the Network Mode between public/private?

[Jason Reiss]

\r\n

[Jason Reiss]

Was the topic exactly as posted? ‘/lora/<deviceid>/clear’
It should be ‘lora/<deviceid>/clear’ without the initial ‘/’ character.

If queue_full is being seen there are more downlinks being scheduled than can be sent. The gateway is able to received up to 8 packets at a time but can send only one.

How often are uplinks being sent from the end-devices?
How often are downlinks expected to be sent to the end-device?
Are ACK’s being requested in the downlink?

• This reply was modified 6 years, 12 months ago by Jason Reiss.

[Jason Reiss]

There are separate packet forwarders already installed for the USB vs SPI model.

The system will detect and run the correct version, all that will need to be done is install the new card.

[Author]

Posts