Custom Bicycle Light - Software
To flash the firmware on the nRF52 microcontroller on the main light PCB board, the Nordic Developer Kit was wired to program an external board. The development kit has its own nRF52 but also contains a J-link that is able to program other boards with a standard I2C data and clock input. These two pins and the reset pin of the nRF52 on the light board were accessible with through-hole pins.
The firmware on the microcontroller utilized the Nordic Connect SDK for various BLE, GPIO, SPI, and analog libraries. Code was written to read and map the battery voltage from a low-pass filter and voltage divider circuit into a battery percentage value. A similar process was done to map photo-resister voltage readings to varying levels of ambient light. GPIO pins were used to detect user input from a push button switch and if the battery was charging or done charging. The SPI library was used to send data packets across the parallel WS2812 LEDs to individually control the color and brightness.
The iOS app interfaced with a custom database and server that stored user information, accident history, and performed custom HTTP requests that were either user initiated or timed automatically. The database was made and programmed in Java using Firebase, a cloud platform by Google.
The database stored user information mainly for authentication purposes by storing an email and unique user ID number. This would allow a user to log in, see their recent accident activity, and see their connected devices to sync any settings across various iPhones. Additional data was stored for each user to monitor their accident reporting activity to timeout the user in the event that they repeatedly and purposefully shake/drop their device and upload a false crash.
Custom HTTP requests were programmed, which were called at various occasions. These were called by the iOS when a user created or deleted their account or when an incident was report by the user (manually or automatically). In the app settings, the user was able to add emergency contacts and enable automatic SMS notifications if an accident was detected. Some of the HTTP requests would request events to a SignalWire account that would perform the SMS messaging. This could not be done through the user’s phone, again because of Apple’s third-party app permissions. When a user added a contact, they would receive a message and have to reply to continue receiving updates and prevent spamming.
The light was preprogrammed with 3 light patterns that the user cannot modify. These are recommended patterns that either optimize the visibility or battery life of the device. An additional 3 light patterns could be customized by the user. Each pattern consisted of 4 bytes of memory: 3 bytes for the color, 4 bits for the flashing frequency and 4 bits for the flashing duty cycle. The flashing could range from 0 to 4 Hz and could have a duty cycle of 20 to 100%, all to conserve battery. With 3 customizable patterns, the custom BLE service had a pattern characteristic with read/write permissions that sent the 12 bytes for all 3 patterns. An additional characteristic was written with notification permissions for the user to specify which of the 6 available patterns they want to have displayed.
The software portion of the project involved programming the iOS app to customize and monitor the light remotely and detect bicycle crashes; the firmware running on the light PCB board to control the lights, monitor sensors, and communicate over Bluetooth; and the database for storing and analyzing any detected bicycle crashes.
The standard communication protocol for Bluetooth servers and clients utilizes BLE services and characteristics to define the functionality and data that a device can communicate. There are many free-to-use services that are provided by Bluetooth to use on devices. For this project, the Device Information Service (DIS) and Battery Service (BAS) were used to advertise and communicate the device information, such as software, hardware, and firmware versioning, and also communicate the battery percentage and charging status. There are other services for common devices like heart rate monitors or wireless computer mice. However, a custom service and characteristic needed to be written to communicate the desired light pattern to display on the light from an iOS application.
The database also included information about every reported accident and every false negative or false positive. Each incident had a UUID that stored the time, user, and other details about the incident. The UUID was associated with stored GPS and IMU data in the 30 seconds leading up to the detected incident. The hope was to use these 3 distinct events and collect information about various accidents to characterize the motion of the bicycle accident and further develop the crash detection algorithm to have fewer false positives and false negatives. For example, the algorithm could modify the accelerometer or gyroscope reading bias’ depending on vehicle speed.
To provide the user with more access and customization than a single push button, an iOS app was programmed to give the user an interface for easily programming and monitoring the light. This app was written in Swift in XCode and Beta tested on various iPhones and iOS’s. The backbone of the app used a BLE queue library named Bluejay that was heavily modified to allow for multiple device connections and enable over-the-air device firmware upgrades (OTA DFU). This would allow the user to connect to multiple lights and control all of them simultaneously. It allows the user to update the firmware of the device wirelessly, as opposed to incorporating a J-link in the design of every light.
The three main screens that the user utilizes on the app are the homepage, the device manager page, and pattern manager page. At the homepage, the user can see recent accident crash history, including any false positive accident reports and provide feedback on details of the accident and any notes about how the app performed the accident detection. At the device manager page, the user can monitor the battery level, change device settings, set the currently displayed light pattern, and disconnect/power cycle the device. At the pattern manager page, the user can change the color, saturation, brightness, flashing frequency, and duty cycle of a specific light pattern. This page also indicates to the user the brightness, battery life, and output power of the custom pattern.
The second main function of the iOS app was to provide automatic bicycle crash detection for the user. At the time of the project, Apple was about to release a similar feature for the Apple Watch. However, this function and other products on the market were not targeted for bicycle crashes and were mainly focused on automobile crash detection, which can take similar forms to bicycle crashes, but at much higher speeds and possibly lower rotational speeds. While the automatic detection was implemented using the iPhone’s internal GPS and IMU, it was impossible to effectively notify the user or their setup emergency contacts because of Apple’s restrictions on third-party app permissions.