UBC Undergraduate Research

Dynamic Parking Signage Project Goodwin-Wilson, Geoff; Cheng, Timothy; Cheung, Hiu Lok; He, Yuyang; West, Jared 2020-07-31

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


18861-Goodwin-Wilson_G_et_al_ELEC_491_Parking_final_report.pdf [ 3.19MB ]
JSON: 18861-1.0394866.json
JSON-LD: 18861-1.0394866-ld.json
RDF/XML (Pretty): 18861-1.0394866-rdf.xml
RDF/JSON: 18861-1.0394866-rdf.json
Turtle: 18861-1.0394866-turtle.txt
N-Triples: 18861-1.0394866-rdf-ntriples.txt
Original Record: 18861-1.0394866-source.json
Full Text

Full Text

UBC Social Ecological Economic Development Studies (SEEDS) Sustainability Program Student Research Report Dynamic Parking Signage Project Geoff Goodwin-Wilson, Timothy Cheng, Hiu Lok Cheung, Yuyang He, Jared West University of British Columbia ELEC 491 Themes: Transportation, Land Date: July 31, 2020 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”.  Design Document for Dynamic Parking Signage Project  ELEC 491 Capstone Design Project     Team PL-89  Geoff Goodwin-Wilson Timothy Cheng Hiu Lok Cheung  Yuyang He Jared West    Design Document 1 TABLE OF CONTENTS Glossary 3 1. Executive Summary 5 2. System Overview 6 2.1 High-Level Architecture 6 3. Hardware Design 7 3.1 Functional Description 7 3.2 Power Architecture 8 3.2.1 Solar Panel 8 3.2.2 Main Power Path 9 3.2.3 Max Power Point Tracker 10 3.2.4 Rechargeable Battery Selection 11 3.2.5 Battery Pack Configuration 13 3.2.6 Battery Management 14 3.3 Communication 15 3.3.1 Cellular Modem (LTE) 15 3.3.2 PlacePod Smart Parking Sensor 16 3.4 E-ink Display 16 3.4.1 Display Selection 16 3.4.2 E-ink Display Driver Board 17 3.5 STM32 Microcontroller 19 3.6 Electronics PCB Integration 20 3.7 Enclosure 21 3.7.1 Functional Summary 21 3.7.2 Fabrication Method 24 4. Management System 25 4.1 Functional Description 25 4.2 Amazon Web Services IoT Core 26 4.2.1 MQTT 26 4.3 Web application 28 4.3.1 Functionalities 28 4.4 Eleven-X Server 28 5. Recommendation to Future Instructors 29 6. Potential Directions of Future Iterations 30 6.1 Security of Web app 30 6.2 Provide more functionalities in the web app and system 30  Design Document 2 6.3 Move logic from server to sign 30 6.4 Increase portability of web app source code 31 7. References 32 Appendix A: Battery Comparison 33 Appendix B: E-ink Display Comparison 39 Appendix C: Power Budget 41 Appendix D: Cloud Platform Comparisons 44 Appendix E: Goodisplay Representatives 47    Design Document 3 Glossary AWS Amazon Web Services BOM Build Of Materials C Celcius CAT Category CNC Computer numerical control DC Direct Current EC2 Elastic Compute Cloud E-Ink Electronic Ink FDM Fused Deposition Modeling FET Field-effect Transistor GUI Graphical User Interface HTTPS Hypertext Transfer Protocol Secure Hz Hertz IC Integrated Circuit IoT Internet of Things IP65 Ingress Protection Standard KISS Keep It Simple, Stupid kWh Kilo-Watt hour LCD Liquid Crystal Display LED Light-emitting Diode Li-ion Lithium-ion LoRaWan Long Range Wide Area Network LTE Long Term Evolution mAh milliamp hour MCU Microcontroller Unit mm millimeter MOSFET Metal-oxide-semiconductor FET MPPT Maximum Power Point Tracking MQ IBM MQ - MQSeries MQTT MQ Telemetry Transport  Design Document 4 Nom Nominal OLED Organic LED PCB Printed Circuit Board PV Photovoltaic R&D Research and Development R-DOT display company name SEEDS Social Ecological Economic Development Studies SLA Stereolithography SLS Selective Laser Sintering STM32 STMicroelectronics 32 bit UBC University of British Columbia UBC PAS UBC Parking and Access Services V Voltage VIP Very Important Person W Wattage 3D Three dimensional    Design Document 5 1. Executive Summary Our capstone team is working with UBC Parking and Access Services (UBC PAS) to create a dynamic parking sign which will allow for wireless stall restriction control. This project is a continuation of a previous year capstone project which UBC PAS wanted us to improve upon their design. The designed product will be installed in areas where stall flexibility is needed. UBC PAS will have access to an online management system to remotely control what is displayed on the sign and monitor the status of each sign. The final product will feature a programmable display showing parking information. It will be powered by rechargeable batteries and a solar panel.  This document records all choices of components our team made in order to fulfill the functional and non-functional requirements while adhering to the constraints of this project. Justification for these decisions will also be included, with reference to the requirements specification key document.                      Design Document 6 2. System Overview Each dynamic parking sign involves multiple subsystems working together to perform the intended task of displaying a parking restriction. For this document, the project will be divided into four systems:  ● Power Architecture: Documents how power is supplied by a solar panel and batteries as well as utilized by different components of the whole system. ● Communication: Documents how web app communicates with the sign through cellular network as well as how sensors communicates with microcontroller ● E-ink Display: Documents the screen for displaying images.  ● Online Management: Documents how the screen is controlled from the client’s end using online services and protocols.   Each system is influenced by the design of the previous dynamic parking sign project with a major redesign of the electrical, mechanical, and software systems.  2.1 High-Level Architecture The main goal of this project is to create a solution to automate parking space usage. As seen in Figure 1, the final system proposed will have two devices for each parking stall - a dynamic parking sign and a PlacePod smart parking sensor. They will be connected to a web application accessible by the user through a web browser, allowing the user to control the dynamic parking sign. The PlacePods are part of an existing network of parking sensors that communicates the stall occupancy to the management system, making parking sign changes based on occupancy.   Figure 1. A High-Level Overview of the Complete System  Design Document 7 3. Hardware Design In this section, we will justify our design decisions for the parking sign hardware, explain how each subsystem works from a high-level perspective and how they are related to the requirements and constraints of the project.  3.1 Functional Description The hardware for this project is designed to implement all necessary components needed to fulfill the project requirement specification. As seen below in Figure 2, the electronics system first receives power from both the battery and the solar panel simultaneously. Any extra energy generated by the solar panel is used to charge the battery pack. The voltage generated by the solar panel and battery pack is then stepped down to a steady voltage to power the remaining circuitry.  The rest of the system, outlined in Figure 2, is designed to be controlled from a microcontroller (MCU), which runs C code. An off-the-shelf cellular module is used to communicate with the microprocessor from the web application. Any data received wirelessly by the cellular module is either processed on the spot or stored in flash memory. The microprocessor also drives an e-ink display, which is used as the “dynamic” part of the parking sign. In addition to this core functionality, various sensor inputs are constantly read by the microprocessor. The sensor suite includes motion sensing, temperature sensing, and ambient light sensing.   Figure 2. Electrical System Architecture Block Diagram    Design Document 8 3.2 Power Architecture From design constraint ​C1, ​the device must be solar-powered. This introduces complexity to the way power is delivered to the system since the device must be powered for two weeks straight without being charged (​NFR1​). Due to space constraints, the solar panel used is unable to supply the system indefinitely. Consequently, the design requires batteries to power the device when the solar panel is not generating sufficient power. Designing the device around low power consumption and extracting as much energy as possible from the solar panel also helps to meet ​NFR1​. Due to these design requirements, the power system consists of several sub-systems working together to power the device which are shown in Figure 3.   Figure 3. High-Level Power Architecture Diagram 3.2.1 Solar Panel The solar panel is used to charge the batteries to create a self-sufficient system - requiring a manual re-charge by UBC PAS every two weeks according to ​NFR1​. Daily mean insolation data (kWh/m​2​) produced by the government of Canada [1] helps us determine the amount of power a solar panel can produce under ideal conditions in Vancouver, BC.   From constraint ​C2​, our team reduced the overall size of the legacy solar panel by using an alternative panel rated for 10 watts. To justify this decision we calculated the amount of energy the panel can produce during the worst-case month, December, having the lowest  Design Document 9 daily mean solar insolation. In the worst case, the panel is capable of producing 262 watt-hours over a two week period (see Appendix C) for complete calculation and power breakdown. The value includes de-rating factors (i.e. environmental factors such as temperature, irradiation, climate change, etc.) from the cell efficiency, performance ratio, and the active area of the panel [2].  The Renogy 10 watt solar panel was chosen because the form factor is smaller than the legacy solar panel while generating sufficient power. Reducing the solar panel size was requested by the client as it will meet signage space constraints. 3.2.2 Main Power Path The power path starts at the input voltage generated by the solar panel. The input voltage can also be provided from a wall adapter through an external 19-24 volt 5.5mm barrel jack supply to charge/power the device. The input power goes through an ideal diode-OR controller to accommodate the dual input supplies and keep power losses to a minimum. The diode-OR controller is an integrated circuit that works by controlling the gate of a MOSFET for each supply acting like two diodes, blocking the back drive into one another. The advantage of using a MOSFET instead of traditional diodes is from the reduced power losses through the channel of the FET.  After the power is supplied from the solar panel or barrel jack, it goes into a maximum power point tracker (MPPT) circuit, which will draw more current until the max power point voltage is reached by the solar panel. This will draw the maximum available power from the solar panel to help achieve two weeks of self-sufficiency ​(NFR1)​. The input power will be converted by the MPPT in order to charge the battery pack and supply the device with power. The charging process will take approximately 10 hours from 0% to 100% at the max charging current (2 amp) with all 12 batteries installed.  Lastly, a clean (fixed, low ripple) 5 and 3.3 volts is required to power all other circuitry. A constant output buck converter steps down the voltage output from the MPPT/batteries to provide 5 volts to the low voltage circuitry. In cases where chips require a precise 3.3 volt rail instead of 5 volts, it will be provided by a linear regulator to step down the voltage from the 5 volt rail. There is also a power input from a USB port, so blocking diodes are used on the 5V_USB rail to prevent back-drive into the USB supply. The USB is necessary to communicate to the device directly via a UART interface. It also allows the device to be powered without the use of batteries or a 24 volt barrel jack.  Using our power scheme, both the batteries and solar panel work simultaneously to power the device. During high sunlight scenarios when the solar panel produces enough power, it will power the 5 volt buck converter in addition to charging the batteries. During the night or low-light scenarios, any power from the solar cells will contribute to the output power but the batteries will supply the remaining power drawn by the 5 volt buck converter (Figure 3).  Design Document 10 3.2.3 Max Power Point Tracker Since a lower power solar panel (10 watt) is used in our design, every extra milliwatt of power drawn from the solar panel makes a significant difference in the duration the device can run from a single charge. For this reason, a MPPT is used to draw near maximum power from the panel for any given sunlight condition. As seen from Figure 4, there is a specific point on the current versus voltage curve where maximum power is drawn.  Figure 4. Max Power Point for a Photovoltaic Source  Implementing circuitry to automatically seek out this point is difficult, but there are integrated circuits (ICs) that are specifically made for this purpose. Being an emerging technology, choices of ICs were limited. Two potential ICs were compared: SM72441 and LT3652. The SM72441 is more versatile, requiring four external switches to implement a full-bridge buck-boost converter which can be used for various power output levels. Alternatively, the LT3652 is designed for a more simple turn-key solution for an MPPT circuit, and integrates all switches and control circuitry internally. Designing a circuit around the LT3652 is vastly simpler than the SM72441. An IC such as the SM72441 becomes a necessary solution in high power applications that the LT3652 can no longer handle, but in our case, the maximum short circuit output current of the solar panel is approximately 700mA, and the LT3652 is rated for 2 amps [3]. From the simplicity and low-cost of the LT3652, it was chosen as the max power point tracker chip in this design.  We can observe the efficiency curve of the MPPT chip in the graph below from the LT3652 datasheet - Figure 5.   Design Document 11  Figure 5. LT3652 MPPT Chip Efficiency  From efficiency figures, we can determine the amount of energy the solar panel delivers to the battery. Since the majority of the components require 5 volts, we can assume the efficiency will be between 80-88%. With efficiency, the energy produced in our worst-case scenario is 209 watt-hours, which is within our power budget as shown in Appendix C. 3.2.4 Rechargeable Battery Selection Since our system consumes a low amount of power due to our e-ink display and low-power consumption circuitry, our battery cell was chosen strictly to maximize energy density instead of power density. Currently, the most energy-dense battery cells on the market fall in the lithium-ion category, so we selected a cell from this chemistry.  Packaging & Form Factor A cylindrical cell was chosen over pouch cells to provide convenient packaging such that the cells can be spring-loaded and easily replaced. This form factor also does not require any compression for proper operation, which is convenient to keep things simple for the user.  Low-Temperature Performance It is important to observe the capacity retention at low temperatures of our cell candidates since lithium-ion batteries can lose a lot of their rated capacity in cold weather. In Vancouver, temperatures rarely go below -10°C, so this is an appropriate worst-case scenario temperature to consider. For our chosen battery cell (Panasonic NCR18650B), the low temperature performance is shown in Figure 6.    Design Document 12  Figure 6. Low Temperature Performance of Panasonic NCR18650B  The battery takes a significant capacity penalty at -10°C. The battery is rated for 3350mAh, but only achieves 2750mAh (while discharging at 3.25 amps). It’s difficult to extrapolate the cold weather battery performance for our specific use case since we’re drawing much less continuous current (~30mA).  Cycle Life Most lithium-ion cells have an impressive cycle-life. Typical cycle life under normal operating conditions can be seen graphically in Figure 7.  Design Document 13  Figure 7. Cycle Life of Sony VTC6 Over 500 Cycles [4]  From the nominal capacity and capacity retention at low temperatures, ​Sanyo NCR18650GA and ​Panasonic NCR18650B​ are considered to be the best options for this design. However, all considered cells share the same form factor (18mm x 65mm), so if a different battery is used then the total usage time without being charged will increase or decrease depending on the cell, but the design will remain functional. The user should note that the same amount of cells should be placed in parallel for each element in series in order to keep the pack balanced. 3.2.5 Battery Pack Configuration The battery pack cell configuration for the device depends on two factors:  1. NFR1: ​Self-powered, lasting for at least two weeks - including low light and night conditions 2. Pack voltage must be within the range of the MPPT battery float voltage (4.5V to 14.4V)  Since the chosen cell is lithium-ion chemistry with minimum and maximum cell voltages of 2.5 and 4.2 volts respectively, two cells can be put in series to create a minimum pack cut-off voltage of 5.0 volts, and a maximum voltage of 8.4 volts. Both of these voltages lie within the LT3652’s accepted range of 4.5 to 14.4 volts.    Design Document 14 With two cells in series, the number of cells in parallel can be determined to satisfy the requirement of being powered for two weeks without charge (​NFR1)​. Increasing the number of cells in parallel will increase the overall capacity of the pack and reduce the current drawn from every cell (although power limitations of the cells are not a concern with this design). To determine this number, the average power draw of the system is estimated, using the power budget included in Appendix C, to be 0.94 watts. The energy required for a two week period is calculated to be 315 watt-hours. Using the energy required and the energy which can be supplied by the solar panels, the amount of energy needed from the batteries is found to be 54 watt-hours. Additional batteries are implemented to ensure our two week requirement is satisfied.  3.2.6 Battery Management Since lithium-ion battery cells are used in this design for their high energy and volumetric density advantages, special care has to be taken to ensure they are used safely. The battery management system has various safety features to ensure it is functioning within its electrical limits at all times. The battery management system for this design has the following features:  ● Short circuit protection ● Overcharge prevention ● Undervoltage and overtemperature protection ● Reverse polarity protection ● Cell balancing ● Voltage sensing  Short Circuit Protection Each cell in the battery pack has its own 1.5A fuse to ensure that the batteries will not be damaged in the case of the battery pack being short-circuited. Since each parallel element is fused, even if a battery in the pack fails as a short circuit, additional parallel fuses will prevent the other cells in parallel from discharging into the short.  Overcharge Prevention An overcharge event on the battery pack is prevented by the MPPT chip. If the battery voltage becomes higher than the programmed maximum, the chip will shut down, preventing any additional current going into the battery pack.  Undervoltage and Overtemperature Protection Undervoltage and overtemperature events are prevented by comparators. If the battery pack falls below 5.2V (2.6V/cell), a reference voltage will cause the comparator to output a logic 1, signifying a fault. The same comparator strategy is used in conjunction with a thermistor to protect against overtemperature. The overtemperature and undervoltage fault outputs are ANDed together such that if one output goes low, the DC/DC converter enable signal will go low and shut it down, preventing any current being drawn from the battery.  Design Document 15  Reverse Polarity Protection Reverse polarity protection can be easily implemented with a series diode, but this solution has high power losses across the diode and also prevents current from charging the battery pack (uni-directional). Therefore, an N-channel MOSFET is used at the battery input in order to prevent against a reverse polarity condition (putting the batteries in the wrong way) This circuit works by closing off the main path of current whenever negative voltage is applied. The negative voltage itself will turn off the FET in the main path of the current, causing an open circuit. To prevent any parasitic current drawn through the body diode of the FET, the drain is placed facing the battery.  Cell Balancing A 2-series cell balancing IC is used in the battery management system to automatically balance the cells. It ensures both cells in series are at the same voltage by bleeding off charge of the higher voltage cell through an internal resistance. If the cells become out of balance, it is possible for the pack to be overcharged without the MPPT “realizing”. Suppose cell 1 is at 4.2 volts but cell 2 is 3.5 volts. The total pack voltage is then 7.7 volts, but the MPPT will continue charging the pack since the total pack voltage is below 8.4 volts. This is dangerous because cell 1 will become overcharged in this scenario. We are using the Texas Instruments BQ29209 as our balancing chip, referring to the datasheet as a guide to properly implement the circuit for our application [5].  Voltage (State of Charge) Sensing The voltage of the battery pack is also sensed and read by the microcontroller. This indicates the state of charge of the battery pack. This information is processed by the microcontroller and can be sent to the web application so the user can tell when the device(s) need to be recharged manually. 3.3 Communication The device communicates with the management system through the 4G LTE network using a cellular module. Therefore, all new instructions can be received wirelessly, such as uploading new images, changing parking displays based on schedules, and checking current stall restrictions. This achieves ​FR2​ and removes the need to physically flash new instructions onto the device as required by the previous design. 3.3.1 Cellular Modem (LTE) For the sign to communicate with the management system, the expansion board from the P-L496G-CELL02 STM32 discovery pack is used. This board has a Quectel BG96 cellular modem capable of LTE CAT M1 communication, with up to 300kbps downlink and 375kbps uplink [6]. Therefore, data uploaded to the device from the online management system will take less time to transmit to the sign. Furthermore, this modem uses a power-saving mode  Design Document 16 when idle, reducing power consumption for ​NFR1. ​Since our e-ink display also uses a STM32 MCU, this modem which is also controlled by an STM32 was a good choice for compatibility with our system.  LTE capabilities were prioritized when selecting the cellular module, as compared to other wireless communication methods due to speed, signal availability and popularity. In particular, the previous design had communications using only LoRaWAN, which has a maximum 27kbps raw data rate [7]. This resulted in long upload times that would exceed the two minute upload time required by ​NFR2​.​ ​Since most of the modem specifications are proprietary, we are unable to characterize power consumption and specific data rates of the module. 3.3.2 PlacePod Smart Parking Sensor In a pilot project, the service provider Eleven-X installed data collection infrastructure on selected campus parking stalls to detect when they were occupied [8]. This infrastructure used PlacePod Smart Parking Sensors connected to a LoRa network, which sent the occupancy data to an Eleven-X server. Our design was intended to use this infrastructure to sense which stalls were in use to fulfill ​FR1​, but unfortunately due to the outbreak of COVID-19, this functionality was removed from the scope of the project. 3.4 E-ink Display  The display system consists of two components: an e-ink display screen and circuitry used to generate the necessary driving waveforms. To change the image on the display, an MCU sends SPI data to the display driver circuitry. For our design, this board is integrated into the main MCU on the PCB, as opposed to a separate board which was used in the previous design. There are various advantages of an integrated single-board solution for the display circuitry. It allows a circuit that originally consisted of 2 PCBs to be combined on to the main PCB. This reduces cost, decreases manufacturing complexity, and greatly reduces packaging constraints, which helps us achieve ​C1​. 3.4.1 Display Selection To meet ​NFR1​, it is critical to have a low power solution for a changeable display on the device. Based on research completed during the previous capstone project, the use of e-ink is recommended because of the low current draw when flashing a new image. The updated sign will then display the image with minimal consumption of power. An advantage of e-ink over the alternatives (Appendix B) is that the display consumes zero power once the new image is flashed and will remain on the display until a new image is displayed.    Design Document 17 To reduce the bill of materials (BOM) cost, we decided to use a relatively inexpensive display which the previous team had used, GDEW1248Z95 (Goodisplay), over a more complex (ED133UT2) e-ink display for the following reasons:  1. Cost is $120 dollars, whereas other similar sized options are in the range of $500 to $1000 2. Screen refresh rate meeting ​NFR2  3. Development kit ease-of-use  As shown in the table in Appendix B, Goodisplay costs less than the e-ink display while meeting ​NFR3​. Furthermore, the previous team developed using Goodisplay GDEW1248Z95, providing us code and other open-source resources for future firmware development.  The ED133UT2 display board would be challenging to integrate within our timeline, since one would need to reverse engineer the entire codebase that loads an image to the display in order to migrate it to our chosen MCU. Eink, the company that manufactures this display, requires developers to use their proprietary software to load images onto it. They only provide the binary (.bin) file and not the source code so we would not be able to customize the firmware. Also, the driver chip is not in the ST family that our cellular module is in, so migrating the code would require significant development time. Furthermore, the benefits of working with Goodisplay is that they have sufficient customer support. 3.4.2 E-ink Display Driver Board  Using our chosen e-ink display allows the project to use a driver board in the STM32 family. Although there is a specific development board to control the driver, we have designed our PCB to replicate the Goodisplay PCBs’ circuitry, allowing for the sign thickness to be reduced (​C2​).  3.4.3 LED Control To fulfill ​NFR3​, we decided to surround the display with LED strips that illuminate during low light conditions. To save power, the LED strip should only light up when needed i.e. a vehicle is driving by or approaching the sign. One naive solution would be to turn on the LED light strip the entire night or time of day when it is dark out by using only an ambient light sensor. We chose to use a photoresistor sensor, which provides an analog signal that is simple to measure, and its small profile fits the PCB and enclosure easily. The power consumption to leave LED strip the entire night is found using the following assumptions:  ● 13-hour night (worst case in December, Vancouver, BC) ● LED power consumption of 0.24 watts each (12 volts at 0.02 amps) ● Length around the interior of the sign is 1 meter ● 18 LEDs total  Design Document 18  Based on the assumptions, the average power the LED strip would consume during the night is about 4.3 watts. This value exceeds our power budget which violates the ​NFR2​ since the two week energy required would be 782 watt-hours using the aforementioned assumptions (13 hour night specifically). Considering the solar panel is capable of 209 watt-hours this needs to be modified.   Keeping the LED strip on for the entire night consumes too much power. The proposed solution is using a photoresistor and a motion sensor. Instead of leaving the LED strip on, the LED strip only turns on when motion is detected. This reduces the power consumed by the LED strip to 0.54 watts using the same assumptions as above with the following additional assumptions:  ● The power draw of an additional component of motion sensor is 113.6 mW ● The probability of triggering an LED strip is 10% and assuming each time triggered, the LED strip stays on for 30 seconds.  Using these assumptions, the mean daily power used by the LEDs is about 0.43 watts. Using the sensors to control the LED uses 80 watt-hours of energy which is approximately 10% of the initial suggestion. All the calculations are included in Appendix C in the form of the power budget of our design.  Our proposed solution justified leaving the LED strip in the prototype for ​FR3​ while meeting NFR1​. The motion sensor (​EKMB1101112 PIR)​ has up to a 5-meter range and a field of view of 106° by 97° [9], which enables detection of vehicles and people near the stall. A visual representation of the range is shown in Figure 8.   Design Document 19  Figure 8. Field of View of Motion Sensor 3.5 STM32 Microcontroller The MCU processes all information from the different inputs and decides what to do accordingly. Due to the constant need to check sensors and network information, the MCU is always active in the device. The MCU is chosen to accommodate all the necessary peripherals used on the device. In addition, the MCU must support the chosen display and cellular module. To fulfill ​NFR1​, it is also critical that the MCU consumes a low amount of power and has “sleep” functionality to save power.  We have two different MCUs for our display and cellular development boards. It is decided that one of the MCUs on these development boards should be used in the final prototype to reduce code migration risks.   Therefore, there are two options: STM32F103 Cortex M3 (used with display) and STM32L496 Cortex M4 (used with cellular module). STM32F103 Cortex M3 was used in the legacy design and is already available, while the M4 is a low power variant that has the same STM32 architecture as the M3. Since the codebase for the cellular module is much larger and more complex than the display firmware, it would be preferable to migrate the display code to the STM32L4 instead of attempting to migrate the cellular module firmware to the STM32F103. The STM32L4 was ultimately chosen due to this, as well as it’s low power consumption. Please refer to Appendix C for the power calculation.   Design Document 20 3.6 Electronics PCB Integration All previously mentioned electronic systems are integrated onto a single PCB. This design decision was influenced by many advantages in the context of our project:  Manufacturability: A PCB is easier to both manufacture and prototype. It removes the need to add unnecessary jumper wires between systems since all electronics are integrated on to the same board. If the design was to be manufactured at any volume, it is much easier to use standard automated PCB fabrication and assembly machines.  Testability: When testing a system, it is advantageous to rule out wiring/connections as being an issue. Since our PCBs are tested for continuity between every connection during fabrication, wiring is a failure mode which can be ruled out unless a mistake on the schematic design is made.  Footprint Reduction: Integrating all systems on the same PCB allows the designer to merge all components in any configuration, which reduces the size. There is also no need for many of the connectors required to interconnect multiple PCBs, which also reduces the footprint.  Enclosure integration: In order for us to meet the constraint of 2 inches maximum thickness for our enclosure, it was essential to integrate systems such as the driver board and display development board onto a custom PCB. For example, the stock driver board ribbon cable header alone takes up ~1cm of height, which would have put us over the constraint of 2 inches. This, combined with complex mounting issues made designing a PCB an essential design decision for our project.  Cost: Designing a PCB has the potential to greatly reduce the BOM cost of the prototype since all the parts are chosen by the designer strictly for the application, whereas parts of development boards are chosen for more general applications. Additional parts, such as optional headers and connectors are unneeded with a custom PCB design, which further reduces cost. If the PCB is manufactured in volume, part costs are also reduced exponentially.  The PCB is sectioned and correlated to the high-level electronics diagram by highlighting each section’s respective functionality as shown in Figures 9 and 10.   Design Document 21  Figure 9. Electrical System Architecture Block Diagram  Figure 10. PCB Layout - Colour Coded Systems 3.7 Enclosure 3.7.1 Functional Summary All the components of the dynamic sign will be within an enclosure with an ingress protection rating of IP65 or greater (​NFR4)​. The rating is adequate for Vancouver weather and also the rating used by UBC PAS for all of their outdoor devices. We have designed an enclosure that is built around our PCB and screen dimension constraints, as opposed to conforming to set dimensions from a prefabricated enclosure. This allowed us to meet the enclosure thickness constraint, ​C2​. In accordance with the existing UBC PAS parking infrastructure, our enclosure is also designed to be integrated with an aluminum parking sign footprint  Design Document 22 commonly used on campus. The aluminum sign, seen in Figure 11, displays information that does not change - for example, legal messages, parking services, and contact information. The aluminum sign has a cut-out to show the current parking restriction on the e-ink display, seen in Figure 11 with an image of the Mona Lisa displayed. An exploded view of the designed parking sign is shown in Figure 12, demonstrating the various components included in the enclosure assembly.    Design Document 23   Figure 11. Enclosure and Parking Sign Front and Isometric Views  Design Document 24   Figure 12. Enclosure Exploded View  The enclosure is designed with respect to ​NFR4 ​by using a combination of a rubber gasket, epoxy, IP65 or higher rated components, and a silicone sealant. To validate our waterproofing techniques and ensure our target rating of IP65 is fulfilled, further validation testing was unable to be completed due to the COVID-19 outbreak. 3.7.2 Fabrication Method When using a custom design for an enclosure, a method of fabrication has to be chosen. In our case, with limited machining access and in-house fabrication options, we looked to out-source the fabrication. There is a considerable amount of options to fabricate our enclosure. Popular options include:  ● 3D printing (FDM) ● Additive manufacturing (SLS, SLA) ● Injection Moulding ● CNC Machining ● Sheet metal bending   Design Document 25 In our case, a versatile option was necessary due to the requirement of adding small, unique features necessary for our design, such as wire management cavities, LED strips & our display. FDM and bent metal were ruled out due to their inability to restrict water flow (microcracks in the layer structure for FDM). Injection moulding could be used for a part like this but is expensive and generally used with a CNC machined mould for medium to high volume production. Making a mould for this part would not be worth it for a prototype due to the prohibitive cost. CNC machining could work, but with this process the part needs to be designed specifically to be machined by a 3-axis mill and therefore restricted our design options. This, combined with being a (relatively) expensive process, took it off the list of options. SLA would be fine but the disadvantage of melting improperly for our threaded inserts made SLS the ideal choice. To summarize, SLS was convenient in being able to add virtually any feature we want with extremely precise tolerance. This, combined with being waterproof, accommodating melted-in threaded inserts properly, and being the cheapest option made it the obvious choice for fabrication of our enclosure design. 4. Management System The management system is the controller for the behaviour of the dynamic signage devices. Through the management system, the client can remotely change the image displayed on the screen and its behaviour between the three use cases (section 5 of the Requirements Specification document). 4.1 Functional Description The online management system consists of three major elements - the web application (web app) deployed on a EC2 instance on AWS Cloud platform, AWS IoT Core to route MQTT requests, and the Eleven-X server. The web app introduces the interface between the client and AWS to customize the information shown on the dynamic parking sign. A visual representation of the management system is seen in Figure 13. By providing a simplistic web app for UBC PAS, it allows administrators to log-in and access the managing system from any computer and modify the stall restrictions with a couple clicks of the mouse. The management system also allows parking administrators to upload their own images in .jpg and .png formats to the server and be used as new parking restrictions to be displayed on the parking sign.  Design Document 26  Figure 13. Online Management System Architecture  It was a constraint that our system uses the pre-existing PlacePod network installed for UBC PAS. The PlacePod Smart Parking Sensor checks parking stall occupancy and sends the information through the LoRa network to the Eleven-X Server. This information is then forwarded to the AWS IoT Broker (MQTT).  4.2 Amazon Web Services IoT Core Amazon Web Services (AWS) provides a multitude of cloud-based products for computing, storage, and analytics; of which the AWS Internet of Things (IoT) core allows connecting devices to the cloud in a secure and scalable manner. We chose AWS over Microsoft Azure and Google Cloud Platform as the cloud platform to host our backend because at the time of development (2019 September - 2020 April), AWS provides the most benefits (see appendix D) of the three platforms. AWS also offers a wide range of services such as EC2, beanstalk, lambda functions, and databases that may be used in future projects. By hosting the backend on AWS, we reduced the development time and simplified the interaction between other services we are using on the cloud.  4.2.1 MQTT Initially, we proposed to run our server on one AWS EC2 instance. Each sign would communicate directly to the server using HTTPS. We then considered the possibility of scaling up and concluded that it would be very difficult and infeasible to do so. The reason being that each new device added to the system would need to create a separate connection to the server and other services (database and processes), which opens up to more security flaws as more connections need to be made.  Design Document 27  We chose to use MQTT as the communication protocol in the management system. As shown in Figure 14, MQTT uses a broker that mediates the communication between our device(sign) and the web application. MQTT is a subscription/publish model. This means devices that wish to receive data from a device can “subscribe” to a “topic”. When a device has new information to post, it “publishes” to the broker. The MQTT broker acts as a post office by forwarding the messages to devices or services that “subscribed” to the device’s “topic”. This message forwarding mechanism is known as the broker’s “policy” in dealing with incoming messages. AWS IoT Core provides us with a graphical interface to modify topics, subscriptions, and policies easily. Now, instead of each sign establishing a connection with the server, each sign establishes a connection with the MQTT broker. It takes care of security (encryption and authentication) and message forwarding so that we have more time to spend on developing other components.   An MQTT connection is persistent, meaning it remains intact even when devices power off and on - general overview in Figure 14. On the other hand, HTTPS requires a connection establishment (handshake) for every single message which results in a large amount of overhead. As a result, this reduces unnecessary messages to establish connections and thereby reducing power consumption (​NFR2​). The connection is inherently bidirectional which solves the problem of initiating a connection to each sign (each has a different IP address; a list must be kept if HTTPS is used).    Figure 14. MQTT Broker System Architecture  Design Document 28 4.3 Web application The web application uses an interface for the user to communicate with the AWS cloud service. It simplifies the interaction by creating preset commands at the click of a button; the major one being streamlining the process of uploading an image to the sign. The interface communicates with AWS through HTTPS as opposed to the MQTT protocol used between AWS and the sign. The web application UBC PAS will be working with is shown in Figure 15 - a simple interface to remain user-friendly.   Figure 15. Concept Interface for Web Application  4.3.1 Functionalities The functionalities of the web app are:   1. Upload a new image to the sign 2. Change parking restriction displayed on a sign 3. Schedule a change to the restriction displayed on a sign  These functionalities address the three use cases outlined by the client and are made to be user-friendly to reduce complications for daily use by the client. In the previous team’s prototype, the uploading of new images requires manually cropping the image, converting it to black and white, and to the correct data type before it may be uploaded. The web app our capstone team designed will have these steps incorporated into the web app itself, to reduce the difficulty of operating the management system.  4.4 Eleven-X Server The management system will require the use of PlacePod smart parking sensors that are installed on campus by Eleven-X, a managed service provider. The PlacePods detects if a  Design Document 29 parking stall is occupied and sends the information to an Eleven-X server through LoRaWAN. The web app would then request that information to the AWS cloud, so the system knows when a car occupies a stall, fulfilling​ FR1​. However, due to the COVID-19 outbreak, our team was unable to establish communication between the Eleven-X gateway and our AWS server. We had reached out to the Eleven-X company, but were not able to talk with anyone there.  We were not able to implement this into our final system as our contact at Eleven-X had left the company. We reached out to the co-founder, Fraser Gibbs, but was unable to get a hold of him amidst the covid-19 pandemic. His contact information is:   Fraser Gibbs, Co-Founder & CTO 300-460 Phillip Street Waterloo, ON, N2L 5J2 226-220-5851  As UBC PAS really wants to get the most value of the pilot program UBC has with Eleven-X, we highly recommend the next capstone team to reach out to Mr.Gibbs to incorporate the Eleven-X component into the project. The next team should prioritize figuring out how to incorporate PlacePods to the project. It uses the LoRa (long range​)​ technology and we recommend one person to get started on it in September, 2020 and budget 1 month of time to complete the task. This should be done in parallel as the next team writes their milestones. 5. Recommendation to Future Instructors This section is a word of recommendation and caution to future instructors that assign the teams for capstone projects. In this year’s iteration of the UBC Dynamic Parking Signage capstone project, we were hardware and firmware focused. We have completed the entire hardware prototype. Now, the biggest challenge to future iterations of this project is software and firmware. This year our team composition was 1 CPEN and 4 ELEC students. We also faced the same issue as our predecessor in that members lacked the technical skills in firmware and software development. The burden in firmware and software development fell mainly onto the shoulders of a few members with development experience.  We highly recommend the team composition for next year’s team to have at least 3 CPEN students and ideally 4 CPEN to parallelize the firmware and software development process. As our team has finished the hardware component of the project, future iterations will be more software focused. However, at least 1 ELEC student should still be on the team to assist hardware and firmware troubleshooting and improvements. The ELEC student is pertinent to the team as more electrical components need to be purchased and prototype assembled to demonstrate the true capabilities of the system.  Design Document 30 6. Potential Directions of Future Iterations In this section, we highlight some areas we see future teams can improve the project on. This project has lots of room for improvement and growth. 6.1 Security of Web app In our final iteration, we used a simple login page to access the login page. We recommend future teams to look into this area as cybersecurity is taken more seriously by society now as privacy scandals and data being mishandled is so widespread.  The data and instructions sent from the webapp are not encrypted and this should be addressed in the next iteration. 6.2 Provide more functionalities in the web app and system As our clients at UBC PAS are not technical, we recommend future teams to spend time on the GUI to improve user experience and add functionalities to the web app that will make the platform easy to use. We stress that UBC PAS administrators should never need to touch the source code as this is not user friendly and will not be used.   Teams should also look at streamlining the setup process of new unregistered prototypes. The A-Z of the entire set up process of a new sign needs to be thought out and well documented. Currently sign ids and relevant device information are hardcoded but this should change for future iterations as UBC PAS should not need to change code to operate the management system. This process involves:  ● connecting the sign to cellular network ● some sort of method to load the permission keys to the signs ● registering the sign to the database or server ● downloading existing images from the server to the newly registered sign 6.3 Move logic from server to sign We designed our system to put all the logic of deciding what a sign displays on the server. This way we only needed to develop in software (i.e. node JS) instead of firmware. This made our development process very simple. We followed the principle KISS to reduce complexity and sources of bugs. The drawback of our approach is that each time a different parking restriction has to be displayed on the sign, the server has to send an image to the sign. This is massively wasteful and unscalable when the number of signs increases. For  Design Document 31 example, if each image is 1 Mb and there are 200 signs to be updated at 3PM as rush hour begins and parking restrictions is now “5 minute pick up only”:    Mb/image  image/sign 500 sign 500 Mb1 × 1 ×  =    This gives 500 Mb of data to be used per update. The robustness of the system is also in question when cellular networks are down and during server outages. The signs should remain functional regardless of cellular connection and server status.  The alternative approach is to implement the logic in each sign. This way bandwidth usage is reduced and each sign is independent of network status such as unpredication network congestion, cellular service outage, and server status.  6.4 Increase portability of web app source code We see dockers as a viable way to tackle the possibility that UBC PAS may one time move all source code and hosting in house. Often specific versions of libraries and frameworks (node JS, python, git, etc) are used and violating them will result in compilation issues. Instead of having each team re-download libraries, install dependencies, and configure operating systems, future teams can save many development hours by adopting dockers to run web app source code in containers. This greatly increases portability from one platform to another.             Design Document 32 7. References [1] “Photovoltaic and solar resource maps,” ​Natural Resources Canada​, 20-Mar-2017. [Online]. Available: https://www.nrcan.gc.ca/18366. [Accessed: 25-Jan-2020]. [2] “Performance Ratio of Solar Power Plant - Definition, Glossary, Details - Solar Mango,” Solar Mango – #1 guide for solar​, 28-Sep-2015. [Online]. Available: http://www.solarmango.com/dictionary/performance-ratio/. [Accessed: 31-Jan-2020]. [3] Linear Technology, “Power Tracking 2A Battery Charger for Solar Power,” LT3652 datasheet, Jan. 2010. [4] Sony, “Lithium Ion Rechargeable Battery,” US18650VTC6 datasheet, Jan. 2015. [5] Texas Instruments, “BQ2920x Voltage Protection with Automatic Cell Balance for 2-Series Cell Li-Ion Batteries,” BQ29209 datasheet, Sept. 2010. [Revised Mar. 2016]. [6] ST, “STM32 Discovery Pack for LTE IoT Cellular to Cloud,” P-L496G-CELL02 datasheet, Feb. 2018. [Revised May. 2018]. [7] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui, and T. Watteyne, “Understanding the Limits of LoRaWAN,” ​IEEE Communications Magazine​, vol. 55, no. 9, pp. 34–40, Jan. 2017. [8] “Intelligent Parking Empowers Smart Campus: eleven-x takes parking assets in a smart direction at UBC,” ​Eleven-X​. [9] Pan​asonic, “High-sensitive human detector sensor with built-in amp,” EKMB1101112 PIR datasheet, Aug. 2012. [10] K. Araujo, “Battery Cell Comparison,” ​Epec Engineered Technologies - Build to Print Electronics​. [Online]. Available: https://www.epectec.com/batteries/cell-comparison.html. [Accessed: 25-Nov-2019]. [11] F. Lambert, F. Lambert, and Fred, “Tesla battery degradation at less than 10% after over 160,000 miles, according to latest data,” ​Electrek​, 14-Apr-2018. [Online]. Available: https://electrek.co/2018/04/14/tesla-battery-degradation-data/. [Accessed: 25-Nov-2019]. [12] Samsung, “Introduction of INR18650-25R,” INR18650-25R datasheet, Oct. 2013. [13] Samsung, “Lithium Ion Rechargeable Cell,” INR18650-35E datasheet, Mar. 2015. [Revised Jul. 2015]. [14] LG Chem, “Rechargeable Lithium Ion Battery,” Lithium Ion INR18650HG2 datasheet, Apr. 2014. [15] Panasonic, “Lithium Ion NCR18650B,” Panasonic 18650B Battery datasheet, 2012. [16] Panasonic, “Specifications for NCR18650GA,” Panasonic 18650 Battery datasheet. [17] LG Chem, “Rechargeable Lithium Ion Battery,” Lithium Ion INR18650 MJ1 datasheet, Apr. 2014. [Revised Aug. 2014].   Design Document 33 Appendix A: Battery Comparison Battery Chemistry A visual comparison of different battery types is found in Figure 17 below.   Figure 17: Battery Chemistry and Energy Density Comparison [10] Assuming the project can fulfill two weeks of usage per charge up to 250 cycles, one set of batteries will last 500 weeks or approximately ​9 and a half years​, conservatively. It should also be considered that the projected cycle life at a lower discharge rate is much better. For example, the following plot is from Tesla Model S/X battery pack, which also uses Lithium-ion 18650 cells:   Design Document 34  Figure 18: Tesla Model S/X Mileage vs Remaining Battery Capacity [11]  As seen, 250,000km corresponds to ~91.5% retention rate average. Assuming 450 kilometers per charge, this corresponds to 550 charge cycles. This retention rate is much better than the ~75% retention for higher discharge cycles.  Potential Options  Part No. Retention -10C Nom. Capacity Discharge rate Cost (per cell) Samsung 25R 2125mAh 2500mAh 4C $2.89 Panasonic NCR18650B 2800mAh 3350mAh 1C $7.49 LG Chem INR18650 MJ1 2450mAh 3500mAh 0.2C $4.99 Samsung 35E 1400mAh 3500mAh 1C $4.99 LG Chem HG2 1800mAh 3000mAh 0.2C $5.49 Sanyo NCR18650GA 2900mAh 3450mAh 1.15C $5.49 Sony VTC6 2550mAh 3000mAh 3.33C $5.99 Table 1: Battery Cell Comparison [4], [12], [13], [14], [15], [16], [17]  Safety  Design Document 35 All compared cell options have successfully completed standard safety and reliability testing, such as:  ● Overcharge ● Short Circuit ● Impact ● Crushing ● Hot Oven (140C)  Every cell manufacturer seems to have its own method of proving the safety and reliability of each cell (noted in datasheets), but the cell design is tested under all operating conditions over their rated specifications to ensure safety in all regards. In addition, protection circuitry is implemented in the battery management circuitry including:  ● Overcharge ● Undervoltage ● Overtemperature ● Reverse polarity ● Cell balancing  All considered cells are mass manufactured by large well-trusted engineering companies and are used in millions of applications across the globe. These products are generally considered safe, although accidents do rarely happen.   Design Document 36  Figure 19. Battery Management Circui​try   Design Document 37  Figure 20. Ideal Diode-OR Controllers with Input Protection   Design Document 38  Figure 21. Max Power Point Tracker Circuit Implementation   Figure 22. Two Cell Li-ion Balancing Circuit   Design Document 39 Appendix B: E-ink Display Comparison LCD Display: This technology is very bright and easy for road users to see (​NFR3​). It has high resolution and is appropriate to display images (​FR2​, ​FR1​). It is also very cheap to purchase. It is not appropriate for our project as the power consumption is incredibly high and unfeasible to achieve ​NFR1​.  Brand CMO G121X1-L04 SHARP LQ125D1JW34 Resolution 1024 x 768 3840*2160 Screen Size (inches) 12.1” 12.5” Power consumption  2W (white Pattern) 2.08W (grey bar pattern) Table 2: LCD Display Comparison  OLED Display: This technology is much more power-efficient than LCD displays when the background is dark since it turns off the black pixels. The resolution is high and fulfills ​FR2 ​and ​FR3​ The drawback is that it consumes more energy than e-ink displays and we wish to maximize the battery life of the system. Another issue was the lack of merchants for large OLED screens in small quantities.  Brand NHD-3.12-25664UMY3 EA W256064-XGLG Resolution 256 x 64 256 x 64 Screen Size (inches) 3.12” 5.5” Power consumption 495mW (50% ON) 522mW (50% ON) Table 3: OLED Display Comparison   R-DOT: This screen technology is built off of e-ink displays and uses even less power when changing displays ( <1µW/cm​2​)​. However, because the technology is so new only alphanumeric characters that can be displayed on a 7-segment display can be shown. This does not fulfill any of our use cases and ​FR3 ​since images are not displayable. https://rdotdisplays.com/displays#/     Design Document 40 Each of the aforementioned displays would produce good images, however, we decided to go with an E-Ink display. The E-Ink displays only require power when a new image is uploaded which will help to reduce the amount of power which would be required otherwise - reducing the impact of the sign.   Brand Goodisplay  E Ink  Model Number GDEW1248Z95 VB3300-NCB / ED133UT2 Screen Resolution 1304 x 984 1600 x 1200 Screen Size (Inch) 12.48 13.3 Max grayscale 4 16 Maximum Refresh rate ⅙ Hz 75 Hz Power consumption of the refresh(mW) 82.5 mW 0.4 mW Dev Kit  DESPI-02 ICE Driving Board Dev Kit MCU STM32F103 IT8951E-64 Dev Kit Cost $30 $350 Display Cost $130 $449 Table 4. Comparison Between the Two Available Legacy E-Ink Displays     Design Document 41 Appendix C: Power Budget For justification of the solar panel to use, the team has to look at the amount of potential energy that can be captured per square meter in Vancouver, BC. Using data from the Government of Canada, we were able to determine the amount of energy the solar panel is capable of producing given ideal conditions. For the amount of energy, the following equation was used: nergy [Wh] rea nsolation erformance Ratio ell Eff iciencyE = A * I * P * C   Using the area of the panel, daily mean insolation values, a performance ratio of 75% (average value including environmental factors) and a cell efficiency of 21%, the daily mean energy is calculated for each month of the year - used to find the worst-case month for the calculations used in the above report. The monthly energy values are found in Table X    Table 5. Daily Mean Energy Generated by Solar Panel  Using the data obtained, a general power budget is built to record the power flow of the dynamic sign - complete power inflow and outflow found in Figure x and x respectively.   Design Document 42  Table 6. Power Inflow From Solar Panel and Batteries   Table 7. Power Outflow From Sign Components  The data in Table 6 can be modified by altering the assumptions (percentage of time the component is on) which will update the budget.  The following data is a calculation for determining the amount of power the MCU will be using, the data is included in the budget for completeness.  To decide which MCU to choose, we calculated the power consumption of both MCU’s at maximum current consumption (Appendix C). The result shows that M3 consumes about 24 times more power than M4, so from the power perspective, M4 is a better choice, and is the chosen MCU for the project.    Design Document 43  Figure 23. MCU Power Calculation      Design Document 44 Appendix D: Cloud Platform Comparisons In this appendix, we highlight 3 most popular cloud platforms that we considered to host our web app on. Although UBC PAS didn’t give us a budget restriction, we did not want to be wasteful and spend unnecessarily. We looked at platforms that provided free server times. Ultimately, we settled on amazon after our cost-benefit analysis. Some concerns UBC PAS has are: ● Storing personal information on servers outside of Canada ○ UBC staff and faculty have to follow FIPPA or  ​Freedom of Information and Protection of Privacy Act. This means they cannot store personal information outside of Canada unless with written consent. This is a concern for future teams when databases of credentials, license plates, or other personal identifiable information are stored on stored in the management system ● Potentially moving all codebase and hosting on to UBC servers (i.e. bring everything in house for security, control, and cost purposes)  Amazon Web Services ● Most beginner-friendly, easy to pick up ● Lots of online tutorials and resources ● The most popular and biggest player in cloud-based gaming ● 12 months free service (within the extent, very generous) ● Many regions in Canada available to host server   Design Document 45  Figure 24. AWS Dashboard Google Cloud Platform  ● Newcomer to the Cloud game ● Only $300 free credits for a year   Figure 25. Google Cloud Platform Login Page  Design Document 46 Microsoft Azure  ● Only $260 credit for 30 days ● Limited choice of free services for a year ● Team members have past experience with Azure that is not good ● Not transparent in billing ● Fewer online resources than AWS ● Less popular than AWS ● A new player to the cloud game   Figure 26. Microsoft Azure Sign-up Page   Design Document 47 Appendix E: Goodisplay Representatives These two representatives replied to our request for help. They took around 1 week to reply for each question so plan ahead when developing using the Goodisplay boards.   Figure 27. Contact information of Lisa Wong          Design Document 48   Figure 28. Contact information of Boris Jen  


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



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"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items