Electronics on William Floyd (high-quality images)

DIY Solar Battery Backpack for the XTEINK X3

William Floyd — Wed, 30 Sep 2026 00:00:00 +0000

I love my XTEINK X3 (running Crosspoint), and wondered if I could make a quick and dirty solar backpack for it. I planned a better writeup but here I am anyway not letting perfect get in the way of done.

Pictures

Battery

Mold/Pour

Pour Results

Magnets

Final Result

Notes

Thin batteries are hard to get in low quantities
A thinner solar panel would be really helpful
I need to get my 3D printer running again - a printed shell + fixture to hold pogo connector would save a lot of work
Next time will avoid the epoxy itself being the rear surface - sanding flat was a lot of work, and imperfect
Charge time and efficiency are likely quite poor
Silicone tape seemed to work nicely for the battery, but robustness/actual affect untested
Getting the reed switch positioning correct is a pain when the backpack itself needs to carry it’s own magnets - maybe look at pogo-pin style switch?
A custom PCB could help reduce thickness/complexity
- As a fallback, a carrier PCB for modules would be trivial and inexpensive
I started designing a CNC case for this with the intent to do another spin, but a few things put it on the backburner:
- Space constraints are tight, case will likely still be thicker than I want
- The X3 already has excellent battery life, making this a novelty more than a useful item
- I have too many other projects in-flight

BOM

Part	Role	Notes
5V 150mA polycrystalline solar panel (~89 × 61mm)	Charging input	Close to the footprint of the X3’s back - I very much doubt 150mA claim
CN3163 mini solar charger board	Battery management	Linear solar-tracking charger, 4.4-6V in, 4.2V out
TPS63020 buck-boost module	5V output	Fixed 5V via a solder jumper, has an EN pin
303450 LiPo pouch cell, 3.7V 500mAh	Energy storage	Roughly doubles the X3’s onboard capacity
Molded reed switch (N/O)	Magnetic power switch	Enables the boost converter only when attached
4-pin 2.54mm magnetic pogo connector	Output to the X3	Matches the X3’s charging pin pitch
BSI slow-cure epoxy	Potting
Silicone tape	Battery sock	See below

I used silicone tape to seal the battery so as to prevent epoxy doing anything to the battery - I’ve not tried encasing a cell in epoxy directly, but the heat and shrink/expansions scares me and this is what I landed on that would allow some amount of squish.

Antlion ModMic Wireless Battery Swap

William Floyd — Fri, 24 Jul 2026 00:00:00 +0000

I’ve used an Antlion ModMic Wireless since I started my first job (where I regularly took calls 6+ hours a day). Over time, its runtime has dropped from a full day to about half, and Antlion doesn’t sell replacement batteries, so officially my only fix was a new mic. But it’s held together with just three screws, so swapping the battery is easy enough (took me 15 minutes).

The base of the mic is a two-part plastic body held together by three small screws, with nothing glued.

The cell is a 502030 LiPo cell (3.7V, 250mAh, dated 2022.04.22), stuck with double-sided tape and soldered to two pads. That “502030” is the cell’s size (5 x 20 x 30mm), which is all you need to find a replacement. I ordered a replacement 502030 from Amazon ($8 after tax). Unfortunately there’s no space to choose a larger size.

Mine came with a JST plug, so I snipped it off (don’t cut the wires at the same time!). The old cell comes off by desoldering its two leads and working a piece of cardstock underneath to release the double-sided tape without damaging the old cell. The replacement goes in the same way - leads soldered to the same pads, and taped down in the same spot. Screw it together the same way it came apart.

$20 pen plotter

William Floyd — Sun, 26 Dec 2021 00:00:00 +0000

This was the final assignment for my second semester freshman engineering class (IEP 2). Budget given was $20, and my teammates and I decided a pen plotter would be a fun project. Here are some photos mostly of the final results

Analysis of a 2005 Nissan Altima Remote Keyfob

William Floyd — Fri, 08 Jan 2021 00:00:00 +0000

I got my first car a few months ago - a decidedly beat up North American 2005 Nissan Altima. It came with a remote keyfob, but something was shorting internally, and the battery would drain within a matter of hours. I ordered a two-pack of aftermarket fobs from Amazon, paired them no problem, and that was that.

After a while though, I got to thinking, how might I connect my car to my Home Assistant system? I am reluctant to tap into the CAN bus directly, so instead I am going to investigate utilizing the same method as my remote fob. Specifically, I want to program my own “fob” using an Arduino and a RF transmitter (spoiler: I cannot, at least for now).

The Hardware

While I may analyze the original fob at some point, for the time being I shall work from the aftermarket fob. Opening the casing reveals a rather simple circuit (front, back) - battery contacts, four buttons, a smattering of passives, an oscillator, the main control chip, 8 test points, and an antenna trace running around the perimeter of the PCB.

Rather unhelpfully, the control IC is unmarked, so either I’ll need to wait until I can look at the original fob to find any clues, or try to find what I need online.

As a note, it should be easy enough for me to replace the buttons with an electrical solution controlled by an ESP8266 or similar - I may end up doing this some day. For the time being, however, I have nothing to glean from the hardware in my fob.

Research

A quick look at the Amazon listing for my fob already tells me what models of fobs it replaces: KBRASTU15, CWTWB1U758, and CWTWB1U821. Matching other listings, my specific model is the KBRASTU15. This is actually an FCC ID, so that’s my next lead.

This fccid.io listing is rather useful, providing original FCC images and documents. Unfortunately, the internal images are low enough resolution to prevent reading the IC silkscreen. Interestingly, the aftermarket fob has a small fraction of the part count of the original fob, while still functioning perfectly. The most useful available document is the Technical Description. This is where we start to get somewhere.

In essence, the fob emits a wakeup sequence ‘A’, followed by sequence ‘B’ repeated as long as the button is pressed. The structure of these sequences is also described - sufficient to say, it uses a rolling code system. Importantly for my analysis, the encoding method of the signal is given (though interestingly their diagram annotations seem to be incorrect).

With this information in hand, I ordered a cheap RTL-SDR (a Nooelec NESDR Mini 2+).

SDR Analysis

The radio, being a North American model, operates at 315MHz. Using Universal Radio Hacker, I began capturing examples of locking and unlocking signals. Using the software is outside the scope of this post, but I found some YouTube videos by the software author that proved to be useful - it’s not hard to learn to use.

Ultimately, I ended up trimming down 4 ‘B’ sequences each of locking and unlocking (that is, different presses, not repeats during the same press). I also opted not to include the preamble and header of these ‘B’ sequences, as these are the same for any fob and include no actual information.

The resulting signals varied in length and followed no apparent repeating format - this is where the encoding scheme described in the FCC documents comes in. Fortunately, URH allows specifying and chaining encoding schemes, as well as calling external software to decode the data. As I am not dealing with a large amount of data, I wrote a quick bash script to decode the data:

#!/bin/bash

lc=''

while IFS= read -r -n1 c; do

        if [ "${c}" == '' ]; then
                break
        fi

        if [ "${c}" != "${lc}" ] && [ "${lc}" != '' ]; then
                echo -n "${lc}" # Deal with the last character
                lc="${c}"
        elif [ "${lc}" == "${c}" ]; then
                if [ "${c}" == '0' ]; then
                        echo -n '1'
                else
                        echo -n '0'
                fi
                lc=''
        elif [ "${lc}" == '' ]; then
                lc="${c}"
        fi

done <<<"${1}"

exit

This does the trick, and all the data has a uniform length of 67 bits. While the document specifies 66 bits, perhaps the aftermarket keyfob adds an extra bit. In any case, this extra trailing bit is always 0.

Finally we have something like this:

The top four entries are when locking, the bottom four when unlocking. The highlighted segments from left to right, as per the technical document, are:

encrypt
serial number
function code
verify code

It can easily be seen how the intent of the button press is not encrypted, but is part of the function code near the end. Also, the serial is correctly defined, as it does not change at any point. I am not sure what the verify bits are present for - perhaps if an error occurs the encoding scheme would result in a non 0 result (though this is purely speculation).

What we know now is that the keyfob does indeed use a rolling code algorithm, though not which one (web searches do not seem to specify).

More Research

I do not have access to the original keyfob at this time, so some image searching may be in order. Several leads appeared, but the main one was this:

None of the text appears especially legible, so the first thing I can do is compare the logo on the OEM fob to existing rolling code chip manufacturers. As it happens, Microchip is the company in question, producing the widely documented KeeLoq product line (leaked spec sheet). Looking at their product lines, it becomes clear that the original fob uses the HCS361 chip. My aftermarket chips must be using a knockoff or unmarked version of this.

Hurray, we know what chip we’re up against, what algorithm it uses, and how to get the information of an existing fob. What we do not know is how to program our own chip (or software equivalent). This is where things get a lot more involved than I have the expertise to do.

What would be required would be the Nissan manufacturer code for this series of fobs. Try as I might, these do not seem to have leaked online, nor have any other manufacturers as far as I can tell. Speculating, perhaps those that have access to these codes either keep them to themselves for ethical reasons, or because there is financial incentive to keeping this information private. Clearly there are Chinese manufacturers who know what this key is, because it would have been required in order to program this fob.

Key Problem

So how might I find this manufacturer key? Curiously, I cannot even find reference to Nissan ever using KeeLoq, so that does not bode well. Trawling the recent NA Nissan git leak doesn’t reveal anything related to such a key. The consensus seems to be that a power analysis of the receiver is required to determine the manufacturer key. While apparently not difficult for the researchers, it is beyond my means at this stage. I am certainly not the first one to try this.

The way forward would seem to buy a spare ECU for my vehicle and to use a ChipWhisperer and attempt to learn how to do power analysis. I don’t have the time or resources (or frankly the need) to do that for now, so I think this is where my journey ends. I’ll update this if ever I can get my hands on the manufacturer key and do anything more with this.

DIY 'Smart' Coffee Maker

William Floyd — Sun, 05 Jul 2020 00:00:00 +0000

I have recently (last couple months) been getting into home automation, specifically using Home Assistant. I also wanted to get a coffee maker that used K-Cups. Thus the goal was born - to get a coffee maker working with Home Assistant, such that I could automate it to fit my morning routine.

I first searched for new coffee makers, looking to see what the easiest ones would be to hack into and automate. I got so far as adding a sleek new brand name model to my Amazon cart, but thankfully reason and frugality prevailed! Instead, I opted to swing by the local Goodwill the next day, to see what secondhand options might be available. As luck would have it, I found a no-frills, single button coffee maker for the princely sum of $4, and I was on my merry way.

Later that evening, opening the black box up (thankfully I had the correct triangular screwdriver head), I found very easily hackable innards.

The control board (front, back) is very simple - two buttons in parallel, an LED, and a couple resistors. I’m not quite sure what the logic is upstream (it un/latches on each press), but the buttons short to ground, and this is something I can work with. The control board has wires for ground, signal, and 5V, in that order.

The ordeal of hacking into the thing, and my missteps trying to do so, is rather boring really, but it produced this:

The brains I added was a Wemos D1 Mini (thanks, Aliexpress!), with a 3.3V<->5V converter between to sense when the coffee maker is on, and also turn on a mosfet to short the button to ground. I initially had issues with the coffee maker turning on whenever I plugged the D1 Mini in, but a pulldown resistor solved this.

I also opted for an external USB plug - this allows me to possibly reflash this without opening the enclosure, and also meant I did not need to splice into the mains line inside, which I was reluctant to do.

I initially flashed and programmed the coffee maker with Tasmota, but almost immediately opted to use ESPHome instead. I like Tasmota and ESPHome, I was just able to get more fine control of the setup using ESPHome in this instance, especially concerning the button logic.

The (important) code is as follows:

binary_sensor:
  - platform: gpio
    device_class: power
    internal: true
    id: power_on
    pin: D2
    
switch:
  - platform: gpio
    pin: D1
    id: relay
    restore_mode: ALWAYS_OFF
  - platform: template
    name: "Coffee Maker"
    icon: "mdi:coffee-maker"
    lambda: |-
      if (id(power_on).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
    - switch.turn_on: relay
    - delay: 50ms
    - switch.turn_off: relay
    turn_off_action:
    - switch.turn_on: relay
    - delay: 50ms
    - switch.turn_off: relay

The beauty of the way in which I can detect signals and simulate a button press is that ESPHome senses when I use the physical button, and updates accordingly. I can use the coffee maker absolutely as normal, the ‘Smart’ part of it is optional.

The rest of my setup using this coffee maker is somewhat outside the scope of this post, but it includes using Tasker on my phone to run a ‘Wakeup’ automation on Home Assistant, which will - along with turning on my bed-head lamp, and switching my monitor on before putting it to sleep - check if I turned on a ‘Morning Coffee’ user input. If I remembered to prep my coffee the night before, and turned on the switch, I will wake up to a hot cup of coffee (or, the sound of a coffee-in-progress). I can also command Alexa and Google Assistant to do my bidding and make me a coffee. At least someone does what I want…

Truly, we are living in the future.

midiMixer - A simple Arduino powered MIDI potentiometer bank

William Floyd — Wed, 06 May 2020 00:00:00 +0000

This is nothing too special really - I wanted to try my hand at designing a custom PCB and assembling a device from scratch. GitHub for this project.

This story actually starts a while ago (perhaps 2015), when I got the desire to build a DJ control panel (with no knowledge of how to get into it). This never really happened, but it did lead me to get to know some DAW software, and experiment with it off and on. But in the back of my head I still wanted to build some hardware to help with this.

This eventually came about in the summer of 2019, when I finally hand-wired a simple 8 knob control surface. Truth be told, I actually built two. The first one had some issues (I wonder why…?), and would sporadically jitter values. The second one worked correctly, having been wired much more carefully.

Still, it was lacking professionalism, polish, and most importantly, robustness. The sandwich of 22AWG wire, cardstock and PCB was less than sturdy, so I promptly packed it away and never used it. Around this time also, I tried very briefly to learn how to use KiCAD, but didn’t get far at all. This would come to change, however, in April of 2020.

Fast forward close to a year, and here we are - toilet paper is the currency of the quickly collapsing Covid19 crazed world, and I’m back with my grandparents for the remainder of my semester (which, as of writing, is all but concluded). Finding my lack of a social life leaving me with a little bit more free time, and being home yielding a lot more distractions, I learned the basics of KiCAD from YouTube, and set out to design a simple PCB. My old MIDI controller project came to mind, so I set myself to it, and within a few days had my first Gerber files sent off to JLCPCB. In reality, I should have waited a bit and done a couple more design iterations before committing, but I guess $7 is the price of impatience.

So it was that my crisp PCBs showed up 3 weeks later - I had one assembled within the hour, and my old code dusted off and flashed within two hours. It’s really as simple as it gets - a Pro Micro hooked up to a 4051 analogue multiplexer, in turn hooked up to 8 potentiometers.

The potentiometers I had on hand ended up being a bit different than the footprints I had used, so I ended up having to clip the mounting tabs off of them. This, as one might imagine, made them extraordinarily flimsy, so I designed and printed a couple clamps to align and hold solid the potentiometers. These also have the added benefit of keeping the soldered pins off of whatever surface the mixer is on. Should the correct potentiometers be used, these would not be needed, though some feet or a case for the PCB would still be best.

This being my first PCB design, I am quite happy it worked out so well - I am studying for Mechanical Engineering, not Electrical… However, I see room for improvement. The potentiometers are too close together, and the rows are too far apart. The knobs barely clear the Arduino, and the Arduino is mounted far higher off the PCB than I would like. I see myself making a v2 in due course - perhaps next time I will try JLCPCB’s SMT assembly? I imagine adding indicator LEDs, improving the layout, and adding a button to switch between banks would make this much more useful.