User:Bera6278

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
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
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.

=Final Design=

=Validation= 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.

=Team Members=

=Additional Documentation= Portfolio Project Schedule Project Portfolio

Meeting Minutes

Presentations



Client Interview