<!--order=12-->

<h1>Building a Small Edge Computing Lab</h1>
<p>A few different boards become much more useful when they are treated as a small lab instead of a pile of unrelated computers. The goal is not to make every board do everything; it is to make each role clear, observable, and replaceable.</p>

<h2>Give Every Device an Identity</h2>
<pre>
pi5-gateway-16g
pi5-gateway-04a
pi5-gateway-04b
vim3-edge-01
field-pico-01
field-pico-02
</pre>
<p>Use names that describe the device and its job. Record the board revision, memory size, radio variant, antenna, firmware, operating system, and location in a small inventory file. This prevents a later “which Pico was that?” problem.</p>

<h2>Keep a Hardware Notebook</h2>
<pre>
Device:
Board:
MCU / CPU:
RAM and storage:
LoRa chip and regional band:
Antenna:
Power source:
Firmware / OS:
Serial device:
Last known-good test:
</pre>
<p>Photographs are useful too. Take one of the board before closing an enclosure and one showing the antenna and cable route. A written record is part of the system, not paperwork added after the system is finished.</p>

<h2>Use the Pi 5 and VIM3 as Test Hosts</h2>
<p>The two 4 GB Pi 5 boards can be dedicated to repeatable gateway and service tests while the 16 GB board remains the main development and analysis machine. The VIM3 can host a second Linux environment, test eMMC-based logging, or run a local processing experiment without changing the primary gateway.</p>
<pre>
Development host:
  write and test code, keep backups, inspect data

Gateway host:
  connect to the USB Pico, log the mesh, run continuously

Comparison host:
  repeat the same logger or workload on the VIM3
  compare storage, temperature, CPU load, and recovery behavior
</pre>

<h2>Test the Failure Cases</h2>
<ul>
  <li>Unplug and reconnect the USB Pico. Does the gateway find the same stable device?</li>
  <li>Reboot the Linux host. Does the logger restart and produce a visible status message?</li>
  <li>Remove network access. Does local LoRa communication and logging continue?</li>
  <li>Let a field node report a low battery. Is the warning visible at the gateway?</li>
  <li>Fill a test filesystem or rotate a database backup. Does the service fail safely?</li>
  <li>Change one modem or channel setting. Can you identify the mismatch from the logs?</li>
</ul>

<h2>Measure Instead of Guessing</h2>
<pre>
For each host, record:
  CPU temperature at idle and under load
  memory use
  storage write speed and free space
  USB serial reconnect behavior
  gateway packet count
  RSSI, SNR, and packet loss
  power draw at idle and during radio activity
</pre>
<p>These measurements make the choice between Pi 5, VIM3, Pico, and Pico 2 evidence-based. The best board for a prototype is not always the best board for an unattended field deployment.</p>

<h2>Keep the Lab Reproducible</h2>
<ul>
  <li>Keep Python projects in virtual environments and record their requirements.</li>
  <li>Export Meshtastic configurations after a successful test.</li>
  <li>Keep firmware files and release notes with the deployment record.</li>
  <li>Use scripts for repeated checks instead of relying on memory.</li>
  <li>Make backups before changing the gateway database or radio configuration.</li>
</ul>
<p>The lab becomes valuable when someone can rebuild a working node from the notes without needing to remember every detail of the original setup.</p>

<h2>References</h2>
<ul>
  <li><a href="https://meshtastic.org/docs/software/python/cli/" target="_blank" rel="noopener">Meshtastic Python CLI Documentation ↗</a></li>
  <li><a href="https://docs.python.org/3/library/venv.html" target="_blank" rel="noopener">Python Virtual Environments ↗</a></li>
</ul>