Hey, so it's apparently this day; I figured I should do my part, and also give interested folx a chance to learn a bit more about me.

I do indeed identify as a Transgender individual for several reasons, which may be surprising to some who know me. I'd like to go into a bit of depth over what that means for me, but also for the wider community. So here are a bunch of meaningful words!

If you already know a decent amount about LGBT+ language, feel free to skip straight to About Me .

Language

As we continue to nudge society toward a fairer, more inclusive and less awful place, we develop the need for new language. Getting to grips with LGBT+ realities is no exception, and we need language sufficiently powerful to articulate what is going on. Here are some definitions that are particularly important to the LGBT+ and Transgender experience:

• AMAB - Assigned Male At Birth: This one is quite self explanatory.
  Most people called 'Boys' or 'Men' in my English-speaking culture, are AMAB individuals. This assignment is typically based on the presence of external genitalia.
• AFAB - Assigned Female At Birth: Same as above, but the assignment is typically based on the absence of external genitalia.
• Man/Male - An individual who identifies as such.
  Traditionally associated with certain behaviors, societal roles, clothing, colors and more. All, some or none of these things may apply to any particular man. For our purposes, mutually exclusive with 'Woman'.
• Woman/Female - An individual who identifies as such.
  Traditionally associated with certain behaviors, societal roles, clothing, colors and more. All, some or none of these things may apply to any particular woman. For our purposes, mutually exclusive with 'Man'.
• Non-binary - Typically someone who identifies as neither strictly a 'Man' nor 'Woman'.
• Cisgender - From Latin 'cis-', meaning 'on this side of'.
  Someone whose Assigned Gender at Birth, 'matches' their gender identity.
  Eg: An AMAB individual who identifies as a 'man' can typically be referred to as a 'Cisgender man', or commonly 'Cis man'.
  Cisgender individuals make up the majority of the population, and as a group are well represented in various contexts.
• Transgender - From Latin 'trans-', meaning 'across, beyond'.
  Someone whose Assigned Gender at Birth does not 'match' their gender identity.
  Some individuals here may feel most comfortable and authentic presenting differently to ways that 'match' their Assigned Gender at Birth.
  Some may identify with some specific gender, while others do not.
  Some may benefit from any of a wide variety of medical procedures to better align their body with what makes sense for them, while others do not.
  Some may feel that they were "born in the wrong body", while others do not consider this to be true.
  Eg: An AMAB individual who identifies as a 'woman' can typically be referred to as a 'Transgender woman', or commonly 'Trans woman'.
• Hormone Replacement Therapy (HRT) - Also known as 'Gender Affirming Hormone Therapy', represents a family of medical treatments intended to modify the levels of an individual's sex hormones (primarily testosterone and estrogen, but also others). This can have a broad range of desirable physical and psychological effects, and there are a multiple possible goals for such an endeavour. It is highly individualized, and usually involves experiencing a 'second puberty'.
• Transsexual - Arcane term for what we now typically refer to as a Transgender individual. Best for most people to avoid using this to refer to human beings, though within the LGBT+ community there is some nuance here.

This is the language I use - none of this is 'final'; words are ultimately 'made up' noises and squiggles for referring to things, tangible and otherwise, that we need to communicate about. Definitions may differ between points of view, and do just change over time.

About Me

After all that, it should make sense that some labels I use for myself are AMAB, Transgender, Non-binary and Gender-fluid. Breaking it down:

• I was assigned 'male' at birth (thanks to my external genitalia), but I do not identify as male.
• 'Woman' is also inaccurate, making me 'non-binary'.
• Gender-fluid describes how some of my behaviors, presentation and internal workings, when viewed through a gendered lens, tend to shift around from day to day.

Something I haven't spoken to many people about previously is that I do indeed employ feminizing HRT - moving my body from the testosterone-dominant regime I have had for most of my life, to an estrogen-dominant one. This has brought a slew of benefits which are, at this time, still difficult to convert into language - you're just going to have to trust me on this ;) .
It has been challenging to talk about for a number of reasons, including:

• By sharing such a fact, people may think I am looking for their approval, which is a burdensome misunderstanding for all involved. At this point however, things have been going on for long enough that it should be clear I'm not asking for permission.
• Many people are simply weirded out by this stuff. It's unusual and makes people uncomfortable to think about. I don't like making people uncomfortable and speaking frankly, I expect this will lose me the support of some friends who find it hard to tolerate.
• I don't want this to change how people treat me; alas, things are becoming more difficult to...conceal - I might as well take the opportunity and do my part to help normalize all this.
• I don't want to be labelled a 'woman'. For many people, this kind of disclosure will put me into the 'woman' box, or indeed the less-nice 'trying to be a woman' box. Neither of these are good for me. What I am going through can reasonably be called 'feminization', but 'transition' is misleading. Something that becomes painfully, wonderfully obvious, is that everyone seems to be doing this stuff for different and personalized reasons. The transgender community isn't one big monolith - it's a diverse bunch of people with some stuff in common. Kinda. Since getting acquainted with this reality, I actually feel less connected to a solid community, but I feel much more connected to myself; perhaps that makes sense to someone!

How can you support me?

• Basically don't do anything different.
• Don't make disrespectful/invasive questions/comments about my body. I do enjoy talking about myself in general, but there is also a big issue with folks feeling entitled to inspect/judge transgender bodies - perhaps asking quite clinical/medicalized questions which would normally demand a good deal of familiarity, or at least a little "asking to ask". It's annoying and weird, and particularly if it's 'out of concern', please just don't.
• Continue to address me as the non-binary individual I am. Avoid gendered language. Use they/them pronouns (I definitely don't want to hear nonsense about singular they/them being grammatically illegitimate - it's not; get over it).

Diversity within the community

As i've labored previously in this post, there is a great deal of diversity within the group of people called 'Transgender'. To not appreciate this will undoubtedly lead to confusion, so here are some dimensions which can vary between Transgender individuals:

• Identity - eg: Man, Woman, Non-binary, Genderfluid, etc... (many of these)
• Presentation - eg: clothing, behavior, third-person pronouns.
• Presence/degree of Gender Dysphoria - this is a medical diagnosis centered around discomfort with one's body, along gendered lines; a Transgender individual may or may not experience it.
• Self concept - eg: "Born in the wrong body" vs personal evolution, vs something else?
• Medical procedures undertaken - eg: none, hair removal, facial surgery, breast augmentation/reduction, genital surgeries, many more.
• Presence/degree of HRT undertaken - eg: none, microdosing, feminizing, masculinizing, transitional.
• History - eg: Some single moment they "found out they were transgender" vs some incremental change, vs something else? Presence of Childhood 'signs' vs not?
• Desire to 'pass' - particularly for Trans men and Trans women, it may or may not be desirable to appear visibly transgender.

This is not exhaustive or even extensive; hopefully it illustrates some of the great diversity within this group.

Challenges

Some social challenges particularly related to the Transgender population include:

• Underrepresentation and lack of visibility in media, workplace and other contexts.
• Social/moral taboo - Many individuals simply take moral issue with some or all aspects of Transgender individuals; this may be for religious reasons, and/or cultural beliefs around narrow, very specific definitions of man/woman-hood.
• Trivialization - Often a massively oversimplified view of this group is the only one considered. Eg: a popular trope is the AMAB individual who spends their childhood secretly dressing in female clothes, eventually 'fully transitioning' to become a Transgender woman, taking full advantage of all medical procedures available to present as closely to an idealized Cisgender woman as possible, with a goal of becoming indistinguishable from one. Though completely valid, it should be clear that this is very far from a universal story.
• Fetishization - Sigh
• Misinformation and even organized hate - Unfortunately, there exist influential and well-resourced groups of individuals, many of whom are so-called Trans Exclusionary Radical Feminists (TERFs), casting Transgender individuals as some combination of mentally disturbed, untrustworthy, hostile to feminism, hostile to womens' rights, or even predatory. This is a large problem in the UK for example, where such views could be called practically mainstream. It represents a sizeable risk to Transgender equality/safety.

Closing note

There is so, so much more to say on all of this, and I have not tried to cover everything. This is a snapshot into my world, and here I try to show how I place myself within it.

So here's what is likely the final installment in my COVID test explorations. I've learned a bunch and got some seemingly useful practical experience.

Broadly, I knew where I wanted to go with this - I wanted to be able to use the Arduino IDE to reprogram the device, and I wanted to be able to make use of the BLE radio to do something interesting. In my last post, I talked about getting the Jeff Probe working with the nRF52810 chip, well enough that I could erase/program it.

I've not done much with the Arduino platform, so I knew I had to learn a bunch of little pieces on the way. The first thing I needed was an Arduino 'core' for this chip. This is Arduino parlance for a board support package, which implements what you might call the Arduino basics - initialization, serial ports, GPIO, ADC and the like. Some googling around led me pretty quickly to an nRF5x core:

GitHub - sandeepmistry/arduino-nRF5: Arduino Core for Nordic Semiconductor nRF5 based boards

Arduino Core for Nordic Semiconductor nRF5 based boards - GitHub - sandeepmistry/arduino-nRF5: Arduino Core for Nordic Semiconductor nRF5 based boards

GitHubsandeepmistry

While it has no specific support for the nRF52810 chip, it has support for others which vary in relatively minor ways such as memory size, pinout and how many of whatever peripheral type there are. This also has Blackmagicprobe support which ended up working out-of-the-box with the Jeff Probe. So I set about creating a new board in boards.txt for the Ellume COVID test, along with an appropriately configured variant placed in the variants directory. A smattering of other little changes here and there were needed to get things going, including adding linker scripts and #ifdef directives. Without too much difficulty, I was able to write a program, compile it and download it onto the chip. I could even use gdb to verify that it was running!

Something I needed to do at this point was figure out what GPIOs are hooked to what things on the board. From poking around with a multimeter and experimenting with some basic code, I gleaned the following:

• P0.18 - Green LED
• P0.15 - Red test strip-reading LEDs
• P0.12 - ??? - Driving it low while P0.15 is high makes one of the red LEDs turn off
• P0.25 - Something button-related

On P0.25/Button, I spent a lot of time poking around trying to figure out how exactly it worked. It wasn't trivial, and I was prodding it with an oscilloscope probe for quite a long time indeed, as it jumped around on pushing the button - a capacitor seemed to be involved. I prodded a little too hard however, so much so that I actually deformed the solder and shorted out that pin of the MCU 😱.

The bridge between those two bits of solder on the bottom-left of the chip is reasonably visible in the first pic. The second pic shows me trying to separate them indirectly, via a rigid pin - you can see the pesky capacitor preventing direct access with the soldering iron. The third picture shows what appears to be the once-again separated conductors.

Unfortunately after all of this poking and prodding, it still didn't work! Perhaps I left a dry joint under the QFN; more likely I feel is that my shorting out with VDD, combined with driving the pin low from software while I was experimenting, lead to that GPIO driver being permanently destroyed. Or maybe something else was wrong - who knows? In any case, I gave up on using the switch for anything and just moved on.

I also ended up figuring out those two unknown pads on the programming header!

• P0.16 - Pad 3 on the programming header
• P0.20 - Pad 2 on the programming header, and also a red LED

I decided these should be a UART, and pretty arbitrarily declared Pad 3 to be TX and Pad 2 to be RX; this has the nice benefit of making the red LED blink while data is being received.

I wired these up to the TDI and TDO pins of the Jeff Probe; these aren't used when speaking SW-DP protocol, but the Blackmagic probe has a handy feature where you can set the lines to be logically attached to the second tty device presented by the probe, giving you a serial console. This behavior can be switched on in GDB via the command: monitor convert_tdio enable .

This was all working pretty well thus far, but of course still no BLE. I had a feeling this would be tough to get working and I was right, but not for any reason that I predicted.

BluefruitLib

To make things easier for myself I tried to find some Arduino-friendly way to do this. I figured I already have a working Arduino core, so this should just drop right in, right? Well kinda, but also no. Adafruit has a BluefruitLib library that seems to be super easy to use and even had some examples:

Adafruit_nRF52_Arduino/libraries/Bluefruit52Lib at master · adafruit/Adafruit_nRF52_Arduino

Adafruit code for the Nordic nRF52 BLE SoC on Arduino - Adafruit_nRF52_Arduino/libraries/Bluefruit52Lib at master · adafruit/Adafruit_nRF52_Arduino

GitHubadafruit

But some digging around revealed that I couldn't just copy/paste that library into the Arduino core I was working with. This is because the library depends on the Adafruit core specifically, which is quite different from the one I have been working with and ported to the nRF52810. While being Arduinoish, it's actually based on FreeRTOS; BluefruitLib and its dependencies depend on the specifics of this core, and some FreeRTOS parts, in order to work.

Take 1

So I investigated trying to pull BluefruitLib and its dependencies out one-by-one, along with FreeRTOS. This was not as painful as one might fear, but it was quite painful. One problem was that this port of FreeRTOS seems to require hard floating point support - something the nRF52810 doesn't have. So I tried to mess with the context switching function, to avoid switching out FP registers, and hopefully make it compatible. In the end there was just a bunch of this kind of nonsense to get something basic building, and the result didn't even work! 😢 🗑️

Take 2

I mostly threw that monstrosity away and tried a different monstrosity approach, this time starting with the new Adafruit core for which BluefruitLib and its dependencies was designed. I had a pretty good understanding of how an Arduino core hung together at this point, and figured it wouldn't be terribly hard to port the Adafruit core (for the most part) to the nRF52810, remove the bits of FreeRTOS that didn't work for me and just try to kludge it into working in some minimal way. I did this work and actually got something building, downloaded and running! The UART was funky, but I figured I could sort that out. The biggest problem was when I tried to do anything with Bluetooth, BluefruitLib and all its friends would get pulled in as dependencies. The poor nRF52810 has a lot less memory than what these components are normally running on, so it didn't fit! 😭
I tried hacking bits off, to no avail. And yeah, the UART didn't work. 🗑️

Take 3

So my next attempt and the one that ultimately worked, was to go back to my original core, dispensing with BluefruitLib, FreeRTOS et al, and basically do the bluetooth interaction from scratch, ripping the necessary parts out of BluefruitLib. I only wanted a BLE beacon; I didn't even want connections/pairing, so that's a pretty small amount of functionality, I thought.

WTF is a Softdevice?

Thus far, I had been mainly running only the code in the Arduino core. I've not been using any bootloader etc; just writing my program directly into the MCU's flash at an appropriate address, so it's the first thing to run at powerup. This is fine and reasonable until you want to use BLE. It seems to be a universal constant that the presence of wireless hardware necessitates a binary blob. For Nordic's nRF52 devices, this blob is called a "Softdevice".

You use it by writing it into the flash where you would normally write your application, so it has control of the MCU on power up. It then acts a bit like a hypervisor - after doing some initialization itself, it jumps to the code located immediately after itself in flash (your application goes here) in exactly the way the CPU would do at power up; specifically, it expects to find an ARM interrupt vector table at that location, and jumps to the reset vector therein.

So you have this softdevice written into the lower chunk of flash, and your application, with its vector table, needs to be loaded immediately above it. This APP_CODE_BASE address is always immediately after the end of the softdevice blob (modulo some alignment), so the version of softdevice blob installed actually needs to match the sizes/offsets in the application's linker script; such a linker script will contain a memory layout like this:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x30000 - 0x26000
  RAM (rwx)  : ORIGIN = 0x20003600, LENGTH = 0x20006000 - 0x20003600
}

A corollary of this setup is that the softdevice gets first dibs on any interrupts; it can handle an interrupt itself or (normally) it can forward it to the application's vector table. Your application can access the hardware directly as usual, but it needs to ask the softdevice blob to do BLE work. Your application also needs to avoid touching RTC0, which the softdevice expects to have exclusive access to. There is an API to call various functions of the softdevice, which seems to be implemented using software interrupts.

SO! As part of my "Take 3" I also needed to upgrade the softdevice version (and API headers) to match the version (v6.1.1) used in the Adafruit code I was callously ripping out of BluefruitLib, to ensure it would work properly with minimal adjustment.

Success!

After a whole lot of mashing sourcecode around into the right shape, I got everything into a function that's needed to initialize a beacon that broadcasts for 3 seconds.

arduino-nRF5/nrf_ble_utils.cpp at 6058680eed78d70bd81cc442ad234bbf1a7dc8b5 · routevegetable/arduino-nRF5

Arduino core + example for turning an Ellume Covid test into a BLE beacon - arduino-nRF5/nrf_ble_utils.cpp at 6058680eed78d70bd81cc442ad234bbf1a7dc8b5 · routevegetable/arduino-nRF5

GitHubroutevegetable

Moreover, what I ended up doing for this project was read the internal temperature sensor of the MCU and include that reading in the minor number of the beacon. Not particularly big or clever, but undeniably satisfying and it actually seems pretty accurate as far as I can tell.

IRQs/SoftDevice Events

The softdevice pretty much completely handles the transmission, signalling the user application that it has run for the desired time, via an "SD Event":

SD Events are delivered to the application via a interrupt; or rather, your application receives an interrupt when there are events to read from the softdevice. Such a handler in your application might look like this:

extern "C" void SD_EVT_IRQHandler(void)
{
  got_sd_events = true;
}

The application's main loop can then periodically check this flag and, if it is set, retrieve any pending events via a softdevice call. The code could look like this:

if(got_sd_events)
{
    got_sd_events = false;

    // For each pending event:
    bool done = false;
    while(!done)
    {
        // Get BLE event from softdevice
        uint32_t err = sd_ble_evt_get(ev_buf, &ev_len);

        switch (err) {
        case NRF_SUCCESS:
            /* ... Handle event ... */
            break;
        case NRF_ERROR_NOT_FOUND:
            /* ... Done processing all events */
            done = true;
            break;
        default:
            /* Some kind of error! */
            done = true;
            break;
        }
    }
}

Sleeping

This is an area where my inexperience with the nRF52 shows. I was expecting to find something akin to the ESP32's model of deep sleep, light sleep, etc... I found this isn't exactly the case - the nRF52 is just a way less power-hungry chip. To get decent power usage, you can just...stop doing things. Sitting in a loop or on a wfi instruction, with the automatic low power mode enabled (simply NRF_POWER->LOWPWR = 1;) gets the chip down into the range of 10s of microamps. The datasheet suggests much more power saving is possible, down to sub-microamp amounts by disabling peripherals, clocks and RAM retention, but my lack of patience got the better of me and I just wanted to see it do some stuff. So I made a very much belt-and-braces implementation  of 'do a thing, sleep for 30 seconds, do it again, and so on...'. From power-on, I do 3 seconds of beacon-transmitting, then I embark upon the following litany of crazed off-switch-throwing:

Serial.end();
// Disable softdevice
sd_softdevice_disable();

// Kill RTC interrupt for better quality sleep
NVIC_DisableIRQ(RTC1_IRQn);

// Kill timers?
NRF_TIMER0->TASKS_STOP = 1;
NRF_TIMER1->TASKS_STOP = 1;
NRF_TIMER2->TASKS_STOP = 1;

// Kill RTCs?
NRF_RTC0->TASKS_STOP = 1;
NRF_RTC1->TASKS_STOP = 1;

// Wake after some time
#define WAKE_SECS 30
NRF_RTC0->PRESCALER = 4095; // 8Hz
NRF_RTC0->CC[0] = WAKE_SECS * 8;

NRF_RTC0->INTENSET = RTC_INTENSET_COMPARE0_Msk;
NRF_RTC0->EVTENSET = 0;

NVIC_EnableIRQ(RTC0_IRQn);
NRF_RTC0->TASKS_START = 1;

__WFI();
NVIC_SystemReset();

extern "C" void RTC0_IRQHandler(void) {
      NVIC_SystemReset();
}

I'm quite sleep deprived at this point, but after a solid 4 days of frustration and learning, it all seems to work. A day or so later, it's still reporting in. Given the high frequency of broadcasting and lack of attention to detail around power consumption, I doubt this will last a week on the coin cell the device came installed with, but it'll be interesting to see!

Conclusion & Future things

The Arduino core I am using, with parts added on to do BLE beacon business with an Ellume COVID test, can be found here:

GitHub - routevegetable/arduino-nRF5: Arduino core + example for turning an Ellume Covid test into a BLE beacon

Arduino core + example for turning an Ellume Covid test into a BLE beacon - GitHub - routevegetable/arduino-nRF5: Arduino core + example for turning an Ellume Covid test into a BLE beacon

GitHubroutevegetable

I want to get a better handle on the way sleep works on these devices - there's clearly a lot more I could be doing to save power, and a lot of potential for the kinds of low-powered applications that interest me.

It would be good to be able to do OTA firmware updates without physically plugging in a SW-DP probe. I suspect there's a good amount of memory left, which could be used to hold a replacement image, and the softdevice seems to have software update-relevant parts to do these kinds of things robustly.

Even if I don't bother figuring out how to do OTA, it'd be nice to be able to program this thing without soldering 3 wires to it every time, so I'll have a think about how to more neatly do that.

Finally, that damn button I broke is really bugging me. For a beacon which just periodically broadcasts autonomously it's not really relevant, but i'm sure there are useful things I could come up with if I could figure out the button.

Next in my list of things to do with this COVID test is figure out how to program it/erase it using the programming port I mentioned previously. I acquired a Jeff Probe - a Blackmagic-based/compatible multipurpose JTAG device, which I was going to try to use for this.

Things didn't just work out of the box; of course they didn't!

First off, I didn't realize the IDC connector on the Jeff Probe was 1mm pitch, rather than the 2.54mm I had in my brain. So much for my plan for soldering some wires onto the board and simply jamming them into the IDC cable holes - they're too small. I tried using some very thin wire...

But even after I mostly stopped the wires popping out of the IDC connector, things weren't happening - the probe wasn't finding the MCU:

(gdb) target extended-remote /dev/ttyACM1
Remote debugging using /dev/ttyACM1
(gdb) monitor swdp_scan
Target voltage: 3.3V
SW-DP scan failed!

I figured I needed pullups on the clock and data lines and/or a better connection, so I slowed down, put things on a breadboard with some Dupont wires, and legitimately tried make an okay job of it. It felt slow and tedious, but worth it - I didn't have to worry about wires popping out or snapping as 30AWG tends to do.

But even with all that...

(gdb) monitor swdp_scan
Target voltage: 3.3V
SW-DP scan failed!

Arg!
I figured I needed the source code for this thing to better understand what could be going wrong; this was easy enough to get hold of - I just cloned the Blackmagic git repo. I also figured I should update the firmware to the latest, because why not!? Maybe it will fix my problem. So I make'd the Makefile after taking care of some dependencies, and used the dfu-util tool to download the generated file to it. And...it stopped working completely! Unplug...replug...nothing; nothing even in dmesg!

I panicked a bit, concerned I had bricked my brand new probe. Fortunately after messing with the button on it, I found that plugging it in *while* the button is depressed puts it in some bootloader mode, where at the very least you can install new things on it; so it wasn't bricked! Still didn't work though...

I realized my error: I needed firmware built for the Jeff Probe, duh! Not the blackmagic probe. They might be compatible from a user perspective, look similar and run largely the same software, but they have different MCUs, different peripherals etc; I'm not sure how I expected it to work.

So I acquired the Jeff Probe fork of the firmware, built it, downloaded it and... same problem; I was befuddled! How is anyone supposed to use this? I spent ages trying to figure it out, incl. manually messing around with the existing supported platforms to match the Jeff Probe (a dangerous game that risks overwriting the bootloader) - my hopes were low and I was almost ready to throw in the towel and just buy a Blackmagic probe so I could get on with my project. Then, somehow, I noticed something: the Jeff Probe repo has a branch called "sam". I checked it out in my repo and lo and behold there it was - the platforms/sam/jeff directory! I had a good feeling about this. I built and downloaded it hungrily....it worked normally! As above, it still didn't find the nRF52810, but I was now able to build firmware from source code - that's some kind of progress!

So while the latest Jeff Probe firmware does seem to support some nRF52 chips (see src/target/nrf51.c), it doesn't support the Control Access Port or "CTRL-AP". This is needed to re-enable access to the main debug port, if it has been protected. So I tried to backport the code to support this, from the original blackmagic repo. After a lot of messing around (things had not changed too much since the Jeff Probe fork, but they had changed somewhat) I got it building.

I downloaded and connected everything, and it showed the access port in the scan! This is the first hard evidence I've had that the wiring is good, and the debug port isn't disabled some other way, so I am super pleased about this.

Attaching seems to be a problem - the probe stops responding... more staring at code... I find that my backported code needs to initialize a struct to default values, which in the modern codebase has been refactored to be done elsewhere. I added the following nonsense to the appropriate place:

t->attach = (void*)nop_function;
t->detach = (void*)nop_function;
t->check_error = (void*)nop_function;
t->mem_read = (void*)nop_function;
t->mem_write = (void*)nop_function;
t->regs_read = (void*)nop_function;
t->regs_write = (void*)nop_function;
t->reset = (void*)nop_function;
t->halt_request = (void*)nop_function;
t->halt_poll = mdm_halt_poll;
t->halt_resume = (void*)nop_function;

and it works! I can now both scan and attach to the Access Port without the probe crashing!

(gdb) monitor swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver 1
      Nordic nRF52 Access Port (protected)
(gdb) attach 1
Attaching to Remote target
warning: while parsing target description: no element found
warning: Could not load XML target description; ignoring
PC register is not available

Here we see the access port is indeed "protected", so we need to unprotect it via the monitor erase_mass command:

(gdb) monitor erase_mass
(gdb) detach
Detaching from program: , Remote target
(gdb) monitor hard_srst
(gdb) monitor swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
1      ARM Cortex-M
2      Nordic nRF52 Access Port

After resetting the chip, "ARM Cortex-M" is clearly visible as another target, meaning I have successfully erased the firmware, unprotecting the debug port; w00t!

I next try attaching to the "ARM Cortex-M" target; it complains about a missing memory map, but registers are accessible. On the missing memory map, more poking (peeking, rather) reveals my chip's device ID is not present in the hard coded list and the probe isn't identifying it as specifically an nRF52; it's falling back to a generic "Cortex-M" CPU target. It looks like the latest blackmagic firmware (from the original blackmagic repo) dispenses with the list and handles things differently, with ignorance of the device ID - probably a more robust approach, as this ID seems to change with chip revision.

Rather than backport these changes too, I simply added my chip's device ID to the list of known nRF52 devices. Rebuild, download, it works:

(gdb) mon swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Nordic nRF52
 2      Nordic nRF52 Access Port
(gdb) attach 1
A program is being debugged already.  Kill it? (y or n) y
Attaching to Remote target
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0xfffffffe in ?? ()
0xfffffffe in ?? ()
(gdb) info mem 
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs 
0   y  	0x00000000 0x00030000 flash blocksize 0x1000 nocache 
1   y  	0x10001000 0x10001100 flash blocksize 0x100 nocache 
2   y  	0x20000000 0x20006000 rw nocache 
(gdb) 

AAAAAAA that was so much messing around!

This should be everything I need in order to get code into the chip, and maybe even debug it.

Here's the repo:

GitHub - routevegetable/blackmagic at sam

In application debugger for ARM Cortex microcontrollers. - GitHub - routevegetable/blackmagic at sam

GitHubroutevegetable

Building & Downloading the firmware is simply a matter of:

make PROBE_HOST=jeff
...
...
...

sudo dfu-util -d 0000:0000 -s 0x2000:leave -D src/blackmagic.bin

Next up, i'll be trying to run some actual code on this thing!

This week for some extra peace of mind, my friend let me use one of their spare rapid tests prior to visiting with them later in the day. With the Omicron variant rampaging around, it seemed like a wise precaution on top of us both being vaccinated/boosted.

This particular test works in conjunction with a smartphone app. After connecting the "analyzer" to the app, you drop your sample in a small hole. 15 minutes later, the app displays the test result.

After the test had given me my negative result, I decided to disassemble the analyzer

The white strip, normally mounted above the PCB, is the COVID-relevant part. This is a seemingly typical lateral flow test strip, positioned such that the end is under the sample-accepting hole. On the other side not pictured are a pair of pregnancy test-style lines. Presumably one shows blue to indicate the test is valid, while the other indicates a positive result when visible. There are some lights and sensors on the PCB aligned with these areas on the strip.

I am tempted to label this another instance of IoT-gone-mad, but maybe this one is potentially justifiable, given high stakes and low cost of powerful electronics, if you absolutely want to remove human error from the equation?

The white round pill-like object appears to be some kind of moisture absorber, which makes sense; the analyzer (and its contained strip) is kept in a sealed bag prior to use.

The QFN32 chip on the left of the PCB is where the magic happens - a Nordic Semiconductor nRF52810. This is a BLE-capable microcontroller with GPIO and some internal peripherals including a temperature sensor. I figured it'd be a fun exercise to try to reprogram the device, perhaps to make a bluetooth temperature sensor or beacon, or something similar. Encouragingly, there are a bunch of nRF52-based boards on Adafruit with complete Arduino-compatible firmware, including parts to drive the BLE radio; hopefully that will not be difficult to leverage here.

I did some poking around with a multimeter, hoping the set of 7 pads near the right end of the PCB was a programming port of some kind. This turned out to be the case, and the 3-wire ARM "SWD" (Serial Wire Debug) port, or "SW-DP" can be found here.

The meanings of each pad, specifically:
1. GND
2. ?
3. ?
4. VDD
5. SWDIO
6. SWCLK
7. Reset

I couldn't find the meaning of #2 and #3 without more poking than I felt like doing for now, though it might come up later.

The MCU has integrated power conditioning/regulation, and there's no obvious external regulator. There's what is probably a P-channel MOSFET between the battery + and VDD. When the analyzer is powered down the gate is pulled high, seemingly to avoid draining the battery via leakage current while not in use.

Though it's physically awkward to verify, the sole button on the device probably holds this gate low when pressed, powering up the MCU. The firmware then likely engages some GPIO to keep the gate low after the button has been released. The MCU can then release that when it decides to power itself off.

While the device is powered up, the button is held down to initiate some 'pairing' with the smartphone app, so I expect there's some extra circuitry that permits the state of the button to be read via a separate GPIO.

I ordered an open source JTAG interface which seems to be nRF52 compatible, glancing at the github repo. I've used such products rarely and could be missing some obvious reason this won't work, but so far it's looking positive. The code in the repo also shows that there's support for the MCU's ERASEALL command via the CTRL-AP or Control Access Port. Confusingly, this is internally referred to as "erase_mass"; this will be needed for writing new code, if it turns out the MCU's program memory is protected.

I'll keep thinking about possible applications for this, and when the JTAG interface arrives in the mail I can actually try some stuff.

Is 'exec' an abstraction leak wrt 'client code'? When a program wants to use some other bit of code to do something, there are a number of ways it does it, including:

• open a socket and send a request/start a communication
• spawn a program to do the thing

Out of these two, the commonality is "I want to invoke someone else's code to perform a service for me". One is saying: "I want to talk to a process which is already running", the other one is "I want to make a new process".

So in order to decide which one to use, your code needs to have an understanding of what a process is, and also how the service you want relates to that concept.

This seems like an irrelevant-to-client-code implementation detail of the service being requested; why should the client know or care if a new memory space and thread must be created to best handle what it's asking for?

This degree of freedom also ends up papered over as necessary:

• A library may be used to abstract the difference, providing a function which internally communicates with a running server or spawns a new program as appropriate.
• Some programs even when exec'd, just tell a running server to start a new instance in its own process (examples: chrome, gnome-terminal)

So my thought is perhaps 'exec' really shouldn't be used by client code. Perhaps it wants to be something more akin to an administration command, like 'mount'.
Perhaps in the days of yore, to exec or not exec was a useful degree of freedom, but these days I'm not sure.

If we were going to make a brand new unix, perhaps systemd would be in charge of execing things; the OS would maintain a registry of installed services, and new programs could invoke those things in some standardized way; it'd be up to the service whether it wanted to spawn a new process, new thread or whatever, to handle a given request.

In general I've been moving away from only building complex/technically-flashy things in my spare time and just trying to build things which are neat, even if they are simple. This is to help me avoid burnout, and quell impulses of perfectionism which tend to monopolize my time.

I'd been doing a bit of reading about solar panels and wanted to build something solar-powered. Particularly with my recent low-power ESP32 escapades, I was ready to do something in that vein. I got to work planning and prototyping with a goal of building a thingy which would collect solar energy, periodically taking a photo and uploading it somewhere.

This all ended up taking far longer than I expected it to.

First Attempt

I started by drawing things in CircuitLab and playing with breadboards. I desired to use a 2.5ish V solar panel I harvested from a yard lantern. I figured that with a boost converter, I could take whatever this panel was putting out up to 5V and use that to charge a supercapacitor. Then I could take another boost converter and use that to power my ESP32-CAM module and boom! Job done! Or...not.

Supercapacitor Charging

First off, you can't just hook a boost converter to a supercapacitor; the supercapacitor has very low impedance and, when it's empty, will effectively 'short out' the boost converter. So you need some kind of current limiting. No problem there - I can just make such thing with an opamp and a reasonably chunky MOSFET. So I did that and, after some messing around, I managed to charge a supercapacitor at a current-limited rate, up to 5V, using a low voltage solar panel. Hurrah!

UVLO

I also needed an undervoltage lockout circuit or UVLO - this circuit avoids powering the ESP32 until some voltage threshold is reached by the supercapacitor. A UVLO then only switches off when a (lower) off-threshold is crossed.

It's needed because the ESP32 sucks quite a lot of power on startup, and if it were allowed to turn on as soon as the boost converter sensed enough supercap charge to start, it would immediately:

• Suck a lot of current out of the supercap
• The supercap voltage would drop too low for the boost converter to operate
• The boost converter would stop working and stop drawing current
• The supercap voltage would go high enough to start the boost converter
• Start all over again

This would repeat over and over and make no progress. No problem! The hysteresis portion of the UVLO can be implemented with an op-amp and positive feedback network, and I already have a dual op-amp chip in the design from the current limiter, so I can use the other op-amp in there with another MOSFET, to implement a UVLO. This also seemed to work, after a little tweaking.

I got a bit carried away

This is where things took a turn for the complicated. I didn't like having 2 boost converters in a design when theoretically, the services of only one should be enough. So I got to designing a circuit that would share the input to the boost converter between the solar input, and the supercap's charge, and would use that boosted output to power the ESP32, and also charge the supercap further when appropriate. It was a neat design and...I basically just couldn't get it working enough.

I even designed/ordered a PCB with all of the above, partially because I just wanted to make a PCB for the first time in a while, but also because I really thought it would work.

There were multiple issues. One of the main ones being that the boost converter kept oscillating when the supercap charge got too low. I took measurements, experimented, asked on IRC and learned a bit more boost converters (A good article https://www.eetimes.com/power-tip-3-damping-the-input-filter-part-1/#), and it turns out that having a small supply impedance is crucial to not accidentally making an oscillator here. I also learned that the supercaps I was using were quite low quality and had high equivalent series resistance (ESR), meaning that the input to the boost converter was wobbling all over the place. Notice in the picture above how I have a bunch of them paralleled.

Second attempt

So after lots of lessons learned I canned that particular design and set about simplifying it all, while also filling in some gaps I left in the previous one. This time, I didn't bother trying to do the boost-converter sharing thing. Instead, I used a higher voltage solar panel (5v), which I could connect to the supercap directly. I still need a UVLO to power on/off the ESP32, but nothing more fancy than that.

Rather than working with the supercaps I had, I did some searching around and acquired some much nicer ones, with much lower ESR (https://www.newark.com/illinois-capacitor/dgh505q5r5/supercap-5f-5-5v-radial/dp/16AC9334). I only needed 1 in the end!

Some New Features

• Programming header/jumper
• Area to mount the actual ESP32 & boost converter
• Space for WS2812 LEDs
• Space for DHT-11 temperature/humidity sensor
• Voltage divider for charge level sensing

This all worked pretty well!

Software

My plan is to not rely on the UVLO during normal operation - while the sun is somewhat out, the ESP32 should try to stay running, checking the supercap charge level and collecting temperature/humidity data, even if there's not enough power to connect to Wifi and upload an image (by far the most power-expensive thing this circuit does).

The ESP32 features a 'deep sleep' mode which shuts down most of the microcontroller, leaving the realtime clock and a small amount of RAM running, so it can wake back up based on a timer or other triggers. See here for more info: https://lastminuteengineers.com/esp32-deep-sleep-wakeup-sources/.

Sleep Algorithm

I played with a bunch of strategies for saving power, but ended up going for the following:
There's a fixed "wifi threshold" - 4.4V. If the ESP32 reads this or higher voltage at startup, it'll try to take a picture and upload it over wifi. If not, it will log data, go to sleep for a bit then try again.

As for how long to sleep, we try 2-minute "short sleeps" for as long as the voltage always appears to be increasing (or staying above wifi threshold) between wakeups.

If the voltage is observed to drop during a short sleep, that means the power cost of waking the ESP32 is outstripping what power the solar panel can provide during a short sleep.

In this case, we switch to 30-minute "long sleeps", staying in this "long sleep" mode until the wifi threshold is reached again. Once the wifi threshold is reached, we go back to trying short sleeps as above.

Data Logging

Making use of the RTC and the RAM which persists through deep sleeps I decided to log the supercap voltage, as well as temperature and humidity from the DHT-11 sensor on every startup, regardless of whether there is enough power for wifi.

Then at the next wifi connection, we upload all of the previously logged data.

Cameras are hard

So it's all working apart from one small detail; the camera is doing ALL KINDS of wacky stuff. I went through various strange failure/glitch modes.

Greenness

At one point, the camera would produce green-tinted images. I went down various rabbit holes suspecting electrical issues, a faulty SPI RAM chip, etc... It turned out to be very straightforward - the camera needs some number of frames to 'warm up' and get its automatic gain control into a good place, and I wasn't giving it that because I was uploading the first frame that came out of it. Makes sense when you think about it!

Timeouts

These OV2640 camera modules seem to be a bit unreliable - both of the ones I have don't always initialize the first time, and sometimes don't produce a frame. Some googling indicates this isn't completely unknown, and my solution is to basically retry a bunch of times, before giving up and going to sleep again.

Frame Corruption

So here's a weird one. I noticed that if the sun moves into frame (or just seemingly randomly at other points), i'd end up getting half a picture; eg:

After much googling, headscratching, playing with registers in the camera and reading the OV2640 Reference Manual, I have a theory about what causes this. The clock architecture is thus:

• The camera's 'main clock' (XVCLK) is generated by the ESP32 (default 20MHz).
• XVCLK is divided by the CLKRC register to generate the pixel/frame clocks internally.
• This resulting clock is further converted via PLL/divider (R_DVP_SP) to PCLK, which is then used to clock data out of the camera and into the ESP32.

So, reducing CLKRC makes the framerate increase, and reducing R_DVP_SP makes the data rate increase. However! One cannot simply reduce R_DVP_SP to its lowest possible value, as it will be shifting data out faster than the I2S peripheral in the ESP32 can consume it. Now, the amount of (JPEG) data to shift out depends on how much the image can be compressed. So I suspect the above happens when there's not enough time to shift out all of the data before the next frame starts. But I haven't confirmed this.

My solution has been to reduce the framerate (via CLKRC), then increase the PCLK (via R_DVP_SP) up to the maximum the ESP32 will tolerate. Leaving more time to get all the data out before the next frame starts.

Tools

CircuitLab

Online circuit simulator & schematic editor - CircuitLab

Powerful online circuit simulator and schematic editor. Easy to learn.

CircuitLab— yigitdemirag

Eagle PCB

EAGLE | PCB Design And Electrical Schematic Software | Autodesk

Autodesk EAGLE is a powerful PCB design & schematic software for professional electronics designers, with easy-to-use schematic editor, and powerful PCB layout.

BUY FUSION 360

ESP32-CAM

Amazon.com: 2 Pack ESP32-CAM WiFi Bluetooth Camera Module Development Board ESP32 with Camera Module OV2640: Computers & Accessories

Amazon.com: 2 Pack ESP32-CAM WiFi Bluetooth Camera Module Development Board ESP32 with Camera Module OV2640: Computers & Accessories

Top 10 Zone

ESP-IDF

espressif/esp-idf

Espressif IoT Development Framework. Official development framework for ESP32. - espressif/esp-idf

GitHubespressif

esp32-camera

espressif/esp32-camera

Contribute to espressif/esp32-camera development by creating an account on GitHub.

GitHubespressif

About a year into the pandemic, I've been working at home for quite some time now.
Aside from the obvious negatives, there are some positives to this whole thing:

• No more commuting! Still relatively new to the San Francisco Bay Area, commuting holds some novelty. I like how it breaks up the day; a kind of life "minigame" if you will. However if I am being honest, I know it harms my productivity, at least in the immediate sense. Compared to days when I am working from home, it takes me a lot longer to "settle down" and start doing stuff in the morning.
• More time! Now there's no commuting, I have more free time. That and lunchtime can be used for things I would just not be able to do before. I can take a walk, work out in the back yard, do yoga or work on projects!
• Less disruption - kinda obvious and a double-edged sword, as I benefit from some degree of diversion. Nonetheless, I can more predictably get stuff done now that I have more control over my physical workspace.
• Ergonomics...okay, here's the deal:

I suck at this! For most of the pandemic, I have been typing away on my tiny 13 inch laptop. I've done some great work that i'm proud of, but DAMN! Particularly without my regular gym visits, my posture has not responded well to this.
Finally I decided enough was enough and DID something about it - I bought a
Heckin' Big Monitor.

Yeah you've got a big monitor; so what?

So, many people in my line of work have giant monitors, multiple monitors, curved monitors etc, so this might not seem world-breaking. But while I've typically had a minimum of 2 monitors at work, I just haven't ever really given this kind of thing a second thought at home. I've stuck to the absolute basics. I've really refused to engage with the question of computer ergonomics at home. Call it ADHD, laziness or penny-pinching, I'd just honestly rather think about and spend money on something else.
So this is a BIG DEAL for me.

The time for looking the other way is over; as a 6'4 sciatica-prone hypermobile person, I have to take this stuff seriously.

How do I use this thing?

So how do I make good use of this eyewatering investment?
I don't need a 34" text editor or a 34" terminal or 34" anything most of the time, so I want to be able to have multiple things on screen at once. With multiple smaller monitors, you can drag/snap windows between the monitors as they both provide a place for a window to maximize to. Things just work; it's intuitive, for user and computer program alike.

A now-commonplace feature in window managers (even Windows 10) is being able to snap a window to half of the screen, or even a quarter, by dragging the window to that side/corner. You can do this with all your windows and boom - you have something like the intuitive flexibility of multiple monitors, but with one monitor. This is pretty great and makes having a giant monitor a whole lot more useful.

Still, it needs to be better though. Moving things around like this feels clunky, and there's no elegant way to take minimized/hidden things and move them to a given part of the screen. I don't want a window limit and I don't want fixed proportions the window can have; it's so much better than nothing, but it's not enough.

Long ago I used AwesomeWM. Awesome is a tiling window manager - its whole deal is breaking the screen up into separate panels which each have one thing in them. I don't remember Awesome very well, but I wanted that kind of thing. My manager strongly suggested another popular tiling window manager - i3wm, but half way through learning the key combinations, I lost the will grind through what was mostly in my head already...

Emacs to the rescue!

I use Emacs! Emacs has all the tiling things. Things which I spent a long time learning and am reasonably comfortable with. I didn't want to do all that hard work again, and I spend a lot of time in Emacs anyway.
I remembered a project EXWM, which makes Emacs a window manager. Basically Emacs plugs into Xorg like any other WM and when a program wants to make a window, emacs makes a buffer for it and there it is. It can be moved around, hidden, whatever, just like any regular Emacs buffer. I tried it long ago, before I was all that familiar with Emacs, and remembered it not working very well. I don't know if that was really true or it was just my inexperience. But now, about a month in, I have to say it's working out pretty well.

Things to take care of

So it turns out there's a bit more to a typical desktop environment than a window manager.

Network Management

While the decisions about what to connect to and other such things are managed by the aptly-named NetworkManager daemon, you need a frontend to control it. Something to give you a list of available wireless networks and let you select one. For most of my Linux usership, this has taken the form of 'nm-applet'. This is a gnome applet that you can right click and basically gives you access to all that stuff. Unless I want a gnome-panel in my Emacs, there's no way I can get nm-applet back. So I googled around and found enwc - an Emacs-based frontend for NetworkManager. It's not too big and clever - it just gives you a list of wifi networks and lets you hit enter to connect to them. Seems to work, though as far as I can tell, doesn't offer any configuration. For that, i'll have to use the 'nmcli' command line tool, which is a rare enough occurrence that I think it's okay.

(require 'enwc)
(setq enwc-default-backend 'nm)
(condition-case nil
    (enwc)
  (error nil))

Audio

When you hit Volume up, Volume down or Mute on your keyboard something has to be listening for that, and know what to do. I googled around and found the pulseaudio-control package, which provides a means for telling Pulseaudio to do those things from Emacs.

; Tell EXWM to send these keys to Emacs
(dolist (k '(XF86AudioLowerVolume
             XF86AudioRaiseVolume
             XF86AudioMute))
  (pushnew k exwm-input-prefix-keys))

; Setup pulseaudio-control's "C-/" keybinding 
(require 'pulseaudio-control)
(pulseaudio-control-default-keybindings)

; Bind the 'media keys' to relevant pulseaudio-control functions
(global-set-key (kbd "<XF86AudioRaiseVolume>") 'pulseaudio-control-increase-volume)
(global-set-key (kbd "<XF86AudioLowerVolume>") 'pulseaudio-control-decrease-volume)
(global-set-key (kbd "<XF86AudioMute>") 'pulseaudio-control-toggle-current-sink-mute)

The first block is needed because if an X window is active in EXWM, it will send these keys to that window. Most applications will not know what to do with these. So adding these to the exwm-input-prefix-keys list means that EXWM will intercept these and let Emacs handle them directly, with the bindings I set up afterward. Simples!

Backlight stuff

Sigh, this was a little annoying to get right. I ended up writing a helper program to do the talking-to-sysfs part of it for me. Seriously rough stuff:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>

#define BL_PATH "/sys/class/backlight/intel_backlight/brightness"

int main(int argc, char **argv)
{
    if(argc == 1)
    {
        int fd = open(BL_PATH, O_RDONLY);

        char buff[10];
        int chars = read(fd, buff, 10);
        buff[chars-1] = '\0';
        puts(buff);
    }
    else
    {
        int value = atol(argv[1]);
        char buff[10];
        int s = snprintf(buff, 10, "%d\n", value);
        buff[9] = '\0';

        int fd = open(BL_PATH, O_WRONLY);
        write(fd, buff, s);
    }

    return 0;
}

I built this, and made it setuid root so it could write to the 'brightness' file.
Now for the second piece:

(defvar backlight-level 4000)
(defconst backlight-step 500)
(defconst backlight-max 7000)

(defun backlight-fn (value)
  (*
   (expt (/ backlight-level (float backlight-max)) 3)
   backlight-max))

(defun backlight-set ()
  (start-process "backlight-set" nil "set_backlight"
                 (format "%d" (backlight-fn backlight-level)))
  (message (format "Backlight: %d/%d" (backlight-fn backlight-level) backlight-max)))


(defun backlight-inc () (interactive)
  (setq backlight-level (min backlight-max (+ backlight-level backlight-step)))
  (backlight-set))

(defun backlight-dec () (interactive)
  (setq backlight-level (max 0 (- backlight-level backlight-step)))
  (backlight-set))

(global-set-key (kbd "<XF86MonBrightnessUp>") 'backlight-inc)
(global-set-key (kbd "<XF86MonBrightnessDown>") 'backlight-dec)

PHEW! What's going on here is I define backlight-set, which calls my 'set_backlight' program above, passing the value of backlight-level to it. Then I define backlight-inc and backlight-dec to add/subtract this level before calling backlight-set. Finally, I add keybindings for it (I need to add these keys to the exwm-input-prefix-keys list too). backlight-fn is also there to give me a nonlinear curve to my backlight setting. It works without this but is less useful - there's a lot more visible difference between levels 1000-1500, and 6500-7000. So this corrects for that and an exponent of 3 feels about right.

Time, Date, Battery

It took me a couple of days to realise the time, date and battery level weren't anywhere to be seen! Fortunately, Emacs has something for this:

(setq display-time-day-and-date t)
(setq display-time-default-load-average nil)
(display-time-mode)

(setq battery-mode-line-format " [ 🔋 %p%% ]")
(setq battery-update-interval 5)
(display-battery-mode)

Pretty self-explanatory; shows time, date and battery in mode line. Works fine.

Window Layouts

Not a requirement, but a lot more useful if you have it:

(winner-mode)

When you use Emacs for everything, it's easy to accidentally C-x 1 all of your other windows away, which can be frustrating. With winner-mode, you can immediately get the previous layout back with a C-c <left>. This is just great and desktop environments need this in general.

Also, I like to use ace-window , which is a more intuitive way to jump between windows than regular C-x o, which doesn't behave very predictably when dealing with more than 2 open ones. It does this by showing a character in the corner of each window, which you can then press to jump to that window. Pretty great...except it doesn't work for EXWM windows. EXWM covers up/doesn't have text area for this character to be shown in (i'm no Emacs expert so maybe there is an easy fix to this), so I have switched away to using winum-mode . This simply puts a number in the modeline of each window, and lets you jump between them via C-x w <window number> .

VPN

I use a corporate VPN for certain things, so I need a way to switch that on and off. I was pleasantly surprised to learn that NetworkManager handles all of this for me - I just wrote some commands to flip the VPN on and off:

(defun vpn-start () (interactive)
       (shell-command "nmcli c up VPN"))

(defun vpn-stop () (interactive)
       (shell-command "nmcli c down VPN"))

Final Words

There are still some nagging issues, like how I haven't got monitor hotplugging working yet. It's a bit of an edge case, as I spend the vast majority of my time just using my big monitor, but it'd be good to get it right. There's also some weirdness around audio sinks appearing/disappearing as my monitor is plugged in/out, sometimes requiring me to open a shell, type cinnamon-settings sound and click around like some n00b to get things straight.

But it's pretty good and I strongly recommend giving EXWM a shot to anyone who seriously uses Emacs. It's a surprisingly low-friction experience and especially useful if you have a big monitor!

Having recently completed a project using the excellent ESP-32 microcontroller, I wanted something new to work on.

After spotting a nice e-ink display on Amazon, I decided it was time to play.

Helpfully, Amazon also suggested a "Universal" e-ink driver board with a built in ESP-32:

At this point, I wondered if this project would be too easy; I was somewhat mistaken...

The FFC on the display has 20 pins; the receptacle on the driver board has 24, so immediately I see i'm going to have to do some work. Looking into the schematic for the driver board and what documentation I could find for the display, these do not connect in any trivial way, though the signals seem to be somewhat comparable.

I've so far been unable to find a technical reference manual for the relevant EPSON s1d13541 display controller, but I found some documentation from a plasticlogic github repo which explains a good amount around how e-ink displays actually work. I've never worked with e-ink displays before and it turns out they aren't completely trivial.

Some noteworthy details I didn't appreciate:

• You need to generate relatively high voltages (the driver board handles this).
• Switching pixels on and off requires factory-generated/calibrated 'waveform' data to be fed into the display's controller at startup.
• This and other such factory-established parameters are stored in an I2C memory which is also stuck to the display in this case.
• The display->host processor interface is SPI, so the memory must be accessed via the display controller's SPI-I2C bridge functionality.

Finally, I found that the code for the PlasticLogic eval kits is available in a github repo!
This code is nicely structured and looks relatively easy to port to ESP32. It takes care of basically everything and comes with everything you need, even example applications to exercise the screen!

I'm currently waiting for some FFC breakout boards to arrive; things are pretty hectic at the moment and I have multiple projects going on elsewhere in my life which cannot be deferred. Hopefully i'll get some time together soon to port some of the demo code to ESP32!

So I recently set up my minecraft server after a very long hiatus; with the shelter in place not ending any time soon, the conditions are surely perfect to get back into this :)

Some things seem to have changed since 2015 or whenever I last properly played Minecraft. My previous setup involved the FTB launcher and the Yogcraft modpack, which included a bunch of silliness including ComputerCraft, BuildCraft and IndustrialCraft. Here's a nugget I found from that time:

You said something about a web server?

Yeah, so I have a bee in my bonnet - I want a 'webserver' in minecraft-land that I can access from the outside world. For no particular reason beyond figuring out if it's reliably doable and what kind of "horrible stuff" is required to make it happen.

Parts

I'm using the FTB Revelation modpack because frankly, it was the first one on the FTB launcher and Yogcraft isn't there anymore. I'm also going to be using creative mode and start with a file in a computer that can be served statically. I remember that computer files used to live in a directory that could be read from outside minecraft; hopefully this is still the case, as it will probably make this a whole lot easier. Here it is:

I made a new file with some known content; let's have a poke around the minecraft server directory and try to find it...

lmarshall@tuvok:~/minecraft/world/computer$ tree
.
├── 0
│   └── myfile.txt
└── lastid.txt

1 directory, 2 files
lmarshall@tuvok:~/minecraft/world/computer$ cat 0/myfile.txt 
TESTFILE

Well that was easy! Guess this is going to be a short one :)

Lets set up nginx

lmarshall@tuvok:~/minecraft/world/computer$ apt install nginx
...
lmarshall@tuvok:~/minecraft/world/computer$ sudo nano /etc/nginx/sites-enabled/default

server { 
        listen 80;
        listen [::]:80;

        server_name mc.routevegetable.com;

        root /home/lmarshall/minecraft/world/computer/0/www;
        index index.html;

        location / {
                try_files $uri $uri/ =404;
        }
}

Annoyingly, I get the router configuration page when I now try to go to http://mc.routevegetable.com in my browser - looks like my router is trying to be helpful. Hmm; gonna have a quick look around for a switch that controls that in the router config...

Ah-hah! I can add a DNS record for my LAN only:

Now a re-connection later to flush my local DNS cache and...

So, there are a couple of things that are unsatisfying about this:

• We hardcoded the path /home/lmarshall/minecraft/world/computer/0/www into the nginx config, meaning that this specific computer is now special, and we can't make another web server without messing with the nginx config.
• It would be pretty awesome to be able to get some real interaction going, so you can trigger programs you write in minecraft. Like a CGI bin, but sandboxed within minecraft.

I think that's enough silliness for this morning.

Recently my place got a new bathroom installed; it's been lacking a sink however, so use has been a bit limited.

Rather than plumbing + affixing a new sink, we heard about these weird sink things that mount on the toilet tank. For the very tiny bathroom that this is, it seemed like a perfect solution.

Got it ordered, it arrived and lo and behold, it didn't fit! The top of the toilet tank was too slim and the sink just kinda rocked around:

Fortunately I had some wood lying around, so I set about it with a jigsaw:

Success!

Finally, turns out nail polish remover gets errant sharpie marker off of plastic; who knew?

Today I decided to send an email to my colleagues about my non-binary gender identity. I'll write more later, but for now, here it is:

Hi all, I wondered what would constitute a good mailing list to send this to. To be honest, I am still not sure but I figured what the hell.
I want to bring to light a detail that's become an increasingly important part of my life and identity over the last few years. After much deliberation, soul searching and consulting with various folks - I'd like to broadcast my status as a non-binary individual.

💼 Executive summary 💼

• I don't identify strictly with masculine or feminine gender.
• I greatly prefer the singular gender-neutral pronouns "they/them/their" for talking about myself

Below is a sort of blog post-style collection of words; I am sure there are many people in <Company Name> who don't require the whole thing, but it seems to be the easiest format for me to cover everything I want to - this stuff's hard!

Wat?

Non-binary gender identity refers to how someone, anyone and anybody, may view themselves as neither strictly masculine, nor strictly feminine. What does it mean to be masculine, feminine or neither or both? What even is gender? 🤷
I don't claim have a universal answer that everyone will agree to; I can only try to articulate my experience, that is: I experience gender as a social construct and I find that where behaviour and internal experience doesn't "match" gender-based expectations, this generates friction and/or shame, and is a bit rubbish. I want to distance this from being a biological conversation of any sort; it's a common tangent which misses the point and frankly, work is not my preferred venue for such topics ;-) .

Why are you telling us this

This is a difficult one and, as little as anyone may understand exactly why being correctly identified matters, it does appear to matter to humans and I appear to be mostly a human ;-) .
In many ways I would *love* for this to be a non issue for me; it would make my life easier! But I want to be a decent, functional blend of realistic, authentic and pragmatic.The experience of fitting in with masculine norms and/or simply tolerating having them applied to me consumes a non-zero amount of my mental + emotional resources; these are resources that I'd rather spend on other things, like <Awful hateful technical task I will have to do soon>. I am honestly tired of holding all of this on my own and would like to give others the opportunity to help me out, even simply reading this and validating my experience makes more of a difference to me than one might expect.

On Pronouns

If you've been hanging around the blogosphere for the last ten years, you may have noticed a rise in people who choose to go public with such an identity; perhaps you've noticed people using gender neutral pronouns they/them/their as singular when referring to such individuals in the third person.
It's not perfect but for me, this is the best that English has to offer and I prefer to be referred to in this way.  This facet is one that some find quite contentious and difficult to get to grips with; there is no pronoun-police and nobody is forcing anyone to do anything; please just know that this is my preference.

Final Word

Identity is a complex subject about which I am absolutely no expert, and gender is but one axis; there are plenty of other important axes including sexuality, race, ethnicity; these are systems of classifying humans which are baked into the collective consciousness, codified into law; these things form the foundations, floors, walls, ceilings, windows and chimney-pots of our society. They are often invisible and not considered, but everything we do is built around them. As such, many people experience issues with identity and many never speak about it; perhaps it isn't emotionally, professionally or even physically safe to do so. I believe that <Company Name> is a safe place for me to share this message, and while nobody has to come out and not everybody can, I want to offer myself as an ally and a cheerleader for anyone here who experiences an atypical gender identity.

Thanks for reading, y'all. If anyone has respectful/sensitive questions, I'd like to try to engage with them.

A while back, I noticed the carpet in the driver's side of my 2001 Corsa C was wet. Pushing down on it would reveal a lot of water just sitting there, with a nasty, squelchy sound.

I spent a week trying to dry it out with hot air, to no avail. I then did some research and it turns out this is a common problem with no easy fix.

The car itself was a steal at less than 900GBP with very little wrong with it, and has served me well for the last 6 months. I wasn't about to blow potentially more than half of that on labor to resolve this non-serious problem, so either I was going to fix it, or it wouldn't be fixed.

I'm pretty inexperienced with car repair. Although I've always known my way around a socket set and I'll confidently work with electricals, I still had a big real-world-experience gap. Nevertheless, I had the internet and some helpful colleagues, and I thought it worth a shot. I also found this fantastic video which shows pretty clearly what needs to be done.

The Problem

Above the pedals, there is a panel in the chassis with a seal around it. Compost and other outside-crap builds up around it, trapping water and rotting the seal. After a decade or so, the seal fails and begins to let water directly into the carpet and soundproofing.

Removing the carpet

The carpet/soundproofing was completely saturated with water and needed to come out before it got too nasty. I set about doing this one weekend, also taking the opportunity to look at the panel and verify the source of the leak using a bucket of water.
Removing the carpet was significantly harder than I had anticipated. The carpet is all in one chunk and needed to be cut out; that is, after various bits of plastic trim and the driver's seat had been removed.

I spent the next few weeks driving around with no carpet/soundproofing, as the chunks of carpet got drier. There were a few sessions of heavy rain, accompanied by puddles as expected.

Fixing it

Last weekend, the weather was finally nice enough to permit the actual fix.
First I had to remove the wipers, plastic panelling under the wipers & wiper motor, detergent bottle and other bits of plastic:

The next step is to get the master cylinder out of the way. This isn't as simple as unbolting and pulling it away as the feed to the clutch cylinder comes out of the right-hand side of the reservoir, and the pipe has very little slack in it; see the spigot on the right:

To detach this pipe without brake fluid going everywhere, I had to use a syringe to suck just enough fluid out of the reservoir that the level was below that of the spigot, but not so low as to expose the brake master cylinder inlets.
After pulling off the clutch cylinder feed tube and unclipping the rigid hydraulic lines from the chassis where I could, I unbolted and pulled the master cylinder away:

The problematic seal is now clearly visible around the black plate behind the brake servo(round black thing). That needed to come off, which was a bit more straightforward than the brake cylinder. This involves yanking the vacuum pipe out of the front of it, and jamming yourself under the pedals to undo a couple of bolts and remove the pin that attaches the brake pedal to the brake servo:

To get to one of these bolts, I needed to remove the accelerator pedal; the hardest part of this was figuring out how to unplug it. The answer is to grab the red face on the side of the plug and pull it toward you; this magically pulls the plug upwards off of the pedal.

After removing the brake servo, you can see the whole seal which I painstakingly extracted with a knife/screwdriver. Here it is half-done:

This was oddly relaxing to do, and took most of an hour.
After cleaning it up with soapy water and an old toothbrush, I resealed it with Plumbers Gold:

It ended up a bit messy, particularly in the bottom-right corner which was quite hard to reach, but as far as I could tell it was well-sealed.

It was then just a matter of doing everything in reverse.

Putting the carpet back

I've been driving around for a week without the carpet back in as I wanted to be sure it wasn't still leaking. We've had a couple of sessions of rain with no puddles, so I'm confident that it's done. It'll probably take an hour or two to get the carpet back in, either today or tomorrow.