<azonenberg>
So i got in touch with corgi via twitter DM, he has two proposed designs for the active probe power system that he'll be dropping in here shortly to get our comments on
<azonenberg>
On the MAXWELL side I'm still making schematic symbols for the FPGA and DRAM
<azonenberg>
and doing high level component selection
<azonenberg>
later today i'm gonna fire up the power estimator spreadsheet and figure out some performance targets for the PSU
<Degi>
Like 1 kW, then we can use the probes for welding
<Degi>
What if you made a soldering iron connected to an oscilloscope? So you can probe while soldering!
<azonenberg>
lolol
alexhw has joined #scopehal
<Degi>
Actually a voltmeter on a soldering iron would make a lot of sense
<azonenberg>
Hey, question for the channel... after work today i plan to work on the RGMII protocol decode for scopehal
<azonenberg>
Is there any reason we would want to decode RGMII to GMII?
<azonenberg>
or should i go straight from RGMII to ethernet frames like all of the other ethernet decodes do?
<azonenberg>
the latter would be easier to implement and IMO makes more sense
<electronic_eel>
hmm, usually you either have a RGMII interface or a GMII one. as long as you can decode both, I don't see any reason why you would want to convert between the ones in decode
<electronic_eel>
the only reason I could think of is if you are debugging a switch-like interface where one side is GMII and the other RGMII and want to compare the data
<azonenberg>
Exactly my thought. It makes a lot more sense to just decode directly
<electronic_eel>
but I guess this is a very niche application, and also you probably want to compare ethernet in the end
<azonenberg>
Yeah ultimately i'm going to be looking at frames
<azonenberg>
So this is interesting, glscopeclient is deadlocking during startup if i have two lecroy scopes connected. but not if connecting to either alone
<azonenberg>
And not 100% consistently either
<azonenberg>
but often enough to be annoying
<azonenberg>
The main glscopeclient UI thread is in LeCroyOscilloscope::ReadReply() blocking, waiting for the trigger voltage to come back after having sent TRLV?
<azonenberg>
and the ScopeThread is blocking in LeCroyOscilloscope::PollTrigger() on line 970 waiting to get the mutex that the main thread is holding
<azonenberg>
innnteresting
<azonenberg>
so the scope is dropping the command and giving errors about TRLV?
<azonenberg>
"illegal header path for command (current path is DIGITAL1)"
<azonenberg>
so basically i need to qualify the trigger level if the scope has digital channels installed since the last channel i did something to might have been digital?
<azonenberg>
that seems weird because TRLV should not be scoped to a channel, it should be general referring to the trigger subsystem
<azonenberg>
but welp
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jfyvl
<_whitenotifier-f>
[scopehal] azonenberg a10f772 - Bugfix: LeCroyOscilloscope would sometimes hang checking the trigger voltage on scopes with the MSO option installed