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.
====== Peripherals ======



===== GPS =====

==== Localization ====

GPS signal is handled by the kgpsd daemon. By default, this daemon sends the received nmea frames to both virtual ports ''/dev/nmea1'' and ''/dev/nmea2''. Once a program reads a line from a virtual port, this line is deleted. Thus, only one program should read a virtual port at a time.

Some Wirnet™ Productline gateways don't have a GPS device. For these gateways, kgpsd will not be launched and ''/dev/nmeaX'' files will not be created.

By default, the packet forwarder reads the ''/dev/nmea1'' virtual port.

The number of virtual ports can be increased using the ''/etc/kgpsd.conf'' configuration file.

To determine whether GPS signal is properly received, NMEA sentences can be monitored using the following command:

<code bash>
cat /dev/nmea2
# ctrl-c to exit 
</code>

The GGA sentences contain 2 fields that indicate the quality of the GPS signal. 
  * The number of satellites being tracked. To calculate coordinates at least 4 satellites are required. If less than 4 satellites are being received, then ''0'' is always written. A maximum of 12 satellites can be received at the same time.
  * The fix quality. Receiving 4 satellites is not enough, a few sets of data are required to calculate coordinates. This sets of data can belong to receive (up to 15 minutes the first time). When the fix quality is equal to 1, it means the data is valid. 

Example of correct GGA sentence:

''$GNGGA,194640.00,4530.70229,N,00914.26728,E,<fc #008000>**1,12,**</fc>4.31,184.9,M,47.1,M,,*41''

//In this example, the fix quality is OK (<fc #008000>**1**</fc>) and <fc #008000>**12**</fc> satellites are received.//

Examples of bad GGA sentence:
  * Frames like the one below, indicates that not enough satellites are received.

''$GNGGA,152451.00,,,,,<fc #b22222>**0,00,**</fc>99.99,,,,,,*7E''

  * Frames like the one below, indicates that the set of data is not valid.

''$GNGGA,163411.00,,,,,<fc #b22222>**0,04,**</fc>24.77,,,,,,*7A''

In case the number of received satellites is small, the value of the field ''fixed_altitude'' in the ''/etc/kgpsd.conf '' configuration file can be set to ''yes''.

<code>
# 2D/3D Altitude management
fixed_altitude=yes
</code>

It will result in losing the altitude, however, only 3 satellites will be necessary to receive correct frames. 


==== Time management ====
  * Some NMEA frames contain UTC time.
  * GPS possesses two signal features:
      - **PPS (Pulse per second) feature:** It sends a hardware signal to produce a one-hertz clock. Pulse is produced at the beginning of each second.
      - ** TAI offset information:** It sends current TAI offset and time of next leap second insertion in UTC time (if any insertion is planned).

==== Leap second feature configuration ====

''KGPSd'' configuration file is ''/etc/kgpsd.conf''.\\
Configurations concerning leap second features are:
  * **leap_second_feature:** "yes" means the feature is activated (binary message will be sent sometimes).
  * **leap_second_file:** Filename where information about leap second will be written (each time a correct answer is received from GPS component).
  * **leap_second_period:** When daemon starts, for every 10 seconds, leap second information is checked until it is received.

Example of kgpsd configuration file for this feature: 
<code>
# Leap second management
## no: no leap second information is given, yes: information given
leap_second_feature=no
## where leap second information is written (this is not directly usable by NTPd)
leap_second_file=/tmp/kgpsd_leap_file.list
## Leap second information is looked for at first GPS fix after daemon start and then after given period
leap_second_period=2592000
</code> 

===== Sensors =====

==== Temperature ====

=== CPU temperature sensor ===

All Wirnet™ Gateways have a temperature sensor in their CPU. To read the sensor output:
<code bash>
cat /sys/class/hwmon/hwmon0/temp1_input
</code>

It is necessary to divide the result by 1000 to get the temperature in degrees Celsius (°C).

=== Wirnet™ iBTS temperature sensor ===

Wirnet™ iBTS has another temperature sensor in CPU module. To read this sensor temperature:
<code bash>
cat /sys/class/hwmon/hwmon1/temp1_input
</code>

It is necessary to divide the result by 1000 to get the temperature in degrees Celsius (°C).

==== Light sensor (Wirnet iBTS only) ====
A light sensor can be used to know if the Wirnet iBTS casing door is opened or closed.\\
To use the light sensor use the following command:

<code>
# echo "0.1000" > /sys/bus/iio/devices/iio\:device2/in_illuminance_integration_time
# cat /sys/bus/iio/devices/iio\:device2/in_illuminance_input 
47.240000 => opened casing
# cat /sys/bus/iio/devices/iio\:device2/in_illuminance_input
0.880000 => closed casing
</code>
==== Humidity and temperature sensor (Wirnet iStation only) ====
To read humidity level inside Wirnet iStation:
<code bash>
cat /sys/bus/i2c/drivers/hdc100x/1-0040/iio\:device2/in_humidityrelative_raw
cat /sys/bus/i2c/drivers/hdc100x/1-0040/iio\:device2/in_humidityrelative_scale
</code>

Humidity level is:
  * in_humidityrelative_raw * in_humidityrelative_scale in %

To temperature:
<code bash>
cat /sys/bus/i2c/drivers/hdc100x/1-0040/iio\:device2/in_temp_scale
cat /sys/bus/i2c/drivers/hdc100x/1-0040/iio\:device2/in_temp_offset
cat /sys/bus/i2c/drivers/hdc100x/1-0040/iio\:device2/in_temp_raw
</code>
Temperature in degrees Celsius is:
  * ((in_temp_raw + in_temp_offset) * in_temp_scale) / 1000


===== LEDs =====

==== Common LEDs ====
All Wirnet gateways have:
  * a green power LED
  * a status LED (red or orange, might be one bi-color led together with power LED or a separate LED)

Green power LED is on from power on to power off.

Status LED behavior:
^ Gateway state^ Status LED behavior ^ 
^ Boot part 1| Fix On| 
^ Boot part 2| Heartbeat|
^ Boot part 3| Blink every second| 
^ Run time   | Off|
^ Power down sequence | Heartbeat|
^ Update| Blink fast (400 ms) |
^ Restore backup| Blink / 2 seconds|
^ Restore Stock| Blink / 4 seconds|

On Wirnet iBTS:
  * power LED is the green LED of the debug port
  * status LED is the orange LED of the debug port. On firmware 4.0.X, status LED blinks once each 5 second during run time.

On Wirnet iFemtoCell, the 3 LEDs are bicolor LEDs.
  * power LED is the green LED of the left bicolor LED
  * status LED is the red LED of the left bicolor LED

On Wirnet iStation:
  * power LED is the green LED under the power button
  * status LED is the red LED under the power button

==== Other LEDs ====
++++
Wirnet iBTS |

The three RJ45 connectors (PoE, LOCAL and debug) integrate 2 LEDs, one Green and one Orange.\\
The behavior of the LEDs is detailed hereafter:

^ Connector ^ LED  ^ Description ^
^ LOCAL| **<fc #008000>Green</fc>** | Ethernet data activity| 
^ LOCAL| **<fc #ffa500>Orange</fc>** | Ethernet data link| 
^ PoE/LAN| **<fc #008000>Green</fc>** | Ethernet data activity| 
^ PoE/LAN| **<fc #ffa500>Orange</fc>** | Ethernet data link| 
^ DEBUG| **<fc #008000>Green</fc>** | Power LED| 
^ DEBUG| **<fc #ffa500>Orange</fc>** | Status LED| 
++++

++++
Wirnet iFemtoCell |

There are 3 LEDs on the Wirnet iFemtoCell:
  * LED 1 : Power/Status (left)
  * LED 2 : Backhaul (center) 
  * LED 3 : LoRa Traffic (right)

^ Status ^  Backhaul LED  ^
| **Boot**   | <fc #ff0000>Red</fc> |
| **WMC - Not connected (2)**   | <fc #ff0000>Red</fc> |
| **WMC - During connection (2)**   | <fc #008000>Green blinking </fc> |
| **WMC - Connected (2)**   | <fc #008000>Green </fc> |

^ Status ^  LoRa traffic  ^
| **Boot**   | <fc #ff0000>Red</fc> |
| **Packet forwarder - Rx (1)** | <fc #008000>Green blinking </fc> |
| **Packet forwarder - Tx (1)** | <fc #ff0000>Red blinking </fc> |

(1): This LEDs behavior is only available in the packet forwarder provided on this wiki.
(2): This LEDs behavior is only available when Wanesy Management Center is used.

++++
Wirnet™ i-series

User Tools

Site Tools

Page Tools
