External Input Triggering of DAVIS346

[SternSu]

Hi, I am trying to synchronize the DAVIS346 camera with OptiTrack motion capture system. According to this discussion, it seems that if the input signal source can not provide VDD_IN, then the grounds of input signal source and external power supply should be shorted together. I drew a layout based on my understanding, where eSync2 is the  input signal source. I am wondering if this kind of connection is OK? Or will it cause damage to the DAVIS346? 
Thank you for your help.

[Tobi Delbruck]

Thanks for clear post.  I don't know the details of the production DAVIS346 camera board so I don't know if has an isolated external input event circuit like the DVExplorer that requires power.  You can probably try it without any risk of damage if you limit the pulse to 3.3V and don't connect VDD_IN.  I would try this with function generator and just see that you get the events. 

In jAER, the external input event count is shown as a little white bar to the lower left of the display of the chip output. In this screen shot is what I see with no camera attached.

.

Note there are many options in DAVIS346 for these external input events that are selected (in jAER) with the External Input Config panel of the HW configuration frame. I don't know how it is controlled in DV.

 

[SternSu]

Thank you very much for your reply. I have conducted several experiments and the results are:
1. When the VDD_IN was not connected, the number of trigger events was not correct;
2. When the VDD_IN was connected, the number of trigger events was correct;

3. When the synchronization cable was connected to the camera, there were not frames output; when the synchronization cable was disconnected, the frames could be output.

For the 3rd point, I have seen a discussion here. I am wondering is it a bug or something else? Have you encountered this problem?

[Tobi Delbruck]

That's an interesting observation that connecting the sync cable blocks the frame output. As far as I am aware, the sync cable cannot "trigger" frame capture. The name "trigger" is not correct because it implies that the sync can trigger a frame capture. The sync cable input can only cause "external input events" that are recorded to the AEDAT file (and are tagged as "special" events in the stream). But someone from inivation will need to comment on this issue of lack of frames when sync cable is connected, perhaps things have changed.

One thing that might be possible is to detect these events in a packet and then in software trigger a frame capture. But note this will be a synchronous operation on the event packet, not asynchronous at the moment that the sync event is received by PC over USB.

[SternSu]

I see. I will try to contact with iniVation's engineers for more details.

[Luca Longinotti]

Indeed none of the external signals control the frame output directly, BUT if the CLOCK_IN signal is unstable, then the timestamp is getting continuously reset to zero, and that will break the frame output, which expects all of its pixels to come out with an increasing timestamp, and if that's not happening, no frame is generated.

The events just 'slip through' the cracks between timestamp resets and will still be visualized to some extent, but their timestamps will be mostly wrong.

As per our documentation at https://docs.inivation.com/hardware/hardware-advanced-usage/external-camera-sync.html#dvs240-davis346-dvxplorer-dvxplorer-lite VDD AND GND MUST BE PROVIDED!

If they're not, the isolation component on the PCB that receives SIGNAL_IN and CLOCK_IN just won't work and you get very random results. If your signal generator doesn't provide a separate VDD output, then generating it separately (with the same voltage swing) and shorting GND, as per your first drawing, is the correct solution.

If you're not using CLOCK_IN but only SIGNAL_IN, we recommend just also putting VDD on CLOCK_IN which will disable it, if you leave it floating there's a good chance it will couple with SIGNAL_IN over the long cable and go up and down following that signal instead, which will result in the timestamps resetting all the time and the side-effects I described above.

To summarize, if only using SIGNAL_IN:

- VDD_IN and CLOCK_IN -> connect to your VDD, eg 3.3V

- GND_IN -> connect to your GND

- SIGNAL_IN -> connect to your trigger signal

Hope this helps, have a nice day!

-- 

Luca Longinotti (llongi)

Senior Software Engineer
iniVation AG - https://inivation.com/
A SynSense Group company

[Tobi Delbruck]

Great answer Luca, thanks!

One more note from jAER side: If you want to process data with the minimum latency, e.g. trigger frame captures as close in time as possible to when the camera gets external input frame trigger input, then you can activate the EventFilter window option "Process on acquisition cycle" (screenshot below). This undocumented feature will run all the EventFilters in the low level thread that captures the raw USB event packets, with maximum interpacket intervals of 1ms (set by the early packet timer camera setting) going down to 125us with USB high speed interface. Probably even less latency with FX3 and superspeed USB.

I added this feature to jAER many years ago to decrease latency for robots like the goalie robot. 

It has the cost of increased memory copying and the EventFilter rendering onto the display breaks because the rendering occurs in the USB thread, not the GUI Swing thread. So I usually don't use it and instead just increase the target frame rendering rate (right arrow key) and disable the View/Filtering options "Active rendering enabled" option to collapse OpenGL display calls:

What you could do in jAER is to write a small event filter that calls for frame capture when one of the special external input events is found in the packet and then use the Davis camera's takeSnapshot() method to trigger a single frame capture. For example in the EventFilter DavisAutoShooter:

If you are interested, I could add this takeSnapshot()  triggering method to DavisAutoShooter as an option

[SternSu]

Thank you both for your helpful replies! I have tried to connect VDD_IN and CLOCK_IN with the 3.3V VDD, and both the synchronization process and frame acquisition work well. I think it will also be very helpful for other users if this information can be added to the tutorial. 
As for the jAER function takeSnapshot(), does it mean that the grayscale image capture of DAVIS can be controlled by external signals?

[Tobi Delbruck]

takeSnapshot() in DavisBaseCamera is this:  I don't recall now where is the documentation of the configSequence commands or their meanings. 

It is a user-mode software method to trigger a single frame. 

   /**
     * Triggers shot of one APS frame
     */
    @Override
    public void takeSnapshot() {
        // Use a multi-command to send enable and then disable in quickest possible
        // succession to the APS state machine.
        getDavisConfig().setCaptureFramesEnabled(false);

        if ((getHardwareInterface() != null) && (getHardwareInterface() instanceof CypressFX3)) {
            final CypressFX3 fx3HwIntf = (CypressFX3) getHardwareInterface();
            final SPIConfigSequence configSequence = fx3HwIntf.new SPIConfigSequence();

            try {
                configSequence.addConfig(CypressFX3.FPGA_APS, (short) 4, 1);
                configSequence.addConfig(CypressFX3.FPGA_APS, (short) 4, 0);

                configSequence.sendConfigSequence();
            } catch (final HardwareInterfaceException e) {
                // Ignore.
            }
        }
    }

[SternSu]

I see, if I am going to use it in the next step, I will check it for further details.