Routeing the optional clocks trough the FPGA might degrade their performance. Perhaps better to use e.g. three state buffers controlled by the FPGA to switch them.
Moreover, if I see it correctly, the external clock input of the ADC board is designed with no direct way to the clock input of the ADC, but is routed through the NB3N511 multiplier (with doubtable jitter performance).
But best would be perhaps to locate an optional second clock on the ADC board itself.
Moreover, if I see it correctly, the external clock input of the ADC board is designed with no direct way to the clock input of the ADC, but is routed through the NB3N511 multiplier (with doubtable jitter performance).
But best would be perhaps to locate an optional second clock on the ADC board itself.
I can read the 100 MHz SPI from a LTC2500-32 into the BeagleBoneBlack.
I did not get the SPI interface of the BBB running b/c of software, and that is
limited to 48MBit/s anyway. I used a $2 Xilinx Coolrunner II CPLD to parallelize
SPI to bytes and then read the bytes via one of the 2 200MHz I/O "PRU" processors.
From the BBB side, I could read 3 ADCs with one PRU, maybe 4 with some
effort.
The Coolrunner also creates the sample clock from the 100 MHz crystal osc.
There are no activities in the CPLD at sample time, then the ADC wants to be
left alone. The 100 MHz SPI clock is necessary because the 32 bit words have
to be shifted out in the 1/3 of the 1MHz sample period when the ADC is not
busy with aquisition.
What I'd really like is a credit-card sized board that has at least a 16 bit
bus interface. The BBB might do it. I'm not sure what features I had to give
up for it if I get the s/w right. I want fast register/DMA access to an FPGA.
Cheers, Gerhard
I did not get the SPI interface of the BBB running b/c of software, and that is
limited to 48MBit/s anyway. I used a $2 Xilinx Coolrunner II CPLD to parallelize
SPI to bytes and then read the bytes via one of the 2 200MHz I/O "PRU" processors.
From the BBB side, I could read 3 ADCs with one PRU, maybe 4 with some
effort.
The Coolrunner also creates the sample clock from the 100 MHz crystal osc.
There are no activities in the CPLD at sample time, then the ADC wants to be
left alone. The 100 MHz SPI clock is necessary because the 32 bit words have
to be shifted out in the 1/3 of the 1MHz sample period when the ADC is not
busy with aquisition.
What I'd really like is a credit-card sized board that has at least a 16 bit
bus interface. The BBB might do it. I'm not sure what features I had to give
up for it if I get the s/w right. I want fast register/DMA access to an FPGA.
Cheers, Gerhard
Last edited:
Continuous aquisition is a software problem in the BBB. The intended system is
at least 3 * LTC2500-32 because I need 3 channels to compute the 3 cornered hat.
That allows to compute away the noise contribution of the own power supplies,
input amplifiers, ADCs, clocks(if you have 3 of them also) by 3 pairs of correlation
and keeping only the part of the signal that is common to all 3 channels.
The Coolrunner packs the SPI data bytewise and passes them to the Beaglebone.
There, a "PRU" I/O processor collects them and builds the 32 bit words together and
puts them into a shared RAM. The shared RAM is organized as a ping-pong buffer.
While one half is written by the PRU, the other half can be emptied by the ARM CPU
that runs Linux. As long as the Linux side can keep up with this ping-pong, there is
no time limit on the record length. I have not yet tested this handshake on the long
run.
I could compile FFTW, the Fastest FFT in the West on the Linux ARM.
For now, the user interface is the network. A laptop may open port 5005 on
192.168.178.38 (my BBB) and dump/read normal GPIB style traffic. I have
copied this from my Agilent 89441A control program. No need to re-invent the wheel.
Currently, there are not many commands implemented, just *IDN
, programming
the ADC for decimation, filtering etc and reading some result buffers.
I have done no FFT on payload data.
For example, you set the decimation on the laptop, this is transferred to the BBB
ARM over LAN and the ARM then interprets the command. It sees that it is sth.
hardware-related, passes a command to the PRU processor and the PRU then
bit-bangs it into the Linear Tech ADC.
It was quite hairy to figure out how to do all these handshakes, or how to access
all that hardware from Linux, or to compile a PRU program and make it execute.
Or to find out where the ping-pong buffer is, as seen from the PRU hardware and
how to map it into the ARM-Linux virtual memory. There are pics of the setup in
some other thread here on DIYaudio, it's not much hardware. The complexity
is completely on the software side. All compilers / everything needed is
on the BBB. No need for external infrastructure, maybe ssh or some other
terminal program.
Alternatively, one could use the Apache web server and display the spectrum
in the web interface, as it is done in the spectrum analyzer / scope app for the
Red Pitaya. That is somewhere on github and could be recycled. You get
real time spectra on the screen of your laptop with this tiny Red Pitaya.
That's really too much to do for one man in finite time. I wanted to use it for
phase noise measurements, but I now have a Timepod, so it is no longer
THAT urgent for me.
at least 3 * LTC2500-32 because I need 3 channels to compute the 3 cornered hat.
That allows to compute away the noise contribution of the own power supplies,
input amplifiers, ADCs, clocks(if you have 3 of them also) by 3 pairs of correlation
and keeping only the part of the signal that is common to all 3 channels.
The Coolrunner packs the SPI data bytewise and passes them to the Beaglebone.
There, a "PRU" I/O processor collects them and builds the 32 bit words together and
puts them into a shared RAM. The shared RAM is organized as a ping-pong buffer.
While one half is written by the PRU, the other half can be emptied by the ARM CPU
that runs Linux. As long as the Linux side can keep up with this ping-pong, there is
no time limit on the record length. I have not yet tested this handshake on the long
run.
I could compile FFTW, the Fastest FFT in the West on the Linux ARM.
For now, the user interface is the network. A laptop may open port 5005 on
192.168.178.38 (my BBB) and dump/read normal GPIB style traffic. I have
copied this from my Agilent 89441A control program. No need to re-invent the wheel.
Currently, there are not many commands implemented, just *IDN
, programmingthe ADC for decimation, filtering etc and reading some result buffers.
I have done no FFT on payload data.
For example, you set the decimation on the laptop, this is transferred to the BBB
ARM over LAN and the ARM then interprets the command. It sees that it is sth.
hardware-related, passes a command to the PRU processor and the PRU then
bit-bangs it into the Linear Tech ADC.
It was quite hairy to figure out how to do all these handshakes, or how to access
all that hardware from Linux, or to compile a PRU program and make it execute.
Or to find out where the ping-pong buffer is, as seen from the PRU hardware and
how to map it into the ARM-Linux virtual memory. There are pics of the setup in
some other thread here on DIYaudio, it's not much hardware. The complexity
is completely on the software side. All compilers / everything needed is
on the BBB. No need for external infrastructure, maybe ssh or some other
terminal program.
Alternatively, one could use the Apache web server and display the spectrum
in the web interface, as it is done in the spectrum analyzer / scope app for the
Red Pitaya. That is somewhere on github and could be recycled. You get
real time spectra on the screen of your laptop with this tiny Red Pitaya.
That's really too much to do for one man in finite time. I wanted to use it for
phase noise measurements, but I now have a Timepod, so it is no longer
THAT urgent for me.
Last edited:
Even at the max. 1 MSPS rate, 3 or 4 Mbytes is 1 second worth of samples. A 10 second FIFO should be just 40 MBytes. It's just that the top priority must be the unloading of the pingpong buffer. I think that could be even handled by DMA or the second PRU. Other than that, there is not much to do in real time.
An advantage of the LTC2500-32 against its similar brothers is that it has built in decimation and the digital low pass filters that are then required. Each halving of the sample rate halves the processing overhead and the decimation and digital filters are already debugged by LT. The *guaranteed* AC specs are the same.
One could also use the Beaglebone AI, with a second 'big' ARM, 4 smaller ones, two floating point long instruction word DSPs and the PRUs. It has the same form factor, it should fit electrically. Most of the migration work would be to decide what is not needed and keeping it out of the way.
That was also the problem with the BBB. Getting a somewhat recent Linux and and a set of tools that work together, throwing away outdated appnotes, books and web content. If someone wants to play with the BBB, I can provide a boot disk / SD-card that works or put it on github.
An advantage of the LTC2500-32 against its similar brothers is that it has built in decimation and the digital low pass filters that are then required. Each halving of the sample rate halves the processing overhead and the decimation and digital filters are already debugged by LT. The *guaranteed* AC specs are the same.
One could also use the Beaglebone AI, with a second 'big' ARM, 4 smaller ones, two floating point long instruction word DSPs and the PRUs. It has the same form factor, it should fit electrically. Most of the migration work would be to decide what is not needed and keeping it out of the way.
That was also the problem with the BBB. Getting a somewhat recent Linux and and a set of tools that work together, throwing away outdated appnotes, books and web content. If someone wants to play with the BBB, I can provide a boot disk / SD-card that works or put it on github.
Last edited:
Hello Chris,
Thank you all for your comments.
I'm not able to say what we could really do with the R-pi, I rest my choice to added the R-pi interface
connector on experiments of others , and because also that cost nearly nothing.
So this allow a solution as soon something will be available.
If required, and can also provide a BB-black I/interface connector if that make sense
(I can't judge this on myself).
I agree with you (and others) that using USB/MCH streamer to send splitted streams is not very satisfying,
and I would greatly prefer an another option like R-pi board or BB black. Much less expensive and much
more versatile and powerful solution.
Anyway, I prefer to allow multiple interface solution (as wide as possible) to let the OSVA widely open.
(SDR-Widget and USB/MCH-Streamer are already available).
I think that for testing purpose only of transmitting high sampling rate, you don't have to build
the current AA2380 board (I think it's too soon).
A small CPLD/FPGA board (very cheap) can be used to generate high rate I2S data up to 1536 kHz
(as AA2380 can do). A simple sine-wave lock-up table can be used as signal source and will allow
to validate the correct data transmission with the digital board (R-pi of BB-black or other).
Note that the FPGA in AA10M08 board is not (in my mind intended to be used for PC interfacing (via USB),
but it is designed to perform math operation like multiple digital filtering .
I is used also for GUI interface with a small display that allow function control and measurements display.
Of course, it will be able to provide the digital interface to stream data to the external
CPU board (Rpi-BB, black, other ?). This interface can be I2S type, but that can also be what we want.
It's the story to be write, and I will do the necessary to adapt the FPGA software if required for interfacing
(with the limit of my knowledge and spare time).
If the limit come from data transfer rate of SPI interface, does it is possible to use Quad-SPI interface
on R-PI or BB-black ? This could reduce drastically the effective speed of each SPI line.
Zfe,
There is many different operation possible.
The first one that is far the better, is to stay with the on-board AA2380 98.304MHz low phase noise clock.
It is important to keep the the clock source near the ADC to avoid degrade it's performance.
In my mind, this clock is sufficient and allow all audio clock multiple to 48KHz standard (48k to 1536k).
I have read that some users would like to use others standard audio clock like 44.1kHz.
So, it is why I add two audio clock (98.304M and 90.3168M) on the AA10M08 board.
When we use the USB/MCH streamer, these boards are normally used to be the Master clock source
(They provide the MCLK audio clock),
So it is possible to send this audio audio clock to the clock input (SMA) of the AA2380.
Because the AA2380 require much higher frequency, i added the PLL to get the 98.304M and 90.3168M
frequencies (from 22.579M and 24.576M MCLK).
It is also possible to use them as slave (MCLK provided by AA2380), but that require few hardware
modifications on USB/MCH-streamer. So, you must keep in mind that i designed the AA10M08
to be able to perform lot of configurations, even if we will found some better than others.
They will need to be tested/evaluated.
For now, i continue the work on AA10M08 board, starting placing parts on Kicad.
I will do also some minor schematics modifications.
I would like to have "ready to send" PCB at end of the month.
Regards.
Frex
Thank you all for your comments.
I'm not able to say what we could really do with the R-pi, I rest my choice to added the R-pi interface
connector on experiments of others , and because also that cost nearly nothing.
So this allow a solution as soon something will be available.
If required, and can also provide a BB-black I/interface connector if that make sense
(I can't judge this on myself).
I agree with you (and others) that using USB/MCH streamer to send splitted streams is not very satisfying,
and I would greatly prefer an another option like R-pi board or BB black. Much less expensive and much
more versatile and powerful solution.
Anyway, I prefer to allow multiple interface solution (as wide as possible) to let the OSVA widely open.
(SDR-Widget and USB/MCH-Streamer are already available).
I think that for testing purpose only of transmitting high sampling rate, you don't have to build
the current AA2380 board (I think it's too soon).
A small CPLD/FPGA board (very cheap) can be used to generate high rate I2S data up to 1536 kHz
(as AA2380 can do). A simple sine-wave lock-up table can be used as signal source and will allow
to validate the correct data transmission with the digital board (R-pi of BB-black or other).
Note that the FPGA in AA10M08 board is not (in my mind intended to be used for PC interfacing (via USB),
but it is designed to perform math operation like multiple digital filtering .
I is used also for GUI interface with a small display that allow function control and measurements display.
Of course, it will be able to provide the digital interface to stream data to the external
CPU board (Rpi-BB, black, other ?). This interface can be I2S type, but that can also be what we want.
It's the story to be write, and I will do the necessary to adapt the FPGA software if required for interfacing
(with the limit of my knowledge and spare time).
If the limit come from data transfer rate of SPI interface, does it is possible to use Quad-SPI interface
on R-PI or BB-black ? This could reduce drastically the effective speed of each SPI line.
Zfe,
There is many different operation possible.
The first one that is far the better, is to stay with the on-board AA2380 98.304MHz low phase noise clock.
It is important to keep the the clock source near the ADC to avoid degrade it's performance.
In my mind, this clock is sufficient and allow all audio clock multiple to 48KHz standard (48k to 1536k).
I have read that some users would like to use others standard audio clock like 44.1kHz.
So, it is why I add two audio clock (98.304M and 90.3168M) on the AA10M08 board.
When we use the USB/MCH streamer, these boards are normally used to be the Master clock source
(They provide the MCLK audio clock),
So it is possible to send this audio audio clock to the clock input (SMA) of the AA2380.
Because the AA2380 require much higher frequency, i added the PLL to get the 98.304M and 90.3168M
frequencies (from 22.579M and 24.576M MCLK).
It is also possible to use them as slave (MCLK provided by AA2380), but that require few hardware
modifications on USB/MCH-streamer. So, you must keep in mind that i designed the AA10M08
to be able to perform lot of configurations, even if we will found some better than others.
They will need to be tested/evaluated.
For now, i continue the work on AA10M08 board, starting placing parts on Kicad.
I will do also some minor schematics modifications.
I would like to have "ready to send" PCB at end of the month.
Regards.
Frex
RPi's I2S has been tested (not by me) at 364kHz. It may go higher but I have not seen any reports of that. Very likely nobody had any hardware to test with. Nevertheless IMO 1.5M is way too high for this peripheral.
RPI' SPI is known to top up below 50MHz. IMO that is too slow to fetch the data between the conversion runs.
IMO the way to go with RPi4 could be serial/parallel conversion in simple hardware and reading RPI's GPIOs (all 24 bits at samplerate?) to RAM in a separate kernel thread, running on a dedicated core. The remaining cores should easily handle the USB-audio conversion plus some minor DSP (e.g. averaging to lower rate), should it be required.
RPI' SPI is known to top up below 50MHz. IMO that is too slow to fetch the data between the conversion runs.
IMO the way to go with RPi4 could be serial/parallel conversion in simple hardware and reading RPI's GPIOs (all 24 bits at samplerate?) to RAM in a separate kernel thread, running on a dedicated core. The remaining cores should easily handle the USB-audio conversion plus some minor DSP (e.g. averaging to lower rate), should it be required.
RPi has 27 GPIOs, enough for 24bit and clock. I would prefer 1 x 24bits at fs, but the 2x12bits at 2fs is a theoretical option too. Practical implementation remains to be tested
I could generate a test signal with STM32 or another RPi but honestly have no time for it at the moment, a few other projects WIP + looking for an extra commercial work in this weird time...
My longer-term "mental intention" is an affordable-cost stereo DAC/ADC analyzer combo timed from common clock running up to 512kHz, managed by RPi4. Stereo AK4493EQ for DAC via RPI I2S, 2x ADS127L01 via 2 RPI SPIs. RPi would run the digital distortion compensation, all presented as a standard USB soundcard to a PC running any of the existing advanced software analyzers (preferably REW which was perfectly stable in my test up to 1.5MHz). Using the latest inexpensive very-low THD+N opamps.
I believe at this rather low samplerate there is no technical obstacle, just LOTS of work. Frontend, ranging, clocks, constant BOM cost optimization... For now just looking at options and economical feasability...
I could generate a test signal with STM32 or another RPi but honestly have no time for it at the moment, a few other projects WIP + looking for an extra commercial work in this weird time...
My longer-term "mental intention" is an affordable-cost stereo DAC/ADC analyzer combo timed from common clock running up to 512kHz, managed by RPi4. Stereo AK4493EQ for DAC via RPI I2S, 2x ADS127L01 via 2 RPI SPIs. RPi would run the digital distortion compensation, all presented as a standard USB soundcard to a PC running any of the existing advanced software analyzers (preferably REW which was perfectly stable in my test up to 1.5MHz). Using the latest inexpensive very-low THD+N opamps.
I believe at this rather low samplerate there is no technical obstacle, just LOTS of work. Frontend, ranging, clocks, constant BOM cost optimization... For now just looking at options and economical feasability...
I understand the use/need of 98.304M and 90.3168M clocks and the need of the multiplier when externally fed with a e.g. 22.579M or 24.576M MCLK.
My first objection is that, according to the schematic at github (A2380 OSVA ADC board v1.0), the external clock signal to the LTC2380 (CLKIN_xN) is routed through the multiplier (NB3N511).
As far I see it, the NB3N511 has no option to pass the clock with unaltered frequency and moreover is only specified up to 50MHz input.
Thus supplying the 98.304M and 90.3168M from the AA10M08 via the external clock input of the A2380 should not work.
The second objection is that the purpose of an external clock input is generally not only to supply other frequencies but also to provide higher quality clock signals (in which sense ever). Thus the external clock input should not degrade the quality of the external clock ... in some reasonable range.
As the aperture jitter of the LTC2380 is 4ps, according to the data sheet, the additional jitter of the external clock circuity should be lower than that (say at most 1ps). The NB3N511 has 25ps jitter.
I agree that the best option is to keep the the clock source near the ADC. Therefore I sugested (for an future revision) to add the possibility to add an second clock next to the ADC. Then it would also be nice if you do design the landing for the clock(s) such that one could use clocks with different footprints (or add a SMA connector).
And if you are really serious, you think about the vibration properties of the board around that clock mounting. Maybe a possibility for a cutout with just the clock on a mini-board possible to break a few thin bridges so that the clock can be suspended by rubber band etc. The signal and power feed is TBD in this case ;-)
On a lab table there are fans and what not making the board and oscillator vibrate making the side band of the crystal go "banana"!?
//
On a lab table there are fans and what not making the board and oscillator vibrate making the side band of the crystal go "banana"!?
//
It's been a while, and I didn't follow this thread, so please bear with me.
Is this still an option? A DIY audio analyser with a Nyquist frequency of 0.75 MHz would indeed be super cool!
Is this still an option? A DIY audio analyser with a Nyquist frequency of 0.75 MHz would indeed be super cool!
Hello,
JimBeam69 ,
For now, the best results i have is with the ada4945-1, but adding some tweak because the part behavior is not well documented.
Do you have used their eval board or it's your own design ?
Hello mbrennwa,
Yes. I have added a full I/O link on the AA10M08 currently designed digital board of the OSVA
to allow direct connection of a RPI 4.
This has been done because of some developments (not from me) to use RPI-4 to stream high
sample rate audio data from USB? That would be an audio bridge seen as audio device.
On my side, I work on the full mechanical integration (learning to use Freecad...) of all
parts of OSVA in the enclosure.
So, work is in progress ans i hope to finalize soon the AA10M08 board to send it for manufacturing.
(I need change some parts placement because of the mechanical issue ).
Regards.
Frex
JimBeam69 ,
For now, the best results i have is with the ada4945-1, but adding some tweak because the part behavior is not well documented.
Do you have used their eval board or it's your own design ?
Hello mbrennwa,
Yes. I have added a full I/O link on the AA10M08 currently designed digital board of the OSVA
to allow direct connection of a RPI 4.
This has been done because of some developments (not from me) to use RPI-4 to stream high
sample rate audio data from USB? That would be an audio bridge seen as audio device.
On my side, I work on the full mechanical integration (learning to use Freecad...) of all
parts of OSVA in the enclosure.
So, work is in progress ans i hope to finalize soon the AA10M08 board to send it for manufacturing.
(I need change some parts placement because of the mechanical issue ).
Regards.
Frex
Well, good luck
After several reworks of my first 3D project (version 0.16 was really bad at accommodating model changes which are inevitable for any larger project) I had to dump Freecad. Fusion360 is not open source, free only for diy projects, but incomparably more productive and comfortable. While it has its quirks too, making changes to the model is WAY more reliable.Salut Frex ...
From a first glance it may not appear to be anything special but IMHO it is super intuitive to use and also very powerful in terms of drawing all sorts of things (including complex work).
And I think that the name (MoI is an acronym for "Moment of Inspiration") actually says what is possible with this program: When the inspiration for "something" is there I can use the program without having to think much about all sorts of technical or GUI aspects but just use it.
Not for free but again IMHO worth its ~ USD300 asking price. 30 days trial.
Looking forward to what you end up with in this project ;-)
Cheers,
Jesper
... Now I'm not familiar with FreeCad but if for some reason at some point in time you go looking for a very intuitive and easy to use 3D modeling program may I suggest MoI3D ...
From a first glance it may not appear to be anything special but IMHO it is super intuitive to use and also very powerful in terms of drawing all sorts of things (including complex work).
And I think that the name (MoI is an acronym for "Moment of Inspiration") actually says what is possible with this program: When the inspiration for "something" is there I can use the program without having to think much about all sorts of technical or GUI aspects but just use it.
Not for free but again IMHO worth its ~ USD300 asking price. 30 days trial.
Looking forward to what you end up with in this project ;-)
Cheers,
Jesper