Can DAVIS346 AER pin change 3.3V to 1.8V?

[범준석]

Hello, I am the student at Chungbuk national university.

and I wonder that DAVIS346 AER pin change 3.3V to 1.8V.

In this picture, DAVIS346 AER's sensor supply voltage is 3.3V and 1.8V.

thank you.

[Luca Longinotti]

Hello, as per documentation:

https://docs.inivation.com/hardware/current-products/davis346-aer.html#aer-connector

all exposed pins are 3.3V.

They cannot be changed to 1.8V, the 1.8V supply is only used internally to the sensor, not for its I/O pins.

Hope this helps, have a nice day!

-- 

Luca Longinotti (llongi)

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

[범준석]

Thank you, your answer was helpful.

I have an additional question.
 
1. is it correct to enable when REQ signal goes from High -> Low state?

2. why is Y only event a defect? Is it unavailable data?

3. Is it correct to receive X signal when XSEL signal is 1?
If correct, why is there a glitch where XSEL is continuously high?

Is that Y only event glitch?

I will attach a picture.
Looking forward to your answers.

Have a nice day and thank you.

2024년 12월 17일 화요일 오전 9시 2분 5초 UTC+9에 Luca Longinotti님이 작성:

[범준석]

Here is picture.

Thank you.

2024년 12월 18일 수요일 오후 7시 1분 8초 UTC+9에 범준석님이 작성:

[Luca Longinotti]

1. Yes, REQ 1->0 transition is the start of the handshake.

2. The protocol is one Y address, followed by one or more X addresses, then again one Y address, and so on.

There is a glitch in the sensors that can output two Y addresses consecutively, without one or more X in between.

That is unusable because to have an event, you need both the Y and X component, especially since the X address contains the polarity in its last bit.

3. XSel=1 is the case for X addresses, yes. What you're seeing is not a glitch but the intended way for the protocol to work. If there are multiple consecutive X addresses, which is often the case, it just stays high.

Take a look at the VHDL example state machine, it may help.

[범준석]

Hello,
Hope you're having a great Christmas.

I would like to know what happens to REQ and XSEL when a glitch occurs.

Q1. What are the consecutive REQ and XSEL status values when a glitch occurs (i.e., row-only event)?

I need to discard the first event address and replace it with the second event address during glitch cases. I would like to know the REQ and XSEL status during glitch events. If there are other indicators of glitch events, please let me know.

Q2. Additionally, I want to verify my understanding of glitches: The polarity information is transferred with the X address, so if there is a row-only event, I must discard the first event since it contains no polarity information. Is this correct?

Q3. Furthermore, if I were to discard the second event instead of the first event, would this cause any issues with image processing?

Thank you,
Have a nice day!

2024년 12월 19일 목요일 오전 12시 27분 44초 UTC+9에 Luca Longinotti님이 작성:

[Luca Longinotti]

It is a serial protocol, so you get one Y address followed by one or more X addresses with polarity.

So, in normal operation, you get something like:

Y=100, X=200/Pol=1, X=300/Pol=0, X=400/Pol=0

which you then decode into the full events (x,y,polarity):

(200,100,1), (300,100,0), (400,100,0)

Sometimes you get two Y addresses consecutively, with no X in between, so you just discard the first one.

Basically an event is realized when you get the X/Pol information, at which point you just look at the last Y address you received to complete the (x,y,pol) triplet.

The example code handles this:

https://docs.inivation.com/hardware/current-products/davis346-aer.html#fpga-receiver-state-machine

To answer your questions in detail:

1) REQ behaves normally as with any other transaction, XSEL will be 0 to represent an Y address. Row-only glitches are protocol glitches, not electrical ones, so the signals all behave normally and you do a normal handshake giving you a normal value. It's simply an invalid value that you discard.

2) Correct.

3) That would be wrong as you then complete your (x,y,pol) event triplet with the wrong Y address and that would represent an event in a position where nothing happened.

[범준석]

Thank you, Luca!
Your answer is so helpful.

To start designing the chip, I have one question.

To pass the ACK signal to the camera, you need an I/O modeling or black box for the ACK pin.
Do you have any of these that you can provide me?

Thank you.

Sincerly,
JunSeok, Beom

2025년 1월 7일 화요일 오전 7시 57분 54초 UTC+9에 Luca Longinotti님이 작성:

[범준석]

It means IBIS.

Thank you.

2025년 1월 9일 목요일 오후 4시 47분 46초 UTC+9에 범준석님이 작성:

[Luca Longinotti]

We do not have IBIS files for these older chips.

Just simulate it as a standard 3.3V GPIO, similar to Arduino, I don't think there is anything special going on.