search

sinara-hw / Urukul

4 channel 1GS/s DDS (AD9910 or AD9912 variant)
13 stars 7 forks source link

v1.5 #45

Closed hartytp closed 4 years ago

hartytp commented 4 years ago

We're preparing to order another batch of Urukuls. There are a few minor annoyances I'd like to resolve before those go to production (e.g https://github.com/sinara-hw/Urukul/issues/42). None of them are a particularly big deal, but they feel worth fixing.

So, assuming there are no objections, I'd like to propose we cut a v1.5 release shortly. I've tagged some issues for that release. I think they're all relatively uncontroversial and can be fixed pretty quickly.

https://github.com/sinara-hw/Urukul/issues/44 and https://github.com/sinara-hw/Urukul/issues/37 are perhaps the two that need the most thought. Based on prior conversations I think the solutions can be agreed relatively quickly, but I'm also happy to leave them for a future revision if that's easiest.

I haven't tagged https://github.com/sinara-hw/Urukul/issues/40 as I'm not involved in the AD9912 version. It might make sense to fix that in this release, but I won't push for it.

Ideally, I'd like to get this release ready for manufacture in the next week (ish). Please flag if you have opinions about this and don't think that timeline is reasonable.

cc @gkasprow @jordens

jordens commented 4 years ago

IMO #37 requires somebody trying it by modifying an existing board. Then we should apply that.

40 can remain open until measured. It's just a BOM change. And as explained it might also affect the AD9910.

My biggest pain point currently is the short SMA mechanics. CTI uses very thin plastic washers which tend to get pushed into the hole on the panel on the inside. TS uses the bigger ones which (with the thicker shielded panels, the multiple plastic washers, the tooth washer, and assembly inconsistencies) leave too little thread sometimes. We've notified them many times but there is no resolution. Neither approach is really complete IMO. Currently AFAICT, the connectors are as close to the inside as they can be so there is no gain to be had there. This problem is even worse on IDC-SMA and DIO-SMA (IIRC) where the connectors are not close to the panel yet.

Three more things would be interesting, sorted by priority:

hartytp commented 4 years ago

IMO #37 requires somebody trying it by modifying an existing board. Then we should apply that.

That's reasonable. Let's agree what a fix would look like first (@gkasprow can you sketch out the schematic including all components numbers). Assuming we can agree on a reasonable list of tests I think we should have hw and manpower to do this. I'm assuming we would do the tests open loop. So

hartytp commented 4 years ago

40 can remain open until measured. It's just a BOM change. And as explained it might also affect the AD9910.

Okay, I'd forgotten that it might affect the AD9910 variant as well (last I remember was "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." and, indeed, the issue title was AD9912). Am I right in thinking that the conclusion here is that (unlike the AD9910 variant) the Urukul-AD9912 schematic matches the eval board but (a) does not give the expected performance (b) does not match the intuitive model?

FWIW my personal preference is to avoid BOM changes without changing the revision number as far as possible since it can cause confusion (users see different performance from nominally identical parts). So, probably better to fix now or wait for v1.6 whenever that comes.

For the AD9910 if it's just a matter of measuring the SFDR before/after populating a 100R resistor we can do that before the next revision, but we don't have any AD9912 hw.

hartytp commented 4 years ago

DNP un-uns for the outputs.

Do you mean adding pads for DNPd un-uns at the ouput? Use-case is presumably breaking ground loops? Do you have an un-un pn in mind? Assuming it doesn't require major layout work that seems reasonable.

hartytp commented 4 years ago

A second DNP attenuator stage. 31.5 dB range is sometimes not enough. An example is higher multipole (clock) transitions. We currently use multiple Urukul channels to cover the required power range. Integrating it into the digital infrastructure would be some work. Just bringing it up, I'm ambivalent whether it's worth it.

My personal preference would be to leave this one out. I'm happy to be corrected but I feel that this could require major layout work for a relatively niche application.

Edit: but I don't feel strongly and am happy to be overruled. Open an issue if you want this done.

jordens commented 4 years ago

I'd forgotten that it might affect the AD9910 variant as well

Yes. It started as a AD9912 issue and spiraled.

Am I right in thinking that the conclusion here is that (unlike the AD9910 variant) the Urukul-AD9912 schematic matches the eval board but (a) does not give the expected performance (b) does not match the intuitive model?

Urukul-AD9912 does not match the eval board (1:1 trafo vs 1:2) while Urukul-AD9910 matches. On paper both Urukul variants and the AD9910 eval board are wrong. (I'd appreciate if someone could check this analysis, it's all in #40).

And experimentally there is 2.5 dB compression at max output. That's a bit high indicating an error in the dimensioning.

For the AD9910 if it's just a matter of measuring the SFDR before/after populating a 100R resistor

The first step would be just doing that test described in the issues. It's non-intrusive and would tell whether there is anything to be gained.

Do you mean adding pads for DNPd un-uns at the ouput? Use-case is presumably breaking ground loops? Do you have an un-un pn in mind?

Yes. Yes. TC1-1(T)(X)(+). Maybe we already use one of those somewhere. All pin compatible.

hartytp commented 4 years ago

The first step would be just doing that test described in the issues. It's non-intrusive and would tell whether there is anything to be gained.

To be clear, you mean just this

AD9910: compare wideband SFDR ASF=max and 20 dB attenuation with ASF=max/2 and less attenuation to compensate

at some test frequency (e.g. 100MHz) both before and after populating a 100R differential termination resistor where there is currently a DNPd 50R resistor? If so that's easy to do and we can do that for the AD9910.

I'd appreciate if someone could check this analysis, it's all in #40

@gkasprow what do you think about this analysis?

hartytp commented 4 years ago

@jordens I assume you're happy with the test I outlined for the phase lock?

We're up against an annoying deadline for getting this design revision sent of, so I want to make sure there is agreement on what needs to be done.

jordens commented 4 years ago

at some test frequency (e.g. 100MHz) both before and after populating a 100R differential termination resistor where there is currently a DNPd 50R resistor?

Measure output power of the fundamental and second, third harmonics at 100 MHz: (baseline) 20 dB attenuation, max ASF. Compare with (a) 14 dB attenuation and half max ASF and (b) 17 dB attenuation and 1/sqrt(2) ASF.

If trading ASF for attenuation (which would guarantee the DACs are within compliance) does not improve SFDR significantly (6 dB), then there is no point in trying to populate that 100 Ohm and the AD9910 variant is OK (IMO).

For the VCO tuning test, I'd just connect Stabilizer DAC (or just a battery for low-noise and ground-loop free) via a coax and a compact RC-RC (100 kHz or 1 MHz corner?) on Urukul to the VCO and look at phase noise degradation before and after. The DDS outputs should be fine for this. Sturdy ground connection between Stabilizer and Urukul. If it's horrible with spurs, estimate what CMRR would be required and go another step adding a diffamp. Same as your proposal. I'd just trust the datahseet on tuning range and linearity.

jordens commented 4 years ago

@hartytp when's the deadline and when do we send this? I need to decide whether to wait and change to v1.5 or push our v1.4 order that has already been delayed.

akaminska commented 4 years ago

@jordens @hartytp Hi! Regarding deadlines - China PCB manufacturer presently claims that they will re-open tomorrow. We have our PCB order hanging there. We can probably still modify it tomorrow, changing the project. If we put the order on hold, we might get pushed to the end of the queue. Hence, tomorrow is the decision time. Either we go ahaid with v1.4, change the project or put it on hold and risk further delays.

dtcallcock commented 4 years ago

A second DNP attenuator stage. 31.5 dB range is sometimes not enough. .. Just bringing it up, I'm ambivalent whether it's worth it.

@jordens I am about to design a little standalone digital step attenuator that'll be designed to plug into DIO_RJ45. Basically a version of MCL ZX76-31R5A-SPS+. I'll keep you posted.

jordens commented 4 years ago

@akaminska fully agreed. If we can't crank out a new release tomorrow, let's stick with full steam ahead v1.4 (at least for what I ordered).

jordens commented 4 years ago

@dtcallcock Hmm. Nothing against that in principle. But thinking about wiring that up (with a power supply, your LVDS-CMOS converter, that cable which reminds me of old Nokia 6210) I get a headache. ;) We have Tester. You could use that straight away.

dtcallcock commented 4 years ago

But thinking about wiring that up (with a power supply, your LVDS-CMOS converter, that cable which reminds me of old Nokia 6210) I get a headache. ;)

I'm not talking about using that MCL board but making my own that connects directly to DIO_RJ45. No Nokia cables needed.

jordens commented 4 years ago

I see. Good!

hartytp commented 4 years ago

Thanks for the input all! My position in this is:

  1. We need our hw delivered by end of March for a grant deadline (frustrating but so it goes)
  2. I would like to fix some annoyances before ordering our batch of hw, so would prefer to cut a release now if possible
  3. @gkasprow has agreed to prepare a new release this eve which will be fine for the current production run if reviewed promptly tomorrow am
  4. BOM issues (washers, baluns/ termination resistors) can be resolved after the PCBs go to production. I’d prefer to freeze the bom before boards have been shipped to customers (so when someone says “I have version x” we exactly know what they mean) but that still gives us some time
  5. The only change that doesn’t seem either uncontroversial or a bom change (which we can sort out later) is the vco tune port. There’s no way we’re going to get that tested for tomorrow (would need to order parts). My feeling is that it’s worth adding dnpd parts for it in this rev. We can always tweak as needed in a future rev but it would be good to have at least something (even just an mmcx + rcfilter) in this rev

Thoughts?

jordens commented 4 years ago

All agreed. Also MMCX+RCRC for the VCO tune port (but don't forget the added clock routing jumpers from that issue #37)

hartytp commented 4 years ago

Any objection to adding the InAmp as well assuming: we add a 0R pad so it can easily be bypassed; it’s easy to fit it within the layout? I’d like to have it there to play with.

jordens commented 4 years ago

If it is easy (no new power supplies, no significant layout crowing), sure.

hartytp commented 4 years ago

👍

hartytp commented 4 years ago

Good I think we have agreement on what we want from this release if it’s feasible within the time constraints

akaminska commented 4 years ago

Great, thanks for all the quick work! Now it is up to @gkasprow to see what is feasible by tomorrow and for us to check with the supplier if the changes won't affect the lead time.

gkasprow commented 4 years ago

the new release is here https://github.com/sinara-hw/Urukul/releases/edit/v1.5rc1

hartytp commented 4 years ago

@gkasprow many many thanks for turning that around so quickly. A few questions about the clocking but if we have to I’d be ok pressing ahead with the design as is.