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™ i-series 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:

cat /dev/nmea2
# ctrl-c to exit 

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,1,12,4.31,184.9,M,47.1,M,,*41

In this example, the fix quality is OK (1) and 12 satellites are received.

Examples of bad GGA sentence:

• Frames like the one below, indicates that not enough satellites are received.

$GNGGA,152451.00,,,,,0,00,99.99,,,,,,*7E

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

$GNGGA,163411.00,,,,,0,04,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.

# 2D/3D Altitude management
fixed_altitude=yes

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

• Some NMEA frames contain UTC time.
• GPS possesses two signal features:
  1. 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.
  2. TAI offset information: It sends current TAI offset and time of next leap second insertion in UTC time (if any insertion is planned).

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:

# 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

All Wirnet™ Gateways have a temperature sensor in their CPU. To read the sensor output:

cat /sys/class/thermal/thermal_zone0/temp

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

Wirnet™ iBTS has another temperature sensor in CPU module. To read this sensor temperature:

cat /sys/class/hwmon/hwmon1/temp1_input

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

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:

# 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

To read humidity level inside Wirnet iStation:

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

Humidity level is:

• in_humidityrelative_raw * in_humidityrelative_scale in %

To temperature:

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

Temperature in degrees Celsius is:

• ((in_temp_raw + in_temp_offset) * in_temp_scale) / 1000

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:

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 or iFemtocell-Evolution, 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 (left) under the power button
• status LED is the red LED (right) under the power button

On Wirnet iZeptoCell:

• power and status led are one bi-color LED
• this LED is represent with the power symbol

Wirnet iBTS

Wirnet iFemtoCell or iFemtocell-Evolution

Wirnet iZeptoCell

It is possible to manage LEDs in some scripts, to make it blinking for example.
Here some scripts examples with LED path and management:

• In usb.autorun specific file.
• In Initialization scripts wiki page.