Files
2026-10-02 12:23:58 -04:00

2.4 KiB
Raw Permalink Blame History

Wired gaze-link bench — 2026-09-27

Hardware: DFRobot DFR1154 V1.1 camera (MAC E8:F6:0A:87:0B:4C), Waveshare eye Board 1 (…CF:F8), and Board 2 (…D2:10). Camera GPIO43 TX fans out to both eye GPIO44 RX pins, with common ground. All three use their separate USB diagnostic/power ports; the eye UART USB-C ports are unplugged.

Normal tracking

Command: python3 firmware/tools/capture_gaze.py --camera /dev/cu.usbmodem11401 --eye1 /dev/cu.usbmodem11201 --eye2 /dev/cu.usbmodem11101 --duration 12. Both receivers reported GAZE_READY ... recent=1 bad_format=0 bad_sequence=0 and accepted the same live sequence/coordinates, including seq=31 x=655 y=774 valid=1 and seq=37 x=830 y=715 valid=1. Both also accepted valid=0 idle commands. Joshua confirmed both screens switched to TRACK and their irises followed together when moving left and right in front of the camera. This is a user-observed bench result; no video was saved.

Malformed/stale injection

The camera was temporarily built with FREDDY_GAZE_LINK_SELF_TEST=1 and flashed to its MAC-verified board. At boot it sent sequence 61440 (valid=0), the duplicate 61440, old sequence 61439, a wrong-version 61441, a bad-CRC 61441, and fresh recovery sequence 61442. Both eye USB logs showed:

39.227 eye1 GAZE_ACCEPT board=1 seq=61440 x=500 y=500 valid=0
39.229 eye2 GAZE_ACCEPT board=2 seq=61440 x=500 y=500 valid=0
39.385 eye1 GAZE_REJECT board=1 reason=sequence
39.543 eye1 GAZE_REJECT board=1 reason=sequence
39.545 eye2 GAZE_REJECT board=2 reason=sequence
39.545 eye2 GAZE_REJECT board=2 reason=sequence
39.701 eye1 GAZE_REJECT board=1 reason=format
39.702 eye2 GAZE_REJECT board=2 reason=format
39.859 eye1 GAZE_REJECT board=1 reason=format
39.861 eye2 GAZE_REJECT board=2 reason=format
40.018 eye1 GAZE_ACCEPT board=1 seq=61442 x=500 y=500 valid=0
40.097 eye2 GAZE_ACCEPT board=2 seq=61442 x=500 y=500 valid=0

Each board's next GAZE_READY reported bad_format=2 bad_sequence=2. The diagnostic send is compiled out in the normal build. After restoring that build, the camera application flash was hash-verified and both eyes again accepted matching normal sequences, including 43–46. The restored application SHA-256 is 0acc763624b20a09afbf512e20afad51ffc9de4276102ffa639a0345d39d70a5.

The camera was powered/reset during this bench, and the receivers reported recent=0, but no active-TRACK loss-of-signal timeout was observed. That visual test remains open.