<Bird|otherbox>
working on the static analysis stuff right now, it looks like I have cmake -DANALYZE=true working for cppcheck so far
<Bird|otherbox>
integrating clang-analyzer is going to be a bigger challenge, the usual way it runs wraps the buildsystem
<Bird|otherbox>
also: fixed an annoying -pedantic warning that was coming out of the logging headers
<azonenberg>
what, the ... with no args?
<azonenberg>
i had wanted to look into how to fix that
<Bird|otherbox>
yeah!
<azonenberg>
what was the fix?
<Bird|otherbox>
the fix was taking the explicit "fmt" argument out of the macros
<azonenberg>
ah ok
<Bird|otherbox>
so that it's just picked up by the varargs pack instead
<azonenberg>
Makes sense
<azonenberg>
So that way there's always at least one arg
<azonenberg>
Great
<azonenberg>
Send a PR
<Bird|otherbox>
OK, I'll see if I can get that commit wrapped in a PR of its own once I commit that change
<azonenberg>
my ultimate goal is to have everything build without warnings with -Wall -Wextra -pedantic and whatever other warning flags i have, plus clean static analysis
<Bird|otherbox>
a very worthy goal indeed :)
<azonenberg>
we're not quite there yet but close
<Bird|otherbox>
yeah
<Bird|otherbox>
I get one or two other warnings in my build
<azonenberg>
Most are probably related to incomplete protocol decodes etc
<azonenberg>
the OFDM demodulator is broken and incomplete
<azonenberg>
i think there was a warning or two in that
<Bird|otherbox>
yeah
<azonenberg>
So dont waste time fixing that
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JU5nM
<_whitenotifier-f>
[scopehal] azonenberg 6fe6cf6 - SWDDecoder: turnaround bits after read are now configurable, default 4
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg pushed 5 commits to master [+2/-0/±8] https://git.io/JU5Kl
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #200: Automatically create new waveform group for spectrum channels on Tek 5/6 series - https://git.io/JU6At
<electronic_eel>
this is usb hs, on my 500 MHz 4 GSPS Rigol. white is the rigol passive probe (not the stock one that came with the scope, a 600 MHz one that costs about 400 EUR)
<electronic_eel>
pink is the kickstarter probe
<electronic_eel>
it is clear that the scope bw is the limit here, but the better probe also plays a good role here
<electronic_eel>
and the most important thing: when probing with the passive probe, I get less usb bandwidth
<electronic_eel>
so it seems there are some packets lost when using the conventional probe, while the kickstarter probe does not affect the bandwidth to not probing at all
<electronic_eel>
and I think I have to change to more flexible cabling. currently using LMR-194-UF. this is nice for stuff like small amplifiers, filters and stuff that are fixed on the bench
<electronic_eel>
but for a handheld probe it is too stiff, using something like a probe holder is completely impossible with this
<azonenberg>
Nice :)
<azonenberg>
The kickstarter probe is way behind where I think the AKL-PT1B (tentative designation for the improved design in the same form factor) will be. But it should easily beat any cheap passive probe
<azonenberg>
and even lower end transmission line probes like the pico ta061
<sorear>
curious whether the improved versions are going to be distributed in any fashion
<azonenberg>
sorear: Yes. To start, I will offer AKL-PT1B's as a "naked" upgrade package to current AKL-PT1 owners
<azonenberg>
i.e. no accessories included
<azonenberg>
the accessories are actually the most expensive part of the package so i can offer board+enclosure for probably $50 or less and break even
<azonenberg>
but i will also offer them with the accessory pack standalone, price TBD but probably similar to what i charged on kickstarter
<azonenberg>
also the AKL-PT1B is actually performing quite nicely even on oshpark PCB. While the production ones will have full testing and impedance control, it's looking like making one DIY will be very feasible
<azonenberg>
The AKL-PT2 is a solder in version that will use the same attenuator but is intended to be semi-permanently installed on a DUT (but can be removed if you're careful and reused)
<azonenberg>
commercial solder in probe tips are $1K or more, i'm targeting under $20 BOM so i can probably take a profit selling them for $30-40 if not less
<azonenberg>
there wont be any accessories or tip sockets
<azonenberg>
just three resistors (about $2 each), the SMA ($10), and the flex pcb itself. It will be a little more expensive if i want to figure out some kind of silicon sleeving around the probe body but still not unreasonable
<azonenberg>
silicone*
<azonenberg>
The AKL-PT2 will also have higher bandwidth, i think, because of the shorter tip stub
<sorear>
naive question, how much do you have to worry about oshpark making unannounced process changes that affect RF impedence
<azonenberg>
sorear: They document the stackup and materials, i'd expect some level of warning if they changed things
<azonenberg>
it's not explicitly *controlled impedance* in that they don't fine tune the etching based on TDR measurements etc
<azonenberg>
But it's not awful either
<azonenberg>
for anything i was going to sell i'd pay for impedance control for sure
<sorear>
presumably anything you sold would be tested by you in some form
<azonenberg>
Yeah. But also in higher volume oshpark is pricey
<azonenberg>
and you have to file off the mouse bites
<electronic_eel>
about the sleeve for the solder in probe: have you considered using common heatshrink tubing?
<azonenberg>
Yes. I don't think it would work well
<azonenberg>
it's stiffer than i'd like, and i also expect it would squish the flex pcb and stretch/bend it unpredictably
<azonenberg>
causing random impedance variations
<azonenberg>
I was thinking actually it would be better to have a non-shrunk tube of some sort that is just glued down at the ends or something
<azonenberg>
and just have the flex be sitting inside
<azonenberg>
But i havent had time to sit down and look at the options yet. The first prototype will be bare flex
<miek>
is the goal to insulate the bare transmission line? or more than that?
<azonenberg>
miek: also protection against physical damage and a nicer surface to tape down/put in alligator clips to hold the probe, etc
<azonenberg>
Another option i'm considering is to not have a long flex at all
<azonenberg>
Have the flex be a tiny little tip with the resistors, solder-in endpoint, and a u.fl
<azonenberg>
then supply a u.fl to sma pigtail with micro coax
<azonenberg>
but u.fl has very low mating cycle count
<azonenberg>
hand soldering micro coax to the pcb is possible but would be tricky to do repeatably
<azonenberg>
and you'd have strain relief concerns
<miek>
mm, yeah. i'd be more worried about the ufl durability than the flex
<azonenberg>
also i think micro coax is pretty lossy
<azonenberg>
not sure micro coax + u.fl is a good choice for going 6" or more with a 5+ GHz signal (I'm targeting 5 GHz bandwidth or better)
<azonenberg>
If it's more than 6 i'll spec it at 6 because i can't test past that
<electronic_eel>
there is this stuff called "glass silk" that was used in incadecent lamps to make sure the isolation of the wires doesn't melt due to temperature. maybe this is also offered in a bit thicker version than just for one wire as used in the lamps
<azonenberg>
Yes, i think i know what you're thinking of. That is an option but is perhaps a bit too smooth to secure well
<azonenberg>
basically a braided fiberglass?
<electronic_eel>
yes
<electronic_eel>
i think you could easily glue it down on the ends
<miek>
i like the flex option from the point-of-view of making it ultra cheap, might get down to a point where they're almost disposable & making it last a long time doesn't matter
<azonenberg>
Yeah. Again, several options
<azonenberg>
miek: It will definitely be flex. the only question is how we'd sleeve it
<azonenberg>
i want these to be durable enough i can individually VNA cal them
<azonenberg>
and have that make sense
<azonenberg>
but they are also intended to be semi-disposable for sure
<azonenberg>
I might offer sleeved and unsleeved versions
<miek>
i wonder whether coverlay is more repeatable/modelable than mask, so maybe it doesn't need to be bare?
<azonenberg>
The coverlay adhesive is the issue more so. I doubt that's well specced for Er
<azonenberg>
and it will be filling the CPWG gap
<miek>
mm yeah, good point
<electronic_eel>
yeah, that is also why just sticking kapton tape around it will affect performance
<azonenberg>
Exactly. Although a small amount for securing it should be a non-issue as the mismatch won't be that big or long
<azonenberg>
but i dont want it over the whole line length for sure
<azonenberg>
One option i might consider for a prototype, if it's not too expensive, is shapeways SLS TPU
<electronic_eel>
isn't that too stiff too?
<azonenberg>
I can 3d print a custom perforated jacket that's set up like a cable strain relief, disks with alternating horizontal and vertical connections
<sorear>
…what is a mouse bite
<azonenberg>
sorear: the little things holding oshpark pcbs together
<azonenberg>
tabs of fr4 with drills so they snap off
<miek>
the thing i like about the bare flex is it's really small, any sleeve is going to bulk it up a lot
<azonenberg>
miek: yes, hence the plan to offer both versions
<azonenberg>
and the very end would be unsleeved for easy squeezing into tight spots
<electronic_eel>
yes, you want to stack up a lot of these probes together in a tight space if you want to probe a bus or something
<azonenberg>
Yeah i want these usable for maxwell among other things
<azonenberg>
so fitting dozens of them on a board has to be viable
<azonenberg>
i also want to make a differential version for a future active diff probe
<electronic_eel>
is there some non-masked feature on the bottom of the tip part that could make a short?
<azonenberg>
So that's the fun bit
<azonenberg>
The old v0.1 version i made at pcbway, and the v0.2 i made at multech, both in 2017 (using a single resistor with no sim or optimization, and MMCX connectors) used castellations
<azonenberg>
they had poor yield due to requiring +/- 0.1mm edge registration tolerance or better for the 0.2mm drills
<azonenberg>
Also they were pretty fragile, and they had to be decently wide too so there was an impedance mismatch and they'd short if used on fine pitch pins
<azonenberg>
My new idea is to have 0.15mm wide bare traces for a mm or so at the tip
<azonenberg>
you'd tape the tip down then solder a bodgewire from there to the signal
<electronic_eel>
isn't a 0.15mm solder pad a bit too narrow? I'd probably use 0.3mm diameter wire or similar
<azonenberg>
i was thinking of using something like this
<electronic_eel>
hmm, does it need to be this small?
<azonenberg>
if you want to hit two 0.5mm pitch TQFP pins without shorting them, it helps
<azonenberg>
i might make the tip a bit wider but one of the things hurting signal integrity on the AKL-PT1 is that the impedance of the tip was too low
<azonenberg>
ideally you want the tip impedance matched to 500 ohms so your reflection is at the DUT and not the resistor
<azonenberg>
so for the most part thinner is better (and no ground plane under the tip either)
<electronic_eel>
ok
<azonenberg>
I might bump the width up to 0.2 or something. need to do a combo of sonnet sims and real world testing
<azonenberg>
this will be the first solder in probe i've made on oshpark since they didnt have flex when i started, and i'm testing on a scope with >10x the bandwidth of the last one
<electronic_eel>
yes, no kickstarter before you are satisfied with the design ;)
<azonenberg>
well i *was* satisfied with the AKL-PT1
<azonenberg>
then i realized how much further i could improve it lol
<azonenberg>
I was all set to ship 0.8 to my backers
<electronic_eel>
seems like there is no bare wire thinner than 32 awg (0.21mm dia) available at mouser and digikey
<azonenberg>
Yeah you have to go special to stuff like this
<electronic_eel>
grr, why do they have to make it so difficult?
<azonenberg>
That said, i think an 0.2mm tip is not unreasonable
<electronic_eel>
seems like there was some 38 awg on digikey before, but now discontinued
<miek>
cause it probably doesn't sell well?
<azonenberg>
I'll probably still use the smaller wire myself
<azonenberg>
I like the flat stuff rather than round for ultra fine work
<electronic_eel>
miek: yes, probably not many people are doing this kind of fine rework / prototyping anymore
<azonenberg>
And those that are, use stuff like the circuitmedic wire i linked
azonenberg_work has quit [Ping timeout: 246 seconds]
<_whitenotifier-f>
[starshipraider] azonenberg pushed 5 commits to master [+20/-18/±3] https://git.io/JUd2A
<azonenberg>
yeah but i have to finish my 10G rollout first
<azonenberg>
i need a 10G file server to even make good use of the 10/40G pipe to my desk
<azonenberg>
as well as at least 10G to the lab desktop
<azonenberg>
it's still on 10G and has no free pcie slots so i need a full cpu/mobo upgrade to put 10G on it
<azonenberg>
Will probably move this to the microscope bench and build a full new computer for the soldering bench
<electronic_eel>
using this adapter you could also use the hpe 10 gbe cards, they are like 10 bucks each on ebay. so also a lot cheaper than regular
<azonenberg>
honestly the cost of an intel 10g card isnt a big deal for me
<azonenberg>
its more just the hassle and cost of building a whole new computer to get the extra pcie lanes
<azonenberg>
or in the case of the file server a completely new multi-node storage cluster full of tens of TB of SSDs
<azonenberg>
it's not as simple as just sticking a nic in my existing box with two 7200rpm hdds :p
<electronic_eel>
yeah, getting the pcie lanes, in number and slot configuration, for nvme and the network cards is the biggest problem in my experience
<sorear>
one pcie lane, any version, will still get you more than 1G
<azonenberg>
sorear: so the lab PC has zero free pcie lanes of any kind
<azonenberg>
ok let me rephrase
<azonenberg>
the single x16 slot has a GPU in it
<azonenberg>
then i think it has a x1 or two, but i physically cannot fit an x4/x8 NIC in one
<azonenberg>
the file server has a couple of free lanes, but the hard drives can't keep up with more than about 1.3 Gbps of linear read/write data (tested via local benchmarks)
<azonenberg>
So i need a drive upgrade to make use of a 10G card
<azonenberg>
And at that point i might as well build the ceph cluster i've been planning
<electronic_eel>
if you wanted to upgrade the lab pc at least a bit, you could make this adapter, but just x1 and then use the hpe lom 10gbe card
<electronic_eel>
but I don't know if it is really worth the time
<azonenberg>
It's not. the thing is an i3 from like 2014 i built while still in college for a couple hundred bucks
<azonenberg>
or is it an i5? either way its old
<azonenberg>
i'd want to build a completely new box
<electronic_eel>
so also no bifurcation and so no way to steal some lanes off the gpu
<azonenberg>
Yeah
<azonenberg>
The GPU is a quadro k5200. was a nice card at one point
<electronic_eel>
ah, you can't do without a custom design ;)
<electronic_eel>
looks nice though
<azonenberg>
Well i was gonna RFQ this at shapeways just to see
<azonenberg>
but obviously a cots solution is best if one exists
<electronic_eel>
I'm just working on packaging ffts to prepare compiling glscopeclient. have you seen that it is basically unmaintained for several years now? website of the author down and so on
<azonenberg>
Hmm it's not letting me print in TPU, trying to figure out why. Says
<azonenberg>
and yeah. If you have suggestions on a better fft lib that's not GPL let me know
<azonenberg>
i've been eyeing a compute shader implementation that looks cool but havent had time to try it
<electronic_eel>
I haven't looked at fft libs before. the most common one, fftw, seems to be gpl though
<azonenberg>
Yes
<azonenberg>
That's why i'm not using it
<electronic_eel>
how deep is ffts integrated into your code? how much work would it be to change to another lib?
<azonenberg>
Not hard. i think i only call it in the de-embed and fft filters
<azonenberg>
it's a question of finding one that's fast and license compatible
<azonenberg>
$15 to print that in TPU after a few dfm tweaks
<azonenberg>
That's not actually too bad
<azonenberg>
I'm gonna get one made and see how i like the feel of it
<azonenberg>
i had to add a little "tail" to hit the 15mm minimum width but i can cut that off
<azonenberg>
or i could make a little molded shell that goes over the SMA etc. This is really just to see if SLS TPU is a good choice of material for this purpose, more so than to validate the exact geometry
<electronic_eel>
woo, got glscopeclient running. with the 10gbe session you posted here before, just to get a feeling for it
<electronic_eel>
azonenberg: cmake showed a warning about CMP0072 / OpenGL_GL_PREFERENCE
<electronic_eel>
is this a known issue? I couldn't find anything on github with a quick search
<electronic_eel>
in the end it compiled fine, but I guess this should be taken care of, otherwise it will choke on newer cmake versions in the future
<azonenberg>
Yes that is a known issue
<azonenberg>
I havent had time to look at the differences between glvnd and normal gl to see if i need to make any changes
<azonenberg>
Ignore it for now
<azonenberg>
electronic_eel: what physical scopes do you have that you might want to work with?
<electronic_eel>
I just have a Rigol MSO 4000
<electronic_eel>
I'm currently exploring the ui a bit from your session file, once I'm familiar how it should work I'll try connecting my scope
<azonenberg>
ok
<azonenberg>
so far we have known working support for mso5 and ds1000/1000z family
<azonenberg>
i dont think mso4 has ever been tested. it's likely similar to mso5 but you may have to patch the driver to detect it
<azonenberg>
and it may or may not be the same exact command set
<electronic_eel>
yeah, I figured as much
<electronic_eel>
how do you close a protocol analyzer window?
<azonenberg>
The same way you close any other window, with the X in the corner?
bvernoux has quit [Quit: Leaving]
<azonenberg>
electronic_eel: if there isn't a close button that's a problem, what OS etc?
<electronic_eel>
there is no x in the corner. strange.
<electronic_eel>
this is Fedora 32, window manager is kde kwin
<azonenberg>
File an issue against scopehal-apps with a screenshot and details on OS/window manger
<electronic_eel>
ok, will do
<azonenberg>
and what window manager theme/gtk theme you have selected by default
<electronic_eel>
the protocol decoders have a very "bare" heading with this oldish x symbol on the left
<azonenberg>
Hmm, interesting so they're not getting themed by the window manager right
<azonenberg>
not sure if that's a flag i set wrong or if that's something to do with the gtk theme i'm using but definitely an issue. File a bug including that screenshot
<electronic_eel>
I think I'll investigate a bit more, like trying different window manager settings, themes and similar
<sorear>
that's the x.org loo
<sorear>
*logo
<sorear>
possibly a default being added by xwayland since the app doesn't provide an icon
<electronic_eel>
unfortunately running glscopeclient in a vm is not possible due to the gl stuff, so I can't easily switch too much without risking to break my workstation
<azonenberg>
yeah thats my problem with reproducing issues too
<azonenberg>
unfortunately there isnt really way around the compute shader requirement
<sorear>
can't mesa run shaders on the cpu with that big llvm dependency?
<electronic_eel>
do you have experience with moving the whole gpu pcie device to a vm and using a different gpu for the workstation (or running headless)?
<azonenberg>
electronic_eel: I have used pcie passthrough with xen before
<azonenberg>
It's iffy on nvidia but works fine with most amd cards afaik
<electronic_eel>
for the gpu or other stuff?
<azonenberg>
For GPUs
<azonenberg>
i have a pair of radeon pro wx 4100's in my xen server
<electronic_eel>
I use it for network cards every day with kvm, but haven't tried it with gpus
<azonenberg>
one passed through to my general web browsing VM to accelerate youtube playback etc, and the other was on a CAD vm for a while but is currently idle
<azonenberg>
the fancy SRIOV-compatible gpus are $$$$ and most are full height so won't fit in a 2U
<azonenberg>
and i really dont want to burn 4U on a vm server at this point
<azonenberg>
i'll probably want to make it longer to cover more of the probe length, and have it also cover the SMA a bit
<azonenberg>
this is just a proof of concept at this point
<Degi>
Does it affect impedance?
<Bird|otherbox>
that's actually pretty cool
<azonenberg>
It shouldn't because it will be floating in the air over the top of it
<Bird|otherbox>
never seen elastomeric strain relief used with flex PCBs before
<Degi>
Would it be made in 3D printed rubber?
<azonenberg>
]it would be intentionally loose fitting so you get air dielectric
<azonenberg>
yes, SLS TPU
<azonenberg>
it's $15 at shapeways for that prototype
<Degi>
Hm yes, you could add a groove in the middle too to ensure that there is enough air... Looks fancy
<Degi>
And how reusable are the probes?
<azonenberg>
Depends on how careful you are to not rip the contacts off the tip
<azonenberg>
The intent is to use kapton tape to secure the end to the PCB, then either a positioner or tape to hold the SMA end to the bench probably to avoid putting stress on the solder joint
<azonenberg>
I still have to work out details of the mechanical form factor, this is a concept
<azonenberg>
i want to use flex but i like the idea of some protection, like how the lecroy active probes are
<azonenberg>
this will protect it from trivially shorting to stuff on the PCB although it's not fully insulating
<azonenberg>
and will also provide some protection against physical damage
<Degi>
Hmm, how good is flex PCB as a dielectric? Are there different grades too?
<azonenberg>
oshpark flex is using Panasonic Felios F775 as the substrate
<azonenberg>
Er 3.2, loss tangent 0.002
<Degi>
Well, at 1 MHz
<azonenberg>
by comparison FR408HR as used on the oshpark rigid probe is Er 3.68, Df 0.0092
<azonenberg>
Yes. It's not specified higher
<Degi>
FR408HR is specified at 1 GHz
<Degi>
Interesting, loss decreases at 10 vs 5 GHz
<azonenberg>
anyway i'm going to slap the prototype on the VNA and see how it looks
<Degi>
Sounds like a good idea ^^
<azonenberg>
I know some folks who have played with oshpark flex for low loss cavity filters etc
<azonenberg>
as a cheap low loss substrate
<electronic_eel>
wow, the scpi parser of my rigol is complete crap. you send one command it doesn't recognize and it crashes. no reconnect helps, you have to reboot to get it to answer again
<azonenberg>
lol
<azonenberg>
Now you know my pain writing drivers
<electronic_eel>
oh yea
<azonenberg>
Tek isn't THAT bad but it will hang for several seconds
<azonenberg>
lecroy has the best error handling i've seen yet
<sorear>
will need to see benchmarks of the unrecognized commands per second performance of the azonenberg scope boards
<electronic_eel>
maybe rigol improved that with newer scopes, I don't know. but this is really bad
<azonenberg>
lol
<azonenberg>
i crashed my ds1102d all the time back in the day
<electronic_eel>
you don't happen to have some ZENNECK ready to ship? maybe go looking in your time machine?
<Degi>
Rigol seems to be fine with unrecognized commands and just sends no response
<Degi>
Though when you query data too often it hangs up
<electronic_eel>
Degi: ok, so they must have fixed the unrecognized command stuff in the newer scopes
<electronic_eel>
mine doesn't answer any legal command whatsoever after an illegal command
<azonenberg>
lol
<miek>
whaat
<Degi>
What does illegal command mean here? Like just the command name being unrecognized or weird symbols?
<electronic_eel>
just send "GARBAGE?" and it is gone
<Degi>
Haha
<azonenberg>
electronic_eel: if i send anything invalid to the tek mso6 it will hang for quite a while and ignore all commands
<azonenberg>
if i *IDN? a bunch of times
<azonenberg>
after 30 sec or so i will get a single IDN reply back
<azonenberg>
then it will be back to normal
<azonenberg>
but it effectively kills the connection because reads start timing out and my software loses sync
<azonenberg>
then i have to manually ping the scope until it resets whatever is borked
<electronic_eel>
I tried it like 10 minutes after crashing, no response until reboot
<Bird|otherbox>
waitamoment -- when I try to commit my changes to log.h, it says something about HEAD being detached
<azonenberg>
Bird|otherbox: ah yes, thats a quirk of submodules
<azonenberg>
you need to "git checkout master" in the submodule directory
<azonenberg>
then it will let you commit
<azonenberg>
because the submodule points to a specific git hash
<azonenberg>
even if that's head it doesn't KNOW it's head
<Bird|otherbox>
rightyo
<Bird|otherbox>
urgh
<Bird|otherbox>
now I have a problem
<Bird|otherbox>
how do I propagate a git config from a repository to its submodules?
<azonenberg>
what do you mean?
<azonenberg>
move the remote to your fork rather than upstream?
<Bird|otherbox>
I have a local git config that sets things up correctly with that sort of thing, yeah
<Bird|otherbox>
and I want to get that config propagated to all the submodules from the top-level project
<azonenberg>
So, the submodules are set up with relative paths
<azonenberg>
so if you fork all of the submodules you can clone your local fork
<azonenberg>
then just periodically pull from upstream to stay in sync
<azonenberg>
and pushes will automatically go to your fork
<azonenberg>
Git in general is not great at handling external dependencies. I wish there was a better way
<electronic_eel>
woo, got my first waveform from the rigol. did some dirty patch to adapt the idn. unfortunately the horizontal and vertical scaling is all wrong.
<Degi>
Hm, trying to parse it as a 5000?
<electronic_eel>
yes
<Degi>
Between 5000 and 1000 there seems to be the difference that one is in volts FSR and one in volts per div
<electronic_eel>
ah, so you suggest to not use the 5000 mode?
<Degi>
Which scope do you have?
<electronic_eel>
mso4000
<electronic_eel>
it is an older model
<Degi>
Ah idk, maybe check in the manual
<Degi>
If the voltage is off by factor 8, then try the other mode
<Degi>
Or you might need a MSO4000 mode
<electronic_eel>
yes, I think I do. I just tried hardcoding the "DS" protocol and that didn't work.
<Degi>
With some luck you only need to remove the * 8
<azonenberg>
electronic_eel: yeah you probably need to make a new family ID for it
<Degi>
(if it detects a MSO4000, the 5000 needs that)
<azonenberg>
and then special case some stuff
<electronic_eel>
bah, clean coding required, new family and stuff. I hoped I could get by with dirty hacks ;)
<Degi>
Hmm, hope that the MSO / DS hack is not too dirty...
<azonenberg>
the tek driver has family specific stuff too
<azonenberg>
lecroy is the only one without family specific quirks afaik, MAUI is *very* good at compatibility from really old to really new deviecs
<azonenberg>
the protocol is exactly the same
<azonenberg>
the only thing i have checks for are stuff like "what sample rates are available"
<azonenberg>
or "which channels can be interleaved"
<electronic_eel>
I removed the * / 8 stuff and it became a bit better, but was still not working correctly. so I have to go through all the commands and check what is going on. also I have to reboot the scope ever so often...
<electronic_eel>
so I think I have to create a new family id and work my way through the commands
<electronic_eel>
luckily the heavy lifting of displaying the waveforms, a whole ui and so on is already there
<azonenberg>
Yeah making a new driver is comparatively easy
<azonenberg>
especially if the commands are similar enough you can mostly cut and paste from another family
<azonenberg>
Could be signed vs unsigned adc samples?
<electronic_eel>
I think the samples themselves are ok, it is just the scope that is set up scaled wrong
<azonenberg>
ah ok
<electronic_eel>
the samples look like what is on the screen of the scope
<azonenberg>
yeah you might be able to keep the mso5 acquisition code then
<azonenberg>
i normally have family checks as big switch statements so i can just fall through when two families have the same command for something
<electronic_eel>
I also saw a lot of tables of legal sample rates, channel attenuations and so on. It looks like they don't match my scope, so it switched into some software scaling mode
<electronic_eel>
I guess it will also help a lot if I put the correct data for my scope in these tables
<azonenberg>
Yeah. unfortunately most scopes have no means to query that
<electronic_eel>
mine even doesn't have a command to check which options you got, so you don't know which bw or triggers are available
<azonenberg>
lolwut?
<azonenberg>
*OPT? doesnt work?
<azonenberg>
you should be able to extrapolate BW from the IDN info with model name
<electronic_eel>
*OPT? hangs the scope, as usual...
<azonenberg>
lol
<azonenberg>
Of course
<azonenberg>
i guess the safest option would be to assume all options are available and just hope the user doesnt select an unsupported trigger and hang the scope? :p
<electronic_eel>
no, can't extrapolate the bw from the model name. the model name stays as original, the bw changes with installed options
<azonenberg>
That is bad even by rigol standards
<electronic_eel>
yeah, I guess we have to assume a fully optioned up scope
<electronic_eel>
and for everyone complaining, I send them a link to the option keygen...
<azonenberg>
lol
<azonenberg>
well i guess the question is, if you try to configure a scope missing options
<azonenberg>
does it hang or gracefully fail?
<azonenberg>
say enabling an i2c trigger on a scope with no i2c
<electronic_eel>
yeah, I already thought about that. but unfortunately can't test it
<azonenberg>
i guess we'll just have to put a caution to that effect in the manual lol
<azonenberg>
only so much we can do
<electronic_eel>
yes, now I have to get it to work somewhat reliably first
<electronic_eel>
but not tonight, have to get up early tomorrow, so I'm going to bed now
<azonenberg>
(that's a draft, there's no official manual release yet as lots of sections are missing or blank)
<Kenley>
For folks here, I'm a recent owner of a Rigol MSO5074 and learning how to set it up with glscopeclient.
<azonenberg>
Kenley: degi, i believe, has a MSO5000 and is probably going to be your best resource as far as the rigol driver specifically. Although she's in... Germany? and probably not awake yet :p
<azonenberg>
She wrote a good chunk of the modern rigol driver although i wrote the original code for a DS1000D back years ago
<azonenberg>
electronic_eel has a MSO4000 and they're trying to get it running, that model is not yet supported though. apparently the command set isn't quite the same as the MSO5000
<Degi>
More like still awake lol
<Degi>
The problem is that (at least my) MSO5000 hangs up after a while. glscopeclient is kinda usable before that (approximately 100 waveforms, I think it was at 4 channels and 10 k sample depth), it gets approximately 0.9 waveforms per second.
<Degi>
Hangs up = it freezes and you need to restart it with the power button
<azonenberg>
Degi: so still some debugging needed then
<Degi>
I think it should be pretty usable when we get single trigger mode
<azonenberg>
We have single trigger mode, is it not implemented in the driver?
<Degi>
Oh, we do?
<Degi>
Hm, I should take a look at that sometime soonish