I'm confused about the length of the timestamp between 4 and 2 bytes.
I have read the thesis "Highspeed USB2.0 AER Interfaces" and the paper "A 5 Meps $100 USB2.0 Address-Event Monitor-Sequencer Interface" by Raphael Berner; and I have understood that the sensor send to the PC 16 bits = 2 bytes. With a tick of 1us should restart in about 65 miliseconds.
However in jAER the timestamp is type int = 32 bits = 4 bytes. With a tick of 1us should restart in about 71 minutes.
Thanks and Regards
Armando
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The timestamp sent by hardware is 4 bytes but in the Java HardwareInterface translateEvents method is is expanded to a 32- bit address and 32-bit timestamp. See for instance line 170 of
Tobi made a typo here:
it is not the timestamp that has 4 bytes coming from the hardware, it is the event: 2 bytes of address and 2 bytes of timestamp. the hardware also sends special events when the local 2 byte (actually only 14 bits) overflows. this is used to create 4 byte timestamps on the host computer.
rapha
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked the RetinaAEReader class that Tobi recommended me.
It's a complicated class because it use a binary level and I don't know the rules of the sensor communication (bit order …).
I have debugged the class, I obtained the next data:
byte aeBuffer = b.BufferMem; //Is like a byte array of the data read in the USB port.
After, one loop take segments of 4 bytes of aeBuffer, for example when the initial position is 8, take the bytes 8, 9, 10 and 11.
I observe, in this example, that only the input bytes are classified in input events.
One variable, named wrapAdd, could change the timestamp value, with some rules in the if-else instruction.
I still don't understand what is the function of wrapAdd.
I would like to know if the timestamps in the computer have 4 bytes, and in the receive process we add more bytes to the timestamp when the camera timestamp overflows.
Equally, I would like to know the bit order in an event sent by the camera, for a FPGA application of another student.
Regards…
Armando
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
//addressisLSBMSBaddresses[eventCounter] =(int)((aeBuffer[i] &0xFF)|((aeBuffer[i+1] &0xFF)<<8));//samefortimestamp, LSBMSBshortts=(aeBuffer[i+2] &0xff|((aeBuffer[i+3] &0xff)<<8)); // this is 15 bit value of timestamp in TICK_US ticktimestamps[eventCounter] =(int)(TICK_US*(shortts+wrapAdd)); //*TICK_US; //add in the wrap offset and convert to 1us tick
The wrapAdd is used to compute the true 32-bit timestamp from the short (16-bit) timestamp. Every time the 14-bit timestamp counter wraps around on the CPLD it send a wrap event. This increments the wrap counter.
I hope this helps.
Tobi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) The camera send 4 bytes per event through USB to the PC.
2) The first 2 bytes are the addresses and the last 2 bytes are the camera timestamp.
3) The fourth byte is the MSB and the third byte is the LSB of the camera timestamp.
4) The camera timestamp only use 14 bits, the bits and are control bits.
5) The bit of the camera timestamp means, when is 1, the overflow of the camera timestamp, and it origin that the computer add 0x4000 to the computer timestamp (add 1 to the bit ).
Am I correct?
_________________________________________________
I still have the next questions:
A) Where are x, y and the polarity sign in the 2 bytes addresses? (bits location)
B) Is one bit of the address unused?
C) What is the function of the bit of the timestamp?
D) When the bits or have the value 1, this packet doesn't have important information in addresses? (we should pass to the byte i+4)
Thanks and Regards…
Armando
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A. Bits of address are decoded in the DVS128.EventExtractor. But it is bit0=polarity, bits 7:1 are X address, and bits 14:8 are Y address. Bit 15 is unused except for special "sync" events that are sent by the camera on external input pin rising edges.
C. Yes, bit 15 is unused except for sync addresses, and for the left/right eye in stereo pair configurations.
D. Yes, 14 or 15 bits set for timestamp bytes then for now at least rest of address bits are not used. That could change in the future if we decide to send more information with wrap event or timestamp reset event.
By the way, the timestamp reset event is sent by a camera if its timestamp is reset by the master camera. Then the usb thread that listens to the camera that has been reset knows to reset its wrap counter.
Regards
Tobi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I'm confused about the length of the timestamp between 4 and 2 bytes.
I have read the thesis "Highspeed USB2.0 AER Interfaces" and the paper "A 5 Meps $100 USB2.0 Address-Event Monitor-Sequencer Interface" by Raphael Berner; and I have understood that the sensor send to the PC 16 bits = 2 bytes. With a tick of 1us should restart in about 65 miliseconds.
However in jAER the timestamp is type int = 32 bits = 4 bytes. With a tick of 1us should restart in about 71 minutes.
Thanks and Regards
Armando
Armando -
The timestamp sent by hardware is 4 bytes but in the Java HardwareInterface translateEvents method is is expanded to a 32- bit address and 32-bit timestamp. See for instance line 170 of
http://jaer.svn.sourceforge.net/viewvc/jaer/trunk/host/java/src/net/sf/jaer/hardwareinterface/usb/cypressfx2/CypressFX2DVS128HardwareInterface.java?revision=3719&view=markup
This is the translateEvents method that unwraps the timestamps using wrap events and detects timestamp reset events.
Hope this helps.
Tobi
Tobi made a typo here:
it is not the timestamp that has 4 bytes coming from the hardware, it is the event: 2 bytes of address and 2 bytes of timestamp. the hardware also sends special events when the local 2 byte (actually only 14 bits) overflows. this is used to create 4 byte timestamps on the host computer.
rapha
Hi Tobi and Rapha
Thanks for answering
I have checked the RetinaAEReader class that Tobi recommended me.
It's a complicated class because it use a binary level and I don't know the rules of the sensor communication (bit order …).
I have debugged the class, I obtained the next data:
byte aeBuffer = b.BufferMem; //Is like a byte array of the data read in the USB port.
After, one loop take segments of 4 bytes of aeBuffer, for example when the initial position is 8, take the bytes 8, 9, 10 and 11.
In the debugged example these are the values:
aeBuffer = 114 = 0111 0010 = 72h
aeBuffer = 46 = 0010 1110 = 2Eh
aeBuffer = -72 = 1011 1000 = B8h
aeBuffer = 23 = 0001 0111 = 17h
Next, some if-else instructions are executed and the result is the next:
timestamps = 6072 = 0001 0111 1011 1000 = 17B8h = aeBuffer (concatenated with) aeBuffer
addresses = 11890 = 0010 1110 0111 0010 = 2E72h = aeBuffer (concatenated with) aeBuffer
I observe, in this example, that only the input bytes are classified in input events.
One variable, named wrapAdd, could change the timestamp value, with some rules in the if-else instruction.
I still don't understand what is the function of wrapAdd.
I would like to know if the timestamps in the computer have 4 bytes, and in the receive process we add more bytes to the timestamp when the camera timestamp overflows.
Equally, I would like to know the bit order in an event sent by the camera, for a FPGA application of another student.
Regards…
Armando
I'm not sure why it seems so complicated Armando:
The wrapAdd is used to compute the true 32-bit timestamp from the short (16-bit) timestamp. Every time the 14-bit timestamp counter wraps around on the CPLD it send a wrap event. This increments the wrap counter.
I hope this helps.
Tobi
Hi
Summarizing that I have understood:
1) The camera send 4 bytes per event through USB to the PC.
2) The first 2 bytes are the addresses and the last 2 bytes are the camera timestamp.
3) The fourth byte is the MSB and the third byte is the LSB of the camera timestamp.
4) The camera timestamp only use 14 bits, the bits and are control bits.
5) The bit of the camera timestamp means, when is 1, the overflow of the camera timestamp, and it origin that the computer add 0x4000 to the computer timestamp (add 1 to the bit ).
Am I correct?
_________________________________________________
I still have the next questions:
A) Where are x, y and the polarity sign in the 2 bytes addresses? (bits location)
B) Is one bit of the address unused?
C) What is the function of the bit of the timestamp?
D) When the bits or have the value 1, this packet doesn't have important information in addresses? (we should pass to the byte i+4)
Thanks and Regards…
Armando
Yes, you are correct Armando in your 1-5.
A. Bits of address are decoded in the DVS128.EventExtractor. But it is bit0=polarity, bits 7:1 are X address, and bits 14:8 are Y address. Bit 15 is unused except for special "sync" events that are sent by the camera on external input pin rising edges.
C. Yes, bit 15 is unused except for sync addresses, and for the left/right eye in stereo pair configurations.
D. Yes, 14 or 15 bits set for timestamp bytes then for now at least rest of address bits are not used. That could change in the future if we decide to send more information with wrap event or timestamp reset event.
By the way, the timestamp reset event is sent by a camera if its timestamp is reset by the master camera. Then the usb thread that listens to the camera that has been reset knows to reset its wrap counter.
Regards
Tobi
Hi Tobi
Thanks for your answers.
Regards…
Armando