The world's first Cowboy key-fob

First published on

Last year I got my Cowboy 3 e-bike and I love it. Every day I start riding the bike it feels great, it makes cycling even better than it already is. My only gripe is unlocking the bike with the app, which takes about 15 seconds. This post is about how I built a BLE powered 3 button key that unlocks my bike, and the physical key unlocks the battery.

Here it is in action:



Is it faster? Maybe. But cool? Definitely.

But why?

tldr: It doesn't make sense, but I learned a lot and it was fun.

I used the official Cowboy app with a cheap Android phone (Moto G7 Play) and also an my wife's iPhone SE (both first and second gen). On the iPhones the Bluetooth works a lot better, once the app opens it's almost instant. But: unlocking takes about 15 seconds: taking your phone out of your pocket while you're fiddling with the lock (7s), finding the app (3s), opening it (3s), unlocking (2s). If you do this 2 times a day for 365 days it will take 3 hours. So, I decided to spend a week and a couple hundred euros building a solution for this... :D

Goal

I wanted the experience to be more like my car key. So, I set out to build a foldable key fob with 3 buttons: turn on, turn off, toggle the lights. The physical key should unlock the battery.

Here is the result:

Starting with ESP32

First I built a prototype with an ESP32 dev board using the Arduino IDE. Got everything working, but then figured out that even the separate chip would never fit in a car key enclosing and could not be powered by a CR 2032 coin cell, as the ESP requires quite a lot of power. I have to say that the ESP32 was a joy to program. Learning about BLE GATT took some time, but then copying the commands and UUIDS from the Bronco Unleashed source code was super easy. But anyway, in the end it didn't work because of the power constraints.

Going for nRF52

After doing some more research I found the nRF52 ecosystem. The chips are tiny and very low power. It should easily be able to last a year on a CR2032. However, the programming experience was much much worse than the Arduino IDE. There is a big migration from the nRF5 SDK to the nRF Connect SDK, and most posts don't mention this. Also, the IDE targets SVN instead of GIT., it is all very niche. Nevertheless, after a couple of weekends I got it to work.



*note -> this was a prototype, the version I'm using now uses a proper PCB. Look at the github repo for more details.

Ingredients:

  • Fanstel BC805M or BT832A, I tried both, the cheaper one is good enough.
  • 3 buttons
  • A led + resistor
  • A CR2032 or CR2025 3v coin cell battery
  • Diodes for routing power only when the buttons are pressed
  • Car key fob shell, look on eBay
  • Source code (also contains the ESP32 code)

Needed tools:

  • nNR52-DK for debugging and flashing the chip
  • Glue gun
  • Dremel for cutting out the original key and for making room in the new key fob shell

Learned:

  • The nRF toolkit plus horrible cMake configuration options...
  • Sniffing BLE network traffic
  • Brushed up my skills in C, soldering micro connections, electronics
  • That the bike sends a trip summary even without the app! The full route details are not there, but the distance and destination is recorded.
    • Update: untrue, I did not unpair my phone so in the background it would sometimes connect, get the latest trip data and synchronize with the Cowboy servers. After unpairing my phone completely, the trips did not show up in the app anymore.
  • Battery usage profiling is difficult. The battery would drain in a couple of days. I solved this by using diodes to only power the chip while a button is pressed. As this takes +/- 2 seconds it also prevents against some accidental presses.

Next steps..

  • For some weird reason I can't switch the lights on and off. See this thread 
    • Solved! I figured out that you need to be subscribed to the notify of the UART RX characteristic. Updated in the (horrible!) source code.
  • Now that the light is solved, I'd like to toggle it. The next question is how to decode the Dashboard service data. This is variable length and will require some reverse engineering or insider knowledge ;)
    • Solved too! You can read out the memory.
  • It's very important for me to switch between speed limits 24km/h and 25km/h by pressing a combination of buttons.
    • Solved too.
  • Obviously this project is not complete without some kind of "beep beep" sound when unlocking. I don't think the Cowboy has a speaker, but this has to be fixed somehow.
  • Update: The battery is not replaceable as I could not fit this into the existing enclosure. I went on and designed my very first custom PCB that will allow for user replaceable batteries. Currently waiting for the components and will do a follow-up post once everything works.

Comments

Post a Comment

Popular posts from this blog

AI programming tools should be added to the Joel Test

First published on
Here's a wake-up call to all CTOs: AI programming tools are getting freaking amazing and if you don't allow your teams to use them somehow, it will bite you in the ass in a couple of years. You will be slower and you will lose your best people. The infamous Joel Test is a list from the year 2000 of 12 things all great software companies do. Since then most companies have implemented Git and CI/CD, checking of three items, so we have some space left in the 2024 update ;) I believe "Do you allow your developers to use AI assisted development environments?" is a necessary addition. I get that you don't want your source code to end up on some OpenAI / Microsoft / Github server somewhere, sure, but find a way to use your own models or learn to live with it. Note that this is often not the same as "#9 - Do you use the best tools money can buy?" as blocking AI tools is about data security, not money. So why do I think developers need AI programming tools? I&#
Read more

The unreasonable effectiveness of i3, or: ten years of a boring desktop environment

First published on
Image
My wife uses Windows and over the years I've helped her move things to new systems. Win8, 10 and now 11. With every change the UI changes. Now I can't right click the bottom right corner anymore to open Task Manager. The UI feels "fresh" and up-to-date I guess, but does it really matter? My desktop has looked like this since 2008. I love the picture of the gearbox, it's a testament to the hidden precision engineering that goes on inside the built world all the time. I don't see much of the gearbox though, because most of the time my screens look like this: The environment around my background picture has changed a little more, but has been stable for the last 10 years. My experience is very different to my wife's constantly changing system. In 2009 I moved from Windows to Ubuntu, then to Debian using Gnome. Then finally to i3 in 2013 after a brief affair with XMonad in 2012. So by now in early 2024, I've had the same minimal UI for more than 10 years,
Read more

Idea time: RFID+E-Ink, electronic price tags without batteries

First published on
I got this idea years ago, somewhere in 2004 after I had heard both of RFID and E-Ink. The order is irrelevant ;) The idea is simple, we take: 1) RFID readers, which send radio waves to tags, which pick up some of the energy in the wave, do some computations and send a reply. The tags are brilliant: no batteries, no connected power source of any kind except for the antenna. 2) E-Ink displays, which need power only to change pixels. After the power is cut off, the pixels remain in their current state. The result: a small tag with a display. The display gets initialised and updated by an RFID-reader and after that retains its state indefinitely. Perfect for price tags on shelves in supermarkets, which need to be updated every now and then but are hellish to replace. I soon found out in 2004 that Epson had already done this:  http://gizmodo.com/026090/epsons-electronic-ink-%252B-rfid--21st-century-price-tags
Read more