New feature: high speed continuous recording

Discussions about active development projects
Post Reply
fisafisa
Posts: 29
Joined: Fri Jun 06, 2014 6:02 pm

Re: New feature: high speed continuous recording

Post by fisafisa » Fri Mar 20, 2015 12:20 am

hi
what would be more convenient?

If I am thinking big, I imagine N rpi all synchronised and acquiring 2xN streams of data
A big switch will then aggregate all this into a 10Gb link.

For this to be useful, we need to have common acquisition clock. Is that possible?
Then we need to mark the time so that to align all the streams among each other and with other potential sources.
For that 2 mechanisms can be used.
1) an external trigger
2) a loose network based sync mechanism (PTP or IEE1588)

The first allows setting to 0 a counter in all cards so that one can time stamp the data acquired with that counter
The second allows continuosly and progressively aligning an internal clock source with an external master, a reference clock.

I prefer the first as it is simple to implement and I have used it in my last project with no issue.
The second is more popular now but it is more complex.

I would propose the first. For that you need to implement a counter in the FPGA which counts up the daq clock.
An external pin is used to reset the counter and thus establish the time=0.
For this method one also needs to sync the daq clock with an external reference clock or use an external reference clock.
Can this be done?

Ciao
Filippo

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Sat Mar 21, 2015 4:14 pm

Hi Filippo,
fisafisa wrote:For this to be useful, we need to have common acquisition clock. Is that possible?
The ADC can be driven by an external clock, but it is neccessary to resolder two resistors on the Red Pitaya in order to do so (see here). I have no experience with clock distribution over larger distances in the 100MHz range, but I suspect signal integrety and delay will have to be considered carefully.
I would propose the first. For that you need to implement a counter in the FPGA which counts up the daq clock.
An external pin is used to reset the counter and thus establish the time=0.
For this method one also needs to sync the daq clock with an external reference clock or use an external reference clock.
Can this be done?
The same clock that clocks the ADC is used for all (FPGA-) internal processing on the signal path, too. So a counter that runs synchronuously with the acquisition and can be reset by an external input is entirely possible. I would also prefer this solution for timestamping, it is easily implemented and requires negligible additional processing.

Aragorn2101
Posts: 7
Joined: Sun Mar 22, 2015 10:54 am

Re: New feature: high speed continuous recording

Post by Aragorn2101 » Sun Mar 22, 2015 11:11 am

Hello Nils,

Thank you very much. Nice work. :D

I would like to make a small request, I hope it will be possible. At the University of Mauritius the Department of Physics is building a radio telescope and we are planning to set up a low-cost data acquisition. We are considering the use of Red Pitaya as an ADC. I must say your work comes at the right time. The problem is our signal bandwidth is 10 MHz and in order to do proper digital processing we need to sample at a rate higher than 20 Msps.

So, I would like to ask if it is possible to obtain a decimation of 4 so that we reach something around 30 Msps? Even if it is available only through UDP, I don't mind.

Another thing is that we only need a resolution of 8 bits for the samples. I am suspecting that for 30 Msps the network speed will not be sufficient. But if we could truncate the raw samples (take 14 bits down to 8 bits) before transferring over the network, there could be a chance. Is the operating system fast enough to perform this task and not affect the whole acquisition?

But I must say, the world of radio astronomy (both professional and amateur) ;) will be very fond of your work. If that 30 Msps is made possible, it will be a small revolution in low-cost ADC. 30 Msps is very often the standard considering our baseband filters and other electronics.

Thanks in advance.

fisafisa
Posts: 29
Joined: Fri Jun 06, 2014 6:02 pm

Re: New feature: high speed continuous recording

Post by fisafisa » Sun Mar 22, 2015 12:19 pm

how many channels?
How are they geographically distributed?
Do you need to synchronise with soem time reference?
ciao

pavel-demin
Posts: 33
Joined: Tue Dec 23, 2014 10:52 pm

Re: New feature: high speed continuous recording

Post by pavel-demin » Sun Mar 22, 2015 2:29 pm

Hi Aragorn2101,

Out of curiosity. What is the frequency range for this radio telescope? Is it all the 0-10Mhz range or just 3-5 Mhz around 10 MHz?

Cheers,

Pavel

Aragorn2101
Posts: 7
Joined: Sun Mar 22, 2015 10:54 am

Re: New feature: high speed continuous recording

Post by Aragorn2101 » Mon Mar 23, 2015 11:03 am

Hi,

The radio telescope is actually designed as an interferometer array with several groups of antennas. Basically, we have a number of antennas placed in a T shape configuration. A radio frequency signal comes from each antenna. The central frequency is 327 MHz (to observe the Deuterium line) with a bandwidth of 10 MHz. The front end is designed to do frequency down-conversion to a baseband of bandwidth 10 MHz. So respecting Nyquist sampling and allowing for some uncertainty in the filtering we wish to sample at around 30 Msps.

Let's say we could use an ADC with each antenna. So one channel per Red Pitaya is ok. Yes, we need to synchronize the Red Pitayas. I thought we could do that externally by triggering.

Cheers

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Mon Mar 23, 2015 11:29 am

That's a really interesting application. I suspect your T shape will have a size on the order of some kilometers, yes ? In that case, proper synchronisation will be a challenge.

On the matter of data rates, 30MSps on one channel with 8 bit resolution is well within reach of the existing solutions. Some small changes would be neccessary to reduce the sample size, then you'd be good to go.

Aragorn2101
Posts: 7
Joined: Sun Mar 22, 2015 10:54 am

Re: New feature: high speed continuous recording

Post by Aragorn2101 » Tue Mar 24, 2015 9:21 am

Hello,

Yes, we will be working hard to synchronize the Red Pitaya's.

Thanks a lot for your support Nils. I needed to know if it was a feasible thing to do. Looking forward to your App.

Cheers

noah
Posts: 33
Joined: Fri Jan 23, 2015 9:53 am
Location: Zurich

Re: New feature: high speed continuous recording

Post by noah » Fri Mar 27, 2015 2:01 pm

I'm following this thread a while now and been using the library to play around. It recently crashed so here's a bug report. 8-) I was using your binaries on a custom built kernel and buildroot. Makes it a bit difficult to spot the error but perhaps it helps developing.

Another question regarding the file transfer: What is the current progress on that? I'm going to test with netcat on a small gigabit network.

Cheers

Code: Select all

redpitaya> cat /dev/rpad0 >> dump.txt
------------[ cut here ]------------
Kernel BUG at c009deb8 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in: rpad(O)
CPU: 1    Tainted: G           O  (3.9.0-xilinx #1)
PC is at cache_alloc_refill+0x238/0x5c0
LR is at 0x3c0
pc : [<c009deb8>]    lr : [<000003c0>]    psr: a00d0093
sp : dc3b5ee8  ip : ddc123cc  fp : ddc11824
r10: 00000000  r9 : 00000007  r8 : 000000d0
r7 : ddc11800  r6 : ddc12380  r5 : ddecd000  r4 : ddc00d40
r3 : 00000004  r2 : c0668a80  r1 : c05f4f08  r0 : e76f4c7c
Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5387d  Table: 1c27c04a  DAC: 00000015
Process ash (pid: 847, stack limit = 0xdc3b4238)
Stack: (0xdc3b5ee8 to 0xdc3b6000)
5ee0:                   dc3b4000 00000000 ffffffff c00ae954 00000041 b6fef068
5f00: 000000d0 ddc00d40 600d0013 00000000 b6fef068 00000000 bee23814 c009e3e8
5f20: c063fb40 b6fef068 ddec9040 01200011 00000000 c001f030 0000000a 00000000
5f40: 00000000 00000000 0000000b 0000000a 00000001 b6fef068 01200011 00000000
5f60: 00000000 00000000 dc3b4000 00000000 bee23814 c001fe84 00000000 00000000
5f80: dddc6300 00000000 ddd64e80 c00a0858 b6fef068 bee237e8 b6f53000 00000078
5fa0: c000e6c4 c000e540 b6fef068 bee237e8 01200011 00000000 00000000 00000000
5fc0: b6fef068 bee237e8 b6f53000 00000078 b6fef4c0 000aa294 0000034f bee23814
5fe0: 00000000 bee237e8 b6fef000 b6eba260 600d0010 01200011 00000000 00000000
[<c009deb8>] (cache_alloc_refill+0x238/0x5c0) from [<c009e3e8>] (kmem_cache_alloc+0x7c/0xe8)
[<c009e3e8>] (kmem_cache_alloc+0x7c/0xe8) from [<c001f030>] (copy_process.part.54+0x88/0xdec)
[<c001f030>] (copy_process.part.54+0x88/0xdec) from [<c001fe84>] (do_fork+0xcc/0x260)
[<c001fe84>] (do_fork+0xcc/0x260) from [<c000e540>] (ret_fast_syscall+0x0/0x30)
Code: e59fb370 e008b00b e35b0000 0a000000 (e7f001f2) 
---[ end trace 9eb90bfd49f79de8 ]---
note: ash[847] exited with preempt_count 1

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Mon Mar 30, 2015 10:50 pm

That is a rather strange occurrence, and no function of my module seems to have been involved. Also, if you are using a custom kernel, it is rather unlikely that the module would have been able to load unless you load it with "insmod --force". Can you post the configuration of your kernel - and patches, if any ?
Another question regarding the file transfer: What is the current progress on that? I'm going to test with netcat on a small gigabit network.
We have a small utility that connects to the driver, mmap()s the DDRRAM buffers and transfers samples to a file, if that is what you meant. I have not yet tried it with a network share, though.

Anyway, thank you for your feedback.

Cheers
Nils

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 3 guests