[Jason Reiss]

AT+ULC will give the uplink counter.

[Jason Reiss]

Looks like “port” wasn’t listed, I added it to the mqtt-messages page.

AEP doc
http://www.multitech.net/developer/software/aep/lorawan-aep/downlink-queue/

LinkADRReq ex. 0300FFFF01

CMD DR/PWR MASK CTRL/REP
03 0 0 FFFF 0 1

See page 23 and 24
https://lora-alliance.org/sites/default/files/2018-07/lorawan_regional_parameters_v1.0.3reva_0.pdf

[Jason Reiss]

The MIC is 4 bytes appended to the packet determined cryptographically using the Network Session Key and CMAC hash algorithm. It is attached to each packet to ensure authenticity.

[Jason Reiss]

Resetting the transmitter is the correct fix. The uplink counter must have passed the 16-bit boundary. Only 16-bits are sent in the frame, but the transmitter is calculating a MIC with a 32-bit. Resetting the counter on the transmitter to 0 allows the receiving end to recover.

The next release and our current dev library, https://os.mbed.com/teams/MultiTech/code/libmDot-dev-mbed5/, has a change to only use the 16-bit value for MIC so the receiver can accept the packet without tracking the upper 16-bits of a 32-bit counter.

[Jason Reiss]

Yes an application on the gateway can send a MAC command in a payload through the network server.

The end-device has only on operation when it is not joined. It can only send join requests. No information can be received from the network until it is joined.

Once the device is joined you will know that the network is available on the successful sub-band used for the join request/accept messages. There is no need to hop across sub-bands after the join is successful. Send an uplink using the same sub-band and the network will send down the correct channel mask for the available channels.

To change sub-bands will be tricky as the device will be stranded if the gateway changes first. The application on the device will need to detect and fallback to the join procedure.

Likewise if the end-device is changed first then the uplinks will be lost until the gateway is also changed.

[Jason Reiss]

The full channel mask is sent in the first downlink.

If the end-device is reusing all channels, perhaps ADR has dropped to lowest datarate and enabled all channels again. The network is not aware of the channel mask change accept for join.

Only part of the channel mask will be set by ADR as only 16 channels can be changed in a single command and only one command is sent to adjust DR or TXP.

The application can send ADR commands on port 0 to end-devices to change channel mask.

[Jason Reiss]

The xDot/mDot hardware does not include hardware filters. The firmware controls the frequencies used.

The US models have the FCC stamp on the label and EU models have CE stamp.

[Jason Reiss]

Perform a firmware upgrade with the same version of AEP if the system is functioning enough to run the web UI.

Otherwise the upgrade.bin file from AEP can be used via ssh as detailed in the Using Auto-Flash During Reboot with image upgrade.bin section of the linked document above.

[Jason Reiss]

The Max Datarate setting allowed by ADR, will be the datarate needed for power to be reduced. If Max Datarate is set to DR6:SF7BW250 then yes.
If Max Datarate is set to DR4:SF8BW125, then the ADR will set DR4 and then reduce power on additional ADR commands.

On Conduit AEP see LoRaWAN > Network Settings > Max Datarate

[Jason Reiss]

The LoRaWAN spec does not describe an ADR algorithm.

The time-on-air for an SF reduced one step is halved. This saves more power than a tx power reduction of 3 dBm.

Tx power is only reduced when the maximum datarate is set.
The network server on Conduit will reduce the Tx Power one step at a time while the SNR is maintained above 3 dB in uplinks.

[Jason Reiss]

For mLinux 4 try using sudo

[Jason Reiss]

Are both IPK’s available in the directory of the command?
The * is a wildcard which will install any matching IPK. The command may abort on first error.

Remove the 1.0.43 IPK or specify to install the 2.1.5 IPK.

The 3.3.15 tag was a development tag not released.
3.3.22 would be the release version with with an updated LNS v2.0.16.

In either case the 3.x mLinux versions should be compatible with 1.0.x and 4.x mLinux is not.

[Jason Reiss]

Lns v1.0.43 was added in mLinux 3.3.15.

[Jason Reiss]

mLinux 3.x is needed for the 1.0.x network server.

See http://www.multitech.net/mlinux/feeds/

[Jason Reiss]

Creating a Custom Application

You could create a custom app that performs the monitoring. It would be reinstalled after the firmware upgrade.

[Jason Reiss]

It depends on what you intend to do. Just LoRa modulation or support LoRaWAN protocol.

Application Development

C/C++ Toolchain

Python is ok for an application depending on what you need it to do. Just forwarding to cloud is probably a light lift. The development may be easier.
C is the best choice for performance.

Looking at the feeds http://www.multitech.net/mlinux/feeds/
mLinux 3 – python 2.7.3
mLinux 4 – python 2.7.12

[Jason Reiss]

Packet Forwarder interfaces with the MTAC-LORA card and provides LoRa packets via UDP for uplink and downlink. This is used for sending packets via LoRa modulation.

The Network Server provides, key/session management, authentication and decryption of packets which can be access via UDP or MQTT. It provides the LoRaWAN protocol services.

A python application could interface with either service. Sending packets to LoRaWAN motes would require key/session management, authentication and encryption of packets.

Datasheet is available here, there is 256 MB of RAM.
https://www.multitech.com/brands/multiconnect-conduit

Developer doc is available here

Conduit

[Jason Reiss]

Integration to collos would require the v2.1 gateway and GPS.
This is performed by a cloud network server forwarding location data to the location service.

The Conduit AP and 8-Channel IP67 Conduits cannot perform the accurate time-of-arrival required to locate end-devices.

[Jason Reiss]

Channels for DR6 and DR7 are configured separately

Conduit AEP: Convert to Basic Packet Forwarder

The Sx1301 allows 8 Multi-SF (SF7-12) channels at 125 KHz, one LoRa channel with fixed SF/BW and one FSK channel.
https://www.semtech.com/uploads/documents/sx1301.pdf

In packet forwarder mode the full configuration is available via MANUAL configuration.

In network server mode see the LoRaWAN Gateways page.
Choose the detail option from the gateway list.

Also info available through API, see packetForwarders section.
https://192.168.2.1/api/lora/config

Multiple Conduits can also be networked to provide more downlink capability

Networking Conduits

[Jason Reiss]

OTA and ABP will work.

Packet forwarders are stateless. They Rx packets on the frequencies and forward to network server.

[Jason Reiss]

And the xDot does not need special configuration to work with packet forwarder.

[Jason Reiss]

The MQTT messages contain gateway information.

$ mosquitto_sub -v -t lora/+/+/packet_recv

lora/<GW-EUI>/<DEV-EUI>/packet_recv {"tmst":...}

$ mosquitto_sub -v -t lora/+/up

{..."gweui":"<GW-EUI>"...}

[Jason Reiss]

An updated firmware with multi-region support for MTDOT-BOX is available here.
https://github.com/MultiTechSystems/Dot-AT-Firmware-beta

[Jason Reiss]

AU915 is the only channel plan with changes to the protocol between AEP 1.4.17 and 1.6.4. Datarates were changed.

What channel plan are you using? I am able to connect to our latest AEP firmware using EU868.

MTDOT 2.1.2
Private mode AT+PN=0 will use join delay of 1
Public mode AT+PN=1 will use join delay of 5

[Jason Reiss]

The NucleoL152 would be close. I would use that as a starting point.

[Jason Reiss]

For the EU868 channel plan 868.8 MHz is defined of FSK in network server using the UI to configure.

https://192.168.2.1/api/loraNetwork?method=PUT&data={“lora”:{“frequencyOffsetDR7”: 300000}}

Frequency is offset from 868.5 MHz, offset is limited to ~ +/- 500K

Restart lora network server.
Save and restart the Conduit to persist.

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

[Jason Reiss]

I agree, the queue of the network server is not providing a benefit to the application in this use case. The queue is better managed by the application, part of which can reside on the Conduit to provide a timely response to the uplink.

[Jason Reiss]

Packet forwarder allows configuration of an FSK channel.

		"chan_FSK": {
			"bandwidth": 125000,
			"datarate": 50000,
			"enable": true,
			"if": 300000,
			"radio": 1
		},

For the EU868 channel plan 868.8 MHz is defined of FSK in network server and packet forwarder modes using the UI to configure. The above configuration is used by packet forwarder MANUAL mode.

[Jason Reiss]

Application payloads will not be lost unless the application queues a downlink packet. The application can choose which uplinks it wants to queue downlink packets for. If ack=true uplinks signify the device is listening for downlinks the application can queue the downlink at that time and it will be sent as expected.

This behavior is defining an application protocol, use of the ACK bit for this purpose is extraneous state information that is not intended by the original protocol. The application is in full control of the downlink queue.

If the device were to send before the Rx windows have expired the network server will not schedule additional downlinks. i.e. Two uplinks received less than 1 second apart will only result in a downlink scheduled for the first packet, the second uplink is accepted without downlinks added to the queue. Downlinks will be scheduled for the device after at least one second elapses between uplinks from that device.

What extra functionality is required of the network server?

[Jason Reiss]

Windows can be canceled and the dot can be put to sleep or send another packet without waiting for Rx Windows if AT+TXW=0.

With libmDot sends can be performed in non-blocking mode and Rx windows can be canceled.

Both of these methods are not recommended and not compliant with LoRaWAN.

The Rx windows are needed for LoRaWAN compliance so the network can issue MAC commands to control the end-device.
If a device does not respect the windows it cannot receive updates for channel usage, frequency changes, etc…
The network even has the ability to reduce the rate the end-device can transmit via DutyCycle MAC command.

[Author]

Posts