[Jason Reiss]

A US915 gateway does not respond with a downlink on the same frequency.

Are you using TTN as network server?

Be sure the channel plan chosen for the gateway is US915.

[Jason Reiss]

There is limited support in the current release.

Our next release includes unique DevEUI/AppKey configuration as a main feature.

[Jason Reiss]

This issue can occur when the same appkey is used for end-devices.

The remedy is to use a unique key for each end-device.

Or add a confirmed uplink that must be responded to following the join accept. Only the intended device will create the correct session keys using its random devnonce.

Of course multiple end-device could randomly select the same devnonce for the join request and create the same keys.

[Jason Reiss]

We will have an update soon to add the IN865 option.

Until then the API will reset a change in the ChannelPlan field
The API for the lora network can be disabled by changing the init file to point to a static lora-network-server config file.

conf_file=$conf_dir/lora-network-server-test.conf

Then adjust /var/config/lora/lora-network-server.conf file on the Conduit with these settings in the “lora” section.

cat /var/config/lora/lora-network-server.conf | jsparser --jsobj > /var/config/lora/lora-network-server-test.conf

Edit /var/config/lora/lora-network-server-test.conf
“channelPlan”: “IN865”,
“frequencyIN”: 866385000

Any changes made in the network server GUI will not be reflected.
Re-installation of the lora-network-server IPK or firmware update will revert this change.

[Jason Reiss]

You can adjust the counter values in mDot with these commands.
AT+DLC – Downlink counter
AT+ULC – Uplink counter

If you have multiple conduits in range and all have ABP session information for the end-device, any one of them can receive the uplink or author a downlink for the device.
However there will be issues with keeping the downlink counter in sync between the dot and conduits if it moves around, out-of-range at times, or if two gateways are responding to the same packet.
If this is an uplink only network this may work OK as long as the counter does not get ahead of the gateway by 16k packets.

With mDot there is NVM available to store the counter values over a reset.

AT+SS – save session before reset
AT+RS – restore session after reset

[Jason Reiss]

Looks like there was a recent change to add MTCAP-0.1 hw support to the utility. It will not work for MTCAP-0.0, perhaps you have a early rev?

$ mts-io-sysfs show hw-version
MTCAP-0.1

28 was an intermediate release for the v1.5 cards and AP units.
The spectral scan utility may be different from 31.
Other LoRa rx/tx operations are same.

We use 31 and 33 in our cards and AP units.
31 – spectral scan
33 – listen-before-talk

[Jason Reiss]

Actually here are the latest.
http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora?h=3

There is patch to add FPGA version 28, 31, and 33 that is different.

# mts-fpga-loader -c
Checking hardware compatibility
Found Valid Hardware: MTCAP-LORA-1.5
Valid FPGA version: 31

On Conduit AP

spidev0.0 is the lora card
spidev0.1 is a spi flash

mts-io-sysfs show lora/*

This should return 1
mts-io-sysfs show lora/cdone

To reset the card
mts-io-sysfs store lora/creset 0
mts-io-sysfs store lora/creset 1
mts-io-sysfs show lora/cdone

[Jason Reiss]

Did you try the card in each slot?

[Jason Reiss]

Here is a link to our recipes and patches for the packet forwarder and gateway.
http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora

[Jason Reiss]

Here is a link to the v1.4.1 release source
https://github.com/Lora-net/packet_forwarder/tree/0011a60759a7d81656a5393e97089daab1ff1a81

[Jason Reiss]

If the “older” conduits have USB lora cards then basic_pkt_fwd is used.
Release v1.4.1 of packet_forwarder on lora-net

[Jason Reiss]

Does not look like fakegps would work.
The packet forwarder looks for an updated time from the gps device.

ref_ok can only be true if gps_enabled is true

line 1518

        /* get a copy of GPS time reference (avoid 1 mutex per packet) */
        if ((nb_pkt > 0) && (gps_enabled == true)) {
            pthread_mutex_lock(&mx_timeref);
            ref_ok = gps_ref_valid;
            local_ref = time_reference_gps;
            pthread_mutex_unlock(&mx_timeref);
        } else {
            ref_ok = false;
}

line 1609

            /* Packet RX time (GPS based), 37 useful chars */
            if (ref_ok == true) {
                /* convert packet timestamp to UTC absolute time */
                j = lgw_cnt2utc(local_ref, p->count_us, &pkt_utc_time);
                if (j == LGW_GPS_SUCCESS) {
                    /* split the UNIX timestamp to its calendar components */
                    x = gmtime(&(pkt_utc_time.tv_sec));
                    j = snprintf((char *)(buff_up + buff_index), TX_BUFF_SIZE-buff_index, ",\"time\":\"%04i-%02i-%02iT%02i:%02i:%02i.%06liZ\"", (x->tm_year)+1900, (x->tm_mon)+1, x->tm_mday, x->tm_hour, x->tm_min, x->tm_sec, (pkt_utc_time.tv_nsec)/1000); /* ISO 8601 format */
                    if (j > 0) {
buff_index += j;

[Jason Reiss]

The packet forwarder could be patched to add the time field.
Or a process could be in-lined to modify the UDP packets to add a time stamp.
Or the network server could fill in the missing time field.

What network server are you using for the backend?

[Jason Reiss]

That is correct, with the packet forwarder used for SPI cards, time is only included when a gps signal is available.

[Jason Reiss]

When the packet forwarder source was updated to include basic, gps and beacon functionalities into one binary, time was changed to only be included when a gps signal is available.
This new packet forwarder code is used for the SPI cards.
The USB cards use the older version.

https://github.com/Lora-net/packet_forwarder

[Jason Reiss]

This user repo has some examples with sx1272 for mdot rx and tx.
https://os.mbed.com/users/dudmuck/

[Jason Reiss]

The network server does not currently support this functionality.
There are only global settings for Rx1 delay, datarate offset, etc. that apply to all devices.

Sending MAC commands from the application can be used for testing the end-device.

[Jason Reiss]

Send an http request to 127.0.0.1/api/system for all system info.
Or 127.0.0.1/api/system/deviceId for just the serial number.

[Jason Reiss]

The input must be valid json, try running it through a linter.
https://jsonlint.com

[Jason Reiss]

Did you modify the PC IP address as well to be on the same network?

[Jason Reiss]

Is there a newline in the string at the end?

I’d go back to the support person who gave you this for help to be sure the logic is intact after modifications.

[Jason Reiss]

Search is your friend.

Search Results

[Jason Reiss]

I have no clue where your data is coming from.
What event is this taken from?

Are you using the mtdot box hardware?

[Jason Reiss]

Did you try to register the nodes with EUI values reversed?

Reverse the DEV-EUI and APP-EUI values used previously.
# lora-query -a <NET-ADDR> [CLASS] <APP-EUI> <DEV-EUI> [APP-KEY]

This EUI should be reversed to
00-18-b2-44-52-49-43-31 => 31-43-49-52-44-b2-18-00

[Jason Reiss]

change const to var?

[Jason Reiss]

The MQTT topic should be “lora/<DEV-EUI>/+”
This will receive all events from the network server

Replace the “+” with “up” to receive only uplinks, this would be the same as lora-in node.

Disconnect the MQTT node from the lora-out node and change the debug node configurations to show complete object.

[Jason Reiss]

You must have meant to say “reçois rien pourtant” unless your machine is laughing?

I guess that answers my last question. You are not seeing uplinks.

Does the device join successfully?

You can add an MQTT input node with topic “lora/+/+” connected to a debug node to see all events from the network server.

[Jason Reiss]

That looks correct.
Are you able to see uplinks from the device in the debug?

[Jason Reiss]

In Node-RED use lora-in to receive packets from the end-device, use lora-out to send back to end-device.

Add lora-in and lora-out nodes to flow with function node between them.

Put this code in the function node to disable ack for the downlink packet:

msg.ack=false;
return msg;

If you want to change the payload.

msg.ack=false;
msg.payload = "new data";
return msg;

A buffer could also be used.
msg.payload = new Buffer([0x01, 0x02, 0x03]);

[Jason Reiss]

You are using Adeunis so the mDot command-line function examples cannot be used.

The documentation will only help for the Conduit side.

[Author]

Posts