Giter Site home page Giter Site logo

lora-net / sx1302_hal Goto Github PK

View Code? Open in Web Editor NEW
225.0 35.0 275.0 1.79 MB

SX1302/SX1303 Hardware Abstraction Layer and Tools (packet forwarder...)

License: Other

Makefile 1.41% C 95.77% Shell 0.21% Python 0.11% C++ 2.49%
sx1302 sx1303 gateway corecell

sx1302_hal's Introduction

 / _____)             _              | |
( (____  _____ ____ _| |_ _____  ____| |__
 \____ \| ___ |    (_   _) ___ |/ ___)  _ \
 _____) ) ____| | | || |_| ____( (___| | | |
(______/|_____)_|_|_| \__)_____)\____)_| |_|
  (C)2020 Semtech

SX1302 LoRa Gateway project

1. Core library: libloragw

This directory contains the sources of the library to build a gateway based on a Semtech LoRa SX1302 concentrator chip (a.k.a. concentrator). Once compiled all the code is contained in the libloragw.a file that will be statically linked (ie. integrated in the final executable).

The library also comes with few basic tests programs that are used to test the different sub-modules of the library.

Please refer to the readme.md file located in the libloragw directory for more details.

2. Helper programs

Those programs are included in the project to provide examples on how to use the HAL library, and to help the system builder test different parts of it.

2.1. packet_forwarder

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.

((( Y )))
    |
    |
+- -|- - - - - - - - - - - - -+        xxxxxxxxxxxx          +--------+
|+--+-----------+     +------+|       xx x  x     xxx        |        |
||              | USB |      ||      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.

Please refer to the readme.md file located in the packet_forwarder directory for more details.

2.2. util_net_downlink

The downlink packet sender is a simple helper program listening on a single UDP port, responding to PUSH_DATA and PULL_DATA datagrams with proper ACK, and sending downlink JSON packets to the socket, with given frame parameters, at regular time interval. It is a network packet sender.

It can also be used as a UDP packet logger to store received uplinks in a local CSV file.

Please refer to the readme.md file located in the util_net_downlink directory for more details.

2.3. util_chip_id

This utility configures the SX1302 to be able to retrieve its EUI. It can then be used as a Gateway ID.

2.4. util_boot

On used for a USB gateway, this software switches the concentrator in DFU mode in order to program its internal STM32 MCU.

2.5. util_spectral_scan

This software allows to scan the spectral band using the additional sx1261 radio of the Semtech Corecell reference design.

3. Helper scripts

3.1. tools/reset_lgw.sh

This script is used to perform the basic initialization of the SX1302 through the GPIOs defined by the CoreCell reference design. It gets the SX1302 out of reset and set the Power Enable pin. This script is called by every program provided here which accesses the SX1302. It MUST be located in the same directory as the executable of the program.

4. Compile, install and run instructions

All the libraries and test programs can be compiled and installed from the root directory of this project.

4.1. Clean and compile everything

make clean all

4.2. Install executables and associated files in one directory

First edit the target.cfg file located in the root directory of the project in order to configure where the executables have to be installed.

TARGET_IP : sets the IP address of the host of the gateway. In case the project is compiled on the gateway host itself (Raspberry Pi...), this can be left set to localhost.

TARGET_DIR : sets the directory on the gateway host file system in which the executables must be copied. Note that the directory MUST exist when invoking the install command.

TARGET_USR : sets the linux user to be used to perform the SSH/SCP command for copying the executables.

In order to avoid entering the user password when installing the files, the following steps have to be followed.

Lets say you want to copy between two hosts host_src and host_dest (they can be the same). host_src is the host where you would run the scp command, irrespective of the direction of the file copy!

  • On host_src, run this command as the user that runs scp
    ssh-keygen -t rsa

This will prompt for a passphrase. Just press the enter key. It'll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/id_rsa.pub

  • Transfer the id_rsa.pub file to host_dest
    ssh-copy-id -i ~/.ssh/id_rsa.pub user@host_dest

You should be able to log on host_dest without being asked for a password.

Now that everything is set, the following command can be invoked:
make install

In order to also install the packet forwarder JSON configuration files:
make install_conf

4.3. Cross-compile from a PC

  • Add the path to the binaries of the compiler corresponding to the target platform to the PATH environment variable.
  • set the ARCH environment variable to arm.
  • set the CROSS_COMPILE environment variable to the prefix corresponding to the compiler for the target platform.

An example for a Raspberry Pi target:

  • export PATH=[path]/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin
  • export ARCH=arm
  • export CROSS_COMPILE=arm-linux-gnueabihf-

Then, from the same console where the previous environment variables have been set, do:

make clean all

5. USB

This project provides support for both SPI or USB gateways. For USB interface, the concentrator board has a STM32 MCU with which the linux host will communicate to configure the sx1302 and the associated radios. The STM32 acts as a USB <-> SPI bridge.

The STM32 MCU has to be programmed with the binary provided in the mcu_bin directory of this project. For more details about how to flash it, please refer to the util_boot/readme.md instructions.

Each test utility of the project can be used using the `-u -d /dev/ttyACMx' command line option, or with the proper configuration in the packet forwarder global_conf.json file.

6. Third party libraries

This project relies on several third-party open source libraries, that can be found in the libtools directory.

7. Changelog

v2.1.0

Updates

This release only targets USB Corecell (no change for SPI connexion type). The USB-SPI bridge firmware, which runs on the STM32 MCU of the USB Corecell, has been updated for API clean-up and robustness improvements.

Changes

  • MCU: USB-SPI bridge firmware binary v1.0.0.
    • Removed obsolete commands (ORDER_ID__REQ_SPI, ORDER_ID__ACK_SPI)
    • Command index shifted after obsolete commands removal (ORDER_ID__REQ_MULTIPLE_SPI, ORDER_ID__ACK_MULTIPLE_SPI)
    • Command parser sends ORDER_ID__UNKNOW_CMD in case of wrong command size.
    • Code clean-up (typo fixed, comments added...)
    • Implemented Error_Handler() function to reset the MCU in case of fatal error.
    • Fixed a potential roll-over issue in read_write_spi() function.
    • Increased delay tolerance for host feedback on USB transfers.
  • HAL: Command interface updated for MCU firmware v1.0.0.
    • Removed obsolete commands from enum order_id_e
    • Shifted commands enum index according to USB-SPI bridge update.
    • Removed decode_ack_spi_access() unused function.
  • HAL: Added timing debug information under DEBUG_MCU.

v2.0.2

Updates

Fixed AGC firmware version check for sx1255/sx1257 based platforms (full-duplex gateways...).

Changes

  • HAL: AGC firmware version for sx1255/sx1257 based gateways is v6.
  • HAL: minor cosmetic changes & typo fixing.

v2.0.1

Updates

The fine timestamping feature has been fully validated with this release.

Changes

  • HAL: Adjusted the freq_offset field of received packets, to take into account the channel IF resolution error.
  • HAL: Refined the fine timestamp offset compared to Gateway v2, by taking into account the frequency offset of the received packet.
  • HAL: Fixed the preamble length for FSK downlinks
  • MCU: Removed the binary compiled in debug mode.
  • util_spectral_scan: actually use the nb_scan input argument which was ignored.

v2.0.0

New features

  • Added support for USB interface between the HOST and the concentrator, for sx1250 based concentrator only.
  • Added support for Listen-Before-Talk for AS923 region, using the additional sx1261 radio from the Semtech Corecell reference design v3.
  • Added support for Spectral Scan with additional sx1261 radio from the Semtech Corecell reference design v3.
  • Added support for SX1303 chip, for further Fine Timestamping support.
  • Merged the master-fdd-cn490 branch to bring support for CN490 Full-Duplex reference design. It is an integration of the releases v1.1.0, v1.1.1, v1.1.2 described below.

Changes

  • HAL: Reworked the complete communication layer. A new loragw_com module has been introduced to handle switching from a USB or a SPI communication interface, aligned function prototypes for sx125x, sx1250 and sx1261 radios. For USB, a mode has been added to group SPI write commands request to the STM32 MCU, in order to optimize latency during time critical configuration phases.
  • HAL: Added preliminary support for Fine Timestamping for TDOA localization.
  • HAL: Updated AGC firmware to v6: add configurable delay for PA to start, add Listen-Before-Talk support.
  • HAL: Added new API function lgw_demod_setconf() to set global demodulator settings.
  • HAL: Added new API functions for Spectral Scan.
  • Packet Forwarder: The type of interface is configurable in the global_conf.json file: com_type can be "USB" or "SPI".
  • Packet Forwarder: Changed the parameters to configure fine timestamping in the global_conf.json.
  • Packet Forwarder: Added sections to configure the spectral scan and Listen-Before-Talk features.
  • Packet Forwarder: Added a new thread for background spectral scan example, to show how to use the spectral scan API provided by the HAL, without interfering with the main tasks of the gateway (aka Receive uplinks and transmit downlinks).
  • Packet Forwarder: Added "nhdr" field parsing from "txpk" JSON downlink request in order to be able to send beacon request from Network Server.
  • Packet Forwarder: Added chan_multiSF_All in global_conf.json to choose which spreading factors to enable for multi-sf demodulators.
  • Packet Forwarder: Updated PROTOCOL.md to v1.6.
  • Tools: added util_spectral_scan, a standalone spectral scanner utility.

Notes

  • This release has been validated on the Semtech Corecell reference design v3 with USB interface.

v1.1.2

Integrated in v2.0.0 from master-fdd-cn490 branch.

  • packet forwarder: updated global_conf.json.sx1255.CN490.full-duplex with RSSI temperature compensation coefficients, and updated RSSI offset for radio 1.

v1.1.1

Integrated in v2.0.0 from master-fdd-cn490 branch.

  • HAL: Updated SX1302 LNA/PA LUT configuration for Full Duplex CN490 reference design.
  • test_loragw_hal_rx/tx: added --fdd option to enable Full Duplex
  • packet forwarder: updated global_conf.json.sx1255.CN490.full-duplex for CN490 reference design.

v1.1.0

Integrated in v2.0.0 from master-fdd-cn490 branch.

  • HAL: Added support for CN490 full duplex reference design.

v1.0.5

  • HAL: Fixed packet timestamp issue which was "jumping in time" in specific conditions.
  • HAL: Workaround hardware issue when reading 32-bits registers (timestamp, nb bytes in RX buffer...)
  • HAL: Fixed potential endless loop in sx1302_tx_abort() in SPI access fails.
  • Packet Forwarder: Added global_conf.json.sx1250.US915 for US915 band
  • test_hal_rx: added command line to specify RSSI offset to be applied

v1.0.4

  • Added missing LICENSE.TXT file
  • HAL & Packet Forwarder: added support for sx1250-based reference design for CN490 region
  • Packet Forwarder: disabled beaconing by default

v1.0.3

  • HAL: Fixed scheduled downlink time precision by taking the tx start delay into account.
  • HAL: Fixed timestamp correction calculation for BW250 & BW500
  • HAL: Fixed possible buffer overflow in lgw_receive() function
  • HAL: Keep packet received in RX buffer when the buffer allocated to receive the packets is too small. Remaining packets will be fetched on the next lgw_receive calls (aligned on SX1301 behaviour).

v1.0.2

  • Fixed compilation warnings reported by latest versions of GCC
  • Reworked handling of temperature sensor
  • Clean-up of unused files
  • Added instructions and configuration files for packet forwarder auto-start with systemd
  • Added SX1250 radio calibration at startup

v1.0.1

  • Packet Forwarder: Updated TX gain LUT in global_conf.json.sx1250 with proper calibration

v1.0.0

  • HAL: Initial official release for SX1302 CoreCell Reference Design.

v0.0.1

  • HAL: Initial private release for TAP program

8. 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

sx1302_hal's People

Contributors

mcoracin avatar mluis1 avatar smtcbboulet 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

sx1302_hal's Issues

How to know SX1302 Receiver state (it is reeving lora packets or not)

Hello,

Power Fluctuation is a test condition where high voltages switching took place outside of system condition to get Hardware failure rate. In this, system have to recover to its state again if anything fails, As gateway is places at higher altitude and also there may be lighting that also can cause this type of issue.
So we have to make it recoverable in this state. we can’t make system to stuck somewhere.

When there is power fluctuations, SX1302 stop receiving and didn’t receive any data till sx1302 reset.

But for resetting, I need to know the state of sx1302, if it is receiving or not problematically.

So, How do I know SX1302 is in receving mode or not?

Thank You

Building issue

Hello

Just following the README to build the project, just after cloning:

ubuntu@ubuntu-VirtualBox:~/sx1302_hal$ make all
make all -e -C libtools
make[1]: Entering directory '/home/ubuntu/sx1302_hal/libtools'
arm-poky-linux-gnueabi-gcc  -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/poky/3.1.10/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi -c  -O2 -pipe -g -feliminate-unused-debug-types  src/tinymt32.c -o obj/tinymt32.o
src/tinymt32.c:16:10: fatal error: tinymt32.h: No such file or directory
   16 | #include "tinymt32.h"
      |          ^~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:33: obj/tinymt32.o] Error 1
make[1]: Leaving directory '/home/ubuntu/sx1302_hal/libtools'
make: *** [Makefile:14: libtools] Error 2

Seems the libtoools\inc directory is not included ?

Joel

EDIT: make command below to pass over the issue:

make CFLAGS+="-Iinc -I../libtools/inc"

Clearly a problem with Makefiles...

Packet drop in Sx1302

After multiple testing I have observed that there are some LoRa packets drops in gateway designed from sx1302 , in comparison with sx1301 for which I have also attached some screenshots. There are min of 5% packets drops in sx1302 . I hope that someone have faced similar issue can help me in some way. thanks for help in advance.

Screenshot (38)
Screenshot (43)

Compatibility with SX1301

Hi-
Does this library work with the SX1301?
The old libraries haven't been updated in a while.
David

GPIO control - How does it work? - Where to find documentation?

Where can we find details on how to control the registers that control the GPIOs.

My current interest in the three GPIOs 3, 4 and 5 for the LEDs, but have a wider interest to control all unused GPIOs in the reference design.

Even a short description here outlining the chip's architecture would help point me in the right direction

is wrong format of pa_gain in global_conf.json.sx1250.CN490?

the pa_gain is from 0 to 3 in global_conf.json.sx1250.CN490, but the pa_gain is limited to 0 or 1 in code, which is right?

"tx_gain_lut":[
{"rf_power": -6, "pa_gain": 0, "pwr_idx": 0},
{"rf_power": -3, "pa_gain": 0, "pwr_idx": 1},
{"rf_power": 0, "pa_gain": 0, "pwr_idx": 2},
{"rf_power": 3, "pa_gain": 1, "pwr_idx": 3},
{"rf_power": 6, "pa_gain": 1, "pwr_idx": 4},
{"rf_power": 10, "pa_gain": 1, "pwr_idx": 5},
{"rf_power": 11, "pa_gain": 1, "pwr_idx": 6},
{"rf_power": 12, "pa_gain": 2, "pwr_idx": 7},
{"rf_power": 13, "pa_gain": 1, "pwr_idx": 8},
{"rf_power": 14, "pa_gain": 2, "pwr_idx": 9},
{"rf_power": 16, "pa_gain": 2, "pwr_idx": 10},
{"rf_power": 20, "pa_gain": 3, "pwr_idx": 11},
{"rf_power": 23, "pa_gain": 3, "pwr_idx": 12},
{"rf_power": 25, "pa_gain": 3, "pwr_idx": 13},
{"rf_power": 26, "pa_gain": 3, "pwr_idx": 14},
{"rf_power": 27, "pa_gain": 3, "pwr_idx": 15}
]

Can we set TX_JIT_DELAY to 60ms?

In our system, packet forwarder sometimes gets TX_SCHEDULED error after lgw_send() called, at about 0.3 percent chance. We think the reason of this is packet forwarder doesn't program the DOWN packet to the concentrator in time.
If we can set TX_JIT_DELAY large, for example: 60ms, thread_jit will have more time to program the DOWN packet to the concentrator, then TX_SCHEDULED error will disappear.

But we don't know what adverse effects will be caused by changing TX_JIT_DELAY, could anyone tell us? Thanks for your help!

High CPU load when using the packet forwarder

I am using an SX1302 corecell module with this library and packet forwarder on a custom system. Unfortunately the current configuration of the packet forwarder uses a whole lot of CPU time on that system. I was able to narrow it down to the JIT queue thread and uplink thread, they both use much of the CPU time relative to the available resources of the system. I was able to lower the CPU load by adjusting the parameter of the wait_ms(...) function-call in the respective threads from 10ms to 100ms. Is there a reason that these sleep times for the threads were chosen so low? Is it safe to just change the wait times in those thread without any compatibility issues?
Having these parameters adjustable over the global_conf.json would be very helpful in a future version.

Thanks and regards

Frequency values being rounded to 100 KHz resolution.

When the gateway is used for IN865 the frequencies reported by the packet forwarder are being changed from the configured channels. When the reported channel is used for the Rx1 window the end-device may miss the packet as it may be 25KHz from the actual channel.

Demonstrating with 915 hardware shows the frequency and foff. Should the foff be used to adjust the Rx Frequency?

Expecting to receive a packet at 915.385 MHz

INFO: radio 0 enabled (type SX1250), center frequency 915200000, RSSI offset -196.000000, tx enabled 1, single input mode 0
INFO: radio 1 enabled (type SX1250), center frequency 915385000, RSSI offset -196.000000, tx enabled 0, single input mode 0
INFO: no configuration for LoRa multi-SF spreading factors enabling
INFO: Lora multi-SF channel 0> radio 1, IF -137500 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 1> radio 1, IF 202500 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 2> radio 1, IF 32500 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 5 to 12

JSON up: {"rxpk":[{"jver":1,"tmst":4875057,"chan":6,"rfch":0,"freq":915.400000,"mid": 9,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssis":3,"lsnr":12.2,"foff":15044,"rssi":3,"size":18,"data":"gDQSNBKBCAANAesmY6ZqeFfo"}]}

Question: How to convert RSSI of Float to RSSI of uint16_t?

Question: How to convert RSSI of float to RSSI of uint16_t?

I choosed sx1302 to Gateway and sx1261 to nodes in Lora network.
I could get this int16_t format of RSSI in the codes of sx1261. For example, value maybe are "-70", "-75".
image

Then I want to get a RSSI value that format just like sx1261. But I don't how to convert the rssic to the int16_t format.

I find RSSI in here. And There are float type.
image

Then I found RSSI in here. And There are uint8_t type.
image

Why mix code from different reference designs?

For example, the 1.0.5 version code can be used normally on my device, but the latest 2.0.1 can't work because there are more non-existent devices such as sx1261 and ADC ad338r. If I want to use the code, I can only check the previous code version.

Even if I want to use the latest version of the code to enjoy some new features by commenting out the code that calls these devices, it is very hard.

All in all, the code has no downward compatibility.

Packet Drop, USB vs SPI

Hi,

There is some Packet Drop when comparing USB vs SPI Version. USB version has Packet Drop when compared with SPI Version

Thanks,
KarthiG.

No documentation to calculate RSSI in dBm for SX1302 + SX1250

I am using Semtech LoRa® Corecell reference design V1.0 (which has SX1302 and SX1250) and testing Receive and Transmit examples. While receiving packets, packet information are printed on console which has RSSI channel and RSSI signal value but those values are in dB.

Is there any equation to convert those values in dBm? I tried to find the information in source code and documents from Semtech website but all in vain.

How to perform continuous output with LORA modulation enabled.

The Sx1301 HAL utiliities have util_tx_continuous for CW, LORA and FSK modulations.
The test_loragw_hal_tx utility can perform a continuous CW but only output LORA and FSK in packet mode.
The certifications lab is requesting a 100% duty-cycle signal to measure Power Spectral Density.

AGC_status not available

Hello i m new here i am trying to run tx_utility in my controller and i am able to compile all files of libloragw but when i am running code its stuck into function agc_wait_staus(0x09) of ( sx125x_cal_tx_dc_offset) function .i am not understanding why its happening
so can anyone help me??

"foff" calculated method

  1. my config:
    {
    "SX130x_conf": {
    "spidev_path": "/dev/spidev0.0",
    "lorawan_public": true,
    "clksrc": 0,
    "antenna_gain": 0, /* antenna gain, in dBi */
    "full_duplex": false,
    "precision_timestamp": {
    "enable": false,
    "max_ts_metrics": 255,
    "nb_symbols": 1
    },
    "radio_0": {
    "enable": true,
    "type": "SX1250",
    "freq": 481800000,
    "rssi_offset": -207.0,
    "rssi_tcomp": {"coeff_a": -0.004, "coeff_b": 0.562, "coeff_c": -8.166, "coeff_d": 1224.528, "coeff_e": 11990.495},
    "tx_enable": true,
    "tx_freq_min": 470000000,
    "tx_freq_max": 510000000,
    "tx_gain_lut":[
    {"rf_power": -6, "pa_gain": 0, "pwr_idx": 0, "dig_gain": 0},
    {"rf_power": -3, "pa_gain": 0, "pwr_idx": 1, "dig_gain": 0},
    {"rf_power": 0, "pa_gain": 0, "pwr_idx": 2, "dig_gain": 0},
    {"rf_power": 3, "pa_gain": 1, "pwr_idx": 3, "dig_gain": 0},
    {"rf_power": 6, "pa_gain": 1, "pwr_idx": 4, "dig_gain": 0},
    {"rf_power": 10, "pa_gain": 1, "pwr_idx": 5, "dig_gain": 0},
    {"rf_power": 11, "pa_gain": 1, "pwr_idx": 6, "dig_gain": 0},
    {"rf_power": 12, "pa_gain": 2, "pwr_idx": 7, "dig_gain": 0},
    {"rf_power": 13, "pa_gain": 1, "pwr_idx": 8, "dig_gain": 0},
    {"rf_power": 14, "pa_gain": 3, "pwr_idx": 9, "dig_gain": 0},
    {"rf_power": 17, "pa_gain": 3, "pwr_idx": 15, "dig_gain": 0},
    {"rf_power": 20, "pa_gain": 3, "pwr_idx": 11, "dig_gain": 0},
    {"rf_power": 23, "pa_gain": 3, "pwr_idx": 12, "dig_gain": 0},
    {"rf_power": 25, "pa_gain": 3, "pwr_idx": 13, "dig_gain": 0},
    {"rf_power": 26, "pa_gain": 3, "pwr_idx": 14, "dig_gain": 0},
    {"rf_power": 27, "pa_gain": 3, "pwr_idx": 15, "dig_gain": 0}
    ]
    },
    "radio_1": {
    "enable": true,
    "type": "SX1250",
    "freq": 482600000,
    "rssi_offset": -207.0,
    "rssi_tcomp": {"coeff_a": -0.004, "coeff_b": 0.562, "coeff_c": -8.166, "coeff_d": 1224.528, "coeff_e": 11990.495},
    "tx_enable": false
    },
    "chan_multiSF_0": {"enable": true, "radio": 0, "if": -300000},
    "chan_multiSF_1": {"enable": true, "radio": 0, "if": -100000},
    "chan_multiSF_2": {"enable": true, "radio": 0, "if": 100000},
    "chan_multiSF_3": {"enable": true, "radio": 0, "if": -300000},
    "chan_multiSF_4": {"enable": true, "radio": 1, "if": -300000},
    "chan_multiSF_5": {"enable": true, "radio": 1, "if": -100000},
    "chan_multiSF_6": {"enable": true, "radio": 1, "if": 100000},
    "chan_multiSF_7": {"enable": true, "radio": 1, "if": 300000},
    "chan_Lora_std": {"enable": true, "radio": 1, "if": -200000, "bandwidth": 250000, "spread_factor": 7,
    "implicit_hdr": false, "implicit_payload_length": 17, "implicit_crc_en": false, "implicit_coderate": 1},
    "chan_FSK": {"enable": true, "radio": 1, "if": 300000, "bandwidth": 125000, "datarate": 50000}
    },

    "gateway_conf": {
    "gateway_ID": "AA555A0000000000",
    /* change with default server address/ports /
    "server_address": "127.0.0.1",
    "serv_port_up": 1700,
    "serv_port_down": 1700,
    /
    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,
    /
    GPS configuration /
    "gps_tty_path": "/dev/ttyUSB0",
    /
    GPS reference coordinates /
    "ref_latitude": 0.0,
    "ref_longitude": 0.0,
    "ref_altitude": 0,
    /
    Beaconing parameters */
    "beacon_period": 128,
    "beacon_freq_hz": 508300000,
    "beacon_datarate": 10,
    "beacon_bw_hz": 125000,
    "beacon_power": 14,
    "beacon_infodesc": 0
    },

    "debug_conf": {
    "ref_payload":[
    {"id": "0xCAFE1234"},
    {"id": "0xCAFE2345"}
    ],
    "log_file": "loragw_hal.log"
    }
    }

  2. I have a log like this:

CH0: 0 0 616 84 5133 14013 234 6128
CH1: 0 0 624 79 5214 13835 330 6280
CH2: 0 0 593 96 5186 13825 233 6386
CH3: 0 0 614 84 5139 14017 234 6130
CH4: 0 0 662 96 5178 13902 250 6239
CH5: 0 0 631 83 5201 13967 230 6316
CH6: 0 0 619 84 5111 13944 239 6326
CH7: 0 0 638 79 5272 13812 226 6305
CH8: 0 0 0 0 0 0 0 0
FSK: 0
Total number of LoRa packet received: 210517
Total number of FSK packet received: 0
Total number of LoRa packet received from 0xCAFE1234: 0
Total number of LoRa packet received from 0xCAFE2345: 0

JSON up: {"rxpk":[{"jver":1,"tmst":3897288465,"time":"2019-09-27T10:11:00.264327Z","tmms":1253614279264,"chan":5,"rfch":1,"freq":482.500000,"mid": 8,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssis":-63,"lsnr":12.5,"foff":-3362,"rssi":-62,"size":18,"data":"gPp4oQEAFtss6GNpmtthP3Ca"}]}

My question is: "foff":-3362, how is it calculated? 【 foff | number | LoRa frequency offset in Hz (signed interger) 】

My understanding: the data packet frequency of the log is: 482.500000MHz, the calculation method should be (482.6 - 0.1)MHz, chan is 5, and foff should be -100000 Hz.

How to know the starting position of string in JSON using the prason library?

As shown here, If I want to get the position of string 'data' in the JSON array rxpk, how to program?

I know that this library can get the content with code below, but I can't find the function of the position.

const char* data= json_object_get_string(json_array_get_object(json_object_get_array(json_value_get_object(json_parse_string_with_comments((const char*)(original string))), "rxpk"), 0), "data");

All I want to do is replace the original content with a new string to fill in.

tx test application CRC

Hello,

Is a CRC always sent with each transmission when using the test_loragw_hal_tx application?

Using a signal generator, I can send LoRa modulated packets, and the receiver (sx1250) can receive with passing CRC. Also I can receive other packets from devices (unknown location) with passing CRC. With the tx test application run from a different DUT, I can receive all packets with correct payload information (except for rssi because I do not have the temperature sensor), but all CRC checks fail. I am trying to debug this issue.

Does the temperature sensor adjustment have any influence on this? (typically I don't think it would)

Thanks,
Robert

Meaning of RSSI values

Hello all,

recently I have been doing some testing with test_loragw_hal_rx.
I usually get output that looks like this:

----- LoRa packet -----
count_us: 6233679
size: 23
chan: 5
status: 0x10
datr: 7
codr: 1
rf_chain 0
freq_hz 868100000
snr_avg: 9.8
rssi_chan:117.0
rssi_sig :116.0
crc: 0xFBA4

The RSSI values are however somewhat unclear for me. Normally I would expect the value to be somewhere around -110/-130 dBm, yet here the value is a positive number, which goes down as the signal gets weaker. For weak signals RSSI value is around 94. Could you maybe explain to me how to interpret those values?

Thank you.

cross compiling

Hello Every one

I am new hear and little bit of coding knoweledge .now i want to run packate forwarder on stm32mp157 (STM microprocessor)
for that i am using yocto SDK.now i want to cross compile this code but it shows error tinymt32.h not found.any one know how to add and where to add this file.or which package i need to install.

Branch master-fdd-cn490

Hello,
Question about the branch master-fdd-cn490 and the release made here: is this branch tested ? Is it stable ?
Why isn't it merged on master branch and why the tags 1.1.0, 1.1.1 and 1.1.2 have no release (the last one today is 1.05) ?
Thanks for the answer,
Joel

Failed To calibrate

Hello Everyone,
I am trying to run HAL_TX_TEST utility for esp32.not in Linux but in controller now i am able to load "cal_fw" in sx1302 using esp32
and its gives parity error(0x00)means its loaded but after that it tries to read( amp ,phi ,snr , rej) and its gives same value every time and
that values are not good enough and its shows ERROR: Rx image calibration of radio 0 failed.and in ras-pi it gives different value every time.so i am doing something wrong.

TX : send the last written data this time

I'm using STM32F407VGT6 to drive the sx1302.When i send the data(lgw_send()),enddev receives the data last time written into flash.This issue is also found in raspberryPi4.Scren shoots as flollw:
微信图片_20210519162743

Permit temperature sensor to be optional

Hello,

I would like to reopen an issue that was previously discussed at #28.

The issue deals with the mandatory temperature sensor required to make the RSSI compensation. All SX1302 boards have not the embedded temperature sensor has expected. I'm using RAK2287 which is a recent product (https://www.rakwireless.com/en-us/products/lpwan-gateways-and-concentrators/rak2287) but without the temperature sensor.

Today the solution is to get the code and patch it to remove the temperature sensor reading and use an arbitrary fixed value (let say 25 or 30°C for example).

It's a shame the RSSI compensation could not be bypassed today. Is it possible to study this use case please ?

If the answer is "yes that something that may be useful" I'm ready to work on it and propose a pull request.

Let me known please.

Regards
Joel

(actually working with a patched packet-forwarder v1.0.5 binary because I have not the force to do the patches for all consecutive versions each time a new one is released :-( )

AGC fw read/write check failed

The packet forwarder refuses to start with the following error -

sx1302_hal  *** Packet Forwarder ***
 sx1302_hal  Version: 2.1.0
 sx1302_hal  *** SX1302 HAL library version info ***
 sx1302_hal  Version: 2.1.0;
 sx1302_hal  ***
 sx1302_hal  INFO: Little endian host
 sx1302_hal  INFO: found configuration file global_conf_US915.json, parsing it
 sx1302_hal  INFO: global_conf_US915.json does contain a JSON object named SX130x_conf, parsing SX1302 parameters
 sx1302_hal  INFO: com_type SPI, com_path /dev/spidev0.0, lorawan_public 1, clksrc 0, full_duplex 0
 sx1302_hal  INFO: antenna_gain 0 dBi
 sx1302_hal  INFO: Configuring legacy timestamp
 sx1302_hal  INFO: Configuring Tx Gain LUT for rf_chain 0 with 16 indexes for sx1250
 sx1302_hal  INFO: radio 0 enabled (type SX1250), center frequency 904300000, RSSI offset -215.399994, tx enabled 1, single input mode 0
 sx1302_hal  INFO: radio 1 enabled (type SX1250), center frequency 905000000, RSSI offset -215.399994, tx enabled 0, single input mode 0
 sx1302_hal  INFO: no configuration for LoRa multi-SF spreading factors enabling
 sx1302_hal  INFO: Lora multi-SF channel 0>  radio 0, IF -400000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 1>  radio 0, IF -200000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 2>  radio 0, IF 0 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 3>  radio 0, IF 200000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 4>  radio 1, IF -300000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 5>  radio 1, IF -100000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 6>  radio 1, IF 100000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora multi-SF channel 7>  radio 1, IF 300000 Hz, 125 kHz bw, SF 5 to 12
 sx1302_hal  INFO: Lora std channel> radio 0, IF 300000 Hz, 500000 Hz bw, SF 8, Explicit header
 sx1302_hal  INFO: FSK channel 8 disabled
 sx1302_hal  INFO: global_conf_US915.json does contain a JSON object named gateway_conf, parsing gateway parameters
 sx1302_hal  INFO: gateway MAC address is configured to AA555A0000000000
 sx1302_hal  INFO: server hostname or IP address is configured to "miner"
 sx1302_hal  INFO: upstream port is configured to "1680"
 sx1302_hal  INFO: downstream port is configured to "1680"
 sx1302_hal  INFO: downstream keep-alive interval is configured to 10 seconds
 sx1302_hal  INFO: statistics display interval is configured to 30 seconds
 sx1302_hal  INFO: upstream PUSH_DATA time-out is configured to 100 ms
 sx1302_hal  INFO: packets received with a valid CRC will be forwarded
 sx1302_hal  INFO: packets received with a CRC error will NOT be forwarded
 sx1302_hal  INFO: packets received with no CRC will NOT be forwarded
 sx1302_hal  INFO: global_conf_US915.json does not contain a JSON object named debug_conf
 sx1302_hal  INFO: no debug configuration
 sx1302_hal  CoreCell reset through GPIO23...
 sx1302_hal  SX1261 reset through GPIO23...
 sx1302_hal  CoreCell power enable through GPIO18...
 sx1302_hal  CoreCell ADC reset through GPIO13...
 sx1302_hal  Opening SPI communication interface
 sx1302_hal  Note: chip version is 0x00 (v0.0)
 sx1302_hal  INFO: using legacy timestamp
 sx1302_hal  INFO: LoRa Service modem: configuring preamble size to 8 symbols
 sx1302_hal  ERROR: AGC fw read/write check failed
 sx1302_hal  ERROR: failed to load AGC firmware for sx1250
 sx1302_hal  ERROR: [main] failed to start the concentrator

Note the last 3 lines -

 sx1302_hal  ERROR: AGC fw read/write check failed
 sx1302_hal  ERROR: failed to load AGC firmware for sx1250
 sx1302_hal  ERROR: [main] failed to start the concentrator

What does the error mean ? and can we debug/fix this ?

Fail to reconfigure service channel (IF8) without reset the SX1302

After resetting the SX1302 and calling "lgw_start" from the HAL library, the Service channel(IF8) of the SX1302 works fine. I want to change the RX SF&BW of the service channel (IF8) without resetting the chipset. I call the "sx1302_lora_service_modem_configure" HAL function to change it, but it doesn't seem to work. It works fine on rare occasions, but most of the time RX seems to have stopped. The new SF&BW for RX is applied correctly only after resetting the chip and call "lgw_start".
Are there any other ways to reconfigure the service channel without reset?

synched gps time is sometimes 1 seconds off

I found that the absolute time, which is pulled from gps serial messages, is sometimes 1,0 seconds off.
I assume this happenes when the gps record whichs conveys the time arrives close to top of second. It then sticks to the previous pps signal, instead to the next pps, meaning that absolute time is adjusted to 1 second in past.

Cannot start lora service

I use customized code, which is different from the source code, but I can't solve the problem. Has anyone encountered a similar problem?
本人操作

LEDs in design not lighting up

The CONFIG_OK, RX and TX LEDs are not lighting up. Is it not being done in code ? If not can you please suggest how it can be done ?

CN490 FDD : test_loragw_i2c does not start

When launching the test_loragw_i2c test application on the CN490 full-duplex reference design, there is an error "failed to read I2C device /dev/i2c-1".

This is because this application targets the I2C_PORT_STTS751 0x39, which is wrong for this reference design.
It needs to be changed to 0x38.

TODO: make I2C params configurable for this test utility.

Same uplink but two rxpk

I'm using a SX1302C868GW1 and trying different devices (STM B-L072Z-LRWAN1 with LoRaMAC-node too) but most of the time the gateway is sending to the LNS two rxpk with different frequencies for the same uplink.

JSON up: {"rxpk":[{"jver":1,"tmst":1087514388,"chan":4,"rfch":0,"freq":867.300000,"mid": 1,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","rssis":-110,"lsnr":-11.0,"foff":-1732,"rssi":-100,"size":23,"data":"QPk1ASYAAQDLeGWe3Vtlz/jFaY8ZpnA="},{"jver":1,"tmst":1087514390,"chan":1,"rfch":1,"freq":868.300000,"mid": 0,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","rssis":-35,"lsnr":11.0,"foff":-1733,"rssi":-35,"size":23,"data":"QPk1ASYAAQDLeGWe3Vtlz/jFaY8ZpnA="}]}

Is it something related to the radio configuration? I'm using global_conf.json.sx1250.EU868

After stop, reconfig and start: Failed to set SX1250_0 in STANDBY_RC mode

I'm working on an application which implements the SX1301/2 HAL as a daemon. One of the features is to re-configure the concentrator channel-plan, without restarting the daemon. The initial startup works fine, however stopping the SX1302 (lgw_stop) doing the new configuration and starting (lgw_start') fails. In short I execute the following sequence of commands:

  1. board_setconf
  2. timestamp_setconf
  3. txgain_setconf
  4. rxrf_setconf
  5. rxif_setconf
  6. start

When there is new configuration to apply, I execute stop and start again with 1) (with the new configuration). However, step 6) fails with:

ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: Failed to set SX1250_1 in STANDBY_RC mode
ERROR: Failed to load fw

I'm unable to restart my binary after this failure, unless I execute the reset script first.

The same sequence with the SX1301 HAL works fine and there is no need to reset the SX1301 reset script.

For the SX1302 I'm using the v1.0.5 HAL version.

SX1261 in corecell design

Hi

There is a SX1261 transceiver connected to host via SPI. Does the code here handle that transceiver also ? I went through the code but didn't find any corresponding code here.

Regards
symovs

Packet Loss in SX1302

Hi All,

I am using the SX1302 module over spi and the Two SX1272 is Node, I am sending from Two Nodes Uplink every 5sec once for checking the Packet Loss, I am getting 30% packet loss because of the below logs.

INFO: Received pkt from mote: 00000417 (fcnt=77)

JSON up: {“rxpk”:[{“jver”:1,“tmst”:472419812,“chan”:0,“rfch”:0,“freq”:865.062500,“mid”: 8,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssis”:-49,“lsnr”:13.2,“foff”:-9254,“rssi”:-49,“size”:21,“data”:“gBcEAACATQAH1HLmqHHq1BJ9Zkuh”}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[116:222] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:473419812,“freq”:865.0625,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:12,“data”:“YBcEAACgjhrTIPAE”,“brd”:0,“ant”:0}}
WARNING: a downlink was already scheduled on rf_chain 0, overwritting it…
INFO: [jit] lgw_status returned TX_SCHEDULED
INFO: [down] PULL_ACK received in 0 ms

INFO: Received pkt from mote: 00000417 (fcnt=85)

JSON up: {“rxpk”:[{“jver”:1,“tmst”:472419812,“chan”:0,“rfch”:0,“freq”:865.062500,“mid”: 8,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssis”:-49,“lsnr”:13.2,“foff”:-9254,“rssi”:-49,“size”:21,“data”:“gBcEAACATQAH1HLmqHHq1BJ9Zkuh”}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[116:222] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:473419812,“freq”:865.0625,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:12,“data”:“YBcEAACgjhrTIPAE”,“brd”:0,“ant”:0}}
WARNING: a downlink was already scheduled on rf_chain 0, overwritting it…
INFO: [jit] lgw_status returned TX_SCHEDULED
INFO: [down] PULL_ACK received in 0 ms

no Ack ConfirmedDataUp Packet

Failed to set SX1250_0 in STANDBY_RC mode

I am getting this error:

root@f986d0ed3f2c:/opt/iotloragateway/packet_forwarder# sx1302/util_chip_id/chip_id -d /dev/spidev1.2
CoreCell reset through GPIO22...
Opening SPI communication interface
Note: chip version is 0x12 (v1.2)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
ERROR: failed to start the gateway

And the concentrator gets very hot, very quickly.

Any idea of the issue?

Transmitting at 1.5x requested frequency?

I'm the electrical engineer on a project. As part of EMC testing, we found that for the first time after our system boots up, when I use test_loragw_hal_tx to transmit, it transmits at the requested frequency as well as at 1.5x the requested frequency. If I Ctrl+C kill the process and start it again, the 1.5x frequency isn't there anymore. Continued repeats of the command also do not send the 1.5x frequency. If I warm reboot the system, the 1.5x frequency comes back for the first run of the command.

I'm using this command to transmit rather continuously:
./test_loragw_hal_tx -f 925.1 -r 1250 -m LORA -n 10000 -s 12 -b 500 -z 255 --pwid 16 -l 65535 -t 50

We are using release v2.0.1.

Does this sound like an issue that others have seen?

Thank you.

Stuck in "sx1302_agc_start" function

Hello,

I'm using release 1.0.5 with a RAK2287 EU868 mini-pcie SX1302 board.
I have difficulties to get it working. Impossible to start lora forwarder, impossible de get EUI with chip_id.

After adding some logs, I see the program is stuck in "sx1302_agc_start" function, at this step:

/* Wait for AGC fw to be started, and VERSION available in mailbox */
sx1302_agc_wait_status(0x01); /* fw has started, VERSION is ready in mailbox */

The byte retrieved from the SX1302 is always read "0". So it seems the AGC firmware doesn't start.

I don't know what is AGC and what is the purpose of all this stuff, just don't know how to get it working...
If you had a similar issue or know details about this to help, it's welcome 👍

Joel

CN490 configuration mismatch

Hello

I just compared the CN490 and CN490 USB configuration as shown below, and there is large differences at the radio configuration level. Why ?

cn490_diff

Thanks,
Joel

PS : some remark for the CN490.full-duplex config file template.

How to control GPIO8 and GPIO9 of SX1302 as outputs?

I want to use SX1302 to operate LNA, I don't know how to do it? Only see the use of GPIO6.
I did this without success:
init
/* Select GPIO_8 to be controlled by HOST /
lgw_reg_w(SX1302_REG_GPIO_GPIO_SEL_8_11_GPIO_8_SEL, 0);
/
Configure it as an OUTPUT */
lgw_reg_w(SX1302_REG_GPIO_GPIO_DIR_L_DIRECTION, 0xFF);

/* Select GPIO_9 to be controlled by HOST */

lgw_reg_w(SX1302_REG_GPIO_GPIO_SEL_8_11_GPIO_11_9_SEL, 0);
/* Configure it as an OUTPUT */
lgw_reg_w(SX1302_REG_GPIO_GPIO_DIR_L_DIRECTION, 0xFF);

out:
//GPIO8 High
lgw_reg_w(SX1302_REG_GPIO_GPIO_OUT_L_OUT_VALUE, 256);
wait_ms(100);
// GPIO8 low
lgw_reg_w(SX1302_REG_GPIO_GPIO_OUT_L_OUT_VALUE, 0);
//GPIO9 High
lgw_reg_w(SX1302_REG_GPIO_GPIO_OUT_L_OUT_VALUE, 512);
wait_ms(100);
// GPIO9 low
lgw_reg_w(SX1302_REG_GPIO_GPIO_OUT_L_OUT_VALUE, 0);

How to set Syncword value for proprietary

Dear @mcoracin,

In LoRaWAN, the Syncword value 0x34 is for public and 0x12 is for private.

In SX130, the Syncword is defined in loragw_hal.c. It is easy to identify and understand at here.

In SX1302, it is defined in loragw_sx1302.c at here.
However, it is not that easy to understand. It looks to me:

  • to set 0x34, actually 6 and 8 are set to the registers
  • to set 0x12, actually 2 and 4 are set to the registers.

Can I ask what is the algorithm behind it? Is that 0x68 = 0x34 * 2 or 0x6,0x8 = 0x3 * 2, 0x4 * 2.

If I would like to set a proprietary value e.g. 0x2B what should I set here? 0x56 = 0x2B * 2 or 0x4, 0x16 = 0x2 * 2, 0xB * 2

Thanks for your support.

Cheers,
Paul

The program 'test_loragw_spi' was not created

The program 'test_loragw_spi' was not created in the 'bin' folder.

This was my procedure:

git clone https://github.com/Lora-net/sx1302_hal.git
cd ~/sx1302_hal/
make clean all

ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub pi@localhost

make install
make install_conf

cd ~/sx1302_hal/bin
./test_loragw_spi

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.