AD9912 resistors/balun

[jordens]

The eval board uses a 2:1 balun and no resistors. We use a 1:1 balun and no resistors. This is probably wrong.

also c.f. #39

Context

• 43 for the original discussion

1. Measurements indicate about 2.5 dB compression (and corresponding distortion and harmonics) when scanning amplitude scale at 0 dB attenuator setting. On paper should only see 1 dB compression from the amplifier. When scanning attenuation at full scale output there

2. With -40 dBc at 12 dB attenuation and 400 MHz (AD9910) and -47 dBc at 5 dB attenuation and 80 MHz (AD9912) and we are quite a bit worse than the datasheet value (-52 dBc 400 MHz AD9910 and -70 dBc 90 MHz AD9912).

AD9912

each output: 20 mA FS current source, 0.5 V compliance, 50 R internal termination

eval: no resistors, 2:1 trafo (high impedance 100 R secondary impedance on DAC side) into 50 R SE, consistent

Urukul: no resistors, 1:1 trafo into 50 R SE, inconsistent

AD9910

each output: 20 mA FS current source, 0.5 V compliance, no internal termination

eval: 50 R each output, 1:1 trafo into 50 R SE, nominally inconsistent

Urukul: 50 R each output, 1:1 trafo into 50 R SE, nominally inconsistent

On paper

On paper, for a 1:1 transformer and 50 R single ended load, each DAC current output needs to be terminated with 25 R before the balun. The AD9910 eval board is incorrect on paper and the AD9912 is correct (but uses a 2:1 balun). Required changes would be:

• Urukul-AD9912: populate the one 100 R diff (or populate the two 50 R resistors)
• Urukul-AD9910: populate the one 100 R diff

This would kill about 3 dB power to the load and result in -2 dBm out of the transformer. One could then change the 9 dB pad IC17 to 6 dB to compensate. On the plus side this should then significantly improve THD/SFDR/OIP2/OIP3.

Test

• AD9910: compare wideband SFDR ASF=max and 20 dB attenuation with ASF=max/2 and less attenuation to compensate
• AD9912: compare status quo with added 100 R termination and 6 dB pad instead of 9 dB: SFDR/THD/OIP2/OIP3.

[dhslichter]

In my experience, both the impedances of the baluns and of the DDS/DAC outputs are not flat over the whole desired band, nor are they exactly what the nominal spec would be, and so the performance is reasonably tolerant of these kinds of substitutions. In fact, different choices provide improved performance at different frequencies. I'm basing this on both output power as well as on return loss measured with an NWA looking into the output of the DDS when it is powered on and running. I think one has to actually perform a measurement to determine which configuration is better for the desired application, rather than relying on theory.

[jordens]

You need to rely on a decent theoretical understanding before doing measurements. Otherwise you have no idea what to measure and how to interpret the data other than handwaving. Using the eval board design as a substitute for own optimization tends to be a really good idea. If something is already wrong on paper or compared to the eval board, it is pretty likely to be problematic in practice as well.

[gkasprow]

Let's make simulations with S-models of all components before changing anything in the circuit.

[dhslichter]

You need to rely on a decent theoretical understanding before doing measurements.

Agreed. This usually requires using measured S-parameters of components (from vendors), rather than assuming ideal components, though. One of the issues is that it is often hard to find S-parameters for things like DAC outputs that can be plugged into simulation software.

[hartytp]

While there may be some room for improvement (there always is), there are now enough Urukuls out there that, on reflection, I'd prioritise minimising changes over marginal design tweaks.

Closing this now, anyone else can feel free to reopen if they want to pick it up again.

[jordens]

This is not a subtle design tweak. It's a bug. It contradicts the on-paper solution. It contradicts the datasheet. It contradicts the eval board. It contradicts the nominally identical alternative variant.

[hartytp]

Is it a bug that has adverse consequences for users or just an in-theory one? What are the adverse consequences?

some context here: we're planning to place another large HW order in the next few weeks and i'd like to do a little house-keeping before that by fixing known issues. So, if we are going to do anything about this then it's worth aiming to do it this month (if not then when?). So the question is whether this is serious enough that anyone is willing to put the time/energy into fixing it. Otherwise, is it worth keeping the issue over if this is really a "won't fix". Unfortunately I won't have the time/hw access to test out a new solution, so someone would else would need to lead this.

Having said that, if your suggestion is really just "follow the reference design" then I'd consider that a low-enough risk that we can probably move forward without prototyping first...

[jordens]

You have so far been exclusively interested in the AD9910 variant. This bug or its fix won't affect you. The most likely fix is a simple BOM change for the AD9912 variant. Why do you feel irritated or hindered in your work or even forced to test or measure anything? The measurements of the impact of this and the choice of solution will happen independent of what you do with your large hardware order. And what makes you think you are in a position to set a ~6 hour deadline for me to address this? What's wrong with you?

[hartytp]

You have so far been exclusively interested in the AD9910 variant. This bug or its fix won't affect you. The most likely fix is a simple BOM change for the AD9912 variant.

Oops, sorry misread/misremembered and had thought this was AD9910. In that case it's not an issue for me as you say -- although if we are going to put out a new release it makes sense to try to fix all the issues in one go, but it's not something I feel strongly about.

Why do you feel irritated or hindered in your work or even forced to test or measure anything?

I'm not irritated in the least. As I said, just ticking off some beginning of year housekeeping.

And what makes you think you are in a position to set a ~6 hour deadline for me to address this? What's wrong with you?

Woah! Where are you getting that from. I said "if we are going to do something about this it's worth aiming to do it this month" how do you get from that to me setting you a 6 hour deadline?

...edit: oh, I see, it's still December by a few hours. I mean January as I'm already mentally in the New Year. If something seems that unreasonable then it's usually a mis-communication...

The measurements of the impact of this and the choice of solution will happen independent of what you do with your large hardware order.

Sure. As I said though, where possible, it's nice to fix as many issues as possible in each design revision to avoid huge numbers of different PCB/BOM revisions. It's not a big deal though

[jordens]

Woah! Where are you getting that from. I said "if we are going to do something about this it's worth aiming to do it this month" how do you get from that to me setting you a 6 hour deadline?

This month ends in a few hours. You posit that it should be done by then and if not then you want a time table.

[gkasprow]

what's the decision here?

[jordens]

Speaking for the AD9912, please populate the 100 R differential R8.

[jordens]

For reference some some insight into the ADI reasoning for the differences between AD991[245] w.r.t. AD9910.

[gkasprow]

ACK

[gkasprow]

it was fixed in v1.5.1

[ghost]

quick question here why does urukul ad9910 use balun with 75 ohm impedance isn't dac impedance of ad9910 is 50/port so why not use 100 ohm balun (1:2) ?