Demian,
As you, I would be very happy if the analyser could work fully in stand-alone mode
using a R-pi or others CPU boards, but there is a big software job (and not in my skill).
So, we will need to find some skilled team for that.
(It's a foot call)
I've spent a bit of time thinking about how I would write an analyser software that was intended for devices like RPi. This new SAR ADC might be just the motivation I need to finally write that. Where I am unfamiliar is in writing a linux driver for a new device, which is why I was thinking to use SPI in on the RPi/Parallella which already have drivers and I'd need to access that hardware through those drive APIs. But as Frex points out this would make it challenging to use the existing software.
I have in mind open source software with a web UI for analyser that is accessed over the network (or from a screen connected to the RPi/parallella/bb/whatever). I was thinking that I would build something that is minimal functionality (at least initially) but have the ability to export saved captures for offline analysis in existing software.
I'll try to make some rough prototypes then start a discussion on this topic either here or in a new thread. Happy to discuss this some place else rather than derail this thread.
Chris
Have a look at the Avermetrics Avermetrics | AverLAB | Avermetrics product to get an idea how they solved the problems. There is a suite of Linux audio test stuff that could be ported. I'm not sure a Rasberry pi has enough horsepower for the analysis but I may be mistaken. Linux drivers are pretty easy. The ALSA project has lots of examples and source code for lots of sound cards, both USB and PCI types. probably some other variations as well. (Even Android uses ALSA so lots there for other processors).
Just to be clear this ultra high performance ADC (and DAC) are not needed for acoustic measurements so the focus should be on electronic measurements first.
And the author of this package Audio Testing | audioroot is a DIYaudio contributor with a package that may be amenable.
Just to be clear this ultra high performance ADC (and DAC) are not needed for acoustic measurements so the focus should be on electronic measurements first.
And the author of this package Audio Testing | audioroot is a DIYaudio contributor with a package that may be amenable.
The FTDI chip mitigates this partially because the D2XX and D3XX APIs have cross-platform drivers and there are probably already open source implementations.
Hi all ...
... let me start by saying that I am not a programmer so I will do my best to tread carefully here ... but some time ago I looked at FTDI's chips and they e.g. have a USB 3.0 based chip that can transfer quite a bit of data, and comes with a driver that "I reckon" can be modified relatively easily by someone skilled in programming. If I remember correctly one of the ICs may transfer up to four channels. Another advantage is that they (to my memory) are not expensive and should be relatively simple to implement from a hardware perspective...
Cheers,
Jesper
... let me start by saying that I am not a programmer so I will do my best to tread carefully here ... but some time ago I looked at FTDI's chips and they e.g. have a USB 3.0 based chip that can transfer quite a bit of data, and comes with a driver that "I reckon" can be modified relatively easily by someone skilled in programming. If I remember correctly one of the ICs may transfer up to four channels. Another advantage is that they (to my memory) are not expensive and should be relatively simple to implement from a hardware perspective...
Cheers,
Jesper
They are convenient for a non audio device class method. Of course it will require another mechanism to output data to appear as an audio device on a PC,. Demian had some good suggestions for that.
I think we're on the same page, I very much am in the mindset of electronics measurements here not acoustic stuff.
Regarding horsepower, that's something I'm investigating (RPi gpu for FFT or using a xilinx zynq based board and letting the FPGA do the FFT among other ideas). Let me look in to that in the coming weeks - I have a diy bathroom reno to finish before I get too stuck in to this idea.
I can't see much details about how the Averlab manages its calculations/processing and whether it performs that all in the computer or if it performs that inside the instrument itself. It is an interesting tool for sure!
What other linux analyser stuff did you have in mind just so I can do some background research?
There doesn't appear to be an ARM version of the linux drivers for D3XX so aside from my reservations about how it well it would work within an ALSA driver it's a non-starter for me because most of the hardware I'm personally thinking about is ARM based. Further, I don't know enough about USB audio to know how well that may perform, especially considering that Frex has indicated that he wants to include a DAC in this system in the future. As a result I don't think I'm the programmer you're looking for to implement that.
Cheers,
Chris
Yeah, the FTDI stuff is a non-audio, higher bandwidth path, you would not use it in an audio driver. D2XX does have ARM versions available though.
Hello,
Zfe, not really.
If we would use the ADC at it's maximum rate (1536 kHz), we would need then at least :
2 channels * 24 bits * 1536 kSPS = 73 728 kHz >> 73 Mbps
So USB 2 Full speed is the minimum required.
OF course for lower standard sampling rate, we can need much less bandwidth.
Anyway the idea (in my mind), is to provide a way that able to send high rate data
and the FT600 could be a good solution. Of course, many users probably don't care
about this so is will be of course an option.
hochopeper (Chris),
I think your R-pi on-board analyser would be very welcome in the project !
Web UI is great. Saving captured data would be also very convenient (especially for high rate)
and even could replace the FT600 interface by using your network connection.
So, i think we can try to work together to define the interface between the ADC board and the R-Pi.
So it's sure, i must add a R-Pi in my main synoptic.
Demian,
Could you clarify your idea about the AVERlab analyzer ?
I don't have found much info about their hardware.
I just have seen that they use Ethernet connexion between the analyzer
and the computer side.
Note that the OSAV is intended as measurement instrument,
but nothing stands in the way of it is used for audio.
Any dedicated input stage could be used for audio recording purpose.
Chris,
From what suggestions are you talking about ?
I maybe have missed it (sorry).
If we add a Pi board with network access, there is possibly no need to
to have FT600 USB link. I think it's two different things.
So R-pi hardware with stand-alone analysis and data capture with remote UI
and would be a great tool !
Note that it's not always easy for me to synthesize all idea here (and we have a lot ),
but i think it's very constructive and help me for building a better instrument that fit
our DIY users needs. So thank you to all for your active participation !
Regards.
Frex
Zfe, not really.
If we would use the ADC at it's maximum rate (1536 kHz), we would need then at least :
2 channels * 24 bits * 1536 kSPS = 73 728 kHz >> 73 Mbps
So USB 2 Full speed is the minimum required.
OF course for lower standard sampling rate, we can need much less bandwidth.
Anyway the idea (in my mind), is to provide a way that able to send high rate data
and the FT600 could be a good solution. Of course, many users probably don't care
about this so is will be of course an option.
hochopeper (Chris),
I think your R-pi on-board analyser would be very welcome in the project !
Web UI is great. Saving captured data would be also very convenient (especially for high rate)
and even could replace the FT600 interface by using your network connection.
So, i think we can try to work together to define the interface between the ADC board and the R-Pi.
So it's sure, i must add a R-Pi in my main synoptic.
Demian,
Could you clarify your idea about the AVERlab analyzer ?
I don't have found much info about their hardware.
I just have seen that they use Ethernet connexion between the analyzer
and the computer side.
Note that the OSAV is intended as measurement instrument,
but nothing stands in the way of it is used for audio.
Any dedicated input stage could be used for audio recording purpose.
Chris,
From what suggestions are you talking about ?
I maybe have missed it (sorry).
hochopeper (Chris) again,
If we add a Pi board with network access, there is possibly no need to
to have FT600 USB link. I think it's two different things.
So R-pi hardware with stand-alone analysis and data capture with remote UI
and would be a great tool !
Note that it's not always easy for me to synthesize all idea here (and we have a lot
), but i think it's very constructive and help me for building a better instrument that fit
our DIY users needs. So thank you to all for your active participation !
Regards.
Frex
But there seems to be an problem due to the USB-audio-class specifications,
see http://www.xmos.com/download/private/Fundamentals-of-USB-Audio(1.0).pdf
The data is transferred in frames of at most 1k byte size at a rate of 8000 frames per second. That is enough only for one channel at 1536 kHz.
However this limitation is per endpoint and an USB connection can have multiple endpoints - but I have no idea if it is possible to keep the data of different endpoints synced.
see http://www.xmos.com/download/private/Fundamentals-of-USB-Audio(1.0).pdf
The data is transferred in frames of at most 1k byte size at a rate of 8000 frames per second. That is enough only for one channel at 1536 kHz.
However this limitation is per endpoint and an USB connection can have multiple endpoints - but I have no idea if it is possible to keep the data of different endpoints synced.
OSVA project update.
Hello,
To take in account previous comments i updated the OSVA general synoptic.
You can show it below (pdf file can be downloaded HERE ):
The first (main) board is the AA2380 ADC PCB.
This board include two ADC channels with an isolated high speed digital
interface allowing to send data to external hardware at full sampling rate (1536kHz 24bits).
The external hardware could be the future AA10M08 CPLD PCB, or Raspberry PI or any others
digital board that can handle the stream speed from ADC PCB.
These external hardware allow to extend design capability
(adding digital filtering, making standalone GUI...).
Anyway, the AA2380 PCB can work as standalone mode.
Without any other hardware it can provide direct S/PDIF output supporting 24/192kHz
and also I2S outputs.
Some I/O allow to select sampling rate and averaging ratio of ADC internal SinC filter.
If a SDR-Widget or USB-streamer board is added, it provide direct USB link of the analyzer
with 24/192 support (SDRwidget) and even 24bits/768k with multichannel mode of USB-streamer.
Each digital links between all of these board are isolated from AA2380 ADC PCB
to avoid ground loop issue and noise contamination.
An isolated master clock input is also provided to use external clock for ADC sampling.
Now, you can show a detailed synoptic view of the AA2380 PCB itself :
(pdf file can be downloaded HERE )
Each ADC front-end start with EMC filtering and protections, followed by
ultra-low THD and noise drivers with anti-alias HF filtering.
This stage is very critical to not degrade ADC performances.
The signal path is fully differential, but the signal input can be single-ended
or differential.
The board include two ADC channels (for LTC2380-24 or compatible devices).
Note that the use of two ADC channels offer various possible system configurations like :
_ Interleaving sampling (for twice output sampling rate)
_ Parallel mode for SNR improvement
_ Separate channel for ratio calculation (Bode plot)
So, many of these configuration are only software dependent (CPLD firmware).
The serial links (SPI) of ADC are connected to a CPLD and to the clock synchronizer.
The sync block ensure precise ADC sampling from the low phase noise master clock.
The conversion can also be initiated by an isolated external clock source.
Some on-boards LEDs allow to display status, and dedicated connectors provide
test I/O and JTAG programming link.
A dedicated connector allow connection of a rotary encoder and leds for ADC control
in stand-alone mode.
The connexion to the SDR-widget or USB-streamer use dedicated connector with same pin-out
as target board and are fully isolated. The isolated side provide the isolator supply.
Another connector is used for the external digital interface (AA10M08 or others)
it provide many high-speed I/O to allow full rate ADC data transfert and also
control signal to ADC board.
This link is also fully isolated from ADC side to avoid loop and noise.
The digital interface side mus provide isolator supply.
A last connector provide uninsulated I/O for future ADC extension board.
The board is supplied with +5V and +/-12V.
All of these voltages come from low noise source.
I think it's a nearly complete board description, and that will help me to start
schematics drawing. I also started to define data I/O communication specifications
for all connectors to avoid an oversight. They will be published as soon completed.
To be continued...
Frex.
Hello,
To take in account previous comments i updated the OSVA general synoptic.
You can show it below (pdf file can be downloaded HERE ):
The first (main) board is the AA2380 ADC PCB.
This board include two ADC channels with an isolated high speed digital
interface allowing to send data to external hardware at full sampling rate (1536kHz 24bits).
The external hardware could be the future AA10M08 CPLD PCB, or Raspberry PI or any others
digital board that can handle the stream speed from ADC PCB.
These external hardware allow to extend design capability
(adding digital filtering, making standalone GUI...).
Anyway, the AA2380 PCB can work as standalone mode.
Without any other hardware it can provide direct S/PDIF output supporting 24/192kHz
and also I2S outputs.
Some I/O allow to select sampling rate and averaging ratio of ADC internal SinC filter.
If a SDR-Widget or USB-streamer board is added, it provide direct USB link of the analyzer
with 24/192 support (SDRwidget) and even 24bits/768k with multichannel mode of USB-streamer.
Each digital links between all of these board are isolated from AA2380 ADC PCB
to avoid ground loop issue and noise contamination.
An isolated master clock input is also provided to use external clock for ADC sampling.
Now, you can show a detailed synoptic view of the AA2380 PCB itself :
(pdf file can be downloaded HERE )
Each ADC front-end start with EMC filtering and protections, followed by
ultra-low THD and noise drivers with anti-alias HF filtering.
This stage is very critical to not degrade ADC performances.
The signal path is fully differential, but the signal input can be single-ended
or differential.
The board include two ADC channels (for LTC2380-24 or compatible devices).
Note that the use of two ADC channels offer various possible system configurations like :
_ Interleaving sampling (for twice output sampling rate)
_ Parallel mode for SNR improvement
_ Separate channel for ratio calculation (Bode plot)
So, many of these configuration are only software dependent (CPLD firmware).
The serial links (SPI) of ADC are connected to a CPLD and to the clock synchronizer.
The sync block ensure precise ADC sampling from the low phase noise master clock.
The conversion can also be initiated by an isolated external clock source.
Some on-boards LEDs allow to display status, and dedicated connectors provide
test I/O and JTAG programming link.
A dedicated connector allow connection of a rotary encoder and leds for ADC control
in stand-alone mode.
The connexion to the SDR-widget or USB-streamer use dedicated connector with same pin-out
as target board and are fully isolated. The isolated side provide the isolator supply.
Another connector is used for the external digital interface (AA10M08 or others)
it provide many high-speed I/O to allow full rate ADC data transfert and also
control signal to ADC board.
This link is also fully isolated from ADC side to avoid loop and noise.
The digital interface side mus provide isolator supply.
A last connector provide uninsulated I/O for future ADC extension board.
The board is supplied with +5V and +/-12V.
All of these voltages come from low noise source.
I think it's a nearly complete board description, and that will help me to start
schematics drawing. I also started to define data I/O communication specifications
for all connectors to avoid an oversight. They will be published as soon completed.
To be continued...
Frex.
I have some doubt that, with the analogue anti-alias HF filter, the interleaving sampling will double the useable frequency range.
The only benefit would probably then be the possibility of additional digital anti-alias HF filtering.
If that is so, then with interleaving sampling the analogue anti-alias HF filter should perhaps be switched to one with appropriate frequency.
The only benefit would probably then be the possibility of additional digital anti-alias HF filtering.
If that is so, then with interleaving sampling the analogue anti-alias HF filter should perhaps be switched to one with appropriate frequency.
I think that is a good idea.
Another reason is that if you do not need an analog brick wall filter for other reasons it is surely better to get rid of it and use an problem adequate (external) filter.
Hello,
About the input anti-alias filter at the ADC inputs, it could be use or not depending on target applications,
that i hope they will be numerous.
User will be able to tune easily the filter cut-off frequency to fit it's requirements.
Edmond, If no anti-alias is desired the some passive components on the filter can be omitted.
I have no doubt that your software DiAna will fit very well with the OSVA analyzer
and will offer many attractive benefits of this hardware.
TNT, yes absolutely !
diyralf, yes it is what it would be (and more !).
Frex
About the input anti-alias filter at the ADC inputs, it could be use or not depending on target applications,
that i hope they will be numerous.
User will be able to tune easily the filter cut-off frequency to fit it's requirements.
Edmond, If no anti-alias is desired the some passive components on the filter can be omitted.
I have no doubt that your software DiAna will fit very well with the OSVA analyzer
and will offer many attractive benefits of this hardware.
TNT, yes absolutely !
diyralf, yes it is what it would be (and more !).
Frex
anti-alias filter
Cheers,
E.
I'd rather prefer a switch to bypass the filter (or at least a few jumpers on the PCB)
Cheers,
E.
Hello,
Zfe and Edmond, i can add some jumpers or maybe a small signal relay to bypass input filter if required. These parts may be omitted if direct path is not needed. That would be fine ?
About a daughter board, i don't think it's a good idea to get the best performance. I want to avoid any signal degradation caused by slotted ground plane.
Regards
Frex
Zfe and Edmond, i can add some jumpers or maybe a small signal relay to bypass input filter if required. These parts may be omitted if direct path is not needed. That would be fine ?
About a daughter board, i don't think it's a good idea to get the best performance. I want to avoid any signal degradation caused by slotted ground plane.
Regards
Frex
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.