I am a software engineer from Brighton. I studied at Southampton. I now live and work in Seattle. For my day job, I design, test and deploy code for what you might call underwater drones. Oh, and I support the Albion.
The moniker? My granddad was from Mull.
Oceanographic instruments, such as gliders and floats (we don't actually call them drones), have to
- move up and down in the world's oceans
- collect data from various sensors
- at the surface, beam data home using Iridium sat comms
- download further commands for continued operation
- do all the above for years on a single battery pack
- Embedded Systems Programming, aka Bare-Metal
- Real-time Operating Systems
- Iridium Sat Comms (both Short-Burst Data and Dial-up/RUDICS)
- Underwater Communications (Acoustic modems)
- Cryptography (AES, RSA, Stream ciphers, One-time pads)
- Concurrent Programming (Unix, IPC)
- Data visualization (JFreeChart)
- Geospatial (Maps, Projections)
- Network Programming (sockets)
- Data compression
- Simulations/Models
A time-ordered event queue, enabling time to be used as a file descriptor. Realizes a single-threaded concurrent programming model where a simple main loop can listen to I/O from many devices simultaneously while also servicing timed (esp I/O timeout) actions. Multi-threaded programming, just say no. More on the Executive here.
An API for structured conversations with (mostly serial/rs232) devices. Builds upon the Executive, adding regular expressions, resulting in a clean, powerful and verifiable method for device interfacing. We all draw state machines on the whiteboard. This API translates those diagrams directly into code.
Applied the fragmentation/assembly technique in the IP protocol (OSI model layer 3) to both underwater data transfer using acoustic modems and to Iridium Short-Burst Data (SBD) data transfer. In both domains, the data to be sent (layers down to 4) is larger than can be handled by the data/physical layer (layer 2).
Used the crontab event scheduling syntax, along with a cron-like Executive loop, as the method by which pilots control data acquisition schedules on remote, rarely-connected, systems.
Have a remotely-deployed system download and run an arbitrary script (bash, etc) via e.g. Iridium sat comms. Capture the output via simple redirection and upload back to pilot. The gateway to remote system administration, as it permits solutions to problems never anticipated to occur when the unit was deployed. Have saved some very complex (read expensive) instruments with this.
- TCP/IP
- HTTP
- IMAP
- I2C
- RS232/485
- Environment: Unix
- Languages: C, Java, bash
- Tools: regex, pseudo-terminals
- Build: make, maven
- Versioning: git, semver
- C++
- ARM Cortex M Assembler
- Reverse Engineering (HexRays, IDA)
- Parsers and Code Generation (Antlr, lex+yacc)
- cron
I have managed to open source various bits and pieces over the years
- The Executive - Multiplexing I/O and Timed Actions
- Real-time Operating Systems - Building the RTX RTOS using make/gcc
- Cryptography - A filesystem based on one-time pads
- Networking - Observing TCP data flow
- Embedded Systems - Capturing fault dumps on ARM Cortex M
I follow, and have contributed to, various products, blogs and forums. These include