Four weeks on the bench, and a first board

In four weeks on the bench the Sparton has streamed into the maths on the STM32, bench buoys have posted to the WII6 cloud and taken commands back, sleep and firmware update have worked on development boards, and I have drawn and routed the rev A main board.

WII6 was announced on 14 September. I put the first NUCLEO-U575ZI-Q on the bench on 22 September, and a XIAO ESP32-S3 beside it the day after as the debug processor. This is what I have had working since, and what the first board looks like.

The Sparton into the maths

The firmware programs the Sparton AHRS on the bench, and the sensor streams its binary record at 64 Hz with a CRC on every frame. A ten-minute capture of 40,960 frames goes to the card with the wave maths fed as the frames arrive. I saw no gaps and no CRC errors, and on a still desk the result was noise, as it should be. The maths library on the board gives the same result as the workstation on the same record.

On 7 October I tilted the instrument through a capture to settle the sign conventions. The accelerometer agreed with one body-frame model in 4,602 frames of 4,603, and the synthetic sea used in testing had assumed the other, so the direction results of the first library releases were half a turn out on real data. The Spartons deployed on WII5 buoys read the same way. Library 0.4.0 corrects it.

The WII6 cloud

The WII6 cloud has been up over HTTPS since 4 October. A bench buoy posts the same binary message it would send over Iridium, through the ESP32 over WiFi, and the cloud stores the bytes, decodes them against the format registry and shows the capture. On 7 October I queued a command in the cloud, and it was delivered to the buoy, run, and acknowledged in the buoy’s next message. Every message now carries the buoy’s clock drift, so a fleet’s clocks can be watched from the cloud. The raw 64 Hz record of a capture, 2.1 MB, reaches the cloud from the bench in about four minutes.

The cycle, sleep and firmware update

The buoy runs a cycle: wake, capture on a fifteen-minute slot, transmit, sleep. The STM32 sleeps in STOP2 between captures, stopped for about ninety per cent of the sleep, and I can still reach it through the ESP32 while it sleeps.

MCUboot sits in front of both processors. A new STM32 image travels through the ESP32 in 1,501-byte chunks, including into a sleeping STM32, and runs on trial until its first transmit confirms it; a reset before then reverts to the previous image. I tried a tampered image and a raw image, and the bootloader refused both. A reset part way through the swap resumed at the next boot. The ESP32 takes an image of its own over WiFi the same way. A 120-second watchdog is armed by the bootloader on every boot.

The board

I drew and routed revision A of the main board on 8 October, with every part specified for factory assembly and the electrical and design rule checks clean. Each peripheral sits on its own switched and monitored supply, so the firmware can turn it off between jobs and see that it is off. Five boards are planned for revision A.

If you are planning a season, get in touch for the current schedule.