Explanation of IOT Device

We have developed a smart bike theft tracker that sounds an alarm and alerts other devices in the area if a bike is being stolen. Users can attach the device to their bike, park the bike, and arm the alarm. While the alarm is armed, an accelerometer and gyroscope monitor the acceleration and rotation of the bike. If the bike moves around too much, a buzzer goes off to alert other people in the area, and the device also sends a notification over the cloud to alert the user. We decided to take on this project because Jack likes to ride his bike to class every day, and he wanted to develop a way to know if his bike was safe.

Bootloader Implementation

Our bootloader works by checking the boot flags to see if a firmware update is ready to be copied into the NVM of the SAMW25. If so, the bootloader performs a CRC check on the previously-downloaded image (stored in SPI flash) to ensure that it is still valid, copies the data from SPI flash to the NVM, clears the update flag, and resets the device. If the checksum or copy fails, the bootloader does not clear the update flag, flashes the LEDs to indicate an error, and waits for the user to manually update it. Future iterations of the device could include support for a “golden image” so that the user doesn’t have to manually service the device, as well as an HTTPS firmware update server for added security, to mitigate spoofing of the firmware image site.

Cloud Connection

We use a Node-Red backend instance running on IBM Bluemix for cloud connectivity between the devices. The device that is attached to the bike (the master) sends accelerometer readings to the cloud every second. It also sends theft notifications to the receivers over the cloud, which the receivers (slaves) will respond to by sounding their alarms. Both the master and slaves can also be actuated from our Node-Red cloud UI, which can turn the devices’ LEDs on and off, control their buzzers, update their firmware, and reset them.

Discussion

The most challenging aspect of our firmware development was getting everything integrated together successfully. Getting our peripherals working independently was not too difficult, but getting things to work together well was a challenge because of unforeseen interactions between them. For example, when we tried to integrate Wi-Fi with our IMU, we kept running into bus conflicts because both our IMU and the Wi-Fi chip on the SAMW25 were trying to occupy the same SERCOM (communications) channel. We fixed this by moving UART onto a different SERCOM channel and set of pins and moving Wi-Fi onto the SERCOM channel occupied formerly by UART. This required us to do some rework on our board to rewire UART. We would do several things differently for the next iteration of our device, such as:

  • Ensuring our pin mappings are correct and don’t conflict with each other.
  • Adding a “golden image” to the SPI flash chip for better robustness, and using an HTTPS download server for added security.
  • Adding more debugging headers to our board, especially for SPI and I2C. We ran into some hardware problems with I2C where the SDA line was stuck low due to a clock frequency issue. Having these headers would have saved us a lot of time in debugging.
  • Adding a cutout for the SAMW25 antenna. Right now, it awkwardly sticks off the top of the board, making it hard to put into a case.
  • Making a case for the board that would allow it to easily attach to a bike.

Built With

Share this project:
×

Updates

Jack Harkins posted an update

Explanation of IOT Device

We have developed a smart bike theft tracker that sounds an alarm and alerts other devices in the area if a bike is being stolen. Users can attach the device to their bike, park the bike, and arm the alarm. While the alarm is armed, an accelerometer and gyroscope monitor the acceleration and rotation of the bike. If the bike moves around too much, a buzzer goes off to alert other people in the area, and the device also sends a notification over the cloud to alert the user. We decided to take on this project because Jack likes to ride his bike to class every day, and he wanted to develop a way to know if his bike was safe.

Bootloader Implementation

Our bootloader works by checking the boot flags to see if a firmware update is ready to be copied into the NVM of the SAMW25. If so, the bootloader performs a CRC check on the previously-downloaded image (stored in SPI flash) to ensure that it is still valid, copies the data from SPI flash to the NVM, clears the update flag, and resets the device. If the checksum or copy fails, the bootloader does not clear the update flag, flashes the LEDs to indicate an error, and waits for the user to manually update it. Future iterations of the device could include support for a “golden image” so that the user doesn’t have to manually service the device, as well as an HTTPS firmware update server for added security, to mitigate spoofing of the firmware image site.

Bootloader Flow Chart

Application Flow Chart (for firmware downloads)

Partition Tables

Cloud Connection

We use a Node-Red backend instance running on IBM Bluemix for cloud connectivity between the devices. The device that is attached to the bike (the master) sends accelerometer readings to the cloud every second. It also sends theft notifications to the receivers over the cloud, which the receivers (slaves) will respond to by sounding their alarms. Both the master and slaves can also be actuated from our Node-Red cloud UI, which can turn the devices’ LEDs on and off, control their buzzers, update their firmware, and reset them.

Cloud UI

Cloud Dashboard

Discussion

The most challenging aspect of our firmware development was getting everything integrated together successfully. Getting our peripherals working independently was not too difficult, but getting things to work together well was a challenge because of unforeseen interactions between them. For example, when we tried to integrate Wi-Fi with our IMU, we kept running into bus conflicts because both our IMU and the Wi-Fi chip on the SAMW25 were trying to occupy the same SERCOM (communications) channel. We fixed this by moving UART onto a different SERCOM channel and set of pins and moving Wi-Fi onto the SERCOM channel occupied formerly by UART. This required us to do some rework on our board to rewire UART. We would do several things differently for the next iteration of our device, such as:

  • Ensuring our pin mappings are correct and don’t conflict with each other.
  • Adding a “golden image” to the SPI flash chip for better robustness, and using an HTTPS - download server for added security.
  • Adding more debugging headers to our board, especially for SPI and I2C. We ran into some hardware problems with I2C where the SDA line was stuck low due to a clock frequency issue. Having these headers would have saved us a lot of time in debugging.
  • Adding a cutout for the SAMW25 antenna. Right now, it awkwardly sticks off the top of the board, making it hard to put into a case.
  • Making a case for the board that would allow it to easily attach to a bike.

Log in or sign up for Devpost to join the conversation.