<GenTooMan>
azonenberg, I take it if you get zero length data you will see no trace on the graph?
<azonenberg>
Yes
<azonenberg>
it might not even draw axes. i forget exactly how early the early-out is
<GenTooMan>
hmm I suppose I need to be sure something was captured before data request or figure out why I am getting zero length results.
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
<_whitenotifier-a>
[scopehal] azonenberg commented on issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/Jn4Xg
<_whitenotifier-a>
[scopehal] azonenberg edited a comment on issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/Jn4Xg
<_whitenotifier-a>
[scopehal] thirtythreeforty commented on issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/Jn4Sm
<_whitenotifier-a>
[scopehal] azonenberg commented on issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/Jn4Qv
azonenberg has quit [Ping timeout: 252 seconds]
<GenTooMan>
well thanks that can explain why I nary seen a nice trace on the screen. :D
azonenberg has joined #scopehal
<_whitenotifier-a>
[scopehal] MegabytePhreak forked the repository - https://git.io/JnBUT
<_whitenotifier-a>
[scopehal-apps] MegabytePhreak forked the repository - https://git.io/JnBUT
<_whitenotifier-a>
[scopehal] MegabytePhreak opened pull request #503: Windows fixes - https://git.io/JnBIK
<_whitenotifier-a>
[scopehal-apps] MegabytePhreak opened pull request #380: Windows fixes - https://git.io/JnBI5
<_whitenotifier-a>
[scopehal] azonenberg commented on pull request #503: Windows fixes - https://git.io/JnB3x
<_whitenotifier-a>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JnBgy
<_whitenotifier-a>
[scopehal] azonenberg pushed 4 commits to master [+0/-0/±6] https://git.io/Jn0oV
<_whitenotifier-a>
[scopehal] MegabytePhreak 1494a73 - CMakeLists: Find shared yaml-cpp on mingw This was updated for MacOS a while ago but that broke mingw/windows
<_whitenotifier-a>
[scopehal] MegabytePhreak e0964ff - Unit: Fix windows compile
<_whitenotifier-a>
[scopehal] MegabytePhreak 6287a26 - scopehal: Improve resource search on windows Improve windows (mingw64) builds to look for resources such as shaders, icons, etc. in the share directory adjacent to the bin directory where execuatable lives. This matches the pattern for a mingw64 package install, and is the same as on Linux. Without this, a freshly installed mingw package will fail to start the
<_whitenotifier-a>
glscopeclient GUI due to inability to find resources.
<_whitenotifier-a>
[scopehal] azonenberg 545e2f9 - Merge pull request #503 from MegabytePhreak/windows-fixes Windows fixes
<_whitenotifier-a>
[scopehal] MegabytePhreak commented on pull request #503: Windows fixes - https://git.io/Jn0oy
<_whitenotifier-a>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/Jn0KI
<xzcvczx>
azonenberg: more productive since i said f*** it and just installed debian on one of my machines though
<xzcvczx>
using the bullseye rc as i was too impatient to wait til the end of july for it
<azonenberg>
lol
<azonenberg>
nothing worth sharing yet though?
<xzcvczx>
azonenberg: will be by the end of tomorrow
<xzcvczx>
currently i have added enumeration so it will yell at you if more than one scope is detected and make you specify which one you want
<azonenberg>
Great. I dont have >1 picoscope so i didnt bother
<azonenberg>
but long term that is definitely going to be needed
<xzcvczx>
azonenberg: i just use the enumerate function on each of the picoscope apis that are currently supported
<xzcvczx>
so 3/5/6
<xzcvczx>
then it will ignore any that are already "in-use"
<azonenberg>
excellent
<xzcvczx>
ok i just saw you as mr burns right there :)
<azonenberg>
lol
<electronic_eel>
so pico has really different apis for each of the series or is it more like one api for the 6000 series and similar apis for 3/4/5 ?
<electronic_eel>
i have a pico 4262 left over from a previous side job. it is really slow, but 16 bit and continous. so it is more like a data acquisition device like than a scope
<electronic_eel>
would be nice to have that in scopehal too
bvernoux has quit [Quit: Leaving]
<azonenberg>
electronic_eel: They're reasonably similar across the line, i think there is a split between the base and the -A series
<azonenberg>
api wise
<azonenberg>
i dont know which models are supported by which API
<azonenberg>
4000 series support is a wishlist item, once xzcvczx finishes his refactoring it should be easier to add new models
<azonenberg>
in fact, 4000 and 2000 series are the only series that we do not currently have anyone working on
<azonenberg>
2000 is the super cheap i think fx2 based ones
<electronic_eel>
how well would glscopeclient work for continous sampling over a longer time, something like 10 minutes or so?
<azonenberg>
with how many points acquired in that time?
<electronic_eel>
can you see the results while it is still sampling or must the sampling be completed before you can begin to analyze?
<azonenberg>
As of now, it's generally assumed a waveform is immutable once created
<electronic_eel>
the 4262 is 10 MS/s 16 bit
<azonenberg>
this isnt strictly true as filters sometimes reuse the same waveform object when the filter graph reruns to save memory allocation
<azonenberg>
But semantically it's a new waveform each time, just at the same address
<azonenberg>
The way i'd implement something like that would be to acquire waveforms in blocks say a second long (10M points) with no gaps
<azonenberg>
Longer term i plan on adding support for pulling waveforms out of history and working across history in filter pipelines
<azonenberg>
for example, i want to be able to average waveforms taken on the same trigger
<azonenberg>
i.e. take ten historical waveforms and compute the average of them
<azonenberg>
or subtracting a waveform from a previous one
<azonenberg>
there's a bunch of infrastructure work that will be needed before we can do that
<electronic_eel>
is there some limitations of what math etc. can be done across the border between two gapless waveforms?
<azonenberg>
Right now, the filter graph only has access to the "current" waveform. Which is normally the most recently acquired one but if you pause and go back in history can be an older one
<azonenberg>
as far as working across the border, the challenge is that right now the data model would see each one as a totally separate signal
<azonenberg>
it doesnt understand that they're consecutive
<electronic_eel>
so an averaging filter wouldn't continue over the gap to the next waveform?
<azonenberg>
Correct. Because in the common case of normal scope captures, you have unknown, long gaps between triggers
<azonenberg>
so all filters start clean-slate
<electronic_eel>
ok, understood
<azonenberg>
and if you preserve state naively, then navigate through history
<azonenberg>
you risk averaging violating causality
<azonenberg>
e.g. if you look at the current waveform then one from 30 seconds ago
<azonenberg>
you might average the new waveform into the start of the old
<azonenberg>
This is the kind of stuff that will have to be worked on to get better streaming support. it's not going to be trivial
<electronic_eel>
yeah, the filter model must be aware of the gaps to make it work right
<azonenberg>
well the metadata is kinda there
<azonenberg>
every waveform has a start time with, in theory, femtosecond resolution
<azonenberg>
and you know how long it is
<azonenberg>
so you can determine if they're gapless within some epsilon
<azonenberg>
But none of the filters actually *do* this
<azonenberg>
Supporting streaming as a bunch of waveforms that happen to have no gaps between them will be fairly easy
<azonenberg>
but actually taking advantage of the gaplessness will be a lot more work
<electronic_eel>
but you wouldn't want each filter to check all this metatdata each time, you probably want some abstraction layer to do it automatically for most filters
<azonenberg>
oh and the other thing is
<azonenberg>
right now most filters maintain state in local variables in the Refresh() method
<azonenberg>
if you wanted to maintain state across waveforms you'd have to move them to member variables
<azonenberg>
then determine whether to clear them or not
<azonenberg>
It would be a major refactoring
<azonenberg>
I think it probably should happen, long term
<azonenberg>
but it's not gonna be before v0.1
<azonenberg>
probably not 0.2 either
<electronic_eel>
when you get around building a scope with 100gbit ethernet, you'll want live streaming and analyzing until your disk is full ;)
<azonenberg>
lol
<azonenberg>
i'm expecting that adc bandwidth will always exceed lan bandwidth for anything higher end
<azonenberg>
so triggering and buffering will be a must
<electronic_eel>
live streaming and writing to disk makes precise triggering unnecessary. so you don't have to know in advance what you are looking for, but can carefully analyze after the fact
<electronic_eel>
that is very helpful for problems that are seldom and hard to trigger
<electronic_eel>
so when you don't need the full highend bw and have such a problem, you could switch to continous sampling
<electronic_eel>
i have sometimes used this with slow i2c and uart stuff on an fx2 based logic analyzer. for some problems that was really helpful
<someone--else>
I wonder if replacing scope sample DRAM with a NVMe 4.0 device(s) makes sense yet or not..
<electronic_eel>
you might need a bunch of nvmes in parallel to get the bw necessary. also a problem could be that you don't get a continous bw out of nvme ssds. once their fast cached sections are full or the controller gets too hot, you can get a massive drop in throughput
<electronic_eel>
i saw that when i replaced a nvme disk that was part of a md raid 1 cluster and initialized the new one
<electronic_eel>
the first few minutes i got stellar throughput and then it dropped considerably
<someone--else>
electronic_eel: I think some latest NVMe 4.0 drives have 3-4GBps sustained write speeds, which translates to 8-bit GSPS 1:1
<someone--else>
yep, many drives drop write speed significantly after exhausting SLC cache, but some higher-end consumer ones don't much
<someone--else>
Samsung Pro series etc.
<electronic_eel>
i saw them getting really hot (>85°C on the internal temp sensor) and then dropping speed. so i think it is also thermal limiting.
<someone--else>
but that is easy to solve with some heatsinks and fans
<electronic_eel>
this was in a server with a full set of high speed fans and a server room with proper aircon
<electronic_eel>
also i did some test with adding some additional heatsinks. that helped, but not too much
<azonenberg>
electronic_eel: so what i wanted to do was add realtime filtering
<azonenberg>
being able to stream tons of waveforms and run the filter graph on them
<azonenberg>
then discard anything not matching some criteria
<someone--else>
electronic_eel: dunno, maybe it would be the time to bring out the fluorinert then..
<electronic_eel>
someone--else: there goes the idea of a 1u 19" rack scope if you need a full cryo unit next to it...
<electronic_eel>
azonenberg: the realtime filtering helps if you know what you are looking for in advance, but it is too complex to calc on the trigger fpga in the scope
noopwafe1 is now known as noopwafel
<electronic_eel>
but there are cases where you need a day or two until the error event occurs, you really don't want to miss your trigger then
<azonenberg>
yeah makes sense
<electronic_eel>
and sometimes you don't really know what you are looking for beforehand. the root cause could have been 5 minutes before the fault happens
<azonenberg>
The NSA debug philosophy
<electronic_eel>
yeah, slurp in all data you can get and analyze later
<electronic_eel>
this is not best way to deal with all issues of course, but a very valuable tool to have at your disposal for some cases
<azonenberg>
Yeah
<azonenberg>
One limitation in that regard is that right now glscopeclient requires all history to be kept in RAM
<azonenberg>
long term i plan to support paging stuff out to disk
<azonenberg>
Which is going to be a must if you are going to be collecting hundred of GB of waveforms
<electronic_eel>
yeah
<azonenberg>
At work i've hit tens of GB datasets on a pretty routine basis
<electronic_eel>
tens of gb isn't an issue with a proper workstation, but once it goes into tb region you get a problem
<azonenberg>
yeah i have 192GB on my workstation
<azonenberg>
so it's fit fine
<azonenberg>
but if i wanted to get more than that...
<electronic_eel>
you can get commodity servers that allow up to 2 tb i think, but once you want to go above that there are no easy solutions
<electronic_eel>
but even the 2 tb aren't cheap
<azonenberg>
yeah my workstation can fit up to i think 1.5 TB in the mobo
<electronic_eel>
maybe ddr 5 will bump it up a bit, but not by an order of magnitude. so a paging solution should be the way to go for true continuous sampling
<GyrosGeier>
the TalosII can fit 2 TB
<GyrosGeier>
and it has a gzip coprocessor, so you could compress the history
<azonenberg>
Yeah we definitely need paging, even for smaller datasets on workstations that are less beefy than mine
<xzcvczx>
electronic_eel: when i am done with the refactor i can probably add the 4k stuff and then just put it in a branch for you to test if you want
<electronic_eel>
xzcvczx: cool, thank you for the offer
<electronic_eel>
i just used it on windows before, because they only have a gui there. so i need to see how their linux api thing works
<azonenberg>
the SDK is available for linux and windows
<electronic_eel>
but it is probably a good excuse for me to add rpm packages for pico bridge too
<electronic_eel>
yeah, i know that the api is available for linux. just need to see how to properly package it and make it usable without violating copyrights and stuff
<azonenberg>
on debian at least, they have debs of the sdk already
<xzcvczx>
only (open)suse and debian
<xzcvczx>
not sure how well the (open)suse rpms can be used with fedora/redhat/one that starts with c
<electronic_eel>
they= pico themselves, not debian, correct?
<electronic_eel>
thanks. i'll have to take a look at what their packages contain, where they put their stuff and so on
<xzcvczx>
on debian they seem to use /opt/picoscope
<xzcvczx>
well using the deb, i assume its the same using the rpm
<xzcvczx>
currently the pico-bridge requires all the (currently supported) family apis to build
<xzcvczx>
s/apis/sdks/
<electronic_eel>
sometimes i've encountered problems because of different linking options, like pie. that was something i had to change for scopehal to work
<xzcvczx>
azonenberg: look at you on front page of hackernews :)
<xzcvczx>
oh lol, you already seen it, nvm
<xzcvczx>
electronic_eel: what did you install it from?
<electronic_eel>
as i wrote, i could extend that packaging to the pico bridge
<xzcvczx>
btw azonenberg i am starting to wonder at the practicality of having scopehal-pico-bridge rather than just a scopehal-scoped or similar that does picobridge for all scopes?
<electronic_eel>
xzcvczx: for all scopes? but many scopes do not need picobridging since they can be contacted directly
<electronic_eel>
and don't need to be accessed through a pc-side api
<xzcvczx>
well for all scopes that use a native api i meant
<xzcvczx>
s/native/pc/
<azonenberg>
I think we can refactor some of the scpi code out to a separate library or something
<azonenberg>
but i want to keep the bridges separate
<xzcvczx>
ah ok
<azonenberg>
so for example you don't need to install digilent's sdk to use a picoscope
<azonenberg>
as we add more hardware the build dependencies would get totally out of hand otherwise
<azonenberg>
this is also why i didnt include them in libscopehal natively
<azonenberg>
well one of several reasons
<electronic_eel>
also could be a license problem to link in two different vendor apis at the same time
<azonenberg>
Potentially yes
<azonenberg>
It's much cleaner to have them all socket connected
<xzcvczx>
fiar neough
<xzcvczx>
fair enough*
<xzcvczx>
azonenberg: re testing the multiple scopes attached logic what i will probably do is just emulate a couple of scopes and make sure it works
<azonenberg>
Dont worry too much about multi scope stuff yet
<azonenberg>
if you mean multiple simultaneous scopes in glscopeclient? or do you mean in the bridge
<xzcvczx>
in hte bridge
<azonenberg>
ah ok yeah thats fine
<xzcvczx>
as in just when you start picobridge
<xzcvczx>
if it detects more than one it will just tell you to specify which one
<azonenberg>
multiple simultaneous scopes in one session is still a fairly new and not fully debugged capability
<azonenberg>
it needs more dev and more documentation and lots of polish
<azonenberg>
cant be used at all except from the command line, etc