Smart Parking node
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.
(*) 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
Libelium provides the next versions of Smart Parking:
The Smart Parking node supports the next LoRaWAN regions:
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.
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
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.
(*) 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.
(*) 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.
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.
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
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.
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.
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
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 Smart Parking architecture manages different uplink and downlink frames. The next table shows the uplink frames:
The next table shows the downlink 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.
Figure: Smart Parking node program flow chart
The Smart Parking node has different parameters that change the timing and detection performance of the node. The next table shows the node parameters:
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
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.
- Sleep: 1 minute
- 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.
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 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".
- Sleep: 1 minute
- Keep-alive: 2 hour
- 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.
Libelium provides all Smart Parking nodes with factory default parameters.
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).