azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://freenode.irclog.whitequark.org/scopehal
<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> got it
<d1b2> <fsedano> DATA ends with a \a
<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> fsedano: https://github.com/azonenberg/scopehal/pull/451/files doesnt look right
<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
<_whitenotifier-3> [scopehal] fsedano synchronize pull request #451: Implement SetChannelVoltageRange for RS3000 - https://git.io/J3RzE
<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 opened issue #452: DreamSourceLab DScope driver - https://git.io/J3RNW
<_whitenotifier-3> [scopehal] azonenberg labeled issue #452: DreamSourceLab DScope driver - https://git.io/J3RNW
<_whitenotifier-3> [scopehal] azonenberg closed pull request #451: Implement SetChannelVoltageRange for RS3000 - https://git.io/J3RzE
<_whitenotifier-3> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/J3RAO
<_whitenotifier-3> [scopehal] fsedano 09e5eaa - Implement SetChannelVoltageRange for RS3000
<_whitenotifier-3> [scopehal] fsedano a9b7c6b - Fix typos
<_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
<d1b2> <mubes> Spacewire is available from here. It does appear you have to create an account to download a copy; https://ecss.nl/standard/ecss-e-st-50-12c-rev-1-spacewire-links-nodes-routers-and-networks-15-may-2019/
juli9610 has joined #scopehal
Tost has quit [Ping timeout: 240 seconds]
<azonenberg> mubes: post that in a comment on the ticket
Degi has quit [*.net *.split]
JSharp has quit [*.net *.split]
JSharp has joined #scopehal
Degi has joined #scopehal
Tost has joined #scopehal
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
Tost has quit [Ping timeout: 252 seconds]
juli9610 has quit [Quit: Nettalk6 - www.ntalk.de]