Git Product home page Git Product logo

packet_forwarder's Introduction

 / _____)             _              | |    
( (____  _____ ____ _| |_ _____  ____| |__  
 \____ \| ___ |    (_   _) ___ |/ ___)  _ \ 
 _____) ) ____| | | || |_| ____( (___| | | |
(______/|_____)_|_|_| \__)_____)\____)_| |_|
  (C)2013 Semtech-Cycleo

Lora network packet forwarder project

  1. Core program: lora_pkt_fwd

The packet forwarder is a program running on the host of a Lora gateway that forwards RF packets receive by the concentrator to a server through a IP/UDP link, and emits RF packets that are sent by the server. It can also emit a network-wide GPS-synchronous beacon signal used for coordinating all nodes of the network.

((( Y )))
    |
    |
+- -|- - - - - - - - - - - - -+        xxxxxxxxxxxx          +--------+
|+--+-----------+     +------+|       xx x  x     xxx        |        |
||              |     |      ||      xx  Internet  xx        |        |
|| Concentrator |<----+ Host |<------xx     or    xx-------->|        |
||              | SPI |      ||      xx  Intranet  xx        | Server |
|+--------------+     +------+|       xxxx   x   xxxx        |        |
|   ^                    ^    |           xxxxxxxx           |        |
|   | PPS  +-----+  NMEA |    |                              |        |
|   +------| GPS |-------+    |                              +--------+
|          +-----+            |
|                             |
|            Gateway          |
+- - - - - - - - - - - - - - -+

Uplink: radio packets received by the gateway, with metadata added by the gateway, forwarded to the server. Might also include gateway status.

Downlink: packets generated by the server, with additional metadata, to be transmitted by the gateway on the radio channel. Might also include configuration data for the gateway.

  1. Helper programs

Those programs are included in the project to provide examples on how to communicate with the packet forwarder, and to help the system builder use it without having to implement a full Lora network server.

3.1. util_sink

The packet sink is a simple helper program listening on a single port for UDP datagrams, and displaying a message each time one is received. The content of the datagram itself is ignored.

3.2. util_ack

The packet acknowledger is a simple helper program listening on a single UDP port and responding to PUSH_DATA datagrams with PUSH_ACK, and to PULL_DATA datagrams with PULL_ACK.

3.3. util_tx_test

The network packet sender is a simple helper program used to send packets through the gateway-to-server downlink route.

  1. Helper scripts

4.1. lora_gateway/reset_lgw.sh

This script, provided with the HAL (lora_gateway), must be launched on IoT Start Kit platform to reset concentrator chip through GPIO, before starting any application using the concentrator, like the packet forwarder.

4.2. packet_forwarder/lora_pkt_fwd/update_gwid.sh

This script allows automatic update of Gateway_ID with unique MAC address, in packet forwarder JSON configuration file. Please refer to the script header for more details.

  1. Changelog

v4.0.1 - 2017-03-16

  • Class-B: Added xtal error correction to beacon frequency
  • Class-B: Added support for all regions to beacon frame format (various datarates imply different frame sizes), as defined by LoRaWAN v1.1.

v4.0.0 - 2017-01-10

  • Added Class-B support, as defined in LoRaWAN v1.1
  • Downlink only support "tmst" or "tmms" timestamp. "time" is not supported anymore ("time" field is kept in Uplink as an informative field).
  • Reworked thread_gps to handle GPS UBX messages for native GPS time.
  • Updated Gateway <-> NetworkServer protocol to describe the new "tmms" field.
  • Updated global_conf.PCB286*.json to remove indexes of the TX gain LUT above 20dBm. Use PCB336 (aka GW v1.5) to comply with ETSI TX mask between 20dBm and 27dBm.

v3.1.0 - 2016-09-07

  • Updated "Listen-Before-Talk" JSON configuration to match with LBT rework.
  • Added TX Notch Filter JSON configuration.
  • Updated Parson library to latest version
  • Fixed Class-B beacon CRC-16 calculation
  • Removed JiT time_on_air local function, and use lgw_time_on_air() function

v3.0.0 - 2016-05-19

  • Merged all different flavours of packet forwarder into one unique lora_pkt_fwd Note: Various flavours can still be achieved using the corresponding global_conf.json.XXX file provided in lora_pkt_fwd/cfg.
  • Added downlink "just-in-time" scheduling to optimize downlink capacity.
  • Updated Gateway <-> NetworkServer protocol to describe the new format of "tx_ack" message.
  • Added "Listen-Before-Talk" JSON configuration.
  • Splitted reset_pkt_fwd.sh script in 2 different scripts:
    • reset_lgw.sh, provided with the HAL (lora_gateway)
    • update_gwid.sh, provided with lora_pkt_fwd

WARNING: Gateway <-> Network Server protocol version has changed. Please refer to PROTOCOL.txt file.

v2.2.1 - 2016-04-12

  • util_tx_test: added FSK support and specific payload for easier PER testing.
  • base64: fixed padding check.
  • Updated all makefiles to handle the creation of obj directory when necessary.
  • [gps/beacon]_pkt_fwd: fixed crash on exit when GPS not enabled.
  • [*]_pkt_fwd: added a cfg/ directory containing different flavours or the global_conf.json file for different boards: Ref Design PCB_E336 (GW1.5-27dBm), Ref Design PCB_E286 (GW1.0), Ref Design with US902 frequency plan.

v2.2.0 - 2015-10-08

v2.1.0 - 2015-06-29

  • Added helper script for concentrator reset through GPIO, needed on IoT Starter Kit (reset_pkt_fwd.sh).
  • The same reset_pkt_fwd.sh script also allows to automatically update the Gateway_ID field in JSON configuration file, with board MAC address.
  • Updated JSON configuration file with proper default value for IoT Starter Kit: server address set to local server, GPS device path set to proper value (/dev/ttyAMA0).

v2.0.0 - 2015-04-30

  • Changed: Several configuration parameters are now set dynamically from the JSON configuration file: RSSI offset, concentrator clock source, radio type, TX gain table, network type. The HAL does not need to be recompiled any more to update those parameters. An example for IoT Starter Kit platform is provided in global_conf.json for basic, gps and beacon packet_forwarder.
  • Removed: Band frequency JSON configuration file has been removed. An example for EU 868MHz is provided in global_conf.json for basic, gps and beacon packet forwarder.
  • Changed: Updated makefiles to allow cross compilation from environment variable (ARCH, CROSS_COMPILE).

** WARNING: ** ** Update your JSON configuration file with new dynamic parameters. **

v1.4.1 - 2015-01-23

  • Bugfix: fixed LP-116, fdev parameter parsed incorrectly, making FSK TX fail.
  • Bugfix: fixed a platform-dependant minor rounding issue.
  • Beta: updated beacon format, partially aligned with latest class B proposal.

v1.4.0 - 2014-10-16

  • Feature: Adding TX FSK support.
  • Feature: optional auto-quit if a certain number of PULL_ACK is missed.
  • Feature: upstream and downstream ping time is displayed on console.
  • Bugfix: some beacons were missed at high beaconing frequency.
  • Bugfix: critical snprintf error caused a crash for long payloads.
  • FSK bitrate now appears in the upstream JSON.

v1.3.0 - 2014-03-28

  • Feature: adding preliminary beacon support for class B development.
  • Solved warnings with 64b integer printf when compiling on x86_64.
  • Updated build system for easier deployment on various hardware.
  • Changed threads organization in the forwarder programs.
  • Removed duplicate protocol documentation.

v1.2.0 - 2014-02-03

  • Feature: added a GPS-enabled packet forwarder, used to timestamp received packet with a globally-synchronous microsecond-accurate timestamp.
  • Feature: GPS packet forwarder sends status report on the uplink, protocol specification updated accordingly (report include gateway geolocation).
  • Feature: packets can be sent without CRC at radio layer.
  • Bugfix: no more crash with base64 padded input.
  • Bugfix: no more rounding errors on the 'freq' value sent to server.
  • A minimum preamble of 6 Lora symbol is enforced for optimum sensitivity.
  • Padded Base64 is sent on uplink, downlink accepts padded and unpadded Base64.
  • Updated the Parson JSON library to a version that supports comments.
  • Added .md (Markdown) extension to readme files for better Github viewing.

v1.1.0 - 2013-12-09

  • Feature: added packet filtering parameters to the JSON configuration files.
  • Bugfix: will not send a datagram if all the packets returned by the receive() function have been filtered out.
  • Bugfix: removed leading zeros for the timestamp in the upstream JSON because it is not compliant with JSON standard (might be interpreted as octal number).
  • Removed TXT extension for README files for better Github integration.
  • Cleaned-up documentation, moving change log to top README.
  • Modified Makefiles to ease cross-compilation.

v1.0.0 - 2013-11-22

  • Initial release of the packet forwarder, protocol specifications and helper programs.
  1. Legal notice

The information presented in this project documentation does not form part of any quotation or contract, is believed to be accurate and reliable and may be changed without notice. No liability will be accepted by the publisher for any consequence of its use. Publication thereof does not convey nor imply any license under patent or other industrial or intellectual property rights. Semtech assumes no responsibility or liability whatsoever for any failure or unexpected operation resulting from misuse, neglect improper installation, repair or improper handling or unusual physical or electrical stress including, but not limited to, exposure to parameters beyond the specified maximum ratings or operation outside the specified range.

SEMTECH PRODUCTS ARE NOT DESIGNED, INTENDED, AUTHORIZED OR WARRANTED TO BE SUITABLE FOR USE IN LIFE-SUPPORT APPLICATIONS, DEVICES OR SYSTEMS OR OTHER CRITICAL APPLICATIONS. INCLUSION OF SEMTECH PRODUCTS IN SUCH APPLICATIONS IS UNDERSTOOD TO BE UNDERTAKEN SOLELY AT THE CUSTOMER�S OWN RISK. Should a customer purchase or use Semtech products for any such unauthorized application, the customer shall indemnify and hold Semtech and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs damages and attorney fees which could arise.

EOF

packet_forwarder's People

Contributors

mcoracin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

packet_forwarder's Issues

radio_1 cannot be disabled

The lgw_rxrf_setconf call for radio_1 will fail and cause the packet forwarder to crash if radio_1 is set to disabled.

INFO: radio 1 disabled
ERROR: NOT A VALID RADIO TYPE
ERROR: invalid configuration for radio 1

Receiving multiple 255 byte packets

How many 255 byte packets can be received at a single time?

It seems when four end-points send max size packets at SF7BW125, the concentrator stops reporting packets received.
When a few end-points are turned off packets are reported again.
Is there be FIFO overflow happening in this scenario?

Occasionally I would receive this warning, with random numbers reported as IF_CHAIN.
lgw_receive:1140: WARNING: 76 NOT A VALID IF_CHAIN NUMBER, ABORTING

ERROR: Packet REJECTED, timestamp seems wrong, too much in advance

Randomly getting the above error when sending packets back from a network server to the gateway. The error is misleading because the txpk packet was received by the gateway in time and queued on the JIT queue but come the time to process it, the current time is AFTER the timestamp in the packet as can be seen in this log message:

`JSON down: {"txpk":{"imme":false,"tmst":1171949259,"freq":868.5,"rfch":0,"powe":14,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":17,"data":"IAEaZceWDv2zLGE/G78VyXQ="}}

src/jitqueue.c:314:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=1171981382, packet=1171949259, type=0)
ERROR: Packet REJECTED (jit error=2)`

The potential for a problem seems to have already been considered as there is a comment immediately above the line causing the issue:

* Warning: unsigned arithmetic (handle roll-over) t_packet > t_current + TX_MAX_ADVANCE_DELAY

The problem lines are lines 232 and 250 of jitqueue.c

TIA

Which version of Lora Gatway to use

I am currently using the latest version lora packet forwarder to run on kerlink base station.
Is it ok for me to use lora gateway of version 3.2.1 and below?

ERROR

Hi,
Sorry if this section is not suitable to leave messages about problems we encoutered while following your tutorial but I don't where I can leave my messages (is there a forum?).

I tried following your tutorial but I always get the same error when I want to run lora_pkt_fwd.
I always get:
image
Failed to start the concentrator, any idea why I have this?

Thanks

Unable to recieve schedule downlink from Server Side

Hi,
We have a risinghf gateway in which we are using version 2.0 ./lora_pkt_fwd. We have two end nodes , One was given by risinghf along with the gateway in which we are receiving the frame. On the Second end node However we are not receiving the packet hence even the queue is not getting empty either.

The logs of the second node where problem is occuring:
INFO: Received pkt from mote: 09876543 (fcnt=0)

JSON up: {"rxpk":[{"tmst":43022164,"chan":3,"rfch":0,"freq":867.100000,"stat":1, "modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":8.2,"rssi":-77,"size":29,"d ata":"gENlhwmAAAACeBhm7eM1gZTNjCnGsHBgXjxO4Ps="}]}
INFO: [up] PUSH_ACK received in 8 ms
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":44022164,"freq":867.1,"rfch":0,"powe":14 ,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":29,"data":"oEN lhwkwBgACMTAwMTEwMDAwMDAxMDAwMddsy2c="}}
INFO: [down] PULL_ACK received in 8 ms

INFO: Disabling GPS mode for concentrator's counter...
INFO: host/sx1301 time offset=(1506076573s:177915µs) - drift=-96µs
INFO: Enabling GPS mode for concentrator's counter.

2017-09-22 10:37:15 GMT

[UPSTREAM]

RF packets received by concentrator: 3

CRC_OK: 66.67%, CRC_FAIL: 33.33%, NO_CRC: 0.00%

RF packets forwarded: 2 (47 bytes)

PUSH_DATA datagrams sent: 3 (523 bytes)

PUSH_DATA acknowledged: 100.00%

[DOWNSTREAM]

PULL_DATA sent: 3 (100.00% acknowledged)

PULL_RESP(onse) datagrams received: 2 (386 bytes)

RF packets sent to concentrator: 2 (58 bytes)

TX errors: 0

TX rejected (collision packet): 0.00% (req:2, rej:0)

TX rejected (collision beacon): 0.00% (req:2, rej:0)

TX rejected (too late): 0.00% (req:2, rej:0)

TX rejected (too early): 0.00% (req:2, rej:0)

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

[JIT]

src/jitqueue.c:511:jit_print_queue(): INFO: [jit] queue is empty

[GPS]

GPS sync is disabled

END

The logs of the working Node:
INFO: Received pkt from mote: 013E6354 (fcnt=1)

JSON up: {"rxpk":[{"tmst":137621676,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":7.0,"rssi":-1,"size":15,"data":"gFRjPgGAAQAIEwWspahP"}]}
INFO: [up] PUSH_ACK received in 24 ms
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":138621676,"freq":868.5,"rfch":0,"powe":14,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":12,"data":"YFRjPgEgxAARzi8q"}}
INFO: [down] PULL_ACK received in 8 ms

2017-09-22 10:38:45 GMT

[UPSTREAM]

RF packets received by concentrator: 1

CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%

RF packets forwarded: 1 (15 bytes)

PUSH_DATA datagrams sent: 2 (306 bytes)

PUSH_DATA acknowledged: 100.00%

[DOWNSTREAM]

PULL_DATA sent: 3 (100.00% acknowledged)

PULL_RESP(onse) datagrams received: 1 (170 bytes)

RF packets sent to concentrator: 1 (12 bytes)

TX errors: 0

TX rejected (collision packet): 0.00% (req:3, rej:0)

TX rejected (collision beacon): 0.00% (req:3, rej:0)

TX rejected (too late): 0.00% (req:3, rej:0)

TX rejected (too early): 0.00% (req:3, rej:0)

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

[JIT]

src/jitqueue.c:511:jit_print_queue(): INFO: [jit] queue is empty

[GPS]

GPS sync is disabled

END

JSON up: {"stat":{"time":"2017-09-22 10:38:45 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":1,"txnb":1}}
INFO: [up] PUSH_ACK received in 5 ms
INFO: [down] PULL_ACK received in 8 ms
^C

2017-09-22 10:38:48 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: 1 (113 bytes)

PUSH_DATA acknowledged: 100.00%

[DOWNSTREAM]

PULL_DATA sent: 1 (100.00% acknowledged)

PULL_RESP(onse) datagrams received: 0 (0 bytes)

RF packets sent to concentrator: 0 (0 bytes)

TX errors: 0

TX rejected (collision packet): 0.00% (req:3, rej:0)

TX rejected (collision beacon): 0.00% (req:3, rej:0)

TX rejected (too late): 0.00% (req:3, rej:0)

TX rejected (too early): 0.00% (req:3, rej:0)

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

[JIT]

src/jitqueue.c:511:jit_print_queue(): INFO: [jit] queue is empty

[GPS]

GPS sync is disabled

END

Can anyone help us explaining as to why we are not receiving the packet in 2nd node ???

Unable to find logs of DOWNLINK queue

Hi,
I need your assist on Something, We have made the api call to push the packet from the server side. We are also Recieving 200 status (OK). But we would like to see where we are recieving the packet. Is there a log file which is generated at the gateway end?.

multiple servers

Hello
tell me how to set up global.conf so that the package is sent to two servers

How can I reset 1301 timestamp counter?

Hi Sir,

I have two 1301 AP modules on my board.
There are two packet_forwarder process running in the mean while.
However, I don't have GPS to correct the time clock of 1301 timestamp periodically.
So that, the timestamp difference of these two packet_forwarder from 1301 is getting longer.
Can I reset the 1301 timestamp periodically?
Or there any method I can sync the timestamp of each 1301?
Please advise.
Thanks.

Packet Forwarder don't show all packets from multiple End Device

Hi,
I am using multiple End devices and facing a issue on packet forwarder

Packet Forwarder don't show all packet from end device but End Device get ACK from the Server, and no record of these packets in lora server as well.

End Device code version - V4.3.2
Lora Packet Forwarder Version - v4.0.1
Lora Gateway version - v5.0.1

duty cycle handling

Hi,
how the pktfwd or iC880 (design ref 1) handle the duty cycle limit on TX ? source code seams no taking into account that ....
Last LoRaWan spec confirm that at the moment only the duty cycle is consider and not LBT+AFA
Thanks
F

NetID missing from Beacon

I feel the implementation is not standard compliant. See
https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L1873

The code says:

    /* fixed bacon fields (little endian) */
    beacon_pkt.payload[0] = 0x0; /* RFU */
    beacon_pkt.payload[1] = 0x0; /* RFU */
    /* 2-5 : time (variable) */
    /* 6-7 : crc1 (variable) */

Whereas the standard says the (US 902-928MHz) beacon frame content is

3 4 2 7 1 2
NetID Time CRC GwSpecific RFU CRC

The two-byte RFU feels wrong. Doesn't it? It should be 3-byte and it should be NetID, right?

Autostart lora_pkt_fwd

Hi everyone,
Is there any way on how to start the packet forwarder automatically in Rapsberry pi? I tried to edit the rc.local file but that seems that is not working.
Many thanks in advance.

need support in schedule downlink.

Hi,
We have a risinghf gateway in which we are using version 2.0 ./lora_pkt_fwd. We have two end nodes , One was given by risinghf along with the gateway in which we are receiving the frame. On the Second end node However we are not receiving the packet hence even the queue is not getting empty either.

The logs of the second node where problem is occuring:
INFO: Received pkt from mote: 09876543 (fcnt=0)

JSON up: {"rxpk":[{"tmst":43022164,"chan":3,"rfch":0,"freq":867.100000,"stat":1, "modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":8.2,"rssi":-77,"size":29,"d ata":"gENlhwmAAAACeBhm7eM1gZTNjCnGsHBgXjxO4Ps="}]}
INFO: [up] PUSH_ACK received in 8 ms
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":44022164,"freq":867.1,"rfch":0,"powe":14 ,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":29,"data":"oEN lhwkwBgACMTAwMTEwMDAwMDAxMDAwMddsy2c="}}
INFO: [down] PULL_ACK received in 8 ms

INFO: Disabling GPS mode for concentrator's counter...
INFO: host/sx1301 time offset=(1506076573s:177915µs) - drift=-96µs
INFO: Enabling GPS mode for concentrator's counter.
2017-09-22 10:37:15 GMT
[UPSTREAM]
RF packets received by concentrator: 3
CRC_OK: 66.67%, CRC_FAIL: 33.33%, NO_CRC: 0.00%
RF packets forwarded: 2 (47 bytes)
PUSH_DATA datagrams sent: 3 (523 bytes)
PUSH_DATA acknowledged: 100.00%
[DOWNSTREAM]
PULL_DATA sent: 3 (100.00% acknowledged)
PULL_RESP(onse) datagrams received: 2 (386 bytes)
RF packets sent to concentrator: 2 (58 bytes)
TX errors: 0
TX rejected (collision packet): 0.00% (req:2, rej:0)
TX rejected (collision beacon): 0.00% (req:2, rej:0)
TX rejected (too late): 0.00% (req:2, rej:0)
TX rejected (too early): 0.00% (req:2, rej:0)
BEACON queued: 0
BEACON sent so far: 0
BEACON rejected: 0
[JIT]

src/jitqueue.c:511:jit_print_queue(): INFO: [jit] queue is empty
[GPS]
GPS sync is disabled
END

The logs of the working Node:
INFO: Received pkt from mote: 013E6354 (fcnt=1)

JSON up: {"rxpk":[{"tmst":137621676,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":7.0,"rssi":-1,"size":15,"data":"gFRjPgGAAQAIEwWspahP"}]}
INFO: [up] PUSH_ACK received in 24 ms
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":138621676,"freq":868.5,"rfch":0,"powe":14,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":12,"data":"YFRjPgEgxAARzi8q"}}
INFO: [down] PULL_ACK received in 8 ms
2017-09-22 10:38:45 GMT
[UPSTREAM]
RF packets received by concentrator: 1
CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
RF packets forwarded: 1 (15 bytes)
PUSH_DATA datagrams sent: 2 (306 bytes)
PUSH_DATA acknowledged: 100.00%
[DOWNSTREAM]
PULL_DATA sent: 3 (100.00% acknowledged)
PULL_RESP(onse) datagrams received: 1 (170 bytes)
RF packets sent to concentrator: 1 (12 bytes)
TX errors: 0
TX rejected (collision packet): 0.00% (req:3, rej:0)
TX rejected (collision beacon): 0.00% (req:3, rej:0)
TX rejected (too late): 0.00% (req:3, rej:0)
TX rejected (too early): 0.00% (req:3, rej:0)
BEACON queued: 0
BEACON sent so far: 0
BEACON rejected: 0
[JIT]

src/jitqueue.c:511:jit_print_queue(): INFO: [jit] queue is empty
[GPS]
GPS sync is disabled
END

JSON up: {"stat":{"time":"2017-09-22 10:38:45 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":1,"txnb":1}}
INFO: [up] PUSH_ACK received in 5 ms
INFO: [down] PULL_ACK received in 8 ms
^C
2017-09-22 10:38:48 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: 1 (113 bytes)
PUSH_DATA acknowledged: 100.00%
[DOWNSTREAM]
PULL_DATA sent: 1 (100.00% acknowledged)
PULL_RESP(onse) datagrams received: 0 (0 bytes)
RF packets sent to concentrator: 0 (0 bytes)
TX errors: 0
TX rejected (collision packet): 0.00% (req:3, rej:0)
TX rejected (collision beacon): 0.00% (req:3, rej:0)
TX rejected (too late): 0.00% (req:3, rej:0)
TX rejected (too early): 0.00% (req:3, rej:0)
BEACON queued: 0
BEACON sent so far: 0
BEACON rejected: 0
[JIT]

src/jitqueue.c:511:jit_print_queue(): INFO: [jit] queue is empty
[GPS]
GPS sync is disabled
END

Can anyone help us explaining as to why we are not receiving the packet in 2nd node ???

A lot of CRC_FAIL

Hello!
I'm using:

  • iC880A (USB, with additional power supply) with a Cubieboard A20 (Ubuntu server)
  • lora_gateway 3.10 (I know that is not the recent version, but I have only the USB-version of iC880A)
  • packet_forwarder 2.10
    Gateway is 2 m far from a node (Arduino + HopeRF 95).
    A lot of packets are failed to forward because of CRC_FAIL error. thethingsnetwork.org application data log skips 1 or 2, or even 3 packets (according to counter).
    Also, when I use a debug build of libloragw I see a lot of failed packets (third byte is 7).

So, the question is: how can I get rid of CRC_FAILED?

Server Messages

Hi,

I have setup Lora-net/packet_forwarder and server;
Is there any standart way to parse the data from messages?
Or can I send only valid json messages with the packet_forwarder?

On the server I receive messages like this ones:

+@�UZ{"rxpk":[{"tmst":2934474419,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":6.8,"rssi":-67,"size":18,"data":"QBEREREAlAMEX5iCQB8ij0ZU"}]}
���UZ{"rxpk":[{"tmst":2921073603,"chan":0,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.8,"rssi":-71,"size":18,"data":"QBEREREAkwMEoIEzjVYBnMfH"}]}
e��UZ{"rxpk":[{"tmst":2908126707,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":6.2,"rssi":-66,"size":18,"data":"QBEREREAkgME/9mgCeWD3REa"}]}
O�UZ{"rxpk":[{"tmst":2894923683,"chan":0,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":8.2,"rssi":-65,"size":18,"data":"QBEREREAkQMEi7mXjZsNpziU"}]}

Thanks in advance, any help will be appreciated.

No rule to make target

I try to make the paket forwarder I get

pi@WLo-LoRa-GWY:/packet_forwarder $ sudo make all
make all -e -C lora_pkt_fwd
make[1]: Entering directory '/home/pi/packet_forwarder/lora_pkt_fwd'
make[1]: *** No rule to make target '../../lora_gateway/libloragw/inc/loragw_hal.h', needed by 'obj/lora_pkt_fwd.o'. Stop.
make[1]: Leaving directory '/home/pi/packet_forwarder/lora_pkt_fwd'
Makefile:11: recipe for target 'all' failed
make: *** [all] Error 2
pi@WLo-LoRa-GWY:
/packet_forwarder $

Any ideas?
Thanks

the timestamp in beacon is placed in a wrong place?!

Under the beacon_pkt_fwd example

void thread_down(){
    ....
    beacon_pkt.payload[ 9] = 0xFF &  field_time;
    beacon_pkt.payload[10] = 0xFF & (field_time >>  8);
    beacon_pkt.payload[11] = 0xFF & (field_time >> 16);
    beacon_pkt.payload[12] = 0xFF & (field_time >> 24);
    ...
}

According to the spec 1.0.1 Page 86, it should be like this.

void thread_down(){
    ....
    beacon_pkt.payload[3] = 0xFF &  field_time;
    beacon_pkt.payload[4] = 0xFF & (field_time >>  8);
    beacon_pkt.payload[5] = 0xFF & (field_time >> 16);
    beacon_pkt.payload[6] = 0xFF & (field_time >> 24);
    ...
}

Build error (undefined reference to `modf')

mipsel-openwrt-linux-uclibc-gcc -L../../lora_gateway/libloragw obj/gps_pkt_fwd.o obj/parson.o obj/base64.o -o gps_pkt_fwd -lloragw -lrt -lpthread
obj/gps_pkt_fwd.o: In function thread_down': gps_pkt_fwd.c:(.text+0x2464): undefined reference tomodf'
../../lora_gateway/libloragw/libloragw.a(loragw_gps.o): In function `lgw_cnt2utc':

issue is fixed by adding "-lm" in all the Makefiles. Request you to review this issue and fix in next version.

rajendra

Listen Before Talk, how to use RX2

If the gateway is configured for 8 uplink channels, I assume 8 channels will be configured for TX.
This will not allow TX on Rx2. Can 9 channels be supported by the hardware?

LoRa packet-Forwarder doesn’t start

I have installed lora_gateway and the lora-packet-forwarder git repos from Lora-net in my raspberry pi 3B and made connections to my IC8808 board as indicated in the image below.

https://forum.loraserver.io/uploads/default/original/1X/2ab38cc876e5d76bacb85ea00645f0e5ba097a50.png

I compiled the lora_gateway and the lora-packet-forwarder repos successfully and produced all their binaries.

My SPI for the Raspberry Pi is activated via raspi-config. I have confirmed that SPI is active by running cat /boot/config.txt | grep spi. My problem is that sometimes the packet forwarder choses to not start and give the following error. This issue persists for long when it starts. I receive the following error message continuously.

pi@raspberrypi:~/packet_forwarder/lora_pkt_fwd $ ./lora_pkt_fwd 
*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.1
*** Lora concentrator HAL library version info ***
Version: 5.0.1;
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
INFO: LBT is disabled
INFO: antenna_gain 0 dBi
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 129000
INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
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: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to B827EBFFFE243B19
INFO: server hostname or IP address is configured to "127.0.0.1"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
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 NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
ERROR: [main] failed to start the concentrator

I have made sure that the SPI connections and all pins are properly connected with the help of a multimeter. I tried two methods, namely by connecting the IC8808 board to the raspberry pi with jumber cables and also using intermediate PCB specially printed to make the above connections stated in the image. In both cases, I have received successful results. But at times, when this unit choses not to work, it just doesnt work for hours and sometimes a day or so. This unpredictable behavior is really frustrating… But it also means that my connections must be right. And I can assure that there is no lose connection from the Rpi end or from the IC8808 end. Below is a photo of both when they are connected using the intermediate board- A method that has worked but sometimes dosnt work. I have also tested with multiple raspberry pi3’s and multiple IC8808 boards. This issue is common to all setups.

https://forum.loraserver.io/uploads/default/original/1X/9103ca7257c8f461739af53f5c8b5d4b16935835.jpg

I hope this repo is the place from which everyone gets their updated Packet forwarder code and lora_gateway software from. I am also worried that this is an outdated repo as not many people seem to have this issue.

How can I solve this issue? Any advices are really appreciated.

observation : Once I keep on re-starting the packet-forwarder (sometimes over a half a day!) , it does start. When it did, I has run for weeks without trouble!

Class-C ACK:TOO_EARLY

Hi,
I'm testing Class-C, and gateway return an ACK to server TOO_EARLY. But everything is ok, if server uses Class-A and mote uses Class-C.
I have set imme=true within txpk.
For example:

  • This is all right (Class-A)

    {
      txpk:{
        imme:false,
        tmst: RecvTime + RX1/RX2,
        ...
        }
    }
  • ACK : TOO_EARLY (Class-C)

    {
      txpk:{
        imme:true,
        ...
        }
    }  

What's wrong with it? What should I do with gateway?

TOO_EARLY when TOO_LATE

Hello. I am getting

src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED,
timestamp seems wrong, too much in advance (current=1213920578, packet=1213631788, type=0)

which is kinda weird because packet->count_us - time_us = 1213631788-1213920578 = -288790, which is definitely not > TX_MAX_ADVANCE_DELAY. The error should be TOO_LATE, not TOO_EARLY.

I guess this is an overflow error.

Extra information

Hello, I have some questions:

  1. The RF packet from end device encoded using Base64. What type of information we can get, decoding metadata as field "data".
  2. How we can get detailed information about gateway and endpoint (battery level, temperature and etc.)

packets types

Hi, I have a question about how this project can help us with a loranet deployment..
We would like to forward mysql data through lora (From lora gateway to lora device and vice versa) and I wonder if this lora-net packet forwarder can work in that scenario


| Server 2 |------|Lora device |*********** radio link**************** |Lora Gateway |------| Mysql serve1|
| mysql | || || |__________|

Downstream (ACK) from packet_forwarder not working

Hello

I've set up a Raspberry PI Model B with the IC-880A Concentrator as Gateway for my private LoRa Network. The Host is a Windows Service, which acts as UDP Listener and communicates with the Gateway.
Packets, that are forwarded from the Gateway can be received.
But if I try to acknowledge the PULL or PUSH request, nothing happens on the Gateway.¨
With the util_ack it works, and with util_sink I can see, that a packet with 4 bytes is incoming.

Can you please help?

My Settings are as follows:

global_conf.json

"gateway_conf": {
    "gateway_ID": "AA555A0000000000",
    /* change with default server address/ports, or overwrite in local_conf.json */
    "server_address": "192.168.43.48",
    "serv_port_up": 1680,
    "serv_port_down": 1681,
    /* adjust the following parameters for your network */
    "keepalive_interval": 10,
    "stat_interval": 30,
    "push_timeout_ms": 100,
    /* forward only valid packets */
    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": false
}

The Windows Service Host is listening to Port 1680 for up and Port 1681 for downstream.
If a PULL_DATA is received the Windows Service Host sends following Data to IP of the Gateway 192.168.43.248, Port 1681: [1][token][token][4].

The Gateway and the Host are connected over WiFi to a firewall-free network.

If down_stream data is received by the packetforwarder it shows it (I added a MSG("..")) but the buff_down is empty (all bytes are 0)

/* try to receive a datagram */
msg_len = recv(sock_down, (void *)buff_down, (sizeof buff_down)-1, 0);

DownStream

Hello,

I am trying to issue a downlink to the forwarder but it does not work as expected.

When I receive a packet PUSH_DATA for example, i get the tokens and try to return an acknowledge to the forwarder but on the status afterwards I get PUSH_DATA acknowledged 0.00%. This is weird because i sent it according the protocol (0x01 token token 0x01). I see that the bytes are received on the forwarder because i use the utilities to test the UDP connection and I see the 4 bytes received on the forwarder side, but are not recognized by the software. The same is valid for the PULL DATA requests and acknowledges.

Can you please assist me in some way?

Regards.

packet forwarder stops receiving packets after some time

Hello, i am using raspberry 3 v. B with the ic880a concentrator. I set everything as it is suggested and the gateway receives packets normally. However, as I observed after some time (maybe one day) the GW stops receiving packets, the program runs but it doesn't receive any packets. I believe that is some problem with the sx1301 module but i can not figured out. As somebody suggests I am checking for 2113929216 value of SX1301 time (PPS) and in this case I am shutting down the packet forwarder but this value never came up (unlike the error). Any ideas?

Reliability risk

Is there anyway to run the same packet forwarder in TCP/IP mode, UDP over large networks is not advisable

installing

Hello!

I use the packet_forwarder on the BeagleBone computer, and have to run the application each time I power it on. Is there way to "install" the packet forwarder as system service via the packet manger, like "aptitude install packet-forwarder" ? What repository should I use?

Thanks in advance,
Best regards!

PULL_RESP not received

Hi,
i'm having a strange issue...
I've compile and run the lora-gateway and the packet-forwarder without any problem with a ic880a-spi concentrator.Then, I've set the UDP out/in port to localhost:1680 in global_conf.json, and I've write a very simple python script for open a UDP socket and receive/send message to the packet-forwarder.
Here my global_conf.json: https://pastebin.com/pt2TFdgv
Here my python script: https://pastebin.com/WQurTnmk
Here the log of the packet-forwarder: https://pastebin.com/4XLw7aFu

I'm able to send the PUSH_ACK to the packet-forwarder anytime i get some data from the node, but the PULL_RESP never appear on the packet-forwarder log. I've also try removing the sleep from PUSH_ACK and PULL_RESP, and also changing the json on the PULL_RESP.

I'm working on it because i need to send a confirmation ACK to the node, otherwise it will try to resend the packet...
Then, i've got to collect all the packet received in one hour, and every hour turn on the GSM/3G connection and send all the packet to a my server.

I'm missing some procedure to send/receive the PULL_RESP in the packet-forwarder?

Checking internet connection

How to implement the packet forwarder with internet connection check and re-connection upon internet is established.

Packet forwarder with SX127X

Can I use packet forwarder with SX127X modem instead of multichannel SX130X modem?. My setup is RPI board with HopeRF SX1272 LoRa module. I dont have SX130X and not interested on multichannel as well.

TIA,
Prakash

No packets with large time offset

Hello!
I'm using git verstion of packet_forwarder and lora_gateway with DIY rpi2 (archlinux arm distro) and iC880A-based gateway (without GPS) and RFM95W-based transmitter with OTAA and private server.
Looks like after random periods of time I'm receiving no packets at all and it only could be fixed via restarting the packet forwarder (my systemd lora_pkt_fwd service also contains reset_lgw.sh script from lora_gateway with custom pin).
And according to logs packet loss is accompanied with time offset larger that 60000ms:

INFO: host/sx1301 time offset=(1491594643s:916918µs) - drift=60000286µs
...
host/sx1301 time offset=(1491597498s:536800µs) - drift=-1693691040µs

Could you help me with resolving the issue?
Should I look at lora_gateway code or is it looks like hardware problem?

Proxy config

Hi. Is it possible to configure a proxy?

I've tried with http_proxy env variable, but it doesn't work.

low range

hey,

we got a problem of low range in our project. We can send (and receive) data only if the forwarder and node arent more then 5 meters apart.

Maybe you can help us witch config we may change so this get better?

About exiting pkt_fwd

Hi, I have an issue.
When exiting pkt_fwd frequently, sometimes it didn't exit normally (maybe one or two hours later,pkt_fwd would exit fail , if pkt_fwd exit per 15 seconds. I use systemd to restart pkt_fwd) ,
I use command cat /proc/pid/status , found the value of Threads is 1 which process exit fail , but the value of Threads is 7 which process run normally, so I thought it was caused by function pthread_cancel(),
I use pthread_join instead of pthread_cancel , and test over 20 hours, it works fine.
so Is it the process go into deadlock state when use pthread_cancel to quit the thread? Or something else caused it ?
Regards

global_conf.json.US902: invalid config or does channel 64 use two radio signals?

Hi, I have a question related to the global_conf.json.US902 configuration. From my understanding this configuration will configure the gateway for channel 0-7 (125kHz) + 64 (500kHz).

What I don't understand is how channel 64 (chan_Lora_std in the JSON) would fit on radio: 0 as configured in the JSON.

Radio 0 frequencies (1.000.000Hz rx bandwidth):
Min: 902.200.000Hz, Mid: 902.700.000Hz, Max: 903.200.000Hz

Radio 1 frequencies (1.000.000Hz rx bandwidth):
Min: 902.900.000Hz, Mid: 903.400.000Hz, Max: 903.900.000Hz

Channel 64 (500000Hz bandwidth):
Min: 902.750.000, Mid: 903.000.000, Max: 903.250.000Hz

The max frequency of channel 64 (903.250.000Hz) exceeds the max frequency of radio 0 (903.200.000Hz).

Does this mean that the configuration is invalid, or does this mean that since there is an overlap of frequency range between radio 0 and radio 1, that the signal of both radios are being used?

UDP problem

hi,
Usually my gateway works fine, but when the gateway was re-assigned IP address as I restart the Router,problem comes:
function send(sock_down, (void *)buff_req, sizeof buff_req, 0) return -1, error code is Invalid argument.
Why would it happen?
In this situation,should I close the socket and reconnect it ? Or was it caused by another problem?
thanks.

List of global_conf.json keys

Atm, there is no documentation on all the available keys on the global_conf.json or the functionality of each key.

We have multiple questions in mind that could be answered if we had a very brief documentation, since we are doing lots of guess work. There are tags that we accidentally discovered by looking at multiple different example codes and we would really appreciate it if we could have a list 😄

Another big question in mind
We are wondering if we could add a second mCard to our Multitech Conduit and then expand the packet forwarder to handle it by using another "SX1301_conf" key? If so, what is the limit. This would let us to listen to 16 channels simultaneously rather than 8.

Thanks in advance for your help.

LoRaWan Channel

as per LoRaWan spec network server can dinamically define up to 16 channels on a single device using a mac command.
In global.json packet forwarder conf file there are only 8 chan_multiSF entry.

it is possible to update that entry up to 16 chan_multiSF using for example the second radio ?

If my understanding are coorect how will be possibel configure, on the fly, the GW with dinamic network server channel mask ?

Thanks in advance
B/R

Management device

Hi, Is it possible to manage device in level packet forwarder?

Thanks

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.