<mxshift>
Build ngscopeclient for the first time today on Fedora 39. Seems to work ok if I run it from the build directory. If I run `make install`, running `ngscopeclient` failed with `ngscopeclient: error while loading shared libraries: libscopeprotocols.so: cannot open shared object file: No such file or directory`
<d1b2>
<vipqualitypost> Darius: I have also been starting to work on a driver for older Teks although mine is later than your TDS (MDO4K). If you have a repo it could be fun to work together on it.
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<azonenberg>
mxshift: balrog is redoing a bunch of the build stuff, check with him to see if thats a known issue
<balrog>
mxshift: make install is not done, I'll test some though
<d1b2>
<darius0949> I haven't done any serious work on it, I was just basically smashing rocks together to try and get something going
<d1b2>
<david.rysk> @darius0949 @vipqualitypost check the programming manual first; MDO4K may use nearly the same protocol as the already-supported MSO5K/MSO6K
<d1b2>
<david.rysk> I took a quick look at MDO3K and it seems to support the same protocol
<d1b2>
<david.rysk> @darius0949 what TDS do you have?
<d1b2>
<david.rysk> TDS2000 series seems to use a similar protocol but with different / fewer commands
<d1b2>
<david.rysk> but similar enough that it could be in the same source file
<balrog>
mxshift: are you installing into /usr/local or elsewhere?
<d1b2>
<darius0949> yeah TDS2024
<d1b2>
<darius0949> I have the programmer manual, I used it to write some other code for logging PPS edges when checking Rubidium standards vs GPS 1PPS
<d1b2>
<david.rysk> yeah you probably just need to add another family in TektronixOscilloscope.cpp / .h
<d1b2>
<david.rysk> and then implement the changes (which are mainly that some of the commands used for the newer scopes are not supported)
<d1b2>
<azonenberg> @vipqualitypost also small world, a friend literally just bought a pair of 6627A's and wants to use them with scopehal
<mxshift>
balrog: yup
<d1b2>
<darius0949> yeah probably, the main things where trigger naming was different and the scope returned things like 'EDGE' rather that 'EDG'
<d1b2>
<darius0949> my diffs are at https://termbin.com/s5t2 (I did start making FAMILY_TDS but gave up so it is a mess)
<_whitenotifier-7>
[scopehal-docs] azonenberg b3f21ee - Clarifications to Coupler De-Embed filter
<mxshift>
yes, I'm not setting any flags other than what is in the install guide. By default, that installs to /usr/local
Kerr has joined #scopehal
Kerr has quit [Ping timeout: 255 seconds]
Kerr has joined #scopehal
Kerr has quit [Ping timeout: 255 seconds]
Kerr has joined #scopehal
<mxshift>
If I import this CSV, I get a waveform that looks reasonable and I can generate a histogram which also looks reasonable. If I change the Y units to UI (best approximation of what it actually is) before opening the histogram, the waveform still works but the histogram no longer renders. If I change the Y units after opening the histogram, I get a crash with a floating point exception
<mxshift>
guess I should file an issue
<azonenberg>
Interesting. yeah thats definitely a bug
<azonenberg>
So i think my working copy isnt quite exactly the same as yours since i'm actively doing dev, and i dont feel like reverting to whatever version you're testing with right now. But the SIGFPE and general part of the function you're looking at
<azonenberg>
is a pretty clear indication that data->m_timescale is somehow ending up as zero
<azonenberg>
i.e. the histogram is reporting it's zero x axis units per bin
<azonenberg>
then the renderer divides by zero trying to draw that
<azonenberg>
How that's happening is another question
<azonenberg>
(and why that has anything at all to do with the units selected)
<mxshift>
I've also discovered your max time range. I originally had my timestamp in clock ticks. CSV importer assumes that is in seconds. My first data point is at 17256 ticks. It never renders
<azonenberg>
we measure time in femtoseconds with 64-bit signed integers
<mxshift>
the X axis timeline wraps around to negative
<azonenberg>
ah ok yeah that does overflow
<azonenberg>
yeah
<azonenberg>
9223 seconds is the max offset from zero in a standard time domain waveform with fs as the base time unit
<azonenberg>
and yeah we will eventually add support for other units in the csv importer
<azonenberg>
but fundamentally our x axis measurements are all 64-bit signed integers
<azonenberg>
(we do have a few other scaled versions of base units for special purposes, its getting a little annoying and we're looking into ways to simplify that)
<d1b2>
<ledude0001> I want to create a PC based FPGA scope and use ngscopeclient, I plan to use UART. How do I know the API/data formats ?
<d1b2>
<ledude0001> I can't seem to find it in the documentation, any help greatly appreciated
<d1b2>
<azonenberg> First off, UARTs are sloow 🙂
<d1b2>
<azonenberg> almost anything else is likely a better choice
<d1b2>
<azonenberg> But generally speaking to make a custom instrument, you'd want to make a new driver class derived from SCPIOscilloscope and override all of the relevant functions to talk to your hardware via the transport (in this case a SCPIUARTTransport object)
<d1b2>
<azonenberg> The formatting of that data is completely up to your driver and firmware to agree upon
<d1b2>
<azonenberg> There's no single standard wire format because every commercial scope out there has its own protocol already
<d1b2>
<ledude0001> I am thankful for the fast reply! what Transport would you recommend? Ethernet? and is there a good standard protocol? I don't want to reinvent the wheel
<d1b2>
<azonenberg> I prefer Ethernet, specifically the "twin LAN" version which has two separate TCP sockets running in parallel
<d1b2>
<azonenberg> one of them is for control traffic and one for waveform data
<d1b2>
<azonenberg> (of course this means a TCP stack on your FPGA which isn't necessarily easy to do)
<d1b2>
<azonenberg> But in this model the control plane socket uses plain text commands generally using SCPI-style formatting, for things like starting/stopping acquisition
<d1b2>
<azonenberg> and the data plane socket is raw ADC samples with some minimal headers around them specifying number of samples per waveform, number of enabled channels, etc
<d1b2>
<azonenberg> Generally speaking though, our driver model is transport agnostic
<d1b2>
<azonenberg> the driver object is given a transport object and just calls methods on it to send data to/from the instrument
<d1b2>
<azonenberg> so you can write a driver once and then use the same protocol to talk to the scope over rs232 or usbtmc or ethernet or whatever
<d1b2>
<azonenberg> (as long as they use the same commands over the different interfaces)
<d1b2>
<ledude0001> thanks a lot
<d1b2>
<ledude0001> can you suggest one device driver that I can refrence 😅
<d1b2>
<azonenberg> The Agilent driver is probably one of the simpler ones in terms of implementing what you need to be functional and not a whole lot of extras
<d1b2>
<azonenberg> it does support logic analyzer channels which is something you can skip if your scope doesn't ahve that
<d1b2>
<azonenberg> actually, hmm looking closer it might not be the best example
<d1b2>
<azonenberg> since it's using the old non-queued command API
<d1b2>
<azonenberg> The Rigol driver is probably a better one to look at
<d1b2>
<azonenberg> you can see there's a bunch of conditionals in that one for different models of scope with slightly different command sets, if you're making a driver only for your custom hardware you won't need all that extra stuff
<d1b2>
<ledude0001> Do I recompile the entire program when writing drivers? or is it a different program
<d1b2>
<azonenberg> It's possible to write drivers as a plugin loaded separately, although we don't yet have stable APIs so any time you update libscopehal to a newer version you'd have to recompile the plugin
<d1b2>
<azonenberg> But if this is a device you plan to make a bunch of, upstreaming the driver in libscopehal is probably the simpler route
<d1b2>
<ledude0001> I am concerned because compiling ngscopeclient took 15 minutes 😲
<d1b2>
<azonenberg> Rebuilding after changing a driver should be fast
<d1b2>
<ledude0001> ok thanks a lot
<d1b2>
<ledude0001> very grateful for the help and the software 🤗
<d1b2>
<azonenberg> The architecture is very modular and we don't include every driver all over the place or anything
<d1b2>
<azonenberg> there's one function in scopehal.cpp that you have to add a line to in order to register your driver, other than that it's just recompiling your driver itself and re-linking