Functional Goal
Identify when cars are parking and inform drivers nearby that a space is coming available. Added feature of billing for spaces.

Required for Implementation

1. Verification of proof of concept
2. A group of encased sensors per parking location that can withstand the punishment of being outdoor in rain, sun, heat, and impact
3. A low cost long lasting life of the sensor
4. Communication to some hub that transports the events of parking, preparing to leave, leaving, replace sensor to mobile devices and a management suite
5. A pay mechanism for parking associated to the phone

Proof of Concept

For your parking application you would like to know when a space is occupied and when a space is not occupied. It would be great if you could tell if a space was about to be unoccupied so you could notify people nearby. You might theorize that the shadow cast beneath a vehicle in conjunction with the effect on the magnetic field by so much metal might be enough information to determine vehicle presence.
Additionally, you postulate that the sound of the car door closing is distinctive enough to be identifiable and is a positive indicator if followed by the engine turning on that the car is about to leave. Before proceeding to identify hardware design and packaging, we must validate that our postulates are true. How?

How to Confirm IoT Postulates
Confirming postulates takes multiple steps. They are:
1. Mock up the numbers, the analysis, and the labels
2. Create data collection devices
3. Collect data and label events (simple setting to complex setting)
4. Analyze data
5. Determine algorithm for thresholds with confidence interval
6. Disperse devices
7. Test algorithm
8. Refine algorithm

Postulate confirmation and formula calibration are ongoing processes. They require design and a detailed understanding of data and an effective labeling of events within the data at the correct times. The greater the data volume, the better the accuracy of the data, and most importantly the more numerous and more accurate the labels the better the results.

Data Labeling

Effective sensor systems provide a way of labeling windows of operation within the data and data events. Most industrial applications use sensor specifications, calibration on the device, and calibrating external devices to make sense of the sensor data. These days there is heavy reliance on AI for this. There are always issues with sensors in terms of lost communication, anomalous data, out of sync calibration devices, and sensor degradation. These issues require preventative maintenance test and configuration cycles.
Human labeling of events is one of the more accurate methods for noticing an event and recording it. Making labeling of events in IoT at the time of measurement and after deployment is a key functionality that is lacking in many IoT applications today.


Proof of Concept Experiment
Equipment Required
1.Two Android mobile devices (data collection and recording devices)
2. Mobile 1
3. Mobile 2 (has the protective case)
4. Protective case for one of the phones
5. A car
6. Physics Toolbox Sensor Suite (records phone sensor data)
7. Event Logger to log events as they occur
8. Chalk easily read on road service


1. Download Event Logger on Mobile 1
2. Open the Event Logger on Mobile 1
3. Program the buttons so there are
4. parking
5. parked
6. engine on
7. engine off
8. door open
9. door closed
10. leaving
11. available
12. replace sensor
13. Download Physics Toolbox Sensor Suite on Mobile 2
14. Find a level place to test your parking application and park your car in the spot
15. Draw a line on the road surface with the chalk parallel to the front of the car
16. Draw a cross where the center of the car is
17. Take two steps away from the bumper and mark another line
18. On the outside, away from the curb, of the car mark the middle of the vehicle between the front and the back of the car
19. Pull the car out of the space and draw a square where you will place your mobile device lined up with the cross and the line you drew for the middle of the length of the car
**Caveat: The physics toolbox used to save more than one sensor parameter at the same time. We must run separate tests and align the numbers.

Light Test

Make three tests for light readings based on high light, clouds, and street light conditions. The idea is to take light readings under varying conditions and record the percentage change based on the decrease when a vehicle passes over the space. Repeat the following steps for as many readings for light as you desire.

  • Open the Event Logger on Mobile 1
  • Open Physics Toolbox
  • Select Light Meter from the sensor menu on top left
  • Start recording by selecting the + sign
  • Place Mobile 2 in the square you drew on the road surface
  • Get in the car
  • Start the engine
  • On Mobile 1 push the parking button
  • Slowly park making sure not to drive over your phone
  • Pull forward until the 2nd line you drew is directly in front of the vehicle
  • On Mobile 1 push the parked button
  • Turn the engine off
  • On Mobile 1 push the engine off button
  • Open your door
  • On Mobile 1 push the open door button
  • Get out
  • Close the door
  • On Mobile 1 push the door close button
  • Open the door
  • On Mobile 1 push the door open button
  • Get into the car
  • Close the door
  • On Mobile 1 push the door close button
  • Start the car
  • On Mobile 1 push the engine on button
  • On Mobile 1 push the leaving button
  • Pull out of the parking space (be careful)
  • After completely out of the space push the available button
  • On Mobile 1 select the stop symbol
  • Save the file as Light Test 1 and send it to your email or drive

Magnetometer Test (Metal)

  • Open the Event Logger on Mobile 1
  • Open Physics Toolbox
  • Select Magnetometer from the sensor menu on top left
  • Start recording by selecting the + sign
  • Do the instructions above from 5 to 29
  • Save the file as Magnetometer Test 1 and send it to your email or drive

Audio Test

  • Open the Event Logger on Mobile 1
  • Open Physics Toolbox
  • Select Sound Meter from the sensor menu on top left
  • Start recording by selecting the + sign
  • Do the instructions above from 5 to 29
  • Save the file as Sound Test 1 and send it to your email or drive

Repeat Tests under Varying Conditions

Repeat the above tests under varying conditions at least 3 times. Increment the file name each time to correspond to the test series and not the conditions at the time of testing.

Getting the Data into an Analysis Spreadsheet
This is the fun part of IoT, analysis of data. To help you out I have included a reference to a google spreadsheet with sample data and analysis. You will have to do some manipulation of your data to get it into the spreadsheet in an acceptable manner. Steps to use the spreadsheet and understand analysis.

  • Copy the google spreadsheet to your drive or download it as an excel file
  • Import your sample data into a spreadsheet by opening it either in google spreadsheets or excel
  • Select the appropriate column ranges and drop them into the analysis sheet where they belong. Make sure you get the correct number of rows to make it easier on yourself or make the adjustments to handle the situation
  • Each spreadsheet of each type should be a trial run

Understanding the Analysis
Sensor data generally exhibits amplitude and frequency. The sensors being used for the parking application are very straight forward. Our goal is to smooth the data, and match our labels against peaks and troughs and determine amplitude. We do that by using very simple equations for rate of change, percent change, and amplitude. In the end we end up with a series of charts like this.


Our analysis is validated and we can determine parking and leaving. Now we have to collect this data from a sensor, do the analysis, and transport it to a device.

Collection Sensor

There are many companies that sell coin based Smart BLE sensors that have sound, light, magnetometers. One such company is mBientLabs. You could order few sensors from them and encase them in a resin making sure the microphone has access to sound without water damaging the sensor.

The Gateway

A gateway is a multi-sensor collection hub that has both Smart BLE, Internet, and Cellular communication capabilities. Most smart phones have these as do many other devices. For your initial MVP you should use a smart phone to collect the data in real time. mBientLabs has a lot of material on how to program your phone to collect data from their sensors. For your testing you will want to put the equations in the spreadsheet into your program on your mobile device and just send the events with the coordinates for the sensor. Provisioning sensors, assigning coordinates, and maintaining them is a whole other conversation. For that you might want to check out Google or Samsung for their libraries for IoT. Firebase is a great database for a parking application and your sensor network.


For real time communication you should consider Twillio which when integrated in your gateway can send millions of messages per second around the world. You want the programmable messaging.

Completing the Application

To complete the application you need a client that listens to the messages which are the events you produce from your gateways about the sensors located in the parking spots. In this case the client must be:
1. looking to park
2. be near the leaving or available space
3. know who else is looking and if they are closer and committed to the space

Self Promotion

Zanthion is a pioneer in changing our social environment with future vision and use case (solution based) systems that improve the world based on open source, transparent, crowdsourced economic mechanisms that accurately assess what happened, inform the correct resources that the event has occurred, provide resources to the problem efficiently, and keep track of the efficiency of fixing the non-conformity. We embrace a responsible future.