Smart Parking node

Hardware description

The Smart Parking node is based on 2 different pieces: the base and the external enclosure. The base of the Smart Parking node includes the PCB, the battery, the antenna and the internal enclosure piece.
Figure: Base of a Smart Parking node
The base is screwed to the external enclosure piece:
Figure: External enclosure
The next table shows the basic Smart Parking node characteristics.
Enclosure dimensions
200 x 200 x 37.25 mm
Enclosure materials
Polyamide, polypropylene and glass fiber
Weight
0.813 kg (including installation accessories) 0.540 kg (just the Smart Parking node)
Power supply
Built-in lithium-thionyl chloride (Li-SOCl2) batteries; expected lifetime of 4-10 years*
Configurable sleep time
Min: 10 s / max: 10 min
Radio protocol
LoRaWAN module
Dual detection
Radar (main) and magnetic (backup)
Provisioning
Ready to install (factory LoRaWAN OTAA IDs and key are pre-configured to each node)
Node configuration
Via Libelium Cloud
LoRaWAN configuration
Via "Smart Devices App" (Java desktop application)
Operating temperature**
-20 to +65 °C
Market certifications
CE (Europe)
FCC (USA) UKCA
Ingress protection certification
IP68 (maximum rating against dust and water ingress)
Impact protection certification
IK10 (maximum rating against impacts)
(*) Under normal circumstances and depending on settings
(**) Continuous operation in extreme temperatures (high or low) is not recommended for long periods of time for example, this may lead to reduced battery capacity, lower radar performance or random resets
Figure: Vaulted enclosure dimensions
The radar sensor performs a re-calibration process periodically to deliver the most accurate measurement. It is an automatic feature, so no user action is required. Besides, this re-calibration is internal, meaning it is always completed correctly, regardless of whether there is a vehicle above the node or not.

Node versions

Libelium provides the next versions of Smart Parking:
Reference
Version
Operating frequency
SP-EU
Smart Parking EU
863.0 to 870.0 MHz (LoRaWAN EU863-870)
SP-US
Smart Parking US
902.0 to 928.0 MHz (LoRaWAN US902-928)
SP-APLA-AU
Smart Parking APAC/LATAM/AU/AU915
915.2 to 927.8 MHz (LoRaWAN AU915-928)
SP-IN
Smart Parking IN
865.0 to 867.0 MHz (LoRaWAN IN865-867)
SP-APLA-AS
Smart Parking APAC/LATAM/AU/AS923
923 MHz (LoRaWAN AS923)

LoRaWAN regions

The Smart Parking node supports the next LoRaWAN regions:
LoRaWAN region
Supported by
EU 863-870 MHz ISM Band (Europe)
Smart Parking EU
US 902-928 MHz ISM Band (United States)
Smart Parking US
AU 915-928 MHz ISM Band (Australia)
Smart Parking APAC / LATAM / AU / AU915
IN 865-867 MHz ISM Band (India)
Smart Parking IN
AS 923 MHz ISM Band (Asia and ASEAN region)
Smart Parking APAC / LATAM / AU / AS923
CN 779-787 MHz ISM Band (China)
Not available
CN 470-510 MHz ISM Band (China)
Not available
KR 920-923 MHz ISM Band (South Korea)
Not available
433 MHz ISM Band (Worldwide)
Not available
If you are interested in further information about LoRaWAN country regulations, please refer to the LoRa Alliance regional parameters document.

LoRaWAN protocol and parameters

LoRaWAN is a Low Power Wide Area Network (LPWAN) protocol. It is a spread-spectrum modulation technique at extremely low data-rates which permits sending data achieving long ranges.
The most important LoRaWAN parameters are:
  • LoRaWAN EUI: Read-only, 8-byte, unique identifier which defines each LoRaWAN module in the market.
  • Device EUI: Read/write, 8-byte identifier configured into the LoRaWAN module to be used as operating identifier. By default, the "LoRaWAN EUI" of the module is factory-configured as "Device EUI" in the Smart Parking node.
  • Join mode: ABP or OTAA. Defines how the module joins the network. Different keys are needed for each method.
  • Device address: Needed for ABP. The 4-byte address of the the LoRaWAN module. Must be unique in its own sub-network.
  • Network Session Key: Needed for ABP. The 16-byte AES key. Used to generate Message Integrity Check.
  • Application Session Key: Needed for ABP. The 16-byte AES key. Used to encrypt data.
  • Application EUI: Needed for OTAA. The 8-byte application identifier. Needed for opening an OTAA session and exchange encryption keys.
  • Application Key: Needed for OTAA. The 16-byte key. Needed for opening an OTAA session and exchange encryption keys.
  • Data-rate: Defines the transmission rate (bits per second). Each data-rate settings combines different Spreading Factor (SF) and bandwidth (BW). By default, all LoRaWAN regions use the same data-rate (DR 0). However, depending on the region, that means different SF and BW:
    • LoRaWAN EU863-870 version: SF12 / 125 kHz
    • LoRaWAN IN865-867 version: SF12 / 125 kHz
    • LoRaWAN AS923 version: SF12 / 125 kHz
    • LoRaWAN US902-928 version: SF10 / 125 kHz
    • LoRaWAN AU915-928 version: SF10 / 125 kHz
  • ADR: Adaptive Data Rate setting which can be enabled or disabled. If ADR is enabled, the server will optimize the data-rate based on the information collected from the network: the RSSI / SNR of the last received packets.
If you are interested in further information about LoRaWAN specifications, please refer to the LoRa Alliance specifications document.

Identification label

There is a sticker on the bottom side of the Smart Parking node base. In this sticker, several device specifications can be seen. For example the "Model" which refers to the device's region. Also, the unique "LoRaWAN EUI" is displayed so each node can be distinguished.
Figure: Smart Parking node label

Power and time consumption

The Smart Parking node firmware executes different steps since the node is started. Firstly, the node's setup and then an infinite loop where every cycle is based on measuring, sending if needed and sleeping. The next tables show the power and time consumption of each step modelled as a pulse of a specific time duration and average power consumption.

Smart Parking EU

Power consumption
Time consumption
Node setup
22.9 mA
59 s
Measure cycle
26 mA
340 ms
Measure and send cycle
17 mA
6 s
Sleep cycle
5.5 uA
Depends on sleep time settings
(*) LoRaWAN EU is set to the default SF12 settings (worst case). The send process may be lower power if the node is close to the base station.

Smart Parking US

Power consumption
Time consumption
Node setup
21.8 mA
53 s
Measure cycle
26 mA
340 ms
Measure and send cycle
20 mA
3.6 s
Sleep cycle
5.5 uA
Depends on sleep time settings
(*) LoRaWAN US is set to the default SF10 settings (worst case). The send process may be lower power if the node is close to the base station.

User switches

The Smart Parking node has 2 switches to manage the working mode:
  • On/Off switch: Determines whether the node is powered-on or powered-off
  • App/Boot switch: When the node is powered-on, this switch determines the performance state of the device
    • App position must be used for a normal operation mode, so the device executes the firmware within it
    • Boot position must be used for configuring purposes only
Figure: Smart Parking node "users witches"
When the node is powered-on (On switch), you can change from App to Boot or viceversa by changing the state of the App/Boot switch. However, you must press the reset button to apply the operation mode change. Another possibility to successfully change the operation mode step-by-step would be to: power down the device (Off switch), change the App/Boot switch, press the reset button and then power on the device.
Never leave the device set to On and Boot for more time than needed. The bootloader does not provide any sleep mode and it will waste the battery of the device. So when you finish reconfiguring the device, please set the node in off state.

Reset button

The reset button can be used to re-start the node in the corresponding operation mode (App or Boot). If the node is set up to "App" (normal operation mode), pressing the reset button will re-start the program execution. On the other hand, if the node is set up to Boot (configuration mode), pressing the reset button will re-start the MCU bootloader for reconfiguration or firmware update.
Figure: Reset button

Node setup

"Ready to install" state

Libelium provides the nodes "ready to install" so the user only needs to install the nodes and follow the "Magnet start-up" process.
The Smart Parking node has a power-on process in order to put the device into a "ready-to-install" state:
  • Step 1: The switches are set to "App" and "Off" (press the reset button to make sure you discharge capacitors)
  • Step 2: You power the device on by sliding the switch from "Off" to "On"
  • Step 3: Both LEDs (red and green) blink rapidly for 5 times
  • Step 4: Red LED blinks once for 1 second to indicate that the device enters sleep mode for the 1st time. Now the node is in a "ready to install" state. The customer should install the node on the real scenario and perform the "Magnet start-up" process.
You can see how the previous steps are performed in this video: Ready to install process

How to close the Smart Parking node

After following the previous steps, the device can be closed. In order to close the node correctly and ensure correct sealing, the following steps must be strictly followed.
  • Step 1: Make sure that the screws have the o-rings to prevent water ingress.
Figure: Screw swith o-ring
  • Step 2: Ensure that the top surface of the gasket is clean and contains no foreign objects.
  • Step 3: Place the inner casing inside the outer casing and make sure that the 2 position marks match.
Figure: Enclosure position marks
  • Step 4: Insert the screws and tighten them halfway.
Figure: Screws in their position
  • Step 5: Finally, tighten the 4 screws firmly. Do not use the maximum pressure (do not go all the way with the screws), because the o-rings could be ejected from the screws, and then the waterproof feature would NOT be valid. Besides, do not screw too hard and keep on screwing, because the screws could carve the female sockets, expanding their inner diameter; this would cancel the waterproof quality too.
Libelium manufactures and provides all nodes configured after following all explained steps, so the node is "ready to install". By factory default, all nodes are configured with their unique LoRaWAN EUI and random private keys. On the other hand, if different LoRaWAN parameters are desired, “SmartDevicesApp” must be used to change the settings and repeat the previously explained steps.

"Magnet start-up" process

Once the node has been set to "ready to install" state and it has been closed and placed on the parking slot, the "magnet start-up" must be done. This process consists on resetting the device using the magnet for 3 consecutive times. Each magnet reset must be separated by at least one second period.
The best way to proceed with the magnet is to go over the enclosure from left to right in a one-motion movement. Then wait for at least one second (although you can wait more) and proceed again until you complete 3 magnet resets.
Figure: Magnet reset
In the next video-clip you can see how the "magnet start-up" is performed: Magnet start-up
After finishing the "magnet start-up", the node starts working normally for the rest of the time. No more three-time "magnet resets" are needed in order to reset the device properly. So if a 4th magnet reset or software reset is applied, the device will reset and continue working normally again.
The "magnet start-up" is only mandatory when the node is powered from a power-off state. In other words, when the device is set to a "ready to install" state.

How the node works

Frame types

The Smart Parking architecture manages different uplink and downlink frames. The next table shows the uplink frames:
Frame type
#num
Description
Start frame 1
4
First frame sent by the node when starting (with params settings)
Start frame 2
5
Second frame sent by the node when starting (with params settings)
Info frame
0
Used to inform a Parking Status change
Keep-alive frame
1
Used to inform the device keeps working since last reported status
Configuration uplink
2
Used to confirm a "Configuration downlink" was applied or not
RTC update request
7
Used to request for an RTC sync once every day
The next table shows the downlink frames:
Frame type
#num
Description
Configuration downlink
3
Used to update the node parameters. After the customer sets up a new node configuration in the Remote Configuration Form a new "Configuration downlink" frame is enqueued into the LoRaWAN network server's downlink queue.
RTC sync frame
6
Used to sync the node's RTC to the server's timestamp. It is the mandatory response to "Start frame 1" and "RTC update request" uplink frames.
The uplink frames are 11-byte long to always comply with the LoRaWAN datarate worst case scenario. Their structure consists on 2 parts: header and payload. The "header" format is always the same for all uplink frame types. On the other hand, the "payload" format may be different for each frame type.
Regarding the downlink frames, they have variable length and its format is private to the customer. The "RTC sync frame" is the mandatory response for both "Start Frame 1" and "RTC update request" frames. The "RTC sync frame" provides the server time to the nodes in order to keep the RTC updated. Also, the "Configuration downlink" is an asynchronous frame sent by the server when the Remote Configuration Form is managed by the customer.
You must keep in mind that when a downlink packet is requested there are usually some issues related to LoRaWAN network latency. This implies that the 1st request attempt usually fails. In that case, a 2nd attempt is sent in order to retrieve the lost downlink packet. For this reason, you might see that a couple of "Start Frame 1" or "RTC update request" frames are sent sequentially during the execution of the program.
Libelium Cloud has the needed code to parse data inside frames into a more comprehensive structure. The cloud connectors also provide the needed tools to transmit the parsed data to a 3rd party IoT cloud.

Node program execution

Figure: Smart Parking node program flow chart

Node parameters

Parameters description and ranges

The Smart Parking node has different parameters that change the timing and detection performance of the node. The next table shows the node parameters:
Parameter
Range
Description
Sleep time
1-10 min or 10-59 s
Minutes or seconds elapsed between each measurement cycle
Keep-alive time
0.5, 1, 2,..., 23 hour
Hours elapsed since last uplink message which triggers a new Keep-alive frame
Night-mode
0 or 1
Night-mode disabled/enabled
Night-mode start
0, 1,..., 23 hour
Night-mode starts when RTC reaches this parameter field
Night-mode duration
1, 2,..., 15 hour
Night-mode period is equal to this field
Night-mode sleep
1, 2,..., 10 min
Sleep time applied during night-mode
Radar range start
20 to 50 cm
Starting measurement distance (objects below this value are not detected)
Radar range length
50 to 100 cm
Range of measurement to be added to "range start" value
Radar threshold
5 to 100
Threshold used in detection algorithm, so higher threshold imply less sensitive detection
LoRaWAN join mode
0 (ABP) or 1 (OTAA)
Join mode used by the LoRaWAN radio module
LoRaWAN DevEUI
8-byte identifier
Defines the device EUI used by the LoRaWAN radio
LoRaWAN DevAddr
4-byte identifier
Defines the device address used by the LoRaWAN radio in ABP mode
LoRaWAN NwkSKey
16-byte key
Defines the LoRaWAN Network Session Key used by the LoRaWAN radio in ABP mode
LoRaWAN AppSKey
16-byte key
Defines the LoRaWAN Application Session Key used by the LoRaWAN radio in ABP mode
LoRaWAN AppKey
16-byte key
Defines the LoRaWAN Application Key used by the LoRaWAN radio in OTAA mode
LoRaWAN AppEUI
8-byte identifier
Defines the LoRaWAN Application EUI used by the LoRaWAN radio in OTAA mode
LoRaWAN port
1 to 223
Defines the port used for uplink sendings
LoRaWAN ADR
0 (off) or 1 (on)
Defines if Adaptive Data Rate is enabled or disabled
LoRaWAN RX1 Delay
0 to 65536
Defines the delay after first LoRaWAN rx window
LoRaWAN Subband
8-bit bitmap
Defines the sub-band used by the LoRaWAN radio (only applies to US and AU versions)
The LoRaWAN identifiers and keys must be registered in the LoRaWAN network server before starting the node in order to receive data. For OTAA mode: DevEUI, AppEUI and Appkey. For ABP mode: DevEUI, DevAddr, NwkSKey and AppSKey.

Understanding Info and Keep-alive frames

In the regular working mode (day-mode), "Sleep" and "Keep-alive" parameters are used. So the node normally sleeps for a specific "Sleep" time then wakes-up, measures and applies the algorithm detection in order to detect changes in the parking slot.
If a change is detected from 'free' to 'occupied' or viceversa, then an "Info" frame is sent. If no change occurred during the last "Keep-alive" time, then a Keep-alive frame is sent. Besides, if a sensor error is detected, a Keep-alive frame sending is forced in order to inform about this issue.
Example parameters used:
  • Sleep: 7 minutes
  • Keep-alive: 1 hour
Figure: Example Info and Keep-alive frames

Understanding night-mode

As shown in the parameters table, there are some parameters that allow the user to configure the node to use 2 working modes depending on time settings: day-mode and night-mode.
The night-mode is a secondary and optional working mode that allows the user to configure a different time basis parameters in order to reduce the battery impact. So, it was developed to use it when the parking slot is expected to have fewer changes (i.e. at night). Therefore, a different night-mode "Sleep" setting is used.
It is not mandatory to use the night-mode during night. This mode is thought to be used when less vehicle movement is expected in the parking slots. Which could be during day time.
Example:
  • Day-mode:
    • Sleep: 1 minute
  • Night-mode:
    • Night-mode start hour: 21 hours (9 PM)
    • Night-mode duration: 10 hours (Night-mode goes from 9 PM to 7 AM)
    • Night-mode sleep time: 10 minutes
In the example, from 9 PM to 7 AM, the node will waste less battery because measurements are done every 10 minutes instead every minute. Keep-alive events are not shown but a Keep-alive event would be triggered if no change occurs in the parking slot.
Figure: Example of day and night mode
The conclusion is that the Night-mode is interesting for customers who certainly know the parking slot is expected to have fewer changes during large periods of time every day.
From October 2019 the "keep-alive night-mode" setting was deprecated to simplify the parameter management. Since then, there is a single keep-alive setting, for both "normal mode" and "night mode".

Understanding RTC synchronization

There are specific frame types that allow the node to synchronize the RTC to the server timestamp.
The "Start Frame 1" expects an answer from the server with the timestamp (hours and minutes). This frame is sent after starting the node or a software reset.
Besides, the node's firmware provides a mechanism which an "RTC update request" frame is sent every 24 hours since the node was started or reset. This frame waits for a downlink frame which brings the current server timestamp (hour and minutes).
Figure: Example of RTC sync
The RTC sync is important for Night-mode only where it mandatory to operate with a correct timestamp in order to enter and exit from night-mode to day-mode and viceversa.
The next table shows all frames sent by a single node since it was started. The different columns display the parsed data from the received "uplink data".
Example:
  • Day-mode:
    • Sleep: 1 minute
    • Keep-alive: 2 hour
  • Night-mode:
    • Night-mode start hour: 22 hours (10 PM)
    • Night-mode duration: 8 hours (Night-mode goes from 10 PM to 6 AM)
    • Night-mode sleep time: 5 minutes
It is possible to distinguish the starting frames at the beginning of the execution. Then the node informs with a new Keep-alive every 2 hours. Any change of Parking slot status implies a new Info frame. And after 24 hours working, you can see the RTC request performed by the node.
Timestamp
F. Type
Parking lot
Battery
Recal
Seq
04/15/19 15:59
4 (Start 1)
Not available
0
0
0
04/15/19 15:59
5 (Start 2)
Not available
0
0
1
04/15/19 15:59
1 (Keep-alive)
Free
0
1
2
04/15/19 17:29
1 (Keep-alive)
Free
0
0
3
04/15/19 19:29
1 (Keep-alive)
Free
0
1
4
04/15/19 21:29
1 (Keep-alive)
Free
0
0
5
04/16/19 23:29
1 (Keep-alive)
Free
0
0
6
04/16/19 01:29
1 (Keep-alive)
Free
0
0
7
04/16/19 03:29
1 (Keep-alive)
Free
0
0
8
04/16/19 05:29
1 (Keep-alive)
Free
0
0
9
04/16/19 06:04
0 (Info)
Occupied
0
0
10
04/16/19 08:04
1 (Keep-alive)
Occupied
0
0
11
04/16/19 10:04
1 (Keep-alive)
Occupied
0
0
12
04/16/19 12:04
1 (Keep-alive)
Occupied
0
0
13
04/16/19 14:05
1 (Keep-alive)
Occupied
0
0
14
04/16/19 15:58
7 (RTC request)
Occupied
0
0
15
04/16/19 15:59
7 (RTC request)
Occupied
0
0
16
04/16/19 17:59
1 (Keep-alive)
Occupied
0
0
17
04/16/19 18:32
0 (Info)
0
0
0
18
04/16/19 20:02
1 (Keep-alive)
0
0
0
19
04/16/19 22:32
1 (Keep-alive)
0
0
0
20
04/17/19 00:02
1 (Keep-alive)
0
0
0
21

Factory default values

Libelium provides all Smart Parking nodes with factory default parameters.
Parameter
Default value
Sleep time
1 min
Keep-alive time
2 hour
Night-mode
0 (disabled)
Night-mode start
0 hour
Night-mode duration
6 hour
Night-mode sleep
5 min
Radar range start
20 cm (should not be changed)
Radar range length
60 cm (should not be changed)
Radar threshold
25 (should not be changed)
LoRaWAN join mode
1 (OTAA)
LoRaWAN DevEUI
unique factory default value
LoRaWAN DevAddr,
unique factory default value
LoRaWAN NwkSKey
unique factory default value
LoRaWAN AppSKey
unique factory default value
LoRaWAN AppKey
unique factory default value
LoRaWAN AppEUI
unique factory default value
LoRaWAN port
3
LoRaWAN ADR
0 (off)
LoRaWAN RX1 Delay
1000 (should not be changed)
LoRaWAN Subband
8-bit bitmap

Configure new parameter values

Both Smart Devices App and Libelium Cloud allow the user to update program parameters to the node:
  • Smart Devices App: it is a desktop Java application which implies opening the node enclosure and plug a micro-USB cable to the node (the new configuration is flashed to the node's memory via the USB cable).
  • Libelium Cloud: permits to remotely change some of the node parameters.
Regarding the time and sensor parameters, the same values are set to all nodes manufactured by Libelium. The default values can be seen in the previous section. However, the customer can configure the time and sensor settings using both Smart Devices App and Remote Configuration Form.
Regarding the LoRaWAN parameters, all keys are randomly generated for each node and kept secret. The DevEUI set to the node is the LoRaWAN hardcoded EUI which is unique for each radio chipset. However, the client can configure/modify all LoRaWAN parameters using the Smart Devices App only (the Remote Configuration Form does not permit it).
For further information about this matter please refer to the "Smart Devices App" section.
Copy link
On this page
Hardware description
Node versions
LoRaWAN regions
LoRaWAN protocol and parameters
Identification label
Power and time consumption
Smart Parking EU
Smart Parking US
User switches
Reset button
Node setup
"Ready to install" state
How to close the Smart Parking node
"Magnet start-up" process
How the node works
Frame types
Node program execution
Node parameters
Parameters description and ranges
Understanding Info and Keep-alive frames
Understanding night-mode
Understanding RTC synchronization
Understanding uplink frames format (real example)
Factory default values
Configure new parameter values