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

"Security Is Our Top Priority" is BS

First published on
A couple of years ago I was asked to give a conference talk about software security. Well, actually I wasn't really asked, my company bought a sponsorship package with a speaker slot and I replied to the internal email asking for volunteers  🤣  Anyway, while preparing my talk, I realized a couple of important points about security that have not left my mind since: Security is limitless . You can always spend more effort to make things more secure. The same goes for quality, safety, employee happiness, etc. The needs of security are opposed to the needs of a convenient user experience . Improving one typically hurts the other. Now some organizations say "Security is our #1 priority". Really? You want to make something that has no limits your number one priority? I mean security is a good thing, but this seems a bit too simple? In fact, hollow marketing claims like that can make me a bit angry. In this post I'll help you understand what to make of statements like that...
Read more

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 long long tail of AI applications

First published on
Image
Last year multiple companies asked me for advice. " We are evaluating this AI powered product, but do you think it makes sense at all? It seems a bit niche and we think ChatGPT might make this entire thing obsolete soon. " Long tail - credit to Wikipedia My answer so far has always been: "No, bare LLMs are not going to compete with this product." I think that people are failing to understand the distinction between different classes of AI companies. I see it like this: Foundational AI - creating models like GPT-4 (text), Sora (video) etc. Applied AI - using existing models to create smart applications. Note that there are also companies not focusing on AI - they will start lagging behind, let's forget about them ;) There are orders of magnitude  (!)   more companies that will deal with Applied AI than Foundational AI, and they will be very busy for decades to come. Here's why: To get the most out of LLMs, you have to ask the right questions. LLMs have acc...
Read more