Behringer UMC 202HD for measurements

And another pair of pictures with and without 48V boost powered.
This time the output knob is at max. The output distorts.
I just did some quick tests on this: I have a similar spike around 24kHz in mine.

If there's an easy way to just disable the booster for the Phantom power via a switch, do let me know, I'm game to try some mods on this to improve it for measurements.
 
I cut the phantom boost power supply. The boost IC is LM3488 in my device.
Just cut the trace and put a switch.
bhrg_ph_pwr.png
 
Thanks a lot, @Remedy, this is awesome.

I am not sure I can fix all issues with mine: I did some tests today and there is a lot of noise depending on pot positions. Some of this is already known: overload of ADC, so Input Gain can't be too high, distortions induced by output gain too high as well but I also do get clicks and I am not sure it's a buffer issue.

I might have a defective unit. I bought it second-hand for cheap from a guitarist so I don't expect too much here but I got some clicks every few seconds or so. I tested this using ASIO4ALL and R.E.W. Additionally, there seems to be a harmonic around 24K all the time. And I also saw that when R.E.W. is open, if I am watching a Youtube video for reference, the unit and/or the driver goes haywire.

The Cal. procedure is a lot more complicated because you need to put these pots down but then the level can be too low for precise results in the software. I get varying levels of difference between the signal and the noise floor, it doesn't seem as good as some of the pics I saw.

Do I understand @MagicBus 's info up to now properly?: the change of resistors caused some op amps to die so that's not recommended and we could gain on specs here by getting at least 5V to the unit, but the Vcom rewire was a good mod.

Direct IN is also a cool one for me, I was looking at doing this.

It would be really cool if we could rationalise the Input Gain and also the Output Gain effects.

I also noticed that these pots would unbalance the audio at the headphones out while monitoring. The Headphones Volume Pot does that too. This might be wear-and-tear or maybe this can be improved upon in circuit.

There's horrible and audible distortion on the headphone outputs when I reach around 2 o'clock. This is a known issue as well but it would be great if we could fix this.
 
Let's try to put all this in one order. The digital converter - audio codec - as implemented in this soundcard, is fine to reach full scale at 0dB and only there it would clip. What we see as clipping at lower levels comes from the input buffer. It can only do around -17dB at factory status and go up to -8db with my risky mod. If we push input signal to go higher then the opamps are forced to exceed the power supply rails and they deliver the spirit. It would take more than 5V to cure this. In my diy souncard I used +/-8V with different opamps of course. Regarding the output, I suppose the same should apply. I used it with the interface mentioned earlier so additional amplification relaxed the necessity to crank up the output vol control. Moreover, headphone output worked fine all the way up a few times I tested it but I happen to have 600 ohm headphones i.e. an easier load.
 
After yrs of fiddling with soundcards I came to the conclusion that it is preferrable not to rely on a calibrated soundcard with levels referred in dsBVrms - but better use a scale with dB FS. Once I know the sweetspots of my soundcard I can adjust quickly output and input levels to best performance. This is especially helpful when comparing to older plots where the exact test-setup is unknown. Measuring absolute rms-levels is done with a good true rms meter.
 
OK, I've been through the thread again, so Step 2 isn't recommended as first posted. The more recent experiments you did was for a little while because you then went onto the design of a new soundcard instead.

Check the unit I have. It is misbehaving at around 24k and 48k and distortion is also very high:

Capture1.jpg


What could be the cause of this? I've tried a few different capture formats, but these are still there although their extent can vary some.

As is, it doesn't seem worth doing the mods on this one if these glitches are still there.
 
Sometimes quirky plot responses can be due to USB and PC activities going on in the background, as they are part of the 'measurement loop' with respect to REW getting the PC to send and receive data through its drivers and USB hardware. Sometimes that may be other background processes going on with the PC or other USB activities for other devices. Similar to ground loops and other ways that a measurement result can be corrupted, you need to either work out how to minimise those quirks (eg. minimise all PC background and USB activities, and/or make many measurements to get a good one), or just disregard them as an 'unreal' quirk with respect to the test result you want to confirm (ie. the spectrum response is the 'smoothed' line without the glitches).

I have an EMU0404 which has one channel that includes some glitches (a well known issue that can be alleviated by some internal rewiring) so I just don't worry about those glitches as I know what they are from.
 
Sometimes quirky plot responses can be due to USB and PC activities going on in the background, as they are part of the 'measurement loop' with respect to REW getting the PC to send and receive data through its drivers and USB hardware. Sometimes that may be other background processes going on with the PC or other USB activities for other devices. Similar to ground loops and other ways that a measurement result can be corrupted, you need to either work out how to minimise those quirks (eg. minimise all PC background and USB activities, and/or make many measurements to get a good one), or just disregard them as an 'unreal' quirk with respect to the test result you want to confirm (ie. the spectrum response is the 'smoothed' line without the glitches).

I have an EMU0404 which has one channel that includes some glitches (a well known issue that can be alleviated by some internal rewiring) so I just don't worry about those glitches as I know what they are from.
For this kind of troubleshooting the intrinsic oscilloscope can be very helpful. In my case it showed disrupted output signals caused by buffer-overflows.
 
OK, I've been through the thread again, so Step 2 isn't recommended as first posted. The more recent experiments you did was for a little while because you then went onto the design of a new soundcard instead.

Check the unit I have. It is misbehaving at around 24k and 48k and distortion is also very high:

View attachment 1013308

What could be the cause of this? I've tried a few different capture formats, but these are still there although their extent can vary some.

As is, it doesn't seem worth doing the mods on this one if these glitches are still there.
I'm not sure if I can help but here are my thoughts anyway... Although this soundcard has a sampling rate up to 192kHz it doesn't perform well in the ultrasonic range above 22kHz. This is due to the audio codec specs and it cannot be improved. Have you checked it at 48kHz in a window up to 20kHz? Things should be much better and still very useful for audio.
 
And another thing I just remembered. In my other soundcard project when power on from cold, there is a small bump -not peak- on the noise floor starting from around 10kHz or so and moving slowly to ultrasonic. After five minutes it has move out of sight and stays there. Only thing common between these two soundcards is the audio codec.
 
And another thing I just remembered. In my other soundcard project when power on from cold, there is a small bump -not peak- on the noise floor starting from around 10kHz or so and moving slowly to ultrasonic. After five minutes it has move out of sight and stays there. Only thing common between these two soundcards is the audio codec.
And you should check sample rate as well. 44.1kHz is the best bet with my EMU-Tracker. All other sample rates from 48kHz upto 192kHz yield worse THD+N performance.
 
I did some checks again tonight. There seems to be some driver problem on top of the hardware issues: I needed to disable all other sound devices, uninstall all other drivers and re-installed the penultimate official Behringer driver, perform a restart and then I managed to get a somewhat stable configuration.

My distortion levels still seem way too high though.
 
I did some additional tests for sample rates and up to 96kHz, I get 0.040% THD with ARTA. 192kHz is an order of magnitude greater.

Definitely a good idea to both check this and also window and/or filter the responses.

Quite suprised at how many additional harmonics the MIDAS preamp adds. I speculate but I suppose this just shows that someone from MIDAS designed it but it's not the actual MIDAS preamp in their top mixing consoles.

Spikes at 24k and 48k are always there, and some intermodulations appear around these as well with test signals.

It will be interesting to do two of MagicBus's mods and see what happens.
 
Forgot to mention the disabling of the Booster circuit as @Remedy did is a worthwhile mod too.

YashH.

Tell me, do you have the same giant 50Hz spikes as i do with mine Behringer umc-202-HD.
- Also is your'e Behringer also so overly sensitive to main's hum as mine ?
I have them even through i use the "direct in" mod.

I read in a thread over at ASR that the reviewer gave up testing this unit duo to main's hum?

Jesper.
 
do you have the same giant 50Hz spikes as i do with mine Behringer umc-202-HD.
- Also is your'e Behringer also so overly sensitive to main's hum as mine ?
I have them even through i use the "direct in" mod.

I read in a thread over at ASR that the reviewer gave up testing this unit duo to main's hum?

I always see a spike at 24k AND another one at 48k (so high freq).

Haven't seen much in the way of main-related hum yet. That's probably because the last few tests I did while sitting with my laptop and the audio interface on the couch.

However, I have read that someone found that the unit could be susceptible to interference from mains wiring nearby, so you could move it around and re-test and see if that changes anything, or enclose the unit in another box to provide some additional shielding and re-test.