Wirnet™ i-series

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Wirnet™ iBTS Packet Forwarder v5.1.0-klk4 - Instructions ======

===== File structure =====

The package installation creates several files in the system.\\
These files are removed when uninstalling the package. 

{{:images:spf2_folders_v5.1.0-klk4.png}}

The Packet Forwarder installation package creates common API files at runtime (internal usage): \\
{{:images:spf2_folders_5.1.0-klk4_2.png.png| files are also removed when uninstalling (see below).}}


\\
===== Configuration =====

This chapter describes how to configure the packet Forwarder through <fc #4682b4>**6 steps**</fc>.

\\
==== JSON files : informations and behaviour ====

__Location :__ ''/user/spf2/etc''

{{:images:config_etc_v5.1.0-klk4.png.png}}

The packet forwarder uses two configuration files ''config.json'' and ''local.json''. To simplify the configuration, instead of directly using files named this way, two symbolic links are used :  
   * **config.json**: Contains the LoRa, the gateway and the GPS parameters.
   * **local.json**: Contains the calibration of the frontend. This file must not be modified, it is hardware dependent.

The way the packet forwarder takes configuration files into account is the following:
     - If there is a ''config.json'' parse it, look for the next file.
     - If there is a ''local.json'' parse it. If some parameters are defined in both config and local configuration files, the local definition overwrites the global config definition.
     - In our case, the ''local.conf'' is automatically generated at boot time. It contains antenna configuration. Do not change this file.

There are __two kinds of configuration__ files for the Wirnet™ iBTS product :  
   * **single_antenna** configuration.
   * **dual_antenna** configuration.

<note important>
The default LoRa Radio-Frequency configuration is "Europe 868MHz". This can be changed after the package installation.
</note>

To check whether you have to use single or dual mode, read the chapter 4.6.2.4 of the [[wiki:resources#wirnet_ibts_installation_and_maintenance_v10| Installation manual. ]]

<fc #4682b4>**Step 1**</fc><fc #4682b4> - Select the correct JSON file.</fc>
\\
<fc #4682b4>**Step 2**</fc><fc #4682b4> - Execute the following commands : </fc>
    * <code bash>
    rm config.json
    # <config file> is the chosen JSON in first step
    ln -s <selected_config_file> config.json</code>

\\
==== JSON files : configuration structure ====

Structure of ''config.json'' example files:

{{:images:json_structure_5.1.0-klk5.png}}

In each configuration file, there are the following arrays:

**SX1301 configuration**: that should contain the parameters for the Lora concentrator board (RF channels definition, modem parameters, etc).

{{:images:json_structure_5.1.0-klk5_2.png}}

**gateway_configuration**: that should contain the gateway parameters (gateway MAC address, IP address of the server, keep-alive time, etc).

{{:images:json_structure_5.1.0-klk5_3.png}}

There are many configuration fields among these files, but most of them are by default correctly filled.

<note>
For Japan configuration example files an LBT array is added. 
</note>
\\
==== Radio Frequencies configurations ====

Each LoRaLoc module contains two SX1301. Each SX1301 can be configured to use 10 different frequencies. However, these channels need to be contained within a 2 Mhz bandwidth.

  * ''chip_enable'' : enable/disable SX1301.

  * ''chip_center_freq'' : is used to define the center frequency of the SX1301. All 10 channels will be around this particular frequency (+/- 1Mhz). 

  * ''chan_rx_freq'' : are used to define each channel frequencies.

  * ''chip_rf_chain'' : define the rf chain used by the SX1301. The front-end board integrates two duplicated TX and Rx paths (RF1 path and RF2 path). Each TX/RX path is connected to one SMB antenna port, referenced as RF1 and RF2 (Installation manual 1.5.4.4 Front-end boards).

<code>
"SX1301_conf":[
 {
    "chip_enable": true,
    "chip_center_freq": 866000000,
    "chip_rf_chain": 0,
    "chan_multiSF_0": { "chan_rx_freq": 865500000, "spread_factor": "7-12" },
    "chan_multiSF_1": { "chan_rx_freq": 865700000, "spread_factor": "7-12" },
    "chan_multiSF_2": { "chan_rx_freq": 865900000, "spread_factor": "7-12" },
    "chan_multiSF_3": { "chan_rx_freq": 866100000, "spread_factor": "7-12" },
    "chan_multiSF_4": { "chan_rx_freq": 866300000, "spread_factor": "7-12" },
    "chan_multiSF_5": { "chan_rx_freq": 866500000, "spread_factor": "7-12" },
    "chan_multiSF_6": { "chan_rx_freq": 867100000, "spread_factor": "7-12" },
    "chan_multiSF_7": { "chan_rx_freq": 867300000, "spread_factor": "7-12" },
    "chan_LoRa_std" : { "chan_rx_freq": 867300000, "bandwidth": 250000, "spread_factor": 7 },
    "chan_FSK"      : { "chan_rx_freq": 866900000, "bandwidth": 125000, "bit_rate": 50000 }
 },{
    "chip_enable": true,
    "chip_center_freq": 868000000,
    "chip_rf_chain": 1,
    "chan_multiSF_0": { "chan_rx_freq": 867500000, "spread_factor": "7-12" },
    "chan_multiSF_1": { "chan_rx_freq": 867700000, "spread_factor": "7-12" },
    "chan_multiSF_2": { "chan_rx_freq": 867900000, "spread_factor": "7-12" },
    "chan_multiSF_3": { "chan_rx_freq": 868100000, "spread_factor": "7-12" },
    "chan_multiSF_4": { "chan_rx_freq": 868300000, "spread_factor": "7-12" },
    "chan_multiSF_5": { "chan_rx_freq": 868500000, "spread_factor": "7-12" },
    "chan_multiSF_6": { "chan_rx_freq": 868700000, "spread_factor": "7-12" },
    "chan_multiSF_7": { "chan_rx_freq": 868900000, "spread_factor": "7-12" },
    "chan_LoRa_std" : { "chan_rx_freq": 868300000, "bandwidth": 250000, "spread_factor": 7 },
    "chan_FSK"      : { "chan_rx_freq": 869100000, "bandwidth": 125000, "bit_rate": 50000 }
}],
</code>

<fc #4682b4>**Step 3**</fc><fc #4682b4> - Update the JSON configuration file with correct parameters for radio frequencies.</fc>

\\
==== Antennas configuration ====

To understand all antennas configuration possibilities read the chapter 4.6.2.4 of the Installation manual.

  * Enable fields are used to enable or disable emission and reception of the antennas. 

__Single antenna configuration:__
<code>
"rf_chain_conf": [
	{
		"rx_enable": true,
		"tx_enable": true,
		"tx_freq_min": 863000000,
		"tx_freq_max": 870000000
	}
],		
</code>

__Dual antenna configuration:__
<code>
"rf_chain_conf": [
	{
		"rx_enable": true,
		"tx_enable": true,
		"tx_freq_min": 863000000,
		"tx_freq_max": 870000000
	},
	{
		"rx_enable": true,
		"tx_enable": true,
		"tx_freq_min": 863000000,
		"tx_freq_max": 870000000
	}
],	
</code>
<fc #4682b4>**Step 4**</fc><fc #4682b4> - Update the JSON configuration file with correct parameters for antennas.</fc>


\\
==== Listen Before Talk configuration ====

Listen Before Talk (LBT) is a technique used in radiocommunications whereby a radio transmitter first senses its radio environment before starting a transmission.

This feature is mandatory in a few countries (such as Japan and Korea).

''enable'': Enable or disable LBT.

''rssi_target'': The RSSI threshold to detect if channels are busy or not (dBm).

''rssi_shift'':** Do not change this value**, this is the value to be applied to RSSI to convert RSSI in dBm to register value.

''chan_cfg'': 
  * ''freq_hz'': The LBT channel frequency in Hz. These frequencies needs to be the same as the one in the ''SX1301_conf'' array.

<note important>
By default, the frequencies of these channels are different from the one in the ''SX1301_conf'' array. Make sure to change them.
</note>

  * ''scan_time_us'': The LBT channel scan time to be used (only two available values: 128µs or 5ms).

  * ''transmit_time_ms'': Maximum transmission delay allowed (only two available values: 4000ms or 400ms).

<code>
"lbt_conf":{
	"enable": true,
	"rssi_target": -80,
	"rssi_shift": 131,
	"chan_cfg":[
		{ "freq_hz": 922000000, "scan_time_us": 5000, "transmit_time_ms": 4000 },
		{ "freq_hz": 922200000, "scan_time_us": 5000, "transmit_time_ms": 4000 },
		{ "freq_hz": 922400000, "scan_time_us": 128, "transmit_time_ms": 400 },
		{ "freq_hz": 922600000, "scan_time_us": 128, "transmit_time_ms": 400 },
		{ "freq_hz": 922800000, "scan_time_us": 128, "transmit_time_ms": 400 },
		{ "freq_hz": 923000000, "scan_time_us": 128, "transmit_time_ms": 400 },
		{ "freq_hz": 923200000, "scan_time_us": 128, "transmit_time_ms": 400 },
		{ "freq_hz": 923400000, "scan_time_us": 128, "transmit_time_ms": 400 }
	]
},
</code>

<fc #4682b4>**Step 5**</fc><fc #4682b4> - Update the JSON configuration file with correct parameters for LBT.</fc>

==== Gateway configuration ====

  * ''server_address'': Is the address of the server to which the packets will be forwarded.

  * The following fields describe the ports used by the packet forwarder to communicate with the LoRa server
       * ''serv_port_up''.
       * ''serv_port_down''.

  * ''keepalive_interval'': Is the period (in seconds) at which the packet forwarder will send a PUSH_DATA frame to the server.

  * ''stat_interval'': Is the period (in seconds) at which the statistics of the packet forwarder are logged.
 
  * ''push_timeout_ms'': Push timeout value.
 
  * The following fields are Boolean that defines whether invalids packets should be forwarded to the server or not :
       * ''forward_crc_valid''.
       * ''forward_crc_error''.
       * ''forward_crc_disabled''.

  * ''autoquit_threshold'': Enable auto-quit after a number of non-acknowledged PULL_DATA. If the packet forwarder detects X times in a row that it didn't receive feedback from the LNS, it will automatically restart.

<code>
"gateway_conf": {
	"server_address": "lns",
	"serv_port_up": 1700,
	"serv_port_down": 1700,
	"keepalive_interval": 10,
	"stat_interval": 30,
	"push_timeout_ms": 100,
	"forward_crc_valid": true,
	"forward_crc_error": false,
	"forward_crc_disabled": false,
	"autoquit_threshold": 3
}
</code>

<fc #4682b4>**Step 6**</fc><fc #4682b4> - Update the JSON configuration file with correct parameters for the gateway.</fc>

\\
=== Gateway ID configuration ===

From version v5.1.0-klk4_5.1.0-klk5 the gateway ID field has been suppressed from the JSON file. A default gateway ID based on the CPU serial number is automatically generated by the packet forwarder.

== How to use another gateway ID? ==

It is possible to use another gateway_ID instead of the default gateway_ID.
To do this, a gateway_ID (16 hexadecimal digits) field need to be added in the ''gateway_conf'' array of the JSON configuration file.

<code>
    "gateway_conf": {         
        "gateway_ID": "ABABABABCDCDCDCD",
        "server_address": "52.18.106.103",
        "serv_port_up": 20000,        
        "serv_port_down": 20000,             
        "keepalive_interval": 10,           
        "stat_interval": 30,
        "push_timeout_ms": 100,
        "forward_crc_valid": true,    
        "forward_crc_error": false,   
        "forward_crc_disabled": false,       
        "autoquit_threshold": 3             
    }   
</code>

Restart your packet forwarder to apply the modification.

<code>
# monit restart spf2 
</code>

== How to know the gateway ID used? ==

The default gateway_ID is based on the CPU serial number. To check the gateway ID used you can consult the packet forwarder logs.

__Case 1:__ No gateway_ID defined in the ''gateway_conf'' array. The default gateway_ID is used.

<code>
# grep "Gateway EUID" /user/spf2/var/log/spf2.log
Jun 13 14:27:22 klk-lpbs-050789 local1.notice spf2: INFO: Using Gateway EUID: 7276FF002E050789
Jun 13 14:28:02 klk-lpbs-050789 local1.notice spf2: I/ Using default Gateway EUID: 7276FF002E050789
</code>

__Case 2:__ No gateway_ID defined in the ''gateway_conf'' array. The defined gateway_ID is used.

<code>
# grep "Gateway EUID" /user/spf2/var/log/spf2.log
Jun 13 14:46:11 klk-lpbs-050789 local1.notice spf2: I/ Using default Gateway EUID: 7276FF002E050789
Jun 13 14:46:11 klk-lpbs-050789 local1.notice spf2: INFO: Using Gateway EUID: ABABABABCDCDCDCD
</code>

The first line indicates the default gateway_ID: ''I/ Using default Gateway EUID: 7276FF002E050789''. \\ 
The second line indicates the gateway_ID used: ''INFO: Using Gateway EUID: ABABABABCDCDCDCD''.

\\
=== Configure_spf2 utility ===

The ''configure_spf2'' utility is a tool to easily configure the SPF from command line.\\
It can be used to read or edit the default ''config.json'' or another configuration file.

Here is the help of this tool:
<code>
# /user/spf2/bin/configure_spf2 --help
Usage: configure_spf2 [OPTION...] JSON_PATH [VALUE]

-f, --file FILE           Read this file instead of the default one.
-v, --verbose             Turn on verbose output.
                          This option can be used multiple times.
    --version             Print version information and exit.
-h, --help                Print this help message and exit.
</code>

A use case of this tool is available in the next section.

=== Configuration example - Semtech's LoRa demonstrator: gateway configuration ===

Send the following shell commands (using a debug probe or an SSH connection) to configure the packet forwarder to work with the European Semtech's LNS. The field values might be outdated, make sure to use the most up-to-date IP/ports.

<code>
# /user/spf2/bin/configure_spf2 gateway_conf.server_address 52.18.106.103
# /user/spf2/bin/configure_spf2 gateway_conf.serv_port_up 20000
# /user/spf2/bin/configure_spf2 gateway_conf.serv_port_down 20000
</code>

Restart your packet forwarder to apply modifications.

<code>
# monit restart spf2 
</code>
\\ \\
===== Monitoring and maintenance =====

==== Starting and stopping the packet forwarder ====

<note warning>
The Semtech's packet forwarder (process "spf2") will be restarted in loop until the access to the LoRaWAN server is correct.
</note>

=== Monit process ===
Use the ''Monit'' process start or stop the packet forwarder.

''Monit <start | stop | restart> <service>''

  * Check whether packet forwarder process is present or not
  * <code> ps ww | grep spf2 </code>
  * If packet forwarder is not launched :
  * <code>monit start spf2</code>
  * If packet forwarder is launched :
  * <code>monit stop spf2</code>
  * Restart the packet forwarder :
  * <code>monit restart spf2</code>

\\
==== Process and resources monitoring ====
Once the packet forwarder is configured its status can be checked using ps command.

<code>
 1000 root     13220 S    /usr/bin/monit -c /etc/monitrc
 1009 root      2744 S    {start_getty} /bin/sh /bin/start_getty 115200 ttymxc0
 1010 root      2976 S    -sh
 1012 root      2596 S    /sbin/watchdog -t 30 /dev/watchdog
 1026 root      2740 S    {execute_spf2.sh} /bin/sh -e /user/spf2/bin/execute_spf2.sh
 1028 root     52136 S    /user/spf2/bin/spf2 -g /dev/nmea1 -y
 1029 root      2964 S    logger -p local1.notice -t spf2
</code>

For more detailed information with ''monit'' these commands can be used :


<code>
# monit -v : Gives basic information on the SPF2 process
# ======================================================
monit -v | grep -A 2 spf2
Process Name          = spf2
 Pid file             = /var/run/packet_forwarder.pid
 Monitoring mode      = active
--
 Start program        = '/user/spf2/bin/execute_spf2.sh' timeout 30 s
 Stop program         = '/usr/bin/killall -q spf2' timeout 30 s
 Existence            = if does not exist then restart

# monit status : Gives informations about resources consumption, pid files and monitoring status.
# ===============================================================================================
monit status | grep -A 18 spf2
Process 'spf2'
  status                       Running
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    nostart
  pid                          1028
  parent pid                   1026
  uid                          0
  effective uid                0
  gid                          0
  uptime                       13m
  threads                      7
  children                     0
  cpu                          0.8%
  cpu total                    0.8%
  memory                       0.8% [1.9 MB]
  memory total                 0.8% [1.9 MB]
  data collected               Tue, 04 Jul 2017 07:42:59
</code>

\\
==== Log monitoring ====

__Location__ : ''/user/spf2/var/log''

{{:wiki:log.png|}}

While deploying packet forwarder on the Wirnet™ iBTS, the package installer configures syslogd to manage SPF logs in the ''/user/spf/var/log'' directory. This folder will contain activity traces of the packet forwarder. A logrotate feature is used to limit disk space used :   
  * maximum files : ''10''. 
  * maximum size per file : ''200Kb''.
  * most recent file : ''spf2.log''
  * less recent file : ''spf2.log.9''


To survey the log files: 
<code>
tail -f /user/spf2/var/log/spf2.log
</code>

\\
==== Uninstall the packet forwarder ====

Opkg packages (.ipk) can be removed thanks to dedicated procedure: 
[[wiki:sw_updates#package_removal|Software updates:package removal]].

\\ \\
===== Fine Timestamp decoding =====

==== General informations ====

Fine timestamps are the nanosecond accurate dates at which a packet are received by the gateway.
Fine timestamps are generally used for Geolocalization algorithms.\\

=== How it works? ===


  - **//An end-device//** - sends a packet.
  - **//The Gateway//**
      * Receives the packet from the end-device.
      * Retrieve the date at which it received the packet thanks to its GPS chip.
      * Splits the date (e.g. 2017-10-23 13:37:45 186ms 118µs 527ns) in two parts :
          * The <fc #cd5c5c>//**classic timestamp**//</fc>: contains second-accurate timestamp (e.g. 2017-10-23 13:37:45). 
          * The <fc #cd5c5c>//**nanosecond number**//</fc>: is the number of nanosecond elapsed since the <fc #cd5c5c>//**classic timestamp**//</fc>  (e.g. 186118527).
      * Encrypts the <fc #cd5c5c>//**nanosecond number**//</fc> with an hardcoded AES key.
  - **//The Packet Forwarder//** 
      * Retrieves the <fc #cd5c5c>//**classic timestamp**//</fc> and the <fc #cd5c5c>//**nanosecond number**//</fc>.
      * Sends them to the LNS.
  - **//The LNS//**
      * Decrypts the <fc #cd5c5c>//**nanosecond number**//</fc>. 
      * Sums the <fc #cd5c5c>//**nanosecond number**//</fc> with the <fc #cd5c5c>//**classic timestamp**//</fc>.

{{ :images:ftimestmp_scheme.png |}}


\\ \\
==== Requirements ====

=== Obtaining the AES key(s) ===

<fc #4682b4>**Step 1** - Retrieve the FPGA identifier(s).</fc>
     * Connect to your Wirnet™ iBTS gateway.
     * Type the following command: ''cat /tmp/sys_startup_status.json | grep "fpga_cid"''.
     * This will display an output: ''"fpga_cid": "0x00F14086286FFF07",''.


<fc #4682b4>**Step 2** - Contact Semtech and provide them the ''fpga_cid'' of each loraloc module (up to 4 ''fpga _cid'', depending on the product).</fc>

{{ :images:products.png |}}

=== GPS fix ===

The GPS is used by the gateway to retrieve fine timestamps.
GPS synchronization (Fix) can be monitored through NMEA frames and especially $GNGGA frames. 

command: ''cat/dev/nmea2'' \\
parameters:
  * 7th field - ''GPS fix'' 0=no fix, <fc #008000>**1**</fc>=fix GPS.
  * 8th field - ''Connected satellites'' number of connected satellites.
'' $GNGGA,132911.00,4809.08287,N,00135.18250,W,<fc #008000>**1**</fc>,04,4.47,96.1,M,47.7,M,,*69 ''

A GPS fix value equal to ''1'' is required to use the fine timestamp feature.\\
If Fix value is not equal to one, the following error will be displayed in the packet forwarder: \\ 
''ERROR: [BRD0] timestamp is out of range!''.


\\ \\
==== Decyphering ====

== JSON Message ==

The packet received by the gateway is sent to the LNS in a JSON array as below:

<code>
[2017-10-23 15:38:13.439] [1508765865700627] JSON up [1] [CDC6]: 
{"rxpk":
     [{"tmst":64679556,
     "time":"2017-10-23T13:37:45.570488Z",
     "brd":0,
     "aesk":0,
     "freq":868.100000,
     "stat":1,
     "modu":"LORA",
     "datr":"SF12BW125",
     "codr":"4/5",
     "size":30,
     "data":"gFr/ADAAGAIB3Z7VMLH56+YXOwKjMNBjojD0hj3D",
     "rsig":[{
          "ant":1,
          "chan":21,
          "rssic":-112,
          "lsnr":-14.0,
          "etime":"7xkP+6rs/F/Y845JaB5pnQ==",
          "ftime":186118527,
          "ft2d":-323,
          "rfbsb":100,
          "rs2s1":93,
          "rssis":-127,
          "rssisd":0,
          "foff":-2091
          }]
     }]
}
</code>


  * ''time'': <fc #cd5c5c>//**classic timestamp**//</fc>: ''"time":2017-10-23T13:37:45.570488Z''.
  * ''etime'': <fc #cd5c5c>//**nanosecond number**//</fc> - **e**ncrypted **time**. ''"etime":"7xkP+6rs/F/Y845JaB5pnQ=="''.
  * ''ftime'': decrypted <fc #cd5c5c>//**nanosecond number**//</fc>, this field is used for debug purposes. ''"ftime":"186118527"''.

<note>the ''etime'' field can sometimes be missing due to a loss of GPS signal.</note>

\\ \\

=== Security key ===
The AES Key provided by semtech is used to decypher the ''etime'' field.

AES key:   
  * Algorithm: AES-ECB.
  * Key length: 128 Bits.



=== Decypher the data ===

The timestamp is decyphered by the **Application server** of the LNS.\\
Hereunder is an example of script that decrypts the <fc #cd5c5c>//**nanosecond number**//</fc> using OpenSSL.

This example is presented as is. It is not written to cover every possible exception. It is up to the user to adapt it to its needs.

<note important>
To avoid an issue due to the ''nopad'' parameter in the script, use ''OpenSSL 1.1.0g 25 May 2017'' or greater. \\
To check the version : ''OpenSSL version''.
</note>

The ''etime field'' is an hexadecimal value which has been base 64 encoded.
There are 32 clock ticks each nanosecond. Therefore, to retrieve the number of nanosecond from the ''etime'' value, the value needs to be divided by 32.


<file bash etime_dec.sh>
#!/bin/bash

#checking parameters
if [[ $# -ne 2 ]];then
    echo 'Usage : ./etime_dec.sh <etime value> <AES 128-ecb-key>'
    exit
fi

ETIMEFIELD=$1
AESKEY=$2

# OpenSSL decyphering (convert from base64 to decimal, decypher, convert from bin to hex, remove trailing '0'
RESULT=$(echo -n $ETIMEFIELD | base64 -d | openssl enc -d -aes-128-ecb -K $AESKEY -nopad | xxd -u -p | sed 's/^0\+/0x/')

# Display data
echo "etime decyphered = $RESULT"
echo -n "etime real value = "
printf "%d / 10^9 / 2^5\n" $RESULT | bc -l
</file>

=== example ===

The following is an example of decyphering using the script mentioned above.
For ''etime'' and ''ftime'' values refer to the previous JSON message:
  * "etime":"7xkP+6rs/F/Y845JaB5pnQ==".
  * "ftime":**186118527**.

<code sh>
chmod u+x etime_dec.sh
dos2unix etime_dec.sh
./etime_dec.sh 7xkP+6rs/F/Y845JaB5pnQ== 5FEAFD3647351BEB423F93CEF14A5DDB
etime decyphered = 0x162FE2FEE
etime real value = .18611852743750000000
</code>

Note that ''etime'' value and ''ftime'' are the same.


\\ \\
==== Debugging====

In order to check if the application server works properly, its results can be compared to the ''ftime'' fields.
To activate the ''ftime'' field the AES key provided by Semtech must be defined in the packet forwarder  configuration:
  * location: ''/usr/spf2/etc/<config.json>''.
  * field: ''"aes_key": "ABCDEF0123456789ABCDEF0123456789" # Default value''.


\\ \\
===== Compilation =====
\\ \\

<note tip>
The pre-compiled packet forwarder spf2 v5.1.0-klk4 (''spf2_5.1.0-klk4_5.1.0-klk5_klk_lpbs.ipk'') is available in the [[resources:resources_spfv2_v5.1.0-klk4|SPF v2 Resource]] wiki page.\\
</note>

SPF2 package is an ipk which install SPF2 on the board.\\
This chapter describes the procedure to compile the packet forwarder and generate the IPK from the source file ''spf2-5.1.0-klk4.tar.gz'', available in the [[resources:resources_spfv2_v5.1.0-klk4|SPF v2 Resource]] wiki page.\\
Procedure hereunder is dedicated to Linux operating systems (32 bits and 64 bits). There is no embedded compiler in Wirnet™ iBTS.


==== Prerequisites ====

=== Required packages / tools to build the SPF2: ===
  * ''build-essential''\\
  * ''tar''\\
  * ''opkg-build''

Please ensure that these tools are in the ''$PATH''.

<note tip>''opkg-build'' can be install by using this one-liner:
<code>
wget -qO- https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/plain/opkg-build | sudo tee /usr/local/bin/opkg-build && sudo chmod 755 /usr/local/bin/opkg-build

</code>
</note>

=== Required sources: ===
  * ''spf2-5.1.0-klk4.tar.gz'' ([[resources:resources_spfv2_v5.1.0-klk4|SPFv2 5.1.0-klk4 Resources]])\\
  * ''libloragw2-5.1.0-klk5.tar.gz'' ([[resources:resources_halv2_v5.1.0klk5|HALv2 5.1.0-klk5 Resources]]])\\

=== Required toolchain: ===

Set up the environment as described in the [[wiki:toolchain|toolchain]] page.

This build is using 2 sources packages (spf2 and libloragw2). To manage this specifity the ''pkg-config'' utility is used. In order to avoid issues, the toolchain sysroot is not used, please modify the toolchain environment file (use your own toolchain directory):
<code>
# cat << EOF >> /opt/toolchains/lpbs/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
unset PKG_CONFIG_SYSROOT_DIR
EOF
</code>

Source the toolchain environment :
<code bash>
source /opt/toolchains/lpbs/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
</code>


==== Library ====
It is necessary to build and install the LoRa HAL in order to build the SPF2:

  * Extract the sources
Begin by extracting the sources and change directory (''libloragw2-5.1.0-klk5.tar.gz'' 
 from [[resources:resources_halv2_v5.1.0|HALv2 5.1.0 Resources]] page):
<code>
# tar xzf libloragw2-5.1.0-klk5.tar.gz
# cd libloragw2-5.1.0-klk5/
</code>

  * Configure the build:
<code>
# ./configure --host=arm-poky-linux-gnueabi --prefix=/tmp/libloragw2
checking for...
...
configure: creating ./config.status
config.status: creating ...
config.status: executing depfiles commands
</code>

  * Install the library:
<code> 
# make install
...
 /bin/mkdir -p '/tmp/libloragw2/lib'
 /usr/bin/install -c -m 644  libloragw2.a '/tmp/libloragw2/lib'
 ( cd '/tmp/libloragw2/lib' && arm-poky-linux-gnueabi-ranlib libloragw2.a )
 /bin/mkdir -p '/tmp/libloragw2/include'
 /usr/bin/install -c -m 644 libsx1301ar/inc/sx1301ar_hal.h libsx1301ar/inc/sx1301ar_aux.h libsx1301ar/inc/sx1301ar_dsp.h libsx1301ar/inc/sx1301ar_err.h libsx1301ar/inc/sx1301ar_gps.h libsx1301ar/inc/sx1301ar_lbt.h libsx1301ar/inc/sx1301ar_radio.h libsx1301ar/inc/sx1301ar_reg.h i2c_functions/i2c_linuxdev.h spi_functions/spi_linuxdev.h '/tmp/libloragw2/include'
 /bin/mkdir -p '/tmp/libloragw2/lib/pkgconfig'
 /usr/bin/install -c -m 644 libloragw2.pc '/tmp/libloragw2/lib/pkgconfig'
</code>

==== Build ====

  * Extract the sources
Begin by extracting the sources and change directory (''spf2-5.1.0-klk4.tar.gz'' from [[resources:resources_spfv2_v5.1.0-klk4|SPFv2 5.1.0-klk4 Resources]] page):
<code>
# tar xzf spf2-5.1.0-klk4.tar.gz
# cd spf2-5.1.0-klk4/
</code>
  * Export the path:
<code>
# export PKG_CONFIG_PATH=/tmp/libloragw2/lib/pkgconfig
</code>

  * Configure the build:
<code>
# ./configure --host=arm-poky-linux-gnueabi --prefix=/user/spf2
checking for...
...
checking for LORAGW2... yes
...
configure: creating ./config.status
config.status: creating ...
config.status: executing depfiles commands
</code>

  * Create the ipk package:
<code>
# make package
  GEN      ipk/spf2.init
...
  GEN      spf2_5.1.0-klk4_5.1.0-klk5_klk_lpbs.ipk
</code>
Wirnet™ i-series

User Tools

Site Tools

Page Tools
