Temporal alignment —image timestamps upon data capture

[lionfish0]

How we we calibrate the camera clocks/timing accurately?

trying to (a) match up the times the camera triggers were fired [by the pi] with which image (sent later down the ethernet to the pi) matches each trigger and (b) getting precise enough times (they seem to jitter +/-150ms)

How fast are bees? (What timing resolution is necessary)

The pin trigger and the camera capture aren't perfectly correlated.

There may also be time jitter if the time lag itself varies over time.

Ideas

• Do we need a dedicated CPU on the Pi? (e.g. systemd service with cgroup dedicated core)
• Do we need a physical electronic trigger? (Does Raspberry Pi GPIO cause delays due to how the OS works?)
• NTP time service: how accurate is this?
• Clock onboard camera??
• Andrew Straw has written some driver code to drive a display e.g. a clock - it might be really useful for us to do something like this to get more accurate timing or triggering. because the LED pin is driven from the kernel clock on the Pi, the clock can be marshalled with NTP or PTP. For now I just got this code running and so far didn’t have time to validate that it truly gives blinking with microsecond or better precision in absolute time
• Binary LED clock in the field that's photographed

The problem might be that this only solves the problem of "jitter" in the timings, but the difference between cameras might still be a problem (in principle we should be able to set all the pis to the right time to the nearest 3-5ms, but I didn't have success!).

[lionfish0]

Plan:

1) Either (a) rely on initial [wifi] call to trigger the cameras being assumed to be synchronised (b) think of another way of sending a sync signal to all the cameras? (c) Use a version of the binary clock to sync them 2) During operation we can use buffer.get_timestamp() after raw = np.frombuffer(buffer.get_data(),dtype=np.uint8).astype(float). About here.

I think these numbers are the times the images were captured in nanoseconds since power-up.

Note: I think I'll go with option (a) and start on building the binary clock into the Matrix Code spatial registration object.

References

• Aravis docs
• A vaguely relevant issue

[lionfish0]

closing as the bee_track issue can deal with this.