<d1b2>
<dannas> Mamma mia. I wonder why gdb under VsCode takes such an awful long time to inspect call stacks when I hit a breakpoint. It takes 10-20s before it opens the editor view for the location of the hit breakpoint. I must have messed up some gdb configuration or there's some strange interaction between VsCode and gdb. Doh. I don't wanna have to debug my tools with my tools.
<azonenberg>
o_O
<d1b2>
<dannas> And I wonder why SiglentScpiOscilloscope does not specify sample depths for SDS2xxx/SDS5xxx. Maybe I just have to read the datasheet to understand that. It does specify available options for samplerate.
<azonenberg>
It's possible that part was never implemented? ask mubes
<azonenberg>
he wrote that driver
<d1b2>
<dannas> @azonenberg Ok, I'll might ask him later. For now I'm just blurting out questions while I'm coding in case someone might be listening. I have plenty of things to work on still.
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 245 seconds]
<d1b2>
<dannas> Hm, weird. The SDS1104X-E can only change memory depth when the scope is running in non stop mode.
<d1b2>
<dannas> I get an error message on the scope screen but since SCPI-commands don't return error codes I guess I have to check that setting the memory depth really too effect.
<d1b2>
<dannas> Is that true of all SCPI commands? That they don't return error values? AFAICT, you only get replies for query-scpi commands.
<azonenberg>
Yes there are no error returns
<azonenberg>
most are fire and forget
<azonenberg>
It's not the greatest model :)
<azonenberg>
remember it dates back to the 1980s
<azonenberg>
if not older
<d1b2>
<dannas> I'm thinking of disallowing changing timebase properties for the SDS1104x-e if it's in stop mode. Maybe I can just throw up an error popup for now. I guess I'll have to resort to some kind of hack.
<azonenberg>
you could maybe arm the trigger, change timebase, then stop it? idk
<azonenberg>
this is the kind of thing we shoudl reach out to them and see about fixing in future firmware
<azonenberg>
at which point we might just say the minimum fw for the libscopehal driver is version X
<azonenberg>
if you can compose a detailed list of things you'd like fixed and send to me, I can make sure it gets to the right people at Siglent
<azonenberg>
There's no guarantee anything will happen with the report, of course, but we can hope
<d1b2>
<dannas> Yeah, that might work. I'll see what I can do.
<d1b2>
<dannas> 620 inserts, 269 deletes. This WIP changeset is growing and growing.
<d1b2>
<dannas> I'll split it into digestible chunks for review once I'm done.
<azonenberg>
Yeah sounds about right for an instrument driver
<azonenberg>
not massive, but not small either
<d1b2>
<dannas> If I scoll intensily on the scroll wheel when hovering the voltage column at the right of glscopeclient, I can queue up VOLT_DIV events that takes up to 15s to process for the scope.
<d1b2>
<dannas> That's more of an "ape-test" I guess, but maybe I need to throw away excessive amount of events to keep the app responsive.
<d1b2>
<dannas> Now I've done everything except the parts that makes the app useful. 🙂 What still remains is to parse the waveforms so that they can be displayed and add support for triggers. Time's up for today.
<d1b2>
<dannas> I've managed to have the scope lock up a few times. Not sure about the exact circumstances, but AFAIR it happened when I shutdown a debugging session. Maybe the scope was waiting for some message that never arrived?
<d1b2>
<dannas> I'll try to reproduce the hangs some other day (I had to eventually power cycle the scope to get it responsive again, though I didn't try sending the SCPI reset command. Maybe that would have helped).
nelgau has joined #scopehal
nelgau_ has joined #scopehal
nelgau_ has quit [Remote host closed the connection]
nelgau has quit [Ping timeout: 256 seconds]
<electronic_eel>
azonenberg: nice openram test results you posted
<azonenberg>
Still more characterization to do, and this is still only a single die's worth of results
<electronic_eel>
do you have a rough idea what such test results of one die would mean re a commercial datasheet? like would they rate this part as 20 MHz @ 1.8V, right at the margin? or what kind of margin would they add, like 18 MHz or even 15 MHz?
<electronic_eel>
i don't mean some chinese backyard fab that steals their datasheet graphs from somewhere else, but a reputable mfg
<azonenberg>
I don't know what kind of margin to add, that's separate
<azonenberg>
and you don't spec at 1.8000V
<azonenberg>
you spec at say 1.8V +/- 10%
<azonenberg>
At different thermal corners
<azonenberg>
so you'd spec from slow process / 0C / 1.65V to fast process / 85C / 1.95V
<azonenberg>
then add some margin on top of that
nelgau_ has joined #scopehal
nelgau_ has quit [Remote host closed the connection]