<d1b2>
<j4cbo> some common 48v-nominal rails are actually 57v - in particular, 802.3bt PoE specifies 52.0-57.0
<Bird|ghosted>
yeah, 48V is where the gap between "nominal rail voltage" and "lead acid charge voltage required for that nominal rail voltage" really becomes significant
<azonenberg>
very WIP, only the first section or so is mostly done
<azonenberg>
I plan to offer this as a half-day in person class at my place once the covid situation improves a bit, consisting of both lecture and lab components
<azonenberg>
the lecture materials will be published in some form, i may or may not actually film the class
<azonenberg>
the scope screenshot shows loading of a 10x passive probe on a DUT, as compared to the original signal
<azonenberg>
And the glscopeclient view is my mathematical model of the probe loading (slightly transformed VNA measurement of the probe's S11) applied to a unit step
<azonenberg>
Which looks... pretty close
<azonenberg>
This puts me one step closer to being able to back out probe loading from a measurement
<azonenberg>
so I can not only de-embed the forward path gain of the probe (seeing what the signal at the probe tip looked like *when i took the measurement*)
<azonenberg>
I will also be able to de-embed the probe loading response, seeing what the signal at the probe tip *would have looked like without the probe*
<azonenberg>
This of course doesn't avoid any heisenbugs caused by you introducing glitches and non-monotonic edges with the probe, as shown here
<azonenberg>
but if you don't distort the signal enough to change the DUT's visible behavior, you can at least get a better view of signal integrity by removing the probe loading
<ericonr>
I think they apply mainly for the part about releasing the slides online, separate from the course, since most of the points can be explained during the course itself
<ericonr>
my comment about slide 32 might also be wrong, but I think it isn't :p
<electronic_eel>
azonenberg: re your probing slides - what is the expected audience? are they expected to be familiar with a vna, s11, s21, but don't know details about scope probing?
<electronic_eel>
it is a bit hard for me to imagine that group. usually you have some experience with scopes and other gear before you begin using a vna
<electronic_eel>
another example for rc-probe loading you could show is an crystal oscillator: measure the output frequency without probes, then touch the rc probe on one of the pins of the crystal
<Degi>
Or maybe a LC oscillator
someone-else has joined #scopehal
someone-else has quit [Quit: Connection closed]
<azonenberg>
electronic_eel: yes that will be part of the lab
<azonenberg>
measure with an active probe then the rc probe
<azonenberg>
electronic_eel: I'm probably going to include a short s-parameter primer at some point
<azonenberg>
specifically because a lot of people might not have that background
<azonenberg>
But yeah, the point of the lab is going to be working through a bunch of real world examples of using different kinds of probes
<azonenberg>
The other thing i'm going to do is sneak in the Pico TA061, the awful transmission line probe with heavy loading
<azonenberg>
not tell them what it is
<azonenberg>
and ask them to, based on studying its behavior, figure out what it is and what the major non-idealities are
<electronic_eel>
oh, about the heisenbugs: there is another category: it does not work without probing and does not work with probing too - but probing adds a completely different kind of failure mode. so you might go hunt a completely unrelated problem
<azonenberg>
Got a good example of that?
<azonenberg>
one thing i want to try and do is design a system where the glitch introduced by the R-C probe on a fast edge breaks it
<azonenberg>
then instrument the whole thing with a better probe and let them watch the heisenbug happen
<electronic_eel>
for example when you probe the crystal oscillator and that causes the oscillator to stop oscillating at all
<azonenberg>
Oh, yeah good point
<electronic_eel>
if the oscillator is affected by this depends on the phase reserves the circuit has. you can deliberately reduce the reserves by adding a resistor in the path between output and crystal
<electronic_eel>
this resistor is often there to limit the power that the crystal is driven with to prevent damage. but you can further increase it
<azonenberg>
ooh i like it
<azonenberg>
yeah being able to design one board with a lot of different types of probe target would be nice
<azonenberg>
I also just ordered a couple of DS125DF111s
<azonenberg>
They're 2 channel retimers with PRBS generation
<azonenberg>
So i can easily generate high speed, say 10.3125 Gbps, signals with just a cheap micro and that part, no FPGA needed
<azonenberg>
plus it's dual channel so i can do various fun things to it
<azonenberg>
I also want to include something that demonstrates power rail noise and its impact on frequency
<azonenberg>
easiest option will probably to be to use the stm32's internal RC oscillator as well
<azonenberg>
then add a refclk output from the stm32
<azonenberg>
So we can plot frequency vs voltage
<azonenberg>
i just have to figure out how to inject some power rail noise into it
<electronic_eel>
i don't know how good the internal rc of the stm32s are filtered. wouldn't it be better to build just a basic oscillator yourself for that? like with a 74lvc1gu04 and a crystal
<electronic_eel>
or r/c combination instead of a crystal
<electronic_eel>
then add add psu noise and measure phase noise / jitter with a spectrum analyzer
<azonenberg>
then i just have to figure out how to add the noise
<azonenberg>
I want a demo of a power rail probe being used to look at a noisy PSU and how the PSU noise alters the oscillator frequency
<azonenberg>
so you'd have one scope channel on the osc output and one on the power rail and correlate
<electronic_eel>
you could use your signal generator to generate defined noise levels. best way to couple them into a power rail is probably with a small transformer, to take care of the impedance mismatch
<electronic_eel>
a capacitor may also work
<azonenberg>
Hmm, yeah I guess i could just use the SSG to inject the noise
<azonenberg>
I wont need a lot of power if i'm just injecting it into a single oscillator for demo purposes
<azonenberg>
For testing purposes the noise will probably just be a fairly low freq sine or square wave
<azonenberg>
using the LFO on the SSG
<electronic_eel>
you could create a defined noise shape
<azonenberg>
What i'm looking for is a recreation of a bug a friend had years ago with a spartan-6 DCM
<azonenberg>
where psu noise made it glitch faster than the control loop could compensate and cause huge shifts in the output
<azonenberg>
so i think short pulses of dipped vdd makes the most sense
<azonenberg>
an ac coupled squarewave should do that nicely
<electronic_eel>
just add a proper filter between the output of the voltage regulator and the point you couple the noise in. lc filters usually work well on power supplies
<azonenberg>
yeah i was thinking of having a separate LDO driving the DUT, with a ferrite chip between LDO and DUT
<azonenberg>
then a slightly-too-small bypass cap on the other side of the ferrite
vup2 is now known as vup
suzizecat has joined #scopehal
<suzizecat>
Hello there o/
<azonenberg>
o/
<suzizecat>
So, I successfully installed glscope and built the picobridge
<suzizecat>
Then I started the bridge, the sope clicked happyly, and I tried in the cliend to connect to a pico through LAN (i guess) providing 127.0.0.1 as an address
<suzizecat>
And it worked without complain, but I see nothing
<suzizecat>
Does the process seems right ?
<azonenberg>
So it connected, you see the serial number in the title bar and it detected all of the channels?
<suzizecat>
Yup
<azonenberg>
By "you see nothing" you mean a blank plot without waveforms?
<suzizecat>
Yup
<suzizecat>
Dumb, question, but do you have a userguide laying around ?
<azonenberg>
There is a manual, yes. It's not finished
<azonenberg>
that's a live url i periodically upload new versions to
<suzizecat>
Nice !
<azonenberg>
it will be hosted somewhere more formal (i.e. outside /temp/) when we have an official release
<suzizecat>
I'll look at it a bit more and let you know if I still struggle
<azonenberg>
anyway, most likely what's going on is that the scope isn't triggering so you have nothing to see
<azonenberg>
the OEM picoscope software runs with no trigger out of the box, free-running and capturing whatever
<suzizecat>
yup
<suzizecat>
seems legit
<azonenberg>
glscopeclient connects to a new instrument using whatever the default / previously set trigger is and arms it
<suzizecat>
but hitting "start" does nothing
<azonenberg>
the default in the libscopehal picoscope driver is, iirc, a 0V edge trigger on channel A
<azonenberg>
So if you don't have a suitable signal it will just sit around and wait for one to show up
<suzizecat>
Which should trigger, in this case
<azonenberg>
Try hitting the force trigger button on the toolbar (third from left)
<azonenberg>
actually i dont remember if i implemented that in the pico driver
<suzizecat>
Still nothing (and it seems that I zoomed in the time >.<)
<azonenberg>
Go to setup|trigger and play around a bit there
<azonenberg>
baby is crying a bit, have to go deal with that
<suzizecat>
So, I saw some stuff moving, kind of
<suzizecat>
I have quite a fex PicoOscilloscope::CanEnableChannel: Unknown ADC mode warnings from the client though
<azonenberg>
That sounds like the client and server are losing sync. I have some bugs around that i'm still chasing
<suzizecat>
Hmmm
<suzizecat>
I also get some OpenCL error: clCreateKernel (-46)
<suzizecat>
(Anyway, the picoscope model is Unknown, so those issues are to be expected)
<suzizecat>
Warning: Unknown PicoScope model "3405DMSO"
<suzizecat>
If I somehow can help you to debug by providing error messages and such, please let me know =)
<azonenberg>
ok so... you have a couple of different things going on
<azonenberg>
first off, it seems the 3000 series code in glscopeclient wasn't merged yet? i could have sworn it was, the bridge side is
<azonenberg>
noopwafel was working on that but is AFK
<azonenberg>
but that shouldn't break much
<azonenberg>
since the bridge handles most of the hardware abstraction. It just means you might not have the digital channels working
<suzizecat>
which I don't use here, so that's ok
<azonenberg>
also setting sample rate/depth possibly wouldn't work
<suzizecat>
yup
<azonenberg>
since that requires a model specific table in the driver
<suzizecat>
it doesn't
<azonenberg>
That's easy to add support for though
<azonenberg>
The OpenCL error CL_INVALID_KERNEL_NAME might be related to my experimental OpenCL renderer under development
<azonenberg>
i'll look into that, but unless you manually went into preferences and selected the OpenCL renderer it's harmless
<azonenberg>
all of the OpenCL code has fallbacks to non-accelerated or OpenGL paths
<azonenberg>
So I think the big problem you're getting is the client and server desynchronizing. Is there any useful output on the bridge side?
<azonenberg>
also try running both glscopeclient and bridge with --debug
<suzizecat>
No output on the bridge side, trying with debug
<suzizecat>
Oh, dumb question, I have a X10 probe, should I put 10 or 0,1 as Attenuation ?
<suzizecat>
Oh
<suzizecat>
It kindda react as expected
<suzizecat>
So, somehow, it started working
<suzizecat>
Oh ! If I vertically zoom on the trace B, everything stops (as in pause) until I change the vertical zoom of the probe A (which is the trigger source)
<suzizecat>
Hmmm weird. I changed the trigger source and now, it seems that is triggers correctly but doesn't output any significative data
<azonenberg>
Sounds like there's still some bugs to work out
<azonenberg>
I will say, the triggering is done on the digitized data
<azonenberg>
so if your attenuation is mismatched (put 10 for a 10x probe - it's attenuation factor not gain)
<azonenberg>
then your trigger won't be at the level you think it is
<azonenberg>
And if you're zoomed out way too far, you might not have enough ADC codes difference between your low and high level to trigger at all
<azonenberg>
Auto trigger would make some of this setup work easier, there's a pending ticket for it
<azonenberg>
it will just take some back-end work to make that functional
<azonenberg>
and i have dozens of other things to work on and not enough engineering time :)
<suzizecat>
Indeed !
someone-else has joined #scopehal
<suzizecat>
In this situation, the point is that between the moment it worked and when it stopped working, I haven't touched the attenuation factor. So it's a bit strange.
<azonenberg>
The easiest way to check for a de-sync - which i suspect is happening but am not sure of the root cause for yet, i've been chasing an intermittent bug related to it
<azonenberg>
is to add some debug code to PicoOscilloscope::AcquireData after the read of "config" on line 476
<azonenberg>
actually better, after the read of memdepth on 485
<azonenberg>
and print out the memory depth
<suzizecat>
in the client ?
<azonenberg>
Yes
<azonenberg>
and see if you get sane values
<azonenberg>
if you start seeing garbage the protocol state machine desynced somehow
<azonenberg>
use LogDebug(), LogWarning, LogError(), etc functions from logtools
<azonenberg>
they have the same semantics as printf but respect verbosity settings, redirection, etc
<suzizecat>
'kay
<azonenberg>
I'm on baby duty right now so cant spend too much time debuggin
<suzizecat>
indeed !
<azonenberg>
she gets antsty if i sit down for too long while holding her
<suzizecat>
I'm in no urgent need anyway, no problem =)
<azonenberg>
Yeah understood. I just want to get the pico driver production ready before the 0.1 release
<azonenberg>
and i know it's not yet
<suzizecat>
Hmm what should I print in there ?
<suzizecat>
Well, actually, don't mind, I'm a bit tired today and don't know well enough your codebase to start today. I'll get a look in few days if I have the time (and the motivation ^^' )
<suzizecat>
(Also I don't have a proper setup to code on it atm)
bvernoux has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
<ericonr>
electronic_eel: for what it's worth, I am an EE student and will start my last year next year. I learned S-parameters, but never got into probes; most of the HF stuff we messed around with just used a connector and a cable directly instead
<fridtjof[m]>
oh, talking about the pico bridge, i've hackily added support for another one of the pico sdks to the bridge, as my hackspace has a slightly older ps that wasn't supported by the bridge before