Sony Spresense Bike Tracker

Understanding Pain Points

Over the last decade, Colorado (and the Denver area in particular) has seen huge changes as the population has boomed. As more people end up in the area, more infrastructure needs to be added to support them. One of the areas that needs expanding and upkeep is bike paths, as more people are moving away from car ownership. In addition, self driving cars are on pace to fundamentally change how people get around or even need a car for the majority of their travel.

While building infrastructure is one thing, understanding how it needs to grow in order to do it efficiently is an entirely different problem. In addition to this problem, there's continued interest in cities around the Denver area for bike sharing companies to expand their services.

To have a better idea of what already exists, we can look at the data provided by the State of Colorado and the Department of Transportation. Current bike routes in the city of Denver are mainly on-street riding alongside or in the middle of traffic, as designated by the purple and pink lines in this graphical representation of already existing bike routes around downtown.

Whereas in the suburbs, such as the town of Broomfield, where I live, most of the paths are in open spaces and parks, as shown by green paths. While this is great for recreational uses, these paths don't get many people to businesses or more practical locations.

There's currently one major company that handles bike rentals in the Denver area: BCycle, though others are trying to get into the market. The docking stations for bike rentals are mostly clustered in the downtown areas of Denver and Boulder, with some recently being added in the Broomfield area along highway 36 (near the Rocky Mountain Metropolitan Airport on this map)

Here we can see the huge disconnect in bike routes and paths available in the metro area compared to the services of bike rentals being provided.

In order to help with both the problem of improved bike routes/paths and expansion of bike rental facilities, I put together a prototype for a device that can track a rental bike's location as it is used, and then uploads that data to a datastore, which can then be used to compare routes taken by the user with routes that already exist. This project is fully documented here.

Advantage of Sony Hardware?

The main reason I would want to switch to the Sony Spresense hardware is that the SD card reader that I had used for offline data storage and the GPS module are baked in to a very small component, meaning the only additional piece of hardware that would be required is something for a network connection. As I've used Helium's hardware before, which is currently being deprecated for their new technology, I figured I'd give LoRa wireless a shot with the Spresense board.

Location Tracking

The Spresense board has support for location tracking using a built in GNSS module. Rather than rehashing the code here, it makes more sense to see what Sony has put together in their sample on GitHub and I'll go over the small part that I did differently.

The important difference between Sony's code and mine is in the following block

   Serial.print("Lat=");
   Serial.print(pNavData->latitude, 6);
   Serial.print(", Lon=");
   Serial.print(pNavData->longitude, 6);

Rather than printing the latitude and longitude, I wrote them to the SD card, as you'll see in the next section

One issue I did run in to is that I wanted to attach an external antenna, because no antenna is kind of hit and miss with how long it takes to get a position fix. This is possible by soldering on your own uFL connector to the board,

but I ended up holding off on this because their documentation has this big warning about voiding your warranty, and you never know when you may want to use hardware again sometime. For what it is, the GNSS component worked well enough.

Saving Data to SD Card

Luckily, writing to the SD card was super easy. After inserting an SD card into the expansion board, you can modify your Arduino program by including the SDHCI library at the top and creating two objects - one representing your SD card, and the other representing the file that will be written to

#include <SDHCI.h>
SDClass SD;
File myFile;

Then, in setup(), instantiate the File object in write mode

 myFile = SD.open("log.txt", FILE_WRITE);

Finally, you can write the location data to it by accessing the location data and printing it to the file

if (myFile) {
      myFile.print(pNavData->latitude, 6);
      myFile.print(",");
      myFile.println(pNavData->longitude, 6);
}

LoRa Gateway + Backend

This is where I really ran into problems. I first attempted to just import the RadioHead LoRa library to support my RFM95W module from Adafruit, but then learned that I needed to modify the library a bit because of changes to how Sony supported SPI (mainly around different function names for interrupts). Once I finished that, I ran into additional issues with TCCR1A not being declared for the board. While messing around with that, I reached out to some others to see if they had any luck, but most responses were pretty similar with being unable to connect the devices directly to the Internet or another wireless signal without going through an additional MCU that already worked with a network. This is possible via Wire, but isn't what I wanted to do.

Since there's no point in using the Spresense board for this project if I need to bring in another Arduino board to make up for issues, I ended up stopping the project here after a few more tries to make LoRa work. The frustrating part here is that the LoRa modules work perfectly with Arduino Unos, so it was hard seeing something have the potential to work out, and then not pull it off. It is worth noting that I had another project I was going to work on also using this board, but it also relied on being able to connect back to the Internet (that is the tricky part to the Internet of Things, isn't it? :P)

On the plus side, I did get to dig a lot deeper into the LoRa module libraries and antenna theory (antenna theory was more of a side 'oh, that seems really cool' rabbit hole that I fell down, and not as related to developing for this board), so this wasn't a complete loss for me.

Conclusion

Overall the board is OK, but didn't live up to the hype for me. This isn't to say it isn't the perfect board for other projects/users, but just didn't pan out for me. The documentation is a beast, and not being able to use more complex peripherals very easily have been the major downsides to it. I did play with the image recognition sample a little bit, and that wasn't too bad, plus the GNSS and SD card being available on the expansion board were pretty nice. If I had been able to more easily run existing and well known Arduino libraries, this project would have been a blast, but as it was I cut it a bit short rather than spending my hobby time swimming against stream on something that should have been straight-forward.