Bug in evt3 files?

[agirbau]

Hello,

(thank you so much for the great work and the repository!)

I have two types of data, evt2 and evt3 .raw files. Evt2 files work fine (I can read the events and everything), but I'm seeing some problems when reading more than X chunks of events from evt3 files.

I'm using evs = next(wizard.read_chunk()). It properly reads the events up to a point, where it returns an "ERROR: event type not recognised: 0x7". (The files I'm testing are quite big, so I can't upload them.)

I have tried with the test file provided in the repo tests/sample-files/evt3_sample.raw, but it seems that it is not complete (only 36Kb)?

Could you point out to some other test file so I can check again?

Thank you so much!

[fabrizio-ottati]

Hi! Thank you for trying out the library :) In practice, in evt3.c I check that the provided event types are correct according to Prophesee specifications. The event 0x7 is a vendor specific event, called CONTINUED_4. Hence, it should recognize the events. Are you using the version from pip? If yes, could you try to clone develop on your machine and install that with pip install path/to/develop/?

Other EVT3 recordings can be found here.

[fabrizio-ottati]

AH! You are right. I found a bug in evt3.c: I did not include EVT3_CONTINUED_4 in the switch(). Now it should work if you clone the latest version of develop. Thank you very much!

[agirbau]

Thanks! Yes, I'm using the pip installation. I will try the dev branch as soon as I can and comment on the issue.

[fabrizio-ottati]

It would be nice to know what they mean by CONTINUED_4, since Prophesee says that is a vendor specific event and does not provide information about it in the documentation.

@biphasic once this bug is fixed, should we merge develop with main even if the benchmarking is not ready yet? The read_time_window() and save() functionalities are tested and available for all encodings now.

[lbristiel-psee]

Hi all,

CONTINUED_4 are used along CONTINUED_12 and OTHERS. From the EVT3 doc: "The Others Event is used to extend the number of available event types in a system based on a subtype field. The subtype field is then used to decode the event information accordingly. A single OTHERS event word can be used for marker events that contain no additional fields. If additional fields need to be transmitted, they will be sent in a subsequent CONTINUED event."

Those OTHERS events can carry other data types from the sensor, like information about the behaviour of one of our digital block in the ESP (ERC, anti-flicker etc.). In the current version of the SDK/OpenEB, those events are not decoded/leveraged. They will be decoded in the next version of SDK/OpenEB.

Finally, note that those OTHERS events are documented more in details for sensor's customers who get information in the datasheet they receive.

[fabrizio-ottati]

Thank you @lbristiel-psee! Right now I am ignoring them in the code since I did not have this information. I will take a look at the datasheets to understand how to handle them in a better way. Thank you very much, it is great to get feedback from Prophesee :)

[biphasic]

@fabhertz95 yes I think any bugfix should be released asap. @lbristiel-psee thanks for info

[agirbau]

As a final comment to this issue, I tried with the develop branch and it worked perfectly 👍

[fabrizio-ottati]

Really nice :) Now the latest features should be available on pipy and in the documentation https://expelliarmus.readthedocs.io