Right now we have a very narrowly defined problem. An oscillator, passive notch, and gain of 40dB buffer run on batteries and double shielded should be able to verify the performance of the oscillator with almost any sound card. Yes this instrumentation is single purpose and has zero flexibility or generality. It also requires some user sophistication.
Almost my setup. I use a lock in amplifier to look at the 2nd & 3rd (Optionally 4th & 5th) harmonics. Easy to lock as the oscillator frequency is derived from a master clock as are the lock in multipliers.
I differ from the other designs as I use Wien filters for the fundamental and as harmonic cancelers. Small tuning R changes the phase. Only do the first 5 harmonics. Very fixed frequency.
My conclusion so far is to use IM testing, much easier and although the numbers aren't the same distortion products it tracks circuit changes and way easier to measure.
The question will rise:
- how good is your notch in terms of added harmonics
- the notch should have no much or no 2. Harmonic attenuation
- the notch and LDO freq. will go apart (temp & age & used components as a trimmer)
- connections & cables will also be an important factor
- even a 80dB notch will stress your "almost any sound card" 😀
Look my drawing...
Hp
Attachments
This arises with any instrument, what's the point? The attenuation at the 2nd is irrelevant, the active notch to eliminate it adds another op-amp and its possible distortion. AP, Shibasoku, all suffer from the same amplifier, component issues, can you suggest a fundamentally different approach we are all ears. 80dB notch gives you -70dB for -150dB floor not many sound cards are that bad.
As Samuel showed passives at the -160db level for 1V rms are not that hard to find so just eliminate as much else as possible. I just threw out 40dB 60 works too.
Last edited:
Since I don't have one of Dave's oscillators that would be difficult. As for the basic physics of how things work, I figure that is not necessary. Does a 1k Ohm resistor have 4nV/rt-Hz noise if I don't measure it?
The analog circuits have a known phase noise (bell) around the fundamental.
May the latest ESS DAC ES9038Pro may help in this regard...
Hp
Guys do you think this is enough USB bandwidth to pipe data from a convertor?
It's 400 times more than what's needed for two channels of 192kbps audio data.
This is one of Microchips 32 bit micros in MZ series. Runs at 200MHz.
There are some better, new ones that run at 252MHz.
It's 400 times more than what's needed for two channels of 192kbps audio data.
This is one of Microchips 32 bit micros in MZ series. Runs at 200MHz.
There are some better, new ones that run at 252MHz.
Attachments
Yes I know. It was a rhetorical question. This with no overhead.
Once processing of incoming data is added in I won't see this kind of bandwidth but it is doable for our needs.
I will proceed to the next stages.
Don't count on it. Bulk transfer is not isochronous. It can be stalled by a mouse click and you can lose a frame. All of the USB audio implementations using bulk transfer are history now. You can do bulk transfer if you do it like Quantasylum. That means loading the data into a big buffer and moving it all as a piece independent of timing. That's not so hot if you need to do continuous processing and load the data into a large file on a PC.
There are several USB audio chips that can handle data at high rates using UAC2 which means the data is at highest priority and time critical. Both XMOS and CMedia are basically ready to roll. You can roll your own stack but I think you have better things to do with your time.
You can get XMOS and CMEDIA interface boards from China cheap. The XMOS firmware source is all available and you can reflash the China modules.
Am I missing something about this application?
(FWIW there is progress on an ASIO driver for the QA401)
There are several USB audio chips that can handle data at high rates using UAC2 which means the data is at highest priority and time critical. Both XMOS and CMedia are basically ready to roll. You can roll your own stack but I think you have better things to do with your time.
You can get XMOS and CMEDIA interface boards from China cheap. The XMOS firmware source is all available and you can reflash the China modules.
Am I missing something about this application?
(FWIW there is progress on an ASIO driver for the QA401)
I agree that you are better off using XMOS or CMedia chips. If you want to DIY it, I would personally just implement a UAC2 driver on an STM32 MCU. There are some partially working examples floating around. I never gave it a serious look because the STM32 I2S peripherals are limited to 192 kHz last I checked.
On the USB, if you're getting increased latency or other issues with bulk with a mouse click there are other problems with your system. I know you might not mean that literally, though. Isochronous and interrupt transfers buy you only two things; guaranteed latency, and yes, some freedom from bus contention because of the reserved portion of the frame.
In practice, you could do audio very well over bulk but you would never be able to guarantee latency that would satisfy pro audio guys. I am not familiar with older products that used custom bulk interfaces for audio, but I am sure it could be done based on other work I have done with USB. This is sort of analogous to streaming video over TCP vs UDP. Pipes are fast enough now that streaming video via HTTP over TCP is just fine.
One pitfall developers might run into when targeting Windows and going the custom route is the user-mode WinUSB API which has poor performance unless you use it in certain ways. Convenient, but best avoided if performance and latency are important.
2 channel ADC + 2 channel DAC and 1 MHz analog bandwidth:
(2 + 2) * 3 Byte / Sample / 5 MSamples = 60 MByte / second without overhead
...assuming you do all the FFT and calculations on the PC
Udo
(2 + 2) * 3 Byte / Sample / 5 MSamples = 60 MByte / second without overhead
...assuming you do all the FFT and calculations on the PC
Udo
Last edited:
Actually that goes back to my question; what is the application?
In PC's and other hosts there is a tendency to share the USB I/O with many devices. If you find like on a RPI that the network is shared on the only USB host interface you have potential problems.
Sent from my LG-H811 using Tapatalk
In PC's and other hosts there is a tendency to share the USB I/O with many devices. If you find like on a RPI that the network is shared on the only USB host interface you have potential problems.
Sent from my LG-H811 using Tapatalk