I had to pick up BLE peripheral work on the Pi (GATT characteristics and a simple JSON protocol to the phone), threading/async so motor stepping did not stall the main loop, and stepper basics with lgpio—timing, enable polarity, and why the motor sometimes buzzed instead of turning. I also learned enough time and location handling (ISO timestamps, UTC) to compute sun elevation and azimuth on-device and keep it in sync with what the iOS app sends. To learn it, I mostly read library docs and datasheets, used targeted web searches and forum threads when I hit hardware or BlueZ errors, watched a few short setup videos for wiring and drivers, and relied on small test scripts and lots of print logging to isolate BLE vs motor issues before wiring everything into the full app.
This week I focused on getting the sun location, testing, and calibrating the motors:
Sun location — I added on-Pi sun position in sun_location.py. It takes latitude, longitude, and an ISO-8601 time (from the phone over BLE, stored in shared BLE state), converts time to UTC, and computes elevation (degrees above the horizon) and azimuth (0° north, clockwise) using standard solar-position steps (Julian day, declination, equation of time, hour angle, then zenith and azimuth). If GPS is not available yet, it uses a default Pittsburgh coordinate pair and sets source to default_location; otherwise ble_location. integrator.py calls this each loop, treats azimuth/elevation like the old alpha/beta “sun sensor” outputs, and ble_server.update_sun_status pushes sun_azimuth, sun_elevation, sun_source in the JSON the iOS app decodes. Important: automatic shading still follows user-detection errors, not the sun vector; the new work is mainly accurate sun telemetry and a clean base for future sun-aware control.
Motors and smooth motion — motor.py drives vertical and horizontal steppers over lgpio (BCM pins per PINOUT.md), with direction settle time, enable sequencing, short step pulses, and non-blocking moves via a background thread so the 10 Hz integrator loop does not stall. Without GPIO, it logs simulation lines instead of pulsing pins. In integrator.py, send_motor_commands maps tracking error to a bounded step count (roughly proportional to |error|, clamped between 1 and 50 steps) so motion is less jerky than a fixed huge step every tick, and it calls stop_all when there is no command. Calibration in the repo means hardware tuning: ble/motor_test.py is the tool to adjust step timing, optional active-high enable, and slower stepping when drivers buzz or skip steps.
Testing —
Sun: I compared the Pi output to known times/locations or the older logic/sun_calc.py script (pysolar-based prints).
Motors: motor_test.py is the main integration test on real hardware (sudo, Pi). Sensors: small scripts under sensor/ exercise IMU reads.
I plan on adding a few pytest cases for sun math and a smoke test for JSON status fields before demo or handoff.