<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Tom Armstrong — workbench notes</title>
    <link>https://tomarmstrong.net/notes/index.html</link>
    <atom:link href="https://tomarmstrong.net/notes/feed.xml" rel="self" type="application/rss+xml" />
    <description>A few notes from projects I’m actively developing, testing and learning from.</description>
    <language>en</language>
    <item>
      <title>FieldNode — Sync and Power-Off Fixes</title>
      <link>https://tomarmstrong.net/notes/fieldnode-sync-and-power-fixes.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldnode-sync-and-power-fixes.html</guid>
      <pubDate>Sun, 25 Oct 2026 21:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldnode</category><category>firmware</category><category>sync</category><category>power</category>
      <description>The sync sweep showed nodes missing windows even when the hub was on time. The cause was in the node firmware, and fixing it became a set of small changes, each checked on the bench before the next.</description>
      <content:encoded><![CDATA[<p>After each reading a node set its next wake for one interval from now, so every wake drifted later by the length of the wake. Nodes released by the same sync window drifted together. When a reading was still running at the pre-wake minute of the next sync, the node skipped that window completely and powered off with its radio never switched on.</p>
<p>The fix went in as seven small changes, each checked on the bench before the next:</p>
<ul><li>Readings are scheduled on the UTC clock grid, so all nodes sample in the same minute and nothing drifts.</li><li>An alarm that comes due while a node is awake is handled before it sleeps, instead of being cleared.</li><li>A node never releases power over a pending RTC alarm. On the V3 board a set alarm can hold the power switch on, which used to leave the node awake and doing nothing.</li><li>A node that loses its clock listens for the hub for 4 s of every 45 s, then recovers its time from the next window. Before, it stayed awake with its radio off until the battery was flat.</li><li>A node removed from a hub stays on the radio for its idle period instead of cutting power at once.</li><li>A queued time update is aged by however long it waited before it is applied.</li><li>Daily sync mode is removed, so the interval is the only schedule.</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>Auris — Choosing Parts for the Audio Front End</title>
      <link>https://tomarmstrong.net/notes/auris-audio-front-end-parts.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/auris-audio-front-end-parts.html</guid>
      <pubDate>Sun, 25 Oct 2026 19:00:00 +0000</pubDate>
      <category>Project update</category><category>auris</category><category>acoustics</category><category>audio</category><category>hardware</category>
      <description>Every part in the Auris audio front end now has an exact part number, and the passives were chosen for what they do to the signal. Ceramic capacitors, for example, can turn enclosure vibration into noise.</description>
      <content:encoded><![CDATA[<p>The audio front end is the first part of Auris to reach exact part numbers. Every fitted component now has a specific LCSC part, apart from the test pads, which are bare copper. The guide's build stops if one is missing, so the parts list and the design can't drift apart.</p>
<p>Picking the parts meant checking each passive against what it does in the signal path. Class II ceramic capacitors (X5R, X7R) are piezoelectric, so on a high-impedance bias node, wind or rain vibration on the enclosure can show up as signal. The signal-path capacitors are therefore C0G, and the bias and DC-blocking capacitors are tantalum. The mic-bias filter moved from "tantalum or polymer" to a tantalum part, because polymer capacitors leak more and that leakage would add noise to the bias. Where no DC flows, as in the ADC input series resistors, thick film does the job. Thin film stays on the resistors that carry DC or set the gain.</p>
<p>The check also caught one of my own mistakes. The preamp mid-rail capacitor was listed as a ceramic, which is exactly what the reasoning above rules out, and it is now tantalum.</p>
<p>The power and LTE sections get the same check next.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldHub V2 — Sync Sweep Results</title>
      <link>https://tomarmstrong.net/notes/fieldhub-v2-sync-sweep-results.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldhub-v2-sync-sweep-results.html</guid>
      <pubDate>Sat, 24 Oct 2026 20:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldhub</category><category>esp-now</category><category>sync</category><category>scaling</category>
      <description>I ran the sync test I had planned, adding a controlled boot delay to the hub and counting how many nodes still made the sync window. Nodes were lost from a 35 s delay, and waking the hub earlier moved that edge to 70 s.</description>
      <content:encoded><![CDATA[<p>In the last update I said I would test how hub boot time affects synchronisation. The test is done. I injected a controlled delay of up to 85 s before each sync window on Hub V2 and counted how many of the two nodes made it in. Each delay was sampled twice, apart from the 0 s step in the second run, whose first window wasn't logged.</p>
<p>With the original timing, both nodes joined at every delay up to 30 s and neither did from 35 s. That is where the timing model puts the edge. Nodes stop listening 25 s after the slot, so a hub whose boot takes longer than its wake-up lead plus 25 s misses them completely.</p>
<p>Waking the hub 45 s before the slot instead of 10 s, and closing the window as soon as every node has checked in, moved the edge to 70 s, again where the model predicts. Both nodes joined at every delay up to 65 s, except one step at 30 s where a node-side bug lost the window in both passes. With both nodes present a window now takes about four seconds. A missed window costs time rather than data: after four empty windows each node arrived with ten queued readings, and the hub took all twenty in under seven seconds.</p>
<figure><img src="https://tomarmstrong.net/assets/project_pics/fieldmesh/fieldhub-sync-sweep.webp" alt="Dot plot of how many of the two nodes joined each sync window against injected hub boot delay, in two panels. With the original timing both nodes joined up to a 30 s delay and neither from 35 s. With the hub woken 45 s before the slot both nodes joined up to 65 s, except at 30 s where one pass lost one node and the other lost both because of a node-side bug, and neither joined from 70 s." title="Nodes that joined each sync window against injected hub boot delay, two nodes against Hub V2. Each dot is one window." loading="lazy" decoding="async" /><figcaption>Nodes that joined each sync window against injected hub boot delay, two nodes against Hub V2. Each dot is one window.</figcaption></figure>
<p>This was two nodes in one room, with a bench hub that has no modem, so it says nothing yet about fleet size or radio contention. A later single-pass re-run put the edge in the same place. The node-side bug is fixed in the next note, but I haven't repeated the sweep since.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldHub V2 — Sensor Bring-Up</title>
      <link>https://tomarmstrong.net/notes/fieldhub-v2-sensor-bring-up.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldhub-v2-sensor-bring-up.html</guid>
      <pubDate>Fri, 23 Oct 2026 15:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldhub</category><category>bring-up</category><category>i2c</category><category>adc</category>
      <description>The latest FieldHub V2 prototype is now well into bench bring-up.</description>
      <content:encoded><![CDATA[<p>The four external I²C sensor ports have been verified with an SHT40, including operation at 400 kHz. The ADS1015 analogue inputs are also working across all four channels, with measurements within about 1% of my reference meter and no observed crosstalk.</p>
<p>The reed-switch input works functionally, but testing confirmed that the current GPIO choice is susceptible to interference from Wi-Fi and ADC activity. That will be corrected in the next revision.</p>
<p>A few tests remain, including ESP-NOW communication, RTC backup retention and longer wake-cycle testing.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldHub V2 — Scaling the Network</title>
      <link>https://tomarmstrong.net/notes/fieldhub-v2-scaling-the-network.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldhub-v2-scaling-the-network.html</guid>
      <pubDate>Fri, 23 Oct 2026 14:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldhub</category><category>esp-now</category><category>sync</category><category>scaling</category>
      <description>With the core hardware coming through bring-up, I’ve started looking more closely at how FieldMesh behaves as the network grows.</description>
      <content:encoded><![CDATA[<p>The first test will examine the timing between the hub and multiple wireless nodes. Earlier field data suggests hub boot time can reduce the overlap available for synchronisation, so I’ll test this directly by injecting controlled boot delays while running two nodes against the new Hub V2 hardware.</p>
<p>The goal is to replace theoretical node-capacity estimates with measured behaviour before scaling the system further.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldNode V4 — PCB Layout Complete</title>
      <link>https://tomarmstrong.net/notes/fieldnode-v4-pcb-layout-complete.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldnode-v4-pcb-layout-complete.html</guid>
      <pubDate>Fri, 23 Oct 2026 13:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldnode</category><category>pcb</category><category>sdi-12</category><category>rs-485</category>
      <description>The FieldNode V4 PCB layout is complete and a prototype manufacturing package has been prepared.</description>
      <content:encoded><![CDATA[<p>V4 is a substantial redesign focused on flexible environmental sensing, with selectable sensor power, protected analogue inputs, I²C expansion, reed inputs, RS-485/Modbus and SDI-12 support.</p>
<p>A final independent review identified several small but important changes before fabrication, including an incorrect SDI-12 resistor value and improvements to reverse-battery protection.</p>
<p>Those changes are being incorporated before prototype production.</p>]]></content:encoded>
    </item>
    <item>
      <title>Auris — From Concept to Hardware</title>
      <link>https://tomarmstrong.net/notes/auris-from-concept-to-hardware.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/auris-from-concept-to-hardware.html</guid>
      <pubDate>Fri, 23 Oct 2026 12:00:00 +0000</pubDate>
      <category>Project update</category><category>auris</category><category>acoustics</category><category>audio</category><category>lte</category>
      <description>I’ve started developing Auris, an early-stage autonomous acoustic monitoring platform.</description>
      <content:encoded><![CDATA[<p>The first design work has focused on the audio front end, solar power architecture and LTE connectivity.</p>
<p>The current architecture uses a dedicated audio ADC with configurable input paths, a low-power solar system derived from FieldMesh, and a compact LTE modem selected for coverage across Europe, Australia and New Zealand.</p>
<p>The audio, power and communications sections are now defined, with the MCU and processing architecture next.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldMesh — Updating the Public Project</title>
      <link>https://tomarmstrong.net/notes/fieldmesh-updating-the-public-project.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldmesh-updating-the-public-project.html</guid>
      <pubDate>Fri, 23 Oct 2026 11:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldmesh</category><category>website</category>
      <description>I’ve also been updating the public FieldMesh project pages so they reflect the current hardware rather than earlier concepts.</description>
      <content:encoded><![CDATA[<p>The older node renders have been replaced with new FieldHub V2 visuals across the project page and homepage cards, including responsive WebP versions and an updated link-preview image.</p>
<p>I’m also tightening the written case study against the actual repositories so that public descriptions distinguish clearly between what has been built, what has been tested and what is still planned.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldMesh Node V4</title>
      <link>https://tomarmstrong.net/notes/fieldmesh-node-v4.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldmesh-node-v4.html</guid>
      <pubDate>Sun, 18 Oct 2026 00:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldmesh</category><category>pcb</category><category>power</category>
      <description>The Node V4 schematic has completed a major review cycle and is moving toward PCB layout.</description>
      <content:encoded><![CDATA[<p>Recent work includes a revised solar charging architecture, selectable 3.3 V / 5 V / 12 V sensor power, protected analogue inputs, I²C expansion, RS-485/Modbus and SDI-12 support.</p>
<p>The review process has also become more rigorous, with important findings checked against primary-source documentation before they are accepted.</p>]]></content:encoded>
    </item>
    <item>
      <title>Sketch Surf</title>
      <link>https://tomarmstrong.net/notes/sketch-surf.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/sketch-surf.html</guid>
      <pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
      <category>Project update</category><category>sketch-surf</category><category>app</category>
      <description>Sketch Surf reached version 1.4.0 this week.</description>
      <content:encoded><![CDATA[<p>The app combines observed wind, buoy and rainfall data with AI-assisted forecast calls and a structured surf log.</p>
<p>Recent work focused on short-term wind observations, better handling of manual forecast requests and improving data integrity when older sessions are edited.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldHub V2</title>
      <link>https://tomarmstrong.net/notes/fieldhub-v2.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldhub-v2.html</guid>
      <pubDate>Fri, 16 Oct 2026 00:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldhub</category><category>pcb</category><category>prototype</category>
      <description>FieldHub V2 has moved through final prototype-production checks.</description>
      <content:encoded><![CDATA[<p>The latest revision includes a redesigned solar charging stage and several layout refinements around power conversion, feedback sensing and assembly.</p>
<p>The current board has been cleared for a small five-board prototype run, with a structured bench bring-up plan ready for when the boards arrive.</p>]]></content:encoded>
    </item>
    <item>
      <title>FieldMesh Platform</title>
      <link>https://tomarmstrong.net/notes/fieldmesh-platform.html</link>
      <guid isPermaLink="true">https://tomarmstrong.net/notes/fieldmesh-platform.html</guid>
      <pubDate>Thu, 15 Oct 2026 00:00:00 +0000</pubDate>
      <category>Project update</category><category>fieldmesh</category><category>firmware</category><category>backend</category>
      <description>FieldMesh completed a substantial backend and firmware hardening pass.</description>
      <content:encoded><![CDATA[<p>The system now uses a single backend, signed firmware updates, short-lived provisioning codes, stronger device-state handling, and additional race-condition testing.</p>
<p>A read-only demo project is also available for demonstrations and conference use.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
