measure 3 channels

Applications, development tools, FPGA, C, WEB
andreasb
Posts: 4
Joined: Fri Jul 14, 2017 11:06 am

measure 3 channels

Post 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

amike88
Posts: 89
Joined: Tue Mar 29, 2016 7:41 pm

Re: measure 3 channels

Post 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.

andreasb
Posts: 4
Joined: Fri Jul 14, 2017 11:06 am

Re: measure 3 channels

Post 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 all

set 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

JohnnyMalaria
Posts: 28
Joined: Fri Apr 28, 2017 12:43 am

Re: measure 3 channels

Post 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.)

jmoederl
Posts: 6
Joined: Wed May 03, 2017 5:05 pm

Re: measure 3 channels

Post 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/ ... te_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.

andreasb
Posts: 4
Joined: Fri Jul 14, 2017 11:06 am

Re: measure 3 channels

Post 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

jmoederl
Posts: 6
Joined: Wed May 03, 2017 5:05 pm

Re: measure 3 channels

Post by jmoederl » Thu Aug 17, 2017 10:14 am

Hi Andreas,

did you load the FPGA image before executing rp_remote_acquire?
you can do that either via the command line:

Code: Select all

cat ddrudmp.bit > /dev/xdevcfg
or i think with the -l option when executing rp_remote_acquire (i'm not 100% certain it's l though, could also be another letter):

Code: Select all

./rp_remote_acquire -m 3 -d 64 -l
since i just use this as base for my own code i can't really help you any further than this.

Jakob

andreasb
Posts: 4
Joined: Fri Jul 14, 2017 11:06 am

Re: measure 3 channels

Post by andreasb » Mon Aug 21, 2017 11:26 am

Wow, this is really embarrassing :oops:
I assumed that the c code automatically loads the bit file, don't know why I didn't think of that...
Anyway, it seems to works perfectly now, at least I got a perfect read of the function generator signal.
I think I won't bother trying to combine 2 rp's for now,but is there, by any chance, a way to have the code trigger acquisition on a leading edge?

Cheers, and thank you very much for the pointer!!
Andreas

JohnnyMalaria
Posts: 28
Joined: Fri Apr 28, 2017 12:43 am

Re: measure 3 channels

Post by JohnnyMalaria » Tue Aug 22, 2017 2:51 am

Try this - I use this to use software to trigger function generation and capture on two RPs at the same time. I assume this is what you are trying to do.

Connect one of the DIO pins to the trigger pin. e.g., DIO PIN 2_P to DIO PIN 0_P and set the first pin's direction to out. In your software, simply raise the pin's level from low to high. This will trigger acquisition (if you use EXT PE triggering).

To connect two RPs and trigger both at the same time, connect the pin on the first RP to the trigger pins on both and connect the digital grounds. I chopped up the LCR probe cable that came with one of the RPs and made my own jumper wire.

Works like a charm :)

tknopp
Posts: 26
Joined: Thu Feb 09, 2017 1:13 pm

Re: measure 3 channels

Post by tknopp » Wed Aug 23, 2017 5:22 pm

@JohnnyMalaria yes, but @andreasb wants to do this with rp_remote_acquire which cannot handle triggers, correct?

I also use a trigger to synchronize two rp with the same approach you outlined. However, the clocks are not synchronizes making this useless for me. Although the rp has an external clock input, I have not found any description how to get the clock out of one RP (without FPGA knowledge). I would be so thankful if there would be a solution to this problem.

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 16 guests