EEVblog #709 - EDC 4601 AC Voltage Standard Teardown

[tchicago]

Looked at the power amp schematic. Wow, the output is weird: it is actually the central point of the power supply. Whereas the push-pull MOSFETS "drive the ground", so that the central point of the power supply will fly up and down

Why is it made this way? I think this alone may deserve a whiteboard video episode.

[djQUAN]

Regarding the caps on one of the output mosfets,

Rod Elliott's P101 mosfet amp design (http://sound.westhost.com/project101.htm) uses the same devices and also used the capacitor trick. It was done to compensate for the gate capacitance as the P channel part has a much larger capacitance than the N channel complement.

The capacitor will be in around a couple hundred pF in value and when added in parallel with the N channel gate capacitance, the total will be close to the P channel gate capacitance.

The output stage is similar to the old QSC amplifiers (see attachment) The main filter capacitors are also used as a sort of DC blocking capacitor so that a failure of an output device will not result to a huge DC voltage on the speaker output (output transformer primary in this case). This also lessens the need for a very low DC offset power amplifier stage as the output is AC coupled and will not introduce a small DC voltage across the output transformer primary.

[Smokey]

Dave said "...sort of "HP 200" oldschool, used in a light bulb, as the main stability element in your oscillator." - what device do you mean?
I'm very interested in unusual sollutions. Please more info about this stability elemnt (which EEV Blog number(?) or something).
Very nice video BTW I like "rare" gear tearing down.?

http://cds.linear.com/docs/en/application-note/an43f.pdf

Page 32.  Jim Williams replaced the bulb with a VACTEC VTL5C10 in his wien bridge

[EEVblog]

The 25 fps video looks cleaner, but there isn't much movement so it's hard to really compare.
I think it's YouTube encoding that is doing it. I don't know how you can fix it, other than drop the 50fps video which understandably toy don't want to.

I see no noticeable difference between detail in my original rendered video file, and Youtube at 50fps 1080p (shift print screen capture).
I used the Agilent meter front panel shot as a test.
When I flick between them it's very hard to see any detail difference. Slight brightness difference because not exactly the same frame, but no real loss of detail.
Had to convert from PNG to JPG to upload

[EEVblog]

The 25 fps video looks cleaner, but there isn't much movement so it's hard to really compare.
I think it's YouTube encoding that is doing it. I don't know how you can fix it, other than drop the 50fps video which understandably toy don't want to.

Sorry, but I think it's a problem at your end somehow. As just demoed, at my end I cannot see the difference. Youtube is not losing detail from my original at 50fps as captured on my machine.

[EEVblog]

And the original capture from inside Sony editor.
Essentially no difference in detail at all. if you can spot anything serious you have better eyes than I do.

[allikat]

Never ask an engineer to check something unless you want a complete answer 

Nice work looking at the YT renders Dave. Youtube render differences may be caused by YT going for full on HTML5 recently, which would mean it's now not using that *insert technical engineering curse here* Adobe Flash.  A thread on Reddit ( https://www.reddit.com/r/chrome/comments/2bmxpp/youtube_html5_vs_flash_player_performance_cpu_and/ ) has looked into the change, and found that the current YT player may not use the GPU for acceleration, since the GPU will often do some colour tweaking as part of that render, and a CPU based system won't usually, you may well notice some differences depending on your precise setup.

[hikariuk]

Never ask an engineer to check something unless you want a complete answer 

Nice work looking at the YT renders Dave. Youtube render differences may be caused by YT going for full on HTML5 recently, which would mean it's now not using that *insert technical engineering curse here* Adobe Flash.  A thread on Reddit ( https://www.reddit.com/r/chrome/comments/2bmxpp/youtube_html5_vs_flash_player_performance_cpu_and/ ) has looked into the change, and found that the current YT player may not use the GPU for acceleration, since the GPU will often do some colour tweaking as part of that render, and a CPU based system won't usually, you may well notice some differences depending on your precise setup.

If you right click on the video in Chrome you get an option for "Stats for nerds" which will tell you what acceleration it's using, if any.

[ludek]

http://cds.linear.com/docs/en/application-note/an43f.pdf

Page 32.  Jim Williams replaced the bulb with a VACTEC VTL5C10 in his wien bridge

Thanx   Page 28 shows also configuration, that's interesting solution.
I have one more question about what Dave said. What is this HP200 thing? Is this a device model? Or electronic part number?



BTW I've watched this episode in 1080p quality and 25(or 30?) FPS mode and the quality is more than good. No compared to other framerates.

[EEVblog]

If you right click on the video in Chrome you get an option for "Stats for nerds" which will tell you what acceleration it's using, if any.

Mine just showed 37Mbps bandwidth for one of my 1080p50 videos!

[EEVblog]

Thanx   Page 28 shows also configuration, that's interesting solution.
I have one more question about what Dave said. What is this HP200 thing? Is this a device model? Or electronic part number?

The product that started HP:
http://www.hp.com/hpinfo/abouthp/histnfacts/museum/earlyinstruments/0002/

[hikariuk]

If you right click on the video in Chrome you get an option for "Stats for nerds" which will tell you what acceleration it's using, if any.

Mine just showed 37Mbps bandwidth for one of my 1080p50 videos!

I think DASH uses as much bandwidth as it can - it dynamically adjusts the quality of the video based on the throughput it's getting.  That may be why some people are perceiving lower quality videos: their connections aren't up to snuff.

(http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP)

Just noticed the HTML5 player doesn't actually show you the acceleration info either; that only comes up for the old Flash videos.

[EEVblog]

I think DASH uses as much bandwidth as it can - it dynamically adjusts the quality of the video based on the throughput it's getting.  That may be why some people are perceiving lower quality videos: their connections aren't up to snuff.

That makes sense. Nothing wrong at my end at all.
It wouldn't be sensible for me to go back because of a few complaints. Youtube is always changing it's compression and delivery of content, always has, always will it seems. Content producers shouldn't go chasing the Youtube tail, you'll never win.

[hikariuk]

Here is an unmodified comparison shot from 18:14, right hand side of the frame:



You can very clearly see that the 1080p25 shot is lower bitrate and recompressed. There is less fine detail.

Erm, I actually can't see any difference between those two images.

[Andy Watson]

Erm, I actually can't see any difference between those two images.

Neither can I

[c4757p]

They look slightly different to me, but neither looks better.

[Fungus]

kilobyte = 1024 bytes (JEDEC standard)
kibibyte = 1000 bytes

Ummmm...no.

[hikariuk]

kilobyte = 1024 bytes (JEDEC standard)
kibibyte = 1000 bytes

Ummmm...no.

Yeah.  Wrong way around.

[elgonzo]

Ummmm...no.

Ummm...yes?

Yes, and no

JEDEC kilobyte = 1024
SI kilobyte = 1000
kibibyte = 1024

[Quarlo Klobrigney]

Dave, please wash your hands. Here in Florida, I am all to well acquainted with those splotches in the power supply. They look to me to be all of the residue of cockroach shit. They like the warmest part of a piece of electronics, i.e. the power supply, output sections, resistors and displays. I not saying that is what you have there, but it sure looks like it. Wear some gloves as cockroaches carry disease, and clean that crap out of there.
Otherwise good video and nice piece of kit from the old days with engineering that was good enough. "We don't need no stinking software. Why in my day, everything was analog and will still be analog. This digital stuff is just a fad." Apparently what the engineers say at that company that built that thing.

BTW, I always thought that Vactrols were a linear analog pot. Some of the uses I put them to were in audio limiters and compressors. Of course now that can all be done in silicon and software.

[funkyant]

most of your work is largely static shots, so surely it makes sense to prioritize image quality over motion quality? 50fps adds basically nothing, while subtracting substantially.

The streaming encoder only updates blocks of pixels where there is a change detected between frames. A still image at 10 billion fps will use pretty much the same bandwidth as a still image at 25 fps. This is how VBR works.

However, when there is motion involved such as panning, other vector algorithms come into play. For example in a slow panning image, the codec will extrapolate groups of pixels moving linearly in a particular direction and simply use vectoring to move them, and only redraw new information coming into the frame. Again, higher framerates don't really affect bitrate, because although there are more frames, each frame introduces less information, and this ratio is directly proportionate (however there is some overhead in front/ back porch and the like).

Even on a cut frame between two completely different frames of high complexity, the bandwidth required is a factor of resolution, not so much framerate. The only time this is not true, is if the cuts are happening faster than the base framerate (25fps in your example). An instance this might happen is if you shot 60fps random noise on a scope screen compared to 25fps - then you would eat into bandwidth and resolution would most likely be compromised.

BTW this is what they mean when you hear temporal algorithms mentioned with regards to video codecs. The encoder is looking ahead and comparing frames and subdivisions of frames (referred to as blocks) classifying their 'behavior' and then going back and marking the blocks accordingly as they are drawn so they can be handled in the most efficient manner. These days the algorithms are so complex that they are nesting blocks within blocks, so you can have a large block with vector movement, which then has a sub section which is being refreshed with new information as it's parent block is vectored across the screen. Ah, my head hurts now...

Watch your software when it's rendering (or encoding) and see how quickly it smashes through still images and slow pans, compared to cuts and very fast pans. The codec only updates what it needs to. The look ahead is also a part of the reason why the progress bar gets to the end before the render is actually complete.

Uncompressed formats update every frame in its entirety, every time, even if two adjacent frames are identical.

[EEVblog]

Here is an unmodified comparison shot from 18:14, right hand side of the frame:

You can very clearly see that the 1080p25 shot is lower bitrate and recompressed. There is less fine detail.

Nope, I can't see any difference at all.

[EEVblog]

Here is the 1080p25 stream:
I can clearly see the difference, it's heavily recompressed. To help show how bad it is I have enhanced the noise.
You can see that there are a lot more compression artefacts. All settings for the image processing are the same on each of the three images:
Maybe it isn't so noticeable on a crappy computer screen. My 60" TV makes it very obvious.

Let me see if I get this straight. Your complain is only that the 25fps video youtube is delivery (from my 50fps source) is worse than my original 25fps uploaded content?
BTW, how can you know this when you don't have a the exact same clip uploaded in 25fps, and 50fps?

[EEVblog]

Also look at this area:

It looks flatter and smoother on the right. It's almost as if someone moved the light source so that the ridges are less pronounced. In the right hand image there are areas of solid colour where the image is over-compressed as well, where as on the left those parts still have subtle gradients. The eye is very good at recognizing when things look wrong like that, even if you are not entirely concious of it. The images just look worse, as others have said. The eye expects a lot of detail, not a flat block of colour.
Also notice how the diagonal line above the red box is less well defined on the right. The edges are a tad fuzzier.

You're kidding right?
This is your example of the quality difference you are complaining about? Seriously? 

[EEVblog]

Look at the bottom left of each image. The marks are more pronounced on the left hand side.
Now look at the left hand side from about the mid point to the top, where there is a gradient from dark to light. On the right there is much more banding, where as on the left it is a smooth transition.
These are classic signs of recompression and make the image look less detailed.

Of course it will be recompressed! This is what Youtube does, it re-encodes everything that gets uploaded, and it's always re-encoding and changing the compression and quality of content in the background without anyone knowing, based on what new wizz-bang technology Youtube has this week.