Discussions about active development projects
#1731 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
#1743 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.
#1744 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.
#1748 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
#1749 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.
#1775 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 allredpitaya> 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
#1788 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

Who is online

Users browsing this forum: Google [Bot] and 2 guests