I would caution on DC measurement. Measuring DC iis great but maintaining accuracy with such resolution brings a lots of (expensive) issues with it. Everything from possibly chopper stabilized input amps to ultra stable high performance resistors etc. that will do little for the AC performance. I think its why the ADC chip guys provide the high pass filters.
Hello,
The actual design work with 48 / 96 and 192kHz audio sampling rate. This is common frequencies that allow max sampling rate.
These frequency can be shifted for 44.1/88.2 and 176.4kHz by replacing the main oscillator or using external clock input.
Anyway, I must say that i don't see why choosing 44.1 instead of 48k.
Demian,
I agree, but even if the measurement chain can"t reach the full 24 bits DC accuracy, measuring DC can be really helpful
in lot of situations. My concern is for now i don't have found a software (for soundcard) that can display with some digits
the DC value from the audio input (maybe Virtins can ?).
In the 2nd phase of the OSVA project, the LCD display connected to the AA10M08 digital interface board will display
lot of measurements functions like DC value, RMS, peak in dBV or Vrms (and more).
Best regards.
And happy new year all !
Frex
The actual design work with 48 / 96 and 192kHz audio sampling rate. This is common frequencies that allow max sampling rate.
These frequency can be shifted for 44.1/88.2 and 176.4kHz by replacing the main oscillator or using external clock input.
Anyway, I must say that i don't see why choosing 44.1 instead of 48k.
Demian,
I agree, but even if the measurement chain can"t reach the full 24 bits DC accuracy, measuring DC can be really helpful
in lot of situations. My concern is for now i don't have found a software (for soundcard) that can display with some digits
the DC value from the audio input (maybe Virtins can ?).
In the 2nd phase of the OSVA project, the LCD display connected to the AA10M08 digital interface board will display
lot of measurements functions like DC value, RMS, peak in dBV or Vrms (and more).
Best regards.
And happy new year all !
Frex
Hi Frex,
thanks, Happy New Year to you, too!
In pro audio (outside of broadcast / film) the de facto standard is still 44.1 khz. I don't see a problem with providing clocking externally though, as long as jitter is suppressed sufficiently in the device. Ideally there would be two oscilallators and a switch allowing to choose between them, of course.
I understand this is a measuring device first and in this capacity obviously doesn't require to provide for specific sampling rates.
Anyway, can't wait to hear how it actually sounds. Getting rid of sigma delta both on the AD and the DA side in the studio has been a long term goal of mine.
Hello all,
First, thank you for you interest about the project.
I don't have posted much from some time, but not because i don't work on it !
I work hard on the main digital board (AA10M08) and the schematis ic completed to about 90 %.
Anyway, to be honnest there is still lot of job to do. I'm not (and far to be) retired
and so i only do it on my spare time.
I take care also to follow some discussion here that could be pertinent for the project design
(It's important to always have ears largely opened).
I will post some more precise and concrete things in some time when ready,
and for now i try to be focused on the design.
Regards
Frex
First, thank you for you interest about the project.
I don't have posted much from some time, but not because i don't work on it !
I work hard on the main digital board (AA10M08) and the schematis ic completed to about 90 %.
Anyway, to be honnest there is still lot of job to do. I'm not (and far to be) retired
and so i only do it on my spare time.
I take care also to follow some discussion here that could be pertinent for the project design
(It's important to always have ears largely opened).
I will post some more precise and concrete things in some time when ready,
and for now i try to be focused on the design.
Regards
Frex
Frex,
great to hear still progressing on this work - sounds great! My spare time is limited lately too, this is one of the bigger diy projects you've shared with us - it's impressive for us to get to watch it evolve
.
I wanted to pull this comment over from a related thread - I think it would be quite interesting to try this approach - maybe roll an MCU hat for the Pi per the suggestion below. This sounds rather promising as a solution for some people following this project.
great to hear still progressing on this work - sounds great! My spare time is limited lately too, this is one of the bigger diy projects you've shared with us - it's impressive for us to get to watch it evolve
.I wanted to pull this comment over from a related thread - I think it would be quite interesting to try this approach - maybe roll an MCU hat for the Pi per the suggestion below. This sounds rather promising as a solution for some people following this project.
Hi! Just discovered these forums due to the link posted above, I was the guy experimenting with the RPi as a direct acquisition system.. which was great for play, not so much for _reliable_ acquisitions. So far for first hardware experiments =) Since, spent some more time on a open-source ultrasound system (acqs @ 64/128Msps - link in the profile if you're curious, name's un0rick), having fun discovering fpgas.
Now, I still have an issue, that is I need a small, easy to run RPi extension to acquire fast signals. Maybe not as fast as 100Msps but I'd love for example to get 2x20Msps - and I'm working on a raspberry hat for this. Similar to the beaglebone prudaq for example.
Still, having _real world_ requirements would definitely help in working on the specs of the systems, so happy to discuss with you guys!
On another topic, currently exploring the i2s bus, maybe I'll be bothering these forum on the matter - kind of a new and complicated topic for me.
Take care !
Now, I still have an issue, that is I need a small, easy to run RPi extension to acquire fast signals. Maybe not as fast as 100Msps
but I'd love for example to get 2x20Msps - and I'm working on a raspberry hat for this. Similar to the beaglebone prudaq for example.Still, having _real world_ requirements would definitely help in working on the specs of the systems, so happy to discuss with you guys!
On another topic, currently exploring the i2s bus, maybe I'll be bothering these forum on the matter - kind of a new and complicated topic for me.
Take care !
OSVA - AA10M08 board ready to be routed !
Hi all,
Some new about project progress !
I have finished the schematic of the OSVA digital interface board AA10M08.
Before to do it, i have made a complete and detailed synoptic of the board.
You can access to both documents below (pdf files) :
AA10M08 Digital board Synoptic file :
AA10M08_synoptic-V1.0_09052020
AA10M08 Digital board Kicad schematics :
AA10M08v1_schematics_09052020
The digital board include lot of interface can be used with SDR-Widget,
MiniDSP USB-Streamer and MCH-Streamer.
I also added a connector interface to allow using Raspberry-P 3 as interface,
it would be probably the best way (and less expensive too) to send full sample rate data to computer.
We just need to found someone to do this !
Comments are welcome.
I Have all imported in PCB, and i must now routed the PCB.
Lot of job again...
Frex
Hi all,
Some new about project progress !
I have finished the schematic of the OSVA digital interface board AA10M08.
Before to do it, i have made a complete and detailed synoptic of the board.
You can access to both documents below (pdf files) :
AA10M08 Digital board Synoptic file :
AA10M08_synoptic-V1.0_09052020
AA10M08 Digital board Kicad schematics :
AA10M08v1_schematics_09052020
The digital board include lot of interface can be used with SDR-Widget,
MiniDSP USB-Streamer and MCH-Streamer.
I also added a connector interface to allow using Raspberry-P 3 as interface,
it would be probably the best way (and less expensive too) to send full sample rate data to computer.
We just need to found someone to do this !
Comments are welcome.
I Have all imported in PCB, and i must now routed the PCB.
Lot of job again...
Frex
Hi Frex,
I've been pondering this one a little again.
According to SPI speed calculated wrong on RPi3 * Issue #2094 * raspberrypi/linux * GitHub and SPI - Raspberry Pi Documentation
The SPI clock speed is selected by dividing the gpu core clock by either multiples of 2 or powers of 2 (this is probably meaningless for our desired freq since we should be able to get our desired outcome with 2 or 4 and adjusting the clock freq to suit.
Core clock varies with revisions of the RPi:
RPi 2 - 250MHz
RPi 3 - 350MHz
RPi 4 - Min: 200MHz Turbo: 500Mhz
So what I think will need to happen is we set the GPU freq underclocked such that we can divide by 2 to get 100MHz to match the clock on the AA2380 and/or AA10M08 boards.
The questions that I've got because I haven't done any CPLD/FPGA programming before - it may be answered if I read the code that you have already shared here - GitHub - OneAudio/AA2380_MAXV: AA2380 analyser MAX embedded software. I have read the pdf AA2380_MAXV/2380CPLD.pdf at master * OneAudio/AA2380_MAXV * GitHub but I'm quite sure that I'm misunderstanding something due to lack of experience. Question being:
Is the data sent pure SPI (with some sort of flag to show ADC0 or ADC1? Or are you extending the data and using a separate pin to flag data for Left/Right?
I haven't found much info on folks using the RPi SPI bus at these faster speeds - I'd be interested to hear if there is something I'm missing from kelu124 or phofman or others that have played with high speed SPI in to Raspberry Pi.
I think it might be feasible to set up the RPi to be able to follow either of the boards.
The way I see things is that we'd probably want to use the RPi primarily as a way to get the data in to a UAC2 format using the UAC2 gadget in asynch mode that phofman has recently reported is hopefully not too far away. Later it may be interesting to do more with the RPi but for now I think this is the most important goal to get the full data capture in to a PC. Downside is that this may only be supported by linux host system to receive the data at this stage - totally fine with me but may be a limitation to others.
I have also recently ordered a MCHstreamer for a 8ch DAC that I'm building. I can experiment with ways to get this in to slave mode too. But remember that this will still need software support in terms of unwrapping the data that's been split across the 8 channels. I don't think this is ideal and I have no real personal motivation to make it work if there is an asynch UAC2 gadget RPi4 option that supports the full data rate in 2ch.
With all of this in mind - I have no way to test/validate that solution about actually works at this stage. One possibility would be for me to order some PCBs based on the gerbers you've already published and assemble an AA2380 board - but I have held off that so far thinking that there was possibility for revisions to be made to that board through the design of the AA10M08. Is that caution still warranted?
Cheers,
Chris
Last edited: