<azonenberg>
ok let's see, MEAD enclosure bottom is printing now, top is queued up and ready to go once the bottom print is done. Expecting to ship today according to the original schedule so we'll see how long it takes
<azonenberg>
This is black nylon 12 on HP's MJF process
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #scopehal
<azonenberg>
v0.9 probe PCB is ordered
<monochroma>
* azonenberg finds a major error immediately after
<azonenberg>
lol there shouldnt be anything major, i just fine tuned the impedance of the tip a bit
<azonenberg>
so my focus for tonight is going to be finishing the multi-scope sync wizard
<monochroma>
:D
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/Jf9vo
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/Jf9v6
<_whitenotifier-f>
[scopehal-cmake] azonenberg 25d036f - Updating submodules with sync wizard
<azonenberg>
ok, i think its done. gonna try and shoot a test video
<monochroma>
:D!
<azonenberg>
There's definitely issues with the multi scope sync, trigger frequently get missed on one or both instruments so i had to add some timeouts
<azonenberg>
but it does work
<azonenberg>
and it does properly lock-step
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jf9kn
<azonenberg>
Hmm, that may not be necessary since the command doesn't return a value
<azonenberg>
according to the MAUI Oscilloscopes Remote Control Manual, page 233, you only need the ? if returning a value
<azonenberg>
but it doesn't seem to break anything so i kept it there. Some of the automation commands i use were figured out by sniffing lecroy tools as they're not well documented
<tverbeure>
Ok. Let's fix that. Right now, it makes my TCP/IP to VISA bridge server fail because my code that a "?" will result in return data.
<azonenberg>
this may have been copied from that
<azonenberg>
Ok
<azonenberg>
Send me a PR and i'll test
<tverbeure>
Ok.
<azonenberg>
I'm busy fine tuning performance on the multi scope bridge stuff
<azonenberg>
btw, anybody here familiar with the details of how Linux decides which thread should get ownership of a mutex if multiple try about the same time?
<azonenberg>
is there any sort of fair queueing going on?
<azonenberg>
i found that i had to add a sleep to ScopeThread to prevent starving the UI thread if they both had contention for the mutex. for some reason my kernel was giving the mutex to ScopeThread over and over again when polling the hardware
<azonenberg>
and the UI thread was starving for hundreds of ms
<azonenberg>
even a <1ms usleep was enoguh to hint the kernel that i was explicitly yielding
<azonenberg>
and wanted to let the UI thread have a turn
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/Jf9kP
<_whitenotifier-f>
[scopehal-apps] azonenberg d7894ae - Fixed missing units in GTK theme
<_whitenotifier-f>
[scopehal-apps] azonenberg 219e34c - Scope thread now explicitly yields if a trigger poll shows no data ready
<_whitenotifier-f>
[scopehal-apps] azonenberg 3f69d67 - OscilloscopeWindow: improved handling of secondary scopes skipping triggers in multi-scope systems
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #147: "VBS?" -> "VBS" for non-query - https://git.io/Jf9k7
<tverbeure>
Remember how I saw that pressing "stop" would sometimes only take effect after 4 more waveforms were captured? Same thing: it simply stalled on a mutex. I improved it by reducing the scope of the mutex, but every once in a while it still happens.
<azonenberg>
so this fix i just implemented may have fixed that
<azonenberg>
also video demo of multi scope sync coming up shortly
<azonenberg>
tverbeure: your PR is incomplete
<azonenberg>
lines 495, 498, 501, 540, 543, 2046-2048, 2118 all have VBS? without returning a value
<tverbeure>
Ok. My thing was halting just on that one because that's the only one triggered by the Siglent. Let me fix the rest as well.
<azonenberg>
yeah but if we're fixing it i want to do all of it
<azonenberg>
how's the UI for the sync look? seamless enough?
<lain>
azonenberg: awesome demo, this scope sync is going to be so handy
<azonenberg>
I'm looking forward to demoing this between different vendor scopes once we have another vendor's driver as nice as the lecroy one
<azonenberg>
imagine a fleet of cheap rigols slaved to one nice scope, or something
<lain>
hehe
<azonenberg>
if you have a 50 ohm multiport splitter you could in theory have arbitrarily many secondary devices
<azonenberg>
right now the UI does not enforce trigger config, that's still on the todo
<monochroma>
yay! that was a nice demo :D
<azonenberg>
i.e. i should not be able to set a channel on a secondary instrument as the trigger
<azonenberg>
if i do that will make it desync
<azonenberg>
but this is now vastly more seamless than what i've had before
<azonenberg>
note also that i'm mixing 10 and 20 Gsps channels in this demo
<azonenberg>
and it just works (tm)
<azonenberg>
the deskew logic correctly samples reference channels with unequal sampling rates. Not full resampling for the moment, i just do nearest neighbor, but most scope sample rates are integer multiples of each other anyway
<azonenberg>
so it looks like i should be getting the MEAD boards by the end of next week. v0.9 probe is at fab
<azonenberg>
I started work on schematic symbols for MAXWELL and will probably be working on that here and there for a while
<azonenberg>
anybody have other priorities for me in the near term?
<azonenberg>
there's still some more testing needed on the BLONDEL AFE, i wanted to use the VNA to measure S21 through it at some point
<azonenberg>
monochroma, lain: btw once you get a driver for your old agilent scope set up
<azonenberg>
(if it's not working already) i'd love to see if you can sync it and the DDA
<Degi>
Hm why is 8B10B worse that 64B66B? Is it because of the autocorrelation?
<azonenberg>
Degi: yes
<azonenberg>
in particular the 8b10b idle pattern used on most links, K28.5 D16.2 with constant disparity
<azonenberg>
it's 20 bits repeating
<azonenberg>
so you can only measure the phase modulo 20 UIs
<Degi>
Hmh so you mean then the trigger could be 20 UIs off?
<azonenberg>
yes, or 40, or 60, or 80
<azonenberg>
or negative
<Degi>
Hm yeah integer multiples
<azonenberg>
and the deskew couldn't compensate for that unless you had a lot of actual packet data to disambiguate
<azonenberg>
64/66 is a LFSR scrambler, not a codebook. there's a slight autocorrelation peak at 66 UIs because of the packet headers but that shouldn't be enough to confuse sync because the other 64 bits are not going to line up
<azonenberg>
in this example i'm using ethernet frames on the RGMII bus, which should have fairly low autocorrelation
<tverbeure>
I have a bridge server from TCP/IP sockets -> USBTMC up and running, so I can now run the Siglent scope with Sockets instead of straight USBTMC (though I need to force SCPISocketTransport to be batchless.)
<tverbeure>
This is pointless by itself, but with that debugged, I can now use TCP/IP to GPIB without needing a GPIB driver in scopehal.
<tverbeure>
Interesting note: TCP/IP -> LXI doesn't work with Siglent because "WF? DESC" alternately returns 363 and 362 bytes on each call.
<tverbeure>
USBTMC always correctly returns 363.
<tverbeure>
Now the last byte is irrelevant, but the Sockets interface doesn't have a way to simply purge whatever remaining bytes are left in the receiving socket.
lukego has quit [Read error: Connection reset by peer]
lukego has joined #scopehal
<azonenberg>
tverbeure: um, thats interesting
<azonenberg>
tverbeure: as a workaround, re LXI
<azonenberg>
what if you do *IDN?, WF:DESC?, *IDN?
<azonenberg>
knowing the length of the IDN string from the first call, you can read sizeof(IDN-1) bytes and then if it's got an extra garbage byte at the start read one extra byte at the end
<azonenberg>
its an ugly hack but would allow you to bypass the issue
<azonenberg>
the first call only has to be done in the constructor, also
<azonenberg>
no need to repeat after
<azonenberg>
actually since IDN has a well defined end-of-string you could just call IDPing() after reading WF:DESC with 362 bytes before doign anything else
<azonenberg>
i think that would be sufficient by itself
<azonenberg>
As long as the last byte of the WF:DESC is known to not be a newline at least
<azonenberg>
but if you can't make that guarantee then sending *IDN? and explicitly reading N-1 bytes, then an extra byte if misaligned, would still work
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 256 seconds]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
<tverbeure>
You're absolutely right: with *IDN? you also don't know the size of the reply. So there is a way to deal with that. Let me look into that later.
<azonenberg>
tverbeure: string input pulls stuff until it sees a newline one byte at a time
<azonenberg>
with WF:DESC there is not an explicit terminator so that strategy does not work
<azonenberg>
however if you know *almost* how long it is, then have known *IDN? data after
<azonenberg>
you can infer the actual length of the wavedesc ex post facto
<azonenberg>
MEAD enclosures are done printing, shipped, and ETA tomorrow woo
<electronic_eel>
today while gardening I thought about if I wanted to have a DUDDELL
<azonenberg>
DUDDELL/ZENNECK are fast enough to be useful to me for monitoring lots of lower speed lines
<electronic_eel>
I think the 250 MHz / 1 GSPS limit it a bit, while on the other side 8 analog channels, lot's of ram and fast pc uplink are a great step up from traditional scopes
<azonenberg>
BLONDEL is really more of a tpy/prototype IMO
<azonenberg>
toy*
<azonenberg>
it's a stepping stone to the nicer gear more so than an end in itself
<azonenberg>
ZENNECK is probably the lowest end one i'd keep around after initial prototyping, i'd have no problem getting rid of a BLONDEL or DUDDELL once i built the next model up
<electronic_eel>
so I thought - why not add a mode to optionally combine two channels to get 2 GSPS on these channels, also with a 350 MHz bw
<azonenberg>
I feel like at that point you're basically just building ZENNECK though
<azonenberg>
it will be modular, you dont have to load all 8 channels
<azonenberg>
channel interleaving on DUDDELL is plausible but would be a fair bit of work i think
<electronic_eel>
hmm, I don't know about pricing, but I think you'd need much beefier fpgas and 4 times the hmcads for ZENNECK
<azonenberg>
well yeah
<electronic_eel>
and the channel interleaving would have to be developed for ZENNECK nonetheless
<electronic_eel>
so this could be prototyped and tested on DUDDELL
<azonenberg>
hmmm
<azonenberg>
good point
<azonenberg>
electronic_eel: ok so yeah let's support interleaving of two, or possibly even four, hmcad's on DUDDELL then
<azonenberg>
we can also use that to prototype switchable filter banks
<azonenberg>
although there will be some of that on BLONDEL too
<electronic_eel>
oh, you want to add switchable filter banks to the BLONDEL AFE?
<electronic_eel>
or do you mean the ones in the HMCAD?