<Degi>
Is there some way to measure fast rise or fall times without a very high bandwidth oscilloscope?
<someone-else>
Degi: spectrum analyzer perhaps
<Degi>
Hmm maybe, that'd at least give an extra few GHz with what I currently have access to
<someone-else>
how fast rise or fall times are we talking about?
<Degi>
Good question, something below 900 ps (thats as low as my scope goes), theoretically minimally 2.5 ps with the current circuit (well, calculated from the current and the capacitance)
<someone-else>
well then a 100ghz spectrum analyzer should be enough
<someone-else>
do tell about this 2.5ps risetime circuit though, please
<Degi>
Just using transistors with sub-pF junction capacitances in avalanche mode
<Degi>
Like a BFP420 can have 1.6 A of avalanche current while having a C-E capacitance of 0.37 pF
<Degi>
That would cause a rise of 4.3 TV/s theoretically, which at 20 V bias would be 4.6 ps till it reaches 0 V (though with other transistors like the BFU730F it could be faster, since it only has 55 fF of capacitance, but no idea what the avalanche current would be there)
<someone-else>
nice
<Degi>
Actually in my case the avalanche current was limited by the internal resistance of an LED I think
<someone-else>
I've managed to get 15ps or so out of BFU730
<Degi>
At least the fall time on the transistor side of the LED was < 900 ps and on the capacitor side it was relatively slow (in the ns region), its derivative put the peak at about 1.6 A
<Degi>
Neat
<azonenberg>
Realistically i'm sure there there will be parasitics slowing you down a ton
<Degi>
Yes
<azonenberg>
Degi: if you send a board with SMA output my way, i can characterize out to 16 GHz
<Degi>
Though with my scope here the measurable parasitics are like the difference between directly attaching the probe tip vs using a ground cable
<Degi>
Hmm, maybe I can try making one. Any preferred SMA connectors? (I guess not the few cents a piece I found on Ebay? They might be slightly out of spec, I could get better ones with my next mouser order)
<someone-else>
these BFU transistors have SPICE models, I wonder if they model avalanche effects or not
<Degi>
Hm, in LTSpice it does not, it just shows a constant current draw
<someone-else>
MEXTRAM seems to include avalanche modelling, but dunno if the actual models have corresponding parameters
<someone-else>
anyway, these BFUxxx SPICE models proved to be useful for modelling fast circuits, sims match measurements reasonably well
<Degi>
Oh neat, thats good to know
<Degi>
Hmm, I also have some BFU730LX, which have a lower C-E capacitance and maybe a more favorable geometry
<someone-else>
including the mildly cursed 5GHz BJT probe I mentioned earlier
<someone-else>
BFU730LX also has better package parasitics compared to leaded parts
<Degi>
Hmm, I think I even did an avalanche circuit with one once, I think you could also trigger it by applying a pulse to the base over a second resistor
<someone-else>
I wonder if it would survive 1+A avalanche pulses since the DC current limits are pretty small
<Degi>
Hm yes, I mean the BFP420 seems to at a limit of 60 mA
<Degi>
(And 5.6 nF)
<Degi>
Anyways, its like 3 AM, good night!
someone-else has quit [Quit: Connection closed]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
bvernoux has joined #scopehal
massi has joined #scopehal
someone-else has joined #scopehal
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
massi has quit [Remote host closed the connection]
<azonenberg>
The best kind of race conditions are the ones involving functions which are documented as thread safe in the API docs
<azonenberg>
But are, in fact, not
_whitenotifier-e has joined #scopehal
<_whitenotifier-e>
[scopehal] azonenberg labeled issue #522: Allow user to specify a postprocessing filter for de-embeds - https://git.io/JMCvP
<_whitenotifier-e>
[scopehal] azonenberg opened issue #522: Allow user to specify a postprocessing filter for de-embeds - https://git.io/JMCvP
<_whitenotifier-e>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JMaBG
<_whitenotifier-e>
[scopehal] azonenberg 5c71799 - LeCroyOscilloscope: fixed bug causing one garbage sample at end of waveform
<_whitenotifier-e>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JMo0S
<_whitenotifier-e>
[scopehal] azonenberg e695e8c - Added mutexing around allegedly thread safe clfftBakePlan() calls because it's not actually thread safe as documented...
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
bvernoux has quit [Quit: Leaving]
<_whitenotifier-e>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JMKUL
<_whitenotifier-e>
[scopehal-apps] azonenberg 7f552e4 - Single thread per pixel OpenCL renderer works for simple test case
<_whitenotifier-e>
[scopehal-apps] azonenberg 3323a0f - OpenCL waveform rendering kernel can now multithread. Still pretty basic and doesn't handle a lot of paths yet.
<azonenberg>
Ok so, at certain zoom levels it fails and i'm not yet sure why
<azonenberg>
It only works for dense packed analog waveforms
<azonenberg>
i.e. no sparse analog, no digital, no histogram
<azonenberg>
And it's slow because some of the OpenGL path is not disabled when using it (e.g. waveform memory gets copied to the GPU twice)
<azonenberg>
But the beginnings of an OpenCL renderer are at least vaguely alive now
<azonenberg>
When i'm done with it i will be backporting several improvements into the compute shader renderer
<azonenberg>
which might be responsible for some of the hangs we have on some platforms
<azonenberg>
in particular it seems we have some barrier divergence
<azonenberg>
i.e. not all thread in a group hit a memory barrier under some conditions