fix switch glitches

[hartytp]

Switching glitches can be fixed by adding an RC filter to the supplemental control board.

• [x] make the two resistors 1k to match the eval board
• [ ] @gkasprow please can you try a few different capacitors and find one which suppresses the glitches to a reasonable level, while still giving a decent switching speed? (We can't do this since all our Boosters are in use and we don't have a spare one for testing)

[hartytp]

Note that even with the filter there will always be some glitch that one can see if one looks carefully. So, the question is "what level of glitch is tolerable?".

My answer would be that, since no one is likely to use Booster for a device that can't handle close to 1W transiently, any glitch at Booster's output that is comfortably less than 20Vpp is fine. So, I'd try to find the smallest filter capacitor that gives a glitch around 5Vpp-10Vpp.

[dhslichter]

sigh. Is $3 per channel really worth it? Now you have half a ms delay on the interlock, probably enough in most cases, but a rather nasty surprise for those who don't expect it. Why not just make the damn thing work properly, and as people would anticipate it to? I understand the desire to avoid the expense of a respin, but in the grand scheme of things that's really not much money, and is $3/channel going to make a meaningful difference, really? It just seems like there are things worth doing right, and things one can hack and say whatever, and the power interlock switch seems like something worth doing right if the fix is simple and cheap. My two cents...

[hartytp]

half a us which is less than the other delays in the interlock assuming we switch to using an external comparator. The interlock trip time will be in the low single digit microseconds so a few hundred ns from the switch won't be a killer

[hartytp]

Why not just make the damn thing work properly, and as people would anticipate it to? I understand the desire to avoid the expense of a respin, but in the grand scheme of things that's really not much money, and is $3/channel going to make a meaningful difference, really?

@dhslichter to be clear: our goal is definitely to "make this damn thing work properly" and not to cut corners. The question is what does "work properly" mean in this context? What are your expectations about the interlock performance?

My feeling is that there are two timescales one might want the interlock to work on. Firstly, the timescale of thermal damage to sensitive devices, such as small PZTs in AOMs.

The second timescale would be to the time taken for electrical breakdown due to excessive voltage. For that, you're talking about single cycles of the RF, so an interlock response time (RF applied to switch opened) of single-digit ns. That's really tough to do and not something we achieve with this design (the switches aren't fast enough, the 74AHC logic we use to control the switch isn't fast enough, the power detector's internal comparator isn't fast enough, ...).

So, assuming we're only trying to protect sensitive devices from thermal damage, I'd argue that ensuring the interlock trips reliably in <10us will be fine. If that's our aim, then a 400ns delay from the switch (https://github.com/sinara-hw/Booster/issues/93#issuecomment-42349509)1 isn't an issue. And, as I said, in V1.2 we plan to implement the interlock using the Vrms output from the power detector and a comparator, which is never going to work in sub-us timescales anyway, so the switch won't dominate the response time.

If you still think that using the 400ns response-time switch isn't "doing this damn thing properly" then please can you spell out exactly what your expectations for the interlock are? What is your use case? What response time do you want?

[dhslichter]

@hartytp I had read the response time in the previous comments as 400 us, not 400 ns. If it's 400 ns, that's fine.

[hartytp]

ack. 400us would, indeed, be silly.