-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clocker: fix grounding #1
Comments
Really, we should just use a flux-cored balun for the output isolation like in other designs. 1GHz should still be enough bandwidth to transmit a decent square wave output |
Good idea. What about TC2-72T+ 50 Ohms 10 to 700 MHz RF Transformer ? |
That seems to be about the fastest that MCL do, so yeah sounds about right... As this is a major change, it's worth giving other stakeholders (@jordens) a chance to comment before deciding |
Mostly to satisfy my own curiosity: Why go back on the earlier design choice now? I didn't check how the TC2-72T+ compares to the current choice in terms of insertion loss/bandwidth, but one thing to consider would be to keep enough slew rate to be able to cascade Clockers with little phase noise degradation even with moderate coax losses in between (the ADCLK950's jitter performance starts to degrade below 4 V/ns). |
This would kill (or at least risk) 1 GHz direct drive Urukul applications. Nobody felt the need to populate the balun (transmission line or not) there either. Is there data that says the transmission line transformers are a problem? And do we know that the loss in bandwidth does not represent one? |
I don't follow your point here. In the current release of clocker there are TCM2-43X+ baluns on all inputs and outputs. |
It's very situation dependent but, yes, I've certainly seen cases where measured clock phase noise was significantly higher than expected from data sheets and where the resolution was to add an RF isolation transformer. @dnadlinger whether that's more of an issue than the decrease in bandwidth in a particular situation is hard to tell without measurements, but I have definitely seen cases where it was. And, given that one of our major use-cases for clocker is sending our time base between labs, I wouldn't be confident saying that it's not an issue without checking. Running the numbers crudely, if we want
That's not a use case I've considered. But, yes, if people are actually using clocker at 1GHz then this balun is likely not appropriate. Anyway, I don't feel too strongly about this other than that we should not be using capacitors for isolation. |
What we can do is to make isolation transformer variant default. The output baluns were used only to ramp up the amplitude twice and to have the same rise and fall time. The xECL output stage can only source current. Balun makes the output fully symmetrical. What we can do is to have two assembly variants - one, direct output without a balun, with twice lower amplitude but higher BW (comparing with a balun). Second variant would be with fully isolating transformers, higher amplitude but 700MHz BW |
If people are worried about slew rates then we should keep the TLT as a variant. |
Both balun and transformer have compatible footprints. We can make a variant and populate one or another. |
Sure, let's just unfloat the grounds and leave it as is then. |
@hartytp before, default configuration was 100k biasing resistor and AC-coupling. |
'There' meaning urukul. |
I'm sure that it can be a problem. And in that situation you do need to sacrifice bandwidth to isolation. I'd add an external dedicated balun there. |
so what's the conclusion. DO you want 100k or 0R resistor between GND and SMA ? |
0R in my opinion. We don't do differentially floating sma like that anymore AFAICT. It made things worse on urukul in the cases I looked at. And it is dangerous/extremely annoying/unhelpful w.r.t. ground voltage differentials. |
OK, so let's close this issue |
The discussion in the wiki should probably be re-written to reflect this new school of thought. |
From @hartytp on 2018-03-28 23:31
same as Kasli sinara-hw/sinara#499 (comment)
The text was updated successfully, but these errors were encountered: