[Jason Reiss]

https://www.exar.com/design-tools/software-drivers

[Jason Reiss]

Install exar driver

Configuration Mode

[Jason Reiss]

The AT Firmware is an example of using the serial port with mDot
https://os.mbed.com/teams/MultiTech/code/Dot-AT-Firmware/

Here is the serial class used in AT Firmware
https://os.mbed.com/teams/MultiTech/code/MTS-Serial/

[Jason Reiss]

Save and restart is the sure way.
The next version will have current process status and a restart button in the GUI to be pressed after changes are made.

Cheers,
Jason

[Jason Reiss]

This api end-point will change the rx2 frequency used by the network server for downlinks.

/api/loraNetwork?method=PUT&data={"lora":{"rx2Frequency":867100000}}&apply=now

On join the default will still be used for the join accept message in OTA.

The end-devices will not be notified of the different rx2 frequency automatically. A mac command can be sent from the application through the network server on port 0.

Rx Param Setup Request

867.1 => 0x844f18 >>byte-reversed>> 184f84

ID | Rx1Offset / Rx2 Datarate | Rx2 Frequency
05 | 0 0 | 184f84

0500184f84 –to base64–> BQAYT4Q=

Send downlink to end-device to change Rx2 Frequency.
{"port":0, "data":"BQAYT4Q="}

The 869.525 default frequency is used for the 10% duty-cycle property.
Other channels will be limited to 1% duty-cycle.

[Jason Reiss]

Yes, the tmst values should accurately reflect elapsed time as shown in your calculations. I would expect these readings to have some jitter between conduits.

Comparing the “time” values give these differences.

2.328651
2.328650

[Jason Reiss]

The Rx2 Frequency is not currently customizable.

The API can be modified from node-red to affect any configuration parameters of the Conduit. See the Conduit API.

Conduit mPower API

[Jason Reiss]

I do not believe it is possible to use the tmst values or timestamps attached to the packets for sub-microsecond TDoA calculations as mentioned in my first response to this thread.

GNSS module fix

There will be a difference in the SNR for each receiver and the demodulators may register a packet done event based on slightly different input levels. The tmst value is the end of the packet demodulation not precisely the start of packet arrival or the end of packet transmission.

tmst | number | Internal timestamp of “RX finished” event (32b unsigned)

A new gateway hardware that provides accurate fine-timestamps is being developed to provide geo-location based on TDoA calculations.

The tmst values are independent internal counters. They maybe sync’d to the PPS to allow transmit on a GPS timestamp to be started on the signal edge.
https://github.com/Lora-net/packet_forwarder

Line 1625 shows the tmst value used to create an accurate timestamp based on the GPS input and sync’d clock.
https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c

[Jason Reiss]

Good to hear you are successfully working with the new server code.

[Jason Reiss]

See the mDot at firmware for an example of setting up custom event handlers.
https://os.mbed.com/teams/MultiTech/code/Dot-AT-Firmware/?platform=MTS-mDot-F411

Using the setEvents function a custom event handler can be provided to the dot library.

CommandTerminal.h and CommandTerminal.cpp define a RadioEvent object inheriting the mDotEvent Class.

Be sure to call the base class functionality to fill the packet _flags and _info objects of the mDotEvent.

CommandTerminal.h

class RadioEvent : public mDotEvent { ...

CommandTerminal.cpp

void CommandTerminal::init() {
    _dot->setEvents(_events);
}

void CommandTerminal::RadioEvent::PacketRx(uint8_t port, uint8_t *payload, uint16_t size, int16_t rssi, int8_t snr, lora::DownlinkControl ctrl, uint8_t slot, uint8_t retries) {
    mDotEvent::PacketRx(port, payload, size, rssi, snr, ctrl, retries);
 
    if (serial_data_mode) {
        logDebug("Rx %d bytes", size);
        if (size > 0) {
            CommandTerminal::Serial()->write((char*) RxPayload, RxPayloadSize);
        }
        if (!CommandTerminal::Serial()->readable() && _dot->getAckRequested() && _dot->getClass() == "C") {
            _sendAck = true;
        }
    }
}

[Jason Reiss]

Is the dev_addr being used by another device?

The lora-network-server log may have more details.

[Jason Reiss]

CommandTerminal.cpp shows the code for a received packet. It should write to the serial port when in serial data mode and a packet is received with port != 0.
You should also see debug output for the number of bytes received for each packet.

void CommandTerminal::RadioEvent::PacketRx(uint8_t port, uint8_t *payload, uint16_t size, int16_t rssi, int8_t snr, lora::DownlinkControl ctrl, uint8_t slot, uint8_t retries, uint32_t address) {
    mDotEvent::PacketRx(port, payload, size, rssi, snr, ctrl, slot, retries, address);

    if (serial_data_mode && port != 0) {
        logDebug("Rx %d bytes", size);
        if (size > 0) {
            CommandTerminal::Serial()->write((char*) RxPayload, RxPayloadSize);
        }
        if (!CommandTerminal::Serial()->readable() && _dot->getAckRequested() && _dot->getClass() == "C") {
            _sendAck = true;
        }
    }
}

[Jason Reiss]

The gateway is receiving duplicate packets from a single uplink.
In previous network servers this can affect the downlink frequency chosen.

Try to upgrade the network server to v1.0.43. It will filter out packets from the adjacent channels.

Downloads

[Jason Reiss]

To see all options for network server commands`
# lora-query -x help`

For ABP device registration first a device record is added then a session created for the device. The appeui will be attached to uplinks, the joineui is for recording purposes, it would have been sent in an OTA join.

# 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-1-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"}'

The whitelist is for OTA devices, records in the list should be as follows:

{ "deveui": "", "appeui": "", "appkey": "", "class": "A" }

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

[Jason Reiss]

We have created a guide for the next version AEP 1.4.12 with network server v2.0.16.

https://www.multitech.net/developer/wp-content/plugins/download-monitor/download.php?id=44

Please post if additional details are needed and we will incorporate them in the guide.

[Jason Reiss]

There are several threads on TTN with similar issues and more discussion points than I can cover.
https://www.thethingsnetwork.org/forum/c/gateways/multitech-gateway
https://www.thethingsnetwork.org/forum/t/latest-multitech-packet-forwarder-stops-sending-packets/7199/57
https://www.thethingsnetwork.org/forum/t/multitech-ttn-connection-lost-after-bad-connectivity/12355/34

[Jason Reiss]

I was going to suggest the ttn forum as well, but you are already there!
https://www.thethingsnetwork.org/forum/t/multitech-ttn-connection-lost-after-some-days/13017

The log has this message but the unit is working after reboot?

Take note of the IP address on PPP
$ ifconfig

When the device fails check again if the IP address has changed on the cellular interface.

Try to add “autoquit_threshold” to the gateway config to restart if the IP changes.

Check that there is only one packet forwarder process running
$ ps -A

Try to stop the packet forwarder, reset the lora card, then start the packet forwarder. This should occur on reboot
$ mts-io-sysfs store lora/reset 0
$ mts-io-sysfs store lora/reset 1

Check that the card hardware is functioning, cdone should go low when creset is low.
$ mts-io-sysfs show lora/cdone
$ mts-io-sysfs store lora/creset 0
$ mts-io-sysfs show lora/cdone
$ mts-io-sysfs store lora/creset 1
$ mts-io-sysfs show lora/cdone

[Jason Reiss]

Is AT+PN=0 on the Dot Box
And Public is unchecked with Join Delay of 1 on the Conduit?

Or

Is AT+PN=1 on the Dot Box
And Public is checked with Join Delay of 5 on the Conduit?

[Jason Reiss]

Tx on the end-device and gateway are limited by Duty Cycle. Band 0 is 1% duty-cycle.

The only way to not hit the limit and maintain regulations is to transmit less often.

[Jason Reiss]

When I install the example as provided both LEDs are blinking.

On the UDK board
LED2 -> D3 (led1)
XBEE_RSSI -> D15 (led2)

[Jason Reiss]

You could try using ADR or increasing the uplink or downlink datarates.
This could allow smaller packets and reduce the chance of scheduling collisions.

There is no method for coordinating Class A transmissions to work around the randomness.

[Jason Reiss]

Five additional channels can be configured.

For 863.5-867.5 they will be centered around the configured frequency.

4-> 867.1 – SF7BW125 to SF12BW125
5-> 867.3 – SF7BW125 to SF12BW125
6-> 867.5 – SF7BW125 to SF12BW125
7-> 867.7 – SF7BW125 to SF12BW125
8-> 867.9 – SF7BW125 to SF12BW125

For 869.1-869.5 there are only four channels available due to alarm bands.
The radio frequency will set to 869.4 and channel as follows.

869.4 => Channels 868.8, 869.0, 869.525, 869.8

Functionality depends on installed version.
See 1.0.35 in change log for last change to the behavior detailed above.

LoRa Network Server Changelog

[Jason Reiss]

I have also noticed that the “opkg install python-pip” does install a functioning pip. But it must be installed before the ez_setup.py is used.

[Jason Reiss]

33 bytes it the join accept message.

The network server will send down the dwelltime params in the first few downlinks if dwelltime is enabled or one downlink if it is not enabled at the server. The network server will not know if the end-device is defaulted to dwelltime on to send a join accept without the CFList.

It may be assumed a device will join with the dwelltime disabled.

Have you raised the issue with the main source project?
https://github.com/Lora-net/LoRaMac-node

[Jason Reiss]

Choose from one of the available folders.
http://multitech.net/mlinux/feeds/

[DIR] 3.2/ 14-Jun-2016 16:57 –
[DIR] 3.3.6/ 21-Apr-2017 13:05 –
[DIR] 3.3.7/ 27-Jun-2017 13:16 –
[DIR] 3.3.9/ 27-Jul-2017 14:34 –
[DIR] 3.3.12/ 11-Sep-2017 10:39 –
[DIR] 3.3.13/ 06-Oct-2017 17:49 –
[DIR] 3.3.14/ 30-Oct-2017 09:53 –
[DIR] 3.3.15/ 30-Oct-2017 10:00 –

[Jason Reiss]

What is the output to this command?
$ mts-io-sysfs show lora/*

[Jason Reiss]

Try the upgrade without the lora card installed.

[Jason Reiss]

Here is an example program: Ticker, Timer and RtosTimer all seem to work.
https://os.mbed.com/users/jreiss/code/Ticker_libmDot/

[Jason Reiss]

The library still uses RtosTimer. Have you tried using it?

[Jason Reiss]

It has been disabled in the init script.

There is an update for USB packet forwarder for MTAC-LORA-1.0 cards
http://www.multitech.net/downloads/lora-packet-forwarder-usb_1.4.1-r11.0_arm926ejste.ipk

The packet forwarder can be run manually for debugging.

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

[Author]

Posts