Leaving yikes
News, Technical, Work ·Friday July 24, 2015 @ 22:47 EDT (link)
I was the Senior Development Manager for Firmware at Yikes, LLC for a little over a year. Before that, I also did some part-time contracting work for a few months, but they wanted me to come on full-time and we negotiated to an acceptable offer.
While I was there, I architected a system (if link is dead, search the web for articles on "hotel mobile key") I'm proud of, under constraints and complications that made it very difficult at times. I also designed and implemented the firmware and protocols for the in-door device in C++ (C++14, GCC ARM Embedded on Nordic ARM Cortex M0-based microcontrollers), including:
- interfaces with several locks (and elevators)
- Bluetooth (BLE) communication with phone and other devices
- dynamic configuration model
- event and status reporting (e.g., battery level)
- touch-sensing algorithm (capacitance)
- inside/outside detection algorithms (RSSI)
- over the air firmware updates, boot loader
- over the air debugging (GDB server)
- the security/encryption model (AES-CTR etc.)
- flash file system for storing updates (SPI)
- door open/close detect calibration/algorithm (magnetometer, I2C)
- live-streaming of various debug data (e.g., proximity, capacitance)
- robust message-passing protocols (UART, BLE)
- low-power optimization, shutdown/wake
- "buddy" memory allocator for determinism
Many of these also involved host-side Bluetooth (BLE) tools (using a USB dongle) written in Python. I also built the first Android mobile app that could access doors—my first mobile app—and then when that was easy, some debugging apps too. This position was a great learning (self-teaching) opportunity for embedded development, which was a good fit with my past experience with compilers, C++ application and protocol development, and driver development. Low-level development has always been of interest to me, and a device with an ARM Cortex processor and only a few kilobytes of RAM to play with is pretty low-level. There were also power constraints: consumption had to be low so that the battery life would meet hotel requirements: physically accessing the doors to replace a battery is expensive and disruptive (that's also why over the air firmware updates were developed). Other resource limitations included bandwidth (BLE, which was also expensive in terms of power) and persistent storage (for reports). These were complex problems to solve, or sometimes careful trade-offs, and I strove for elegant solutions to each one. At one point I took a spare device with Bluetooth support and threw a web server on it and created some web wrappers around the Python tools (with web sockets notifications, also new for me), and ran periodic automated integration tests via the web socket server too.
So this was fun, certainly, but I expected more than just an opportunity to teach myself another kind of programming (as useful as that has been; see future posts); that was not the whole of the position offered.
All the best to everyone there. I've provided a solid foundation but you have a lot of competition and they've already shipped.
Books finished: Snakes In Suits.
