[Jason Reiss]

P2P in libxDot uses a different sync word from those used with LoRaWAN. The P2P packets will be filtered just as with Private/Public network LoRaWAN packets are.

Also the P2P mode uses an IQ setting same as a gateway transmission. This allows the Dots to received each others packets, but will not allow a gateway to hear them, just as gateway packets are not received by other gateways.

The packet forwarder could be modified to support this type of operation.
The IQ setting would need to be reversed and sync word changed to 0x56.
These resources can help you if that is something you are willing to endeavor.

https://github.com/Lora-net/packet_forwarder
http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora?h=3

Building Images

C/C++ Toolchain

[Jason Reiss]

https://github.com/kersing/packet_forwarder/blob/cb0f92f1c9a8bd85bf68da0328c2180c9d67dc71/mp_pkt_fwd/src/gwtraf_transport.c

If gps is available then line 347 adds the timestamp
should add timestamp with microseconds (nanos/1000)

[Jason Reiss]

Do you know which packet forwarder is installed?

This one recommends using the Semtech or Kersing version, apparently development has stopped.
https://github.com/TheThingsNetwork/packet_forwarder

Here is Kersing, configuration is similar to Semtech instructions.
https://github.com/kersing/packet_forwarder/blob/master/mp_pkt_fwd/global_conf.json

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

[Jason Reiss]

For Semtech packet forwarder configuration add this setting to global_conf.json “server_conf” section to enable gps parsing and timestamping.

“gps_tty_path”: “/dev/ttyXRUSB2”,

[Jason Reiss]

The timestamp applied by the packet forwarder will not have sub-microsecond accuracy. It is the time that the packet is read from the FIFO buffer.

The Semtech packet forwarder should attach timestamps to the micro-second.
https://github.com/Lora-net/packet_forwarder

The TTN packet forwarder developers would need to be contacted to get greater precision into their packets.

[Jason Reiss]

Yes it will sleep after end of tx until the start of rx1.

[Jason Reiss]

The dev version of the library has this as an option.
It will be included as a feature in the next release.

https://os.mbed.com/teams/MultiTech/code/libmDot-dev-mbed5/

/**
* Set auto sleep mode
* Auto sleep mode will automatically put the MCU to sleep in between receive windows
* Note: The MCU will go into a stop mode sleep in between rx windows. This means that
* peripherals such as timers will not function during the sleep intervals.
* @param enable – Flag to enable auto sleep mode
*/
void setAutoSleep(bool enable);

[Jason Reiss]

To interact with sensors you will need to do some custom development with mbed.

https://os.mbed.com/platforms/MTS-mDot-F411/

[Jason Reiss]

That depends on your development language.

https://sqlite.org/

SQLite Node.js

[Jason Reiss]

It is not on Conduit, it is a build tool used on a PC to cross-compile images for use on the Conduit.

SQLite is a database used on Conduit for some applications, you may have better success than using MySQL depending on your use case.

In general MySQL is a feature rich SQL server implementation beyond the needs of most embedded applications.

[Jason Reiss]

AEP is built using mLinux, the opkg utility will pull from the mLinux version feed directory.

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

There is no mysql-server package in the feeds. There are mysql client libraries to use for applications connecting to remote mysql servers.

A MySQL package to install in mLinux can be created using bitbake with the correct openembedded recipies.

mLinux

[Jason Reiss]

I suggest upgrading to mLinux 3.3.13

# mts-io-sysfs show lora/*
MTAC-LORA-915
MTAC-LORA-1.0

1.0 cards should use USB packet forwarder

If conduit has internet try
# opkg update
# opkg install lora-packet-forwarder-usb

[Jason Reiss]

The frame counter (83 and 93) in the later “packet_recv” events is lower than the last “up” event (111). The network server will reject packets with lower than last frame counters to prevent replay attack and only publish the “packet_recv” for duplicate/replays. The “up” events should continue when the end-device frame counter exceeds the highest received counter.

https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=QAFJUkSAUwADUmTQfG0FfQmb4w%3D%3D&nwkskey=&appskey=

[Jason Reiss]

This init script is used only if the Conduit is to be configured for packet forwarder only mode. On a network server Conduit is should be disabled.
/etc/default/lora-packet-forwarder

On the Network Server Conduit:
Remove any global_conf.json and local_conf.json files.
The network server will create a global_conf.json file for the packet forwarder.

Is the packet forwarder output from the Network Server Conduit?
Did you run from /var/run/lora/1/ or from /opt/lora/ directory?

mLinux 3.3.13 is our latest release version

Downloads

To see your installed version check this file
# cat /etc/issue

mLinux should not have a firewall enabled by default.

[Jason Reiss]

Are you using mLinux or AEP? What version?
Is this a setup you had working at one point and now it is not working?

Can you elaborate on the network problem causing the LoRa AP to stop?

The network server requires a packet forwarder to send packets from the radio hardware. A packet forwarder process should be started by the network server init script.

Can you check the packet forwarder process on the LoRa GW?
# ps -A | grep lora

Or try to start manually to see if there are error?

# cd /var/run/lora/1
# ./lora_pkt_fwd

For the network server to receive from the remote gateway the firewall must be opened and the network server configured to listen on the public ethernet interface. The “udp” > “allowPublic” setting must be set true.

[Jason Reiss]

Appears to be working from here.

[Jason Reiss]

We have an update for AEP soon to be released.
It has a fix to reconnect the lora-in node

See /opt/node-red/nodes/core/lora/lora.js

The current release has this line outside of the ‘connect’ handler
client.subscribe(mqttTopic);

The fixed code for SetupLoraInNode function:

  function SetupLoraInNode(node, config) {
    var mqttTopic = 'lora/+/up';
    var client = mqtt.connect(mqttServer).on('error', function(error) {
      node.error("LoRa in node MQTT error: " + error);
      setStatus(node, "error");
    }).on('connect', function() {
      node.log("Connected to MQTT for LoRa in node.");
      setStatus(node, "connected");
      client.subscribe(mqttTopic);
    }).on("reconnect", function() {
      node.log("LoRa-IN node reconnect");
      setStatus(node, "disconnected");
    }).on("error", function() {
      node.log("LoRa-IN node error");
      setStatus(node, "disconnected");
    }).on('message', function(topic, message) {
      var arr = topic.split("/");
      var obj = JSON.parse(message);
      var data;
      if (config.datatype === "utf8") {
        data = new Buffer(obj.data, 'base64').toString('utf-8');
      } else if (config.datatype === "bytes") {
        data = new Buffer(obj.data, 'base64');
      } else {
        node.error("Invalid datatype.");
        return;
      }
      if (obj.data) { // moving the data to the payload for use in Node-RED
        obj.payload = data;
        delete obj.data;
      }
      obj.eui = arr[1];
      node.send(obj);
    });
            
    node.on("close", function() {
      node.log("LoRa in node closing...");
      setStatus(node, "disconnected");
      client.end();
    });
  }

[Jason Reiss]

It’s interesting that they send the answer in the payload instead of using the FOpts field.

Since the application is allowed to send packets using port 0 it may make sense to also forward port 0 packets to it?
It is an uplink from the end-device, same as an empty uplink packet is forwarded to the application.

The application can easily filter packets on the “port” field.

[Jason Reiss]

What channel plan are you using?
I will assume EU868

Are you using 1.4.1 or 1.4.3 or both act the same?

Both look like mac command answers
0703 is a new channel request answer
0307 is an adr command answer

The updated network server sends down a packet in the first downlink to define channels for DR6 and DR7

What port is the packet being received on from the end-device?
If the FOpts is empty and the payload contains MAC commands it should be received on port 0.
Packets sent using port 0 should not be forwarded to the application.

How is your application receiving packets in node-red? MQTT node or LoRa-IN node? Can you post an example of the json received.

[Jason Reiss]

These SDRs are good for trouble shooting or a high power screen saver!

[Jason Reiss]

No packets are being received expect the CRC errors
# RF packets received by concentrator: 0

Are you certain the device is transmitting?
Do you have anything that can measure RF, and SDR radio or Spec Analyzer?

Gateway firmware update would install the same packet forwarder.

Can you post the hardware details?
$ mts-io-sysfs show lora/*

[Jason Reiss]

You have an older USB card?

It uses packet forwarder version Version: 1.4.1
Are you using the default binary provided with mlinux?

This version does not support the setting lorawan_public.

Try added a synch_word setting.

"gateway_conf": {
	"synch_word": 52,

[Jason Reiss]

This is interesting?
mtac-lora private;

You can try to set you device to private mode.

What is your gateway global_conf.json file?

Is there a synch_word setting?
Private – 18
Public – 52

[Jason Reiss]

LoRaWAN protocol does not allow reuse of frame counters. It is a security risk.

The AEP 1.4.4 firmware rejects them by default.

Disable "enableStrictCounterValidation"

[Jason Reiss]

Quite often the gateway can receive a false-positive lora packet.
The CRC filters these out, it is not necessarily created by your end-device.

You can check the packet forwarder config at /var/run/lora/1/global_conf.json

You can double check that the default frequencies are configured and lorawan_public is set to true.

Try to run the packet forwarder manually and see if you receive packets.

$ /etc/init.d/lora-network-server stop
$ cd /var/run/lora/1/
$ ./lora_pkt_fwd

[Jason Reiss]

If the device is reset and counters are not saved then they will have to catch-up the counter to the previous value in the uplink.

[Jason Reiss]

frenquencysubband does not apply in EU868, sorry I missed that.

Is the end-device using 868 frequencies?

#define USE_BAND_868

[Jason Reiss]

Are the devices joined via OTA or ABP?

How do you shutdown the device? Pulling power will not allow the database to be backed to flash.

The database is backed-up to flash on a 1 hour interval.

Try to backup the database after adding your nodes.
$ nc -u localhost -p 6677
database backup

There will still be an issue for downlink counters if the power is pulled without backup. Uplink counters can be caught-up when power is back. But the downlink frames will be rejected until the counter exceeds the previous value.

[Jason Reiss]

Try “frequencySubBand”: 1

You may need to dig into the code to enable a subset of frequencies.
#define USE_BAND_915_HYBRID

The device will use 64 by default but the gateway can only listen on 8.
You may need 8-16 join requests before one is successful.
It should search each frequencySubBand setting during the join process.

Once a join is successful the network server will send down MAC commands to enable only the 8 channels configured in frequencySubBand setting.

[Jason Reiss]

The network server controls the gateway transmit channels, and sends the frequency/datarate/timestamp/payload to the gateway for downlink.

The gateway configuration controls the gateway receive channels.

[Author]

Posts