<azonenberg>
I've had issues in the past w/ buggy drivers/filters emitting NaNs or FLT_MAX or equally absurd values
<azonenberg>
and the shader doing Bad Things(tm) as a result
<azonenberg>
Memory writes are bounds checked but it might result in huge loop iterations or something like that?
<d1b2>
<fsedano> I have the feeling something is wrong on how we’re capturing data in rs driver. Looking at wire shark now
<azonenberg>
Very possible. I wrote that driver years ago over VPN to an RTM3000 and never finished it
<azonenberg>
the guy i was remotely borrowing the scope from needed it back
<azonenberg>
Try logging the data to CSV or something and flushing the file before returning from AcquireData()
<azonenberg>
That way if you do crash the display you know exactly what garbage you fed the shader
<azonenberg>
I bet you'll find some uninitialized memory, NaNs, huge values, or something
Degi_ has joined #scopehal
<d1b2>
<fsedano> What I noticed is we get no response to the HEAD? command sometimes. But if I skip actually asking for the data (i.e. I only send HEAD commands) all is good. I think we're going out-of-sync while reading the data and then everyghing goes south.
<d1b2>
<fsedano> I have a PCAP showing this, looking at it now
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<azonenberg>
Very possible
<azonenberg>
If you're allocating waveform buffer memory then not reading anything into it, and returning it as if everything is good
<azonenberg>
i'm sure the shader will *love* trying to render uninitialized memory :p
<xzcvczx>
rendering unitialized memory will show you the meaning of life
<GenTooMan>
in initialized glory or gory.
<GenTooMan>
well uninitialized perhaps :D
<azonenberg>
xzcvczx: lol
<azonenberg>
Fond memories of the early CUDA days when one bad pointer would happily scribble all over your framebuffer and more
<azonenberg>
Sometimes the screen would fill with colored snow then the system would lock up
<azonenberg>
Other times you'd get just a few corrupted pixels
<azonenberg>
everything would look fine for a while but the system would just not quite act right and get less stable
<azonenberg>
then either randomly hang at some point in the future or gradually corrupt more pixels as it read from corrupted pointers in the driver, etc
<xzcvczx>
at least it didn't pollute storage cache
<d1b2>
<fsedano> but we're not reading it, so it's taken as the reply for STAT?
<azonenberg>
That would do it
<d1b2>
<fsedano> YES! it works great now
<azonenberg>
:D
<azonenberg>
Send a new PR and mark it as fixing that bug then
<azonenberg>
fsedano: so what features are missing in the current RTM3000 driver?
<_whitenotifier-3>
[scopehal] fsedano opened pull request #450: Read extra LF after DATA - https://git.io/J3RW7
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/J3RWp
<_whitenotifier-3>
[scopehal] fsedano 3dfd272 - Read extra LF after DATA
<_whitenotifier-3>
[scopehal] azonenberg b2efa36 - Merge pull request #450 from fsedano/fix_trailing Read extra LF after DATA
<_whitenotifier-3>
[scopehal] azonenberg closed pull request #450: Read extra LF after DATA - https://git.io/J3RW7
<azonenberg>
So no more GPU hangs now?
<d1b2>
<fsedano> So far so good
<d1b2>
<fsedano> Triggers seems to be missing, even the basic stuff
<d1b2>
<fsedano> I can work on that next, before digital chans
<azonenberg>
Great
<azonenberg>
I'll close the gpu hang ticket then
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #325: GPU hang on iris Plus driver - https://git.io/J3R4U
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #325: GPU hang on iris Plus driver - https://git.io/J3k5U
<azonenberg>
And yeah the R&S driver predates the current trigger object model
<azonenberg>
you said you had an agilent too right? that's far more complete
<azonenberg>
so you can use it as a reference
<azonenberg>
although i dont think miek got digital channels done yet either
<d1b2>
<fsedano> yes I can use that one as reference
<d1b2>
<fsedano> I'll start with trigger then
<azonenberg>
Great. I've got a bunch of work to do on the pico driver still so i should focus on that...
<d1b2>
<fsedano> q on filters - How can I use a threshold filter to digitize my analog channel, so I can apply digital decoders? I'd need to use two thresholds, for positive and negative side
<azonenberg>
The current threshold filter has no concept of X
<azonenberg>
all output values are either logic 0 or 1
<azonenberg>
So typically you'd specify vcc/2
<azonenberg>
anything above is a 1, anything below is a 0
<azonenberg>
it also supports hysteresis although there is a performance penalty for that, since it introduces serialization you can no longer use vector instructions to process samples in parallel
<azonenberg>
So normally that only gets used for really noisy inputs
<d1b2>
<fsedano> so how to digitize RTZ signals? Like ARINC
<azonenberg>
As of now we don't have a filter that handles stuff like that and produces a digital output. Filters that handle such stuff normally work directly on the analog signal and do their own thresholding internally according to the rules of that protocol
<azonenberg>
for the more common case of NRZ CMOS/TTL signals we use the threshold filter to produce a boolean output
<azonenberg>
You can look at the MIL-STD-1553 decode as an example of that too
<azonenberg>
incidentally there are now two different implementations of differential manchester in scopehal (1553 and 10baseT), each slightly different because of the different sync rules etc
<azonenberg>
Longer term i'd like to unify that
<azonenberg>
and write a more generic manchester decode filter
<azonenberg>
But it's not trivial
<_whitenotifier-3>
[scopehal] fsedano opened pull request #451: Implement SetChannelVoltageRange for RS3000 - https://git.io/J3RzE
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/J3RzD
<_whitenotifier-3>
[scopehal] Francisco Sedano e8c1d97 - Add proper parameter format specifier for size_t
<_whitenotifier-3>
[scopehal] azonenberg 0fcf6d8 - Merge pull request #449 from fsedano/fix_format_size_t Add proper parameter format specifier for size_t
<_whitenotifier-3>
[scopehal] azonenberg closed pull request #449: Add proper parameter format specifier for size_t - https://git.io/J3RfC
<azonenberg>
you still have i and range commented out
<azonenberg>
sooo not sure how that's supposed to compile :)
<d1b2>
<bob_twinkles> re the new renderer, I have some ideas but haven't had the mental energy to put the performance monitoring tools together just yet
<d1b2>
<bob_twinkles> (i run nixos so this is more effort than it should be, I really need to switch back to a less aggressive distro...)
<d1b2>
<fsedano> Argh I fixed in a repo but commited from a different one
<d1b2>
<fsedano> It would be good to enable automatic build for PRs
<azonenberg>
fsedano: we have CI builds on scopehal-apps
<azonenberg>
just not for scopehal right now
<azonenberg>
setting that up is on the todo list, but i'd have to do a bit of glue to integrate them properly
<azonenberg>
tl;dr right now scopehal's cmakelists is pulled in under scopehal-apps
<azonenberg>
so it's missing a little bit of the infrastructure it needs to be buildable on its own as a top level entity
<azonenberg>
The history of the separate repos and complex build system is, as is usually the answer, legacy
<azonenberg>
this setup is descended from a google-style subversion monorepo i had for my thesis almost a decade ago including a whole bunch of different sub-projects
<azonenberg>
using a custom in house distributed build system
<azonenberg>
over time various things forked off into their own public repos, at times some stuff was dual tracked with a cmake build chain as well as our in house tool
<azonenberg>
we at one point had a repo scopehal-cmake that was just a cmakelists including scopehal and scopehal-apps as submodules
<azonenberg>
that has since been squashed into -apps but the library remains separate for now because it'd be a lot more work to merge
<_whitenotifier-3>
[scopehal] azonenberg 84da3c6 - Merge pull request #451 from fsedano/add_channel_range Implement SetChannelVoltageRange for RS3000
Tost has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<azonenberg>
So i'm starting to find some interesting limitations on the picoscope
<azonenberg>
in particular, it has fairly limited offset at low V/div ranges
<azonenberg>
So while it has a 5V range in 50 ohm mode, you cannot look at a 200 mV window from 4.8 - 5V
<azonenberg>
as you zoom in a bit the offset range drops, so for example if you're in 500 mV full-scale range your max offset is only +/- 500 mV
<_whitenotifier-3>
[scopehal] azonenberg opened issue #453: Pico bridge crashes when selecting an inactive channel as the trigger source - https://git.io/J30jp
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #453: Pico bridge crashes when selecting an inactive channel as the trigger source - https://git.io/J30jp
<_whitenotifier-3>
[scopehal] azonenberg edited issue #453: Pico bridge crashes with error 0x181 when selecting an inactive channel as the trigger source - https://git.io/J30jp
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #453: Pico bridge crashes with error 0x181 when selecting an inactive channel as the trigger source - https://git.io/J30jp
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/J3EUV
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg 9bad9a3 - Offsets are now clamped to reported range and repoted back to client. All channels disabled when a client disconnects.
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3EUy
<_whitenotifier-3>
[scopehal] azonenberg 9769f0e - Offsets now come from bridge as the reported offset can vary from what we requested
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3EIi
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg a441117 - Update trigger configuration any time we reconfigure the frontend of the trigger channel to keep voltage constant