From jumper wires to a PCB.

The starting point was a feeling I already knew from cycling. A corner can feel fast or cautious, but I wanted a trace that showed how the bike actually leaned through it. That gave the prototype a concrete job: record orientation and keep the data for the ride home.

I kept the first version focused on an ESP32, a motion sensor and a microSD card. Live data on a bike computer can come later. First I need a logger that starts, records on battery and gives me a file I can trust. A number on a display would not prove any of those things.

What I learned: A useful first version has to deliver a complete log before it needs a live display.

The first connections on the breadboard were a way to get the boards talking without committing to an enclosure. The BNO055 talks to the ESP32 over I²C; the SD module uses SPI. Separating those connections made it possible to check the sensor and the card before joining them into one logger.

That stage was easy to rearrange and easy to disturb. I could see readings over USB, but every jumper lead added a contact that could move. Power, ground and the exact pin labels mattered as much as the code. A pin map became more useful than another list of numbers once I had to reconnect the real boards.

What I learned: A successful USB session proves that wiring worked for that session. It does not prove it will survive a ride.

Dupont jumpers made the early build quick. They also left a bundle of plugs, bends and small joints between the boards. Contact trouble kept turning into sensor or storage trouble, so I explored a soldered perfboard carrier to give the connections a fixed place.

That meant designing more than a rectangle around the parts. I had to allow for headers projecting from both sides, cable bends, solder joints and access to the screws. A printed dry-fit template exposed an SD module that extended beyond its reserved space. Later, the drilling and assembly work became too much for the first ride, so I simplified that version to retain the existing wiring in a printed box. The full perfboard assembly is not the version I am taking out first.

What I learned: The outline of a module is only part of its size. Connectors, wires and assembly tools need space too.

I chose the BNO055 because it produces an orientation estimate as a quaternion. I can store that orientation and work on the lean calculation after the ride, rather than start by writing my own sensor-fusion system. The logger uses IMUPLUS mode, with accelerometer and gyro fusion and no magnetometer in that fusion.

Calibration still needed real checking. Writing offsets after a fixed delay was not enough: the sensor could still be in the wrong mode and silently ignore them. Reading the mode back, writing the offsets and checking the registers made the restore observable. The physical mount matters just as much. If the board can rock inside the box, the log includes that movement as well as the bike’s lean.

What I learned: Stored calibration and a rigid sensor mount are measurement requirements. Bench results still need checking on a moving bike.

The logger attempts a reading 20 times a second and stores orientation, timing and calibration status on microSD. Writing and flushing the file can interrupt that rhythm. Long pauses came back at flush boundaries in bench logs, so I kept the timing evidence instead of calling the problem fixed after one quiet run.

Power and contact failures complicated the same job. A brownout is a restart caused by a supply voltage drop; a brief loss of power at the sensor can interrupt useful readings without restarting the ESP32. A later file alone may miss an earlier ride segment after a reset. I therefore need to retrieve every relevant log and inspect gaps. The readout also checks file length and CRC32, because copying text from a serial-monitor window once lost the beginning of a file.

What I learned: Increasing row counts and a finished download do not establish a complete ride. Timing, startup records and transfer checks matter.

The SD adapter has a VCC input that feeds an onboard 1117 regulator. On USB it had the input supply it expected. On battery, the ESP32 board’s 5 V pin did not power it. Feeding that regulator from 3.3 V was not the same as delivering 3.3 V to the card: the regulator dropped the output further.

The working modification supplies the regulator’s output side from the ESP32 board’s 3.3 V rail. The unused VCC pin stays isolated because the regulator can feed voltage back toward that input. After the bypass, the logger ran through a USB-to-battery transition and later recorded a bench run lasting 14 hours and 48 minutes on one cell. That is an observed run in that setup, not a promise of battery life on a bike.

What I learned: Check the complete power path in battery-only operation. A design that works with USB connected can still fail when USB is removed.

The original under-saddle carrier grew around wiring, battery support and fasteners. A CAD model could close and still leave a screw impossible to reach. Printed parts added another check: a USB dust plug that looked snug in the model fell out of the actual opening.

I cut back the first-ride build to one printed enclosure on the existing bottle-cage mounts, with the BNO055 screwed to rigid standoffs. The down-tube position left too little clearance near the chainring, so the current plan uses the seat tube. The closed assembly still needs its clearance and fastening checked on the bike. The tube angle also exposed an analysis error: leaning about the sensor’s own tilted axis gave the wrong result. A synthetic ride checked the corrected calculation with a fixed mounting tilt.

What I learned: Physical clearance and sensor alignment belong in the same test as the angle calculation. A printed box is not a completed fit check.

The website gives the project a place to explain what a lean angle means and why I want to record it. The corner scenes show the idea in motion, and the calculator gives the relationship between speed, radius and lean a concrete form.

Those scenes are illustrations. Their speeds and angles are not measurements from this logger, and the synthetic ride used to test the tools is not a road test. Writing the story forced me to keep the working bench prototype, the mounting plan and the future live display separate. This page adds the less tidy part: the wiring and power faults that changed the next design decision.

What I learned: An explanation is more useful when readers can tell what I built, what I tested and what I still want to try.