Applications, development tools, FPGA, C, WEB
#7730 by andreasb
Fri Jul 14, 2017 11:48 am
Hi,
I've ordered four red pitayas (2x the 10 board and 2x the 14 board), but they'll only arrive on Monday so I haven't been able to play with them yet, but I've been reading a bit on this forum and the documentation. I have a couple of questions:
Is it possible to combine 2 boards to make one board with 4 inputs? Do I understand it correctly that the data acquisition is limited to 8s?

Basically, I have 3 square wave signals that I want to measure using the same time base. I have a TTL signal that gives me the frames from my camera, and two position encoder signals which I need to know which position of my setup corresponds to which camera frame. For the 3 signals problem, I guess I could measure the camera signal on 2 boards simultaneously and combine the data afterwards, but it's a bit messy...
The next problem is that I need to record for 43s which, as I understand, is too long. Technically, I only need a "high" or "low" value on each input, so is it possible to use the ADC's at less than the 10/14 bit and record a longer time instead? (or to use the digital pins instead?)
I'm sorry if these are very basic questions, but I don't have the boards yet and I need to get my setup working as soon as possible when I get them.
Thanks, Andreas
#7763 by amike88
Fri Jul 21, 2017 2:07 pm
I'd recommend checking koheron site for synchronisation of a cluster of Red Pitayas.

Data buffers are limited to 16ks for each channel how this relates to time is dependent on the decimation settings. You can take a look at this table for more details.
#7840 by andreasb
Tue Aug 08, 2017 9:42 am
Hi,
thanks for the answer. I had a quick look and I will definitely try it. As I didn't get the setup to work in time i used an old scope that we had lying around. However, I really want to get it to work with the pitaya now.

My most pressing goal is to get around the 16k frame problem (even my crappy scope can save 4M frames...) So I've looked at Pavel's ram writer to have the FPGA write directly to ram.
https://github.com/pavel-demin/red-pita ... riter_v1_0
I have never programmed an FPGA before, so I have no idea what I'm doing. After running a couple of successful test projects (the LED blink thing and one other) I tried to run the ram writer and got a lot of errors. I finally ended up with the following tcl file which runs the ram writer core_config.tcl without errors:
Code: Select allset core_name axis_ram_writer_v1_0

set part_name xc7z010clg400-1

set elements [split $core_name _]
set project_name [join [lrange $elements 0 end-2] _]
set version [string trimleft [join [lrange $elements end-1 end] .] v]

file delete -force tmp/cores tmp/cores/$core_name tmp/cores/$project_name.cache tmp/cores/$project_name.hw tmp/cores/$project_name.xpr tmp/cores/$project_name.sim

create_project -part $part_name $project_name tmp/cores

add_files -norecurse [glob cores/$core_name/*.v]

ipx::package_project -import_files -root_dir tmp/cores/$core_name

set core [ipx::current_core]

set_property VERSION $version $core
set_property NAME $project_name $core
set_property LIBRARY {user} $core
set_property SUPPORTED_FAMILIES {zynq Production} $core

proc core_parameter {name display_name description} {
  set core [ipx::current_core]

  set parameter [ipx::get_user_parameters $name -of_objects $core]
  set_property DISPLAY_NAME $display_name $parameter
  set_property DESCRIPTION $description $parameter

  set parameter [ipgui::get_guiparamspec -name $name -component $core]
  set_property DISPLAY_NAME $display_name $parameter
  set_property TOOLTIP $description $parameter
}

source cores/$core_name/core_config.tcl

rename core_parameter {}

ipx::create_xgui_files $core
ipx::update_checksums $core
ipx::save_core $core

#close_project

Unfortunately, I now get errors when running the implementation:
Code: Select all[Place 30-415] IO Placement failed due to overutilization. This design contains 255 I/O ports
 while the target  device: 7z010 package: clg400, contains only 230 available user I/O. The target device has 230 usable I/O pins of which 0 are already occupied by user-locked I/Os.
 To rectify this issue:
 1. Ensure you are targeting the correct device and package.  Select a larger device or different package if necessary.
 2. Check the top-level ports of the design to ensure the correct number of ports are specified.
 3. Consider design changes to reduce the number of I/Os necessary.


and about a hundred like this
Code: Select all[Place 30-68] Instance aclk_IBUF_BUFG_inst (BUFG) is not placed

Then this:
Code: Select all[Place 30-99] Placer failed with error: 'IO Clock Placer failed'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.


The first error suggests that the part name is incorrect, right? No idea what the others are trying to tell me...

I'd be very thankful for some pointers.
Cheers, Andreas
#7843 by JohnnyMalaria
Tue Aug 08, 2017 4:08 pm
Hi,

I can't advise you re the FPGA. I have the same issue - crappy sized buffer and capturing at a low rate (decim 8192 or 65536 in my case).

Here's a thought:

1. Is your TTL pulse the first thing that happens? i.e., your encoder info etc always occur after?
2. What is the width of the shortest pulse?
3. What time resolution do you need?
4. How frequently do your TTL pulses fire?

Let's say the answer to 4 is every 0.5s, the total time required to cover all the pulses (i.e, the TTL trigger and encoder pulses) is 0.1s, and the minimum pulse width is 0.01s. At the start of each TTL pulse, you could capture one full buffer with a decimation of 1024 to give 0.13s of data. This would give you plenty of headroom to capture the full amount of data for each sequence of pulses.

To trigger acquisition, simply connect your TTL output to DIO0_P on each RP.

FYI, I am working on SCPI/Python code to capture parts of a buffer *during* acquisition with the goal of getting continuous capture at high decimation values and allow my to do near real-time analysis of the data. Of course, I have hit a few brick walls due to the poor RP documentation. But it's getting there. Eventually, once my instrument is beyond proof-of-concept stage then I'll want to program the FPGA to do as much of the work as possible.

John.

(To the RP team: please provide a fully-fledged, functional SD image and VirtualBox image to make FPGA development for the RP realistic. Right now, it is ridiculously complicated, poorly documented and something of a crapshoot.)
#7849 by jmoederl
Thu Aug 10, 2017 7:51 am
Hi.
you don't have to programm the FPGA if you use a precompiled image like ddrdump.bit image here: https://github.com/RedPitaya/RedPitaya/tree/master/Test/rp_remote_acquire. this program writes data directly into the ram and then transfers it via UDP to a server. if you cut out the UDP part you should get exactly what you are lookig for without having to write a single line of VHDL code.
Additionally, with a bit of tinkering in the Linux Device Tree you can reserve even more memmory for your buffer as ther is in this example. let me know if you are intersted in that.

but on second thought, if you just want to capture logic pegels, why not use the digital input pins directly? it should be not problem writing a program that just polls the pins constantly and writes the values in a file.
#7851 by andreasb
Fri Aug 11, 2017 5:01 pm
Hi guys,

Thanks a lot for the answers!
To John's questions:
The signals are more or less independent: the encoders are just running all the time and count the steps of a constantly rotating device (a polariser). The camera outputs a TTL signal when the frame is being exposed (so ~10ms high, 0.1ms low for a couple thousand frames). The shortest encoder pulse is a bit less than 10 microseconds. I'm looking for a time resolution of about 1 microsecond over a period of 50s. The encoder TTL fires rougly every 50 microseconds.

To Jakob, thanks a lot for the pointer. I tried it on both my 10bit and 14bit Red Pitaya. Unfortunately, I don't seem to be able to read the output file. I used a binary viewer to look at it, and the file from the 14bit was basically just ones, so that can't be right. The file from the 10 bit was more promising, but I tried parsing it as all different kind of integers, but none of it made sense. I can't seem to attach the file, so here's the dropbox link:
https://www.dropbox.com/s/mszjg886hgus6z5/out?dl=0
It should be a triangular wave at 10kHz from a function generator. I made the file with the command
./rp_remote_acquire -m 3 -d 64
Any suggestions would be helpful. Oh, and I tried the other python test scripts that read the 16k buffer, they all worked fine.

Thanks! Andreas

Who is online

Users browsing this forum: Bing [Bot] and 5 guests