Benjamin Wiegand

  There is a practice known as "de-Googling" a phone. This is where you take a normal Android phone and remove, disable, or in some cases replace Google's pre-installed services and apps to enhance battery life, security, and privacy, while making yourself less depenant on Google.

When de-Googling my phone, I noticed that there was no alternative for Android Auto, leaving me with 3 choices:

1. Install the real Android Auto and a subset of Google services and apps to make it function.
2. Suck it up and admit it was a mistake to purchase a headunit with the intention of using it with Android Auto.
3. Create my own alternative to Android Auto, re-implementing the entire protocol from scratch with little to no reference and certainly no official documentation.

  Currently, the project is still a work in progress, but as you can see by the below images, I do actually have a working implementation already. Geargrinder works by connecting to the headunit over the USB accessory API, giving it two USB bulk endpoints that can be used to transmit and recieve raw bytes to/from the headunit. Everything else from then on is fully re-implemented from scratch. I won't go into the implementation details otherwise this entry would be a literal novel, but feel free to check out the code or email me with any questions.

  Due to some limitations of the Arduino version (see BattMITM 1.0 section below for more info about that version), this version uses a much more capable RP2040 microcontroller. I was driven to make this upgrade after repeated shutdowns due to the Arduino being too slow to keep up. In order to do this, I had to rewrite all of the code, so I figured I would also make it open source while doing so.

  This verison features a more complex user interface with more battery information, more buttons, marquees, and an always on display. Everything from the data structures to the display driver was written from scratch in C using the Pi Pico's C SDK. For more details and a diagram of how everything is connected, see the project repository.

  Web Presentation Clicker is a browser extension that a fellow classmate and I worked on for the Web Applications course. It allows you to control your Google Slides or Office 365 slideshow presentation in your browser with your phone without having to download an app. The extension displays a QR code when opened, which both acts as a convenient link to the clicker webpage and contains the necessary pairing data. Once scanned, you are presented with two left and right arrow buttons that can be used to control your slideshow.

  To relay the slide change events to the browser extension, a server is used. The extension opens a wbsocket connection with the server, and the clicker (currently) sends REST API calls to the server to switch slides. A websocket-based clicker API has been implemented in the server but I have yet to add it to the client. The actual "clicking" of the presentation is done by simulating the arrow keys with javascript in the browser window.

  The server is written in python and consists of two components. A multiprocess uWSGI application that opens and maintains the websockets and accepts the REST API calls, and a multithreaded "session server" which keeps track of the presentations and routes the "click events" between the multiple uWSGI processes. The two communicate using unix domain socket connections, ensuring minimal overhead.

  I worked on the server and the extension while my classmate David worked on the landing page and the project reports. You can view our work on the github org. You can even host your own server if you want.

  PeerCord is a project I worked on during freshman year with my fellow classmates at University of The Pacific for the Application Design course. It is an end-to-end alternative to the popular chat app known as Discord. It has a similar server/client model, but the key advantage over Discord is that the messages are end-to-end encrypted keeping them private from even the server that hosts Peercord, or any data breaches. It is written 100% in Java, per the course requirements. It was a very large project and my key role was to write the entire server application. I also wrote the code to connect the client to the server. We completed the project and did very well.

  Fast ILO Exporter is a quickly thrown together Python project that I made over the course of a few days to export metrics like temperature, fan speed, power draw, drive status, memory status, health, and more from my HP server with an ILO4 controller. I built it after finding out that all the pre-existing solutions used the ILO's HTTP API and were extremely slow, requiring scrape intervals ranging from 1-5 minutes. For my purposes, such a delay is not satisfactory.

  My implementation uses SNMP to grab most of this information, which ends up being significantly faster, easily achieving the 15 second scrape interval that I was after. The exporter also optionally fetches some minimal information not available over SNMP using the HTTP API, and maps it with the values received over SNMP. Even with all the HTTP functions enabled, it's still able to achieve my 15 second scrape interval since it only has to make 2 HTTP requests.

  After purchasing a 10 year old ThinkPad T420 on ebay, I decided that the battery life could be better. I decided to make a ridiculously large battery using cells intended for electric cars. Coming in at around 189 Wh, it gives about 6-11 hours of battery life with moderate usage and 3-6 hours when compiling Firefox on all cores. To do this properly, I had to modify the BMS' calibration data so it didn't freak out when the battery more than doubled in size.

  Since I didn't want to drop $600 on an SMBus battery programmer and subscription battery repair software, I used the I²C line in my laptop's VGA port and wrote most of the software by hand. Through this, I became familiar with SMBus and SBS (Smart Battery System) 1.1 specifications, the protocol and spec used by the laptop and battery to communicate.

  Using this knowledge, I added an Arduino which captures and relays the data sent between the laptop and the BMS. The Arduino also requests and captures some extra information intended for the laptop's EC (embedded controller). This information includes cell voltages, temperature, instant pack voltage, instant current draw, charge/discharge cycle count, alarms, and more, some of which is very useful for verifying the health, age, and balance of my custom battery pack. Finally, I added a small OLED display and a button to show all this info without needing a USB serial cable.

  This is a project I worked on for my AP Computer Programming course in highschool. I wrote an Android app in Java which turns any Android smartphone into a security camera. It syncs with a server (also written in Java) over an encrypted TCP connection to store recordings and motion events. The cameras can also be viewed live by another phone over an encrypted UDP connection. This differs from many readily-available solutions as the server is on your local network, ensuring the likely very personal footage can only be viewed by you. Additionally, the recordings still happen even if the network drops out, unlike with traditional IP cameras.

  This is a personal project I worked on in middle school where I wanted to remotely control my Roomba from my laptop with a video feed. I connected an Arduino to the Roomba's diagnostic port, paired with a Raspberry pi running an Apache2 web server with PHP and a motion video server. The pi hosts a website over Wi-Fi which allows any modern web browser to view the video feed and send serial commands to the Arduino. The Arduino then sends its own commands outlined in iRobot's SCI specification to carry out control of the Roomba. The Arduino also receives and parses data from the Roomba for safety features such as cliff detection.