DVXplorer Lite Python recordings: first run after camera replug is valid, later runs show unusual noise until replug

[Aryan Thakur]

Hello,
I am using a DVXplorer Lite camera with python (version 3.14.4) and dv-processing (version 2.0.3) on Fedora release 43. I am seeing unusual behavior across repeated recordings from the provided sample script and my own python capture scripts to capture camera data after the first run has ended.

I reproduced it using one of the provided sample scripts from the gitlab repository, specifically writer_mono_dvs.py (https://gitlab.com/inivation/dv/dv-processing/-/blob/master/python/samples/writer_mono_dvs.py). 

My procedure was
1. Physically unplug/replug the camera.
2. Run the Python recording script once while sweeping a laser across a diffuser in front of the camera. 

3. Let the Python process exit normally with ctrl+c.
4. Without unplugging the camera, run the same script a second time with the same sweeping laser.
5. Without unplugging the camera, run the same script a third time with the same sweeping laser.

What I found was that my first run contained my expected run data.

However the two runs afterwards had the unusual noise 

More specifically, I characterized it by when I see more than 99% on events and less than 1% off events at a rate of about 109k events per second. Additionally, the noise looks the same for any runs afterwards.

The laser sweeping was present during all three recordings. The behavior appears to depend on whether the camera was physically replugged before the python recording process. The only reliable solution I found was a physical unplug/replug to restore the expected first-run behavior, but that is not ideal.

The main questions I have are
1. Is there a recommended shutdown or cleanup sequence for Python camera objects before process exit? In my own scripts, I have tried either deleting the python object and garbage collecting it or just letting the python script end but those solutions did not work.
2.  Is there a supported way to reset or reinitialize the camera stream from python without physically unplugging/replugging?
3.  Is there a known issue where repeated Python opens after a previous recording can leave a camera in a bad acquisition state?

Additional environment infomation:
Camera: DVXplorer_DXB00170 / DVXplorer Lite
USB ID: 152a:8419
Resolution: 320x240
dv-processing: 2.0.3
Python: 3.14.4
OS: Fedora 43
Kernel: 7.0.8-100.fc43.x86_64

Thank you for your time. Let me know if there is any other information/data that would help in solving this issue.

[Luca Longinotti]

Hello, thanks for the detailed report.

To answer your questions:

1) You've already identified it. Normally closing the script (not CTRL+C or kill), or deleting the camera object, are the good ways to close a device.

2) Same as 1, this is supposed to work properly already in exactly that way.

3) No such bug is known at the time, but that doesn't mean it doesn't exist. :-)

Can you reproduce the same behavior using our DV software? Basically stopping/starting the capture module is equivalent to creating/deleting the camera object in Python, so should show the same behavior.

-- 

Luca Longinotti (llongi)

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

[Aryan Thakur]

Hello Luca,
This was a headless linux instance but I was able to install a desktop environment to install DV-gui to specifically use the DV software. I was able to reproduce this behavior. I attached the images here.
Same procedure, unplug replug camera, capture. stop capture. start it again, I did see the print outs of the GUI in both the terminal and output box. I attached all images here in order of me doing them.




Also running I was using the version dv-gui-1.7.1-0.fc43.x86_64 

Thank you for your time!
Aryan Thakur

[Aryan Thakur]

Another update, I tried running this procedure on a Windows computer with 1.7.1 dv-gui version with an entirely different DVXplorer-Lite camera and got the same error state. Oddly enough, the imu was working but the camera stream had same issue on linux.