UBC Undergraduate Research

Design Document for Dynamic Parking Project Choudhury, Saurav; Csikos, Anthony; Judd, Graham; O’Sullivan, Alicia; Windt, Nicholas 2019-04-04

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata

Download

Media
18861-Choudhury_S_ELEC_491_Dynamic_parking_signage_final_report.pdf [ 799.52kB ]
18861-Choudhury_S_ELEC_491_Dynamic_parking_signage_user_manual_display_controller.pdf [ 757.32kB ]
18861-Choudhury_S_ELEC_491_Dynamic_parking_signage_user_manual_web_application.pdf [ 564.16kB ]
Metadata
JSON: 18861-1.0387173.json
JSON-LD: 18861-1.0387173-ld.json
RDF/XML (Pretty): 18861-1.0387173-rdf.xml
RDF/JSON: 18861-1.0387173-rdf.json
Turtle: 18861-1.0387173-turtle.txt
N-Triples: 18861-1.0387173-rdf-ntriples.txt
Original Record: 18861-1.0387173-source.json
Full Text
18861-1.0387173-fulltext.txt
Citation
18861-1.0387173.ris

Full Text

UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report         Design Document for Dynamic Parking Project Saurav Choudhury, Anthony Csikos, Graham Judd, Alicia O’Sullivan, Nicholas Windt University of British Columbia ELEC 491 Themes: Transportation, Community, Wellbeing April 4, 2019         Disclaimer: “UBC SEEDS Sustainability Program provides students with the opportunity to share the findings of their studies, as well as their opinions, conclusions and recommendations with the UBC community. The reader should bear in mind that this is a student research project/report and is not an official document of UBC. Furthermore, readers should bear in mind that these reports may not reflect the current status of activities at UBC. We urge you to contact the research persons mentioned in a report or the SEEDS Sustainability Program representative about the current status of the subject matter of a project/report”.   Terms Appendix:   Term  Definition User  UBC Parking Admin Client   UBC Parking Device   Parking stall display and Monitoring Device FR   Functional Requirement, (outlined in requirements documentation) NFR  Non Functional Requirement, (outlined in requirements documentation) C  Constraint,  (outlined in requirements documentation) IP65  IP rated as "dust tight" and protected against water projected from a nozzle LoRaWAN  Long Range Wide Area Network DEVEUI  Unique device ID used to communicate with LoRa devices SPI  Serial Peripheral Interface  USART  Universal Synchronous/Asynchronous Receiver/Transmitter    1   Content  1. High Level System Description 5 1.1 High Level System 5 1.2 Web Management System 6 1.2 Parking Stall Display and Monitoring Device 6 1.3 LoRa 6 2. Low Level System Description 8 2.1 Management Application 9 2.2 Eleven-X DASS system 9 2.3 PlacePod Smart Parking Sensor 10 2.4 Arduino MKR WAN 1300: LoRa Handler, Temperature, and Accelerometer controller 10 2.5 DESPI-M02 Display Controller 11 3.  Parking Stall Display and Monitoring Device 11 3.1 Design Requirements/Rationale 11 3.2 Overview 12 3.3 Components List 12 3.3.1 Arduino MKR WAN 1300[1] (x1) 12 3.3.2 GooDisplay 12.48” Color Large E-Paper Screen[8]  (x1) / GooDisplay Communication Board Demo Kit Adapter for 12.48” E-paper Display[9]  (x1) 13 3.3.3 DESPI-M02 13 3.3.4 LM35 Temperature Sensor (x1) 13 3.3.5 ADLX345 Accelerometer (x1) 14 3.3.6 Four Channel-Optical-Isolated-Trigger (x1) 14 3.3.7 Lead-Acid Battery (x1) 14 3.4 Housing Design 15 4 Power 16 4.1 Power Budget 16 4.2 Approximate Power Consumption of the Circuit 16 5 Web Application 17 5.1 Design Requirements 17 5.2 Web Application Components 18 5.3 Wireframes for Web Application 19 2  6 Software System 22 6.1 Downstream Payload Flow 22 6.2 Arduino Flow Cycle 22 6.3 Car Detection Flow 24 References 25    3  The purpose of this document is to specify and justify the design choices made in order to successfully complete the prototype/system.   1. High Level System Description 1.1 High Level System Based on client requirements the system solution has been broken down into two main components:  ● The Web Management System, from which the user can remotely monitor the occupancy, change the display, and in general manage the stalls. The communication link between the web app and the physical display and monitoring devices will be over LoRaWAN, a wide area network technology intended for low powered IoT (Internet of Things) devices.  ● The Parking Stall Display and PlacePod (a monitoring device installed in the ground of the parking stall) work together to display various parking restrictions according to the need. The stall also transmits parking data over LoRaWAN, in order for the UBC Parking Administration to view.  ● Figure 1.1 below shows a diagram of this high level system.    Figure 1.1 - High Level System Diagram 4  1.2 Web Management System As previously explained, the web management system will be the interface that the user, UBC Parking Services, will use to manage the dynamic parking stalls. This system will communicate remotely with the Parking Stall and Monitoring Devices to update, set stall restrictions, and receive stall data. The core features include: ● Homepage to display all key stall information so the client can monitor the stalls ● Manual and automatic changes to stall restrictions ● Pre-loaded images and custom license plate restriction options 1.2 Parking Stall Display and Monitoring Device The Parking Stall Display and Monitoring Device will be the end-system device present at each individual dynamic stall. Its function is to display parking restrictions and monitor the stall. Core features include: ● Displaying configured parking restriction ● Detecting cars parked in the stall ● Detecting vehicle impacts with sign post 1.3 LoRa LoRa (Long Range) is a long range digital wireless communication technology which utilizes the license-free sub-gigahertz radio bands (915 MHz in North America). LoRaWAN (Long Range Wide Area Network) is the network over which LoRa operates. LoRaWAN enables transmission over very long distances.   LoRa was rated as the best choice for wireless communication in our system design over our second choice, cellular LTE, for the following reasons: 5  ● Low powered - LoRa radio power consumption is much less than LTE cellular. Additionally different classifications of LoRa devices can be implemented, through radio sleep cycles, for even better power consumption.  ● Inexpensive - LoRa utilizes unlicensed radio bands so no subscriptions are needed for network use; this scales much better cost wise than LTE ● Infrastructure at UBC -  Our client currently has a LoRa system set-up for car detection at parking stalls around UBC. This system features deployed gateways connected to the Eleven-X DASS which acts as middleware between LoRaWAN and the internet. This provides us with a trusted, proven and already deployed sub system to ease integration of the Web Management System and the Parking Stall Display and Monitoring Device.  These advantages over LTE do come at cost when it comes to bandwidth. In practice, LoRaWAN payloads should be limited to a maximum size of only 8 bytes and LoRa enabled devices should not be transmitting more than once every two minutes. Infringing these guidelines can lead to network congestion and dropped packets. For our system high bandwidth is not needed as only small amounts of data need to be transmitted, (~1-7 bytes) at intervals generally greater than 5 minutes.    6  2. Low Level System Description    Figure 2.1 - System Level UML Referencing the System Level UML (figure 2.1), the web management system is broken down into 2 main subsystems, i.e. the Management Application (section 2.1) and the Eleven-X DASS system (section 2.2). The Parking Stall Display and Monitoring device is broken down into 3 main subsystems i.e. Arduino MKR WAN 1300, the PlacePod Smart 7  Parking Sensor and the STM32 Display Controller. The rationale and function of these subsystems are described in detail in the following sections: 2.1 Management Application The management application is the interface the user will use to manage deployed dynamic parking stalls. The features and functionality of this subsystem are summarized well by the Web Management System section above (section 1.2). The engine for our web application will be the ASP.NET framework hosted on Amazon Web Services.  The client gave full flexibility for selecting the web-app development stack. The rationale for these components are the following: ASP.NET: ● Active code base, supported by Microsoft ● Readily available documentation ● Mature framework, (stable) ● Powered by C#, (the entire project team has some background in C programing) Amazon Web Services: ● Very popular, very flexible (offers instances for all popular OS’s and frameworks) ● Readily available documentation ● Trendy, good for resumes The management application will allow for the user to remotely manage the deployed Parking Stall Display and monitoring the devices, required by FR1-5. Further details of the web management design are outline in section 5. 2.2 Eleven-X DASS system The Eleven-X DASS system acts as a middleware proxy server between the remote LoRaWAN devices and our Management Application. LoRa based devices can be registered with the DASS. LoRa payloads transmitted by registered devices will be received and cached on the DASS proxy server. Applications can then query the DASS to pull payloads over the web or set up DASS to push payloads over the web to the 8  application. Likewise, payloads can be sent downstream to the remote devices.  An application can push payloads to the server where they are cached and can then be fetched or pushed to the desired remote device. This creates a black box interface between our management application and remote device’s.  As mentioned in section 1.3 the Eleven-X DASS system is currently used and deployed by UBC parking. Several LoRa gateways are set up around campus connected to the Eleven-X DASS over cellular. Using the DASS is a clear choice given the pre-existing infrastructure and use by UBC parking. This subsystem is needed for remote communication with our devices, which is required by FR1. 2.3 PlacePod Smart Parking Sensor The PlacePod Smart Parking Sensor is placed underneath a dynamic parking stall. It utilizes a geomagnetic sensor to detect if a car is parked above. This device does not directly connect to our Parking Display as it utilizes LoRaWAN as its form of networking. Detections are relayed from the PlacePod sensor to the Web App. UBC parking currently has PlacePod sensors deployed for car detection, so we have chosen to integrate these detectors into our system. This car detection functionality is required by FR3. 2.4 Arduino MKR WAN 1300: LoRa Handler, Temperature, and Accelerometer controller One of the biggest challenges to designing our system is power management, as the Parking Display is constrained to being powered autonomously. To design this system we are using the Arduino MKR WAN 1300 which is a very low powered microcontroller (<20 mA operating current) that has a built in LoRa module. However, the device is limited by its computing power. The MKR WAN 1300 will always be running in the system; its tasks include: ● Receiving and transmitting LoRa packets ● Detecting any tampering of the device through an accelerometer  9  2.5 DESPI-M02 Display Controller The DESPI-M02 display controller is used to store and update images on our e-paper display (e-paper will be used to display the parking restrictions; see section 3.3.5 for further details on the e-paper display). The board features an STM32 microcontroller which is used to drive the 2 quad SPI interfaces of the e-paper display. Additionally the board features 128MB external SPI flash chip which was utilized to store images on the device,  (up to 100 images). Images are preloaded onto the board over USB serial using an image loading script we developed. We went with the DESPI-M02 as it was the recommended development board by the e-paper manufacturer, (GooDisplay).                    10  3.  Parking Stall Display and Monitoring Device This section goes into further details of the Parking Stall Display design outlining: design requirements/rationale (3.1), system overview (3.2), component list/rationale (3.3) 3.1 Design Requirements/Rationale  ● Low powered: able to operate power autonomously off of a 20W solar panel ○  Solar panels larger than 20W are dimensionally large for a single stall ● Average power consumption of the device cannot be more than 0.8W ○ In shortest daylight conditions in Vancouver we can expect only 1-2 hours usable sunlight, i.e. direct sunlight. ​[10] ● Ability to update and display parking restrictions autonomously ○ FR1,2 ● Ability to detect parked cars at stall ○ FR,3 ● Ability to detect vehicle impacts with the sign ○ FR4 ● Enclosure must be rated IP65 to protect against rain, dust, wind and snow. ○ NFR1           11  3.2 Overview    Figure 3.1 - Block Diagram System Overview  Above is the device topology diagram in figure 3.1. The system is powered by a lead-acid battery which is charged by the Solar Panel/Solar Charge Controller. The battery output is regulated by a DC-DC buck converter to step down to 5 V for the system. The Arduino MRK1300 is always be running, its functionality is outlined in section 2.4. Note the Arduino controls the power to the DESPI-M02 display controller which will only run to update the display,  (e-Paper does not need power to hold a still image). 3.3 Components List  The following section provides details and justification of the parts that were chosen for the device. The quantity of each part per device is noted in the headings. 12  3.3.1 Arduino MKR WAN 1300​[1]​ (x1) Functionality: ​handles LoRaWAN and device side management. ●  A major design choice was LTE vs LoRaWAN, this decision making was highlighted in section 1.3 LoRa. The Arduino MKR WAN 1300 features a built in LoRaWAN module to ease prototyping. ● The arduino MKR series microcontrollers are extremely low powered as it idles at 20mA  (at 3.3V), thus was chosen to help meet the projects low power constraint. ● Arduino devices simplify and accelerate microcontroller prototyping with it’s extensive, easy to use and well supported libraries. Thus we choice to use Arduino given the 8 month timeframe of the project. 3.3.2 GooDisplay 12.48” Color Large E-Paper Screen ​[8]​  (x1) / GooDisplay Communication Board Demo Kit Adapter for 12.48” E-paper Display​[9]​  (x1) Functionality: ​Display parking restrictions at stall. ● Implement the project’s functional requirement to display parking restrictions. ● Meet the project’s low power constraint; this e-epaper display consumes around 0.045W of power to change the display and requires no power to sustain an image. Thus due to the static display nature of our project this display was chosen over other display options such as LED matrix displays and LCD displays which require constant power to display an image. 3.3.3 DESPI-M02 Functionality: ​Drive the e-paper display and store images ● We went with the DESPI-M02 as it was the recommended development board by GooDisplay.  13   3.3.4 LM35 Temperature Sensor (x1) Functionality: ​ Monitor temperature of the device. The LM35 Temperature sensor is used to monitor the temperature of the device enclosure. This will work in conjunction with the Arduino to ensure that when the temperature is below 0 degrees an image will be uploaded to the display twice to prevent image ghosting (remains of the previous image). 3.3.5 ADLX345 Accelerometer (x1) Functionality: ​Detect any tampering with the device. The ADLX345 Accelerometer sensor will be used with the Arduino MKR WAN 1300 to continuously monitor the device enclosure movement. In the event that a car hits the pole on which the device is mounted or someone is tampering with the device, notifications will be sent to the administrator. This device consumes 58µW when in measurement mode and needs to be powered all the time so that any tampering with the device can be constantly monitored. 3.3.6 Four Channel-Optical-Isolated-Trigger (x1) Functionality:​ Interface to control power of the DESPI-M20. The Four Channel-Optical-Isolated-Trigger will be used by the Arduino to control the input power to the DESPI-M20 display controller. These are the components that consume the most power in the system and will only be used when needed. Note this particular relay switch was selected because its I/O on range accepts 3.3V as ‘ON’ which is the output voltage of the I/O pin in On state of the Arduino MKR 1300. 14   3.3.7 Lead-Acid Battery (x1) Functionality:​ Power the system. We decided to go with lead-acid batteries as our client has an abundant supply of these batteries. We are using a 12V, 7.0Ah battery which should be more than enough to power our system 24/7, (see our power budget in section 4) 3.3.8 MP1584 DC-DC Buck Step Down Converter Functionality:​ Step down the battery output voltage to 5V. We needed to step down our battery output voltage from 12V down to 5V. Buck converters are the most efficient way to step down a DC voltage. 3.3.9 20W Solar Panel/GENASUN GV-4 Solar Panel Control Functionality:​ Recharge the devices battery This solar setup was provided by our client. A 20W panel is more than enough to keep our battery charged, and hence keep our device running continuously (see our power budget in section 4). 3.4 Housing Design  The parking stall display is to be housed in an adapted off-the-shelf casing to help meet our unique size and weatherproofing requirements. The materials chosen for the housing are outlined below:  ● PVC casing ○ PVC casing (JB12126 PVC box)​ ​rated to IP66 was chosen as it is an off the shelf solution that has already been validated for weatherproofing. ● Acrylic display cover 15  ○ Acrylic was chosen for the display cover as it is low glare and UV resistant making it perfect for outdoor display applications.  All of the casing materials were chosen to meet the project requirement of being weatherproof up to IP65. A rating of IP65 indicates that the casing must be completely protected against dust and that it must be resistant to a water jet with a pressure of 30 kPa, at a distance of 3m, for 15 minutes.  The housing consists of an aluminum faceplate with an acrylic screen cover set into the centre to protect the e-Paper display. A PVC box sits on the back of the faceplate, connected to the acrylic screen cover, to house all of the electrical components for the device.              16  4 Power 4.1 Power Budget Due to the project goal which states the signs must be stand alone units and C4 which states the system must be self-powered, the device will be solar powered and therefore cannot consume more than 20W per day.   4.2 Measured Power Consumption  Scenario  Time (hr)   Current (A)  Power(W) 5 V system IDLE *  23.8  0.04   0.20 Update Screen  0.2 **  0.20   1 Average Per Hour  1  0.06  0.3  Daily power consumption = (23.8 x 0.2) + (0.2 x 1) = 4.96 Wh Assumptions * LoRaWAN module transmitting and receiving consumption are negligible compared to IDLE therefore are not considered on their own  ** The update screen time was calculated as follows: screen updates take 30 seconds, and assume screen updates once an hour (this is a very large assumption), thus hours =  (30 seconds / 3600 seconds/hr) * 24 hr = 0.2 hr  17  4.3 Power Analysis Given our worst case scenario of only 2 hours of usable sunlight in vancouver ​[5]​ and 15% solar panel efficiency ​[6]​ our panel should charge our battery: Charged Watts/per day =  2 Hours * 20W * 0.15 = 6Wh This value exceeds our absolute worst case scenario power consumption of 4.96 Wh.  Additionally, the battery that we are using is rated at 7Ah (84Wh, 50.4Wh effective considering worst case discharge) fully charged, thus based off our calculated worst case scenario average power consumption our system can run for ((84Wh*0.6)/0.3W) 168 hours straight without a charge. This is equivalent to 7 days.                          18  5 Web Application This section details the requirements and tools used to develop the web application that UBC parking will use to control and monitor the displays. 5.1 Design Requirements  The following are design requirements for the web application as identified by the team:  1. Device list views. 2. Stall management a. Add/Delete b. Set display and restrictions 3. Scale to handle unlimited number of stalls. 4. Hosted on AWS  5. Transferable to UBC server after the project is finished An overview of the web application system can be seen in figure 5.1.  Figure 5.1 - Components of Web Application 19  5.2 Web Application Components Amazon Web Services ​ was chosen to host our web application. This decision was made because it: ● Satisfies web application design requirement 4 that the web application must be hosted on AWS. ● Implements design requirement 5 to be transferable to UBC server after the project is finished  UBC can set up a server to host the web application, but due to administrative oversight and approval timelines this option was negated as delays would have disrupted the project’s timeline.  ASP.NET ​ was the web framework chosen to implement the application because: ● Implements design requirements 1-6. ● Documentation readily available. ● Smaller learning curve, which allows the team to quickly learn and use the framework.  An alternative that we looked at was using React for the frontend and Node.js for the backend.  This was decided against this as there were concerns with the learning curve of React. 5.3 Wireframes for Web Application Code for the web application can be found on github at: https://github.com/acsikos/Dynamic-Parking-Web-Application.git   20   Figure 5.1 - Page 1: Stall List  1. Header bar provides links to the other pages 2. Create New button allows you to add a new stall 3. Filter search options.  Options to filter search such as “occupied/vacant”, “Alert”, “Restrictions”, etc. 4. Device ID column gives the device’s ID used to identify the device on elevenX 5. Last Check-in column shows the last time the web application received a check-in from the stall 6. Status column shows the stall’s status of the stall occupied/Empty  7. Displayed Restriction column shows the current restriction the stall is displaying 8. Location column shows where the stall is located 9. Group column that displays the stall’s group 10. Alert column indicates whether or not the stall needs attention 11. Edit button to make changes to the stall 12. Details button opens more details about the stall 13. Delete button removes the stall  14. Change restriction takes the user to the Change Restriction Page  21  Figure 5.2 - Page 2: Restriction List 15. Add a customized restriction to reserve a stall for a given licence plate 16. Selection buttons that submit the restriction change to the stall  17. Image of the displayed restriction 18. Clear the display  Figure 5.3 - Page 3: Add New Stall 19. Device ID which represents the ID of the arduino of the stall 20.PlacePod ID which represents the ID of the PlacePod of the stall 22  21. Location where the stall is located 22.Group that the stall is in 23.Create the stall Figure 5.4 - Page 4: About  4. Displays a user manual of the web application  Figure 5.5 - Page 5: Contact   5. Displays contact information of the web developers   23   6 Software System This section provides high level flow diagrams of software functionality needed to achieve functional requirements of the system.  6.1 Downstream Payload Flow                                                               ​       Figure 6.1: Downstream Payload Flow Figure 6.1 shows the downstream flow of data from the web app to the e-paper display. First, from the web app, a packet with a desired command is stored in a JSON object and pushed to the Eleven-X DASS through a HTTPS request. The end device is specified by a DEVEUI which is unique to each deployed device. This DEVEUI is included in the path of the HTTPS request. Next, the packet is forwarded from the DASS to a LoRa gateway where the packet is then transmitted over LoRaWAN. The LoRa packet is received by the Arduino MKR with the specified DEVEUI and decoded by the LoRa handler, (for this example the request is to display a desired image which is currently stored on the DESPI M02). The Arduino powers the  DESPI M02 and transmits the image number to be displayed over a USART connection between the 2 devices. The DESPI M02 then reads a single row (163 bytes) of the desired image at a time and writes it to one of the 2 quad SPI interface (each quad spi controls a half of the display). Upon writing the entire image to the display driver, an update command is passed to the display which then updates it to the new image. 24  6.2 Arduino Initiation Algorithm //Start Device Display(CONNECTING)           // DIsplay Connecting on e-paper display Modem.start()           // Start LoRa Modem  While(Modem fails to connect)    // Check if LoRa modem connected to Eleven-X  wait(30s)         //If modem failed to connect wait restart and try again Modem.Restart()  if(Modem connects) //If successfully connected Display (HANDICAP)         // Default Parking Sign  6.3 Arduino Flow Cycle Figure 6.3 shows the Flow Cycle of the Arduino, which is going to be our hub for all the communication and sensor data processing.                   Figure 6.3 Flow Cycle of the Arduino 25  References  [1]"Arduino MKR WAN 1300 (LoRa connectivity)", ​Store.arduino.cc​, 2018. [Online]. Available: https://store.arduino.cc/usa/mkr-wan-1300. [Accessed: 25- Nov- 2018]   [2]"---e-paper display - GOOD DISPLAY", ​E-paper-display.com ​, 2018. [Online]. Available: http://www.e-paper-display.com/download_detail/downloadsId=693.html. [Accessed: 25- Nov- 2018]  [3]​Amazon.ca​, 2018. [Online]. Available: https://www.amazon.ca/GooDisplay-Paper-Screen-Display-Electronic/dp/B07JG1TN5B/ref=sr_1_2?s=industrial&ie=UTF8&qid=1543125424&sr=1-2&keywords=GooDisplay. [Accessed: 25- Nov- 2018]  [4]​Amazon.ca ​, 2018. [Online]. Available: https://www.amazon.ca/GooDisplay-Paper-Screen-Display-Electronic/dp/B07JG1TN5B/ref=sr_1_2?s=industrial&ie=UTF8&qid=1543125424&sr=1-2&keywords=GooDisplay. [Accessed: 25- Nov- 2018]  [5] Current Results, 2018 [Online]. Available: https://www.currentresults.com/Weather/Canada/British-Columbia/sunshine-average-december.php [Accessed: 10- Feb - 2019]  [6] S. Murmson, “The Average Photovoltaic System Efficiency,” Sciencing, 02-Mar-2019. [Online]. Available: https://sciencing.com/average-photovoltaic-system-efficiency-7092.html. [Accessed: 04-Apr-2019].  26  UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report         Design Document for Dynamic Parking Project Saurav Choudhury, Anthony Csikos, Graham Judd, Alicia O’Sullivan, Nicholas Windt University of British Columbia ELEC 491 Themes: Transportation, Community, Wellbeing April 4, 2019         Disclaimer: “UBC SEEDS Sustainability Program provides students with the opportunity to share the findings of their studies, as well as their opinions, conclusions and recommendations with the UBC community. The reader should bear in mind that this is a student research project/report and is not an official document of UBC. Furthermore, readers should bear in mind that these reports may not reflect the current status of activities at UBC. We urge you to contact the research persons mentioned in a report or the SEEDS Sustainability Program representative about the current status of the subject matter of a project/report”.   Terms Appendix:   Term  Definition User  UBC Parking Admin Client   UBC Parking Device   Parking stall display and Monitoring Device FR   Functional Requirement, (outlined in requirements documentation) NFR  Non Functional Requirement, (outlined in requirements documentation) C  Constraint,  (outlined in requirements documentation) IP65  IP rated as "dust tight" and protected against water projected from a nozzle LoRaWAN  Long Range Wide Area Network DEVEUI  Unique device ID used to communicate with LoRa devices SPI  Serial Peripheral Interface  USART  Universal Synchronous/Asynchronous Receiver/Transmitter    1   Content  1. High Level System Description 5 1.1 High Level System 5 1.2 Web Management System 6 1.2 Parking Stall Display and Monitoring Device 6 1.3 LoRa 6 2. Low Level System Description 8 2.1 Management Application 9 2.2 Eleven-X DASS system 9 2.3 PlacePod Smart Parking Sensor 10 2.4 Arduino MKR WAN 1300: LoRa Handler, Temperature, and Accelerometer controller 10 2.5 DESPI-M02 Display Controller 11 3.  Parking Stall Display and Monitoring Device 11 3.1 Design Requirements/Rationale 11 3.2 Overview 12 3.3 Components List 12 3.3.1 Arduino MKR WAN 1300[1] (x1) 12 3.3.2 GooDisplay 12.48” Color Large E-Paper Screen[8]  (x1) / GooDisplay Communication Board Demo Kit Adapter for 12.48” E-paper Display[9]  (x1) 13 3.3.3 DESPI-M02 13 3.3.4 LM35 Temperature Sensor (x1) 13 3.3.5 ADLX345 Accelerometer (x1) 14 3.3.6 Four Channel-Optical-Isolated-Trigger (x1) 14 3.3.7 Lead-Acid Battery (x1) 14 3.4 Housing Design 15 4 Power 16 4.1 Power Budget 16 4.2 Approximate Power Consumption of the Circuit 16 5 Web Application 17 5.1 Design Requirements 17 5.2 Web Application Components 18 5.3 Wireframes for Web Application 19 2  6 Software System 22 6.1 Downstream Payload Flow 22 6.2 Arduino Flow Cycle 22 6.3 Car Detection Flow 24 References 25    3  The purpose of this document is to specify and justify the design choices made in order to successfully complete the prototype/system.   1. High Level System Description 1.1 High Level System Based on client requirements the system solution has been broken down into two main components:  ● The Web Management System, from which the user can remotely monitor the occupancy, change the display, and in general manage the stalls. The communication link between the web app and the physical display and monitoring devices will be over LoRaWAN, a wide area network technology intended for low powered IoT (Internet of Things) devices.  ● The Parking Stall Display and PlacePod (a monitoring device installed in the ground of the parking stall) work together to display various parking restrictions according to the need. The stall also transmits parking data over LoRaWAN, in order for the UBC Parking Administration to view.  ● Figure 1.1 below shows a diagram of this high level system.    Figure 1.1 - High Level System Diagram 4  1.2 Web Management System As previously explained, the web management system will be the interface that the user, UBC Parking Services, will use to manage the dynamic parking stalls. This system will communicate remotely with the Parking Stall and Monitoring Devices to update, set stall restrictions, and receive stall data. The core features include: ● Homepage to display all key stall information so the client can monitor the stalls ● Manual and automatic changes to stall restrictions ● Pre-loaded images and custom license plate restriction options 1.2 Parking Stall Display and Monitoring Device The Parking Stall Display and Monitoring Device will be the end-system device present at each individual dynamic stall. Its function is to display parking restrictions and monitor the stall. Core features include: ● Displaying configured parking restriction ● Detecting cars parked in the stall ● Detecting vehicle impacts with sign post 1.3 LoRa LoRa (Long Range) is a long range digital wireless communication technology which utilizes the license-free sub-gigahertz radio bands (915 MHz in North America). LoRaWAN (Long Range Wide Area Network) is the network over which LoRa operates. LoRaWAN enables transmission over very long distances.   LoRa was rated as the best choice for wireless communication in our system design over our second choice, cellular LTE, for the following reasons: 5  ● Low powered - LoRa radio power consumption is much less than LTE cellular. Additionally different classifications of LoRa devices can be implemented, through radio sleep cycles, for even better power consumption.  ● Inexpensive - LoRa utilizes unlicensed radio bands so no subscriptions are needed for network use; this scales much better cost wise than LTE ● Infrastructure at UBC -  Our client currently has a LoRa system set-up for car detection at parking stalls around UBC. This system features deployed gateways connected to the Eleven-X DASS which acts as middleware between LoRaWAN and the internet. This provides us with a trusted, proven and already deployed sub system to ease integration of the Web Management System and the Parking Stall Display and Monitoring Device.  These advantages over LTE do come at cost when it comes to bandwidth. In practice, LoRaWAN payloads should be limited to a maximum size of only 8 bytes and LoRa enabled devices should not be transmitting more than once every two minutes. Infringing these guidelines can lead to network congestion and dropped packets. For our system high bandwidth is not needed as only small amounts of data need to be transmitted, (~1-7 bytes) at intervals generally greater than 5 minutes.    6  2. Low Level System Description    Figure 2.1 - System Level UML Referencing the System Level UML (figure 2.1), the web management system is broken down into 2 main subsystems, i.e. the Management Application (section 2.1) and the Eleven-X DASS system (section 2.2). The Parking Stall Display and Monitoring device is broken down into 3 main subsystems i.e. Arduino MKR WAN 1300, the PlacePod Smart 7  Parking Sensor and the STM32 Display Controller. The rationale and function of these subsystems are described in detail in the following sections: 2.1 Management Application The management application is the interface the user will use to manage deployed dynamic parking stalls. The features and functionality of this subsystem are summarized well by the Web Management System section above (section 1.2). The engine for our web application will be the ASP.NET framework hosted on Amazon Web Services.  The client gave full flexibility for selecting the web-app development stack. The rationale for these components are the following: ASP.NET: ● Active code base, supported by Microsoft ● Readily available documentation ● Mature framework, (stable) ● Powered by C#, (the entire project team has some background in C programing) Amazon Web Services: ● Very popular, very flexible (offers instances for all popular OS’s and frameworks) ● Readily available documentation ● Trendy, good for resumes The management application will allow for the user to remotely manage the deployed Parking Stall Display and monitoring the devices, required by FR1-5. Further details of the web management design are outline in section 5. 2.2 Eleven-X DASS system The Eleven-X DASS system acts as a middleware proxy server between the remote LoRaWAN devices and our Management Application. LoRa based devices can be registered with the DASS. LoRa payloads transmitted by registered devices will be received and cached on the DASS proxy server. Applications can then query the DASS to pull payloads over the web or set up DASS to push payloads over the web to the 8  application. Likewise, payloads can be sent downstream to the remote devices.  An application can push payloads to the server where they are cached and can then be fetched or pushed to the desired remote device. This creates a black box interface between our management application and remote device’s.  As mentioned in section 1.3 the Eleven-X DASS system is currently used and deployed by UBC parking. Several LoRa gateways are set up around campus connected to the Eleven-X DASS over cellular. Using the DASS is a clear choice given the pre-existing infrastructure and use by UBC parking. This subsystem is needed for remote communication with our devices, which is required by FR1. 2.3 PlacePod Smart Parking Sensor The PlacePod Smart Parking Sensor is placed underneath a dynamic parking stall. It utilizes a geomagnetic sensor to detect if a car is parked above. This device does not directly connect to our Parking Display as it utilizes LoRaWAN as its form of networking. Detections are relayed from the PlacePod sensor to the Web App. UBC parking currently has PlacePod sensors deployed for car detection, so we have chosen to integrate these detectors into our system. This car detection functionality is required by FR3. 2.4 Arduino MKR WAN 1300: LoRa Handler, Temperature, and Accelerometer controller One of the biggest challenges to designing our system is power management, as the Parking Display is constrained to being powered autonomously. To design this system we are using the Arduino MKR WAN 1300 which is a very low powered microcontroller (<20 mA operating current) that has a built in LoRa module. However, the device is limited by its computing power. The MKR WAN 1300 will always be running in the system; its tasks include: ● Receiving and transmitting LoRa packets ● Detecting any tampering of the device through an accelerometer  9  2.5 DESPI-M02 Display Controller The DESPI-M02 display controller is used to store and update images on our e-paper display (e-paper will be used to display the parking restrictions; see section 3.3.5 for further details on the e-paper display). The board features an STM32 microcontroller which is used to drive the 2 quad SPI interfaces of the e-paper display. Additionally the board features 128MB external SPI flash chip which was utilized to store images on the device,  (up to 100 images). Images are preloaded onto the board over USB serial using an image loading script we developed. We went with the DESPI-M02 as it was the recommended development board by the e-paper manufacturer, (GooDisplay).                    10  3.  Parking Stall Display and Monitoring Device This section goes into further details of the Parking Stall Display design outlining: design requirements/rationale (3.1), system overview (3.2), component list/rationale (3.3) 3.1 Design Requirements/Rationale  ● Low powered: able to operate power autonomously off of a 20W solar panel ○  Solar panels larger than 20W are dimensionally large for a single stall ● Average power consumption of the device cannot be more than 0.8W ○ In shortest daylight conditions in Vancouver we can expect only 1-2 hours usable sunlight, i.e. direct sunlight. ​[10] ● Ability to update and display parking restrictions autonomously ○ FR1,2 ● Ability to detect parked cars at stall ○ FR,3 ● Ability to detect vehicle impacts with the sign ○ FR4 ● Enclosure must be rated IP65 to protect against rain, dust, wind and snow. ○ NFR1           11  3.2 Overview    Figure 3.1 - Block Diagram System Overview  Above is the device topology diagram in figure 3.1. The system is powered by a lead-acid battery which is charged by the Solar Panel/Solar Charge Controller. The battery output is regulated by a DC-DC buck converter to step down to 5 V for the system. The Arduino MRK1300 is always be running, its functionality is outlined in section 2.4. Note the Arduino controls the power to the DESPI-M02 display controller which will only run to update the display,  (e-Paper does not need power to hold a still image). 3.3 Components List  The following section provides details and justification of the parts that were chosen for the device. The quantity of each part per device is noted in the headings. 12  3.3.1 Arduino MKR WAN 1300​[1]​ (x1) Functionality: ​handles LoRaWAN and device side management. ●  A major design choice was LTE vs LoRaWAN, this decision making was highlighted in section 1.3 LoRa. The Arduino MKR WAN 1300 features a built in LoRaWAN module to ease prototyping. ● The arduino MKR series microcontrollers are extremely low powered as it idles at 20mA  (at 3.3V), thus was chosen to help meet the projects low power constraint. ● Arduino devices simplify and accelerate microcontroller prototyping with it’s extensive, easy to use and well supported libraries. Thus we choice to use Arduino given the 8 month timeframe of the project. 3.3.2 GooDisplay 12.48” Color Large E-Paper Screen ​[8]​  (x1) / GooDisplay Communication Board Demo Kit Adapter for 12.48” E-paper Display​[9]​  (x1) Functionality: ​Display parking restrictions at stall. ● Implement the project’s functional requirement to display parking restrictions. ● Meet the project’s low power constraint; this e-epaper display consumes around 0.045W of power to change the display and requires no power to sustain an image. Thus due to the static display nature of our project this display was chosen over other display options such as LED matrix displays and LCD displays which require constant power to display an image. 3.3.3 DESPI-M02 Functionality: ​Drive the e-paper display and store images ● We went with the DESPI-M02 as it was the recommended development board by GooDisplay.  13   3.3.4 LM35 Temperature Sensor (x1) Functionality: ​ Monitor temperature of the device. The LM35 Temperature sensor is used to monitor the temperature of the device enclosure. This will work in conjunction with the Arduino to ensure that when the temperature is below 0 degrees an image will be uploaded to the display twice to prevent image ghosting (remains of the previous image). 3.3.5 ADLX345 Accelerometer (x1) Functionality: ​Detect any tampering with the device. The ADLX345 Accelerometer sensor will be used with the Arduino MKR WAN 1300 to continuously monitor the device enclosure movement. In the event that a car hits the pole on which the device is mounted or someone is tampering with the device, notifications will be sent to the administrator. This device consumes 58µW when in measurement mode and needs to be powered all the time so that any tampering with the device can be constantly monitored. 3.3.6 Four Channel-Optical-Isolated-Trigger (x1) Functionality:​ Interface to control power of the DESPI-M20. The Four Channel-Optical-Isolated-Trigger will be used by the Arduino to control the input power to the DESPI-M20 display controller. These are the components that consume the most power in the system and will only be used when needed. Note this particular relay switch was selected because its I/O on range accepts 3.3V as ‘ON’ which is the output voltage of the I/O pin in On state of the Arduino MKR 1300. 14   3.3.7 Lead-Acid Battery (x1) Functionality:​ Power the system. We decided to go with lead-acid batteries as our client has an abundant supply of these batteries. We are using a 12V, 7.0Ah battery which should be more than enough to power our system 24/7, (see our power budget in section 4) 3.3.8 MP1584 DC-DC Buck Step Down Converter Functionality:​ Step down the battery output voltage to 5V. We needed to step down our battery output voltage from 12V down to 5V. Buck converters are the most efficient way to step down a DC voltage. 3.3.9 20W Solar Panel/GENASUN GV-4 Solar Panel Control Functionality:​ Recharge the devices battery This solar setup was provided by our client. A 20W panel is more than enough to keep our battery charged, and hence keep our device running continuously (see our power budget in section 4). 3.4 Housing Design  The parking stall display is to be housed in an adapted off-the-shelf casing to help meet our unique size and weatherproofing requirements. The materials chosen for the housing are outlined below:  ● PVC casing ○ PVC casing (JB12126 PVC box)​ ​rated to IP66 was chosen as it is an off the shelf solution that has already been validated for weatherproofing. ● Acrylic display cover 15  ○ Acrylic was chosen for the display cover as it is low glare and UV resistant making it perfect for outdoor display applications.  All of the casing materials were chosen to meet the project requirement of being weatherproof up to IP65. A rating of IP65 indicates that the casing must be completely protected against dust and that it must be resistant to a water jet with a pressure of 30 kPa, at a distance of 3m, for 15 minutes.  The housing consists of an aluminum faceplate with an acrylic screen cover set into the centre to protect the e-Paper display. A PVC box sits on the back of the faceplate, connected to the acrylic screen cover, to house all of the electrical components for the device.              16  4 Power 4.1 Power Budget Due to the project goal which states the signs must be stand alone units and C4 which states the system must be self-powered, the device will be solar powered and therefore cannot consume more than 20W per day.   4.2 Measured Power Consumption  Scenario  Time (hr)   Current (A)  Power(W) 5 V system IDLE *  23.8  0.04   0.20 Update Screen  0.2 **  0.20   1 Average Per Hour  1  0.06  0.3  Daily power consumption = (23.8 x 0.2) + (0.2 x 1) = 4.96 Wh Assumptions * LoRaWAN module transmitting and receiving consumption are negligible compared to IDLE therefore are not considered on their own  ** The update screen time was calculated as follows: screen updates take 30 seconds, and assume screen updates once an hour (this is a very large assumption), thus hours =  (30 seconds / 3600 seconds/hr) * 24 hr = 0.2 hr  17  4.3 Power Analysis Given our worst case scenario of only 2 hours of usable sunlight in vancouver ​[5]​ and 15% solar panel efficiency ​[6]​ our panel should charge our battery: Charged Watts/per day =  2 Hours * 20W * 0.15 = 6Wh This value exceeds our absolute worst case scenario power consumption of 4.96 Wh.  Additionally, the battery that we are using is rated at 7Ah (84Wh, 50.4Wh effective considering worst case discharge) fully charged, thus based off our calculated worst case scenario average power consumption our system can run for ((84Wh*0.6)/0.3W) 168 hours straight without a charge. This is equivalent to 7 days.                          18  5 Web Application This section details the requirements and tools used to develop the web application that UBC parking will use to control and monitor the displays. 5.1 Design Requirements  The following are design requirements for the web application as identified by the team:  1. Device list views. 2. Stall management a. Add/Delete b. Set display and restrictions 3. Scale to handle unlimited number of stalls. 4. Hosted on AWS  5. Transferable to UBC server after the project is finished An overview of the web application system can be seen in figure 5.1.  Figure 5.1 - Components of Web Application 19  5.2 Web Application Components Amazon Web Services ​ was chosen to host our web application. This decision was made because it: ● Satisfies web application design requirement 4 that the web application must be hosted on AWS. ● Implements design requirement 5 to be transferable to UBC server after the project is finished  UBC can set up a server to host the web application, but due to administrative oversight and approval timelines this option was negated as delays would have disrupted the project’s timeline.  ASP.NET ​ was the web framework chosen to implement the application because: ● Implements design requirements 1-6. ● Documentation readily available. ● Smaller learning curve, which allows the team to quickly learn and use the framework.  An alternative that we looked at was using React for the frontend and Node.js for the backend.  This was decided against this as there were concerns with the learning curve of React. 5.3 Wireframes for Web Application Code for the web application can be found on github at: https://github.com/acsikos/Dynamic-Parking-Web-Application.git   20   Figure 5.1 - Page 1: Stall List  1. Header bar provides links to the other pages 2. Create New button allows you to add a new stall 3. Filter search options.  Options to filter search such as “occupied/vacant”, “Alert”, “Restrictions”, etc. 4. Device ID column gives the device’s ID used to identify the device on elevenX 5. Last Check-in column shows the last time the web application received a check-in from the stall 6. Status column shows the stall’s status of the stall occupied/Empty  7. Displayed Restriction column shows the current restriction the stall is displaying 8. Location column shows where the stall is located 9. Group column that displays the stall’s group 10. Alert column indicates whether or not the stall needs attention 11. Edit button to make changes to the stall 12. Details button opens more details about the stall 13. Delete button removes the stall  14. Change restriction takes the user to the Change Restriction Page  21  Figure 5.2 - Page 2: Restriction List 15. Add a customized restriction to reserve a stall for a given licence plate 16. Selection buttons that submit the restriction change to the stall  17. Image of the displayed restriction 18. Clear the display  Figure 5.3 - Page 3: Add New Stall 19. Device ID which represents the ID of the arduino of the stall 20.PlacePod ID which represents the ID of the PlacePod of the stall 22  21. Location where the stall is located 22.Group that the stall is in 23.Create the stall Figure 5.4 - Page 4: About  4. Displays a user manual of the web application  Figure 5.5 - Page 5: Contact   5. Displays contact information of the web developers   23   6 Software System This section provides high level flow diagrams of software functionality needed to achieve functional requirements of the system.  6.1 Downstream Payload Flow                                                               ​       Figure 6.1: Downstream Payload Flow Figure 6.1 shows the downstream flow of data from the web app to the e-paper display. First, from the web app, a packet with a desired command is stored in a JSON object and pushed to the Eleven-X DASS through a HTTPS request. The end device is specified by a DEVEUI which is unique to each deployed device. This DEVEUI is included in the path of the HTTPS request. Next, the packet is forwarded from the DASS to a LoRa gateway where the packet is then transmitted over LoRaWAN. The LoRa packet is received by the Arduino MKR with the specified DEVEUI and decoded by the LoRa handler, (for this example the request is to display a desired image which is currently stored on the DESPI M02). The Arduino powers the  DESPI M02 and transmits the image number to be displayed over a USART connection between the 2 devices. The DESPI M02 then reads a single row (163 bytes) of the desired image at a time and writes it to one of the 2 quad SPI interface (each quad spi controls a half of the display). Upon writing the entire image to the display driver, an update command is passed to the display which then updates it to the new image. 24  6.2 Arduino Initiation Algorithm //Start Device Display(CONNECTING)           // DIsplay Connecting on e-paper display Modem.start()           // Start LoRa Modem  While(Modem fails to connect)    // Check if LoRa modem connected to Eleven-X  wait(30s)         //If modem failed to connect wait restart and try again Modem.Restart()  if(Modem connects) //If successfully connected Display (HANDICAP)         // Default Parking Sign  6.3 Arduino Flow Cycle Figure 6.3 shows the Flow Cycle of the Arduino, which is going to be our hub for all the communication and sensor data processing.                   Figure 6.3 Flow Cycle of the Arduino 25  References  [1]"Arduino MKR WAN 1300 (LoRa connectivity)", ​Store.arduino.cc​, 2018. [Online]. Available: https://store.arduino.cc/usa/mkr-wan-1300. [Accessed: 25- Nov- 2018]   [2]"---e-paper display - GOOD DISPLAY", ​E-paper-display.com ​, 2018. [Online]. Available: http://www.e-paper-display.com/download_detail/downloadsId=693.html. [Accessed: 25- Nov- 2018]  [3]​Amazon.ca​, 2018. [Online]. Available: https://www.amazon.ca/GooDisplay-Paper-Screen-Display-Electronic/dp/B07JG1TN5B/ref=sr_1_2?s=industrial&ie=UTF8&qid=1543125424&sr=1-2&keywords=GooDisplay. [Accessed: 25- Nov- 2018]  [4]​Amazon.ca ​, 2018. [Online]. Available: https://www.amazon.ca/GooDisplay-Paper-Screen-Display-Electronic/dp/B07JG1TN5B/ref=sr_1_2?s=industrial&ie=UTF8&qid=1543125424&sr=1-2&keywords=GooDisplay. [Accessed: 25- Nov- 2018]  [5] Current Results, 2018 [Online]. Available: https://www.currentresults.com/Weather/Canada/British-Columbia/sunshine-average-december.php [Accessed: 10- Feb - 2019]  [6] S. Murmson, “The Average Photovoltaic System Efficiency,” Sciencing, 02-Mar-2019. [Online]. Available: https://sciencing.com/average-photovoltaic-system-efficiency-7092.html. [Accessed: 04-Apr-2019].  26  UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report Design Document for Dynamic Parking Project: User Manual Display ControllerSaurav Choudhury, Anthony Csikos, Graham Judd, Alicia O’Sullivan, Nicholas Windt University of British Columbia ELEC 491 Themes: Transportation, Community, Wellbeing April 4, 2019 Disclaimer: “UBC SEEDS Sustainability Program provides students with the opportunity to share the findings of their studies, as well as their opinions, conclusions and recommendations with the UBC community. The reader should bear in mind that this is a student research project/report and is not an official document of UBC. Furthermore, readers should bear in mind that these reports may not reflect the current status of activities at UBC. We urge you to contact the research persons mentioned in a report or the SEEDS Sustainability Program representative about the current status of the subject matter of a project/report”. How To Load Images  Creating Images Compatible with the Display on Windows  1. Open microsoft paint. 2. Import the image you would like to load to the display.  3. Click resize image.  4. A pop up window to resize the window will appear, set the horizontal component to 1304 and vertical component to 984. Make sure to uncheck maintain aspect ratio.  5. Now save the image as a BMP to a folder where you are storing all the image for the display, save the image as a Monochrome Bitmap.     6. You will get a warning saying the image will lose colour quality, this is fine as we are converting the image to be just black and white.   Loading Images   1.  Prepare a folder with all the images you would like to load to your device, also in this folder create a list of the images name, without the file extension (.bmp), separate each image name with a new line.          2. Open up the display device and disconnect the main circuit from the battery. Then connect a USB cable to the DESPI-M02 board, ensure switch on the board is flipped to on.   3. Check what com port the device is connected to write by opening device manager and checking under ports          4. Open the send_image.py script in a text editor, update ​ImageDirectory​, ​image file​ and ​com port​ at the top of the file.  ImageDirectory​, should be the full path to the folder location of the images on you would like to load to the device, put a double backslash between locations as in the image below. ImagesFile, ​should be the name of the file which you listed the images you would like to load note, this should be in the same directory as your images. Com, ​Set this to the com port you just looked up.   5. In order to run the script you need to have python 2.7 installed, additionally you might need to add packages for numpy and serial, do this using pip.  6.  Go to the folder where the send_image.py is in a command terminal, enter, ​python send_image.py. ​This will start the script, if you re loading several images it could take over 20 minutes for it to finish   Limitations 1. If you want to add an image/images to ones already loaded on the device you need to reload all images, ones already on the device as well as the new ones you would like to order.  2. The letter/number images need to be loaded on the device to display serial plate number these need to be loaded only once and do not need to be reloaded when images are added to the device. 3. The device is currently programed to only hold 20 images, (not including the letters or numbers).   UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report         Design Document for Dynamic Parking Project Saurav Choudhury, Anthony Csikos, Graham Judd, Alicia O’Sullivan, Nicholas Windt University of British Columbia ELEC 491 Themes: Transportation, Community, Wellbeing April 4, 2019         Disclaimer: “UBC SEEDS Sustainability Program provides students with the opportunity to share the findings of their studies, as well as their opinions, conclusions and recommendations with the UBC community. The reader should bear in mind that this is a student research project/report and is not an official document of UBC. Furthermore, readers should bear in mind that these reports may not reflect the current status of activities at UBC. We urge you to contact the research persons mentioned in a report or the SEEDS Sustainability Program representative about the current status of the subject matter of a project/report”.   Terms Appendix:   Term  Definition User  UBC Parking Admin Client   UBC Parking Device   Parking stall display and Monitoring Device FR   Functional Requirement, (outlined in requirements documentation) NFR  Non Functional Requirement, (outlined in requirements documentation) C  Constraint,  (outlined in requirements documentation) IP65  IP rated as "dust tight" and protected against water projected from a nozzle LoRaWAN  Long Range Wide Area Network DEVEUI  Unique device ID used to communicate with LoRa devices SPI  Serial Peripheral Interface  USART  Universal Synchronous/Asynchronous Receiver/Transmitter    1   Content  1. High Level System Description 5 1.1 High Level System 5 1.2 Web Management System 6 1.2 Parking Stall Display and Monitoring Device 6 1.3 LoRa 6 2. Low Level System Description 8 2.1 Management Application 9 2.2 Eleven-X DASS system 9 2.3 PlacePod Smart Parking Sensor 10 2.4 Arduino MKR WAN 1300: LoRa Handler, Temperature, and Accelerometer controller 10 2.5 DESPI-M02 Display Controller 11 3.  Parking Stall Display and Monitoring Device 11 3.1 Design Requirements/Rationale 11 3.2 Overview 12 3.3 Components List 12 3.3.1 Arduino MKR WAN 1300[1] (x1) 12 3.3.2 GooDisplay 12.48” Color Large E-Paper Screen[8]  (x1) / GooDisplay Communication Board Demo Kit Adapter for 12.48” E-paper Display[9]  (x1) 13 3.3.3 DESPI-M02 13 3.3.4 LM35 Temperature Sensor (x1) 13 3.3.5 ADLX345 Accelerometer (x1) 14 3.3.6 Four Channel-Optical-Isolated-Trigger (x1) 14 3.3.7 Lead-Acid Battery (x1) 14 3.4 Housing Design 15 4 Power 16 4.1 Power Budget 16 4.2 Approximate Power Consumption of the Circuit 16 5 Web Application 17 5.1 Design Requirements 17 5.2 Web Application Components 18 5.3 Wireframes for Web Application 19 2  6 Software System 22 6.1 Downstream Payload Flow 22 6.2 Arduino Flow Cycle 22 6.3 Car Detection Flow 24 References 25    3  The purpose of this document is to specify and justify the design choices made in order to successfully complete the prototype/system.   1. High Level System Description 1.1 High Level System Based on client requirements the system solution has been broken down into two main components:  ● The Web Management System, from which the user can remotely monitor the occupancy, change the display, and in general manage the stalls. The communication link between the web app and the physical display and monitoring devices will be over LoRaWAN, a wide area network technology intended for low powered IoT (Internet of Things) devices.  ● The Parking Stall Display and PlacePod (a monitoring device installed in the ground of the parking stall) work together to display various parking restrictions according to the need. The stall also transmits parking data over LoRaWAN, in order for the UBC Parking Administration to view.  ● Figure 1.1 below shows a diagram of this high level system.    Figure 1.1 - High Level System Diagram 4  1.2 Web Management System As previously explained, the web management system will be the interface that the user, UBC Parking Services, will use to manage the dynamic parking stalls. This system will communicate remotely with the Parking Stall and Monitoring Devices to update, set stall restrictions, and receive stall data. The core features include: ● Homepage to display all key stall information so the client can monitor the stalls ● Manual and automatic changes to stall restrictions ● Pre-loaded images and custom license plate restriction options 1.2 Parking Stall Display and Monitoring Device The Parking Stall Display and Monitoring Device will be the end-system device present at each individual dynamic stall. Its function is to display parking restrictions and monitor the stall. Core features include: ● Displaying configured parking restriction ● Detecting cars parked in the stall ● Detecting vehicle impacts with sign post 1.3 LoRa LoRa (Long Range) is a long range digital wireless communication technology which utilizes the license-free sub-gigahertz radio bands (915 MHz in North America). LoRaWAN (Long Range Wide Area Network) is the network over which LoRa operates. LoRaWAN enables transmission over very long distances.   LoRa was rated as the best choice for wireless communication in our system design over our second choice, cellular LTE, for the following reasons: 5  ● Low powered - LoRa radio power consumption is much less than LTE cellular. Additionally different classifications of LoRa devices can be implemented, through radio sleep cycles, for even better power consumption.  ● Inexpensive - LoRa utilizes unlicensed radio bands so no subscriptions are needed for network use; this scales much better cost wise than LTE ● Infrastructure at UBC -  Our client currently has a LoRa system set-up for car detection at parking stalls around UBC. This system features deployed gateways connected to the Eleven-X DASS which acts as middleware between LoRaWAN and the internet. This provides us with a trusted, proven and already deployed sub system to ease integration of the Web Management System and the Parking Stall Display and Monitoring Device.  These advantages over LTE do come at cost when it comes to bandwidth. In practice, LoRaWAN payloads should be limited to a maximum size of only 8 bytes and LoRa enabled devices should not be transmitting more than once every two minutes. Infringing these guidelines can lead to network congestion and dropped packets. For our system high bandwidth is not needed as only small amounts of data need to be transmitted, (~1-7 bytes) at intervals generally greater than 5 minutes.    6  2. Low Level System Description    Figure 2.1 - System Level UML Referencing the System Level UML (figure 2.1), the web management system is broken down into 2 main subsystems, i.e. the Management Application (section 2.1) and the Eleven-X DASS system (section 2.2). The Parking Stall Display and Monitoring device is broken down into 3 main subsystems i.e. Arduino MKR WAN 1300, the PlacePod Smart 7  Parking Sensor and the STM32 Display Controller. The rationale and function of these subsystems are described in detail in the following sections: 2.1 Management Application The management application is the interface the user will use to manage deployed dynamic parking stalls. The features and functionality of this subsystem are summarized well by the Web Management System section above (section 1.2). The engine for our web application will be the ASP.NET framework hosted on Amazon Web Services.  The client gave full flexibility for selecting the web-app development stack. The rationale for these components are the following: ASP.NET: ● Active code base, supported by Microsoft ● Readily available documentation ● Mature framework, (stable) ● Powered by C#, (the entire project team has some background in C programing) Amazon Web Services: ● Very popular, very flexible (offers instances for all popular OS’s and frameworks) ● Readily available documentation ● Trendy, good for resumes The management application will allow for the user to remotely manage the deployed Parking Stall Display and monitoring the devices, required by FR1-5. Further details of the web management design are outline in section 5. 2.2 Eleven-X DASS system The Eleven-X DASS system acts as a middleware proxy server between the remote LoRaWAN devices and our Management Application. LoRa based devices can be registered with the DASS. LoRa payloads transmitted by registered devices will be received and cached on the DASS proxy server. Applications can then query the DASS to pull payloads over the web or set up DASS to push payloads over the web to the 8  application. Likewise, payloads can be sent downstream to the remote devices.  An application can push payloads to the server where they are cached and can then be fetched or pushed to the desired remote device. This creates a black box interface between our management application and remote device’s.  As mentioned in section 1.3 the Eleven-X DASS system is currently used and deployed by UBC parking. Several LoRa gateways are set up around campus connected to the Eleven-X DASS over cellular. Using the DASS is a clear choice given the pre-existing infrastructure and use by UBC parking. This subsystem is needed for remote communication with our devices, which is required by FR1. 2.3 PlacePod Smart Parking Sensor The PlacePod Smart Parking Sensor is placed underneath a dynamic parking stall. It utilizes a geomagnetic sensor to detect if a car is parked above. This device does not directly connect to our Parking Display as it utilizes LoRaWAN as its form of networking. Detections are relayed from the PlacePod sensor to the Web App. UBC parking currently has PlacePod sensors deployed for car detection, so we have chosen to integrate these detectors into our system. This car detection functionality is required by FR3. 2.4 Arduino MKR WAN 1300: LoRa Handler, Temperature, and Accelerometer controller One of the biggest challenges to designing our system is power management, as the Parking Display is constrained to being powered autonomously. To design this system we are using the Arduino MKR WAN 1300 which is a very low powered microcontroller (<20 mA operating current) that has a built in LoRa module. However, the device is limited by its computing power. The MKR WAN 1300 will always be running in the system; its tasks include: ● Receiving and transmitting LoRa packets ● Detecting any tampering of the device through an accelerometer  9  2.5 DESPI-M02 Display Controller The DESPI-M02 display controller is used to store and update images on our e-paper display (e-paper will be used to display the parking restrictions; see section 3.3.5 for further details on the e-paper display). The board features an STM32 microcontroller which is used to drive the 2 quad SPI interfaces of the e-paper display. Additionally the board features 128MB external SPI flash chip which was utilized to store images on the device,  (up to 100 images). Images are preloaded onto the board over USB serial using an image loading script we developed. We went with the DESPI-M02 as it was the recommended development board by the e-paper manufacturer, (GooDisplay).                    10  3.  Parking Stall Display and Monitoring Device This section goes into further details of the Parking Stall Display design outlining: design requirements/rationale (3.1), system overview (3.2), component list/rationale (3.3) 3.1 Design Requirements/Rationale  ● Low powered: able to operate power autonomously off of a 20W solar panel ○  Solar panels larger than 20W are dimensionally large for a single stall ● Average power consumption of the device cannot be more than 0.8W ○ In shortest daylight conditions in Vancouver we can expect only 1-2 hours usable sunlight, i.e. direct sunlight. ​[10] ● Ability to update and display parking restrictions autonomously ○ FR1,2 ● Ability to detect parked cars at stall ○ FR,3 ● Ability to detect vehicle impacts with the sign ○ FR4 ● Enclosure must be rated IP65 to protect against rain, dust, wind and snow. ○ NFR1           11  3.2 Overview    Figure 3.1 - Block Diagram System Overview  Above is the device topology diagram in figure 3.1. The system is powered by a lead-acid battery which is charged by the Solar Panel/Solar Charge Controller. The battery output is regulated by a DC-DC buck converter to step down to 5 V for the system. The Arduino MRK1300 is always be running, its functionality is outlined in section 2.4. Note the Arduino controls the power to the DESPI-M02 display controller which will only run to update the display,  (e-Paper does not need power to hold a still image). 3.3 Components List  The following section provides details and justification of the parts that were chosen for the device. The quantity of each part per device is noted in the headings. 12  3.3.1 Arduino MKR WAN 1300​[1]​ (x1) Functionality: ​handles LoRaWAN and device side management. ●  A major design choice was LTE vs LoRaWAN, this decision making was highlighted in section 1.3 LoRa. The Arduino MKR WAN 1300 features a built in LoRaWAN module to ease prototyping. ● The arduino MKR series microcontrollers are extremely low powered as it idles at 20mA  (at 3.3V), thus was chosen to help meet the projects low power constraint. ● Arduino devices simplify and accelerate microcontroller prototyping with it’s extensive, easy to use and well supported libraries. Thus we choice to use Arduino given the 8 month timeframe of the project. 3.3.2 GooDisplay 12.48” Color Large E-Paper Screen ​[8]​  (x1) / GooDisplay Communication Board Demo Kit Adapter for 12.48” E-paper Display​[9]​  (x1) Functionality: ​Display parking restrictions at stall. ● Implement the project’s functional requirement to display parking restrictions. ● Meet the project’s low power constraint; this e-epaper display consumes around 0.045W of power to change the display and requires no power to sustain an image. Thus due to the static display nature of our project this display was chosen over other display options such as LED matrix displays and LCD displays which require constant power to display an image. 3.3.3 DESPI-M02 Functionality: ​Drive the e-paper display and store images ● We went with the DESPI-M02 as it was the recommended development board by GooDisplay.  13   3.3.4 LM35 Temperature Sensor (x1) Functionality: ​ Monitor temperature of the device. The LM35 Temperature sensor is used to monitor the temperature of the device enclosure. This will work in conjunction with the Arduino to ensure that when the temperature is below 0 degrees an image will be uploaded to the display twice to prevent image ghosting (remains of the previous image). 3.3.5 ADLX345 Accelerometer (x1) Functionality: ​Detect any tampering with the device. The ADLX345 Accelerometer sensor will be used with the Arduino MKR WAN 1300 to continuously monitor the device enclosure movement. In the event that a car hits the pole on which the device is mounted or someone is tampering with the device, notifications will be sent to the administrator. This device consumes 58µW when in measurement mode and needs to be powered all the time so that any tampering with the device can be constantly monitored. 3.3.6 Four Channel-Optical-Isolated-Trigger (x1) Functionality:​ Interface to control power of the DESPI-M20. The Four Channel-Optical-Isolated-Trigger will be used by the Arduino to control the input power to the DESPI-M20 display controller. These are the components that consume the most power in the system and will only be used when needed. Note this particular relay switch was selected because its I/O on range accepts 3.3V as ‘ON’ which is the output voltage of the I/O pin in On state of the Arduino MKR 1300. 14   3.3.7 Lead-Acid Battery (x1) Functionality:​ Power the system. We decided to go with lead-acid batteries as our client has an abundant supply of these batteries. We are using a 12V, 7.0Ah battery which should be more than enough to power our system 24/7, (see our power budget in section 4) 3.3.8 MP1584 DC-DC Buck Step Down Converter Functionality:​ Step down the battery output voltage to 5V. We needed to step down our battery output voltage from 12V down to 5V. Buck converters are the most efficient way to step down a DC voltage. 3.3.9 20W Solar Panel/GENASUN GV-4 Solar Panel Control Functionality:​ Recharge the devices battery This solar setup was provided by our client. A 20W panel is more than enough to keep our battery charged, and hence keep our device running continuously (see our power budget in section 4). 3.4 Housing Design  The parking stall display is to be housed in an adapted off-the-shelf casing to help meet our unique size and weatherproofing requirements. The materials chosen for the housing are outlined below:  ● PVC casing ○ PVC casing (JB12126 PVC box)​ ​rated to IP66 was chosen as it is an off the shelf solution that has already been validated for weatherproofing. ● Acrylic display cover 15  ○ Acrylic was chosen for the display cover as it is low glare and UV resistant making it perfect for outdoor display applications.  All of the casing materials were chosen to meet the project requirement of being weatherproof up to IP65. A rating of IP65 indicates that the casing must be completely protected against dust and that it must be resistant to a water jet with a pressure of 30 kPa, at a distance of 3m, for 15 minutes.  The housing consists of an aluminum faceplate with an acrylic screen cover set into the centre to protect the e-Paper display. A PVC box sits on the back of the faceplate, connected to the acrylic screen cover, to house all of the electrical components for the device.              16  4 Power 4.1 Power Budget Due to the project goal which states the signs must be stand alone units and C4 which states the system must be self-powered, the device will be solar powered and therefore cannot consume more than 20W per day.   4.2 Measured Power Consumption  Scenario  Time (hr)   Current (A)  Power(W) 5 V system IDLE *  23.8  0.04   0.20 Update Screen  0.2 **  0.20   1 Average Per Hour  1  0.06  0.3  Daily power consumption = (23.8 x 0.2) + (0.2 x 1) = 4.96 Wh Assumptions * LoRaWAN module transmitting and receiving consumption are negligible compared to IDLE therefore are not considered on their own  ** The update screen time was calculated as follows: screen updates take 30 seconds, and assume screen updates once an hour (this is a very large assumption), thus hours =  (30 seconds / 3600 seconds/hr) * 24 hr = 0.2 hr  17  4.3 Power Analysis Given our worst case scenario of only 2 hours of usable sunlight in vancouver ​[5]​ and 15% solar panel efficiency ​[6]​ our panel should charge our battery: Charged Watts/per day =  2 Hours * 20W * 0.15 = 6Wh This value exceeds our absolute worst case scenario power consumption of 4.96 Wh.  Additionally, the battery that we are using is rated at 7Ah (84Wh, 50.4Wh effective considering worst case discharge) fully charged, thus based off our calculated worst case scenario average power consumption our system can run for ((84Wh*0.6)/0.3W) 168 hours straight without a charge. This is equivalent to 7 days.                          18  5 Web Application This section details the requirements and tools used to develop the web application that UBC parking will use to control and monitor the displays. 5.1 Design Requirements  The following are design requirements for the web application as identified by the team:  1. Device list views. 2. Stall management a. Add/Delete b. Set display and restrictions 3. Scale to handle unlimited number of stalls. 4. Hosted on AWS  5. Transferable to UBC server after the project is finished An overview of the web application system can be seen in figure 5.1.  Figure 5.1 - Components of Web Application 19  5.2 Web Application Components Amazon Web Services ​ was chosen to host our web application. This decision was made because it: ● Satisfies web application design requirement 4 that the web application must be hosted on AWS. ● Implements design requirement 5 to be transferable to UBC server after the project is finished  UBC can set up a server to host the web application, but due to administrative oversight and approval timelines this option was negated as delays would have disrupted the project’s timeline.  ASP.NET ​ was the web framework chosen to implement the application because: ● Implements design requirements 1-6. ● Documentation readily available. ● Smaller learning curve, which allows the team to quickly learn and use the framework.  An alternative that we looked at was using React for the frontend and Node.js for the backend.  This was decided against this as there were concerns with the learning curve of React. 5.3 Wireframes for Web Application Code for the web application can be found on github at: https://github.com/acsikos/Dynamic-Parking-Web-Application.git   20   Figure 5.1 - Page 1: Stall List  1. Header bar provides links to the other pages 2. Create New button allows you to add a new stall 3. Filter search options.  Options to filter search such as “occupied/vacant”, “Alert”, “Restrictions”, etc. 4. Device ID column gives the device’s ID used to identify the device on elevenX 5. Last Check-in column shows the last time the web application received a check-in from the stall 6. Status column shows the stall’s status of the stall occupied/Empty  7. Displayed Restriction column shows the current restriction the stall is displaying 8. Location column shows where the stall is located 9. Group column that displays the stall’s group 10. Alert column indicates whether or not the stall needs attention 11. Edit button to make changes to the stall 12. Details button opens more details about the stall 13. Delete button removes the stall  14. Change restriction takes the user to the Change Restriction Page  21  Figure 5.2 - Page 2: Restriction List 15. Add a customized restriction to reserve a stall for a given licence plate 16. Selection buttons that submit the restriction change to the stall  17. Image of the displayed restriction 18. Clear the display  Figure 5.3 - Page 3: Add New Stall 19. Device ID which represents the ID of the arduino of the stall 20.PlacePod ID which represents the ID of the PlacePod of the stall 22  21. Location where the stall is located 22.Group that the stall is in 23.Create the stall Figure 5.4 - Page 4: About  4. Displays a user manual of the web application  Figure 5.5 - Page 5: Contact   5. Displays contact information of the web developers   23   6 Software System This section provides high level flow diagrams of software functionality needed to achieve functional requirements of the system.  6.1 Downstream Payload Flow                                                               ​       Figure 6.1: Downstream Payload Flow Figure 6.1 shows the downstream flow of data from the web app to the e-paper display. First, from the web app, a packet with a desired command is stored in a JSON object and pushed to the Eleven-X DASS through a HTTPS request. The end device is specified by a DEVEUI which is unique to each deployed device. This DEVEUI is included in the path of the HTTPS request. Next, the packet is forwarded from the DASS to a LoRa gateway where the packet is then transmitted over LoRaWAN. The LoRa packet is received by the Arduino MKR with the specified DEVEUI and decoded by the LoRa handler, (for this example the request is to display a desired image which is currently stored on the DESPI M02). The Arduino powers the  DESPI M02 and transmits the image number to be displayed over a USART connection between the 2 devices. The DESPI M02 then reads a single row (163 bytes) of the desired image at a time and writes it to one of the 2 quad SPI interface (each quad spi controls a half of the display). Upon writing the entire image to the display driver, an update command is passed to the display which then updates it to the new image. 24  6.2 Arduino Initiation Algorithm //Start Device Display(CONNECTING)           // DIsplay Connecting on e-paper display Modem.start()           // Start LoRa Modem  While(Modem fails to connect)    // Check if LoRa modem connected to Eleven-X  wait(30s)         //If modem failed to connect wait restart and try again Modem.Restart()  if(Modem connects) //If successfully connected Display (HANDICAP)         // Default Parking Sign  6.3 Arduino Flow Cycle Figure 6.3 shows the Flow Cycle of the Arduino, which is going to be our hub for all the communication and sensor data processing.                   Figure 6.3 Flow Cycle of the Arduino 25  References  [1]"Arduino MKR WAN 1300 (LoRa connectivity)", ​Store.arduino.cc​, 2018. [Online]. Available: https://store.arduino.cc/usa/mkr-wan-1300. [Accessed: 25- Nov- 2018]   [2]"---e-paper display - GOOD DISPLAY", ​E-paper-display.com ​, 2018. [Online]. Available: http://www.e-paper-display.com/download_detail/downloadsId=693.html. [Accessed: 25- Nov- 2018]  [3]​Amazon.ca​, 2018. [Online]. Available: https://www.amazon.ca/GooDisplay-Paper-Screen-Display-Electronic/dp/B07JG1TN5B/ref=sr_1_2?s=industrial&ie=UTF8&qid=1543125424&sr=1-2&keywords=GooDisplay. [Accessed: 25- Nov- 2018]  [4]​Amazon.ca ​, 2018. [Online]. Available: https://www.amazon.ca/GooDisplay-Paper-Screen-Display-Electronic/dp/B07JG1TN5B/ref=sr_1_2?s=industrial&ie=UTF8&qid=1543125424&sr=1-2&keywords=GooDisplay. [Accessed: 25- Nov- 2018]  [5] Current Results, 2018 [Online]. Available: https://www.currentresults.com/Weather/Canada/British-Columbia/sunshine-average-december.php [Accessed: 10- Feb - 2019]  [6] S. Murmson, “The Average Photovoltaic System Efficiency,” Sciencing, 02-Mar-2019. [Online]. Available: https://sciencing.com/average-photovoltaic-system-efficiency-7092.html. [Accessed: 04-Apr-2019].  26  UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report Design Document for Dynamic Parking Project: User Manual Display ControllerSaurav Choudhury, Anthony Csikos, Graham Judd, Alicia O’Sullivan, Nicholas Windt University of British Columbia ELEC 491 Themes: Transportation, Community, Wellbeing April 4, 2019 Disclaimer: “UBC SEEDS Sustainability Program provides students with the opportunity to share the findings of their studies, as well as their opinions, conclusions and recommendations with the UBC community. The reader should bear in mind that this is a student research project/report and is not an official document of UBC. Furthermore, readers should bear in mind that these reports may not reflect the current status of activities at UBC. We urge you to contact the research persons mentioned in a report or the SEEDS Sustainability Program representative about the current status of the subject matter of a project/report”. How To Load Images  Creating Images Compatible with the Display on Windows  1. Open microsoft paint. 2. Import the image you would like to load to the display.  3. Click resize image.  4. A pop up window to resize the window will appear, set the horizontal component to 1304 and vertical component to 984. Make sure to uncheck maintain aspect ratio.  5. Now save the image as a BMP to a folder where you are storing all the image for the display, save the image as a Monochrome Bitmap.     6. You will get a warning saying the image will lose colour quality, this is fine as we are converting the image to be just black and white.   Loading Images   1.  Prepare a folder with all the images you would like to load to your device, also in this folder create a list of the images name, without the file extension (.bmp), separate each image name with a new line.          2. Open up the display device and disconnect the main circuit from the battery. Then connect a USB cable to the DESPI-M02 board, ensure switch on the board is flipped to on.   3. Check what com port the device is connected to write by opening device manager and checking under ports          4. Open the send_image.py script in a text editor, update ​ImageDirectory​, ​image file​ and ​com port​ at the top of the file.  ImageDirectory​, should be the full path to the folder location of the images on you would like to load to the device, put a double backslash between locations as in the image below. ImagesFile, ​should be the name of the file which you listed the images you would like to load note, this should be in the same directory as your images. Com, ​Set this to the com port you just looked up.   5. In order to run the script you need to have python 2.7 installed, additionally you might need to add packages for numpy and serial, do this using pip.  6.  Go to the folder where the send_image.py is in a command terminal, enter, ​python send_image.py. ​This will start the script, if you re loading several images it could take over 20 minutes for it to finish   Limitations 1. If you want to add an image/images to ones already loaded on the device you need to reload all images, ones already on the device as well as the new ones you would like to order.  2. The letter/number images need to be loaded on the device to display serial plate number these need to be loaded only once and do not need to be reloaded when images are added to the device. 3. The device is currently programed to only hold 20 images, (not including the letters or numbers).   UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report Design Document for Dynamic Parking Project: User Manual Web ApplicationSaurav Choudhury, Anthony Csikos, Graham Judd, Alicia O’Sullivan, Nicholas Windt University of British Columbia ELEC 491 Themes: Transportation, Community, Wellbeing April 4, 2019 Disclaimer: “UBC SEEDS Sustainability Program provides students with the opportunity to share the findings of their studies, as well as their opinions, conclusions and recommendations with the UBC community. The reader should bear in mind that this is a student research project/report and is not an official document of UBC. Furthermore, readers should bear in mind that these reports may not reflect the current status of activities at UBC. We urge you to contact the research persons mentioned in a report or the SEEDS Sustainability Program representative about the current status of the subject matter of a project/report”. 1. The Home Page 3 2. Add a New Stall 5 3. Change Restrictions 10 4. Adding new images 11 This document contains important information on how to use the application. 1. The Home Page  The homepage displays all key information necessary to monitor the stalls and gives easy access to all the system controls including editing/deleting existing stalls, viewing additional stall information, creating new stalls, and changing restrictions on stalls.   Device Id:  Shows the unique ID used to establish a connection through the LoRa network with the sign.  Last Check In:  Displays the last time the device sent an update to Eleven-X and the web application. This should update every 2-3 minutes. If this field is not changing there is a problem the device that is preventing it from sending uplink message through the LoRa Network.  Status:  Shows if the stall is occupied or empty. Only empty stalls can have their restrictions changed.  Restriction:  This column shows the restrictions displayed on the various signs. Restrictions can be changed manually using the change restriction link. The web application also uses logic to automatically change empty stalls to handicap only parking whenever there is only one empty stall left in a group.  Location:  Shows the parking lot where the stall is installed.  Group:  Within a parking lot, stalls can be grouped together. This is used in the automatic allocation of handicap stalls.  Alert:  Shows the user if there are any problems with the display. There are 3 different items that may appear in this section:  1) None:  This indicates there are no issues with the display  2) ALERT:  This indicates the sign may have been damaged in someway. If hit with enough force, or when moved this alert will appear.  3) No Data:  This indicates there is no data in the Eleven-X system for the web app to retrieve. This may occur when the device is first registered or if the device has not been transmitting data to Eleven-X for a long period of time.    2. Add a New Stall  To add a new stall to the management system the device must first be added to the Eleven-X network and then to the web application. To add the device to Eleven-X open https://lora.eleven-x.com/welcome.html​ and log in using the UBC parking account. Once signed in navigate to Devices > Manage devices   From there click on  to open the add device form. This will open the following form. In this form you must fill out the DEVEUI for the sign and generate a 16-byte hexadecimal app key using ​https://www.random.org/bytes/​.   The DEVEUI allows to LoRa Network to communicate with the device and the app key allows for encryption/decryption of the data sent to and from the device.  Once the device has been successfully added to Eleven-X you will see it on the device list. From here you can also navigate to Action > View Data.   If the data sent up from the Arduino is 00: 68 69 then it has been correctly connected and can now be added on the management application.   From the homepage of the web application select , this will take you to the following page. All fields in this form must be filled out.   Device Id:  This must match the DEVEUI of the device that was registered with Eleven-X. This ID will be an 8-byte string and should contain only capital letters and numbers. Space and special characters are not allowed. This value is used by the application to communicate with the device.  Place Pod Id:  This value must match with the place pod vehicle detector present at the same stall as the device. This ID will be an 8-byte string and should contain only capital letters and numbers. Space and special characters are not allowed. This value is used by the application to communicate with the device.  Location:  This is used to identify the parking lot in which the device is located. This value should be a string between 2 and 60 characters long.   Group:  This is used to group stalls together within a parking lot and is used for automatic allocation of handicap stalls. This value should be a number.   3. Change Restrictions  There are two ways restrictions can be changed through the web application. The first way is done automatically by the application to ensure there is, whenever possible, an available handicap stall in every group, the second is to manually select the desired restriction.  For automatic allocation every minute the application will check to ensure there are available handicap stalls in each group. In the case there are nothing will change, in the case there are not the application will manually change the first empty stall in the group to be handicap. If there is only one available handicap stall in a group it cannot be change to a different restriction.  To manually change the restriction, from the homepage select “change restriction” for the stall you would like to edit. This will bring you to the following page. Here you have the option of selecting from one of the pre-loaded images or entering a custom license plate.  The restriction of an occupied stall cannot be changed. In addition, the restriction of the last available handicap stall cannot be changed. For the custom license plate the only acceptable characters are capital letters, numbers, and spaces. The license plate can at most be 8 characters.   4. Adding new images 1. To add new images to the device you must first follow the instructions outlined in the “How To Load Images” manual. Once these steps are completed you will need to add a new button to the web application.   2. First, add a PNG image of the new restriction to the folder images located in the project folder > UbcParkingApp > wwwroot > images.  3. Next, open “~/Views/Stalls/ChangeRestriction.cshtml”. This is the HTML file that contains the code for the button. In this file, you will find code for the existing buttons:    To add another button these lines of code can be copy and pasted. You will need to change the ​value​ attribute, shown above on line 37. This is the name that will appear on the button and should describe the new image. In addition, the image source should be changed to match the new image name added in step 2. Once finished, save the file.  4. Now open “~/Controllers/StallsController.cs”. In this file, locate the ChangeRestriction POST method and navigate to line 314.   You must add a new ​else if​ statement for the new button/image added in steps 2&3. To do this, copy line 320 and paste in below line 320. In this new statement change the ​Restriction​ value in the quotation marks to match the value attribute you gave to the button in step 3.  5. Now the ​package​ value must also be changed. To do this, take the number assigned to the restriction on the device (the numbers 0-8 are already in use) and change it to HEX using ​https://www.online-toolz.com/tools/text-hex-convertor.php ​. Then take the HEX value and change it to Base64 using https://cryptii.com/pipes/base64-to-hex​. This Base64 value is the value that should be assigned to package. Save the file.  6. Run the program on your computer and check that the correct HEX value is being sent through to Eleven-X. To check the value, first change one of the stalls to the new restriction, then sign into ​https://lora.eleven-x.com/welcome.html​ and access the device (as described in section 2). The data enqueued by Eleven-X to the selected device should match the HEX value of the package.  7. Finally, re-publish the new code.  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            data-media="{[{embed.selectedMedia}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.18861.1-0387173/manifest

Comment

Related Items