Kennedn's Blog

Wanted to spy on my dog, ended up spying on TP-Link

Sat, 13 Sep 2025 17:21:20 +0100

I recently bought a cheap Tapo indoor camera to see what my dog gets up to when I am out of the house.

What actually followed? I ended up reverse-engineering onboarding flows, decompiling an APK, MITMing TLS sessions, and writing cryptographic scripts.

My main motivation for this project really stemmed from the fact that the camera annoyed me from day one. Setting the camera up in frigate was quite painful, no one really seemed to know how these cameras worked online.

SIDENOTE: If you want 2 way audio to work in frigate you must use the tapo:// go2rtc configuration for your main stream instead of the usual rtsp://. TP-Link are lazy and only implement 2 way audio on their own proprietary API.

One undocumented behavior that tripped me up was that the device’s API is supposed to accept credentials admin:<your-tapo-cloud-password> after onboarding. However after banging my head against a wall for a few hours I later discovered that if you change your cloud password after onboarding, paired devices don’t get the memo 🙂.

This implied a few things to me that started the cogs turning:

There must be a call made during on-boarding that syncs the device password with the cloud password
The device must either allow unauthenticated calls before this step or have some sort of default password.

So considering my onboarding woes and the fact that I was starting to recoil every time the tapo app tried to jam a “Tapo Care” subscription down my throat, a cloudless onboarding solution for the device was beginning to look more and more desirable.

The first step to cracking this egg was to be be able to snoop on what the app and the camera are saying to each other during onboarding. E.g, establish a man in the middle.

Man in the middle

To man in the middle a phone app, you must be able to route all http(s) traffic via a proxy server you control. Historically this has been quite simple to achieve, simply spin up a proxy on a computer, add the proxy’s self-signed certificate to the phone’s truststore, and configure the phone to point at the proxy.

However, modern phone apps can use a few nasty tricks to render this approach ineffective. Namely they will blatantly ignore proxies, throw the system truststore to the wind and make liberal use of certificate pinning.

The most full-proof technique for generically MITMing an app has therefore become dynamic instrumentation via tools like frida. What this allows us to do is force an app to use the proxies and certificates that we tell it to whilst batting aside it’s attempts to do things like certificate pinning.

So the setup ended up looking like this (full setup guide here ):

  ---
config:
  theme: 'base'
  themeVariables:
    primaryColor: '#00000000'
    primaryTextColor: '#fff'
    primaryBorderColor: '#ffffff8e'
    lineColor: '#fff'
    secondaryColor: '#fff'
    tertiaryColor: '#fff'
---
sequenceDiagram
    participant A as Tapo App <br>(with frida hooks)
    participant L as Laptop <br>(mitmproxy)
    participant C as Tapo Camera

    A->>L: Request
    L->>L: Record request
    L->>C: Forward request
    C-->>L: Response
    L->>L: Record response
    L-->>A: Forward response

After spinning up mitmproxy, injecting the frida scripts , and onboarding the camera, we finally see an initial login flow — before the admin password ever gets changed:

However, subsequent requests look like this:

{
  "method": "securePassthrough",
  "params": {
    "request": "bAhdgihJ9j6PrrknnbXWATBohGTZK5llv3MEzRcmoAmcxexmlVNz3OUX2r0h9a9EG/3X0tBpPi654T2+BjqVEOn2D178kokBpf8RQj01AvBZLYD5S5sFeaCXWiRXA7MgQUppROV4AbrU4f+GOM37KgPqT59qgLVja2slw6CzrKjPzOrG4Ho6Mu6wBa1xepcj"
  }
}

And responses look like this:

{
  "seq": 584,
  "result": {
    "response": "Gqz1wbXAig/3wL+kXzY2Ig3hq+JSYasYI7FXdMNZR5PyH8bpLX+GJqQbImUtby9IEj5HQDhxqcTa+dUqQjI0GaGCxuGHqmrgQ0FeyCTQjBiW5gslAPQG33wj44OOkAep"
  },
  "error_code": 0
}

So from this initial dive we have learned that:

Tapo 100% has a default password due to the fact that it performs a full login before it knows anything about the cloud password.
Tapo has an encrypted securePassthrough channel for its API calls to prevent peeping toms such as myself from spilling the beans.

The JADX dive

The next logical step is to decompile the apk in JADX and start rummaging around for a default password.

The initial login call that we captured references an admin username:

{
  "method": "login",
  "params": {
    "cnonce": "AD0E189F6E1BA335",
    "encrypt_type": "3",
    "username": "admin"
  }
}

Searching for "admin" in JADX gives us many hits but there are a few concentrated in a CameraOnboardingViewModel class that look interesting:

The function m98131y2 appears to be returning a password that is then passed to the new Account() call. Following this function up the chain, we hit gold:

We already know that the device is using encrypt_type: 3, so that means our default password is:

TPL075526460603

Teaching mitmproxy new tricks

With the default password now revealed, we have the cards in our hand to derive session keys and decode the securePassthrough messages.

The only thing that would help us further is if we had a reference implementation for the authentication flow. This is where PyTapo really came in handy.

Using PyTapo as a reference, we could dump the session state and encrypted messages from mitmproxy and write a script to do some static analysis on the decrypted requests and responses, but a really cool feature of mitmproxy is that it supports scripting itself.

What this means is that we can pass a python script to mitmproxy, and have it directly decrypt request and response payloads inline whilst running a capture.

So I wrote tapo_decrypt_pretty.py which:

Watches for the login handshake (cnonce, nonce, device_confirm)
Derives lsk/ivb session keys from it
Transparently decrypts subsequent API calls
Pretty-prints them inline in mitmproxy’s UI in request_decrypted and response_decrypted fields
Dumps them to JSON files for later analysis

Analysing the results

The complete list of calls made by the Tapo app during onboarding were:

getAppComponentList
setLanguage
scanApList
bindToCloud
changeAdminPassword
setTimezone
setRecordPlan
setDeviceLocation
connectAp
getConnectStatus
setAccountEnabled
changeThirdAccount

This boiled down to just four important calls:

scanApList — list Wi-Fi access points
setAccountEnabled + changeThirdAccount — enable RTSP/ONVIF account
changeAdminPassword — change from default password to the cloud password
connectAp — join the selected Wi-Fi access point

Everything else was fluff: timezones, record plans, binding to cloud.

Final thoughts

In the end, the prize for all this nonsense was a scrappy little Bash script, tapo_onboard.sh , which:

Logs in with the default admin password,
Scans and selects a Wifi access point
Switches off the obnoxious OSD logo on the camera feed,
Enables RTSP/ONVIF capabilities
Changes the admin password,
And finally joins the Wi-Fi.

Peeling this onion left me with a few observations on Tapo’s firmware.

Some endpoints use SHA-256 for hashing, while others cling to MD5 like it’s 2003.
There are two public keys used to send passwords to the device — one that is shared with the client and another super secret one that’s hardcoded in the app. The easiest way to figure out which one to use is to flip a coin.
Password syncing between the app and its managed devices is strictly vibe-based.

The whole thing feels like it was cobbled together by a consortium of couch-cryptographers. But then again, it was the cheapest indoor camera on amazon, so what did I expect?

And with all this said I did finally manage to figure out what the dog does when I am away.

She sleeps. On the sofa. Sometimes even in her bed.

Modchipping a fridge

Sat, 20 Jul 2024 09:43:48 +0100

I own a fridge that has a really cool ‘feature’. It beeps if the door is open for more than 60 seconds. 95% of the time this is more annoying than it is helpful. In my opinion it should just shut up and trust that I know best.

In pursuit of this behavioural change I first tried to get at the piezo speaker so that I could rip it out. This turned out to be rather fruitless as the main board is deeply embedded within the fridge. I am not really willing to rip it out of the wall to get at the main circuit board, although I did try to tunnel my way in behind the control panel without much success:

Something I did have access to however was a daughter board that acts as the control panel for the fridge.

Pwning the panel

To try and understand the attack surface and see if it was possible to somehow disable the alarm I reverse engineered the functionality of the control panel. It essentially has 2 features:

Button sensing (including a magnetic switch for door state detection)
Light control

Both of these features are acheived via 6 pin connector on the daughter board:

The connector is actually a serial interface which permits control of two 8 bit shift registers (74HC595) on the daughter board:

PIN	DESC
CLK	Clock input
DS	Serial data in
OE	Output enable
OUT/LAT	Dual purpose, read: output, write: latch
GND	Ground
VCC	Power, 5v

This setup allows the fridge control of up to 16 bits on the daughter board, some of these bits are allocated to a specific LED on the board. Some are used to read button state.

Each button is directly wired up to the OUT pin. This was initially confusing to me as it would mean the fridge would have no way of determining which button was actually pressed at a given point in time. But that is where the shift registers come in, the button will not produce a signal on OUT unless its bit on the shift register is currently enabled:

The sequence for reading a button is therefor:

Toggle the buttons enable bit on the shift register
Read the state of the OUT pin
Repeat for each button

I was able to prove this by having a Raspberry Pi don its freon cap and pretend to be the fridge. I was able to control the lights:

And detect button state:

Creating a modchip

Based on the findings from the control panel, there were a few methods of potentially disabling the alarm:

Automatically press alarm off when the alarm sounds
Hijack the magnetic sensor to tell the fridge it is closed

Controlling the alarm off button was a bit of a dead end for a few reasons.

The alarm off button did not work until the alarm was actually sounding.
The button makes its own sound when pressed, meaning if we pressed it on a timer we would be replacing one noise for another.
The control panel had no feedback for when the alarm sounded, meaning we couldn’t detect and press either.

Hijacking the magnetic sensor had more potential but one of the caveats of this method was that the internal fridge light is disabled when the fridge is in it’s ‘door closed’ state.

To work around this I decided to wait as long as was possible (~59 seconds) and then tell the fridge that the door just closed for around ~100ms.

I was originally going to opt for a microcontroller as the basis for my modchip but what we have just described is essentially a timing circuit. So the desired functionality is actually achievable with just a simple 555 timer.

555 timer

A 555 timer in an astable mode is exactly what we require. Astable means that the 555 oscillates between its on and off state on repeat. We can control the time spent in the on and off state with a couple of resistors ($$r_1$$ & $$r_2$$) and a capacitor ($$c$$).

To calculate the off time ($$t_0$$) we can use:

$$t_0 = 0.694 \cdot r_2 \cdot c$$

And the on time ($$t_1$$):

$$t_1 = 0.694 \cdot (r_1 + r_2) \cdot c$$

We ideally want:

$$t_0 = 59000\ ms$$, $$t_1 = 100\ ms$$

But the above math highlights an issue with this, by default the above arrangement only allows a selection of duty cycles between 50% - 100%. Even making $$r_1$$ as small as possible ($$220\ \Omega$$) will result in around a 50% duty cycle:

The solution is to add a diode across $$r_2$$ which actually allows us to reach duty cycles between 0% and 50%:

Adding the diode changes the formula for calculating $$t_0$$ and $$t_1$$:

$$t_0 = 0.694 \cdot r_2 \cdot c$$, $$t_1 = 0.694 \cdot r_1 \cdot c$$

Notice that $$t_1$$ is no longer dependant on the value of $$r_2$$.

The values for the resistors and capacitor I settled on were:

$$r_1 = 220\ \Omega$$, $$r_2 = 300\ k\Omega$$, $$c = 220\ \mu F$$

Plugging these values into the formula we get:

$$t_0 = 0.694 \cdot 300000 \cdot 220 \cdot 10^{-6} = 45804\ ms$$

$$t_1 = 0.694 \cdot 220 \cdot 220 \cdot 10^{-6} = 48\ ms$$

This is pretty close to the what we were looking for, So I built a ‘modchip’ using those same values of $$r_1$$, $$r_2$$ and $$c$$:

I then wrote a small script called time-delta.py to capture the real off time in a test circuit overnight. This actually got even closer to our desired time of around 59 seconds:

> python3 time-delta.py
avg=56.970      min=55.283      max=58.160

Perfect! The only thing left to do now was wrap it in copious amounts of kapton tape and reinstall in the fridge:

Finally, here is a capture of the modchip breifly driving the magnetic sensor high when installed in the fridge:

Great success. We learned how to converse with the fridge and told it to shut its gob.

Additional resources

Python Scripts

Using JSON without understanding it

Tue, 14 May 2024 11:10:53 +0100

This year I was gifted a Badger 2040W. This device is essentially a Pi Pico attached to a black and white e-ink display. The device is supposed to be used as a wearable badge. My use case was a little different however. I wanted a home automation controller.

This culminated in the restful-badger project, which permits an arbitrary number of RESTful ’tiles’ to be configured. Each tile can control and get state over HTTP.

The problem

One of the major design decisions for the software was that the tiles should be configurable. I chose JSON as the data format for my tiles, a given tile may look something like this:

{
    "name": "office",
    "image_idx": 1,
    "action_request": {
        "method": "POST",
        "endpoint": "/v2/meross/office",
        "json_body": "{\"code\": \"toggle\"}"
    },
    "status_request": {
        "method": "POST",
        "endpoint": "/v2/meross/office",
        "json_body": "{\"code\": \"status\"}",
        "key": "onoff",
        "on_value": "1",
        "off_value": "0"
    }
}

A major downside of using JSON however is that it is expensive to parse on an embedded system. But there is a way to have our cake and eat it too. A way to avoid the runtime cost of parsing JSON but still use it.

Enter the humble byte array

Something that C is very good at parsing is bytes. If we could encode our JSON into a structured byte array and feed those bytes to the microcontorller instead, most of the heavy lifting would be done before we hit runtime. All that would be left to do on our microcontroller is some book keeping to make sure the right bytes end up in the correct place.

The correct place being a couple of c structs, which will look like this:

typedef struct RESTFUL_REQUEST_DATA_ {
    char *method;
    char *endpoint;
    char *json_body;
    char *key;
    char *on_value;
    char *off_value;
} RESTFUL_REQUEST_DATA;

typedef struct TILE_ {
    char *name;
    char image_idx;
    RESTFUL_REQUEST_DATA *action_request;
    RESTFUL_REQUEST_DATA *status_request;
} TILE;

Most programming languages can work with bytes, so we can leverage a high level language such as python to encode the JSON file.

We have 2 types of data to encode in our example JSON, an integer and several strings. Integer encoding is trivial and involves simply appending the integer to our byte array directly:

For strings we must capture both the length and the contents of the string in the byte array to be able to effectively book keep later on in C:

Building on these concepts we can now encode our entire JSON example:

Using our binary data

We now have a binary format that contains all the information we need to be able to reconstruct the important parts of the JSON in C, but how do we get it into our C program? One method is to simply hard code it.

By adding a little bit of printing logic to our python code we can output c syntax for a char byte array:

Decoding the byte array

To decode the byte array in C on our microcontorller, we must traverse it whilst keeping track of our position. We can do this by simply incrementing a variable that we will call ptr.

We still only have 2 types of data to concern ourselves with. In the case of a single byte value, such as image_idx, extraction is simple:

static const char tile_data[102] = {
    0x06, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x01, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x74, 0x6f, 0x67, 0x67, 0x6c, 0x65, 0x22, 0x7d, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x73, 0x74, 0x61, 0x74, 0x75, 0x73, 0x22, 0x7d, 0x05, 0x6f, 0x6e, 0x6f, 0x66, 0x66, 0x01, 0x31, 0x01, 0x30
};
uint ptr = 7;

char image_idx = tile_data[ptr++];

To reconstruct a string however, we must use the string length provided in tile_data to determine how many bytes to malloc and copy:

static const char tile_data[102] = {
    0x06, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x01, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x74, 0x6f, 0x67, 0x67, 0x6c, 0x65, 0x22, 0x7d, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x73, 0x74, 0x61, 0x74, 0x75, 0x73, 0x22, 0x7d, 0x05, 0x6f, 0x6e, 0x6f, 0x66, 0x66, 0x01, 0x31, 0x01, 0x30
};
uint ptr = 0;

uint8_t str_size = (uint8_t)tile_data[ptr++]; // First byte denotes string size
char *name = (char *)malloc(str_size * sizeof(char) + 1); // Allocate memory
strncpy(name, &tile_data[ptr], str_size);   // Copy to alloced memory
name[str_size] = '\0';  // Null terminate
ptr += str_size;

We will perform this same string action many times so it makes sense to refactor it into a function call:

char make_str(char **dest, const char *src) {
    uint8_t str_size = (uint8_t)*src++; // First byte denotes string size
    *dest = (char *)malloc(str_size * sizeof(char) + 1); // Allocate memory
    strncpy(*dest, src, str_size);  // Copy to alloced memory
    (*dest)[str_size] = '\0';  // Null terminate
    return str_size + 1;
}

int main() {
    static const char tile_data[102] = {
        0x06, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x01, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x74, 0x6f, 0x67, 0x67, 0x6c, 0x65, 0x22, 0x7d, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x73, 0x74, 0x61, 0x74, 0x75, 0x73, 0x22, 0x7d, 0x05, 0x6f, 0x6e, 0x6f, 0x66, 0x66, 0x01, 0x31, 0x01, 0x30
    };
    uint ptr = 0;
    char *name;
    ptr += make_str(&name, (char *)&tile_data[ptr]);
}

Piecing this all together we end up with the following code that can decode our packed tile data into c structs:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "pico/stdlib.h"

typedef struct RESTFUL_REQUEST_DATA_ {
    char *method;
    char *endpoint;
    char *json_body;
    char *key;
    char *on_value;
    char *off_value;
} RESTFUL_REQUEST_DATA;

typedef struct TILE_ {
    char *name;
    char image_idx;
    RESTFUL_REQUEST_DATA *action_request;
    RESTFUL_REQUEST_DATA *status_request;
} TILE;

static const char tile_data[102] = {
    0x06, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x01, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x74, 0x6f, 0x67, 0x67, 0x6c, 0x65, 0x22, 0x7d, 0x04, 0x50, 0x4f, 0x53, 0x54, 0x11, 0x2f, 0x76, 0x32, 0x2f, 0x6d, 0x65, 0x72, 0x6f, 0x73, 0x73, 0x2f, 0x6f, 0x66, 0x66, 0x69, 0x63, 0x65, 0x12, 0x7b, 0x22, 0x63, 0x6f, 0x64, 0x65, 0x22, 0x3a, 0x20, 0x22, 0x73, 0x74, 0x61, 0x74, 0x75, 0x73, 0x22, 0x7d, 0x05, 0x6f, 0x6e, 0x6f, 0x66, 0x66, 0x01, 0x31, 0x01, 0x30
};

char make_str(char **dest, const char *src) {
    uint8_t str_size = (uint8_t)*src++;
    *dest = (char *)malloc(str_size * sizeof(char) + 1);
    strncpy(*dest, src, str_size);
    (*dest)[str_size] = '\0';  // Null terminate
    return str_size + 1;
}

void make_tile() {
    uint ptr = 0;

    TILE *tile = (TILE *)malloc(sizeof(TILE));

    // Name
    ptr += make_str(&tile->name, (char *)&tile_data[ptr]);
    // Image idx
    tile->image_idx = tile_data[ptr++];

    // Action Request
    RESTFUL_REQUEST_DATA *action_request = (RESTFUL_REQUEST_DATA *)malloc(sizeof(RESTFUL_REQUEST_DATA));
    tile->action_request = action_request;

    ptr += make_str(&action_request->method, (char *)&tile_data[ptr]);
    ptr += make_str(&action_request->endpoint, (char *)&tile_data[ptr]);
    ptr += make_str(&action_request->json_body, (char *)&tile_data[ptr]);
    action_request->key = NULL;

    // Status Request
    RESTFUL_REQUEST_DATA *status_request = (RESTFUL_REQUEST_DATA *)malloc(sizeof(RESTFUL_REQUEST_DATA));
    tile->status_request = status_request;

    ptr += make_str(&status_request->method, (char *)&tile_data[ptr]);
    ptr += make_str(&status_request->endpoint, (char *)&tile_data[ptr]);
    ptr += make_str(&status_request->json_body, (char *)&tile_data[ptr]);
    ptr += make_str(&status_request->key, (char *)&tile_data[ptr]);
    ptr += make_str(&status_request->on_value, (char *)&tile_data[ptr]);
    ptr += make_str(&status_request->off_value, (char *)&tile_data[ptr]);

    printf("Name: %s\nImage Index: %d\nAction Request:\n    Method: %s\n    Endpoint: %s\n    JSON Body: %s\nStatus Request:\n    Method: %s\n    Endpoint: %s\n    JSON Body: %s\n    Key: %s\n    On Value: %s\n    Off Value: %s\n",
        tile->name,
        tile->image_idx,
        tile->action_request->method, tile->action_request->endpoint, tile->action_request->json_body,
        tile->status_request->method, tile->status_request->endpoint, tile->status_request->json_body, tile->status_request->key, tile->status_request->on_value, tile->status_request->off_value
    );
}

int main() {
    stdio_init_all();
    make_tile();
    return 0;
}

Get the preprocessor to do it

We have now managed to convert a JSON file into a byte array, hardcode it and then decode it. We can go further however. If we are using a build tool such as CMake. We can simply instruct it to run the python script on our behalf:

set(JSON_FILEPATH "${PROJECT_SOURCE_DIR}/config/tiles.json" CACHE STRING "Location of tiles json")

execute_process(COMMAND "${PROJECT_SOURCE_DIR}/tools/json_to_c_array.py" "-f" "${JSON_FILEPATH}" OUTPUT_VARIABLE "TILE_DATA")

target_compile_definitions(badger PRIVATE 
    TILE_DATA=${TILE_DATA}
)

This symbol can then be referenced in our C code and replaced with our bytes by the preprocessor at build time:

static const char tile_data[] = {
    TILE_DATA
};

The techniques discussed in this blog post were utilized and expanded upon to create restful-badger . Hopefully, someone will find them useful for their own project. Happy coding!

Hijacking infrared to make a dumb device smart

Sat, 26 Nov 2022 21:44:40 +0100

I own a very old ‘flat’ screen television from 2009. One of the reason this TV is still kicking around is because I have a strange sentimental affection for it. Another is that I have written automation for it that works really well and it would be a pain to migrate away from it.

It does have a problem however, the TV tends to hit resonance frequency very often with its built-in speakers, causing the body of the unit to vibrate something awful and produce some ear wrenching sounds as a result.

So, to extend the longevity of this relic, I decided to invest in a cheapo soundbar, the Majority Snowdon II . This has worked to fix the resonance issue but has somewhat moved my problems laterally as it came with its own caveats. Namely, its a big dumb dumb.

That’s right, it’s not a smart device, its about as dumb as they come in 2022. It has an infrared remote, some physical buttons and that’s it! However, I had a plan when I bought this device. I thought I could probably make it smarter. So after losing the remote down the side of the couch for the 87th time I decided to crack it open and see what could be done.

Table of Contents

Start

My original intentions when cracking this open was to start looking at datasheets for on-board chips to try and find a foothold somewhere on the board. However, looking at the mainboard, I was very quickly struck with an idea.

There are two very cleanly labelled connection jacks that go to the daughter board. And the daughter board just happens to host all of the interfacing options on the device: the physical buttons, an indicator LED and the infrared receiver.

So lets just hijack these pre-existing interfaces for our own purposes!

Plan of Attack

Now that we know the project has some feasbility, lets lay the ground rules for what success will look like. We want to be able to

Get the current state of Snowdon using the RGB lines from the status LED
Mimic the signal coming in on the Infrared line so that we can send our own infrared commands to Snowdon

We also want to have control over the new super powers we will bestow upon the Snowdon. At this point, I had already earmarked the Raspberry Pi Pico W as the microcontroller of choice for this project for a few reasons:

It has a WiFi chip, which means we can turn the snowdon into a true IoT device
It has Programmable IO , which means we can write our own driver for the Infrared signalling.
It accepts 5v power in, which means we can power it directly from the mainboard
I had a bunch of them in my desk drawer 😀

Decoding the Indicator LED

The daughter board has a 4 pin RGB indicator LED that can display a number of colors. The LED is common anode which means it is active low. Each of the 3 color pins are broken out on a connection jack on the mainboard. The user manual actually tells us the possible colors and their meaning too:

State	LED Indicator Light
Power Off	Red
AUX Mode	White
Line In Mode	Green
Optical Mode	Yellow
Bluetooth Ready	Flashing Blue
Bluetooth Connected	Blue

This is enough information for us to decode which color is currently being displayed on the LED and infer a state from it.

We can achieve this easily by wiring 3 consecutive GPIO pins to the mainboard.

Wiring

Code

Since we are only concerned with 3 pins (17,18 & 19), we can create a 32 bit bit-mask that will select only these pins:

#define RGB_BASE_PIN 17
const uint32_t RGB_MASK = 1 << RGB_BASE_PIN |     // Pin 17
                          1 << RGB_BASE_PIN + 1 | // Pin 18
                          1 << RGB_BASE_PIN + 2;  // Pin 19

Then in our main loop we can initialise the pins as input with our mask:

gpio_init_mask(RGB_MASK);

And then get the current value of each of the 3 pins by ANDing the value of the GPIO register with our mask. We then shift this to the right to clear out the left over zeros from our AND operation and end up with a 3 bit value representing our 3 color lines:

// Extract desired bits from GPIO with RGB_MASK and shift right
// This gives us a 3 bit value in the form 0b<b><g><r>
uint32_t gpio = (gpio_get_all() & RGB_MASK) >> RGB_BASE_PIN;

Finally, we can pass this value into a switch statement and based on the value of the 3 color bits, we can print a different message:

switch(gpio) {
    case 0b110: // red
        printf("off\n");
        break;
    case 0b100: // yellow
        printf("optical\n");
        break;
    case 0b000: // white
        printf("aux\n");
        break;
    case 0b101: // green
        printf("line-in\n");
        break;
    case 0b011: // blue
        printf("bluetooth\n");
        break;
    case 0b111: // off
        printf("none\n");
        break;
    default:
        printf("unknown\n");
    }

Full code

#include <stdio.h>
#include "pico/stdlib.h"

#define RGB_BASE_PIN 17
const uint32_t RGB_MASK = 1 << RGB_BASE_PIN |        // Pin 17
                          1 << RGB_BASE_PIN + 1 |    // Pin 18
                          1 << RGB_BASE_PIN + 2;     // Pin 19

int main() {
    stdio_init_all();
    // Enable pins 17, 18 & 19 as input 
    gpio_init_mask(RGB_MASK);
    uint32_t gpio;
    while (true) {
        // Extract desired bits from GPIO with RGB_MASK and shift right
        // This gives us a 3 bit value in the form 0b<b><g><r>
        gpio = (gpio_get_all() & RGB_MASK) >> RGB_BASE_PIN;
        // Perform comparisons on the 3 bits to determine the state of the RGB LED
        switch(gpio) {
            case 0b110: // red
                printf("off\n");
                break;
            case 0b100: // yellow
                printf("optical\n");
                break;
            case 0b000: // white
                printf("aux\n");
                break;
            case 0b101: // green
                printf("line-in\n");
                break;
            case 0b011: // blue
                printf("bluetooth\n");
                break;
            case 0b111: // off
                printf("none\n");
                break;
            default:
                printf("unknown\n");
        }
        sleep_ms(500);
    }
    return 0;
}

Demo

This simulation demonstrates our ability to decode the color of an RGB LED. The switches on the breadboard can be toggled to ‘hardcode’ an RGB value which our program will then decode on a 500ms timer.

Mimicing an Infrared Remote

The infrared (IR) protocol used by the Snowdon and indeed in the majority of consumer products is called NEC. When you press a button on your remote, a single NEC message will be sent, carrying 32 bits (uint32_t) of information:

8 bit device address
8 bit device address (logical inverse)
8 bit command
8 bit command (logical inverse)

The full message looks like this:

And consists of the following:

9ms (562.5us x 16) leading LOW pulse
4.5ms (562.5us x 8) HIGH pulse
32 bits of information
562.5us trailing LOW pulse

Each bit in the message starts with a LOW pulse for 562.5us, followed by:

If the bit to be encoded is LOW, a HIGH pulse for 562.5us
If the bit to be encoded is HIGH, a HIGH pulse for 1.6ms (562.5us x 3)

It is worth noting there are a few nuances with the NEC protocol when transmitting normally via an LED:

When sent via an LED the message is inverted to what we see in the diagram

When sent via an LED the message is modulated with a 38khz carrier wave

We can safely ignore both of these facts because we will be circumventing the usual front door of an IR LED and directly connecting our Pico to the receiving IR line on the Snowdon mainboard.

Now that we understand a little about the NEC protocol, we can wire up the Pico to the Snowdon’s IR line

Wiring

The 220Ω resistor is required to give priority to the IR transceiver on the daughterboard. Otherwise legitimate IR codes sent via the remote control may get dropped

Code

To achieve the timing requirements of the protocol, we are going to be writing a Programmable IO (PIO) assembly program that will take a 32-bit unsigned integer (uint32_t) as input, translate it into a a NEC formatted message and broadcast it on GPIO 16.

PIO is a bit of a hard nut to crack so here are some suggested materials if its your first PIO rodeo:

Youtube - Raspberry Pi Pico’s PIO

Youtube - Raspberry Pi Pico and RP2040

PDF - Pico C SDK, Section 3

The first thing we are going to configure for our driver is side set. Side set allows us to drive up to 5 consecutive pins as a side effect of a PIO ASM instruction. For our purposes we are only interested in driving a single GPIO pin with our IR data, so we will declare this to the compiler with a label:

.side_set 1

Side setting steals bits from the delay function in PIO. Stealing 1 bit for side setting, as we are doing, reduces this maximum delay value from 31 ticks to 15 ticks

In our init function we also need to perform some setup to assosiate the variable pin (GPIO 16) with the side set function:

sm_config_set_sideset_pins(&c, pin);

We also need to perform some setup functions to enable our pin as output and give it an initial value:

pio_gpio_init(pio, pin);                                // Set pin function to GPIO
pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);  // Set the pin direction to output 
pio_sm_set_pins_with_mask(pio, sm, 1u << pin, 1);       // Set the initial value of the pin to 1 (HIGH)
gpio_pull_up(pin);                                      // Set the default value of the pin to 1 (HIGH)

Lastly, we need to configure the clock. Looking at the timing diagram, our first instinct may be to set the clock to ~560us. so that each PIO instruction takes ~560us to execute. However, as will become evident later on, we actually need the flexibility to perform 2 instructions per ~560us window. So that is what we will set the clock to:

// 2 ticks per 560us window 
float div = clock_get_hz(clk_sys) / (2 * (1 / 562.5e-6f));
sm_config_set_clkdiv(&c, div);

The body of the PIO program looks like this:

.wrap_target
    pull side 1
pulse_init:
    nop side 0 [15] 
    nop side 0 [15]         ; 9ms on 
    nop side 1 [15]         ; 4.5ms delay
next:
    out y 1 side 0          ; Read next bit from OSR into y, side set LOW for 1 tick (280us)
    jmp !y short side 0     ; If y == 0, goto short,  side set LOW for 1 tick (280us)
long:
    jmp bit_loop side 1 [4] ; Side set HIGH for 5 ticks (1400us)
short:
    nop side 1              ; Side set HIGH for 1 tick (280us)
bit_loop:
    jmp !osre next side 1   ; goto next if osr is not empty, side set HIGH for 1 tick (280us)
end_pulse:
    nop side 0 [1]          ; Side set LOW for 2 ticks (560us)
.wrap

Let’s disect this to understand how we are achieving NEC transmission.

pull side 1

The pull instruction will pull 32 bits into the program as input. This call will block until we give the program our uint32_t to encode. Additionally we:

Use side set to drive GPIO 16 HIGH, this will remain HIGH whilst the pull instruction is blocked

pulse_init:
    nop side 0 [15] 
    nop side 0 [15]         ; 9ms on 
    nop side 1 [15]         ; 4.5ms delay

After the user provides input, execution continues and we enter the pulse_init label, where we:

Execute the nop instruction which does nothing for a single tick.
Delay each nop for 15 ticks, such that each instruction takes 16 ticks total.
Use side set to drive GPIO 16 LOW for 32 ticks (9ms) and then HIGH for 16 ticks (4.5ms).

next:
    out y 1 side 0          ; Read next bit from OSR into y, side set LOW for 1 tick (280us)
    jmp !y short side 0     ; If y == 0, goto short,  side set LOW for 1 tick (280us)

We fall through to the next label, where we:

Pop one bit of our input into the y register.
Do a conditional jump, if the bit’s value is 0 we jump to the short label.
Side set LOW for both instructions, achieving our initial LOW pulse for the first bit.

long:
    jmp bit_loop side 1 [4] ; Side set HIGH for 5 ticks (1400us)

If we did not conditionally jump, then we fall through to the long label, where we:

Unconditionally jump to the bitloop label.
Side set HIGH with a 4 tick delay, totalling 5 ticks

short:
    nop side 1              ; Side set HIGH for 1 tick (280us)

Else, we conditionally jumped to the short label, where we:

Do nothing (nop). Due to the positioning of our labels we can simply fall through to the bit_loop label
Side set HIGH on GPIO 16 for a single tick

bit_loop:
    jmp !osre next side 1   ; goto next if osr is not empty, side set HIGH for 1 tick (280us)

Regardless of our branching path, we end up in the bit_loop label. Where we:

Conditionally jump back up to the next label as long as we still have input bits left to transcode
Side set HIGH on GPIO 16 for a single tick. This means we have driven the GPIO HIGH for 6 ticks if we got here via long, or 2 ticks via short!

We then start again from next until we have processed all 32 bits:

end_pulse:
    nop side 0 [1]          ; Side set LOW for 2 ticks (560us)

After all bits have been exhausted, we finally enter the end_pulse label, where we:

Do nothing for a single tick
Side set LOW on GPIO 16 for 2 ticks, achieving our trailing pulse
Wrap back around to the first pull instruction to wait for next input

Full code

; Implements an inverted NEC infrared protocol WITHOUT carrier signal
; For use in wired connection to IR line.  Each instruction is 280us
.program nec
.side_set 1
.wrap_target
    pull side 1
pulse_init:
    nop side 0 [15] 
    nop side 0 [15]         ; 9ms on 
    nop side 1 [15]         ; 4.5ms delay
next:
    out y 1 side 0          ; Read next bit from OSR into y, side set LOW for 1 tick (280us)
    jmp !y short side 0     ; If y == 0, goto short,  side set LOW for 1 tick (280us)
long:
    jmp bit_loop side 1 [4] ; Side set HIGH for 5 ticks (1400us)
short:
    nop side 1              ; Side set HIGH for 1 tick (280us)
bit_loop:
    jmp !osre next side 1   ; goto next if osr is not empty, side set HIGH for 1 tick (280us)
end_pulse:
    nop side 0 [1]          ; Side set LOW for 2 ticks (560us)
.wrap

% c-sdk {
#include "hardware/clocks.h"
static inline void nec_transmit_program_init(PIO pio, uint sm, uint offset, uint pin) {
    pio_sm_config c = nec_program_get_default_config(offset);
    sm_config_set_sideset_pins(&c, pin);

    pio_gpio_init(pio, pin);
    pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);
    pio_sm_set_pins_with_mask(pio, sm, 1u << pin, 1);
    gpio_pull_up(pin);
    
    sm_config_set_out_shift(&c, true, false, 32);
    
    // 2 ticks per 560us window 
    float div = clock_get_hz(clk_sys) / (2 * (1 / 562.5e-6f));
    sm_config_set_clkdiv(&c, div);

    // Init the pio state machine with PC at offset
    pio_sm_init(pio, sm, offset, &c);
    // Start sm
    pio_sm_set_enabled(pio, sm, true);
}
%}

Demo

This simulation demonstrates our driver’s ability to mimic an infrared remote. When the switch is toggled left, it will accept input directly from the IR remote via the IR receiver.

However, when the switch is toggled to the right, we see that our PIO program is sending a random remote code out on GPIO 16 every 500ms:

Code

... 
#define TX_PIN 16
...
uint32_t remote_codes[] = {
    0x5da2ff00,  //POWER                                                            
    0xdd22ff00,  //TEST                                                             
    0xfd02ff00,  //PLUS                                                             
    0x3dc2ff00,  //BACK                                                             
    0x1de2ff00,  //MENU
    0x6f90ff00,  //NEXT
    0x57a8ff00,  //PLAY
    0x1fe0ff00,  //PREV
    0x9768ff00,  //0
    0x6798ff00,  //MINUS
    0x4fb0ff00,  //C
    0x857aff00,  //3
    0xe718ff00,  //2
    0xcf30ff00,  //1
    0xef10ff00,  //4
    0xc738ff00,  //5
    0xa55aff00,  //6
    0xad52ff00,  //9
    0xb54aff00,  //8
    0xbd42ff00,  //7
};
...
while (true) {
    pio_sm_put_blocking(PIO_INSTANCE, tx_sm, 
                        remote_codes[rand() % ARRAY_SIZE(remote_codes)]);
...
    sleep_ms(500);
}

Building a dunderhead HTTP server from scratch

At the time that I started this project (September 2022) there were no examples online, that I could find, of a HTTP server that utilised the C SDK for the Pico W. I did however know from some prior adventures into ESP32, that you can remain very stupid as a microcontroller and still talk HTTP, so lets roll our own HTTP server!

The way I achieved this was by building on the tcp server example over on the official pico-examples github repository.

What even is HTTP anyway?

Hypertext Transfer Protocol (HTTP) at is core is just a TCP socket with fancy strings.
Theres a great crash course by @fasterthanlime over on his blog that I would recommend reading.

So how do we send fancy strings?

Let’s send a standard HTTP PUT request via the cli tool curl and see what it looks like, request:

curl -X PUT http://api.int/api/v1.0/pc\?code\=status

Response:

{"status": "on"}

Plucking the request out of wireshark, we can see that the actual TCP payload contains the following information:

PUT /api/v1.0/pc?code=status HTTP/1.1\r\n
Host: api.int\r\n
User-Agent: curl/7.68.0\r\n
Accept: */*\r\n
\r\n

Let’s disect this. The first line specifies a few things:

Parameter	Value	Description
Method	GET	The method of the call, common methods are GET, POST, PUT, HEAD
Target	/api/v1.0/pc?code=status	Specifies the sub-path target of the call, this allows routing in a HTTP server that hosts many different endpoints. key/value pairs can also be specified in this line
Version	HTTP/1.1	This is the HTTP version of the call, for our purposes it will always be HTTP/1.1

Each line end is denoted with a carriage return \r and line feed \n.
Each line after the first contains a header variable in the form of a key/value pair.
The final line only contains \r\n to denote the end of the data

The response data looks like this:

HTTP/1.1 200 OK\r\n
Content-Length: 17\r\n
Content-Type: application/json\r\n
Date: Wed, 30 Nov 2022 10:40:24 GMT\r\n
Server: waitress\r\n
\r\n
{"status": "on"}

It follows a very similar format, the first line again specifies a few things:

Parameter	Value	Description
Version	HTTP/1.1	This is the HTTP version of the call, for our purposes it will always be HTTP/1.1
Status Code	200	A numeric representation of the response status, must be a valid HTTP status code as documented here
Status Text	OK	A textual representation of the response status, must be paired up with the status code

Again each preceding line is a key/value header variable. However it is worth noting that the HTTP server chose to send a JSON response.

To pull this off, the response had to contain the header Content-Length, to inform the client of how much data it was going to send. After which it appends the JSON string after the final \r\n line of the HTTP body.

This concept of setting the Content-Length header applies to the client too if we wish to send JSON in our request.

This protocol is actually simple enough that we can pick apart a HTTP request and construct responses just by doing some simple string manipulation. We don’t even need to understand anything about HTTP or JSON to speak the lingo!

Code

The first (and hardest) thing we need to do in our little HTTP server is process HTTP request messages.

We can achieve this by breaking the string up into it’s individual tokens. We are going to use the string function strpbrk to achieve this.

The man page has this to say on the strpbrk function:

SYNOPSIS
       #include <string.h>

       char *strpbrk(const char *s, const char *accept);

DESCRIPTION
       The  strpbrk() function locates the first occurrence in the string s of
       any of the bytes in the string accept.

RETURN VALUE
       The strpbrk() function returns a pointer to the byte in s that  matches
       one of the bytes in accept, or NULL if no such byte is found.

So this function takes a string and a set of deliminators, and outputs a pointer to the first deliminator it encounteres in the string.

If we look again at the top line of the HTTP request, there are indeed a fixed set of single character deliminators that denote certain parts of the line:

PUT /api/v1.0/pc?code=status HTTP/1.1\r\n

So we can extract a given token by performing a set of steps.

Define our message in a string (char *) and create a pointer to the first character:

char http_message[] = {
    "PUT /api/v1.0/pc?code=status HTTP/1.1\r\n"
    "Host: api.int\r\n"
    "User-Agent: curl/7.68.0\r\n"
    "Accept: */*\r\n"
    "\r\n"
};
char *p1 = http_message;

Call the strpbrk function to obtain a pointer to the first instance of one of our deliminators:

char *p2 = strpbrk(p1, " ?=\r");

Now lets null terminate p2. By placing \0 at the position earmarked by p2, we transform the deliminator into the last character of the string:

*p2 = '\0';

If we now print p1, it will only print up to the first \0, essentially turning it into our first token:

printf("%s\n", p1);
> PUT

We can further extend this technique to iterate over each token in the first line of the HTTP request, and by keeping track of the deliminators we can tell exactly which token we just extracted.

Full code

#include <string.h>
#include <stdio.h>


int main() {
  char http_message[] = {
    "PUT /api/v1.0/pc?other=monkey&code=status HTTP/1.1\r\n"
    "Host: api.int\r\n"
    "User-Agent: curl/7.68.0\r\n"
    "Accept: */*\r\n"
    "\r\n"
  };

  // Process HTTP message body, example: "PUT /api/v1.0/pc?code=status HTTP/1.1"
  // char *message_body = http_message;
  char *message_body = http_message;
  char *delim = " ?=&\r";
  char next_delim;
  char current_delim = '\0';
  char *token;

  while(1) {
    if (*message_body == '\0') { break; }
    token = message_body;
    message_body = strpbrk(message_body, delim);
    if (message_body == NULL) { break; }
    next_delim = *message_body;
    *message_body = '\0';

    switch(current_delim) {
      case '\0':
        printf("Method\t\t%s\n", token);
        break;
      case ' ':
        if (next_delim != '\r') {
          printf("Target\t\t%s\n", token);
        } else {
          printf("Version\t\t%s\n", token);
        }
        break;
      case '?':
      case '&':
        printf("Key\t\t%s\n", token);
        break;
      case '=':
        printf("Value\t\t%s\n", token);
        break;
    }
    current_delim = next_delim;
    message_body++;
    // Carriage return indicates we have reached the end of the first line of message body
    if (current_delim == '\r') { break; }
  }

  return 0;
}

Within the final program we actually take this one step further and use the same technique to step through JSON as a flat file if it is provided as part of the HTTP request.

Demo

Optional: Recycling unused pins for SWD debugging

If we take a look at the mainboard again, we can see there is a 4 pin “USB” header exposed on the board with unused pins:

I tested both NONE pins on the oscilloscope and determined that there was no activity on either pin during normal operation. As it turns out the panel on the back actually has a cut out for the USB header, which is only covered by a thin layer of mylar tape that can be cut away:

Due to this I decided to wire up the SWD debugging pins from the Pico to the unused pins so that I could perform debugging without having to re-open the unit:

I would highly recommend NOT doing this, as I managed to fry the SWD pins on one of my debuggers using these pins and I am not 100% as to the reason

Tying it all together

Throughout this adventure we have developed some interesting capabilities on our Pico, we can now:

Get the current state of the Snowdon via the RGB LED
Send our own NEC encoded commands to the Snowdon
Decode arbitrary HTTP requests

To bring this all together we only really need a little bit of glue code to translate a HTTP request into a call to our PIO driver or LED decoder.

This is achieve in the program by extracting a value from one of the user provided parameters passed in the HTTP request (code) and passing this into a helper function. The function translates the user provided string into a 32 bit NEC code for our PIO driver, or a HTTP_CODE_LOOKUP_STATUS command for our LED decoder:

static uint32_t http_code_lookup(char *code) {
    if (!strcmp(code, "status"))        { return HTTP_CODE_LOOKUP_STATUS; }
    if (!strcmp(code, "power"))         {return 0x807F807F;}
    if (!strcmp(code, "input"))         {return 0x807F40BF;}
    if (!strcmp(code, "mute"))          { return 0x807FCC33; }
    if (!strcmp(code, "volume_up"))     { return 0x807FC03F; }
    if (!strcmp(code, "volume_down"))   { return 0x807F10EF; }
    if (!strcmp(code, "previous"))      { return 0x807FA05F; }
    if (!strcmp(code, "next"))          { return 0x807F609F; }
    if (!strcmp(code, "play_pause"))    { return 0x807FE01F; }
    if (!strcmp(code, "treble_up"))     { return 0x807FA45B; }
    if (!strcmp(code, "treble_down"))   { return 0x807FE41B; }
    if (!strcmp(code, "bass_up"))       { return 0x807F20DF; }
    if (!strcmp(code, "bass_down"))     { return 0x807F649B; }
    if (!strcmp(code, "pair"))          { return 0x807F906F; }
    if (!strcmp(code, "flat"))          { return 0x807F48B7; }
    if (!strcmp(code, "music"))         { return 0x807F946B; }
    if (!strcmp(code, "dialog"))        { return 0x807F54AB; }
    if (!strcmp(code, "movie"))         { return 0x807F14EB; }
    return HTTP_CODE_LOOKUP_UNKNOWN_VALUE;
}

We then just make the respective call in our program and return a nice hard coded JSON string in our HTTP response:

if (state->message_body->code == HTTP_CODE_LOOKUP_STATUS) {
    uint32_t gpio;
    do{
        gpio = (gpio_get_all() & RGB_MASK) >> RGB_BASE_PIN;
        switch(gpio) {
            case 0b110: // red
                http_generate_response(arg, "{\"onoff\": \"off\", \"input\": \"off\"}\n", "200 OK");
                break;
            case 0b100: // yellow
                http_generate_response(arg, "{\"onoff\": \"on\", \"input\": \"optical\"}\n", "200 OK");
                break;
            case 0b000: // white
                http_generate_response(arg, "{\"onoff\": \"on\", \"input\": \"aux\"}\n", "200 OK");
                break;
            case 0b101: // green
                http_generate_response(arg, "{\"onoff\": \"on\", \"input\": \"line-in\"}\n", "200 OK");
                break;
            case 0b011: // blue
                http_generate_response(arg, "{\"onoff\": \"on\", \"input\": \"bluetooth\"}\n", "200 OK");
                break;
            case 0b111: // off (likely in a transitioning state)
                busy_wait_ms(50);
                continue;
        }
    } while (gpio == 0b111);
    return;
}
if (state->message_body->code > HTTP_CODE_LOOKUP_NO_VALUE) {
    pio_sm_put_blocking(PIO_INSTANCE, 0, state->message_body->code);
    http_generate_response(arg, "{\"status\": \"ok\"}\n", "200 OK");
}

This is essentially all the building blocks required to roll our own RESTful API. With that out of the way, all that’s left to do now is wire it up and compile!

Wiring

SWDIO and SWCLK are not required for normal operations, they expose the SWD debug pins on the unused USB header for easy access

Compiling Guide

Please refer to the offical Getting Started guide for full details on getting a build environment setup

Due to the final software containing hardcoded WiFi credentials, it’s impossible to share a pre-built uf2. So we must install the Pico SDK and built it from scratch.

Install dependencies for SDK:

sudo apt update
sudo apt install git cmake gcc-arm-none-eabi libnewlib-arm-none-eabi build-essential

Clone SDK;

cd ~/
git clone https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk
git submodule update --init

Export PICO_SDK_PATH variable:

export PICO_SDK_PATH=$HOME/pico-sdk

Clone Snowdon-II-WiFi:

git clone https://github.com/kennedn/snowdon-ii-wifi.git

Create a build directory and configure cmake with WiFi credentials:

cd snowdon-ii-wifi
mkdir build
cd build
# Replace <SSID> and <PASSWORD> with own values
cmake -DPICO_BOARD=pico_w -DWIFI_SSID="<SSID>" -DWIFI_PASSWORD="<PASSWORD>" ..

Compile the program:

cd src
make

If all goes well, a file named snowdon.uf2 should now exist under ~/snowdon-ii-wifi/build/src/.

The Pico can now be plugged in via USB whilst holding down the BOOTSEL button, and the uf2 file dropped in the volume mount.

API

The RESTful API is exposed on port 8080:

http://<ip_address>:8080

The endpoint expects a single code parameter, which can be sent via either url encoding or in the JSON body of the request, e.g:

curl -X PUT http://192.168.1.238:8080?code=status
# or
curl -X PUT http://192.168.1.238:8080 -H 'Content-Type: application/json' -d '{"code": "power"}'

And this is the full list of available code values:

Value	Description	JSON response
power	Infrared Code	`{"status": "ok"}`
input	Infrared Code	`{"status": "ok"}`
mute	Infrared Code	`{"status": "ok"}`
volume_up	Infrared Code	`{"status": "ok"}`
volume_down	Infrared Code	`{"status": "ok"}`
previous	Infrared Code	`{"status": "ok"}`
next	Infrared Code	`{"status": "ok"}`
play_pause	Infrared Code	`{"status": "ok"}`
treble_up	Infrared Code	`{"status": "ok"}`
treble_down	Infrared Code	`{"status": "ok"}`
bass_up	Infrared Code	`{"status": "ok"}`
bass_down	Infrared Code	`{"status": "ok"}`
pair	Infrared Code	`{"status": "ok"}`
flat	Infrared Code	`{"status": "ok"}`
music	Infrared Code	`{"status": "ok"}`
dialog	Infrared Code	`{"status": "ok"}`
movie	Infrared Code	`{"status": "ok"}`
status	RGB LED Query	`{"onoff": power_state, "input": input_state}`

power_state has the following possible values:

Value
on
off

input_state has the following possible values:

Value
off
optical
aux
line-in
bluetooth

Finish

With that we can now send HTTP commands to our Pico:

And it’s a win win because my remote control can go on its adventures into the deep recesses of the couch and I can still turn on my soundbar:

Embedding a Pi Zero in a NES controller

Wed, 10 Aug 2022 10:19:40 +0100

I recently purchased a CRT TV in the hopes of reliving my childhood memories through some of the old games I used to play. This works great for devices that support composite video and I’ve gotten some fairly decent mileage out of the consoles I still own from that era.

But therein lies the problem. The TV is old enough to only support one external connection via a scart port on the back of the unit. It became clear rather quickly that this kind of connectivity is a big limiting factor when it comes to interfacing with any device made after 2010.

I had a few options that I explored before committing to this project but ran into brick walls with each one.

I have a soft-modded PlayStation 2 already wired into the TV, and the homebrew scene has produced a couple of SNES emulators for the console. Each however suffered very poor frame rates for Earthbound so this was a non-starter.

I then bought a cheap HDMI to composite adapter with the hopes of hooking something up with more oomph, maybe even a fully fledged computer. However despite advertising PAL support on the listing, the device only supported a subset of PAL formats and was incompatible with the CRT TV, displaying images in distorted black and white.

I finally decided I could make something better myself.

Table of Contents

Build Requirements

If I was going to build something I not only wanted it to work well, I wanted it to look cool too. I had a peek around thingiverse for some inspiration and stumbled upon a project that consisted of a custom base for an original NES controller that can house a Raspberry Pi Zero. Not only does it look cool but the NES buttons can actually be wired to the Pi, letting it double as a console and a controller!

So we are going to use this as a starting point but add some of our own build requirements:

The final 3d model we end up using for a base is available on thingiverse as a remix of the original.

Parts List

Part	Amount
Raspberry Pi Zero W	x1
Raspberry Pi (Any model)	x1
ATtiny45 Microcontroller	x1
NES-004 Controller	x1
MicroSD Card (8GB+)	x1
Strip Board	x3
4 Pole Jack to RCA Cable	x1
Micro USB cable	x1
M3 x 5mm mounting screws	x4
5mm Red LED	x1
TRRS Breakout Board	x1
270Ω Resistor	x3
150Ω Resistor	x2
22nF Capacitor	x2
10uF Capacitor	x2
3d Printer or Printing Service	x1
Wire (22AWG Single Core )	x1 roll
Soldering Iron	x1
Solder	x1 roll

Wiretapping the NES controller

We want to be able to use the controller functionally but also read a button combination from it to toggle the Raspberry Pi Zero’s power state.

To understand if this is even possible we first need to understand two things a little better:

Raspberry Pi Zero power options
NES Controller functionality

Raspberry Pi Zero Power Options

Raspberry Pi makes use of a feature called device tree overlays. Among other things it allows for kernel modules to be enabled / disabled at boot time. Raspberry Pi devices come by default with a plethora of built in dtoverlays that can be used to modify behaviour at boot.

The documentation for the overlays can be found on your Raspberry Pi device under /boot/overlay/README, or over on the Raspberry Pi firmware github page . One such overlay stands out as a very good candidate for achieving the power control we want:

README

Name:   gpio-shutdown
Info:   Initiates a shutdown when GPIO pin changes. The given GPIO pin
        is configured as an input key that generates KEY_POWER events.
...
        This overlay only handles shutdown. After shutdown, the system
        can be powered up again by driving GPIO3 low. The default
        configuration uses GPIO3 with a pullup, so if you connect a
        button between GPIO3 and GND (pin 5 and 6 on the 40-pin header),
        you get a shutdown and power-up button. Please note that
        Raspberry Pi 1 Model B rev 1 uses GPIO1 instead of GPIO3.
Load:   dtoverlay=gpio-shutdown,<param>=<val>
Params: gpio_pin                GPIO pin to trigger on (default 3)
                                For Raspberry Pi 1 Model B rev 1 set this
                                explicitly to value 1, e.g.:

                                    dtoverlay=gpio-shutdown,gpio_pin=1

        active_low              When this is 1 (active low), a falling
                                edge generates a key down event and a
                                rising edge generates a key up event.
                                When this is 0 (active high), this is
                                reversed. The default is 1 (active low).

        gpio_pull               Desired pull-up/down state (off, down, up)
                                Default is "up".

                                Note that the default pin (GPIO3) has an
                                external pullup. Same applies for GPIO1
                                on Raspberry Pi 1 Model B rev 1.

        debounce                Specify the debounce interval in milliseconds
                                (default 100)

The default configuration uses GPIO3 with a pullup, so if you connect a button between GPIO3 and GND, you get a shutdown and power-up button

This sounds like the exact behaviour we are looking for. Pull GPIO3 low and we get a power toggle pin.

We will enable this dtoverlay later on in the Software Setup section. Since we now know the Pi is willing to play ball lets take a deeper dive in to how the NES controller works.

How NES Controllers Work

NES Controller’s are surprisingly simple. They consist of a single 4021 8-bit shift register. This little IC reads 8 separate inputs and can output them serially over a single pin. You can see from this diagram that each parallel input pin (P1-8) is wired to a button on the controller:

The other pins of note here are CK P/S, DS and O8.

Name	Description
`CK`	Clock pin
`P/S`	Parallel or Serial select pin
`O8`	Serial Output
`DS`	Serial input, tied LOW

When the Console want’s to know which buttons are are being pressed, it will do the following:

Set P/S LOW, we are now in Parallel in, serial out mode. On each clock pulse, the 4021 will capture the state of the 8 connected buttons in parallel
Send 1 clock pulse on the CK pin.
Set P/S HIGH, we are now in serial in, parallel out mode. On each clock pulse, the 4021 will read a new value in from DS and shift all registers to the right
Loop 8 times:
- Read the value of O8
- Send 1 clock pulse on the CK pin. The next value becomes available on O8

By stepping through this process, the Console can extract each button’s state from the NES controller using only 3 wires.

RetroPie actually has a driver that does this for us, driver setup is covered in the Software Setup section. We can wire the NES controller directly on to our GPIO to make use of this driver, so lets do that.

NES-004 Circuit Diagram

Wire coloring can vary between controllers and I would highly recommend double checking wire / pin mappings with a multimeter.

4021 pin	Wire Color	Raspberry Pi
3v3	Green or White	3v3
O8	Yellow	GPIO 4
CK	Red	GPIO10
P/S	Orange	GPIO12
GND	Brown	GND

Using An ATtiny To Bridge The Gap

We need a man in the middle to be able to drive GPIO 3 LOW when certain buttons are pressed on the NES Controller. This is because the Pi cannot do the work for us when it is powered off. For this project I decided to use an AATiny45 microcontroller for the job since I had a few lying around.

One problem we need to address is that two devices cannot interface with the 8 bit shift register at the same time without interfering with each other, Both CK and P/S need a single controller to be deterministic. However, each of the 8 NES buttons has its own dedicated connection pin on P1-8. So all we need to do is decide on a combination now and ‘wiretap’ connections from those pins to our ATtiny as inputs.

We can prove this works by providing power to the 8-bit shift register and checking for a voltage shift on one of the 8 ‘Parallel In’ pins, lets use P8. P8’s voltage level shifts when we press the A button:

Pressing the A button pulls the voltage LOW, returning to HIGH when released

Looking good. I opted to use buttons start + select as my combination.

Let’s get a breadboard set up and start trying to implement this. My NES controller has a CD4021BC IC, below is the pinout for this IC and the ATtiny45:

Comparing the Parallel In pins with the nes004 diagram , we have enough information to wire this up now:


4021	Attiny45
P6 (select)	PB1
P5 (start)	PB2
3v3	3v3
GND	GND

Now that we have our hardware setup we need to start writing some software. All Raspberry Pi’s come with on-board SPI and we can leverage this to write directly to our ATTIny45 using AVRDude.

AVRDude Setup

To make this a little easier you can build up a very simple breadboard circuit for seating your ATtiny when you want to flash to it.

Resistors aren’t required if you are using the 3v3 pin to power the ATtiny

As seen in the picture, you can optionally connect `RST` (reset pin) to an additional GPIO on the Raspberry Pi, Pulling `RST` LOW puts the ATtiny into flash mode so realistically you can just tie this to `GND`, as shown in the circuit diagram.

Install dependencies:

sudo apt update && sudo apt upgrade -y
sudo apt install bison automake autoconf flex gcc-avr binutils-avr avr-libc -y

Clone a copy of AVRDude from github:

git clone https://github.com/kcuzner/avrdude

cd to the directory and compile AVRDude, go get a coffee because this step will take a while:

cd avrdude/avrdude
./bootstrap
./configure
sudo make install

Now lets test the connection, connect your ATtiny up to the SPI pins on your Raspberry Pi and run the following:

sudo avrdude -p t45 -c linuxspi -P /dev/spidev0.0 -b 10000

Output

pi@raspberrypi:~ $ sudo avrdude -p t45 -c linuxspi -P /dev/spidev0.0 -b 10000

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9206

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.
pi@raspberrypi:~ $

If you get a similar output then your Pi can now communicate with the ATtiny!

You can see the fuse settings listed in the output. The ATtiny45 usually comes with these values as defaults and looking specifically at the LOW fuse setting, 0x62 means Use the internal 8Mhz RC clock source and divide by 8.

So out of the box the ATtiny is only clocked at 1Mhz. We can change this to use the 16Mhz PLL clock by modifying the LOW fuse to a value of 0xF1. There is a great online calculator that is useful for understanding the fuses in more detail.

Please note that modifying fuse values is a potentially dangerous activity, please make sure you understand the fuse values you are modifying before running the command

Let’s change the LOW fuse to use a 16MHz clock, our code will be designed with the 16Mhz clock speed in mind:

sudo avrdude -p t45 -c linuxspi -P /dev/spidev0.0 -b 10000 -U lfuse:w:0xf1:m

Output

pi@raspberrypi:~ $ sudo avrdude -p t45 -c linuxspi -P /dev/spidev0.0 -b 10000 -U lfuse:w:0xf1:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9206
avrdude: reading input file "0xf1"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xf1:
avrdude: load data lfuse data from input file 0xf1:
avrdude: input file 0xf1 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:F1)

avrdude done.  Thank you.

pi@raspberrypi:~ $

Great, you can see the fuse value has now changed. We should be running at 16Mhz now when it comes to runtime.

The code that I eventually used in this project is available here .

It uses the Interrupt and Timer features of the ATtiny45 to essentially say:

while True:
    if IN_PIN_1 == 0 and IN_PIN_2 == 0:
        sleep(1.2)
        if IN_PIN_1 == 0 and IN_PIN_2 == 0:
            OUT_PIN = 0
        else:
            OUT_PIN = 1
    else: 
        OUT_PIN = 1

ATtiny Circuit Diagram

Hack The Jack Back

Most full sized Raspberry Pi models have an on-board 4 pole TRRS phono jack that consists of 2 audio channels and a composite video channel. However to conserve space on the Zero, most I/O ports have either been minimized or removed completely:

Not all hope is lost however. The composite pin is still exposed as the TV header on the board:

And as it turns out we can actually just re-purpose two PWM pins from the main 40 pin GPIO block. As of Raspbian Buster (10), the standard way of doing this is by using a dtoverlay called audremap. This overlay allows you to choose a pin set to remap and will make an audio device available at runtime using these pins.

README

Name:   audremap
Info:   Switches PWM sound output to GPIOs on the 40-pin header
Load:   dtoverlay=audremap,<param>=<val>
Params: swap_lr                 Reverse the channel allocation, which will also
                                swap the audio jack outputs (default off)
        enable_jack             Don't switch off the audio jack output
                                (default off)
        pins_12_13              Select GPIOs 12 & 13 (default)
        pins_18_19              Select GPIOs 18 & 19

There is a catch however. The TRRS jack of a fully fledged Raspberry Pi has a low pass filter circuit that reduces noise on each audio channel. This is something that is missing on the raw PWM pins and we are going to have to add it back to get the crisp audio we are seeking.

What is a low pass filter?

A low pass filter is a circuit that essentially places an upper bound on the output frequency of a signal. In respect to our audio channels, this means we can eliminate high frequency noise that might interfere with our signal. We know that the ‘good’ part of the signal is going to be within the human hearing range (20hz - 20,000hz), so we can design a circuit with a cut off frequency close to 20,000hz.

To understand how this kind of circuit works it can be useful to see it in action. Let’s look at a simple low-pass filter circuit with a 270Ω resistor and a 22uF capacitor and see what happens to the output signal (green) when we increase the frequency of the input signal (red).

The cut-off frequency for this circuit is 26.79Hz. This can be calculated with the following formula:
$$f = {1 / 2\Pi rc}$$

Substituting our values:
$${ r} = 270Ω$$
$${ c} = 22\mathrm{e}{-6}F$$

$$f = {1 / 2 * \Pi * 270 * 22\mathrm{e}{-6}}$$
$$f = 26.793761463282046$$

You can see in the above GIF that there is a phase shift occurring between the output and the input. The output voltage takes some time before it reflects the input voltage. This is caused by the capacitor charging and discharging at a specific rate. At 10Hz we are below the cut-off frequency and the output is able to reflect the input voltage in time before the next signal edge. However what happens when we approach the cut-off frequency (26Hz) and then move beyond to 100Hz?

The signal starts to attenuate (weaken) as we move beyond the cut-off frequency and that is the trick to the low-pass filter. If the frequency of the input signal at a given point in time is too fast for the capacitor to keep up, that part of the signal is essentially eliminated. If we take this demo circuit and now change the value of the 22uF capacitor to 22nF we get a cut-off frequency of 26,793.76Hz which is close enough to the upper human hearing range for our purposes:

$$f = {1 / 2 * \Pi * 270 * 22\mathrm{e}{-9}}$$
$$f = 26,793.761463282048$$

You can also use a 10nf or 33nf capacitor instead of the 22nf

There are a few additional complications that we must solve for in our circuit. The output voltage of our PWM pins is 3.3v. The standard audio line-level in consumer products has a peak voltage of around 1.5v so we need to reduce our PWM signal down to this level to be within spec. We can create a voltage divider to achieve this and it only requires one additional resistor.

We should also place a DC filter capacitor just before our output, this only permits AC and stops DC voltage from making its way to our speakers.

This is our final circuit:

The 270Ω resistor is ’re-used’ in our circuit as one half of the voltage divider. The 150Ω resistor makes up the second part and together they reduce the voltage to approx 1.18v at the point that they meet. This can be calculated using the voltage divider formula:

$$V_{out} = \frac{R_b}{R_a+R_b} \times V_{in}$$

Substituting our values:
$${R_a} = 270Ω$$
$${R_b} = 150Ω$$
$$V_{in} = 3.3V$$

$$V_{out} = \frac{150}{270+150} \times 3.3$$
$$V_{out} = 1.1785714285714286V$$

We need two copies of this circuit in our final board design, one for each audio channel. The resultant stripboard is placed to the left of the Pi in the case and looks like this:

My stripboard piece ended up being 11 x 12 holes across. As with our previous circuit, you can sand down the edges to fine tune the size so it fits in the cavity.

Phono Jack Circuit Diagram

Indicator LED

The indicator LED is simply an LED with a 270Ω resistor soldered onto one leg:

We want to be able to indicate the power state shortly after powering on the device. Luckily for us the serial communication pins are configured as outputs very early on in the boot process. So by enabling serial communication (see Software Setup ) we can get a quick and dirty power indication pin on GPIO14 (UART TX).

LED Circuit Diagram

Software Setup

Grab a copy of RetroPie:

wget -O - https://github.com/RetroPie/RetroPie-Setup/releases/download/4.8/retropie-buster-4.8-rpi1_zero.img.gz | gzip -d > retropie.img

Insert your SD Card into the computer and locate its device name:

sudo fdisk -l

Output

❯ sudo fdisk -l
...
Disk /dev/sdi: 29.74 GiB, 31914983424 bytes, 62333952 sectors
Disk model: USB3.0 CRW   -SD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdi1        8192 62333951 62325760 29.7G  c W95 FAT32 (LBA)

Write retropie.img to disk, replacing sdx with your disk name:

sudo dd if=retropie.img of=/dev/sdx bs=4M conv=fsync status=progress

There should be two new mount points available after this command completes:

df -h /dev/sdx*

Output

❯ df -h /dev/sdi*
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
/dev/sdi1       256M   49M  207M  20% /media/kennedn/boot
/dev/sdi2       2.5G  2.5G     0 100% /media/kennedn/retropie

cd to your boot partition to continue with setup:

cd /media/kennedn/boot

config.txt

Uncomment sdtv_mode in config.txt to enable composite video:

# uncomment for composite PAL
sdtv_mode=2

Add a dtoverlay line to config.txt to configure gpio-shutdown, this will enable GPIO3 as a power toggle pin:

dtoverlay=gpio-shutdown

Add a dtoverlay line to config.txt to configure audremap, this will re-route audio to PWM pins 12 and 13. In my config I swap the left and right channels with swap_lr to compensate for how I have wired the TRRS module to the board:

dtoverlay=audremap,pins_12_13,swap_lr

Add an enable_uart line to config.txt to enable the tx and rx GPIO pins for our indicator LED:

enable_uart=1

Full config.txt

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
dtoverlay=gpio-shutdown
dtoverlay=audremap,pins_12_13,swap_lr

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

enable_uart=1

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=256
overscan_scale=1

Network setup

Enable ssh by creating a blank file called ssh:

touch ssh

Create and fill out a file called wpa_supplicant.conf, replacing NETWORK-NAME and NETWORK-PASSWORD with your own values:

country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="NETWORK-NAME"
    psk="NETWORK-PASSWORD"
}

Controller setup

We need to boot into RetroPie for the remaining steps. We can ssh directly on to the device headlessly if the IP address is known, otherwise you may need to plug in a monitor and keyboard, you can press F4 when using a physical keyboard to drop into a tty shell.

SSH onto the NESZero:

ssh pi@192.168.1.112

Run the RetroPie-Setup script as root:

sudo RetroPie-Setup/retropie_setup.sh

You will be presented with a menu system, Select Manage packages:

On the next menu select driver:

On the next menu select gamecondriver:

On the next menu select Install from pre-compiled binary:

Once completed, you can hit back a few times and then exit. We can then re-start emulationstation and map our buttons for the nes controller:

emulationstation

Over in emulation station, you will need to plug in another controller or a keyboard to the usb slot.

Press backspace to bring up the main menu, move down to CONFIGURE INPUT with the arrow keys:

and hit z twice to enter the Configure Input Menu:

You can then move through the prompts to configure the NES Controller as an input device.

Finish

If you made it all the way through then congratulations! You can finally kick back, relax and play some Earthbound on your CRT TV: