A small team can reach an awkward stage with a sensor prototype: one person has a working demonstration, and another person has the same board and an import error. A wiring photo and a pasted main.py are often not enough to reproduce the result.
In a Core Electronics forum thread begun in December 2025, a Pico user worked through a BME280 driver setup with help from the community. It is a different sensor, but the exchange shows why the board, the library and the connection details need to travel together. A failing initialization is a much more specific problem than "MicroPython does not work".
Here is the chain we keep for a handoff, using one of our bench setups as the example: a Mysentech MSE soil probe on a Raspberry Pi Pico (RP2040) GraftPort carrier, read over Modbus on a UART. The chain is package, file list, import name, connection settings and actual output. Following it gives a teammate or an engineering partner something they can inspect before anyone changes the hardware.
Keep the files behind the example
Our MSE driver package, version 1.0.0, contains three kinds of file: an example main.py, a sensor module that provides named operations, and a Modbus library under umodbus that exchanges messages with the device. Each does a different job, and the example will not run without the other two.
Two common traps follow from that:
- Copying only
main.py. It imports modules that are not in the file, so the next person gets an import error on the first line. - Guessing the import name from the package name. The package is called
mse_soil_sensor_driver; the Python module it provides ismse_soil_sensor. The file list makes that obvious. A download title does not.
Record the package name, its version and the full file list in the handoff, not only the script.
Record the connection settings with the driver version
Our program selected Modbus device address 1 and UART0 at 9600 baud, with GPIO16 transmitting and GPIO17 receiving. Those settings belong beside the driver version. A script written for one set of pins does not follow a cable moved to another connector, and a sensor configured for another address or baud rate will simply not answer.
The physical adapter is part of the record too. Our probe connected to the carrier through a small cable adapter, and the probe's R and T pins go to the host's TX and RX respectively. "Connect the sensor" hides exactly the detail that most often goes wrong; a photo plus a pin table does not.
Use a known output as the next checkpoint
MicroPython's mpremote documentation covers copying files to a board and running code on it. Match the instructions to the firmware you have installed: the latest page describes the development branch, and our setup ran MicroPython v1.23.0. Put the firmware version in the handoff as well.
Once the files and connection are in place, compare what the program prints. Our run printed a startup message, then temperature, capacitance and configuration fields: 26.5 °C and 31.07 pF in two consecutive blocks. That gives the receiving engineer the output format to expect. It is not a target every probe should reproduce.
One more behavior belongs in the handoff. Our complete example writes a temperature-compensation coefficient to the sensor before its read loop. If the recipient thinks they are running a read-only check, they will change the sensor's configuration without knowing it. Say so explicitly, or provide a read-only variant.
When something fails, the stage tells you where to look:
- Import error: the files available to the interpreter.
- Program starts but the device does not answer: the interface, address, baud rate and wiring.
- Values come back but look wrong: the raw fields and the configuration, which is why both should be logged.
Preserve the errors as well as the successful reads
A second setup in the same sensor family shows why a cropped "success" screenshot is not enough. When we read a Mysentech HDS sensor's registers with the Modbus Poll desktop tool, the window showed returned register values and also a running count of 174 transmissions and 58 errors.
That is evidence that data came back over an imperfect link. It is not proof of an error-free connection. The next engineer should receive that context, not inherit an unexplained assumption that communication is stable. Intermittent errors at the bench can get worse with longer cables, a motor nearby or a different power supply.
Our sensors share Modbus over UART, but other sensors in a product may use I2C, OneWire or plain digital inputs. Whatever the bus, a good handoff carries the recipe for that particular device: files, versions, firmware, connection, settings, the observed output and any unresolved behavior. The recipient should not have to infer any of it from a model number.