jAER discussions moved to Google Groups

Luca Longinotti — Tue, 05 Sep 2017 11:00:34 -0000

After moving all our code to GitHub, it became necessary to find a good replacement for the SourceForge discussion forums. To also support easy e-mail announcements, as well as a good mailing-list and web-interface integration, we decided to use Google Groups.
The following new groups are available:

https://groups.google.com/d/forum/jaer-users
https://groups.google.com/d/forum/caer-users
https://groups.google.com/d/forum/davis-users
https://groups.google.com/d/forum/dynapse-users

This covers all of our software, as well as hardware.
Announcements will be cross-posted as needed.
Subscription is open to everyone.
We encourage you to subscribe to all lists that apply to you!

activating camera directly by FPGA

Luca Longinotti — Fri, 01 Sep 2017 16:12:00 -0000

I don't have any experience in implementing UART at such a low level, usually any kind of microcontroller or OS has libraries for that, and for FPGAs you have modules by the vendor or talk to some external chip over a parallel bus.
Xilinx for example has IP cores to do this:
https://www.xilinx.com/products/intellectual-property/1-4c5ro4.html
According to https://en.wikipedia.org/wiki/RS-232#RTS.2C_CTS.2C_and_RTR the meaning of RTS/CTS changes depending on half or full-duplex communication, modern devices should be full-duplex.
So maybe you're not telling the eDVS you're ready to receive. You should only send commands when CTS is asserted (driven by eDVS), and then after sending 'E+' assert RTS (driven by your FPGA) to indicate you can receive data.
What you're seeing on your PC is probably because of this, if no application is asking the kernel to get data from the serial bus, it just doesn't set RTS to indicate it can receive data. Look at all four lines with a logic analyzer to confirm this.

activating camera directly by FPGA

chenster — Fri, 01 Sep 2017 14:15:50 -0000

Thanks for your replay, Luca. Probably I misundertand the control pins. I thought RTS (require to send, low active) is a output signal of camera and CTS(clear to send. low active) is a input signal for camera. So I just float the RTS and pull down the CTS, which tells camera the FPGA is always ready to receive data.

Today I have also found something intresting. Because the communication between PC and camera is fine, so I test the pin voltage of UART. After setting the baudrate, I use

echo 'E+' > /dev/ttyUSB0
cat /dev/ttyUSB0

these 2 commands to receive data. The intresting point is that after the first command, camera doesn't send data immediately (TXD is high). Only when executing the 'cat' command, there comes the data, which looks as if 'E+' makes camera into "ready to send" state and 'cat' is the real sending command. Do you have any idea or interpretation about this?

Schönes Wochenende!

activating camera directly by FPGA

Luca Longinotti — Fri, 01 Sep 2017 13:40:55 -0000

Hello, indeed if sending commands works, then also the command to enable events should have worked. And it probably did. UART0 is a slave port, so it will start trying to send bytes right away, and you need to read the data and do the flow-control yourself. So you wouldn't control CTS, the eDVS does that when it's ready to receive data (commands in your case), and you'd assert RTS to signal you are ready to get the data.
I hope this helps, have a nice week-end!

activating camera directly by FPGA

chenster — Thu, 31 Aug 2017 14:38:02 -0000

Hello,

my task is to connect the DVS camera with a FPGA and let the FPGA activate the camera and then receive the streaming data from the camera. As the first step I've established the communication between camera and a linux PC. Everything is fine.

For the FPGA test, I use a 5V power source to provide the power for camera and use the UART0 interface to connect with my FPGA. The problem I met is when the FPGA sends the activation command "E+\n" via RXD to the camera. There is no response on TXD. Its voltage level is always high (an digital oscilloscope is available). I set RTS/CTSto low.

I must notice that I've also tried the command "!L[012]" to turn on/off the LED on camera board. It works, so I think the problem is not at my incoming command. According to the user guide of eDVS, there should be no difference of command for activating camera via USB with PC or via UART with peripheral hardware.

I use eDVS4337.
Any help or suggestion would be appreciated.

Chen

Davis 240C Producing Biased Events

Federico Corradi — Tue, 29 Aug 2017 13:12:13 -0000

Hi Timo,

yes the pixel biases are acting on the transistors of the pixel circuits.
To have a better understanding please have a look at this paper: http://ieeexplore.ieee.org/abstract/document/4444573/
The name are also preserved On, Off , Threshold etc..

is this what you were asking for?

Davis 240C Producing Biased Events

Timo S — Fri, 25 Aug 2017 05:03:34 -0000

Hi Federico,

Yeah, that has solved it, thank you! I'm trying to work out what this slider actually changes on the camera, can you help me out with this at all?

Davis 240C Producing Biased Events

Federico Corradi — Thu, 24 Aug 2017 08:13:09 -0000

Hi Timo,

sorry for my late reply (I was on hoidays). The amount of positive vs negative events can be easily controlled by changing the ON (OnBn) and OFF (OffBn) thresholds. Have a look at our bias setting user guide, at this link: https://inilabs.com/support/hardware/biasing/

In addition, if you want to observe fast movements I suggest you use the bias settings that you can find here: https://github.com/SensorsINI/jaer/blob/master/biasgenSettings/Davis240bc/C-fast.xml

Let me know if the user guide and my suggestion will solve your issue.

with best regards,
Federico

Using the DAVIS240C without the CPLD

Luca Longinotti — Mon, 14 Aug 2017 16:25:26 -0000

Pasting answers from me from a private e-mail discussion where we solved this:

If you indeed want to work only via the connectors and do the
biasing yourself, there is no official documentation concerning this,
as we do not support this mode of operation currently. The
documentation you can find is the code, look at the firmware that does
biasing and figure out how to replicate that in your system:
https://github.com/inilabs/devices/blob/master/firmware/CypressFX2/SeeBetterLogic_DAVIS/main.c
BiasWrite() and ChipDiagnosticChainWrite(), or you can also look at the
VHDL logic that we use on newer devices where we do this from our FPGA:
https://github.com/inilabs/devices/blob/master/logic/SystemLogic2/common-source/chipdefs/davis240/DAVIS240StateMachine.vhd
We only support control/biasing via USB officially at this moment, so
require our CPLD and its code to be there. If you just want to use the
top-board without anything else, you'll need to write the code yourself
for biasing, APS control+reading, DVS reading, and IMU if you want to
use that chip too. At the above link for the VHDL logic you'll be able
to find all of the state machines that do this, but you'll need to
understand and adapt what you want to your system on your own.

biasEnable turns on the bias generator which provides power to
the chip, you could also call it chipEnable. It must always be high for
the chip to work.
biasDiagSel is used to select whether a bias is being sent in (8 bit
address plus 16 bit value) or the chip configuration chain (56 bits). To
get the chip in a good, known state, both have to be sent to it at
startup. See ChipDiagnosticChainWrite() in the firmware code or
ChipConfigReg_D in the VHDL, and look at libcaer for what the bit values
mean.
Also the AER interface has an active-low reset signal, which has to be
disabled for DVS event to come. Ensure you do this.

BinauralCochleaEvent class variables meaning

Leslie S Smith — Mon, 14 Aug 2017 15:07:15 -0000

Many thanks for that: I'd had some problems creating the doc info under Eclipse (managed now). Have found detailed info on extracted events: still 1 question (but considering the volume of documentation, I may simply have missed it). Inside the depressing synapse event filter (DepressingSynapseFilter, net.sf.jaer.eventprocessinhfilter.DepressingSynapseFilter.java), type and y are between 8 and 15 (and not 16 as I wrote above). I now understand that for this sort of event, type = y, I take it that they have been unpackaged from a tight representation that the events come in as. I had thought this used getYFromAddress in ConcleaAMS1c.Extractor, but all the values I actually see are between 8 and 15. I'm definately feeling my self a newbie on this code...

Recent posts to Discussion

jAER discussions moved to Google Groups

activating camera directly by FPGA

activating camera directly by FPGA

activating camera directly by FPGA

activating camera directly by FPGA

Davis 240C Producing Biased Events

Davis 240C Producing Biased Events

Davis 240C Producing Biased Events

Using the DAVIS240C without the CPLD

BinauralCochleaEvent class variables meaning