Open lplana opened 4 years ago
I guess the correct thing to do here would be to bake in the delay. It's not a big deal for retina reconfiguration; that's not something that I'd expect to be frequent during a script run.
With no current funding to support the pushbot this is unlikely to be fixed.
Under certain circumstances, configuration packets sent to the PushBot are dropped by the router. It seems to be the result of the microcontroller on the PushBot being busy and not accepting packets for some time.
Tests suggest that the problem is caused by the packet that configures the retina key. The following 2 packets are delayed in the router buffer and the 3rd and 4th are dropped.
Having looked at the PushBot microcontroller code, there is no clear explanation of the hiatus. It might be due to retina activity keeping the microcontroller busy after the retina configuration packet.
The problem has been reported to @jconradt and is under investigation.
WORKAROUNDS:
Turn on packet reinjection. This will guarantee that configuration packets reach the PushBot, even if they are dropped.
Turn on 'repeats' for the sending of configuration packets. This was tested by setting 'repeat=1' and 'delay_between_repeats=20' in function 'generic_motor_enable()' [file: munich_io_spinnaker_link_protocol.py]. Delays < 20 us did not work.