Park-It-CdA: Garage Sensor System over a Mesh Network

The goal of the project is to provide an intuitive means of visual indication for commuters who are looking for available parking within a specific garage in downtown Coeur d'Alene, Idaho.

Problem Definition
Too much time and effort are spent by those looking for a place to park in one or more garages in downtown Coeur d’ Alene. Commuters would benefit greatly from a system that indicates whether there are spaces available for parking within a parking garage. The Garage Sensor System (GSS) will allow people to find open parking spaces, and hopefully provide this information before they enter the garage. The means of indication will be via LEDs; a green light means there is an open stall, where a red means the stall is currently occupied by another vehicle. This is not the complete functionality of the system, but rather a level of abstraction for the consumer; the data that is measured/collected, will be distributed from device to device via a mesh network, then sent through a gateway where it will be received at The Den as a means of data collection for possible further research. A companion app may or may not be added if necessary.

Deliverables

 * 5 GSU’s which includes the enclosure, computer hardware – sensors, LEDs, embedded system.
 * 1 Gateway to be installed on the roof of the Innovation Den.
 * Software to run the GSS – Arduino sketches, simulation.
 * User manual on how to operate the GSUs and simulation.
 * This portfolio including all documentation of the requirements, design process, project learning, communications, design solution and references.

Specifications

 * 5 prototypes will need to be made; 3 for inside the garage, 1 for the entrance and 1 for the exit. The rest of the project will be simulated.
 * Units will be roughly no larger than 4” X 4” X 4” but may be smaller if possible.
 * Each unit needs to be able to last for at least 1 year via battery power.
 * The medium used for vehicle detection can be any type of sensor, or other device capable of detection, so long as it meets the rest of the project requirements.
 * The medium used for communication between devices/server, can be any type, so long as it is wireless, and meets the rest of the project requirements.
 * The units need to be affixed to the garage via some means of adhesion that is non-permanent.
 * Each unit should have a way of being reset, for maintenance, error occurrence, etc.
 * Units will need to have the ability of a deep sleep mode, waking via hardware interrupt, or set intervals.

Functional Requirements
There are 3 categories of users of the GSS.
 * Drivers – people who use the garage and park inside it. Drivers interact with the GSS when they park their car in a stall that is monitored by a GSU.
 * Maintenance staff – a person who must monitor the physical condition of each GSU and clean them, change batteries as required.
 * Owner – the person who owns the garage must be able to see the real time statistics of the garage.

What it should do
 * The GSS is comprised of 5 GSUs.
 * The GSS must periodically check and accurately detect whether a car is parked in a stall
 * A Garage Sensor Unit (GSU) is assigned to a parking stall and must indicate externally with LEDs whether a stall is occupied or available
 * The LEDs of the GSU must always be solid, or blink at a rate to not cause seizures. All LEDS must blink at the same time
 * The GSU must use sensor(s) to determine whether a car is parked in a stall
 * One GSU must be placed at the entry of the parking garage
 * One GSU must be placed at the exit of the parking garage
 * The GSUs must be arranged in a mesh network
 * The GSUs must determine amongst themselves which will be the Garage System Master (GSM)
 * The GSM must rotate on a periodic basis to conserve battery life
 * The GSUs must transmit data periodically about the state of their parking stall to the GSM
 * The GSUs must be synchronized to be able to send and receive the data periodically
 * The GSU must operate at a speed fast enough to send and receive the data reliably
 * The GSM must transmit data periodically about the status of all GSUs to the Garage Sensor Gateway (GSG) at the Innovation Den on top of the roof
 * The GSG must relay this information to the server at the Innovation Den downstairs
 * The server must process this data and simulate the rest of the parking garage
 * The Parking Garage Simulator (PGS) must be located on the server
 * The PGS must display statistics of the parking garage such as the number of and location of currently occupied stalls, number and location of available stalls, average time from entry to find a stall.

Mechanical Requirements
The GSS consists of 5 GSUs located in the garage and a GSG at the Innovation Den.

Strength

The GSU must be capable of supporting its own weight.

Spatial

The enclosure of a GSU must fit within the following: Or equivalent volume in cubic inches (64 in3)
 * Length 4 in
 * Width 4 in
 * Height 4 in

Weight/Mass

The mass of the GSU must be light enough that it will not fall from its mounting point – see 5.4.

Mounting / Interface
 * The GSU must be mounted to a concrete ceiling.
 * The method of mounting used must not cause any permanent damage and be removeable leaving no evidence of having been there.
 * The GSU must be removeable from the mounting bracket used.

Appearance
 * The GSU will have a bubble-dome camera cover over it. The dome is not part of the 4”x4”x4” spatial requirement.
 * The GSU must display the UofI colors – gold, silver, black, white
 * The following are the primary colors used by UofI and the values used for printers, images, websites, etc.
 * Pride Gold
 * Pantone 3514 C
 * CMYK 0-27-100-0
 * RGB 241-179-0
 * #F1B300
 * Silver
 * CMYK 0-0-0-50
 * RGB 128-128-128
 * #808080
 * White
 * CMYK 0-0-0-0
 * RGB 255-255-255
 * #FFFFFF
 * Black
 * CMYK 20-20-20-100
 * RGB 25-25-25
 * #191919
 * Metallic Gold
 * PMS Metallic 871

Durability

The GSU must be constructed to handle the environment that it will be located – (see section 8). A GSU must be able to last 5 years.

Reliability

Each GSU must be able to operate for 1 year continuously on one battery charge. Maintenance must be performed at the 1-year mark to clean the surface of the sensors/dome and change batteries.

Electrical Requirements
Operational Voltage


 * The GSU must be capable of running off batteries/battery packs
 * During operation the voltage of the GSU must run at 3.3V to power all hardware

Operational Power Capability

During operation, the GSU must be capable of supplying enough power for all electronic components.

Energy Storage Capacity
 * The batteries of the GSU must have enough capacity to run for a year
 * The hardware and software must minimize power usage
 * The GSU must have the ability to go into a sleep mode to conserve battery life
 * The total mass of the batteries must not be so high as to compromise the mounting system

Software Requirements
Functionality
 * The software for this project will consist of the control software for the GSU and the simulation
 * The GSU software must interface with the sensors to identify when a parking stall is occupied
 * The GSU must be in a sleep state to conserve battery when not transmitting or detecting
 * The GSU must be activated from its sleep state when a (1) sensor detects a car in its parking stall
 * The GSU must use all its sensors to confirm whether the first sensor successfully detected a car or not
 * The GSU must have multiple sensor activation positives to confirm that a car is parked or not
 * The GSS must be able to have the time synchronized to provide consistent LED blinking
 * Each GSU must be able to communicate with every other GSU in a wireless mesh network
 * There must be a priority system in place to determine which of the GSUs will be the GSM
 * The GSUs must transmit its data to the GSM periodically
 * The GSM must periodically transmit all the GSU data wirelessly to the GSG located at the Den
 * All communication between the GSUs and the gateway must provide Integrity and Availability of the CIA triad
 * The GSG at the Den will have the ability to be able to remotely reset all the GSUs.
 * The simulation software must use the data received from the GSG to perform a simulation of the entire garage
 * The simulation must graphically display the current state of each parking stall, the average time from when a car enters the parking garage to when it parks, the number of occupied stalls and number of available stalls

User Interface
 * If time permits, an IOS or Android app will be created to provide a visual user interface for drivers of the car park
 * The app must contain the same information as the PGS
 * The GSU will be able to be provisioned when installing in a parking stall

Environmental Requirements
Temperature

The GSS must have full operational capabilities in a sheltered outdoor environment and run under industrial temperatures (-40 to +85 C).

Environmental Sealing

The unit is not expected to be directly exposed to rain. However, water – brought in from vehicles during wet and snowy weather, dust – from wind, oil from vehicles and smoke from vehicles is expected.
 * The GSU must be waterproof and dust tight
 * The external sensors of the GSU must be able to perform without maintenance for a year with any debris build up that does occur

Regulatory Requirements
FCC Requirements

The GSS must comply with all FCC requirements when transmitting wirelessly.

Cost Requirements
The cost to build and install 5 prototype GSUs, including test units, batteries and housings, must not exceed $1500.

Arduino
Much time was spent trying to find compatible hardware that could support the needs for this project. Considerations for battery consumption, signal transfer, and sensors played a major role in finding the right processing boards to use. We first ordered the hardware we thought would be best through our research and due diligence. After several failed trial runs, a lot of pain and heart ache would probably have been spared if we just started out ordering a wider range of units to test for compatibility.

Date: 09/10/19

Team Member: Zane

Subject: Experimenting IR sensors

Category: Hardware/Software design

Outcome: Over the weekend I built a project for my Aunt. It’s a box that is staked into the ground with an IR sensor on each side of it to cover almost 360 degrees of view. The box is meant to scare deer away from her apple tree and issues a sound of a dog barking when motion is detected from the IR sensor. The IR sensors work great. There is a bit of a calibration time when they are first turned on, but after that, I was able to program them so that they throw an interrupt when they are triggered. There are potentiometers to limit the range and the frequency of the IR detection, and they consume very little power. I will deploy it in my yard and see what kind of battery life I get before introducing any kind of sleep mode to it.

Date: 09/12/19

Team Member: Zane

Subject: Sleep modes for Arduino Nano

Category: Software design

Outcome: Revisiting the dee scaring project: The motion sensors work perfectly. The unit lasted almost 2 days before it finally died. I have used the interrupt from the PIR sensor to wake the Arduino Nano from a deep sleep mode, where it fires off the noise, and goes back to sleep. This seems to work great as well, as I have serial messages being displayed when the unit goes to/wakes up from its sleep. I have affixed to solar panels on the top of the box in the shape of a roof, that will hopefully give it enough of a charge during the day for it to last all night (this is when the deer come for the apple tree). I will update in a week or so.

Date: 09/20/19

Team Member: Zane

Subject: Issues with sleep mode and the Arduino Nano

Category: Hardware debugging

Outcome: The box I had built previously died after about 6 days of use. Since this is longer than before the sleep mode/solar panels, I assumed there was an issue with how much current the Nano was still drawing. Upon further research, the Nano still uses a whopping .15mA of power in 5V, or roughly .25mA in 3V. These numbers came from people who modified the board as well, removing/altering some hardware to achieve the lowest possible power consumption. While this works well for shorter projects, there is no way we can last a year on a lipo battery using this kind of power. We will have to consider other board options.

Date: 10/15/19

Team Member: Nikolai

Subject: Testing Arduino Pro Minis

Category: Hardware testing

Outcome: Tyrel had given me an Arduino Pro Mini the day before and I tried to upload the blink sketch to it to see if it would work. Had no success in doing this and tried troubleshooting for several hours getting nowhere – was the bootloader an issue, hardware issue, an Arduino IDE setting? Couldn’t work it out and gave up.

Date: 10/17/19

Team Member: Zane

Subject: Further testing on Pro Minis

Category: Hardware testing

Outcome: I ordered myself some Arduino Pro Minis, and ran into the same issue that Nikolai had with his. Since I needed this for not only the Capstone testing, but for personal use as well, I decided to do some research. After trying several different connection types with the FTFL and TTL adapters, I came to the conclusion that there couldn’t possibly be a bootloader on these boards. On the manufacturing website from the company that I purchased the Pro Minis from, it states that they come with the bootloader pre-burned, but they weren’t behaving like they should. I found a couple of tutorials about using an Arduino Uno as a bootloader, which I followed. The solution in the end was to remove the ATMega chip from the Arduino, and use the “burn bootloader” in the Arduino IDE, with jumpers from the Uno’s TX/RX pins. This solved the problem.

Date: 1/1/20

Team Member: Nikolai

Subject: Testing MKR WAN 1310

Category: Hardware and Software Testing

Outcome: Over the break I wanted to test out the MKR WAN 1310 Arduinos we got to confirm that it will work with the Radiohead library and the mesh network implementation we want to use as a starting point. Upload of the mesh network sketch would fail to init the RFM95 module. Going back to the send and receive test that Adafruit has resulted in the same thing. Spent about 6 hours troubleshooting and found out that the LoRa chip on the board isn’t compatible with the RadioHead library. LoRa and RadioHead are not the same thing either even though it seemed like they were. The result is that this board is not going to be usable without having to completely learn how to do all the sending and receiving from scratch. Other things learnt from this: the processor on the MKR WAN 1310 is the SAMD21 instead of the ATMega 328P. This has a different instruction set such as for setting timer and sleeping. There are more timers – 5 for the SAMD21 and fewer sleep modes – 3. There is no EEPROM on the SAMD21 either which the mesh network implementation needs – each node needs a unique ID. This will require a different method for obtaining an ID, probably the MAC address or radio ID – take the last 2 or 3 digits. There is also a way to emulate EEPROM on flash, but it gets erased each time a sketch is uploaded. https://github.com/cmaglie/FlashStorage

The watchdog timer on the SAMD21 cannot be used too generate an interrupt like that ATMega: it’s purely for system resetting.

Date: 1/1/20

Team Member: Nikolai

Subject: Finding a suitable Arduino unit for the project

Category: Hardware Research

Outcome: Since the MKR WAN1310 is unlikely to be the route I want to go for the base unit, I needed to quickly find some other Arduino/LoRa combo units and just order them myself to find if they will be useful. I want to at least verify that we have something usable before the Spring semester starts in 2 weeks. Since the first LoRa chips were bought from Adafruit, I start there and find the Adafruit Feather M0 which also uses the SAMD21 processor and has a built in LoRa chip. It doesn’t have the built-in encryption module and they claim 300 uA in sleep mode. I buy 2 of them. This is something we should have done last semester: pick out a wide range of units and buy 1-2 of each to test out.

Date: 1/8/20

Team Member: Nikolai

Subject: Testing Adafruit Feather M0 LoRa

Category: Hardware and Software Testing

Outcome: I want to test out the sending and receiving on the board to see if it will work with the RadioHead library. It works, which is a relief. I then do some testing on sleeping and use a timer to put it to sleep before waking up and blinking the LED. The result of this is 2.78mA during sleep mode. We’ll need to work on improving that number. I think this is the unit we should use.

Battery and Power Usage
A reliable source of energy along with the lowest amount of power usage from our hardware devices is a key issue for this project. A spreadsheet was created with the different types of ways that the battery is going to be drained in the GSU (Garage Sensor Unit). Estimates as to the power usage were made based on datasheets and how often each will be used in a day.

The following assumptions were used:
 * 10,000 mAh battery
 * 1% battery drain per month due to self-discharge
 * Transmission over LoRa will be at 50% power – 50mA
 * Receiving over LoRa uses 20mA, there will be a 20 second receive window when a GSU is receiving
 * A transmission from GSUs to the GSM will be every 30 minutes between 6am and 8pm
 * Sensors activate on interrupt and will run for 10 seconds at a time
 * The PIR sensor activates when a car parks/motion is detected
 * The ultrasonic sensor will be used when a car is parked every 30 minutes afterwards
 * A 10% duty cycle for the LED will be used, which corresponds to 10% of a 30mA LED
 * The Arduino will be using current when active
 * There will be a constant current drain when in sleep mode
 * Solar charging is currently unknown and will not be included yet

Parameters:
 * Days per year 365
 * Frequency per hour 2 (LoRa and sensor)
 * Frequency per hour 3600 (LED)
 * Hours active per day 14
 * Days per month 30
 * Available capacity on a 10,000mAh battery is 8,800mAh after accounting for the self-discharge

We need to aim for an idle current draw of 270uA in order to last for a year before solar charging is considered.

Date: 9/26/19

Team Member: Nikolai, Zane

Subject: Battery Selection and Power Usage

Category: Hardware Research

Outcome: I (Nikolai) was working on the product requirements spec and got to the electrical portion of the requirements. Some of the concerns that we have regarding this at this point are:
 * Not much physical space for a lot of batteries
 * Can’t use something too heavy since the GSU needs to be ceiling mounted and having it fall on a car would be bad
 * The Arduino Uno and Nano use a lot of power even in sleep mode: 15.5mA which drains a 2500mAh battery in less than a week. Even an LED on uses 20mA

An option is to use standard alkaline batteries in an enclosure. A AA battery typically has 2500mAh. We aim for 10,000mAh minimum for a battery pack. This means we’d need 4 batteries in series to increases voltage to 6V and then 4 of these in parallel to increase capacity to 10,000mAh for a total of 16 AA’s. I decided to weight this on a kitchen scale, and it came to 14oz.

Date: 9/29/19

Team Member: Nikolai, Zane, Tyrel

Subject: Battery packs, Alkaline Batteries, Voltage Regulators

Category: Hardware Research Outcome: Tyrel and Zane look up 3.7 V LiPo battery packs. They could possibly be combined in series to get to 7.4V since an Arduino typically accepts between 5-12V input. The stripped-down Arduinos like the Pro Mini however, don’t come with a voltage regulator and would need 3.3/5V fed directly to it unless a regulator is used. However, this will reduce efficiency stepping the voltage down. Using the pack directly means we would need to get a 3.3V version of the Arduino Pro Mini since the 5V won’t work directly with the packs.

I (Nikolai) decide to get some D batteries and see how big and heavy they are. A D Alkaline has ~13,000 mAh. 4 of them combined to get 6V is 1lb 3 oz and 2.5” x 2.5” x 2.75” which is really heavy and leaves little room for the rest of the hardware.

Tyrel finds the battery modules – 18650 on a site which claim to have 9800mAh in a single cell, which seems too good to be true. He does some further digging and apparently, they are just flat out lying about it and are closer to 4000mAh according to reviews.

Another thing we need to consider is the self-discharge of the batteries: a 10,000mAh battery doesn’t mean we will get 10,000mAh to use and will need to account for it in calculations.

Date: 10/10/19

Team Member: Nikolai, Tyrel, Zane

Subject: Solar Panels in the Parking Garage

Category: Hardware Research

Outcome: Our trip to the parking garage revealed that there is a decent amount of sunlight available on the southern side 2nd and 3rd floors. It is not direct, but it was bright enough that maybe solar panels inside the garage could help charge the battery during the daytime.

Date: 10/10/19

Team Member: Zane

Subject: Solar Panels in the Parking Garage (further)

Category: Hardware Research

Outcome: I still have a pile of solar panels from the deer scaring project I made. They are super small (68x37mm) and are 5V panels that are .3 Watts and output .06 Amps. They aren’t very powerful, but in a project that is supposed to barely sip any power, I feel like these would be really beneficial, as any power coming in would be good. We need to ask John if we can just put these on the box, as a “why not” kind of feature, where we aren’t necessarily relying on it as part of the power usage, but as an added source of longevity from our lipo batteries. These panels are very inexpensive as well, I think I paid around $15 for ten of them. If John agrees, I will also need to update the 3D model to reflect the solar panels being added.

Date: 10/15/19

Team Member: Nikolai

Subject: Pulse Width Modulation

Category: Software Research

Outcome: In CS443 (Embedded Systems) we just had a project to power a DC motor using pulse width modulation (PWM). This is a way of providing a non-continuous supply of power to reduce the speed of the motor. It had 4 settings – 25%, 50%, 75% and 100% which represented the duty cycle to analogWrite on the Arduino.

I decide to try this same approach for powering an LED. A 100% duty cycle with no PWM consumes 65 mA. A 3.9% duty cycle (10/256 on analogWrite) results in a slightly dimmer LED but consumes 1.78 mA. Halving this further to 1.95% (5/256) draws 0.9mA but was much dimmer than 3.9%. Even at 3.9%, that would drain a 10,000mAh battery in ~235 days without running anything else. Unsure as to whether this is the peak current draw when the LED is on or an average, since the multimeter I used doesn’t state over what time interval the reading is.

Date: 10/29/19

Team Member: Nikolai, Tyrel, Zane

Subject: Solar Power

Category: Hardware Research

Outcome: We decide that we probably can’t do everything we need on 10,000mAh and last a year on its own. We’ll need to increase battery capacity and use solar charging from ambient light. The solar charging is looking like the easier choice at this point as anything that the solar panels can pick up will be useful.

Date: 11/17/19

Team Member: Zane

Subject: Sleep mode with at-home garage prototype

Category: Sleep mode

Outcome: I implemented my code for putting my Arduino into deep sleep from my previous project into the prototype on my garage. After 4 hours of trying to figure out why it wouldn’t work, I realized that I forgot half the code. All is working now, the Arduino goes to sleep, wakes on a PIR trigger, verifies a few times with the ultrasonic sensor, and flashes the LED accordingly, then it goes back to sleep. I still need to figure out a good way to pulse the LED independently of the sleep modes. I plan on using a watch dog timer, where the system periodically wakes to flash the LED, regardless of what else is going on sensor wise.

Date: 11/19/19

Team Member: Nikolai

Subject: Power Usage Estimations

Category: Hardware Research

Outcome: I create a spreadsheet with the different types of ways that the battery is going to be drained in the GSU. I then do some estimates as to the power usage based on datasheets and how often each will be used in a day.

The following assumptions were used:
 * 10,000 mAh battery
 * 1% battery drain per month due to self-discharge
 * Transmission over LoRa will be at 50% power – 50mA
 * Receiving over LoRa uses 20mA, there will be a 20 second receive window when a GSU is receiving
 * A transmission from GSUs to the GSM will be every 30 minutes between 6am and 8pm
 * Sensors activate on interrupt and will run for 10 seconds at a time
 * The PIR sensor activates when a car parks/motion is detected
 * The ultrasonic sensor will be used when a car is parked every 30 minutes afterwards
 * A 10% duty cycle for the LED will be used, which corresponds to 10% of a 30mA LED
 * The Arduino will be using current when active
 * There will be a constant current drain when in sleep mode
 * Solar charging is currently unknown and will not be included yet

Parameters:
 * Days per year 365
 * Frequency per hour 2 (LoRa and sensor)
 * Frequency per hour 3600 (LED)
 * Hours active per day 14
 * Days per month 30
 * Available capacity on a 10,000mAh battery is 8,800mAh after accounting for the self-discharge

We need to aim for an idle current draw of 270uA in order to last for a year before we consider solar charging.

Date: 01/19/20

Team Member: Nikolai

Subject: Battery Packs, Solar charging

Category: Hardware Research

Outcome: Looked up possible solutions for battery packs and the solar charging. Adafruit has multiple components that can be combined to provide solar charging. They have 1W 6V solar panels, the charging unit with regulator, JST connectors and battery packs. Their largest battery pack is only 6,600 mAh however and would not be near enough what we need. Combining them in parallel to increase capacity sounds like an option. But looking further into it reveals that the individual 18650 cells need to be impedance and voltage matched when fully charged. Otherwise, bad things happen when one discharges into another like fires, which we want to avoid.

Possible items to get:
 * Adafruit USB, DC & Solar Lipoly Charger. $17.50 https://www.adafruit.com/product/390
 * Adafruit 6V 1W solar panel $19.95 https://www.adafruit.com/product/3809
 * Connector for solar panel and charger $1.50 https://www.adafruit.com/product/2788
 * Additional JST Connector $0.75 https://www.adafruit.com/product/261

Enclosure
Date: 10/1/19

Team Member: Nikolai, Zane

Subject: Mounting the GSU to the Parking Garage Ceiling

Category: Hardware Enclosure

Outcome: Just thinking about how to mount the GSU to the ceiling. We can’t do any permanent damage to the ceiling which limits us to using an adhesive as opposed to drilling. Sugru could be usable, but the concrete surface is going to be porous and may leave residue after remove.

Zane mentions scotch tape and they have a 5lb one and a 30ln “extreme” tape that could be used.

Date: 10/10/19

Team Member: Zane

Subject: LED diffusion for better visibility

Category: Hardware Enclosure

Outcome: While Nikolai was getting the measurements for the garage stalls, I tested a small LED diffuser that I made in the parking garage. Since the LEDs will have to just “blink” they need a way to be seen well. I am using SMD LEDS because of their low power consumption and the ease in which they can be implemented into a project and controlled via the FastLED library. The only issue is that since they are flat, they don’t have a great viewing angle when pointed at the ground from the ceiling. For my testing, I 3D printed a hollow diffuser, a rectangular enclosure that sits over the SMD LED. I tried 3 different wall thicknesses at my house before settling on the .5mm thickness, as it was sturdy enough to affix to the enclosure, but thin enough that light passes through it easily. I then put an Arduino nano on a stick, with the LED attached, an the diffuser over the LED. The results were night and day in terms of visibility. It was much easier to see the LED pulse in the dark garage with this on it.

Date: 10/12/19

Team Member: Zane

Subject: Radius limiting of the PIR sensor

Category: Hardware Enclosure

Outcome: The yellow ring that is present in the 3D model is designed to be a radius limiter for the PIR sensor, so that it isn’t detecting motion anywhere under than directly below it in the garage stall. I have created a small prototype, about half the size of the box specifications, just to test whether the design works or not. While the PIR sensor is in fact working, the plastic ring to limit its radius is not working at all. After doing some research, I found out that Infrared sensors have no problem detecting heat signatures through most kinds of plastic. 3D printers also don’t really ever use 100% infill, so the material is very hollow in the middle. Some suggestions I found were to use aluminum foil or some other kind of metal, or a special plastic that PIR sensors can’t “see” through.

Date: 10/15/19

Team Member: Zane

Subject: Testing radium limiting of PIR sensor

Category: Hardware Enclosure

Outcome: I tried the suggestion of using aluminum foil for the ring that is supposed to limit the radius of the PIR sensor, and it works wonderfully. Though not at all aesthetically pleasing, it does verify that there are options available for this.

Date: 11/5/19

Team Member: Zane

Subject: Update to 3D model

Category: Hardware Enclosure

Outcome: Here is the updated 3D model, after John had approved the addition of two small solar panels to the bottom of it. (Picture on right)

Mesh Network
Date: 9/19/19

Team Member: Nikolai Subject: LoRa Mesh Network

Category: Software Research

Outcome: Found a site that has a basic implementation of a mesh network using LoRa located at https://nootropicdesign.com/projectlab/2018/10/20/lora-mesh-networking/

Looks like it could use a useful starting point

Date: 10/21/19 – 10/22/19

Team Member: Nikolai

Subject: LoRa Testing

Category: Hardware and Software Testing

Outcome: Had soldered the LoRa boards the previous day and was now testing the boards using the RadioHead library and three Arduinos.

I first use the mesh network that I found last month.

First attempt results in an “init failed” message on the serial console.

I then use the tutorial provided at https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/rfm9x-test

Double check the solder joints and pins and they look ok. They also have a wiring diagram, so I follow what they have shown.
 * Vin -> Vin
 * Gnd -> Gnd
 * SCLK -> 13 Uno, 52 Mega
 * MISO -> 12 Uno, 50 Mega
 * MOSI -> 11 Uno, 51 Mega
 * CS -> 4
 * RST -> 2
 * G0 -> 3

Try uploading the client/server sketches to two Arduinos and “init failed” again.

Use a multimeter to measure voltages and make sure power is going to the LoRa boards.

I then go through the sketch and look to see whether there is anything mentioning pins 11, 12, 13, 2, 3, 4 since they correspond to the pins.

I then find #defines for RFM95_CS, RMF95_INT and RFM95_RST are set to 10, 9 and 2. These correspond to CS, G0 and RST respectively however the Pins do not match up with the wiring diagram (maybe older version of hardware was used). I correct this and it works – the console outputs of both Arduinos show that they are communicating.

I attach a multimeter and the power draw is 75mA idle, and 100mA when transmitting which is huge.

I then upload the mesh network sketches to the 2 Arduinos I have, and they all communicate. To get the mesh network going required a program to modify the EEPROM so that there was an ID stored that the mesh network would retrieve for use.

Memory usage: RFM95 Client Server uses 8K FLASH (25%), 893 Bytes of RAM (43%).

Mesh network – 13.7K FLASH (42%), 1447 Bytes of RAM (70%).

I solder the third LoRa module and test that. Decide to go field test this in the garage today.

Date: 10/22/19

Team Member: Nikolai, Tyrel, Zane

Subject: LoRa Range Testing

Category: Hardware and Software Testing

Outcome: After the previous nights’ work of getting the LoRa boards and mesh network working, I (Nikolai) decide we should go to the garage and test the range out.

I have 3 Arduinos each with a LoRa board connected and they are all working as expected, printing the status of the network to console output.

Test conditions:
 * 3 Arduino Uno/Mega with a LoRa radio attached – A Garage Sensor Unit (GSU)
 * Used the LoRa mesh network implementation at https://github.com/nootropicdesign/lora-mesh
 * Broadcasts at maximum power – 100mA per transmission
 * This implementation periodically sends messages including the Received Signal Strength Indicator (RSSI) of each radio in the network
 * Using a laptop and console, measure how far another GSU can be before connection drops out (Goal is to get to the garage ~400 ft away)

One Arduino is placed by the entrance to the UofI’s office at the Den and connected to mains power. I then have one connected to my laptop with serial console active to see the LoRa messages. The third is connected to a 9V battery. The Relative Signal Strength Indicator (RSSI) is typically around -60 when in the same room.

Once we step outside of the Den, the RSSI has already dropped to -90. Halfway down the car park next to the Den at the RRSI is at -120 and drops out. We head to the parking garage and me and Zane stand by the car entrance/exit and Tyrel takes the battery powered Arduino and starts walking up the ramp to the next floor and then to the third floor. The signal doesn’t drop out until he is at the farthest corner on the second floor but otherwise is around -90 to -120 RSSI.

Tyrel then stands on the second floor with Line of Sight to the Den rooftop and Zane and I walk back to the Den to measure signal strength. We get to where the Gateway would be located on the rooftop next to the Den and get -100 to -110 RSSI even without LOS and even get similar signal strength with the Arduino plugged in downstairs. This experiment has proved that using LoRa would the project is viable.

Sensors
Date: 9/12/19

Team Member: Zane

Subject: Various forms of range testing

Category: Sensors

Outcome: Looking into the possible sensor types for verifying that a vehicle is still in the stall after the PIR detects it, I have settled, at least for now, on an Ultrasonic Range Sensor. They are super inexpensive and perform well for what they do. Other suggestions/ideas that we floated around were microphone sensors, laser sensors, vibration sensors, some other form of light-break sensor, as well as more high-powered versions of the ultrasonic sensor that we are going with.

Date: 9/15/19

Team Member: Zane

Subject: Further PIR testing

Category: Sensors

Outcome: As a lot of this is listed above under “Arduino”, I will focus here solely on the PIR aspect of the project that I made, and how it carries over to our Park-It-CDA project. The specific sensor that I used, and will most likely use moving forward, is the HC-SR501, which I purchased from DIYMALL through Amazon. I am familiar with this manufacturer, and have used many of their other sensors, and trust their products. These sensors have a 50uA current draw when inactive, but use 4.5-20V. This can be overcome, and modified to work with a 3.7V system however, as there are various tutorials on how to do so. They have a radius of 100 degrees, which will need to be limited somehow. They also have two potentiometers, one for the range, and one for the timing/sensitivity, or how often they compare heat signatures and how easily a “trigger” is given.

Date: 10/22/19

Team Member: Zane

Subject: Testing the PIR in driveway

Category: Sensors

Outcome: I finally got my small prototype hooked up above my driveway. It is attached to a 2X4 that extends out from the garage. My neighbors probably love the view of it. Before using tin foil on the ring to limit the radius, this thing was practically useless, and would go off constantly to any movements around the area. I took it down and put the foil around the ring, and it does a really good job of detecting when my truck is below it, as well as my wife’s car, and a person simply walking. The next step is to get the ultrasonic sensor to verify this, and to configure the LED to reflect the status of my driveway.

Date: 10/25/19

Team Member: Zane

Subject: Ultrasonic sensor testing in driveway

Category: Sensors

Outcome: Upon adding the ultrasonic sensor to my setup, the unit is behaving erratically again. The PIR works, but after connecting it via serial to my laptop, the ultrasonic sensor is not giving data, and is just reporting a nonstop stream of zeros. I am taking it back into my office to run some more tests without having to climb up and down a ladder and stand in the cold. Will update when I find the issue.

Date: 10/26/19

Team Member: Zane

Subject: Debugging ultrasonic sensor

Category: Sensors

Outcome: I’m not sure if the sensor was DOA or what. I messed with it for awhile, and could not get anything other than zeros from the serial monitor. In the sensor’s defense, it came in a $20 kit with 30-something other sensors. I will order a decent one and update when it arrives.

Date: 11/1/19

Team Member: Zane

Subject: New ultrasonic sensor

Category: Sensors

Outcome: Although most manufacturers make the same HRC-SR04 ultrasonic sensor, I’m hoped that ordering one through DIYMALL would result in a better product, which it did. This sensor is giving meaningful data, and although it’s not extremely accurate, it doesn’t really need to be. It just needs to make sure there either still is, or still isn’t a vehicle underneath it. I hooked it up to the “garage plank” and it works great with the PIR sensor. The serial monitor reports a trigger from the vehicle, and the ultrasonic sensor sends periodic details on whether it’s still there or not. It sometimes takes a few seconds for it to report that a vehicle has left or arrived. Also, sometimes there will be erroneous data between accurate readings which would cause the LED to change for no reason. I will have to design some kind of Byzantine General fault checking to make sure the LED is consistent.

11/9/19

Team Member: Zane

Subject: Adding LED to garage box

Category: Sensors(kind of)

Outcome: I finally had time to add the LED to the project, and this may be the first thing I have added that didn’t give me any trouble. It works great with the sensors. There are still some delays and false readings that need to be worked out, but I am confident that this combination of hardware will suffice for the project.

11/25/19

Team Member: Zane

Subject: Fault tolerance for ultrasonic sensor

Category: Sensors

Output: I implemented a simple “fact checking” routine into my sensor code. Basically, to get rid of the error readings from the ultrasonic sensor, it takes 3 readings, which are temporarily held, and compared. If one is way out of range of the other two, it is thrown out. This isn’t perfect, as once in a great while the sensor will give back-to-back false distance readings, but it’s not often enough to waste battery power doing 5 or more checks. I think one wrong LED blink every so often is worth the trade off.

Simulation
Team Member: Tyrel Parker

Example Simulation Data:
 * Car 1 arriving at hour 2
 * Car 1 parked at 2 for 4 hours
 * Car 2 arriving at hour 4
 * Car 2 parked at 4 for 6 hours
 * Car 3 arriving at hour 6
 * Car 1 leaving spot at hour 6
 * Car 3 parked at 6 for 4 hours
 * Car 4 arriving at hour 8
 * Car 4 parked at 8 for 3 hours
 * Car 5 arriving at hour 10
 * Car 2 leaving spot at hour 10
 * Car 3 leaving spot at hour 10
 * Car 5 parked at 10 for 4 hours
 * Car 4 leaving spot at hour 11
 * Car 6 arriving at hour 12
 * Car 6 parked at 12 for 6 hours
 * Car 7 arriving at hour 14
 * Car 5 leaving spot at hour 14
 * Car 7 parked at 14 for 6 hours
 * Car 8 arriving at hour 16
 * Car 8 parked at 16 for 5 hours
 * Car 9 arriving at hour 18
 * Car 6 leaving spot at hour 18
 * Car 9 parked at 18 for 9 hours
 * Car 10 arriving at hour 20
 * Car 7 leaving spot at hour 20
 * Car 10 parked at 20 for 6 hours
 * Car 8 leaving spot at hour 21
 * Car 11 arriving at hour 22
 * Car 11 parked at 22 for 5 hours
 * Car 12 arriving at hour 24
 * Car 12 parked at 24 for 6 hours
 * Car 13 arriving at hour 26
 * Car 10 leaving spot at hour 26
 * Car 13 parked at 26 for 5 hours
 * Car 9 leaving spot at hour 27
 * Car 11 leaving spot at hour 27
 * Car 14 arriving at hour 28
 * Car 14 parked at 28 for 4 hours
 * Car 15 arriving at hour 30
 * Car 12 leaving spot at hour 30
 * Car 15 parked at 30 for 7 hours
 * Car 13 leaving spot at hour 31
 * Car 16 arriving at hour 32
 * Car 14 leaving spot at hour 32
 * Car 16 parked at 32 for 3 hours
 * Car 17 arriving at hour 34
 * Car 17 parked at 34 for 9 hours
 * Car 16 leaving spot at hour 35
 * Car 18 arriving at hour 36
 * Car 18 parked at 36 for 5 hours
 * Car 15 leaving spot at hour 37
 * Car 19 arriving at hour 38
 * Car 19 parked at 38 for 6 hours
 * Car 20 arriving at hour 40
 * Car 20 parked at 40 for 5 hours
 * Car 18 leaving spot at hour 41
 * Car 21 arriving at hour 42
 * Car 21 parked at 42 for 6 hours
 * Car 17 leaving spot at hour 43
 * Car 22 arriving at hour 44
 * Car 19 leaving spot at hour 44
 * Car 22 parked at 44 for 7 hours
 * Car 20 leaving spot at hour 45
 * Car 23 arriving at hour 46
 * Car 23 parked at 46 for 3 hours
 * Car 24 arriving at hour 48
 * Car 21 leaving spot at hour 48
 * Car 24 parked at 48 for 4 hours
 * Car 23 leaving spot at hour 49
 * Car 25 arriving at hour 50
 * Car 25 parked at 50 for 7 hours
 * Car 22 leaving spot at hour 51
 * Car 26 arriving at hour 52
 * Car 24 leaving spot at hour 52
 * Car 26 parked at 52 for 9 hours
 * Car 27 arriving at hour 54
 * Car 27 parked at 54 for 5 hours
 * Car 28 arriving at hour 56
 * Car 28 parked at 56 for 3 hours
 * Car 25 leaving spot at hour 57
 * Car 29 arriving at hour 58
 * Car 29 parked at 58 for 5 hours
 * Car 27 leaving spot at hour 59
 * Car 28 leaving spot at hour 59
 * Car 30 arriving at hour 60
 * Car 30 parked at 60 for 8 hours
 * Car 26 leaving spot at hour 61
 * Car 31 arriving at hour 62
 * Car 31 parked at 62 for 7 hours
 * Car 29 leaving spot at hour 63
 * Car 32 arriving at hour 64
 * Car 32 parked at 64 for 3 hours
 * Car 33 arriving at hour 66
 * Car 33 parked at 66 for 4 hours
 * Car 32 leaving spot at hour 67
 * Car 34 arriving at hour 68
 * Car 30 leaving spot at hour 68
 * Car 34 parked at 68 for 1 hours
 * Car 31 leaving spot at hour 69
 * Car 34 leaving spot at hour 69
 * Car 35 arriving at hour 70
 * Car 33 leaving spot at hour 70
 * Car 35 parked at 70 for 5 hours
 * Car 36 arriving at hour 72
 * Car 36 parked at 72 for 3 hours
 * Car 37 arriving at hour 74
 * Car 37 parked at 74 for 3 hours
 * Car 35 leaving spot at hour 75
 * Car 36 leaving spot at hour 75
 * Car 38 arriving at hour 76
 * Car 38 parked at 76 for 8 hours
 * Car 37 leaving spot at hour 77
 * Car 39 arriving at hour 78
 * Car 39 parked at 78 for 2 hours
 * Car 40 arriving at hour 80
 * Car 39 leaving spot at hour 80
 * Car 40 parked at 80 for 9 hours
 * Car 41 arriving at hour 82
 * Car 41 parked at 82 for 2 hours
 * Car 42 arriving at hour 84
 * Car 38 leaving spot at hour 84
 * Car 41 leaving spot at hour 84
 * Car 42 parked at 84 for 4 hours
 * Car 43 arriving at hour 86
 * Car 43 parked at 86 for 6 hours
 * Car 44 arriving at hour 88
 * Car 42 leaving spot at hour 88
 * Car 44 parked at 88 for 4 hours
 * Car 40 leaving spot at hour 89
 * Car 45 arriving at hour 90
 * Car 45 parked at 90 for 9 hours
 * Car 46 arriving at hour 92
 * Car 43 leaving spot at hour 92
 * Car 44 leaving spot at hour 92
 * Car 46 parked at 92 for 10 hours
 * Car 47 arriving at hour 94
 * Car 47 parked at 94 for 8 hours
 * Car 48 arriving at hour 96
 * Car 48 parked at 96 for 5 hours
 * Car 49 arriving at hour 98
 * Car 49 parked at 98 for 5 hours
 * Car 45 leaving spot at hour 99
 * Car 50 arriving at hour 100
 * Car 50 parked at 100 for 4 hours
 * Car 48 leaving spot at hour 101
 * Car 46 leaving spot at hour 102
 * Car 47 leaving spot at hour 102
 * Car 49 leaving spot at hour 103
 * Car 50 leaving spot at hour 104

I then need to link this simulated data at a slower rate into the graphical interface that will be developed. I can then show cars in the stalls like the graphic below:



Building this type of graphical environment where I will have the ability to access and highlight or fill the stalls as needed while also having a 3d interface such as Unity would give me might be the best way to accomplish what I am looking for.



Essentially I need to be able to show cars moving into and filling the priority spots and leaving at some accurately simulated timeframe similar to the picture below. I will also need to figure out how to develop the graphical pathing for the interface when given data on actual vehicles. I am currently not sure if this will be possible or if I will simply be changing the parking spots color to indicate if it is full or not.





Vehicle Detection and Indication
The unit needs to be in an active traffic/parking zone and monitored to verify the following: The LED indicator will blink Green periodically, to indicate that the stall is empty. It will need to do this while the rest of the system is asleep. Upon the detection of a heat signature (vehicle) it will wake, triple-verify that the vehicle has entered the space, and change the indication color from Green to Red. It will then need to go back to sleep and blink Red periodically, while the system is asleep, and until there is a change in the stall.

Various vehicles will need to be verified to ensure that all types are detected, and that the radius of the PIR as well as the range of both the PIR and Ultrasonic sensors are catching any vehicle, while also not updating falsely due to the presence of a vehicle that is not within the lines of the stall in which this particular unit operates.

LED Indication
The LED always needs to be visible. This means testing its visibility during the morning, afternoon and night. The LEDs on each of the units should not drift so much as to cause a strobing effect in the garage.

Hardware Enclosure
The enclosure for the parking unit should be tested on a similar surface to that of the parking garage ceiling, with different strengths of mounting tape, to ensure that it holds indefinitely, without the risk of damaging a vehicle or damage to the surface on which it is mounted. It will need to be placed in a test area and left for enough time so as to ensure that it is still holding strong, and will continue to do so.

Mesh Network
These are the milestones and things that need to be tested on the Mesh Network to conclude that it is performing as expected.

A GSM can be determined on power on and on a periodic basis thereafter. If the network is already present, a new GSU being added needs to be able to find the GSM and join the network, otherwise it is going to become a GSM for a different network.

GSUs can transmit data to the GSM either directly or via another GSU. GSUs wake up on a timer to transmit, then go back to sleep. The GSUs and GSM need to be in sync with one another to send and receive data. The receiver is only going to be active for a short period since it uses ~20mA while active. The GSM can transmit data to the GSG at the Den. This needs to be done on a periodic basis to clear the memory of the GSM since we don’t have a lot of memory to work with. Data transmitted is encrypted – the payload needs to be encrypted since anyone with a LoRa radio would be able to receive the packets and decipher them. Especially since some of the messages will be control signals.

Data Collection
The GSUs need to be able to store the sensor data and a timestamp. The GSM needs to store its own data and other GSU data until it transmits to the GSG. This data will be transient. The server in the Den will permanently store all data that comes in. Data will also need to be collected to calibrate the vehicle detection software. This means recording the average time that a commuter takes to park, to leave and the duration in which their vehicle is occupying a stall.

Data Analysis
The Simulation needs to take in this data to analyze and so that it can work out average time from car entry to carpark occupancy.

Additional Documentation
Project Portfolio

Project Portfolio