MultiTech Developer Resources » Topic: STM32 with Conduit Network Server

Participant

Cross-Post from the ST forum: https://community.st.com/message/172370-lorawan-with-multitech-conduit-gateway

Trying to get ST B-L072Z-LRWAN1 Discovery board and P-NUCLEO-LRWAN1 pack, with I-CUBE-LRWAN firmware, to connect to a Conduit gateway.

The gateway seems to be receiving & accepting the Join Request, but nothing else is working thereafter.

ST has an outdated video describing the setup: https://blog.st.com/how-to-set-up-a-complete-lora-node-in-just-10-minutes/ – I guess it’s missing some key point(s) ?

Has anyone had success in getting this working?

October 21, 2017 at 10:14 am #21236

Keymaster

Besure to use the network server in public mode.

I would debug the rx in the end device.

Look at mqtt output from network server to see response packet freq and datr. Be sure end device settings and timings match.

October 21, 2017 at 10:31 am #21238

Participant

The big question is: what, exactly, are the end-device settings needed to make this work?!

As noted, ST’s video is out-of-date – so I guess that there are now important settings that it doesn’t cover.

There is nothing getting as far as MQTT.

On the conduit, I have found /var/log/lora-network-server.log contains stuff like

:
Logger Level Changed to 30
Full MIC: e5.c5.52.bc.ee.73.c0.ff.3b.68.99.c4.86.e1.b4.28
Full MIC: 05.e8.72.ae.c5.d4.0a.02.65.99.e8.24.22.7e.68.94
Full MIC: 7d.cd.25.38.2f.bb.8c.b1.bd.92.14.37.7e.eb.9a.e9
Full MIC: 32.85.ad.f7.f9.26.43.20.9c.e3.3b.c8.7d.7b.2a.67
Full MIC: e2.20.e3.c4.2d.ea.58.ab.11.2e.31.c9.73.f9.e2.17
Full MIC: 98.0d.79.a8.d2.9c.c7.70.b9.f8.d9.bc.82.bd.f3.2d
Full MIC: 82.32.72.04.37.83.db.3f.a4.03.38.5b.72.cd.62.67
Full MIC: 88.62.e3.3e.c2.bf.53.10.80.57.65.f3.d4.40.91.21
:

But what does that mean?
What is, “Logger Level 30”? are there other levels? if so, how to select them?

also /var/log/messages – contains stuff like

Oct 20 16:55:57 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 16:55:57 mtcdt user.info lora-network-server: Received join request
Oct 20 16:55:57 mtcdt user.info lora-network-server: Device found in DB, assigning address: 1
Oct 20 16:55:57 mtcdt user.info lora-network-server: Queue join response 33 bytes
Oct 20 16:55:57 mtcdt user.info lora-network-server: Send Join Accept – EUI: be-7a-00-00-00-00-00-c8 ADDR: 00000001
Oct 20 16:55:57 mtcdt user.info lora-network-server: Schedule TX Time on air: 81 ms
Oct 20 16:55:58 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:01 via GW (00:80:00:00:a0:00:05:a8 Chan LC2 127.0.0.1:34778) Seq# 0
Oct 20 16:55:58 mtcdt user.info lora-network-server: Update DC Band: 1 Duration: 71 time-on-air available: 35929 ms
Oct 20 16:55:58 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 208 bytes

and a lot of

Oct 20 19:12:55 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 19:12:55 mtcdt user.warn lora-network-server: Recv’d frame failed CRC check
Oct 20 19:13:24 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 19:13:24 mtcdt user.warn lora-network-server: Recv’d frame failed CRC check
Oct 20 19:13:34 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 19:13:34 mtcdt user.warn lora-network-server: Recv’d frame failed CRC check
Oct 20 19:15:00 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 19:15:00 mtcdt user.warn lora-network-server: Recv’d frame failed CRC check
Oct 20 19:16:03 mtcdt user.info lora-network-server: Parsing 1 rx packets
Oct 20 19:16:03 mtcdt user.warn lora-network-server: Recv’d frame failed CRC check

This does seem to tie-in with the fact that the Conduit sees the Node as Joined, but the Node’s transmitted data packets are not then recognised.

Is there a way to log/view the raw received packets at the Gateway?

October 21, 2017 at 10:43 am #21239

Participant

Aha – I didn’t have the Network Server in ‘Public’ mode!

Will certainly try that …

October 21, 2017 at 10:46 am #21240

Participant

That was it!

Many thanks!

October 21, 2017 at 12:00 pm #21241

Keymaster

If interested in raw packets, the Conduit uses Semtech packet forwarder.

Protocol of Packet Forwarder to Network Server is detailed here:
https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT

Source is found here:
https://github.com/Lora-net/packet_forwarder

You can run just the packet forwarder from the /var/run/lora/1 directory.

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

January 5, 2018 at 8:05 am #22237

Participant

I am having a similar issue, or at least, I am using the same platform combination: Multitech Conduit mlinux and P-NUCLEO-LRWAN1.

The configuration for the network server is the following:


{
        "lora": {
                "netID": "010203",      /* netID for beacon packets */
                "frequencyBand": "868", /* US="915", EU="868" */
                "channelPlan": "EU868", /* added at hand (jose.gato) according t
                "frequencySubBand": 7,  /* Sub-band for US operation, 1-8 */
                "rx1DatarateOffset": 0, /* Datarate offset for mote rx window 1
                "rx2Datarate": 12,              /* Datarate for mote rx window 2
                "maxTxPower": 14,       /* Max Tx power (dBm), -6 to 26 */
                "frequencyEU": 869500000 /* center freq for extra EU channels (H
        },
        "udp": {
                "appPortUp": 1784, /* port for user-developed application use */
                "appPortDown": 1786 /* port for user-developed application use *
        },
        "addressRange": {
                "start": "00:00:00:01", /* address range used for mDots */
                "end": "FF:FF:FF:FE"
        },
        "network": {
                "public": true,    /* set to false for private LoRa network with
                "eui": "cb4f12499f32373b", /* 8 hex byte */
                "key": "943ac2f9df30a24a84aa6ecb2a36ccbe", /* 16 hex byte, netwo
                "leasetime": 0  /* time until mDot join expires (minutes) or 0 f
        },
        "log" : {
                "console" : true,
                "syslog" : false,
                "level" : 100, /* error=10, warn=20, info=30, debug=50, trace=60
                "path": "/var/log/lora-network-server.log"
        },
        "mqtt": {
                "enabled": true
        }
}

The lora node is using an mbed lorawan example (https://os.mbed.com/teams/Semtech/code/LoRaWAN-demo-72/) with the following configuration:

#define OVER_THE_AIR_ACTIVATION                     1
#define LORAWAN_PUBLIC_NETWORK                      true
#define IEEE_OUI                                    0x11, 0x22, 0x33
#define LORAWAN_DEVICE_EUI                          { 0xBE, 0x7A, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC8 }
#define LORAWAN_APPLICATION_EUI                     { 0xCB, 0x4F, 0x12, 0x49, 0x9F, 0x32, 0x37, 0x3B }
#define LORAWAN_APPLICATION_KEY                     { 0x94, 0x3A, 0xC2, 0xF9, 0xDF, 0x30, 0xA2, 0x4A, 0x84, 0xAA, 0x6E, 0xcB, 0x2A, 0x36, 0xCC, 0xBE}

DEVICE_EUI comming from the video in this thread
APPLICATION_EUI is the same than eui in the network server
APPLICATION_KEY is the same than key in the network server

The only things I see in the log is:

14:43:31:283|TRACE| Parse downstream message 12 bytes
14:43:31:284|TRACE| Gateway 00:80:00:00:a0:00:11:01 seen IP address 127.0.0.1:49355
14:43:41:479|TRACE| Parse downstream message 12 bytes
14:43:41:480|TRACE| Gateway 00:80:00:00:a0:00:11:01 seen IP address 127.0.0.1:49355
14:43:47:355|TRACE| Parse upstream message 301 bytes
14:43:47:356|TRACE| Gateway 00:80:00:00:a0:00:11:01 seen
14:43:47:357|INFO| Parsing 1 rx packets
14:43:47:358|WARNING| Recv'd frame failed CRC check
14:43:51:679|TRACE| Parse downstream message 12 bytes
14:43:51:680|TRACE| Gateway 00:80:00:00:a0:00:11:01 seen IP address 127.0.0.1:49355

Nothing received through MQTT, I dont know if at least I am receiving a join request.

The output from the lora node does not say too much:
lora node output

January 5, 2018 at 8:27 am #22238

Keymaster

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.

January 5, 2018 at 8:52 am #22240

Participant

Well, I should add I am using this in Europe, so @Jason, how should I configure it? which frenquencysubband?

January 5, 2018 at 9:04 am #22242

Keymaster

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

Is the end-device using 868 frequencies?

#define USE_BAND_868

January 5, 2018 at 9:09 am #22245

Participant

I guess so. In Lorawan-Lib file board.h


#include "mbed.h"
#include "system/timer.h"
#include "debug.h"
#include "system/utilities.h"
#include "sx1272-hal.h"

#define USE_BAND_868

extern SX1272MB2xAS Radio;

If you see the logs in the network server this is something I dont understand:

14:43:47:356|TRACE| Gateway 00:80:00:00:a0:00:11:01 seen
14:43:47:357|INFO| Parsing 1 rx packets
14:43:47:358|WARNING| Recv'd frame failed CRC check
14:43:51:679|TRACE| Parse downstream message 12 bytes

January 5, 2018 at 9:16 am #22247

Keymaster

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

January 5, 2018 at 9:47 am #22250

Participant

After some diggin I have enabled the paquet forwareder, the firmaware in my gateway is 3.2.0, so the instructions are different.

This is the log I get:


setup_sx125x:721: Note: SX125x #1 PLL start (attempt 1)
lgw_start:1120: Note: calibration started (time: 3000 ms)
lgw_start:1141: Note: calibration finished (status = 175)
WARNING: problem in calibration of radio B for image rejection
Info: Initialising AGC firmware...
Info: loading custom TX gain table
Info: putting back original RADIO_SELECT value
lgw_receive:1423: FIFO content: 1 10 0 7 71
lgw_receive:1438: [8 16]
Note: LoRa packet

lgw_receive:1423: FIFO content: 1 91 0 7 19
lgw_receive:1438: [2 17]
Note: LoRa packet

lgw_receive:1423: FIFO content: 1 ba 0 7 98
lgw_receive:1438: [8 16]
Note: LoRa packet
lgw_receive:1423: FIFO content: 1 62 1 7 b7
lgw_receive:1438: [4 17]
Note: LoRa packet
*** Basic Packet Forwarder for Lora Gateway ***
Version: 1.4.1
*** Lora concentrator HAL library version info ***
Version: 1.7.0; Options: ftdi sx1301 sx1257 full mtac-lora private;
***
INFO: Little endian host
INFO: found global configuration file /var/config/lora/global_conf.json, parsing it
INFO: /var/config/lora/global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: radio 0 enabled, center frequency 867500000
INFO: radio 1 enabled, center frequency 868500000
INFO: Lora multi-SF channel 0>  radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1>  radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2>  radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4>  radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5>  radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6>  radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7>  radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: /var/config/lora/global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to 00800000A0001101
INFO: server hostname or IP address is configured to "52.3.215.147"
INFO: upstream port is configured to "20000"
INFO: downstream port is configured to "20000"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: [main] concentrator started, packet can now be received

INFO: Start of downstream thread

##### 2018-01-05 16:23:45 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 2
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 2 (138 bytes)
# PUSH_DATA datagrams sent: 2 (613 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 16:24:15 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (152 bytes)
# PUSH_DATA datagrams sent: 1 (418 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 16:24:45 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (183 bytes)
# PUSH_DATA datagrams sent: 1 (458 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 16:25:15 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 16:25:45 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00

January 5, 2018 at 9:52 am #22251

Keymaster

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

January 5, 2018 at 10:40 am #22254

Participant

Sorry I dont understand what do you mean with mtac-lora private, I see the log but all my config is set to public. I dont see a thing about synch_word

ok, here it is my global_conf.json

thank you ver much for your quick responses…

root@mtcdt:/var/config/lora# cat global_conf.json 
{
	"SX1301_conf": {
		"antenna_gain": 0,
		"chan_FSK": {
			"bandwidth": 125000,
			"datarate": 50000,
			"enable": true,
			"if": 300000,
			"radio": 1
		},
		"chan_Lora_std": {
			"bandwidth": 250000,
			"enable": true,
			"if": -200000,
			"radio": 1,
			"spread_factor": 7
		},
		"chan_multiSF_0": {
			"enable": true,
			"if": -400000,
			"radio": 1
		},
		"chan_multiSF_1": {
			"enable": true,
			"if": -200000,
			"radio": 1
		},
		"chan_multiSF_2": {
			"enable": true,
			"if": 0,
			"radio": 1
		},
		"chan_multiSF_3": {
			"enable": true,
			"if": -400000,
			"radio": 0
		},
		"chan_multiSF_4": {
			"enable": true,
			"if": -200000,
			"radio": 0
		},
		"chan_multiSF_5": {
			"enable": true,
			"if": 0,
			"radio": 0
		},
		"chan_multiSF_6": {
			"enable": true,
			"if": 200000,
			"radio": 0
		},
		"chan_multiSF_7": {
			"enable": true,
			"if": 400000,
			"radio": 0
		},
		"clksrc": 0,
		"lbt_cfg": {
			"enable": false,
			"rssi_target": 160
		},
		"lorawan_public": true,
		"radio_0": {
			"enable": true,
			"freq": 867500000,
			"rssi_offset": -162,
			"tx_enable": true,
			"tx_freq_max": 870000000,
			"tx_freq_min": 863000000,
			"type": "SX1257"
		},
		"radio_1": {
			"enable": true,
			"freq": 868500000,
			"rssi_offset": -162,
			"tx_enable": false,
			"type": "SX1257"
		},
		"tx_lut_0": {
			"dig_gain": 0,
			"mix_gain": 11,
			"pa_gain": 0,
			"rf_power": -6
		},
		"tx_lut_1": {
			"dig_gain": 0,
			"mix_gain": 13,
			"pa_gain": 0,
			"rf_power": -3
		},
		"tx_lut_10": {
			"dig_gain": 0,
			"mix_gain": 15,
			"pa_gain": 2,
			"rf_power": 16
		},
		"tx_lut_11": {
			"dig_gain": 0,
			"mix_gain": 10,
			"pa_gain": 3,
			"rf_power": 20
		},
		"tx_lut_12": {
			"dig_gain": 0,
			"mix_gain": 12,
			"pa_gain": 3,
			"rf_power": 23
		},
		"tx_lut_13": {
			"dig_gain": 0,
			"mix_gain": 13,
			"pa_gain": 3,
			"rf_power": 25
		},
		"tx_lut_14": {
			"dig_gain": 0,
			"mix_gain": 15,
			"pa_gain": 3,
			"rf_power": 26
		},
		"tx_lut_15": {
			"dig_gain": 0,
			"mix_gain": 15,
			"pa_gain": 3,
			"rf_power": 27
		},
		"tx_lut_2": {
			"dig_gain": 0,
			"mix_gain": 9,
			"pa_gain": 1,
			"rf_power": 0
		},
		"tx_lut_3": {
			"dig_gain": 0,
			"mix_gain": 10,
			"pa_gain": 1,
			"rf_power": 3
		},
		"tx_lut_4": {
			"dig_gain": 0,
			"mix_gain": 12,
			"pa_gain": 1,
			"rf_power": 6
		},
		"tx_lut_5": {
			"dig_gain": 0,
			"mix_gain": 10,
			"pa_gain": 2,
			"rf_power": 10
		},
		"tx_lut_6": {
			"dig_gain": 0,
			"mix_gain": 11,
			"pa_gain": 2,
			"rf_power": 11
		},
		"tx_lut_7": {
			"dig_gain": 0,
			"mix_gain": 11,
			"pa_gain": 2,
			"rf_power": 12
		},
		"tx_lut_8": {
			"dig_gain": 2,
			"mix_gain": 12,
			"pa_gain": 2,
			"rf_power": 13
		},
		"tx_lut_9": {
			"dig_gain": 0,
			"mix_gain": 13,
			"pa_gain": 2,
			"rf_power": 14
		}
	},
	"gateway_conf": {
		"forward_crc_disabled": false,
		"forward_crc_error": true,
		"forward_crc_valid": true,
		"gateway_ID": "00800000A0001101",
		"keepalive_interval": 10,
		"push_timeout_ms": 100,
		"serv_port_down": 20000,
		"serv_port_up": 20000,
		"server_address": "52.3.215.147",
		"stat_interval": 30
	}
}

January 5, 2018 at 10:45 am #22255

Keymaster

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,

January 5, 2018 at 11:05 am #22256

Participant

Added, but I dont see a difference:

Is it receiving packages from the node? Do you recommed me to upgrade gateway firmware?

INFO: Start of downstream thread

##### 2018-01-05 17:42:32 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 17:43:02 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 17:43:32 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (70 bytes)
# PUSH_DATA datagrams sent: 1 (309 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 17:44:02 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

##### 2018-01-05 17:44:32 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH

This reply was modified 6 years, 3 months ago by Jose Gato Luis.

January 5, 2018 at 11:12 am #22258

Keymaster

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/*

January 5, 2018 at 11:21 am #22259

https://os.mbed.com/questions/79829/VT100-emulation-in-Linux/?compage=1#c29275

Participant

Not sure if the device is transmiting, this is algo something I trying to guess in this thread:

about the hardware details:

19228879
00:80:00:00:A0:00:11:01
MTAC-LORA-1.0
MTAC-LORA-868
Multi-Tech System

I think it is better to way if I have any response from mbed community to ensure I have correctly configured the node 😉

January 5, 2018 at 12:50 pm #22260

https://www.amazon.com/NooElec-NESDR-Mini-Receiver-RTL2832U/dp/B00VZ1AWQA/ref=sr_1_4?ie=UTF8&qid=1515178160&sr=8-4&keywords=nooelec

Keymaster

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

January 11, 2018 at 12:27 am #22304