Manual

The mDot^™ can also be activated manually if supported by network server.

• AT+NJM=0 Configure mDot for manual join mode
• AT+NA Network Address Network address (devAddr in LoraMac) (4 bytes)
• AT+NSK Network Session Key Network session encryption key (16 bytes)
• AT+DSK Data Session Key Data session encryption key (16 bytes)

OTA – Network Join

After configuring the NetworkID and NetworkKey on the mDot. A join packet can be sent with the DeviceID, NetworkID and a dev-nonce value. The network server will check the NetworkID and assign an address which is returned with the NetID and app-nonce value. Using the network address, NetID, nonce values and NetworkKey, session keys will be generated independently on the device and network server for encrypting transmissions during the session.

• AT+NJM=1 Configure mDot for OTA join mode (default)
• AT+NI NetworkID
• AT+NK NetworkKey
• AT+JOIN Send a join request to the server
• AT+NJS Display current join status 0:not joined, 1:joined

AUTO OTA – Network Join

After a successful join the session information will be stored in flash. This session info will be restored when waking from sleep. If the device is reset or the power cycled the session info will be reset and a join will be attempted. The session info will be valid as long as the mDot checks in before the lease-time configured on the Conduit^® expires.

• AT+NJM=2 Configure mDot for AUTO OTA join mode
• AT+NI NetworkID
• AT+NK NetworkKey
• AT+JOIN Reloads the session info from flash
• AT+JOIN=1 Force mDot to perform OTA join regardless for saved session

mDots^™ are pre-loaded with custom AT Command firmware, which turns the serial interface into a command port for configuring the mDot. You can use this firmware to test LoRa connections and to develop production applications where a host processor issues AT commands to the mDot.

The AT Command Firmware is a convenient wrapper around libmDot, our mbed LoRa API. The source code is available on mbed where you can easily fork and customize it as needed.

For the AT Command Reference Guide, go to the Guides section at mDot

AT Command List

Documentation is accessible on the mDot with the help or ? commands.

help
Command Name       Description
AT      Attention  Attention
ATI     Request Id Request Identification
ATZ     Reset CPU  Reset the CPU
...

Get help for a single command using help <command>.

help AT+JOIN
AT+JOIN: Join network, provide argument of `1` to force join ...

Using Commands

Querying

Some commands allow you to query the current value. Enter the command name with no argument or followed by an optional ? to query a setting.

• Query a value.

  AT+TXP
  11
  
  OK

• Query a value with optional ?.

  AT+TXP?
  11
  
  OK

Assigning

Some commands allow you to assign a new value.

• To assign a new value pass the value as an argument.

  AT+TXP=10
  
  OK

• To see a range of input or output values for a command give ? at the only argument.

  AT+TXP=?
  AT+TXP: (0-20)
  
  OK

Examples

Network ID and Network Key can be configured with a hexadecimal value or name/passphrase.

• To configure with a hexadecimal value provide a first argument of 0.

  AT+NI=0,0011223344556677
  
  OK
  AT+NK=0,00112233445566770011223344556677
  
  OK

• To configure with a name/passphrase value provide a first argument of 1. When using this option, the name and passphrase are converted to hexadecimal values behind the scenes.

  AT+NI=1,MTS-LORA-1
  
  OK
  AT+NK=1,MTS-LORA-PASSPHRASE
  
  OK

Before joining to a Conduit^® using the US 915 band, you must set the frequency sub-band to join using the frequencies the Conduit is configured to listen on (which set of 8 from the 64 available channels).

• To configure the frequency sub-band

  AT+FSB=5
  
  OK

The mDot supports over-the-air (OTA) and manual join modes.

• To configure for OTA join mode and connect to the network

  AT+NJM=1
  
  OK
  AT+JOIN
  
  OK

• To configure for AUTO OTA join mode and connect to the network, if you are not already joined, a join attempt will be made

  AT+NJM=2
  
  OK
  Joining Network... Network Joined
  
  OK

• To configure for MANUAL provisioning, change the mode, then set the network address and session keys (in OTA, the session keys are automatically created during the join process).

  AT+NJM=0
  
  OK
  AT+NA=0011223344556677
  
  OK
  AT+DSK=00112233445566770011223344556677
  
  OK
  AT+NSK=00112233445566770011223344556677
  
  OK

For more information, see Network Join Modes and Connecting to a Network.

Ensuring Network Connectivity

The network join status command (AT+NJS) returns a boolean value indicating network connectivity. However, the mDot can only detect a network loss by failing to receive a response from the server.  One method is to require ACKs for each packet, but under heavy load the server may be unable to respond. The other method is to only require an ACK periodically using AT+LCC which reduces the network load but still allows the mDot to detect network failures. Additionally, the link check threshold (AT+LCT) determines how many missed responses determine a network loss. In the following examples the gateway will be powered off to simulate loss of network.

• Method one: require ACKs for each packet. With a threshold of one, after only one lost packet the network will no longer be joined. Increasing the value for LCT will allow some missed packets without having to rejoin the network. If AUTO OTA is enabled the device will attempt to rejoin after network is lost.

  [Gateway Powered On]
  AT+JOIN
  Successfully joined network
  
  OK
  AT+ACK=1
  
  OK
  AT+LCT=1
  
  OK
  AT+SEND=message
  
  OK
  [Gateway Powered Off]
  AT+NJS
  1
  
  OK
  AT+SEND=message
  Operation Timed Out - ACK not received
  
  OK
  AT+NJS
  0
  
  OK

• Method two: only require ACKs periodically by using link checks. AT+LCC set to 2 will request a server response for every other transmitted packet. With a threshold of one, after only one missed response the network will no longer be joined. Increasing the value for LCT will allow some missed packets without having to rejoin the network. If AUTO OTA is enabled the device will attempt to rejoin after network is lost.

  [Gateway Powered On]
  AT+JOIN
  Successfully joined network
  
  OK
  AT+LCC=2
  
  OK
  AT+LCT=1
  
  OK
  AT+SEND=message
  
  OK
  [Gateway Powered Off]
  AT+SEND=message
  
  OK
  AT+NJS
  1
  
  OK
  AT+SEND=message
  Network Not Joined
  
  ERROR
  AT+NJS
  0
  
  OK

Serial Data Mode

The Serial Data mode is designed to work in conjunction with sleep where the mDot wakes up periodically, signals a host, reads data from the serial port, and then transmits it. The mDot can be configured to wake up on a fixed time interval or on an interrupt triggered by the DIO7 pin. When the mDot wakes up in serial data mode, it sets the XBEE_ON_SLEEP pin so the host processor knows when to start transmitting serial data.

This is the basic setup after configuring network settings:

1. Set to wake-up on interval (0:INTERVAL, 1:INTERRUPT)

   AT+WM=0

2. Set wake interval for 10 minutes

   AT+WI=600

3. Wait for serial data for 500 ms

   AT+WD=500

4. Timeout reading serial if no character for 20 ms

   AT+WTO=20

5. Enable auto-join mode to join on start and save session info in flash

   AT+NJM=2

6. Configure ACK’s or set LCC to send periodic link checks

   AT+ACK=4 (make 4 attempts to get response from server)
   or
   AT+LCC=5 (request response every 5 packets)

7. Set number of missed responses to consider link dead and rejoin

   AT+LCT=10

8. Configure the mDot to start in Serial Data mode

   AT+SMODE=1

9. Save changes

   AT&W

Now if you issue AT+SD or ATZ the mDot will enter the wake-read-send-sleep cycle and monitor responses from the server to stay connected.

To escape out of serial data mode, hold SHIFT and + while pressing the reset button on the UDK. Once you see +’s being printed, press ENTER. The AT command interface should now be accessible.

For Conduit mLinux models

SPI device paths with mPower >= 6.0.0

• In the global_conf.json
• AP1

      
      "gateway_conf": {
          "spi_device" : "/dev/spidev0.2",

• AP2

      
      "gateway_conf": {
          "spi_device" : "/dev/spidev1.2",

SPI device paths with mPower = 5.2.1

• In the global_conf.json
• AP1

      
      "gateway_conf": {
          "spi_device" : "/dev/spidev32766.2",

• AP2

      
      "gateway_conf": {
          "spi_device" : "/dev/spidev32765.2",

Links

Troubleshooting Help

Examples of global_conf.json

Copy one of the following to the /var/config/lora/ directory renamed as global_conf.json.

• Conduit with MTAC-LORA accessory cards:
  • US (915 MHz)
  • Europe (868 MHz)
  • Australia (915 MHz)
  • Asia Pacific (923 MHz)
  • Asia Pacific with LBT (923 MHz)
  • Korea with LBT (920 MHz)
  • India (865 MHz)
• Conduit AP:
  • US (915 MHz)
  • Europe (868 MHz)
  • Australia (915 MHz)
  • Asia Pacific (923 MHz)
  • Asia Pacific with LBT (923 MHz)
  • Korea with LBT (920 MHz)
  • India (865 MHz)
• Conduit with MTAC-003 accessory cards:
  • US (915 MHz)
  • Europe (868 MHz)
• Conduit MTCAP3:
  • US (915 MHz)
  • Europe (868 MHz)
  • Australia (915 MHz)
• Conduit IP67 with v2.1 Gateway Card
  • See /opt/lora/ directory for example config files

Enabling start-up on boot

$ update-rc.d lora-packet-forwarder defaults 80 30

Setting up the Conduit

mLinux >= 3.2.4

1. /etc/init.d/lora-network-server stop
2. Edit /etc/default/lora-network-server
3. ENABLED=”no”
4. Edit /etc/default/lora-packet-forwarder
5. ENABLED=”yes”
6. Copy global_conf.json to /var/config/lora/ directory
7. Be sure to set “gateway_id” and server settings.
8. If you need a value for “gateway_id” the lora card value can be used

   $ mts-io-sysfs show lora/eui
   00:80:00:00:00:00:00:97

9. The colon separators must be removed 00:80:00:00:00:00:00:97 => 0080000000000097
10. /etc/init.d/lora-packet-forwarder start

For Conduits with GNSS module installed

As of mLinux 4.1.6 the packet forwarder will get GPS data via libgpsd, set gps property to true.

1. mLinux >= 4.1.6
   1. Set “gps”: “true” in global_conf.json “gateway_conf” section
   2. Reboot
2. mLinux < 4.1.6
   gpsd usage of the GPS is not compatible with lora-packet-forwarder. It is not possible to use the Multitech supplied Lora-Packet-Forwarder with the GNSS port, and GPSD at the same time.
   1. Edit /etc/default/gpsd
   2. Set Enabled=”no” and Save
   3. ntpd must be disabled or configured to not use gpsd
      • Edit /etc/default/ntpd, set Enabled=”no” and Save

      Or

      • Edit /etc/default/ntpd, set GPSD_REQUIRED=0 and Save
      • Configure NTP time server in /etc/ntp.conf
   4. Set “gps_tty_path”: “/dev/ttyXRUSB2” in global_conf.json “gateway_conf” section
   5. Reboot

For Geolocation v2.1 Conduits IP67

• GPS data is available on /dev/gps0 and /dev/ttyXRUSB0
• GPS antenna should be connected to port 3
• Generate AES key to unlock the fine timestamp using the hardware chip-id

  • $ sudo /opt/lora/lora-v21-keygen $(sudo /opt/lora/gateway-utils-geo/chip_id | grep -oe '0x.*' | sed -r 's/0x//g' | sed 'N;s/\\n/ /')

mLinux < 3.2.4

1. Install the LoRa mCard. Refer to Installing an mCard Accessory Card.
2. Attach the LoRa antenna to the LoRa mCard.
3. Use the power cable to connect power to the Conduit and wait for the Conduit to boot up.
4. Login to the console and configure the Conduit for internet access over Ethernet or cellular. Refer to Getting Started with mLinux if needed.
5. Issue these commands on the Conduit:

   $ mkdir /var/config/lora
   $ cp /opt/lora/lora-network-server.conf.sample /var/config/lora/lora-network-server.conf

6. Edit /var/config/lora/lora-network-server.conf and modify these settings as needed (use vi or nano).

   Field	MTAC-LORA-915 (NA)	MTAC-LORA-868 (EU)
   lora[“frequencyBand”]:	“915”	“868”
   lora[“channelPlan”]:	“US915” or “AU915”	“EU868”
   lora[“frequencySubBand”]:	(integer: 1 to 8)	Not applicable
   lora[“frequencyEU”]:	Not applicable	default: 869500000 range: [863500000 – 867500000] and [869100000 – 869500000]
   network[“public”]:	true

7. Restart the network server. This will generate a configuration file for the packet forwarder.

   $ /etc/init.d/lora-network-server restart

8. Copy the generated packet forwarder configuration to the config partition.

   $ cp /var/run/lora/1/global_conf.json /var/config/lora/global_conf.json

9. Edit /var/config/lora/global_conf.json and modify these settings.

   Field	Description	Example
   gateway_conf[“server_address”]:	Network IP or URL of your LoRa network server	“lora.mydomain.com”
   gateway_conf[“serv_port_down”]:	The LoRa network server’s downstream UDP port	1700
   gateway_conf[“serv_port_up”]:	The LoRa network server’s upstream UDP port	1700

   *If you have mLinux firmware version 3.2.4 or greater, skip steps 10-12, and see below for further instructions.

10. Edit /etc/init.d/lora-network-server as follows :
    • Comment out the Lora network server start code

      # start network server                  
      #start-stop-daemon --start --background --make-pidfile \
      #    --pidfile $net_server_pidfile --exec $net_server -- \
      #    -c $conf_file --lora-eui $lora_eui --lora-path $run_dir --db $conf_db \
      #    --noconsole -l $net_server_log                      
      #sleep 1

    • On line 65, change the -c option for packet forwarder from -c $run_dir to -c $conf_dir

      # start packet forwarder            
      start-stop-daemon --start --background --make-pidfile \
           --pidfile $pkt_fwd_pidfile --exec $pkt_fwd -- \
           -c $conf_dir -l $pkt_fwd_log           
      echo "OK"

    • Comment out the Lora network server stop code

      #start-stop-daemon --stop --quiet --oknodo --pidfile $net_server_pidfile --retry 15
      start-stop-daemon --stop --quiet --oknodo --pidfile $pkt_fwd_pidfile --retry 5

11. Restart the packet forwarder.

    $ /etc/init.d/lora-network-server restart

12. For debugging, you can view the packet forwarder log with this command:

    $ tail -f /var/log/lora-pkt-fwd.log

*If you have mLinux firmware version 3.2.4 or greater, continue with steps 13-16 after step 9  from above (If not, stop here after step #12. You are done.)

13. Stop the network server using this command:

nbsp;/etc/init.d/lora-network-server stop
14. Edit /etc/default/lora-network-server:
ENABLED ="no"
15. Edit /etc/default/lora-packet-forwarder:
ENABLED = "yes"
16. Start packet forwarder using this command:

nbsp;/etc/init.d/lora-packet-forwarder start
Setting Up the mDot Using Manual Join

Establish a serial connection to the mDot

Connect your PC to the DB9 serial connector on the UDK
Open a terminal session using an application such as TeraTerm with baud rate 115,200


Issue these commands:

AT+NJM=0 (manual join mode)
AT+PN=1 (public network mode)
AT+FSB=value (915 NA only | value = frequencySubBand from your Conduit)
AT+NSK=value (value = Network session key given by your network server operator)
AT+DSK=value  (value = Data (application) session key for your application)
AT+NA=value  (value = 4-byte device address)
AT&W  (save settings)
ATZ  (restart)


Send data without requesting an ACK:

AT+ACK=0
AT+SEND=hello world



Troubleshooting

The packet forwarder starts but immediately stops

If /var/config/lora/global_conf.json is not in proper json format (extra or missing comma), the packet forwarder cannot run.



Packet Forwarder Configuration Options
Two sections are available in the configuration: radio settings (SX1301_conf) and server settings (gateway_conf).
SX1301_conf

lorawan_public – set sync word to false: 0x12 or true: 0x34
clksrc – must be 0 for Multitech gateway hardware
antenna_gain – configure the installed antenna gain if the network server sends EIRP value with downlinks. The Multitech network server will account for antenna gain before sending tx power to the forwarder.

Radios
The radio_0 and radio_1 settings configure the two front-end radios on the MTAC cards.

enable – true if radio is enabled for use

type – type of radio chip installed SX1257 or SX1255, frequency range differs
freq – center frequency the radio is configured to listen for packets
tx_enable – true if radio can be used for transmissions
tx_freq_min – minimum frequency to be allowed for transmissions
tx_freq_max – maximum frequency to be allowed for transmissions
rssi_offset – offset in dBm to adjust the radio RSSI reading

Channels
Eight channels can be configured to receive LoRa packets using 125 kHz bandwith. These channels are configured in the chan_multiSF_x settings. Each channel has an enable boolean, a selected radio and an intermediate frequency. The channel frequency will freq setting of the radio plus the if setting of the channel.

enable – true if this channel is enabled for use
radio – selected radio to listen for packets
if – intermediate frequency offset applied to the selected radio “freq” setting

Two additional channels can be configured with the chan_Lora_std and chan_FSK settings.

enable – true if this channel is enabled for use
radio – selected radio to listen for packets
if – intermediate frequency offset applied to the selected radio “freq” setting
bandwidth – channel bandwidth
spread_factor (LoRa) – channel spreading factor (7-12)
datarate (FSK) – channel datarate in bps

Look-up-table (LUT)
There are sixteen power settings that can be configured, these settings have been selected during calibration for each hardware. The power sent from the network server is looked up in this table by the rf_power setting. The corresponding pa_gain, mix_gain and dig_gain settings are then input into the radio for the transmission. These settings should not be adjusted.
gateway_conf

gateway_ID – gateway identifier sent in each message to the network server
server_address – address of the network server
serv_port_up – port for sending uplink packets to the network server
serv_port_down – port to communicate to receive downlink packet from the network server
keepalive_interval – interval to ping the network server
stat_interval – interval to send stat messages to the network server
push_timeout_ms – socket timeout when publishing messages to the network server
autoquit_threshold – number of keepalive messages without response to wait before quitting
forward_crc_valid – enable to forward valid packets to the network server, default: true
forward_crc_error – enable to forward CRC failed packets to the network server, default: true. The network server will reject packets with failed CRC, it may not be necessary to forward the packets except for a statistic of local RF quality or to monitor the gateway performance over time. Some random CRC failed packets are expected to be received from random noise.
forward_crc_disabled – enable to forward packets without CRC enabled to the network server, default: false. LoRaWAN protocol expects uplink packets to have CRC enabled.

Listen Before Talk configuration
			

		

The mLinux version of Conduit (MTCDT-xx-210L) supports OTA (over-the-air) joining by third-party LoRa devices as of LoRa Network Server version 0.0.7 (If you need to upgrade, refer to Upgrade LoRa Server & Packet Forwarder).

mLinux >= 3.3.22, lora-network-server >= 2.0.16

Network Server Whitelist

Add unique device records into the whitelist devices list in lora-network-server.conf. The appeui will be attached to received packets. The class setting will be used to configure the end-device when it joins.

`{“deveui”:”008000000000e19c”, “appeui”:”008000000000e19c”, “appkey”:”008000000000e19c008000000000e19c”, “class”:”C”}`

LoRa Query Commands

admin@mtcdt:~# lora-query -x help
MTS Lora Server Command Help

Commands:
stats - list current stats
  reset - reset stats for network, gateways and end-devices
gateway - gateway commands
  list - list connected gateways
      format: gateway list [json]
  delete - remove a gateway from the list
      format: device gateway <GW-EUI>
device - end-device commands
  add - add a new end-device record
      format: device add <DEV-JSON>
      example: device add '{"deveui":"00-80-00-00-00-00-e1-9c","class":"C"}'
  stats - show end-device statistics
  update - update end-device configuration or session info
      format: device update <DEV-EUI> <FIELD> <VALUE>
      example: device update 00-80-00-00-00-00-e1-9c class C
      fields: class, nskey, dskey, ulc, dlc
      format: device update <DEV-JSON>
      example: device update '{"deveui":"00-80-00-00-00-00-e1-9c","class":"C"}'
      fields: class, name, serial_number, product_id, 
              hardware_version, firmware_version, lorawan_version
  delete - delete an end-device configuration, session and packet records
      format: device delete <DEV-EUI>
  config - show configuration for a specific device
  reset - reset end-device session counters
      format: device reset <DEV-EUI>
  list - list end-devices configured in the network server
      format: device list [json | json file <path>]
      example: device list json
      example: device list json file /tmp/devices.json
  keygen - generate a unique end-device key using zero-touch settings
      format: device keygen <DEV-EUI> [APP-EUI]
session - session commands
  add - add a session for a device
      format: session add <DEV-JSON>
      example: session add '{"deveui":"00-80-00-00-00-00-e1-9c",
        dev_addr":"00112233", "appeui":"00-88-88-88-00-00-e1-9c",
        "joineui":"00-99-99-99-00-00-e1-9c","net_id":"000017", 
        "app_senc_key":"531bd9c5ec5d8ba5ef3b262cebfb3e66", 
        "fnwk_sint_key":"531bd9c5ec5d8ba5ef3b262cebfb3e66"}'
      fields: deveui, appeui, joineui, dev_addr, net_id, 
              app_senc_key, fnwk_sint_key
  delete - remove a device session
      format: session delete <DEV-EUI>
  reset - reset session counters
      format: session reset <DEV-EUI>
  list - show current device sessions
      format: session list [json | json file <path> ]
      example: session list jsonvi /
      example: session list json file /tmp/sessions.json
packet - packet commands
  join - list all validated join packets
      format: packet join [json]
  up - list all validated uplink packets
      format: packet up [json]
  down - list all downlink packets
      format: packet down [json]
  list - list all packets: join, up and down
      format: packet list [json]
  queue - list downlink queue packets to be sent to end-device
      format: packet queue [json]
    add - add a packet to the downlink queue
      format: packet queue add <PACKET-JSON>
      fields: deveui, data, ack, ack_retries, rx_wnd
    delete - delete all downlinks for a specific device
      format: packet queue delete <DEV-EUI>
    delete - delete one downlink for a specific device
      format: packet queue delete <DEV-EUI> 
database - database commands
  backup - backup database to flash memory
config - show network server configuration
debug - change debug level
ping - ping the network server command port
help - display this help
quit - command network server process to stop

- add 'json' modifier to request output in json

mLinux < 3.3.22, lora-network-server <= 1.0.43

OTA Join Setup

Configure the following settings in /var/config/lora/lora-network-server.conf:

• Set network[“public”] to true
  • This changes the join response time from 1 to 5 seconds and the sync word from 0x12 to 0x34
  • NOTE: Public mode must also be enabled on mDots in order for them to remain compatible
• Set network[“eui”] to an 8 hex byte value.
• Set network[“key”] to a 16 hex byte value.
• Save the file
• Restart the Lora network server: /etc/init.d/lora-network-server restart

Third-party LoRa devices should now be able to join the Conduit’s LoRa network using OTA join. For more information on these settings, refer to Conduit mLinux: Advanced LoRa Configuration.

Manual Join/Activation by Personalization

• SSH into the Conduit (default IP: 192.168.2.1, default credentials: root/root)

  # ssh root@192.168.2.1

• Then run this command to start a LoRa server configuration console

  # nc -u localhost 6677

• Add a node like this

  # node add [DevAddr] [APPEUI] [DEVEUI] [NwkSKey] [AppSKey]

Example:

# nc -u localhost 6677
node add 00000005 0011223344556677 8811223344556677 2b7e151628aed2a6abf7158809cf4f3c 2b7e151628aed2a6abf7158809cf4f3c

Troubleshooting

Use the following troubleshooting steps to either track down issues on your own or include a capture of the responses/results below in a forum topic or support case.

• SSH into the Conduit (default IP: 192.168.2.1, default credentials: root/root)

  # ssh root@192.168.2.1

• Go to the /var/config/lora/ folder and modify the lora-network-server.conf file with the log level set to 100. Save it and issue the following command:

  /etc/init.d/lora-network-server restart

• Run your test again, then provide the log: /var/log/lora-network-server.log
• Issue the following command and capture the output:

  /opt/lora/lora-network-server --version
  cat /etc/issue

• What brand is the mote?
• What are the mote’s settings and log output?

The AEP version of Conduit (MTCDT-xx-210A) supports OTA (over-the-air) joining by third-party LoRa devices as of version 1.0.33 (If you need to upgrade, refer to the Upgrading Firmware section in the mPower Conduit Software Guide ).

AEP 1.4.16 and above

Devices can be added using Key Management for OTA devices or Device and Session tables for ABP devices.

See the LoRaWAN section in mPower Conduit Software Guide for more details.

AEP 1.4.3 and below

OTA Join Setup

Go to the LoRa Network Server setup page on the Conduit and configure the following settings:

• Enable Public mode
  • This changes the join response time from 1 to 5 seconds and the sync word from 0x12 to 0x34
  • NOTE: Public mode must also be enabled on mDots in order for them to remain compatible (e.g. issue the command AT+PN=1)
• Set Network ID dropdown to EUI (when set to Name, the EUI will be automatically generated from the name)
• Enter an 8 hex byte EUI into the EUI text field.
• Set Network Key dropdown to Key (when set to Passphrase, the Key will be automatically generated from the passphrase)
• Enter a 16 hex byte Key into the Key text field.
• Click Submit to save changes

Third-party LoRa devices should now be able to join the Conduit’s LoRa network using OTA join.

Manual Join/Activation by Personalization

1. SSH into the Conduit (default IP: 192.168.2.1, user -defined device credentials)

   # ssh admin@192.168.2.1

2. Then run this command to start a LoRa server configuration console

   # nc -u localhost 6677

3. Add a node

   node add [DevAddr] [APPEUI] [DEVEUI] [NwkSKey] [AppSKey]

See also: lora-query utility

Example:

# nc -u localhost 6677
node add 00000005 0011223344556677 8811223344556677 2b7e151628aed2a6abf7158809cf4f3c 2b7e151628aed2a6abf7158809cf4f3c

Code base and documentation

• Basic Station Code
• Documentation
• MTCDT station.conf
• MTCAP station.conf
• MTCAP2 station.conf
• MTAC-003 EU868 station.conf
• MTAC-003 US915 station.conf
• MTCAP3 EU868 station.conf
• MTCAP3 US915 station.conf
• MTCAP3 AU915 station.conf

Hardware Requirements

To use basic station an MTCAP or MTCDT with MTAC-LORA-H mCard is required. The Basic Station does not support the MTAC-LORA-1.0 USB cards.
mPower 5.3 includes UI configuration and basic station packages

Connecting to Actility

TLS certs and keys will be downloaded from Actility when Basic Station connects. These files need to be stored in persistent FLASH to be restored after reboot. The firmware mPower 6.3.2 or greater is needed to persist these files. There is a known issue with mPower 6.3.1 where some of these files were being overwritten on reboot.

Connecting to TTN

TTN Basic Station Instructions for Conduit

Logging

The JSON station configuration file has options to enable logging files, level and rotation

https://doc.sm.tc/station/conf.html#logging-setup

The following settings can be used for maximum debugging and rely on the system logrotate process to correctly rotate and gzip files. The Basic Station built-in rotate mechanism does not keep a chronological record over multiple rotate files or compress rotated logs.

 “log_file”: “/var/log/lora-station.log”,
“log_level”: “XDEBUG”,
“log_size”: 1000000,
“log_rotate”: 0,

GPS PPS Settings

On MTCDT, MTCAP and MTCAP3 units without GPS hardware can disable PPS sync to reduce log messages for failed timesync with PPS.

{
“SX1301_conf”: {
“lorawan_public”: true,
“clksrc”: 0,
“pps”: false,

Beaconing Settings

Beaconing parameters should come from the LNS. Since the gateway is configured at the LNS for a specific channel plan, the LNS should be setting the gateway beacon.

TTN supports basic station beaconing since 2022.
https://www.thethingsnetwork.org/forum/t/upgrade-to-the-things-network-v3-21-2-completed/58810

Beacon settings can be provided by the LNS in the router_config or default settings can be provided in the station.conf file place the bcning field into the station_conf section.

The bcning field is either None or a BCNCONF object with the following layout:

{
  "DR"    : INT
  "layout": [INT,INT,INT]
  "freqs":  [ INT, .. ]
}

// Pack parameters into a BEACON pdu with the following layout:

//    | 0-n |       4    |  2  |     1    |  3  |  3  | 0-n |  2  |   bytes – all fields little endian

//    | RFU | epoch_secs | CRC | infoDesc | lat | lon | RFU | CRC |

//

void s2e_make_beacon (uint8_t* layout, sL_t epoch_secs, int infodesc, double lat, double lon, uint8_t* pdu) {

    int time_off     = layout[0];

    int infodesc_off = layout[1];

    int bcn_len      = layout[2];

Beacon Frame Format is found in the LoRaWAN 1.0.4 Specification

LoRaWAN® 1.0.4 Specification Package

Layout settings for each spreading factor:

• SF8 – [ 1, 7, 19 ]
• SF9 – [ 2, 8, 17 ]
• SF10 – [ 3, 9, 19 ]
• SF11 – [ 4, 10, 21 ]
• SF12 – [ 5, 11, 23 ]

Credentials

Select LNS or CUPS depending on server requirements. The LNS protocol will downlink the channel plan from a server. The CUPS protocol and redirect the station process to a network server end-point.

Connecting to TTN Community v3

TTN Instructions

https://nam1.cloud.thethings.network/console
https://eu1.cloud.thethings.network/console
https://au1.cloud.thethings.network/console

https://www.thethingsindustries.com/docs/gateways/lora-basics-station/cups/
https://thethingsindustries.com/docs/gateways/multitechconduit/lbs/

Certificate Information

https://www.thethingsindustries.com/docs/reference/root-certificates/

CUPS

https://nam1.cloud.thethings.network:443
https://eu1.cloud.thethings.network:443
https://au1.cloud.thethings.network:443

Use the following command to view the certificate used by the server.

openssl s_client -showcerts -servername eu1.cloud.thethings.industries -connect eu1.cloud.thethings.industries:443

-----BEGIN CERTIFICATE-----
MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow
MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT
AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs
jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp
Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB
U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7
gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel
/xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R
oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E
BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p
ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE
p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE
AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu
Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0
LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf
r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B
AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH
ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8
S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL
qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p
O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw
UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg==
-----END CERTIFICATE-----

Using CUPS requires creating two API keys for your gateway. The LNS lbs-lns-secret key will be sent to the gateway over the CUPS protocol. The CUPS key will authenticate the gateway when negotiating the CUPS connection.

Creating API keys for CUPS

URI

Set the URI field to point to a network, in this example a TTI private instance is used.

Connecting to TTN Community

Replace “nam1” with “au1”, “eu1” for the desired region.

wss://nam1.cloud.thethings.network:8887

Station Conf

The default station configuration can be used as the network will configure the channels based on the selected channel plan in the TTI configuration.

Server Certificate

TTN Community certificates

https://www.thethingsindustries.com/docs/reference/root-certificates/

Replace “nam1” with “au1” or “eu1” for the desired region.

openssl s_client -showcerts -servername nam1.cloud.thethings.network -connect nam1.cloud.thethings.network:8887

Use the second certificate output by the open ssl command

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----

Gateway Certificate

If a TLS client cert is required to connect to the server provide a certificate. Otherwise leave this field blank for connecting to TTN v3.

Gateway Key

The Gateway Key can be used to populate the authorization header field or be a TLS client key depending on connection method. The Gateway Key needs to be formatted correctly to be used. In The Things Industries v3 GUI, create an API Key with Link as Gateway permissions and copy the key to the text box preceded by “Authorization: ”

Creating the Gateway key for LNS

Authorization: NNSXS.XXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

TTN Community gateway key

Currently the TTN Community servers to not authenticate the gateway key. Any value can be set, the file needs have proper contents to allow parsing by the basic station daemon.

Authorization: NNSXS.XXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Click Save and Apply and the station will be started.

Troubleshooting

If there are issues and the station needs to be run manually, you can ssh into the gateway and issue these commands to see output. The station.conf logging feature can also be used to get messages to find any issue details.

$ /etc/init.d/lora-networks-server stop
$ cd /var/run/lora/1
$ sudo ./station

Installation on MTCDT/MTCAP

Install the Basic Station from downloads.

$ sudo -s
# wget http://www.multitech.net/downloads/lora-basic-station_2.0.3-r1.0_arm926ejste.ipk
# opkg install lora-basic-station_2.0.3-r1.0_arm926ejste.ipk

The /opt/lora/station binary will be installed.

Basic Station to Packet Forwarder

This example python script shows how to send a channel configuration to the connection basic station gateway. It is useful for getting started and ensuring the gateway is functioning.
Basic Station Examples

TTI Configuration

The Things Industries provide private server instances that Basic Station can connect to. Visit TTI for details.

tc.uri

wss://<ORG>.<REGION>.cloud.thethings.industries:8887

wss://multitech.eu1.cloud.thethings.industries:8887

tc.key – Gateway Token

The tc.key file needs to be formatted correctly to be used and can be created with this command. In The Things Industries v3 GUI, create an API Key with Link as Gateway permissions and copy the key to the tc.key file.

echo -en "Authorization: NNSXS.XXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\n" > tc.key

tc.trust

Use the following command to view the certificate used by the server.

openssl s_client -showcerts -servername multitech.eu1.cloud.thethings.industries -connect multitech.eu1.cloud.thethings.industries:8887

-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

Configuration files

• Adjust the station.conf file for the desired frequencies, see examples.Download station.confUse the routerid and euiprefix fields to assign the Gateway EUI.
  See Basic Station Doc for EUI.
• Configure tc.uri to point to the network server web socket port

  ws://192.168.52.72:6090

• For secure web sockets use wss and provide tc.key or tc.trust and tc.crt files

  wss://192.168.52.72:6090

Running the Basic Station

root@mtcdt:/opt/lora$ sudo ./station 
2020-02-26 16:56:02.698 [SYS:WARN] Ignoring field: region
2020-02-26 16:56:02.700 [SYS:INFO] Logging     : stderr (maxsize=10000000, rotate=3)
2020-02-26 16:56:02.700 [SYS:INFO] Station Ver : 2.0.3(mlinux/std) 2020-01-24 16:54:44
2020-02-26 16:56:02.700 [SYS:INFO] Package Ver : (null)
2020-02-26 16:56:02.701 [SYS:INFO] proto EUI   : ::1    (station.conf)
2020-02-26 16:56:02.701 [SYS:INFO] prefix EUI  : ::0    (station.conf)
2020-02-26 16:56:02.701 [SYS:INFO] Station EUI : ::1
2020-02-26 16:56:02.701 [SYS:INFO] Station home: ./     (builtin)
2020-02-26 16:56:02.701 [SYS:INFO] Station temp: /var/tmp/      (builtin)
2020-02-26 16:56:02.701 [SYS:WARN] Station in NO-CUPS mode
2020-02-26 16:56:02.903 [TCE:INFO] Starting TC engine
2020-02-26 16:56:02.908 [TCE:INFO] Connecting to INFOS: ws://192.168.52.72:6090
2020-02-26 16:56:02.912 [TCE:INFO] Infos: ::1 muxs-::0 ws://192.168.52.72:6092/router-::1
2020-02-26 16:56:02.912 [AIO:DEBU] [3] ws_close reason=1000
2020-02-26 16:56:02.913 [AIO:DEBU] [3] Server sent close: reason=1000
2020-02-26 16:56:02.913 [AIO:DEBU] [3] WS connection shutdown...
2020-02-26 16:56:02.916 [TCE:VERB] Connecting to MUXS...
2020-02-26 16:56:02.917 [TCE:VERB] Connected to MUXS.
INFO: FPGA supported features: [TX filter]  [Spectral Scan]  [LBT] 
2020-02-26 16:56:03.219 [S2E:WARN] Unknown field in router_config - ignored: bcning (0x1EE5E245)
2020-02-26 16:56:03.219 [S2E:WARN] Unknown field in router_config - ignored: config (0xF7A3E35F)
2020-02-26 16:56:03.219 [S2E:WARN] Unknown field in router_config - ignored: protocol (0xFD309030)
2020-02-26 16:56:03.220 [S2E:WARN] Unknown field in router_config - ignored: regionid (0xE6FFB211)
2020-02-26 16:56:03.220 [S2E:WARN] Unknown field in router_config - ignored: upchannels (0x7FCAA9EB)
2020-02-26 23:08:46.995 [RAL:WARN] Ignoring unsupported/unknown field: lbt_conf
2020-02-26 23:08:47.049 [RAL:INFO] Lora gateway library version: Version: 5.0.1-mts-1;
2020-02-26 23:08:47.049 [RAL:DEBU] SX1301 txlut table (2 entries)
2020-02-26 23:08:47.049 [RAL:VERB] SX1301 txlut  0:  dig_gain=0 pa_gain=0 dac_gain=3 mix_gain=11 rf_power=-6
2020-02-26 23:08:47.049 [RAL:VERB] SX1301 txlut  1:  dig_gain=0 pa_gain=0 dac_gain=3 mix_gain=13 rf_power=-3
2020-02-26 23:08:47.049 [RAL:VERB] SX1301 rxrfchain 0: enable=1 freq=868475000 rssi_offset=-162.000000 type=2 tx_enable=1 tx_notch_freq=0
2020-02-26 23:08:47.049 [RAL:VERB] SX1301 rxrfchain 1: enable=1 freq=869287500 rssi_offset=-162.000000 type=2 tx_enable=0 tx_notch_freq=0
2020-02-26 23:08:47.049 [RAL:VERB] SX1301 ifchain  0: enable=1 rf_chain=0 freq=-375000 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  1: enable=1 rf_chain=0 freq=-175000 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  2: enable=1 rf_chain=0 freq=25000 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  3: enable=1 rf_chain=0 freq=375000 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  4: enable=1 rf_chain=1 freq=-237500 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  5: enable=1 rf_chain=1 freq=237500 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  6: enable=0 rf_chain=1 freq=200000 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  7: enable=0 rf_chain=1 freq=400000 bandwidth=0 datarate=0 sync_word=0/0
2020-02-26 23:08:47.050 [RAL:VERB] SX1301 ifchain  8: enable=0 rf_chain=0 freq=-200000 bandwidth=2 datarate=2 sync_word=0/0
2020-02-26 23:08:47.051 [RAL:VERB] SX1301 ifchain  9: enable=0 rf_chain=0 freq=300000 bandwidth=3 datarate=50000 sync_word=0/0
2020-02-26 23:08:47.051 [RAL:VERB] SX1301 LBT not enabled
2020-02-26 23:08:47.051 [RAL:INFO] Station device: /dev/spidev0.0 (PPS capture enabled)
2020-02-26 23:08:50.049 [S2E:INFO] Configuring for region: EU863 -- 863.0MHz..870.0MHz
2020-02-26 23:08:50.049 [S2E:VERB]   DR0  SF12/BW125 
2020-02-26 23:08:50.049 [S2E:VERB]   DR1  SF11/BW125 
2020-02-26 23:08:50.049 [S2E:VERB]   DR2  SF10/BW125 
2020-02-26 23:08:50.049 [S2E:VERB]   DR3  SF9/BW125 
2020-02-26 23:08:50.049 [S2E:VERB]   DR4  SF8/BW125 
2020-02-26 23:08:50.049 [S2E:VERB]   DR5  SF7/BW125 
2020-02-26 23:08:50.049 [S2E:VERB]   DR6  SF7/BW250 
2020-02-26 23:08:50.049 [S2E:VERB]   DR7  FSK 
2020-02-26 23:08:50.049 [S2E:VERB]   DR8  undefined
2020-02-26 23:08:50.049 [S2E:VERB]   DR9  undefined
2020-02-26 23:08:50.049 [S2E:VERB]   DR10 undefined
2020-02-26 23:08:50.049 [S2E:VERB]   DR11 undefined
2020-02-26 23:08:50.050 [S2E:VERB]   DR12 undefined
2020-02-26 23:08:50.050 [S2E:VERB]   DR13 undefined
2020-02-26 23:08:50.050 [S2E:VERB]   DR14 undefined
2020-02-26 23:08:50.050 [S2E:VERB]   DR15 undefined
2020-02-26 23:08:50.050 [S2E:VERB]   TX power: 16.0 dBm EIRP
2020-02-26 23:08:50.050 [S2E:VERB]             27.0 dBm EIRP for 869.4MHz..869.65MHz
2020-02-26 23:08:50.050 [S2E:VERB]   JoinEui list: 0 entries
2020-02-26 23:08:50.050 [S2E:VERB]   NetID filter: FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFF
2020-02-26 23:08:50.050 [S2E:VERB]   Dev/test settings: nocca=0 nodc=0 nodwell=0

Description: lora network interface settings : OBJECT (not available on MTR)

LoRa Class C Example

Overview

LoRa motes in class A will only listen for incoming data immediately after it transmits.
If you want the mote to be able to receive data at other times, the mote will need to be in class C. Class C allows the mote to listen for incoming data any time it isn’t transmitting. Class C mode will use much more power, since it is always listening, and must be awake to listen.

Below is quick start guide to setting up Class C on an AEP and a Dot with AT firmware.

Configuring LoRa on Conduit AEP

Login and go to Lora Network Server in Setup.
Click Reset to Default to get in a known state.
Set the Frequency Sub Band.
Set the Network ID to Name and enter a Name below.
Set the Network Key to Passphrase and enter a passphrase below.
Set the Default Profile to DEFAULT-CLASS-C (AEP 1.6.2 and above).
Click Submit.

Configuring the Dot (xDot or mDot)

AT&F to put in known state.
AT+FSB=1 (set frequency sub band to match the Conduit)
AT+NI=1,BDconduit (set network ID passphrase to match Conduit)
AT+NK=1,BDconduit (set network Key passphrase to match Conduit)
AT+DC=C (set Dot to Class C)
AT&W to save settings.
AT+JOIN to connect to Conduit.
AT+SEND to acknowledge Join Accept.
AT+SEND to acknowledge first downlink MAC commands
AT+SD to switch to serial mode. Use +++ sequence to escape serial mode.

Check Node Class in Statistics

Login and click on Statistics.
Select the LoRa tab.
Find the Node for the Dot you had join the network. If you aren’t sure which node is the Dot, check the Device ID on the Dot with an AT&V command and match this to the Node list’s EUI. Most likely the Class will be “A”. This is the default class for a new node.

Change an to Class C (AEP 1.6.4)

LoRaWAN > Devices
Edit Device Row
Set Network Profile to DEFAULT-CLASS-C

Change an to Class C (AEP 1.4.16)

LoRaWAN > Device Configuration
Edit Device Row
Change Class to C

Change an Existing Node to Class C (AEP 1.4.3)

SSH into the Conduit (default IP: 192.168.2.1, default credentials: admin/admin)
Enter the command “lora-query –n” to list the current nodes. Note the Net Addr of the Dot in the node list.
Enter the command “lora-query –node-update 00000001 class C” to set the Dot’s node to class C.
Note: replace the 00000001 value with the Net Addr of the Dot (without the colons).
Enter the command “lora-query –n” to list the current nodes and verify that the Dot node is now listed as class C.
For more information and examples see following link:
https://www.multitech.net/developer/software/lora/lora-network-server/

Sending to Class C Dots in Node-Red

An uplink is needed for the network server to know that the device has received the Join Accept message.
The first down link after Join contains MAC commands and will need to be ACK’d with another uplink before Class C downlinks will be sent freely.

When sending a message to the Node-Red Lora Out node, the msg.eui value must be set on the msg object sent, otherwise the Conduit won’t know which Dot the message is for and won’t be able to send it. It is possible have the Lora Out set to only send to a specific eui value, but setting the msg.eui of the msg object will allow you to send to multiple Dots using the same Lora Out.

When a message is received from Lora In, the msg.eui value is automatically set as the sender, so this message can be successfully sent to Lora Out without setting the msg.eui value.

When sending a Class C message the msg.eui value usually needs to be set manually.
A function node can be used to set the msg.eui before sending it out the lora output node.

In the flow below we will setup an Inject node to output a string message. We will then use a Function node to modify the msg object’s msg.eui value with our Dot’s EUI. We will then output this message to the Lora output node which will transmit the message and the Dot will detect that the message is for it.

Setting Up a Simple Class C Node-Red Flow

Launch Node-Red.
Add an Inject node from the Input section.
Modify the Inject node:
Set Payload to String
Enter a message such as Hello
Leave Repeat set as None.
Add a Function node from the Function section.
Modify the Function node to the following:
msg.eui = “008000000400001b”
return msg;
(Change the msg.eui value to the EUI of the Dot. You can copy and paste the EUI from the Conduit’s LoRa statistics Node List, removing the dashes.)
Connect the Inject node to the input (left side) of the Function node.
Add a Lora node from the Output section.
Connect the output from the Function node to the Lora output node.

Troubleshooting

Make sure that the Conduit is showing the Node as a Class C in its Node List. The Conduit will wait until it receives a transmit from the Dot before sending if it thinks the Node is class A.
Make sure that in your Node-Red flow, the msg.eui value is getting set to the Device EUI of the Dot you wish to send to. Without the msg.eui being set, it will still behave like a Class A and only send the message to the Dot after the Dot transmits to the Conduit.When using the AT firmware, the Dot must be in a serial mode that allows it to output the incoming messages as they are received. When using the AT firmware, use the AT+SD command to put it in serial mode. Note that a +++ will escape out of serial mode so you can issue AT commands again.

Installing Node-Red Flow from Clipboard

Open the Class_C_Clipboard_Flow.txt file, select and copy the entire text for the flow.
In Node-Red, click on the Menu option (3 horizontal lines stacked), hover over Import and select the Clipboard option that then pops up.
In Import Nodes dialog that pops up, paste the previously copied text and click OK.

Installing Node-Red flows.json File

Use a SCP Client (such as WinSCP), connect to the Conduit using the admin credentials, navigate to the “/var/config/app/install/development/” folder and then upload the flows.json file from you PC to the Conduit, overwriting the existing file.
Afterwards restart Node-Red or reboot the Conduit.

Links

Intro to LoRa

Basic Configuration

Advanced Configuration

MQTT Messages

Methods for end-devices to join the Conduit LoRaWAN network

Order of network server join authentication

The first one to succeed will provide the appkey and configuration used for creating the session keys.

1. Network ID and Network Key are checked if the JoinEUI/AppEUI in the Join Request matches the NetworkID
2. If Join Server Location is set to Local Keys, or in mLinux whitelist is enabled
   • The whitelist is searched for the DevEUI and the AppKey and Class setting are used for the device
3. If Join Server Location is set to Cloud Key Store, or in mLinux whitelist is disabled and Lens settings are correct
   • The Join Request is sent to the Join Server to be authenticated, the Lens end-device configuration is returned to the Conduit including the Class setting.

LoRa Query Utility

The LoRa Query Utility provides an easy to use interface to the command port for most operations as an alternative to directly accessing the UDP command port.

lora-query
Version: 1.0.4

Usage: lora-query [-t timeout] [-s] [-n]
        Simple UDP client utility to pull info from LoRa Network server
        --timeout (t)     : UDP recv timeout, default: 100 (msecs)
        --stats (s)       : get LoRa Network server statistics
        --stats-reset (r) : reset LoRa Network server statistics
        --node-list (n)   : get Node List
        --command (x) : send command string to network server
                usage: --command   ...
                ex:    --command device list json
                ex:    -x help
        --json (j)        : data in json format
        --help (?)        : returns this message
        --version (v)     : print version

Examples

End-Device List

> lora-query -x devices

Add End-device
Add a node for ABP or MANUAL network joining

> lora-query -x device add '{"deveui":"00-80-00-00-00-00-e1-9c","class":"C"}'

> lora-query -x session add '{"deveui":"00-80-00-00-00-00-e1-9c","dev_addr":"00112233","appeui":"00-88-88-88-00-00-e1-9c","joineui":"00-99-99-99-00-00-e1-9c","net_id":"000017","app_senc_key":"531bd9c5ec5d8ba5ef3b262cebfb3e66","fnwk_sint_key":"531bd9c5ec5d8ba5ef3b262cebfb3e66"}'

Add a node for OTA join with unique APPKEY

AEP use LoRaWAN > Key Management page in GUI or this curl command, restart of network server is needed after adding

> curl 127.0.0.1/api/loraNetwork/whitelist/devices -X POST --data '{"deveui":"16ea76f6ab663d80","appeui":"0001020304050607","class":"C","appkey":"4c194e20d396b5f7d3e1551e4cd320de"}' -H "Content-Type: application/json"
> curl 127.0.0.1/api/command/save -X POST --data ""
> /etc/init.d/lora-network-server restart

mLinux

> vi /var/config/lora/lora-network-server.conf
...,
"whitelist": {
 "enabled": true,
 "devices": [
     {"deveui":"16ea76f6ab663d80","appeui":"0001020304050607","class":"C","appkey":"4c194e20d396b5f7d3e1551e4cd320de"}
  ]
},
...

Remove an end-device

> lora-query -x device delete 008000df30011a6c

Change node class

> curl 127.0.0.1/api/loraNetwork/whitelist/devices/0 -X PUT --data '{"class":"A"}' -H "Content-Type: application/json"

Command Interface

Connect using netcat

nc -u localhost 6677

or

echo "$x" > /dev/udp/localhost/6677

Where $x is the command to execute.

LoRa Network Server Commands 2.0.19

admin@mtcdt:/opt/lora# lora-query -x help
MTS Lora Server Command Help

Commands:
stats - list current stats
  reset - reset stats for network, gateways and end-devices
gateway - gateway commands
  list - list connected gateways
      format: gateway list [json]
  delete - remove a gateway from the list
      format: device gateway 
device - end-device commands
  add - add a new end-device record
      format: device add 
      example: device add '{"deveui":"00-80-00-00-00-00-e1-9c","class":"C"}'
  stats - show end-device statistics
  update - update end-device configuration or session info
      format: device update   
      example: device update 00-80-00-00-00-00-e1-9c class C
      fields: class, nskey, dskey, ulc, dlc
      format: device update 
      example: device update '{"deveui":"00-80-00-00-00-00-e1-9c","class":"C"}'
      fields: class, name, serial_number, product_id, hardware_version, firmware_version, lorawan_version
  delete - delete an end-device configuration, session and packet records
      format: device delete 
  config - show configuration for a specific device
  reset - reset end-device session counters
      format: device reset 
  list - list end-devices configured in the network server
      format: device list [json | json file ]
      example: device list json
      example: device list json file /tmp/devices.json
  keygen - generate a unique end-device key using zero-touch settings
      format: device keygen  [APP-EUI]
session - session commands
  add - add a session for a device
      format: session add 
      example: session add '{"deveui":"00-80-00-00-00-00-e1-9c","dev_addr":"00112233","appeui":"00-88-88-88-00-00-e1-9c","joineui":"00-99-99-99-00-00-e1-9c","net_id":"0
00017","app_senc_key":"531bd9c5ec5d8ba5ef3b262cebfb3e66","fnwk_sint_key":"531bd9c5ec5d8ba5ef3b262cebfb3e66"}'
      fields: deveui, appeui, joineui, dev_addr, net_id, app_senc_key, fnwk_sint_key
  delete - remove a device session
      format: session delete 
  reset - reset session counters
      format: session reset 
  list - show current device sessions
      format: session list [json | json file  ]
      example: session list jsonvi /
      example: session list json file /tmp/sessions.json
packet - packet commands
  join - list all validated join packets
      format: packet join [json]
  recent - list all recently received packets (unauthenticated)
      format: packet recent [json]
      join - list all recently received join requests
            format: packet recent join [json]
  up - list all validated uplink packets
      format: packet up [json]
  down - list all downlink packets
      format: packet down [json]
  list - list all packets: join, up and down
      format: packet list [json]
  queue - list downlink queue packets to be sent to end-device
      format: packet queue [json]
    add - add a packet to the downlink queue
      format: packet queue add 
      fields: deveui, data, ack, ack_retries, rx_wnd
    delete - delete all downlinks for a specific device
      format: packet queue delete 
    delete - delete one downlink for a specific device
      format: packet queue delete  
database - database commands
  backup - backup database to flash memory
config - show network server configuration
debug - change debug level
ping - ping the network server command port
help - display this help
quit - command network server process to stop

- add 'json' modifier to request output in json

LoRa Network Server Commands 1.0.32

• database backup

LoRa Network Server Commands 1.0.26

• node keygen <DEV-EUI> [APP-EUI] – zero touch key generation

LoRa Network Server Commands 1.0.8

• config – display config
• stats – display stats
• stats reset – reset network server stats
• print error|warning|info|debug|trace – change debug output level
• node list – list nodes
• node add <NET-ADDR> [CLASS] <APP-EUI> <DEV-EUI> { [APP-KEY] | [NET-SKEY] [APP-SKEY] }
  • ABP

    node add <NET-ADDR> [CLASS] <APP-EUI> <DEV-EUI> [NET-SKEY] [APP-SKEY]
    node add 00000001 A 0011223344556677 7766554433221100 00112233445566777766554433221100 77665544332211007766554433221100

  • OTAA with unique APP-KEY

    node add <NET-ADDR> [CLASS] <APP-EUI> <DEV-EUI> [APP-KEY]
    node add 00000001 A 0011223344556677 7766554433221100 00112233445566777766554433221100

• node delete <NET-ADDR> – delete a node
• node config <NET-ADDR> – show node config
• node update <NET-ADDR> (class | appkey | nskey | dskey) <VALUE> – update a config setting
  • change existing node to class C

    node update 00000001 class c

  • change existing node APP-KEY

    node update 00000001 appkey 00112233445566777766554433221100

• node reset <NET-ADDR> – reset node counters
• ping – print alive message
• include <FILENAME> – Read commands from file

LoRa Network Server Commands 0.9.2

• config – display config
• stats – display stats
• stats reset – reset network server stats
• print error|warning|info|debug|trace – change debug output level
• node list – list nodes
• node add <NET-ADDR> <APP-EUI> <DEV-EUI> [NET-SKEY] [APP-SKEY]
• node delete <NET-ADDR> – delete a node
• node reset <NET-ADDR> – reset node stats
• ping – print alive message
• include <FILENAME> – Read commands from file

5.3.5 (10/19/2021)

• Release Notes

5.3.4

Known Issues

• Packet forwarder can stop transmitting after several days, work-around using CRON job to killall -9 lora_pkt_fwd – mPower 5.3.5 has this fixed

5.3.3 (3/29/2021)

• Release Notes

5.2.1 (6/10/2020)

• Release Notes

Known Issues

• Repeated valid join requests can cause the lora-network-server.db to fill the /var/config partition
• Packet forwarder can stop transmitting after several days when LBT is enabled

5.1.6 (3/08/2020)

Bug Fixes

• Web-UI clears local storage on signin to fix browser issues after upgrading

Known Issues

• LoRaWAN FOTA should use non-default Rx2 datarate, US/AU DR10 and other plans DR2 or above. The session may expire and the end-device will return to Class A mode before the firmware has finished broadcasting over multicast.

5.1.5 (3/08/2020)

Bug Fixes

• Fix logrotate issues when configured in packet forwarder mode

Known Issues

• LoRaWAN FOTA should use non-default Rx2 datarate, US/AU DR10 and other plans DR2 or above. The session may expire and the end-device will return to Class A mode before the firmware has finished broadcasting over multicast.

5.1.2 (12/06/2019)

Changes

• See Release Notes

Known Issues

• Packet forwarder logs not being rotated
  • FIX: Update lora-logging IPK to 1.0-r3
• LoRaWAN FOTA should use non-default Rx2 datarate, US/AU DR10 and other plans DR2 or above. The session may expire and the end-device will return to Class A mode before the firmware has finished broadcasting over multicast.

5.0.1(09/04/2019)

Changes since 5.0.0

• Add support for the L4E1 and L4N1 models

Bug Fixes since 5.0.0

• Allow access to SD card, access was lost in 5.0.0.
• Fix for LoRa Network Settings defaulted on upgrade from version <=1.7.4
• Fix two race conditions in LoRa Network Server, one blocked MQTT output, the other would cause a crash on uplink
• Disable node-red logging to /var/log/app/node-red.log, log was not rotating correctly causing RAM to be filled

Known Differences since 5.0.0

• No Known Differences.

Known Behavior in 5.0.1

• User must be at version 1.6.4 (or newer) before upgrading to 5.0.1.
• Although not recommended, downgrading to a version before 5.0.0 will require a
  hard reset back to factory default settings.
• A Hard Reset (or Factory Default) will force 5.0.1 firmware into Commissioning
  Mode to create a new Administrative Username and Password.
• On LVW2, certain newer Verizon SIM’s do not support SMS. Contact Verizon.
• On LVW2, received SMS’s greater than 140 characters may be truncated to 140.
• Command AT+WS46 reverts to default after a power cycle which may affect a user
  that sets a non-default value.
• SMS Command API ignores 6 character password limit, does not fail if SMS is
  longer than 160 characters, has issues depending on location of spaces and can
  not view/delete inbox/outbox.
• Notifications API can delete existing alerts, add new alerts, modify with
  non-existing group, add two groups with same name and generate email with
  bad characters.
• DHCP API can set invalid Gateway.
• With SMS Commands, the Whitelisted numbers may need to be updated to include a +,
  a 1, or full phone number. Send a test SMS to the device to confirm.
• Version 1 API call (/api/v1/whoami) does not respond.
• Connecting OpenVPN Tunnels, user is unable to open WebUI of remote device.
• If using Remote Management and you perform a manual check in to Device HQ, your
  device may show two check in’s based on your Check In Interval.
• The lora-network-server should be updated to from v2.2.30 to v2.2.41 to address a possible deadlock issue

5.0.0 (07/03/2019)

Changes since 1.7.4

• Migration of Web UI to vueJS. Look and Layout has changed.
• Added RADIUS support.
• DHCP Lease Time displays expiration date and time.
• Firewall display/layout aligns more with Linux layout.
• Implement X.509 Certificate support.
• Eliminate Default Username and Password. User prompted to set up a Username and secure Password upon Factory Default/Hard Reset, Commissioning Mode.
• The Logout option has changed to Door Exit icon.
• The browser tab name references page name.
• Changed LogIn screen to sign-in.
• Page links have removed the .html extension.
• Add IPSec certificate based authentication support.
• Updated supported ciphers in multiple features (SSH, HTTPS, etc…).
• Implement Trusted IP feature.
• Implement Self-Diagnostics beta feature to check Resource Overuse and Security Violations.
• Incorporated Signed Firmware support.
• SNMPv3 advanced security settings enhancements and support for multiple trap destinations. Extended SNMP read parameters.
• Usage Policy implementation in the Web UI.
• Display Notifications sent via Email, SMS, or SNMP.
• RADIUS Message Authenticator Attribute was added to all PAP requests.
• Implement tunnel features.
• Implementation of more Network Interface capabilities under Setup > Network Interfaces.
• Updated Global DNS Configuration under Setup > Global DNS.
• Added Bootloader password configuration to the Initial Setup Wizard.
• LoRa Network Server updated to v2.2.27.
• LoRa Packet Forwarder: Added duplicate packet filter, fix for GPS lock and time synchronization and increased radio lead time for better downlink success.
• Updated Help Content.

Bug Fixes since 1.7.4

• Add Statistics page for OpenVPN tunnel.
• Populated leading 0’s in SMS #cellular Command, Uptime now reads 00:00:00 not 0:0:0.
• Fixed “Invalid Date” issue when viewing Remote Management with Firefox 47.
• Fixed SMS Command #cellular eliminating Uptime leading 0’s.
• Fixed device position on GPS page map to not depend on NMEA configuration settings.
• Fixed Generate Certificate so that the City value is not lost and set to empty when generating a new Web server certificate.
• SMS Commands should work again for International numbers.

Known Differences from 1.7.4

• A hard reset/factory default of the 5.0.0 will force Commissioning mode.
• Security modifications may require “sudo” usage if using SSH or debug console.
• Security modifications require a “sudo su” to log into root and adding the following “–unix-socket /var/run/api/http.sock” to existing curl commands.
• Although not recommended, downgrading from 5.0.0 to a previous version will require a hard reset back to default settings. Very important to not downgrade when remote to the device or when using DeviceHQ (Remote Management) because access will be lost.
• On WiFi models, the Dashboard WiFi MAC address now matches the WiFi hardware instead of matching the Ethernet MAC Address. This was improper reporting on the Dashboard only, the WiFi hardware was correct.
• Because of additional GPS options, GPS may take longer to acquire satellites.
• IP Defense options, DoS Prevention, Ping Limit and Brute Force Prevention are Enabled by default.
• Under Adminstration > Access Configuration, SSH via LAN is disabled by default.
• For security, Telnet Radio Access and Telnet have been removed.
• The Clear History buttons have moved from Administration > Debug Options to the Ethernet, WiFi and Cellular tabs under Status & Logs > Statistics.
• GPS NMEA options default with GGA, GSA, GSV and RMC enabled and GLL and VTG are disabled.
• The code version has been removed from the log in screen, it is replaced with the new mPower^™ Edge branding.
• Dashboard banner and Firmware version includes “-AEP”, i.e. 5.0.0-AEP.

Known Behavior in 5.0.0

• User must be at version 1.6.4 (or newer) before upgrading to 5.0.0.
• Although not recommended, downgrading to a version before 5.0.0 will require a hard reset back to factory default settings.
• A Hard Reset (or Factory Default) will force 5.0.0 firmware into Commissioning Mode to create a new Administrative Username and Password.
• On LVW2, certain newer Verizon SIM’s do not support SMS. Contact Verizon.
• On LVW2, received SMS’s greater than 140 characters may be truncated to 140.
• Command AT+WS46 reverts to default after a power cycle which may affect a user that sets a non-default value.
• SMS Command API ignores 6 character password limit, does not fail if SMS is longer than 160 characters, has issues depending on location of spaces and can not view view/delete inbox/outbox.
• Nofications API can delete existing alerts, add new alerts, modify with non-existing group, add two groups with same name and generate email with bad characters.
• DHCP API can set invalid Gateway.
• With SMS Commands, the Whitelisted numbers may need to be updated to include a +, a 1, or full phone number. Send a test SMS to the device to confirm.
• Version 1 API call (/api/v1/whoami) does not respond.
• Connecting OpenVPN Tunnels, user is unable to open WebUI of remote device.
• Firmware upgrade may revert LoRa Network settings to default. Network Mode set to Private LoRAWAN may change to Public LoRaWAN. Rx2 Datarate to 8 for 915 cards and 0 for 868 cards. Rx1 Delay to 1. Join Delay to 1 for Private MTS or 5 for Public LoRaWAN. Additional Channels setting for KR920 and AS923 to 922.9 or 922.6, respectively. MaxEIRP and DwellTime Up/Down for AS923 to 0. WorkAround is to modify /var/config/db.json “__v”: 1 setting in “loraNetwork” collection to “__v”: 18 before the upgrade to avoid reverting. Otherwise modify the above settings after the upgrade.
• If using Remote Management and you perform a manual check in to Device HQ, your device may show two check in’s based on your Check In Interval.

1.7.4 (05/14/2019)

Bug Fixes

• In MTCDT AEP 1.7.3, it was identified that when the Ethernet cable was unplugged and plugged back in, the IP address would revert to the factory default setting (192.168.2.1) instead of the customer-defined IP address. This issue has been corrected.
• In MTCDT AEP 1.7.3, gpsctl occasionally fails to initialize the GPS module, so GPS information is not consistently sent. This has been corrected by downgrading gspd to an earlier and more reliable version (3.16) while continuing to use 3.18.1 libraries.

1.7.3 (04/18/2019)

Changes

• Changes were made to reduce noise during bootstrap, bootloader (u-boot), and kernel device tree on pins connected to the usb hub and GNNS module.

1.7.2 (03/15/2019)

Changes

• The LoRa Network Server has been updated to version 2.2.18.
• The LoRa v2.1 AES key is set by network server for accessing fine-timestamps for geolocation

Bug Fixes

• Fix: LoRaWAN Network Server – Send correct Channel Mask in first downlink for AU/US

1.7.0 (02/27/2019)

Changes

• The LoRa Network Server has been updated to version 2.2.6.
• The GPS functionality has been re-architected for better performance and consistency.
• Configurations downloaded from the device now no longer contain the AppManager.json file. That behavior was found to be problematic, causing App versions to possibly be incorrect.
• A radio reboot feature has been added to reboot the radio when ppp has been unable to connect after all backoff timers have been exercised or ping/tcp connect has failed for ~2 hrs.
• Custom Apps install was enhanced: back up the current app if one exists, and restore it if the new app install fails.
• Support for the MTAC-XDOT card has been added.
• LoRa: Dual Card Support has been added.
• LoRa: RU864 (864- 870 MHz)
• LoRa: Class B support
• LoRa: Class C Multicast

Bug Fixes

• The ICCID on the Radio Status Page has been added back in.
• Radio switching between AT&T and Verizon on the MTCAP models with the LNA3 radio has been fixed.
• A number of help links in the Web UI have been fixed including SMS Configuration.
• Custom Apps: Fixed a race condition between restoring Custom Applications and reboot in User-Defined-Defaults restore.
• SMS issues with international numbers have been fixed.
• LoRa Packet forwarder logs are disabled, the forwarder logging did not work well with logrotate

Known Issues

• LoRaWAN Network Server – US/AU channel plan sends ADR MAC command in first downlink after join that disables all channels. Devices that do not reject it will be silenced. mDot/xDot 3.1.0 with ADR disabled accepts the channel mask and is affected. (Update is pending to repair)

1.6.4 (11/29/2018)

Bug Fixes

• Fix remote management but related to GPS interval that prevents configuration of remote management on devices with no GPS capability

1.6.2 (08/29/2018)

Changes

• Built with Yocto 2.2 (Morty) and mLinux 4.0
• Radio FOTA for H5 and LTE radios
• Enable/Disable call home feature
• Monit added for custom application monitoring
• Back-up custom applications with user-defined-defaults
• Python support for MODBUS and SSL
• LDC3 Radio support
• Netfilter NFLOG, TRPROXY, XT_MATCH_IPRANGE and XT_MATCH_TIME in kernel
• Added libnetnfnetlink and libnetfilter-log to the mPower Conduit^® image to support applications
• Increased RSA cert length to 2048-bits
• SMS Commands
• Firewall – user chanins processed first
• DeviceHQ config upload controls
• OpenVPN Upgrade to v2.4.2
• Certificate upload support
• Bootloader login support
• LoRa Network Server v2.1.5
• Support for LoRaWAN Multicast
• Support for LoRaWAN FUOTA
• Combined LoRaWAN > Devices Configuration and Device Sessions
• Added LoRaWAN menu items
  • Devices
  • Device Groups
  • Profiles
  • Operations

Bug Fixes

• WAN fail-over dnsmasq now updates resolv.conf correctly
• LoRa Network Server downlink queue allows delete through UI, lora-query and MQTT
• Node-RED logs are not rotated
• Packet forwarder manual mode maintained on upgrade from 1.4.3

Known Issues

• GPS error when trying to enable Remote Management on non-GPS units. Workaround using API: https://192.168.2.1/api/remoteManagement?method=PUT&data={"accountKey":"<ACCOUNT-KEY>","enabled":true}

1.4.17 (07/16/2018)

Bug Fixes

• Fix for watchdog when restarted by update from DeviceHQ – it should not monitor api, ppp, or lora
• Fix for WAN manager to setup DNS resolve paths when interface changes are detected
• Firewall – Apply custom user rules first

Known Issues

• Packet forwarder manual mode is not maintained on upgrade from 1.4.3
• IN865: Rx2 frequency for downlink is not set by network server.
  • Workaround by fixing the Rx2 Frequency through the API
    • curl 127.0.0.1/api/loraNetwork -X PUT –data ‘{“lora”:{“rx2Frequency”:866550000}}’
    • curl 127.0.0.1/api/command/save_restart -X POST –data ”
  • If the channel plan is changed the Rx2 frequency setting should be unset
    • curl 127.0.0.1/api/loraNetwork -X PUT –data ‘{“lora”:{“rx2Frequency”:0}}’
    • curl 127.0.0.1/api/command/save_restart -X POST –data ”

1.4.16 (03/29/2018)

Bug Fixes

• Fix for some JoinEUI values creating invalid Join Accept messages to be transmitted
• Fix db migration from AEP 1.4.3/1.4.14 for lora database path

Known Issues

• IN865: Rx2 frequency for downlink is not set by network server.
  • Workaround by fixing the Rx2 Frequency through the API
    • curl 127.0.0.1/api/loraNetwork -X PUT –data ‘{“lora”:{“rx2Frequency”:866550000}}’
    • curl 127.0.0.1/api/command/save_restart -X POST –data ”
  • If the channel plan is changed the Rx2 frequency setting should be unset
    • curl 127.0.0.1/api/loraNetwork -X PUT –data ‘{“lora”:{“rx2Frequency”:0}}’
    • curl 127.0.0.1/api/command/save_restart -X POST –data ”

1.4.14 (03/21/2018)

Changes

• Increase the RSA key length in server.pem (the default self-signed certificate) to 2048 bits.
• Upgrade to wpa_supplicant 2.6
• Upgrade pyserial to version 3.4
• Display LoRa Server and Packet Forwarder versions in web UI.
• Be able to use the lora network server without a mtac-lora card installed
• Update Node-RED to version 0.15.3
• Add support for LDC3 radio
• Custom Apps: Update user defined defaults to backup and restore custom apps installed in /var/config/app. Custom Apps are not uploaded with configuration to Device HQ.
• Add libnfnetlink and libnetfilter-log to AEP 1.4.x and turn on CONFIG_NETFILTER_XT_TARGET TPROXY and NFLOG in kernel
• lora-network-server now version 2.0.18
• Add LoRaWAN Private mode for LoRaWAN compatible network using 0x12 syncword
• Restart lora services if a packet forwarder has not been seen in 10 minutes
• Class C scheduling up to 5 seconds out, instead of failing schedule call multiple times
• Set default join delay to 5 seconds, if null was provided OTA join was not possible
• Fix sample config file JSON error comma at end of list
• Add app port to application MQTT topic for up and packet_sent events
• Allow for application specific filtering such as Multicast or Multipart
  • mosquitto_sub -v -t lora/+/+/+/+
  • mosquitto_sub -v -t lora/<APP-EUI>/<DEV-EUI>/<APP-PORT>/<EVENT>
• PUT update to LENS cloud for end-device class, name, hardware or firmware version if changed on Conduit
• Add some time randomization for class C downlink rescheduling
• Fix for US/AU private mode Rx2, frequency was not correct
• Emit queue_full message if no room left, check of queue size was added before making a call to add the packet
• Lora:
  • show join request result description in hover over
  • statistics for dropped packets has changed
  • add gateway card info to packet forwarder config section
  • do not hide Command to restart lora services based on capabilities.
• LoRaWAN Changes
  • Removed Setup > Lora menu item
  • Added LoRaWAN menu group
  • Added LoRaWAN menu items
  • hide menu items if network server is not enabled.
  • Network Settings
  • Key Management
  • Gateways
  • Device Configuration
  • Device Sessions
  • Packets
  • Downlink Queue
  • Added restart lora services command to commands menu
  • Backup lora database before creating config download
  • Added Packet Forwarder mode configuration UI
  • Updated to Network Server to v2.0.11
  • Added multiple gateway support
  • Added LENS cloud join server support
  • Added LENS cloud statistics support
  • Command API updates to add devices, sessions and downlink packets
  • Added json output options
  • lora-query interface changed to pass commands to network server
  • MQTT event updates for applications

Bug Fixes

• lora-in node fix to reconnect if disconnected from MQTT broker
• Disabled logging on LoRa Packet Forwarder in forwarder only mode to prevent filling up /var/log
• Node-RED LoRa node fixes [IN002602] lora-out node UI cannot be overridden.
• Node-RED mCard and lora node fixes handling lora nodes and new rev of LoRa network server
• Support Portal Case #5084641: Device GPS position data not displaying
• dnsmasq: Starting too early causes it to point to stale empty resolv.conf file
• SNTP: SNTP server settings don’t transfer after device firmware upgrade
• WAN priority defaults after upgrade
• Logging: Setting Debug Options syslog level to INFO doesn’t allow INFO
• Make firmware upgrade error message stay displayed on mPower web UI
• Support #5085601: Lora networking disables if device config from template is used for device config upgrading
• lora packet forwarder does not run after clicking submit button
• ntp_sync: update to call ntpdate with both the -u and -b options
• Radio Firmware upgrade using mPower web UI fails
• Turn off Server Cert Validation in URLopener call for Node-RED app download
• network configuration: Cannot configure the eth0 interface with very restrictive subnet mask
• PPP up and down Verizon (ppp-check process was trying to use ppp0 before it was up – race condition)
• Help link broken for OpenVPN

Known Issues

• Some JoinEUI values sent in the OTA Join Request can cause an invalid Join Accept response, this is fixed in lora-network-server v2.0.19 which is available for download
  • 12-00-00-01-00-00-00-00 is an example value
  • If the last half of 4th byte is greater than zero and the first byte is less than 0x14 an invalid Join Accept may be created
  • If the last half of 4th byte is zero there is no issue with the remaining bytes of any value like this example
  • 12-FF-FF-F0-FF-FF-FF-FF
• Lora end-devices will not be saved over reboot for some configurations. See LoRaWAN > Network Settings > Database > Database Path set to /var/config/lora/lora-network-server.conf or click Reset To Default and reconfigure.

1.4.4 (09/29/2017, released for Conduit IP67 only)

Changes

• LoRa Network Server updated to 1.0.41
• Updates to radio-query and radio-cmd for support of new radios
• Upgrade from mLinux 3.3.6 to mLinux 3.3.12, including MTCDTIP support (mLinux Changelog)

Bug Fixes

• See mLinux fixes from mLinux 3.3.6 to 3.3.12 (mLinux Changelog)

1.4.3 (06/09/2017)

Changes

• Update OpenSSL to be in sync with the mLinux version of OpenSSL for backwards compatibility of applications.
• Update LoRa Network Server to version 1.0.31.  The latest version is available on multitech.net.

Bug Fixes

• Fixed SNTP feature upgrade to preserve non-default configurations.  This bug was introduced in AEP-1.4.1.
• Fixed eglibc memory leak with gethostbyname

Known Issues

• When upgrading to AEP 1.4.3 from a firmware level older than AEP 1.3.2 it is necessary to upgrade to AEP 1.3.3 first and then to AEP 1.4.3 in order to retain the LoRa configuration settings. If it does not matter whether the LoRa configuration settings are retained or not, then it is possible to upgrade from any firmware older than AEP 1.3.2 to AEP 1.4.3.
• Node-Red lora-in node may become disconnected from the broker and not connect again. Edit /opt/node-red/nodes/core/lora/lora.js and move the following code.

  client.subscribe(mqttTopic);

  To the inside of the ‘connect’ handler function.

      }).on('connect', function() {      
        node.log("Connected to MQTT for LoRa in node.");
        setStatus(node, "connected");                                  
        client.subscribe(mqttTopic);                                           
      })

1.4.1 (04/20/2017)

Changes

• WiFi AP and Client support
• Bluetooth IP and BLE support
• Custom Application installation in flash (SD Card no longer required)
• GNSS support (GPS NMEA support)
• WAN failover
• Ethernet Card support
• LoRa support for US915, AU915, and EU915 channel plans
• LoRa network server upgraded to version 1.0.26

Bug Fixes

• The app-manager utility now sets the environment variables correctly for the “Start reload” command after a config file install from Device HQ.
• The size of the fields for the rx_bytes and tx_bytes sent to Device HQ for Cellular stats has been increased and should support far larger values.
• A bug preventing disabling of the LoRa Network Server after it was enabled has been fixed.
• The Multi-Serial Node in Node-RED has been fixed so that RS-485 Half Duplex works and no longer continuously displays “disconnected”.
• The level of OpenSSL has been upgraded to 1.0.2k to address multiple CVE’s.
• An issue has been fixed where the DHCP client would not renew the lease on an Ethernet interface when cable was unplugged for a time and then plugged back in.
• The DHCP server gateway address now gets updated when the IP on the Conduit interface is changed.
• A bug when resetting to User Defined Defaults not working with non-default IP address has been fixed.
• Installing a custom application from Device HQ, deleting it on Device HQ, adding the app back on Device HQ, and then re-installing the app to the Conduit no longer shows two of the same application in the app-manager DB.
• A bug in the Inbound Forwarding Rule menu’s Input Filter Rule not showing the External IP address has been fixed.
• A bug has been fixed involving mPower set for 868, LoRa setting Rx 1 DR Offset drop down menu adds values after changes are submitted.
• A bug has been fixed involving LNS not sending LoRa downlinks with CRC disabled.
• A bug has been fixed involving AS923, join on Rx2 NS uses DR0.

Known Issues

• When upgrading to AEP 1.4.1 from a firmware level older than AEP 1.3.2 it is necessary to upgrade to AEP 1.3.3 first and then to AEP 1.4.1 in order to retain the LoRa configuration settings. If it does not matter whether the LoRa configuration settings are retained or not, then it is possible to upgrade from any firmware older than AEP 1.3.2 to AEP 1.4.1.
• There is limited support fro running Wi-Fi Access Point and Client Mode concurrently at 2.4GHz. When concurrent mode is configured, the channel is not configurable because the channel is restricted to be the same as the channel the Wi-Fi client mode gets. To perform a Wi-Fi scan for access points when Wi-Fi client is connected, all “Saved Wi-Fi Networks” must be disabled.
• It is not recommended to use Wi-Fi 5GHz in concurrent mode with Access Point and Client modes both enabled.
• The version of mLinux stated on the mPower Conduit firmware 1.4.1 is 3.3.5. The mLinux version contains every commit for mLinux 3.3.6 except the commit that updates the revision and got tagged. So, in essence it is the same as mLinux 3.3.6.

1.3.3 (11/17/2016)

Changes

Bug Fixes

• Leave Node-RED enabled on upgrade

1.3.2  (9/15/2016)

Changes

• Custom Application Support
• Configuration File Management for Custom Applications
• Partial Configuration Download
• LoRa network server upgraded to version 1.0.13
• LoRa Web UI changes adding ADR support
• Updated and new help content

Bug Fixes

• Fix: Add support for decoding GSM PDU encoding characters
• Do not set or allow setting LVW2 APN -> provider automatically sets APN
• ppp doesn’t connect after the SIM card is ejected and inserted again
• LEU1: Ping feature not working, increase ping data size due to provider/SIM limitation on minimum ICMP data size
• Diversity gets disabled on LTE models – Initial Setup Wizard was defaulting diversity to false for LTE models
• lora: query MTAC-LORA card frequency band on set defaults.
• lora_pkt_fwd logging is disabled, process can be run manually to debug issues

Known Issues

• Node-RED will be disabled after upgrading to 1.3.2, but you can re-enable it in the UI or through DeviceHQ (this will be fixed in the next release)
• With 868 MTAC_LORA card installed, LoRa Network Server configuration must be set to EU868 channel plan after update.

1.2.2  (6/8/2016)

Changes

• Upload LoRa stats to DeviceHQ
• Upload system logs to DeviceHQ
• Upload Node-RED application status to DeviceHQ
• Make Node-RED settings.js modifiable. You can now modify this file without it being overwritten each time node-red restarts.
• Add LoRa support for ADR (Adaptive Data Rate)
• Improve Node-RED serial card performance by 10x
• Added support for LTE radios
• Improve LoRa config UI
• Upgrade help content framework and theme
• Upgrade lora network server to 1.0.8

Bug Fixes

• Fix IE11 save & restart
• Fix LTE radio RSSI isn’t updated after removing antenna
• Fix only update system time in initial setup wizard if user is changing it
• Fix sms send truncation on C2 radio SMS messages
• Fix C2 receive SMS being truncated.
• Fix for sms: characters like @ $ not working on CDMA & LVW2 multi-part sms
• Fix Issue where “broken” tar files for apps were still “installing” the app though it could not run and was effectively broken.
• Fix for updating time in the initial setup wizard -> only updates time when user has changed it in the wizard.
• Fixed a bug in the jsparser that should resolve the DHCP lease expiration time issue.
• Add npm utility back in, got removed because openEmbedded moved npm utility to a different package than nodejs.
• Fingerprint assets (js/css) to fix caching issues
• Fix restart page to redirect to login.html instead of dashboard.html
• Remove password from lighttpd & api logging
• Fix don’t validate DHCP form if not enabled
• Fix app upload input fields too narrow
• Fix LTE PPP doesn’t work when SIM requires PIN
• Fix lora address range can’t be lowercase
• Fix redirect to login page after factory default goes to wrong IP
• Fix firewall rule description hover help not working
• Fix initial setup wizard: change to LAN lost when backing through wizard
• Fix sms characters = + and ` (but ` doesn’t work with all carrier combinations)
• Fix Remote Management – device not consistently checking into DHQ at scheduled interval
• Fix LoRa stats and nodes to DeviceHQ: reset appears to cause API to not return anything for node list on the Conduit.
• Fix when Node-RED restarted, serial streamer instances not getting killed
• Fix cases where firmware upgrade would fail
• Fix LoRa logging: lora-pkt-fwd-1.log not getting rolled and keeps on growing.

Known Issues

• lora-pkt-fwd-1.log still not being rotated. Will consume all RAM if unchecked.

1.1.2  (1/27/2016)

Changes

• Add LoRa Packet Forwarder Mode
• Upgrade Nodejs to 0.10.40
• Upgrade Node-RED to 0.11.1
• Make LoRa logging level configurable through the UI.
• Update Node-RED SMS node to use only HTTP instead of HTTPS to conserve memory.
• Change Node-RED log to always be /var/log/app/node-red.log
• Improve Time Configuration UI
• Improve Initial Setup Wizard
• Feature: On Install Apps page, change “options” to “actions” and use better icon.
• Add support for no-radio and LTE models.
• Add Node-RED LoRa out support for requesting ACKs and setting the LoRaWAN FPort
• Add Node-RED M2X node.
• Improve stability & UI of multi-serial card nodes in Node-RED. Remove option for DTR/DSR flow control and 5 and 6 data bit options.
• Add popup prompt if configuring lora network server without enabling it
• Update LoRa Network Server to 0.0.9-2
• Update LoRa packet forwarder to 1.4.1-r9

Bug Fixes

• Fix Node-RED gpio node error message
• Fix Node-RED sms UTF8 support.
• Fix can’t browse to Node-RED via WAN port.
• Fix sms to correctly handle characters like @ $ etc.
• Fix firewall – lost access to box after enabling NAT Loopback on Prerouting Rule
• Make default LoRa log level to be 30 instead of 100
• Fix “SIM card is locked. Requires SIM Pin” message after enabling Dial-on-Demand
• Fix can’t save default lora configuration
• Fix Save & Restart not red after adding fixed DHCP address
• Fix can’t add DHCP fixed address when using non-default subnet
• Fix can’t configure DHCP infinite lease time
• Fix can’t login to web interface with password containing ‘&’

Known Issues

• npm is no longer in this version (unintended), but will be added back in the next release.
• DHCP Server does not respond to requests if lease time is set to 11-13-47 or higher. Will be fixed in next release

1.0.33  (9/2/2015)

• First official release!