electronic_eel_ has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f>
[scopehal-docs] tomverbeure opened pull request #6: Table with all existing Siglent scopes and their protocol support. - https://git.io/JfiKg
<_whitenotifier-f>
[scopehal-docs] tomverbeure commented on pull request #6: Table with all existing Siglent scopes and their protocol support. - https://git.io/JfiKw
juli965 has joined #scopehal
<azonenberg>
Status update, the oshpark probe boards came in. Assembling shortly
bvernoux has joined #scopehal
<bvernoux>
azonenberg, I have received my 10x => 2.92mm Edge Launch Connector Southwest Microwave
<bvernoux>
they are just amazing
<bvernoux>
10 for 55.18USD Total ;)
<bvernoux>
5USD per SouthWest connector is amazing
<bvernoux>
when we know they cost >120USD/unit
<azonenberg>
Nice price, lol
<bvernoux>
I need to finish and produce my TRL Board + other Test board with RO4350B+SouthWest footprint for test
<bvernoux>
will use Immersion Silver ;)
<azonenberg>
This is a full probe on oshpark fr408hr with enig
<azonenberg>
I expect high loss, what i'm mostly looking for is flatness of frequency response
<bvernoux>
yes flatness is pretty good with FR408HR/ENIG
<bvernoux>
my complaint was only very high loss
<bvernoux>
3dB for 2inch up to 6GHz is huge
<bvernoux>
when it is expected to have 1dB ;)
<azonenberg>
Yeah. But for prototyping high loss is OK as long as i can model and quantify it
<azonenberg>
the cool thing is, 408HR and RO4350B has almost exactly the same Er
<bvernoux>
we can live with that with lot of RF design ;)
<azonenberg>
Which means you can use basically the same stackup and get less loss without a redesign
<azonenberg>
and of course enig to silver is also less loss but no real other impact on performance
<bvernoux>
miek, woo nice 1.5GHz probe
<azonenberg>
miek: how soon till we have waveforms through them from scopehal?
<bvernoux>
I suspect thei are active probe ?
<bvernoux>
they
<bvernoux>
ha it is wrote on them Active Probe ;)
<bvernoux>
IIRC passive scope probe never exceed 1GHz
<bvernoux>
even 500MHz
<azonenberg>
bvernoux: the normal 1M ones yeah
<bvernoux>
yes
<bvernoux>
azonenberg, I saw that the KS finished fine
<azonenberg>
but dont forget those transmission line probes i'm benchmarking mine against
<bvernoux>
congratulations !!
<azonenberg>
yeah now i have to deliver
<bvernoux>
hehe
<miek>
azonenberg: you've seen ch1 through scopehal before :) unfortunately #2 and #3 that just came in have no accessories, so i need to figure out sources for that stuff
<azonenberg>
bvernoux: i mean i could cheap out and just ship the boards i have now, i'd just need to buy more tips etc from PMK
<azonenberg>
Which i'm about to do as soon as funds clear from KS, since i need those regardless
<bvernoux>
yes
<azonenberg>
but i really want to get better freq response
<azonenberg>
i promised backers i'd ship by august
<azonenberg>
i intend to use all that time and ship the best probe i can
<azonenberg>
unless of course i get something satisfactory before then
<bvernoux>
maybe it will be ok to receive new PCB before that ?
<bvernoux>
to have better freq response ?
<azonenberg>
v0.7 is what i had on order when i started the KS
<bvernoux>
when it is planned to receive v0.7 ?
<miek>
my USB-HS probing from before: https://i.imgur.com/UNjWBkK.png - ch1 was one of those probes, ch2 was a cheap fet probe. once i get more tips for the new probes i can do this properly :D
<azonenberg>
It came in weeks ago and had OK-ish performance
<azonenberg>
v0.8 is an oshpark prototype on 408HR+ENIG with the new SMA and a better impedance transition from SMA to CPW
<azonenberg>
That arrived this afternoon and is cooling off in the reflow oven now
<bvernoux>
ha great
<bvernoux>
so v0.8 is promising even if there is something like 3dB RF Loss which is expected
<bvernoux>
it shall be flat like RO4350B
<bvernoux>
or very similar
<azonenberg>
0.7 still had that big rolloff which i need to troubleshoot more
<azonenberg>
If i like the flatness of 0.8, 0.9 will be a 4350B conversion of 0.8. I'm also going to put a second ground connection in by the tip to reduce loop area at the expense of less flexibility
<bvernoux>
0.7 is with old cheap SMA connector ?
<azonenberg>
yes
<bvernoux>
I'm pretty sure it is due to SMA ;)
<bvernoux>
they are crap in fact >2GHz
<azonenberg>
We'll find out. There are also some issues from the grounding lead placement
<bvernoux>
some chinese SMA for 0.2USD/unit are sometimes better than genuine 5USD DigiKey ones
<azonenberg>
lo
<azonenberg>
lol
<bvernoux>
anyway they do not provide any test even on expensive SMA
<bvernoux>
which they say up to 18GHz
<azonenberg>
well that's why i'm characterizing everything
<bvernoux>
when I see how the GND is far from center pin they cannot be as good
<azonenberg>
i also plan to build a controlled experiment on the oshpark probes soon
<azonenberg>
with 0R's instead of resistors
<bvernoux>
and they do not exceed 6GHz in best case because of that I think
<azonenberg>
To test performance of the tip, ground lead, SMA, pcb, everything but the attenuator
<bvernoux>
ha yes great
<bvernoux>
also a very good things to caracterize everything is to measure step by step
<bvernoux>
with VNA
<bvernoux>
then you add resistor one by one
<bvernoux>
replacing 0ohm by them ...
<bvernoux>
then you can de-embed 0ohm ...
<azonenberg>
i'm going to do two boards for the moment
<azonenberg>
i have three from oshpark
<azonenberg>
one with 0R one fully assembled
<azonenberg>
then see what happens
<bvernoux>
yes a good reference
<bvernoux>
especially if they are well soldered with good reflow oven
<bvernoux>
Qorvo MatchCalc is quite nice for de-embedding
<bvernoux>
you can export SxP results after
<bvernoux>
they have some good tutorials to understand the logic of the GUI as it is not intuitive ;)
<bvernoux>
AnTune is really better for matching
<bvernoux>
but it is not free
<miek>
neat, i see -3dB @ ~375MHz on each probe (on my 300MHz scope)
<miek>
in theory it could be 500MHz+ with some part swaps on the mainboard, but i haven't been brave enough yet..
<azonenberg>
Also the parameter sweep i ran last night on the MMCX looks good
<azonenberg>
0.7mm center pin with 0.8mm ground plane cutout is better than -31 dB S11 out to the 6 GHz rated bandwidth of the connector
monochroma has quit [Ping timeout: 258 seconds]
monochroma has joined #scopehal
<azonenberg>
grrr
<azonenberg>
same basic issue with the new test board
<azonenberg>
flat for a while then steep dropoff
<azonenberg>
From DC to 1.15 GHz we roll off from -15 to -17 dB, nice and smooth - which is likely mostly enig/fr408 loss
<azonenberg>
by 1.5 GHz we're at -21 dB
<azonenberg>
by 2 GHz, -29
<azonenberg>
next step is to try shorting the resistors to measure pcb+tip response
<azonenberg>
so this is the three PMK grounding accessories under consideration, as well as a new ground socket soldered right next to the probe tip, on a 0R probe
<azonenberg>
red is the new ground, blue/cyan/pink are the PMK ones in the standard ground socket
<bvernoux>
yes close ground provide the best like expected
<azonenberg>
if i'm reading this right, the extra loop area of that ground provides a massive amount of inductance. way more than i expected
<azonenberg>
This is a probe without an attenuator, though
<bvernoux>
which is good at more than 3GHz
<azonenberg>
-3 dB of insertion loss for the close ground version at 1 GHz sounds high
<azonenberg>
there's other factors i'm missing
<azonenberg>
Good news is it's looking like the attenuator itself is quite flat
<azonenberg>
blue - thru line extended to approximate length of probe. Vertically shifted (right axis) but same scale as the other traces
<azonenberg>
red = close ground, cyan = normal ground
<azonenberg>
whats interesting is that the red trace is close to a straight line, but much more rolloff than i expected from the blue trace
<azonenberg>
I'm curious if perhaps this might be due to capacitive coupling between the ground (which is REALLY close to the tip socket, i bodged it on and there wasnt a good spot for it)
<azonenberg>
and the tip socket
<azonenberg>
so we might have a parasitic C shunting power that way
<azonenberg>
On a different note, MEAD status update: just finished the final layout of the MMCX input board now that all of the simulations have completed and i have what looks like a good match
<azonenberg>
Now i have to figure out if i'm adding "tails" to it with mounting holes (which i think is probably a good idea)
<azonenberg>
and make any changes to the carrier board needed for this
<tverbeure>
Ok. It's not listed on Siglent Intl website.
<azonenberg>
tverbeure: yeah if you google around you find a bunch of chinese website listings
<azonenberg>
with "siglent powered by lecroy" in the footer
<azonenberg>
different colored enclosure or something but its obviously a wavesurfer 3000
<tverbeure>
I'll add it back.
<azonenberg>
The 3000 series is a Siglent hardware design running a LeCroy-developed port of MAUI/XStream for Windows 7 Embedded aka Windows CE
<azonenberg>
my guess is part of the cross-licensing deal was that siglent doesn't compete with the wavesurfer in the US market
<azonenberg>
miek: wooo
<azonenberg>
i notice you have the old UI in a few spots. has it been a while since you pulled latest?
<miek>
yeaah, a week or two maybe
<azonenberg>
That would do it. the new dark theme is a week-ish old
<azonenberg>
it should look much better in fullscreen or maximized state rather than having distracting light colored chrome around dark plots
<azonenberg>
if we want to make a light theme we'd want to make the plots etc light too
<miek>
ah nice, i'll check it out
<tverbeure>
A friend of mine has a Siglent SDS1104X-E, which is the same family as the SDS1204X-E that's supposed to have unsigned data (instead of the signed data of my SDS2304X.)
<azonenberg>
Better app-wide themeability is on the wishlist but i dont think i made an issue for it yet
<azonenberg>
tverbeure: great. Error_404 has i think the 1204x-e as well so hopefully we can work out the details of this
<azonenberg>
this is exactly why i wanted more people testing and using the software, though
<tverbeure>
All Siglent documentation mentions signed data, so I'm planning to loan his and check out if it's really unsigned. I find it hard to believe...
<azonenberg>
we're not going to find info like this any other way
<azonenberg>
My conjecture is that it depends on how LeCroy-ish the firmware is
<tverbeure>
One alternative is to parse the TEMPLATE data, but that's a very heavy operations.
<tverbeure>
The TEMPLATE data lists the minimum and maximum value. On mine, it says -128 to 127. If the 1204X-E says 0 to 255, that'd be something to rely on.
<azonenberg>
actually no lecroy has signed ADC samples
<azonenberg>
i just checked
<azonenberg>
they're int16_t or int8_t depending on which mode you requested when you configured the scope
<azonenberg>
as of right now i use 8-bit mode in the lecroy driver on all instruments without "HD" in the model name
<azonenberg>
and 16-bit mode on anything that contains "HD" anywhere in the model string
<azonenberg>
miek: i've seen far worse
<tverbeure>
I think, in the long term, it might be better to have a table with scope features and only fall back to string parsing when there isn't a match. The string matching feels very fragile.
<azonenberg>
tverbeure: it is, we've had to add lots of exceptions in the lecroy driver already
<azonenberg>
for example the older DDA5000 series has a DDA5005 model with 4 channels, not 5
<azonenberg>
you need table driven stuff for a lot of things like max memory or sample rate anyway
<tverbeure>
The only problem is that for a table lookup, you need the *exact* string that gets returned by *IDN?
<Degi>
Rigol even needs some GPIB requests heh
<Degi>
Like for installed options, mem depth etc
<tverbeure>
Somebody should just order all these scopes from Amazon, run *IDN? and return them. :-)
<Degi>
(Hmh actually that might be included in the long name)
<azonenberg>
exactly, you cant just do IDN
<tverbeure>
Another problem: my 2304X has a bunch of optionals (16-channel MSO, AWG) and these is no SCPI query to see that they are activated.
<azonenberg>
you need to do a lot of different queries
<azonenberg>
tverbeure: there's not?
<azonenberg>
try *OPT?
<azonenberg>
that's what lecroy uses
<azonenberg>
it should output a comma separated list of option codes
<tverbeure>
*OPT? on the Siglent simply returns: USBTMC, VXI11...
<tverbeure>
That's it. Not very helpful!
<azonenberg>
Interesting. Because that's a crucial step in init on the lecroy driver
<azonenberg>
voltmeter and function gen show up on the list there among other things
<tverbeure>
I know. It's another part of the Lecroy/Siglent driver that needs to be refactored.
<azonenberg>
16-channel logic analyzer on lecroy is an interesting bit
<azonenberg>
because it can be indicated by either a model name ending in -MS or option code MSXX
<azonenberg>
which to use depends on the scope family
<azonenberg>
e.g. wavesurfer 3000 uses MSXX option, most other stuff seems to have it be in the model name
<tverbeure>
This all leads to the following: we need scope-specific command line arguments to indicate the presence of certain features. Right now the remain args get passed on to Transport, not to Driver.
<miek>
hmm, so i saved out 100 waveforms for later but when i open it back up i'm only seeing 10 waveforms in the list
<tverbeure>
How would you go about that?
<azonenberg>
miek: how many waveforms are in the save file?
<miek>
100
<azonenberg>
go look in the _data directory
<azonenberg>
That's a bug, then. Conjecture: the history view doesn't have the depth properly saved/restored
<azonenberg>
File a ticket for it, if you have time to work on it go try and fix it yourself
<azonenberg>
if not i'll get to it later today or something
<azonenberg>
tverbeure: hmmmm. Make a ticket for that so we don't forget, i don't have answers off the top of my head. My preference is always for autodetection if possible
<azonenberg>
so far the only thing i've found i can't autodetect is whether a lecroy scope has the MSO probe physically mated or not
<azonenberg>
(i wanted to not enable digital channels by default if you didn't have the MSO probe connected)
<tverbeure>
I want to be able to override autodetection so that I have force it to be a different scope than what is detected. Case in point: right now, the Siglent driver uses unsigned stuff for everything but the 2000X series. If my theory is correct and the 1204X-E code is wrong, then a commandline override would allow a user to still make things work.
<azonenberg>
I mean generally scope specific argument seem useful. File a ticket and we can think about how to do that
<_whitenotifier-f>
[scopehal] tomverbeure opened issue #130: Support for command line parameters related to the Driver - https://git.io/JfPe8
<_whitenotifier-f>
[scopehal-apps] miek opened issue #108: Only up to 10 waveforms are loaded from a saved scope session - https://git.io/JfPeV
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #108: Only up to 10 waveforms are loaded from a saved scope session - https://git.io/JfPeV
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #108: Only up to 10 waveforms are loaded from a saved scope session - https://git.io/JfPe6
<azonenberg>
miek: are you going to work on #108 or do you want me to? I won't have time until after work
<tverbeure>
In terms of #include of standard libraries, I see that you add everything in scopehal.h.
<tverbeure>
So, right now, liblxi.h is in scopehal.h. But it seems much more logical to restrict it to SCPILxiTransport.h.
<azonenberg>
tverbeure: includes in scopehal.h are dependencies of major classes that are used throughout the entire project
<azonenberg>
Things that are only used by specific classes should go in those files. Especially if it's something not in scopehal.h
<azonenberg>
As a general rule scopehal.h should contain the minimum includes necessary for a user of the library
<tverbeure>
Ok. I'll move it.
<azonenberg>
private implementation details of specific SCPITransport's, Oscilloscope's, etc aren't needed by users of the library
<azonenberg>
so that should be in those headers or even the .cpp file
<tverbeure>
Right. That's what I assumed. But the present of yaml-cpp/yaml.h etc threw me off.
<azonenberg>
That might be an error, but it might be necessary because we used yaml-cpp types in a header of a core class like Oscilloscope
<azonenberg>
in which case it is a true minimum dependency of the library for a user
<miek>
azonenberg: yeah, i've got a fix. just doing the necessary git housekeeping
<miek>
gah, i need a siren & flashing lights that go off when i pull without a submodule update, or forget to submodule update --recursive
<monochroma>
miek: azonenberg needs that too when he doesn't push updates ;)
<azonenberg>
are there updates you're expecting me to push that i haven't?
<miek>
so i'm getting errors about const/non-const char*s in the lxi transport - is that expected?
<azonenberg>
tverbeure: you wrote that code, right?
<azonenberg>
monochroma: I normally don't always push updates to the scopehal-cmake master until i've done a bit more testing, i use the current submodule version in scopehal-cmake as a sort of "release" process
<monochroma>
azonenberg: nothing i know of right now, just when the submodules our out of sync with your personal repo
<tverbeure>
Yes. But I have a clean build.
<azonenberg>
i.e. the latest scopehal may be less stable than the scopehal ref'd by scopehal-cmake
<azonenberg>
miek / tverbeure: what liblxi versions are you using?
<miek>
i'm on 1.8-1 (ubuntu 18.04)
<tverbeure>
Good question... I have both the compiled version and Ubuntu version. I don't know which one gets picked up. :-)
<azonenberg>
document that as the minimum required version
<azonenberg>
then update the cmake script to detect presence of liblxi
<azonenberg>
if not found, disable SCPILXITransport
<azonenberg>
if found but too old, disable SCPILXITransport and print a warning at compile time saying that an incompatible liblxi version was found and to install a later version if you intend to use LXI
<azonenberg>
this will require we use cmake's conditional define features, i think probably creating a config.h file, to detect presence of SCPILXITransport so we can #ifdef out references to it
<azonenberg>
Ubuntu 18.04 LTS is supported until april 2023, so it's recent enough i want to support it. But I'm OK with saying you need to use a newer-than-packaged liblxi on older OSes, as long as we never have compile errors
<azonenberg>
it needs to gracefully degrade
<azonenberg>
Does that sound like the best way forward?
<tverbeure>
I think the best option would be to #ifdef the calls to liblxi, with or without const.
<tverbeure>
But lxi.h doesn't include a version number...
<tverbeure>
We could include liblxi as part of the project and use that version instead.
<azonenberg>
don't ifdef the calls, SCPILXITransport is useless without liblxi
<azonenberg>
ifdef out the entire class
<azonenberg>
Including a vendor'd liblxi is a possibility if we can integrate the build systems
<tverbeure>
I meant: #ifdef lxi...(const) #else lxi(...non-const)
<azonenberg>
i mean the most backward compatible option would be to just copy the string into a non-const buffer before doing the calls
<tverbeure>
Ah, of course. Let's just do that.
<_whitenotifier-f>
[scopehal] azonenberg opened issue #131: SCPILXITransport gives const-vs-non-const cast errors on liblxi <1.13 - https://git.io/JfPvy
<azonenberg>
When it says "eBook" is that some proprietary DRM format? or unencumbered PDF?
<azonenberg>
(i'm fine with a watermark, i just want to be able to read it without issue)
<tverbeure>
BTW: I got my Siglent scope working over USBTMC.
<azonenberg>
Awesome. Send me a PR when the USBTMC driver is ready\
<azonenberg>
how does performance compare to ethernet?
<tverbeure>
It's very similar.
<azonenberg>
great
<tverbeure>
Turns out that the 80% of the time to fetch a waveform from a Siglent scope is spent preparing the data. The transfer itself is only 20%.
<azonenberg>
Yes. That's my experience with my LeCroy scopes too, they get CPU limited preparing waveforms
<azonenberg>
This is why in my custom-hardware scopes, i intend to have everything be streaming processing in the FPGA
<tverbeure>
For example, fetching 1.4M samples takes 5.9s. 3.15s is preparationg.
<azonenberg>
They're basically going to be a giant DDR3 based FIFO with a TCP offload engine on one side and an ADC controller on th eother
<azonenberg>
there will be two sockets, one for SCPI going to a Cortex-M micro for control plane stuff like setting gain/offset, and another for waveform data going directly to the FPGA
<azonenberg>
i fully expect to be capable of saturating 10Gbase-R with that
<tverbeure>
Took me the whole weekend to get it working: Linux kernels before 4.20 have USBTMC kernel driver version 1. They don't play well with Siglent: as soon as you request more than 2032 bytes, the USB device stops working and you need to reboot the scope to get it going again!
<azonenberg>
Error_404: ^
<azonenberg>
any chance that was the bug your an into?
* azonenberg
notes he is running 4.19
<azonenberg>
(but i also don't have any siglent scopes so not an issue)
<tverbeure>
I believe Rigol has the same issue, but the Linux driver has a "rigol_quirk" piece of code.
<azonenberg>
Lol
<azonenberg>
But it doesnt include a quirk for siglent
<tverbeure>
The new driver has all of that removed and everything just works fine.
<tverbeure>
That said: it's very easy to work around the issue. Right now, my TMC driver assumes a later kernel.
<tverbeure>
But the performance impact of the work-around (issuing many 2032 requests instead of 1 large request) is very small (<5%), so once I have some time, I'll just make it work with the old kernel.
<tverbeure>
There is still an issue with issuing waveforms large than 1.4M: in this case, it takes more than 5s to prepare the data in the scope. And the v1 version of the TMC driver has a fixed timeout of 5s.
<tverbeure>
So the solution there is to fetch the wavefrom in pieces, by using WFSU..
<azonenberg>
Wow those scopes are slow
<azonenberg>
is that a single 5M point waveform?
<azonenberg>
or 5M on all channels
<tverbeure>
Same issue for VXI11 for that case: liblxi has an RPC timeout of 25s and no way to change it.
<azonenberg>
Because on my lecroy, with 5M on all channels, I can do 100 triggers a minute
<_whitenotifier-f>
[scopehal-apps] miek opened pull request #109: OscilloscopeWindow: set max waveform count before loading waveforms - https://git.io/JfPf0
<azonenberg>
which comes out to something like 600-700 ms per waveform
<tverbeure>
It hits the 5s timeout for 1 waveform with 2.8M points.
<tverbeure>
Anyway, for now I don't feel like hacking the Siglent driver to split it into multiple WFSU pieces. I'll just truncate it to 1.4M with some logging error.
<tverbeure>
BTW: after loading a new waveform of the scope, the waveform doesn't update until you manipulate the window.
<tverbeure>
Like zoom in or out. So that's a bug.
<azonenberg>
are you doing the toQueue acquisition handling yet?
<azonenberg>
if not, that is going to break everything
<tverbeure>
How will it break everything?
<tverbeure>
I thought it was just a perf optimization?
<azonenberg>
No. It's crucial because the GUI is trying to pop from that fifo
<azonenberg>
if nothing is in there it will never trigger update events
<azonenberg>
also you risk race conditions when waveform data changes under the app
<azonenberg>
toQueue=false is only intended for single threaded ATE applications
<tverbeure>
Ok. I guess I'll have to get to it at some point then.
<tverbeure>
But my 'new' Tek 420A scope will have arrived this weekend. I'll have to make hard decisions!
<azonenberg>
There's a clean separation where data is acquired from the instrument and written into a fifo in ScopeThread, then the app pops that thread, triggers filter graph updates, renders, etc
<_whitenotifier-f>
[scopehal-apps] tomverbeure opened issue #110: glscopeclient: waveform viewer doesn't automatically update after loading new waveform from scope - https://git.io/JfPfj
<tverbeure>
Oh, wait: are you saying that the window not updating is due to the toQueue issue?
tverbeure2 has joined #scopehal
tverbeure has quit [Ping timeout: 256 seconds]
<azonenberg>
tverbeure2: correct
<azonenberg>
See OscilloscopeWindow::PollScopes() and OnWaveformDataReady()
<azonenberg>
if you don't push new waveforms to the queue that whole event path is skipped
<azonenberg>
you're not going to have any filter update, waveforms won't show up in history, nothing will work
<azonenberg>
note that on OscilloscopeWindow.cpp:1818 I call PollTriggerFifo() which is checking if there's data *in the queue*
<azonenberg>
You're basically silently updating new data and hoping something will notice
<azonenberg>
for example, when a render is triggered by a UI event like a resize or zoom
<tverbeure2>
Alright. I'll add it to the list and close the issue that I just opened.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfPJo
<_whitenotifier-f>
[scopehal-apps] azonenberg e55cd2b - Update stats after filter graph update is complete, not before
<azonenberg>
This definitely should be documented better, in general developer documentation significantly lags end user docs in completeness at this phase
<azonenberg>
it's only been the last few months that we've even had people other than me touching the code
<_whitenotifier-f>
[scopehal-apps] tomverbeure closed issue #110: glscopeclient: waveform viewer doesn't automatically update after loading new waveform from scope - https://git.io/JfPfj
<_whitenotifier-f>
[scopehal-apps] tomverbeure commented on issue #110: glscopeclient: waveform viewer doesn't automatically update after loading new waveform from scope - https://git.io/JfPUU
<Error_404>
re: backlog: I haven't touched the usb interface at all, but wouldn't be surprised if the root cause of those two are the same
<Error_404>
I don't think you can request smaller chunks over scpi though?
<tverbeure2>
From a SCPI point of view, you're requesting the full buffer. But just like any 'read' operation in Linux, you can specify the size of the receiving buffer. If there is more data, you issue more reads until you have all the data.
<monochroma>
Error_404: remote debug your scope you coward :<
<electronic_eel>
azonenberg: about the mmcx connector board - what are your plans about the case front panel?
<azonenberg>
tentative plan is just a rectangular cutout that fits all of the connectors
<electronic_eel>
hmm, I don't like that, I'd prefer to have the connectors are on the edge of the case, sticking out a bit of the front panel
<azonenberg>
These connectors don't stick out very far
<electronic_eel>
and you probably can't move them without making the match worse or their mounting unstable, right?
<azonenberg>
MMCX-J-P-H-ST-EM1
<azonenberg>
look at the design. They sit in a cutout on the board edge
<azonenberg>
and are basically flush with the edge at the opening
<azonenberg>
my plan was to have the entire connector board stick out through a hole in the front panel so the connectors were flush with the front panel
<azonenberg>
but there'd be gaps between them that were just holes into the case
<azonenberg>
i need to sit down in solvespace and figure out some exact geometry
<electronic_eel>
how about some cutouts in the connector pcb between the connectors? that would reduce the hole size on the front panel and make it more stable
<azonenberg>
The connectors are on 8mm centers
<azonenberg>
the gap between connectors, edge to edge, is only 3 mm
<azonenberg>
not much cutout is possible there
<electronic_eel>
tight design
<azonenberg>
The mmcx plugs i measured are about 4.5mm wide so you'll have about a plug width between connectors
<azonenberg>
width*
<azonenberg>
3.5mm of gap then 4.5mm connector
<electronic_eel>
do me a favor and make the case / frontpanel geometry design before sending the MEAD boards to fab
<azonenberg>
(the 3mm number includes the copper on either side of the footprint)
<azonenberg>
That's the plan
<electronic_eel>
ok, you wrote about signoff checklist before, so I thought you plan on sending them to fab very soon
<azonenberg>
main MEAD board: needs soldermask openings over the RF traces, needs power/ground pours added (and possibly some slight rerouting of stuff to accommodate this), possibly some caps where signals change reference planes
<azonenberg>
also needs mounting holes for the mmcx board put in (they're on the mmcx board but i don't have matching holes on the main board yet)
<azonenberg>
once all of that is done and i've run through the layout review on that board too, i plan to order components from digikey
<azonenberg>
then do the enclosure design, once that's sanity checked against the boards then order pcbs + enclosure + stencils all at once
<electronic_eel>
ah, ok, so check the actual components against a printed paper mockup board and case
<azonenberg>
i'm not going to check the actual components as i dont have them yet
<azonenberg>
But any potential enclosure changes won't affect the BOM
<azonenberg>
so once layout review is done and i'm sure i'm not adding more caps etc it's safe to order parts
<electronic_eel>
right, but Digikey is fast, so you'll have the components a few days after ordering them
<azonenberg>
Yeah. But I dont see the point in a paper printout check as these are almost all parts i've used before
<azonenberg>
so footprints should almost all be known good
<electronic_eel>
maybe check lcd mounting
<azonenberg>
that is definitely something i want to look at
<azonenberg>
but without a mockup of the enclosure it will be tricky
<electronic_eel>
how much force do you need to pull a mmcx plug? can you do that with your fingers in a tightly spaced setup like this board?
bvernoux has quit [Quit: Leaving]
<azonenberg>
electronic_eel: amphenol RF's spec i found with a quick google is <30N (6.7 lbf) mating force, >8N (1.7 lbf) unmating force for the first five cycles of the connector, >4N (0.89 lbf) for the 500 cycle rated lifetime of the connector
<azonenberg>
there's no spec for max unmating force but i have never had trouble removing them with two fingers pinching the plug
<electronic_eel>
ok, and you think you can grab them with your fingers enough, when you want to pull the middle plug between populated connectors left and right?
<azonenberg>
Yes
<electronic_eel>
ok
<azonenberg>
I looked around for a recommended min pitch for mmcx and couldnt find one
<azonenberg>
Worst case, this board will be inexpensive to respin
<tverbeure2>
So when the scope has finished with AcquireData, what's the mechanism to retrigger?
<azonenberg>
we'd need a new enclosure if we space them further apart but there will only be one in existence, custom 3d printed, so it woulndn't be catastrophic
<azonenberg>
tverbeure2: Look at ScopeThread in glscopeclient/main.cpp:237
<azonenberg>
basically it sits there calling PollTrigger() in a loop and if it returns TRIGGER_MODE_TRIGGERED calls AcquireData(true)
<electronic_eel>
yeah, just wanted to ask if you thought this through to prevent any trouble, looks like you have
<azonenberg>
tverbeure2: The scope driver class is responsible for re-arming the trigger at the end of AcquireData() in continuous acquisition mode
<azonenberg>
and not doing so in single shot mode
<azonenberg>
note that scopehal continous mode is normally implemented by a series of single arm-and-download cycles on the scope, i.e. you never set normal/auto trigger on the scope itself
<azonenberg>
because you want to avoid race conditions where you download channel 1 from one trigger and channel 2 from another
<azonenberg>
so when in "normal" trigger mode in scopehal typically you will set single trigger then set a "not one shot" flag in the driver class, then at the end of AcquireData() you'd re-arm
<azonenberg>
See LeCroyOscilloscope:1459
<azonenberg>
LeCroyOscilloscope.cpp:1459 *
<azonenberg>
note that the LeCroy driver is optimized to re-arm the trigger as soon as it's *downloaded* the waveform data, then parse the data while the scope is already working on the next trigger
<tverbeure2>
Ok. I see that now.
<azonenberg>
i spent a lot of time tuning that driver for max WFM/s and minimizing time the scope and PC spend waiting for each other
<azonenberg>
It's not necessary to tune this much early on, but that's the sort of trick you need to do to squeeze max perf out of a system
<tverbeure2>
Was overlapping really worth it? How long does it really take to process 100M samples, when the processing is just a loop with rescaling?
<tverbeure2>
Compared to downloading, it's that time trivial?
<azonenberg>
It actually was not as trivial as i thought when you're running at high enough trigger rates
<azonenberg>
i recall like a 5% speedup or something in WFM/s?
<azonenberg>
actually no it was more than that
<azonenberg>
it was 20%
<azonenberg>
just found my notes
<azonenberg>
shaving a millisecond of latency here, a millisecond there really adds up when you're triggering several times a second
<tverbeure2>
BTW: right now, we have all these SCPITransport classes, but no general logging of SCPI commands. Any objections against adding logging in SCPITransport:SendCmd in a non-pure virtual method?
<azonenberg>
Any problem with just having LogTrace() calls in each SCPITransport class like we do now?
<azonenberg>
e.g. SCPISocketTransport.cpp:105
<azonenberg>
then you can just run glscopeclient --trace SCPISocketTransport to see that output
<tverbeure2>
Ok.
<azonenberg>
having to change your trace from SCPISocketTransport to SCPILXITransport or something seems like a non-issue as normally you will use one transport with a given instrument and change very infrequently
<azonenberg>
You can also trace SCPISocketTransport::SendCommand or something to get only tx logs, etc
<azonenberg>
This reminds me i should document liblogtools better too, lol
<azonenberg>
It's a tiny library but actually quite powerful
<azonenberg>
there's ~7 levels of logging depending on how you count
<azonenberg>
normal level is "notice"
<azonenberg>
then there's warning (printed with a yellow "WARNING:" before it automatically when logging to stdout/stderr)
<azonenberg>
error (printed with a red "ERROR:")
<azonenberg>
fatal, which is the same as error but aborts after printing
<azonenberg>
going the other way there's verbose, debug, and trace which isn't a log level per se
<azonenberg>
it's considered a subset of debug output that's filtered by class or class::function
<azonenberg>
this is done automatically by prefix matching the current function from compiler macros against the list of active traecs
<azonenberg>
traces*
<azonenberg>
you can tee logs to files, it automatically removes ansi color escape codes when doing so (unlike if you just pipe stdout to the file)
<azonenberg>
turn on/off line buffering
<azonenberg>
select whether to have error/warning go to stderr (default) or stdout
<azonenberg>
you can also indent by declaring a LogIndenter object, this is a RAII wrapper that increments the log by four characters for all lines printed subsequently. And the indent level is a thread local variable so if you have output from threads mixed it shows sane indentation
<azonenberg>
And all this in less than a thousand lines of code
<tverbeure2>
So I added a retrigger. But now when I click 'Stop', it takes a long time for it take. As if there's a lot of pent-up waveforms being in the queue or something.
<azonenberg>
Hmm. How long?
<azonenberg>
try adding some more logging to understand what's going on. i doubt the queue would be filling up, you described seconds per waveform with deep captures
<azonenberg>
the software should easily keep up with the scope that way
<azonenberg>
did you implement the toQueue stuff yet?
<tverbeure2>
Yes.
<azonenberg>
Try logging the number of messages in the queue at the end of AcquireData()
<azonenberg>
number of waveforms*
<tverbeure2>
After pressing STOP, it always does 4 triggers. Probably some dumb bug, maybe related to the number of channels.
<azonenberg>
That is an oddly specific number. and yeah i would suspect you probably are pushing the pending waveforms wrong, or something like that
<azonenberg>
each entry in the pending waveforms list is a SequenceSet containing a waveform or null for each channel. you should only push one pending waveform each AcquireData() call unless you have a multi-segment waveform
<azonenberg>
in which case each segment is considered its own waveform
<tverbeure2>
So the existing code didn't do any trigger arming at all. It might be that the WF? command itself arms by itself.
<azonenberg>
You didn't TRIG_MODE SINGLE?
<azonenberg>
in LeCroyOscilloscope::Start() or whatever override you may have
<tverbeure2>
Probably some interaction between the Siglent and LeCroy code.
<tverbeure2>
Anyway, something to check for later...
<azonenberg>
I note also that by default, glscopeclient enables all channels on the scope and arms the trigger when starting up
<azonenberg>
so if you didn't override Start(), the lecroy driver will do that
<azonenberg>
so you should have m_triggerArmed = true, m_triggerOneShot = false
<tverbeure2>
Yes.
<azonenberg>
My guess is that you're writing to m_pendingWaveforms wrong. Try logging some more details around that
<_whitenotifier-f>
[scopehal] azonenberg opened issue #132: Consider removing support for non-queued acquisition mode in Oscilloscope() - https://git.io/JfPmM
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #132: Consider removing support for non-queued acquisition mode in Oscilloscope() - https://git.io/JfPmM
<_whitenotifier-f>
[scopehal] azonenberg edited issue #132: Consider removing support for non-queued acquisition mode in Oscilloscope::AcquireData() - https://git.io/JfPmM
<_whitenotifier-f>
[scopehal-cmake] markrages opened issue #12: Build fails to compile. (const-ness problems) - https://git.io/JfPYH
<_whitenotifier-f>
[scopehal-cmake] azonenberg commented on issue #12: Build fails to compile. (const-ness problems) - https://git.io/JfPYQ
<_whitenotifier-f>
[scopehal-cmake] markrages opened issue #13: Build fails to link. - https://git.io/JfPYx
<azonenberg>
tverbeure2: can you look into that? ^
<_whitenotifier-f>
[scopehal-cmake] azonenberg commented on issue #13: Build fails to link. - https://git.io/JfPYh
<_whitenotifier-f>
[scopehal-cmake] markrages opened issue #14: Ubuntu needs `texlive-fonts-extra` to compile documentation. - https://git.io/JfPOv
<_whitenotifier-f>
[scopehal-cmake] markrages commented on issue #13: Build fails to link. - https://git.io/JfPOf
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #133: Cast to non-const for interop with old liblxi. - https://git.io/JfPOn
<azonenberg>
tverbeure2: why cast? then you risk crashing if liblxi modifies them (not that it should)
<tverbeure2>
What's the alternative?
<azonenberg>
my suggesting was actually allocating a writable buffer then copying to them
<azonenberg>
then freeing the buffer after
<tverbeure2>
Pffft. :-)
<azonenberg>
It's the safest and most portable option
<azonenberg>
I won't merge that as is
<tverbeure2>
Compared at all the other non-error checking in the code, and the fact that the previous version of liblxi didn't even had a const, this is such a minor thing. But I'll fix it.
<_whitenotifier-f>
[scopehal-cmake] markrages commented on issue #13: Build fails to link. - https://git.io/JfPO6
<azonenberg>
miek: did you have this problem too?
<azonenberg>
^
<miek>
yup
<azonenberg>
can you help him out then? And figure out if it's something we need to either document in the manual or fix in the code?
<miek>
i wasn't able to fix it earlier, i gave up and stepped my scopehal checkout back before the merge
<azonenberg>
Oh, lovely
<azonenberg>
Sounds like things are more broken on 18.04 than we thought
<_whitenotifier-f>
[scopehal-cmake] azonenberg commented on issue #13: Build fails to link. - https://git.io/JfPOQ
<_whitenotifier-f>
[scopehal-cmake] azonenberg edited a comment on issue #13: Build fails to link. - https://git.io/JfPOQ
<_whitenotifier-f>
[scopehal] tomverbeure synchronize pull request #133: Cast to non-const for interop with old liblxi. - https://git.io/JfPOn
<_whitenotifier-f>
[scopehal-cmake] markrages commented on issue #13: Build fails to link. - https://git.io/JfPO5
<tverbeure2>
Andrew, don't pull my lxi compilation fix just yet.
<azonenberg>
you have an off by one
<azonenberg>
in all of the new's
<tverbeure2>
Right. That's why. :-)
<azonenberg>
In case you're not familiar with my background, my day job is embedded systems pentesting
<azonenberg>
i literally do code reviews for a living (among other things)
<azonenberg>
So yeah stuff like that jumps out at me
<tverbeure2>
I think the cure here is worse than the disease, TBH.
<azonenberg>
I consider this a temporary fix. the proper solution is to deprecate liblxi <1.13 IMO
<azonenberg>
but i don't want to kill support for a current ubuntu version at this point
<azonenberg>
in a couple years when 18.04 goes EOL, i intend to remove all of this and define liblxi 1.13 as the minimum supported version
<azonenberg>
I would do that right now and say just install 1.13 from source, but if there's such an easy workaround in our code that seems preferable to adding more complexity to the build
<azonenberg>
I just really don't like casting away const-ness especially with string constants. It's so easy to have some dependency change under you that writes to the buffer and suddenly get mysterious segfaults or data corruption
<_whitenotifier-f>
[scopehal] tomverbeure synchronize pull request #133: Cast to non-const for interop with old liblxi. - https://git.io/JfPOn
<tverbeure2>
But I don't see how this fixes anything. If it's incorrect, you'll still be overwriting an allocated buffer. It's just a different one.
<azonenberg>
The inst0 was the thing i was most concerned about
<azonenberg>
if it wrote to that - unlikely, i know - you crash
<azonenberg>
anyway if you're happy with this as is i'll merge it
<tverbeure2>
Yes.
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #133: Cast to non-const for interop with old liblxi. - https://git.io/JfPOn
<_whitenotifier-f>
[scopehal] azonenberg pushed 4 commits to master [+0/-0/±4] https://git.io/JfP3m
<_whitenotifier-f>
[scopehal] tomverbeure a73fdcc - Cast to non-const for interop with old liblxi.
<_whitenotifier-f>
[scopehal] tomverbeure d99d069 - Replace all non-const casts by a buffer copy
<_whitenotifier-f>
[scopehal] tomverbeure b354f70 - Fix off by 1 buffer allocation.
<_whitenotifier-f>
[scopehal] azonenberg 7f624ee - Merge pull request #133 from tomverbeure/fix_lxi_const_compilation Cast to non-const for interop with old liblxi.
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #131: SCPILXITransport gives const-vs-non-const cast errors on liblxi <1.13 - https://git.io/JfP3s
<_whitenotifier-f>
[scopehal-docs] azonenberg closed pull request #6: Table with all existing Siglent scopes and their protocol support. - https://git.io/JfiKg
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfP3u
<_whitenotifier-f>
[scopehal-docs] tomverbeure 60c65e0 - Table with all existing Siglent scopes and their protocol support.
<_whitenotifier-f>
[scopehal-docs] azonenberg 3e98367 - Merge pull request #6 from tomverbeure/siglent_table Table with all existing Siglent scopes and their protocol support.
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfP3o