<azonenberg>
I would like to have LXI support for lecroy as well though. So if you want to backport selective un-batching, I'm OK with that
<azonenberg>
But i will want to be very cautious testing the PR to make sure we didn't break non-LXI operation
<tverbeure>
Ok. Maybe just some selective overriding might be sufficient.
<azonenberg>
Yes that's my hope. IIRC the main problem Error_404 ran into was the scope occasionally hanging and not returning a response to a command
<azonenberg>
so he was working on some retry code around that
<tverbeure>
For the LeCroy: definitely. Some of the Siglent code seems to be very scope dependent. For example, the header size of WF? DESC is currently hardcoded, but the header on my scope is different.
<azonenberg>
Yeah all of the lecroy stuff has a common sized WAVEDESC because MAUI is basically the same codebase everywhere
<tverbeure>
It's trivial to fix, but I'm just wondering how many of those Siglent scope specific issues there are.
<azonenberg>
the wavesurfer 3000 is siglent hardware running lecroy firmware so it acts almost the same although there's a few quirks like segmented capture not being supported for the LA
<azonenberg>
so we actually use the lecroy driver for it and add quirks
<azonenberg>
I fully expect there are going to be a lot of quirks. Especially as we start supporting older and newer hardware at once
<azonenberg>
I'm about to have breakfast and hop in the shower (yes it's 5pm for me, it's also a 3-day weekend during quarantine so bite me. Lol)
<azonenberg>
Gotta do a few chores around the house but my main focus for tonight is going to be a major facelift of the user manual, which hasn't been updated in months and there's been a lot of UI changes that need to be documented
<azonenberg>
i'll be in the channel if you have questions though
<tverbeure>
Ok!
<azonenberg>
Let me actually make a new ticket for the command batching stuff
<azonenberg>
since that will likely require more wide-reaching changes to multiple scope drivers, but you can probably get the basic lxi code up before we've backported that to everything
<_whitenotifier-c>
[scopehal] azonenberg opened issue #119: Add IsCommandBatchingSupported() method to SCPITransport - https://git.io/JfVY7
<Error_404>
ah, yes. I came to basically the same conclusion that I had to completely divorce the siglent and lecroy code
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
<azonenberg>
Error_404: was that because of command batching or other stuff?
<azonenberg>
tverbeure: maybe it would make sense to refactor the siglent driver so it's not inherited from lecroy anymore
<azonenberg>
even though they share some commonalities
<Error_404>
I believe it was due to the batching
<azonenberg>
Hmm
<Error_404>
because I didn't see a way to retain similar patterns to the lecroy driver -and- make batching/queuing of queries work
<azonenberg>
So in that case perhaps it would be easier to make a SCPIUnbatchedSocketTransport or similar class that just overrides SCPISocketTransport::IsCommandBatchingSupported) to return false
<azonenberg>
and make the lecroy driver check that before issuing a batched command?
<azonenberg>
Error_404: basically what i want to do is avoid having the lecroy driver break if you use it with LXI
<azonenberg>
because lecroy does support LXI on their scopes, i just use VICP on all of mine
<Error_404>
maybe. while I'm not sure the siglent issue is precisely solved by batching, I think the changes turning off batching will require should make retries trivial
<Error_404>
er, solved by not batching*
<tverbeure>
So right now, I simply removed batching in LeCroyOscilloscope::BulkCheckChannelEnableState() and after that, I'm finally able to fetch waveforms and display them. The displayed data is wrong, but I don't see any other batching going on. (I'd get some added warnings if there were... I think)
<tverbeure>
Before deciding to have an SCPIUnbatchedSocketTransport, wouldn't it be better to locate all the places where batching is used? In LeCroyOscilloscope::BulkCheckChannelEnableState(), the difference between batching and synchronous operation is trivial and a very small change.
<_whitenotifier-c>
[scopehal] tomverbeure forked the repository - https://git.io/Je54v
<azonenberg>
tverbeure: Yeah but AcquireData() also has a lot more batching
<azonenberg>
it was critical for performance, we're talking like a factor of two or more speedup
<azonenberg>
the siglent driver has its own AcquireData method though
<azonenberg>
it's possible it's wrong/incomplete
<azonenberg>
tverbeure: i think you should start by creating the IsCommandBatchingSupported method so i can start work on making un-batched stuff in the lecroy driver
<azonenberg>
as far as wrong data, can you quantify "wrong"?
tverbeure has quit [Remote host closed the connection]
tverbeure has joined #scopehal
<tverbeure>
Wrong as in: instead of a nice square wave, I get random spikes. I'm debugging...
<azonenberg>
tverbeure: why is did you add Measurement.cpp to scopehal/CMakeLists.txt?
<azonenberg>
is your PR based on an older version of my code? The Measurement class no longer exists
<azonenberg>
other comments: use new/delete for memory management vs malloc/free since those are the native C++ operators
<azonenberg>
also formatting, libscopehal uses Allman/Visual Studio style brace formatting (curly brace on its own line, not the same line as the if statement)
<azonenberg>
and a single \t character providing a four column indent
<azonenberg>
your indents look OK but i see some gnu-style bracing
<azonenberg>
also Measurement.h in scopehal.h was added and ProtocolDecoder.h was deleted, that's also wrong
<tverbeure>
Older version of the code: I've been copying files back and forth because I don't know how to clone a project that uses git submodules...
<azonenberg>
Yeah submodules are unfortunately a bit painful to work on. If you do good work for a while i can set you up with commit access to master which will solve the problem
<azonenberg>
but i'm not aware of a good intermediate
<azonenberg>
I think the best option is for you to have a checkout of the full scopehal-cmake repo
<azonenberg>
then when you make a change to a submodule, explicitly push to your fork
<azonenberg>
i.e. git push git@github.com:tomverbeure/scopehal
<azonenberg>
but this way your working copy still tracks upstream
<azonenberg>
this is what i did when i had to make a private fork of jtaghal for supporting a client's product
<azonenberg>
tverbeure: ok i merged your PR with some minor edits, added the batching method we discussed, and updated BulkCheckChannelEnableState to properly check if we support batching
<tverbeure>
Thanks for the edits. :-)
<_whitenotifier-c>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±8] https://git.io/JfV4E
<_whitenotifier-c>
[scopehal] azonenberg bb56e70 - Updated to latest xptools
<_whitenotifier-c>
[scopehal] azonenberg e04e0a0 - Added SCPITransport::IsConnected() for error checking
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±3] https://git.io/JfV42
<_whitenotifier-c>
[scopehal-apps] azonenberg c2fde78 - Fixed crashes and misbehavior when trying to connect to an unreachable instrument. Fixes #82.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #82: Crash after failing to reconnect to an unavailable scope when loading a session - https://git.io/JviAe
<_whitenotifier-c>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfV4a
<_whitenotifier-c>
[scopehal-docs] azonenberg 9434abd - Added documentation for top level menus. Added renders of color ramps.
<_whitenotifier-c>
[scopehal-docs] azonenberg pushed 1 commit to master [+4/-0/±5] https://git.io/JfVEG
<_whitenotifier-c>
[scopehal-docs] azonenberg 7df623f - Documented several more dialog boxes. Updated more documentation for recent UI changes etc.
<Degi>
Is m_transport->SendCommand("wAV:FORM BYTE") sending :WAV:FORM BYTE?
<azonenberg>
there should be no leading colon
<Degi>
*Looks into Rigol DL3000 "DC electronic load" guide* Huh, this looks weird for a scope
<azonenberg>
SendCommand() should literally send the text you gave it as is
<azonenberg>
if you want a query, add the ? yourself
<azonenberg>
i think it adds a newline but that's it
<Degi>
Hm okay
<Degi>
Huh, MSO5000 has a FRAM for system setting
juli964 has joined #scopehal
<Degi>
Hmh working on rigol driver now
<Degi>
I added attenuation as a big switch case, is that OK?
<azonenberg>
Degi: you mean for probe attenuation?
<azonenberg>
if the scope only supports fixed values, then sure
<azonenberg>
lecroy supports arbitrary values so that wouldn't work there
<_whitenotifier-c>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfVgG
<_whitenotifier-c>
[scopehal-docs] azonenberg 430ff3a - Lots of updates to filter section of manual
<Degi>
Hm yeah
<azonenberg>
It's very likely rigol only supports 1x/10x
<azonenberg>
in which case a switch is fine
<Degi>
It is nearly 100 lines long now heh
<azonenberg>
Lol
<Degi>
0.0001 to 10000
<Degi>
*50000
<azonenberg>
... oh. You might want to come up with something more efficient then
<Degi>
Hm is there a preferred way to turn a double into a (formatted) string and send it over SCPI? Can I just do "char buf[50]; sprintf(buf, "%f", offset); m_channels[i]->GetHwname() + ":OFFS" + buf"
<Degi>
Idk is switch case inefficient?
<azonenberg>
well a switch on floats is a bad idea as roundoff error etc can make exact comparisons hard
<azonenberg>
and yes i would do exactly that
<Degi>
Hmh I do a switch on int, it complained that it wont switch on double
<azonenberg>
actually, i'd probably build the whole string with snprintf (to properly bounds check)
<azonenberg>
and just SendCommand(buf) after
<Degi>
How big should buf be?
<Degi>
"switch ((int)(atten * 10000 + 0.1))" turns it into an int with proper rounding
<azonenberg>
I'd store attenuation as a float internally
<azonenberg>
re buffer size, figure out how long the command can be and add some margin
<Degi>
Hmm maybe I should've done git pull before
<azonenberg>
or be lazy and do something like 128 bytes because there's no way your string is going to be that long
<azonenberg>
yes there has been a lot of refactoring lately
<apo>
azonenberg │ or be lazy and do something like 128 bytes because there's no way your string is going to be that long <- hold my beer
<azonenberg>
apo: well snprintf will still bounds check, but you should be able to easily statically verify that it can't overflow
<azonenberg>
because channel names have a fixed length as does the command, and floats have a defined max length in ascii
<Degi>
I mean its not like we're ram limited noadays. Can I just do buf[9999999999]?
<Degi>
lol
<azonenberg>
lol
<azonenberg>
that is not a PR i'd merge :p
<Degi>
*Actually implements this in electron*
<Degi>
And the MSO5074 doesnt seen to have a channel:RANGE thing, not sure...
<azonenberg>
Degi: might be volts/div or similar
<azonenberg>
scopehal natively uses full scale range as the measurement for this, but different scopes handle it differently
<azonenberg>
It's very likely the rigol driver will need quirks added for specific scope families due to differences in APIs
<azonenberg>
lecroy already has several
<Degi>
I kinda implemented that
<Degi>
Made an ENUM for MSO5 and DS, though not sure how they differ
<azonenberg>
Yeah. We can refine the list of models etc later on once we have a better idea of what quirks are needed
<azonenberg>
sample rate etc will vary by scope family too
<azonenberg>
that's the main thing i added
<azonenberg>
for populating the dropdown in the timebase config dialog
<Degi>
Hmh what is meant with ResetTriggerConditions or is there somewhere a list of the functions and what they should do?
<azonenberg>
Oscilloscope.h has doxygen comments for everything
<azonenberg>
that's actually a legacy function from old logic analyzer trigger stuff that is likely to be removed at some point
<azonenberg>
i'm going to probably do a major retooling of pattern trigger support at some point
<Degi>
Oh I guess I kinda misunderstood SCPI then? Because in hte command manual for the rigol, there's : before every command
<azonenberg>
all i can say is, this worked on ds1000z
<azonenberg>
it was incomplete, but the functions i had worked
<azonenberg>
there might be an optional leading colon for commands that don't operate on a channel
<Degi>
But there doesnt need to be one?
<azonenberg>
but if it works without, leave it off since we know it worked on DS1000Z
<Degi>
Hmmmm okay
<azonenberg>
Try it and find out :)
<Degi>
Can I just open netcat on the scope to try out?
<azonenberg>
If you DO need it, then we need to either test on DS1000Z with, or add a quirks mode
<azonenberg>
Yes
<azonenberg>
port 5555 iirc. Which is not the IANA default for SCPI over TCP, which is annoying
<Degi>
Hm yes works with and without leading :
<noopwafel>
ds1054z is also happy with leading colons, if that helps
<Degi>
I mean the manual says that there are leading colons everywhere
<azonenberg>
I'd say use without then
<azonenberg>
because that's one less byte going over the link, might be a bit faster
<azonenberg>
unless there's a reason to keep them, omit them
<azonenberg>
i used abbreviated commands for the same raeson
<noopwafel>
it also does vxi11 but it's too painfully slow to actually use, so glad you're not trying that :)
<azonenberg>
noopwafel: lol
<azonenberg>
tverbeure has a siglent that only does vxi11
<azonenberg>
and either that scope or vxi11 doesn't support command queueing
<azonenberg>
which is proving to be a pain in the butt
<azonenberg>
noopwafel: are you using scopehal actively yet?
<azonenberg>
or waiting on the rigol driver to be more well developed?
<Degi>
Now it gets stuck at "Connecting to SCPI oscilloscope at 192.168.1.10:5555" just like last time I tried...
<noopwafel>
azonenberg: waiting to have time to write pico driver
einthecorgi2 has joined #scopehal
<azonenberg>
Degi: pcap it and see what happens?
<azonenberg>
also does gdb give any hints as to where the hang is?
<azonenberg>
noopwafel: so you aren't using it on your rigol gear?
<azonenberg>
also i sent you some of those solder in scope probes a while back that i made right?
<azonenberg>
did you ever try them out? how did you like them?
<Degi>
Hmm gdb... I've never used that seriously, I'd need to take a look at that
<noopwafel>
azonenberg: I did actually use a couple of them with a higher-bandwidth scope for debugging some signal problems, I remember it was mostly super convenient having something I could solder in place (and it worked a lot better than normal passive probes and wires, at least)
<noopwafel>
but right now my work is taking 200% of my time
<azonenberg>
ah
<azonenberg>
reason i was asking is if you had any feedback, i plan to respin them soon
<azonenberg>
new gen version will be targeting higher bandwidth and probably use an edge launch connector
<azonenberg>
and probably a higher quality resistor or string thereof
<azonenberg>
possibly a longer tail as well
<azonenberg>
but sam ebasic idea
<noopwafel>
any idea of your timeline for that? because if it goes beyond a couple of weeks, would be super happy to use them again, no shortage of things on the TODO list to debug
<azonenberg>
Longer time frame. I'm still fine tuning the handheld probe
<Degi>
Hmh I get "sendto(10, "CHAN1:RANGE?\n", 13, 0, NULL, 0) = 13" "recvfrom(10, <unfinished ...>" "+++ exited with 0 +++"
<azonenberg>
speaking of which if you want to get in on the kickstarter there's only a few days left
<azonenberg>
my plan is to do another board rev or two on the handheld probe then use the techniques and test results from field solver testing of it to fine tune the solder-in version over probably 1-2 new iterations
<Degi>
Ahh I see, ofc there is no range and it gets hung
<miek>
you might want to run glscopeclient with '--trace SCPISocketTransport' to print what's being sent back and forth
<Degi>
Thanks! yeah
<azonenberg>
yeah there are a lot of useful debug logging/tracing features built in for this sort of stuff
<azonenberg>
single stepping a complex multithread ed program is often not viable for high level system debug, only for finding segfaults and stuff
<azonenberg>
so i have lots of instrumentation
<Degi>
Rigol, why... Now I request scale and simply multiply by 8
<Degi>
Woo it got a bit further
<Degi>
Does scopehal automatically find scope model? Like that it is a MSO5074? Does it get that from a SCPI command?
<Degi>
Ah yes I see, *IDN
<azonenberg>
Yes, SCPIOscilloscope's constructor should populate the fields for that automatically
<Degi>
Wow. DS1000Z: TRIGger:EDGe and MSO5000: TRIGger:EDGE whyy rigol
<azonenberg>
lol
<azonenberg>
Good news is EDGE is a valid response for both
<azonenberg>
So if we use that, no quirks required
<Degi>
Yes I did that. Whyy
<Degi>
Woo I get something
<azonenberg>
Degi: i suspect fw for the different scopes was written by different teams and didnt quite maintian compatibility
<azonenberg>
This is one of the things i like about lecroy stuff
<Degi>
Hm eah
<azonenberg>
MAUI/XStream is a single unified codebase for basically all of their scopes. The PCIe driver for the acquisition boards is likely a very different interface from scope to scope but that's a private API
<miek>
i think there's a spec somewhere for how SCPI commands can be abbreviated, and iirc it has some weird exceptions and such so i can see why they'd get mixed up
<azonenberg>
the public API is either COM Automation or SCPI, and those interfaces are stable all the way from monochroma's windows XP based DDA5005A up to a modern multimillion dollar labmaster
<monochroma>
azonenberg: i don't know if you saw the backlog, but before einthecorgi2 timed out electronic_eel was introducing them to the hardware projects we are working on. they had said they were interested in working on them
<azonenberg>
Yeah i saw that
<azonenberg>
i've been talking to corgi for a while on twitter about scopehal etc
<monochroma>
ah :D
<Degi>
How do I change timebase and scale in scopehal?
<Degi>
It works now!, Ill do a pr later
<azonenberg>
Degi: :)
<azonenberg>
Awesome
<einthecorgi2>
monochroma: thanks
<azonenberg>
Degi: in the glscopeclient GUI you mean? or in the scopehal API
<Degi>
In the gui
<Degi>
(I hope it doesnt require middle mouse button lol)
<azonenberg>
double click the timeline at the top of the viewport
<azonenberg>
a dialog should pop up with the legal sample rate/depth values
<azonenberg>
if you haven't implemented GetSampleRatesNoninterleaved() and GetSampleDepthsNoninterleaved() obviously it won't do anything
<azonenberg>
the interleaved functions should be left as default for now
<azonenberg>
i.e. empty
<azonenberg>
because channeel interleaving is still a WIP
<azonenberg>
i havent finished defining the APIs for it
<azonenberg>
degi: yes, although it seems there are some issues with the gtk theme causing the text to not show up
<azonenberg>
that background should be dark
<Degi>
Yes I have white parts everywhere
<azonenberg>
something in themes/glscopeclient.css needs fixing then
<Degi>
I guess thats the downside of arch linux lol
<Degi>
Huh css, neat
<azonenberg>
no this is because i have a custom GTK theme that overrides a bunch of stuff but apparently not enough
<azonenberg>
there's likely some default values for certain classes that need to be explicitly specified rather than left blank
<azonenberg>
file a bug report and mention what gtk theme you are using
<Degi>
Is that dialog for x and y scale?
<Degi>
(What is a gtk theme? I think id look that up)
<azonenberg>
that dialog is for timebase only, there's one combobox for sample rate and one for memory depth
<Degi>
GetSampleRatesNonInterleaved should just return the uint64 vector and doesnt need to communicate with the scope right?
<azonenberg>
Correct. It needs to know the set of sample rates supported by the scope (in Hz)
<azonenberg>
but that should just be a switch on the scope model
<azonenberg>
GetSampleRate() does need to talk to the scope since it returns the *current* rate
<azonenberg>
also, i dont know how much is in the rigol driver yet
<azonenberg>
but in general you should be aggressively caching settings rather than polling the instrument for the current sample rate etc every waveform
<azonenberg>
ok yes the toolbar background should be dark too
<azonenberg>
so you definitely have some interop issues between your theme and the glscopeclient dark theme
<Degi>
Maybe I dont have a theme or something and something bugs out
<azonenberg>
no you have one, look at the opacity slider
<azonenberg>
it's the normal application theme selected in "appearance settings" or similar
<azonenberg>
for whatever your desktop environment uses
<Degi>
I probably dont even have an appearance settings program lol
<Degi>
Ah I see, xfce4-appearance-settings
<azonenberg>
I did my development using clearlooks-phenix which is a gtk3 port of the classic gtk2 clearlooks theme, which is itself a slightly rounded windows 2000 style appearance
<azonenberg>
i'm not at all surprised to see that other themes break it as i've never actually tested :p
<azonenberg>
anyway yeah file a bug report
<azonenberg>
Degi: do you not have a 3 button mouse btw?
<Degi>
MMB is kinda stuck and requires a bunch of pressure and sometimes double clicks
<azonenberg>
oh just the clikc button
<azonenberg>
you have a working wheel though?
<Degi>
yesd
<azonenberg>
i make heavy use of the scroll wheel, it's the only way to change gain (scroll wheel on the Y axis) or zoom scroll wheel on the plot area) at the moment
<Degi>
Ohhh
<azonenberg>
better laptop mode support is a wishlist item
<Degi>
I can just scroll and it changes the timebase
<azonenberg>
It changes the display timebase
<azonenberg>
glscopeclient completely decouples the acquisition and display
<Degi>
Changing gain doesnt seem to work when I scroll on the y axis label area
<azonenberg>
the timebase dialog that you had display errors on sets the memory depth and sample rate
<azonenberg>
the scroll wheel sets the display scale, and dragging the timeline up to pans the waveform horizontally
<azonenberg>
(eventually i will do zoom-to-center and not zoom-to-left-side, that's just me not having a chance to sit down and fix the zoom code)
<azonenberg>
Degi: is SetGain() not implemented yet? :p
<azonenberg>
or SetVoltageRange() i think is the name
<azonenberg>
when i left off, the Rigol driver was mostly read only
<azonenberg>
it couldnt' change most settings, only pull waveforms
<Degi>
Ohh
<Degi>
Oh no is that gonna end up like the big switch case loal
<azonenberg>
Lol hopefully not, it should just be a snprintf("%s:RANGE %f" or similar
<azonenberg>
anyway before we forget, file a ticket for the UI/theme issues so i can look into them
<azonenberg>
if you tell me what theme you had the problems on i can try and reproduce
<azonenberg>
einthecorgi2: so regarding the hardware stuff are you comfortable with kicad? and what's your level of familiarity with where the project stands now?
<_whitenotifier-c>
[scopehal] x44203 opened issue #121: GTK theme is broken, white areas - https://git.io/JfVoJ
<Degi>
Hmm should I enable vernier adjustment?
<azonenberg>
Degi: can you reopen that against scopehal-apps?
<azonenberg>
this is a UI issue not a core library issue
* monochroma
thinks azonenberg should unify the repos >.>
<azonenberg>
and yes, probably. glscopeclient's UI likes being able to make relatively small step changes to vertical scale if possible
<azonenberg>
monochroma: that's a whole other problem and one i'm not about to try solving today
<_whitenotifier-c>
[scopehal] x44203 closed issue #121: GTK theme is broken, white areas - https://git.io/JfVoJ
<_whitenotifier-c>
[scopehal-apps] x44203 opened issue #105: GTK theme is broken, white areas - https://git.io/JfVoO
<azonenberg>
also, just reproduced on my end on adwaita, looks fine on clearlooks
<azonenberg>
Actually even more interesting
<azonenberg>
it looks fine on clearlooks-phenix and not on clearlooks (i guess that got updated to gtk3 now?)
<azonenberg>
in fact, lol
<azonenberg>
It appears that the theme i developed on is the ONLY gtk theme installed on my system that does not exhibit this bug
<Degi>
lol
<Degi>
Hmh whats the difference between sprintf and snprintf
<azonenberg>
snprintf takes an extra argument for size of the buffer
<azonenberg>
sprintf should never be used as it has no bounds checking
<Degi>
Uhh ok
<azonenberg>
snprintf(buf, sizeof(buf), format, ...)
<azonenberg>
if your format string/args are too long sprintf will happily overwrite memory as long as you let it
<Degi>
Hmh sprintf doesnt include sizeof(buf) somewhere?
<azonenberg>
No
<azonenberg>
sprintf, strcpy, gets, etc are all old C functions from the dark ages that just assume your input is safe
<azonenberg>
none should ever be used in modern code
<lain>
sizeof(buf) only works on arrays of a (compile-time) fixed length anyway. C/C++ arrays don't carry any length metadata
<Degi>
huh
<lain>
have to use C++ STL containers for that, like std::vector
<azonenberg>
while it is possible in some cases to use them safely if you control all of the inputs 100%, it's very difficult to be certain that they're safe and so good engineering practice says to simply not use them
<azonenberg>
Yeah
<Degi>
"Sending �����:SCALE 2.222222" What is the weird characters? I have "snprintf(buf, sizeof(buf), "%s:SCALE %f", m_channels[i]->GetHwname(), range / 8);"
<azonenberg>
Degi: you're sending the std::string object, not the underlying c string
<azonenberg>
you want GetHwname().c_str()
<einthecorgi2>
azonenberg: I am pretty comfortable with anything RF up to a couple Ghz from design in KiCad to prototype and test. Most of my equipment covers me to 3Ghz. I have been working more with highspeed ADCs recently. I just finished an FPGA sampling interface for a 120MSPs 12bit with 32M SRAM buffer.
<azonenberg>
einthecorgi2: awesome
<azonenberg>
ok so, right now here's where we are with prototyping
<Degi>
Hmh how can I add bandwidths? The context menu only says something about 20 M and 200 M
<azonenberg>
the BLONDEL analog frontend is designed, tested, and needs a bit more characterization and some minor edits bue mostly is done
<einthecorgi2>
yes, I have seen your progress on this.
<azonenberg>
Degi: there's an open ticket somewhere for creating an API to query this
<azonenberg>
as of now, you don't
<azonenberg>
that list is hardcoded
<Degi>
oki
<azonenberg>
einthecorgi2: anyway, so the FPGA processing board is on hold until we finish the stuff that plugs into it
<Degi>
Hmm neat, when I scroll the y axis the program hangs up
<azonenberg>
we can't do the final ADC+AFE board until we've worked out the details of th eactive probe interface
<azonenberg>
then MEAD, the 50 ohm input LA pod, i need to sit down and work on some time soonish
<azonenberg>
So i think the part that would be most in need of third party contribution at this point in the design is the active probe interface
<azonenberg>
how familiar are you with the basic goal there?
<einthecorgi2>
I have only been following the passive probe progress, is it documented or should I just got through the iirc logs?
<azonenberg>
well right now we don't have active probes
<azonenberg>
This is the interface for an as-yet-nonexistent active probe
<azonenberg>
the basic idea is, we dont have the pull of keysight etc to make fancy integrated coax+control+power cables
<azonenberg>
So to keep things simple and low cost the active probes will have two cables
<azonenberg>
a standard SMA connection for data, and something else for power and control
<einthecorgi2>
ah okay, so protected power and some communication itnerface?
<azonenberg>
We wanted something readily available, low cost, and commodity cables
<azonenberg>
The tentative decision was usb-c
<Degi>
"data" heh
<azonenberg>
in order to keep the probes relatively simple and low noise, we wanted to avoid heavy SMPSes etc on them
<Degi>
Hmh we could glue a USB C to a SMA?
<azonenberg>
So the tentative plan is to define a custom usb alternate mode that connects TX+/TX- to +7VDC and RX+/RX- to -7VDC
<einthecorgi2>
oh, I could see that working, as long as we where sticking to using the USB interface and not just using it as a cable. There are lots of low cost chips with USB that can go into the probe head.
<einthecorgi2>
ah
<azonenberg>
then uses either the PD or usb 2.0 data lines to configure gain/offset
<azonenberg>
and Vbus to power the MCU that negotiates this mode
<azonenberg>
We need to fine tune the details of this interface and prototype it
<azonenberg>
so basically the deliverable for this project would be two boards, a host that takes in +12V and a uart for control/status
<Degi>
Hmh yes, if I scroll the voltage scale too fast it gets hung. And it doesnt change the scale, it sends the same value all the time for some reason
<azonenberg>
then has a usb-c port for talking to the scope
<azonenberg>
to the probe*
<azonenberg>
then a device that takes in a usb c port and outputs +/-7V DC
<azonenberg>
and i2c or something for talking to an offset dac etc
<einthecorgi2>
I would be up for this. Is there a particular microcontroller that is being used throughout the designs?
<azonenberg>
with negotiation over either the PD channel or usb 2.0 data lines to ensure that if you plug a "real" USB device into either the probe or scope, nothing fries
<azonenberg>
i.e. don't turn on the +/-7V power until you're sure you are talking to one of our probes
<azonenberg>
So far we've been using STM32s but are not tied to any specific model. The general plan for the scope is to have a F777 as the master MCU for all of the control plane stuff, scpi parsing, etc
<azonenberg>
an artix-7 for the data plane
<einthecorgi2>
okay.
<azonenberg>
then a small MCU on the acquisition card for running the usb interface with a uart/i2c/spi link back to the f777
<azonenberg>
either one per channel or one for all four channels on the card, whatever makes more sense
<azonenberg>
The phase one deliverable is a standalone development platform for prototyping this, it does not need to be integrated into a larger system
<einthecorgi2>
the +/-7V is pretty low current. What about generating it at the head? I guess it would be more difficult to protect against the DC/DC noise generated.
<azonenberg>
the goal is basically just to define the interfaces and verify that the power delivery works
<azonenberg>
That was the idea
<Degi>
Sometimes it hangs on WAV:DATA? after I try to change y scale for some reasion
<azonenberg>
Degi: are you not mutexing around the various io calls?
<azonenberg>
the scope polling/waveform download is in another thread
<azonenberg>
so if you don't properly lock access from the main thread Bad Things will happen
<azonenberg>
again see the lecroy driver for example
<azonenberg>
einthecorgi2: with a usb 3.2 cable you can have four wires (2 diffpairs) for each of +7 and -7
<azonenberg>
we did some math and it shouldnt be a big deal, an active probe isnt super high current
<azonenberg>
the tentative plan is to have the +/-7 be inputs to LDOs on the probe head for +/-6
<azonenberg>
which will be the actual analog supply rail on the head
<Degi>
I have "lock_guard<recursive_mutex> lock(m_mutex);" at the beginning of my function
<azonenberg>
that should be ok then
<azonenberg>
packet sniff and see what's going on?
<azonenberg>
einthecorgi2: Try to avoid being super tightly tied to 7, we might do 8 or 12 or something too, but 7-8 seems reasonable if we are going to LDO to +/-6
<einthecorgi2>
okay, so those will come from the mainboard. Alright I could start on this for sure. Ill start with a block diagram and then go from there.
<Degi>
Yes it gets hung oon WAV:DATA? presumably because the scope doesnt return anything
<einthecorgi2>
easy
<azonenberg>
einthecorgi2: the mainboard will supply +12 to the frontend board
<azonenberg>
which will generate various intermediate voltages for its own internal use
<azonenberg>
odds are there will be a +/-7V rail on the actual frontend that you can just mux on and off of D+/D-
<azonenberg>
but for your prototype board generate them yourself so it can run from a single supply
<Degi>
We could use a synchronous buck converter to make +- rail voltages with a coupled inductor.
<einthecorgi2>
okay, and is there a standard IC being used for the negative rails or just any switched capacitor IC?
<azonenberg>
i was thinking a buck converter not a charge pump
<einthecorgi2>
okay
<azonenberg>
look at the schematic for the current AFE
<einthecorgi2>
will do.
<Degi>
Yeah either inverting if you wanna convert positive to negative or a synchronous buck with coupled inductors if you want to convert like 12 V to +- 7 V with 1 inductor / IC
<einthecorgi2>
I think that is a good approach. I will be sure to add loads on the rails.
<azonenberg>
einthecorgi2: Do your work in a fork of the starshipraider repo under the boards/BLONDEL and firmware/BLONDEL directories
<Degi>
Hmh is it possible to timeout ReadRawData()?
<azonenberg>
Degi: no, that is something Error_404 ran into as well
<azonenberg>
it would be a good thing to add
<einthecorgi2>
okay, I was just about to ask where. thanks.
<azonenberg>
you'd likely have to replace Socket::RecvLooped() in azonenberg/xptools with a separate function that has a timeout
<azonenberg>
einthecorgi2: if we see good work for a while you can eventually get commit access to the main repo but working in a fork for now is probably going to be easier to integrate later on than you making your own for the R&D
<einthecorgi2>
understandable.
<azonenberg>
einthecorgi2: another thing that we want, which you could probably be helpful on, is a low cost active high-impedance probe with low bandwidth
<azonenberg>
since our scopes are 50 ohm input, if you need high Z for probing i2c or something with a pullup you need an active probe
<azonenberg>
so we want to build a really cheap high impedance probe with like 100 MHz bandwidth
<azonenberg>
As well as probably a higher performance active differential probe
<azonenberg>
Those are also nice standalone projects that will tie into the larger ecosystem we're building here, but won't step on the main scope boards which are kinda my project
<azonenberg>
and while design reviews/comments are welcome on those, kicad doesnt really handle multiple engineers working on a single board very well IME
<azonenberg>
so i want to remain the only person actually working on sch/layout for that for now
<azonenberg>
probes, LA pods, etc are nice standalone subsystems that are easy to hand off to another engineer
<einthecorgi2>
yeah I have seen some resources for this and a couple other projects for active probes. I made a differential active probe that was good to 50Mhz but was not low cost.
<azonenberg>
The ultimate vision is the AKL-PT1 (internal codename HALL) for general purpose mid to high speed probing
<einthecorgi2>
I will start to take a look at what amplifier would suit this application.
<azonenberg>
for low speed single ended stuff with high impedance BRAUN, the cheap active probe. I was eyeing the ADA4817-1ACPZ-R7 but have not made a final decision
<azonenberg>
and for high speed differential a not-yet-named high speed active diff probe
<azonenberg>
Your first priority should be the probe power/communications platform
<azonenberg>
because we need that to be figured out before we can do the acquisition board for BLONDEL, because the probe host interface is on the same board
<azonenberg>
We can design the probes later on, but we need the interface defined ASAP
<Degi>
Hm will the probes have a µC on them? Then we could USB instead of I²C though not sure if that makes any sense
<einthecorgi2>
ADA4817-1ACPZ-R7 is nice
<azonenberg>
Degi: yes they will have a micro of some sort. i'm a bit unsure on the actual communications interface
<azonenberg>
but i think usb low/full speed is probably the most logical
<azonenberg>
we will need to be careful to not couple noise into the analog side of the probe
<azonenberg>
high speed is totally unnecessary of course
<Degi>
Hm yes, OP amp noise should be considered...
<azonenberg>
my thought is to run the micro off of the vbus rail then push i2c/spi to the DACs and such in the probe frontend
<azonenberg>
keeping the LDO's +/-6V rails super clean and quiet
<azonenberg>
maybe even separate emi can over the frontend
<Degi>
For example that OP amp would add 40 µV of noise at 100 MHz judging by its noise value at 100 kHz...
<Degi>
Maybe add a peltier cooler xD
<azonenberg>
lol
<azonenberg>
einthecorgi2: did electronic_eel talk to you about the longer term roadmap wrt faster scopes?
<einthecorgi2>
yes, briefly. I went through it on git and I have been checking out the related ICs.
<Degi>
What does "m_channelVoltageRanges.find(i) != m_channelVoltageRanges.end()" do?
<azonenberg>
Degi: find() returns end() if the thing you're searching for isn't in the set
<azonenberg>
i'd have to see context but i think that's checking if there's a cached voltage range for that channel
<azonenberg>
and if so, return that rather than polling the instrument
<Degi>
Ohh ah, I need to add a m_channelVoltageRanges[i] = range; to set voltage
<azonenberg>
round trips to the scope are slow especially over usb
<Degi>
USB slower than LAN?
<azonenberg>
usb has like a 1ms minimum round trip latency
<azonenberg>
because of the TDMA
<Degi>
lol
<azonenberg>
ethernet can be in the tens of microseconds or low hundreds easily
<Degi>
Hmh TDMA? It doesnt use sender signal cancellation? weird
<azonenberg>
um, lol
<azonenberg>
usb is half duplex
<azonenberg>
usb 2.x at least
<Degi>
Welp
<azonenberg>
it's one fake differential pair that isnt even true differential
<Degi>
Ah yes
<Degi>
Hmh okay I still have the issue with it getting stuck on WAV:DATA? when I scroll too fast, but voltage range is adjustable now
<azonenberg>
that runs on a 1ms scheduling interval, although usb 2.0 splits them up into 125us micro frames that i dont know the full details of
<azonenberg>
but even so, to get good performance with tens or more waveforms per second, you need to keep the number of total polls/roundtrips to the scope low
<Degi>
Why do some "Sending..." have a different amount of leading spaces, weird
<azonenberg>
Degi: That's an artifact of the logtools framework not keeping track of indentation per thread yet
<azonenberg>
when you create a LogIndenter object all log events in that scope are intented by one level
<azonenberg>
but that also applies to log messages in another thread
<Degi>
huh
<azonenberg>
so as logindenters in one thread are created and destroyed you will see leading spaces come and go
<azonenberg>
it's annoying but i've been too busy with higher priority stuff to sit down and make that a thread-local-storage value like it should be
<Degi>
Hmm I added a timeout to RecvLooped and it still gets stuck, somewhere else presumably
<Degi>
Hmm :/ scopehal kinda slow with 100 megasamples of data
<azonenberg>
lol 100 MS? on a rigol? i didnt know they could go that far
<azonenberg>
But yes that is a substantial amount of data. There's definitely room to optimize further
<Degi>
Did scopehal just eat a few gigs of ram...
<Degi>
Huh like > 4 gig after a short while
<azonenberg>
did you turn history on?
<Degi>
Idk i dont think so
<azonenberg>
pop up the history dialog
<azonenberg>
see what it says
<azonenberg>
if you have 100M points it will eat memory fast
<Degi>
Where is that?
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfVP2
<_whitenotifier-c>
[scopehal-apps] azonenberg 2372921 - Styles: various fixes for better compatibility with other GTK themes. Fixes #105.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #105: GTK theme is broken, white areas - https://git.io/JfVoO
<azonenberg>
Degi: the "search" toolbar icon, fourth from left
<azonenberg>
also try that new commit to see if it fixes your UI problems
<Degi>
Yes it says max waveforms 10
<azonenberg>
and at the bottom
<Degi>
Do I need to commit my changes before pulling?
<azonenberg>
it should show memory usage from historical waveforms
<Degi>
1.86 GB with 250000 points
<Degi>
Hmm so 186 GB with 25 M points
<azonenberg>
you shouldnt need to, unless you changed the theme file yourself i wouldnt expect any merge conflicts
<azonenberg>
Degi: well 250M points if you have ten waveforms
<azonenberg>
times four channels is 1G points
<azonenberg>
186 bytes per point still sounds a bit high though. it should be more like 20
<Degi>
Hmh when I do git pull it says that im not currently on a branch
<azonenberg>
ah yeah submodules being derpy...
<Degi>
Meh ill just fork the scopehal repo and push to that and then send a PR assuming you didnt change anything of the rigol stuff in the last few hours,
<azonenberg>
Degi: normally what i do is, after i pull the latest of all submodules, i go into each submodule dir and "git checkout master"
<azonenberg>
which lets me track upstream on each submodule separately
<azonenberg>
then i can push from the submodule dir directly to upstream like a normal repo
<azonenberg>
Degi: also can you confirm the UI issue is fixed?
<azonenberg>
Going to sleep, it's 8 in the morning and i've been up since around normal-people-lunchtime yesterday :p
<Degi>
Oki ^^
<azonenberg>
(did i mention my sleep schedule is ruined? lol)
<Degi>
Kinda got mine fixed lately...
<Degi>
Yes it works
<Degi>
Buttons #4 and #5 have what looks like a paper rectangle with a gray triangle with an exclamation mark, are the icons broke?
<Degi>
Hmh the "WAV:DATA?" gets stuck at ReadRawData
<Degi>
And I can crash my PC by removing the +1 from m_transport->ReadRawData(header_blocksize + 1, temp_buf); lol
<monochroma>
segfault?
<Degi>
Idk maybe
<Degi>
Ok fixed that issue with a timeout
<Degi>
Somehow my function overloading doesnt work
<Degi>
Though its in the header and in the class...
<_whitenotifier-c>
[scopehal] x44203 forked the repository - https://git.io/JfaFA
<_whitenotifier-c>
[scopehal] x44203 opened pull request #122: Rigol - https://git.io/JfVHg
<Degi>
Anyways now you got configurable timebase which works surprisingly well for what it does
<Degi>
Hmm I wonder if I could access my scope from the WWW if I'd open a port in my router... Or if some hackerbot would destroy it
<monochroma>
never put equipment like that directly on the open internet
<Degi>
yes
<Degi>
Ui cool I can disable channels
<Degi>
Can I somehow increase the waveform update rate? Is the LAN interface the bottleneck?
<monochroma>
check bandwidth usage
<Degi>
I mean its 250 kilosamples, how would I check that? Is there an option in scopehal?
<Degi>
And somehow the FFT waterfall turns my sinewave into a checkerboard
<Degi>
Is there stuff like integrals etc and plotting a math function against a waveform or another math function?
<Degi>
Hm when I add a channel twice and remove it I get a segfault lol
<monochroma>
it's an OS function
<monochroma>
like bwm-ng or iftop etc
<Degi>
Yea I can try iftop later, just turned the scope off and wanted to do something else for a break, but I dont think that 250 kS saturates a gigabit or 100 M link? I'll see later
einthecorgi2 has quit [Read error: Connection reset by peer]