azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal, https://github.com/azonenberg/scopehal-docs | Logs: https://freenode.irclog.whitequark.org/scopehal
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
<Bird|otherbox> so...how does one reach the main preferences box, first off?
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #scopehal
electronic_eel_ has joined #scopehal
electronic_eel has quit [Ping timeout: 272 seconds]
Bird|otherbox has quit [Ping timeout: 272 seconds]
Bird|otherbox has joined #scopehal
<azonenberg> Bird|otherbox: By pulling the ui-dev branch
<azonenberg> Lol
<azonenberg> That was one of the things katharina left in limbo when she got covid
<azonenberg> And if you want to help with UI stuff, your first step will be to merge all of the most recent changes into ui-dev, fix any conflicts, and then assess her changes and see what if anything you think is preventing them from being ready for mainline
futarisIRCcloud has quit [Ping timeout: 244 seconds]
lukego has quit [Ping timeout: 260 seconds]
LeoBodnar has quit [Ping timeout: 240 seconds]
wbraun has quit [Ping timeout: 244 seconds]
kc8apf has quit [Ping timeout: 244 seconds]
sorear has quit [Ping timeout: 260 seconds]
kc8apf has joined #scopehal
lukego has joined #scopehal
sorear has joined #scopehal
futarisIRCcloud has joined #scopehal
wbraun has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 5 commits to master [+2/-0/±8] https://git.io/JU0lO
<_whitenotifier-f> [scopehal] azonenberg 9ec025c - Runt, slew rate, and window triggers cannot accept digital inputs
<_whitenotifier-f> [scopehal] azonenberg be519fd - FilterParameter: added "string" type. Same as filename internally, only difference is the hint to the GUI to show a browser dialog or not
<_whitenotifier-f> [scopehal] azonenberg e3371dc - PacketDecoder: added controls for foreground color
<_whitenotifier-f> [scopehal] ... and 2 more commits.
LeoBodnar has joined #scopehal
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 5 commits to master [+0/-0/±8] https://git.io/JU0lG
<_whitenotifier-f> [scopehal-apps] azonenberg a37df80 - Changed WindowTrigger to TwoLevelTrigger in UI
<_whitenotifier-f> [scopehal-apps] azonenberg 4780fdc - Fixed segfault on unknown trigger types
<_whitenotifier-f> [scopehal-apps] azonenberg d828bec - Timeline: added null pointer check
<_whitenotifier-f> [scopehal-apps] ... and 2 more commits.
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JU0ln
<_whitenotifier-f> [scopehal-apps] azonenberg 3bedf89 - Updated submodules
electronic_eel_ is now known as electronic_eel
jevinskie[m] has quit [Quit: killed]
promach3 has quit [Quit: killed]
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/JU0Rd
<_whitenotifier-f> [scopehal-apps] azonenberg d7e1d71 - WaveformArea: removed some dead code and frame time spam
<_whitenotifier-f> [scopehal-apps] azonenberg e480351 - Initial implementation of CSV export in protocol analyzer. Fixes #174.
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #174: Protocol analyzer: CSV export - https://git.io/JURhM
promach3 has joined #scopehal
promach3 has quit [Remote host closed the connection]
jevinskie[m] has joined #scopehal
juli965 has joined #scopehal
promach3 has joined #scopehal
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #175: Add "about" dialog - https://git.io/JU0Vg
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #175: Add "about" dialog - https://git.io/JU0Vg
<Bird|otherbox> ui-dev, noted
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #176: When configuring a serial trigger, changing the radix should convert the pattern rather than leaving the same string - https://git.io/JU0VS
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #176: When configuring a serial trigger, changing the radix should convert the pattern rather than leaving the same string - https://git.io/JU0VS
<azonenberg> Bird|otherbox: the single highest priority on the GUI side right now is getting ui-dev up to date (it's probably 2-3 months behind master and there are likely some merge conflicts)
<azonenberg> then doing any additional work needed to get it ready to merge to master
<azonenberg> that will give us the preferences system, which a ton of other tickets depend on
<azonenberg> We can discuss priority of other stuff once ui-dev is merged
<Bird|otherbox> okiedokie
<azonenberg> Also, i don't actually remember what else she had put in that branch. It was more than just the preferences system
<azonenberg> so once it's up to date with master, if you could skim a diff and summarize what functionality was added that would be great. Just to get the lay of the land
<azonenberg> i think she was working on some kind of startup/welcome screen for when you start glscopeclient without loading a file or instrument on the command line. we have one but it's pretty basic
<azonenberg> And i dont know how far she got
<azonenberg> The preferences system is, i believe, pretty complete
<azonenberg> lain: so the latest WUT on the lecroy API front
<azonenberg> They have different enums for different parts of the system that have semantically the same meaning. But the values are different
<lain> D:
<lain> nO
<azonenberg> So for example "less than" on a slew-rate trigger under app.Acquisition.Trigger.SlewRate.Condition is coded as "LessThan"
<azonenberg> but "less than" on a pattern trigger for UART under app.Acquisition.Trigger.Serial.UART.PatternOperator is coded as "Smaller"
<azonenberg> Scopehal hides this from you, both are Trigger::CONDITION_LESS
<azonenberg> But it makes the driver code ugly :p
<azonenberg> because you have to use one of two different serializers depending on which field you're writing the same enum to
<lain> oof
<azonenberg> I've gone through a lot of trouble to make sure that user-facing scopehal APIs are as orthogonal as possible
<azonenberg> But the scope-facing APIs are... not
<azonenberg> So "LessThan" vs "Smaller"
<azonenberg> and "GreaterThan" vs "Greater"
<azonenberg> "Equal" and "InRange" ares the same but one has "OutOfRange" and the other has "OutRange"
<azonenberg> Whyyyyy
vup has quit [Ping timeout: 265 seconds]
anuejn has quit [Ping timeout: 258 seconds]
anuejn has joined #scopehal
vup has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+2/-0/±10] https://git.io/JU0o3
<_whitenotifier-f> [scopehal] azonenberg ea840b2 - Initial implementation of UartTrigger and LeCroy support for it. Fixes #251.
<_whitenotifier-f> [scopehal] azonenberg closed issue #251: LeCroy: Add UART serial trigger support - https://git.io/JUBKi
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/JU0os
<_whitenotifier-f> [scopehal-apps] azonenberg 778d6f3 - Fixed several issues in digital overlay rendering
<_whitenotifier-f> [scopehal-apps] azonenberg c2af97c - Updated submodules
alexhw has quit [Ping timeout: 265 seconds]
alexhw has joined #scopehal
deltab has quit [Ping timeout: 260 seconds]
deltab has joined #scopehal
bvernoux has joined #scopehal
anuejn has quit [Quit: No Ping reply in 180 seconds.]
anuejn has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg opened issue #254: Add quadrature decode support for rotary encoders - https://git.io/JU0NQ
<_whitenotifier-f> [scopehal] azonenberg labeled issue #254: Add quadrature decode support for rotary encoders - https://git.io/JU0NQ
<azonenberg> lain, monochroma, Bird|otherbox: any thoughts on what this would look like?
<azonenberg> i won a $100 digilent shopping spree in a promotion they were running, got a bunch of pmods including one with a rotary encoder
<azonenberg> i figure i should make a scopehal driver for it but i'm not quite sure what makes sense as far as output data format
<azonenberg> a scopehal decoder*
<azonenberg> My thought is to have you specify the number of pulses per revolution then output an angular velocity in deg/sec for each pair of pulses?
bvernoux has quit [Quit: Leaving]
<monochroma> hmm maybe, though i don't see a good reason to implement it when there are a lot of other protocols and such that are way more useful
<azonenberg> sure but it's probably 15 minutes of work to implement lol
<azonenberg> And it would be a nice change of pace from boring glue logic adding all of lecroy's triggers
<monochroma> hehe
<azonenberg> as of now i have support for UART serial trigger plus half a dozen or so of the standard and "smart" trigger types
<azonenberg> Remaining types are glitch, TV, pattern, measurement, plus combination trigger types like "a then b" which i have to figure out how to fit into the model
<azonenberg> measurement trigger is likely not to be supported in the near future as that would mean implementing the whole lecroy measurement model
<azonenberg> Then i have spi and i2c serial triggers on my scope that i want to add soon too
<azonenberg> (on the waverunner, they're not enabled on the HDO - it's part of the decode software package)
<electronic_eel> azonenberg: about the rotary encoder decoder - the velocity would make sense for encoders that are used to measure rotation speeds and similar things
<electronic_eel> but for an encoder that is used as user input I'm not so sure if it is helpful
<electronic_eel> how about just a up/down counter as alternative?
<electronic_eel> so for example if you rotate it on click right, it goes from 0 to 1, if you then rotate two clicks left it goes to -1
<azonenberg> we could have multiple decodes or multiple output formats for one
<azonenberg> in partiuclar though, therer's no absolute position output from pure quadrature
<azonenberg> you just have directions
<electronic_eel> yes. but you could just start counting at 0 when the decoder starts and count from there
<azonenberg> you can integrate it but how do you plan to handle the +C term? assume it's zero at the start of the acquisition?
<azonenberg> i guess
<azonenberg> How's this sound
<azonenberg> Decode takes A, B, and reset inputs
<azonenberg> reset is optional
<azonenberg> plus a parameter for pulses per rev
<azonenberg> then outputs phase and rotational velocity
<electronic_eel> reset is a good idea. when debugging ui code, you could wire a gpio to the reset channel and use it to compare the decode from the scope with the data in your software
<azonenberg> as separate streams
<azonenberg> apparently some encoders meant for absolute position have a reset output too
<azonenberg> just a 1 pulse per rev track
<electronic_eel> so you are not convinced yet that the pure counter makes sense?
<azonenberg> You'll be able to output phase as ticks or an angle
<azonenberg> the inputs to the decode will be I, Q, reset channels, I/Q required and reset can be null
<azonenberg> then parameters will be reset polarity, pulses per revolution, and phase format as angle or tick count
<azonenberg> angle wraps to +/- 180 deg, tick count counts up/down forever
<azonenberg> Angular velocity will be reported as ticks/sec or deg/sec
<electronic_eel> hmm, I "output phase" isn't an option I would look for a tick count under. it suggests some rotation, reset after some pulses per revolution and similar things to me
<azonenberg> I'd say "output format" or similar
<azonenberg> or "angle format"
<azonenberg> i'm not sure what i'd call it
<azonenberg> but it seems logical to report absolute position and rotational velocity, then let you specify units
<electronic_eel> do you have to specify pulses per revolution to make the decoder work or can you leave this option empty if you just care about ticks?
<azonenberg> It will be ignored if you specify ticks as the output format
<azonenberg> Angle units will be ticks, deg, and rad
<azonenberg> ticks do not wrap, deg/rad do
<azonenberg> velocity units are angle units per second/minute
<azonenberg> Fitting this into the current unit framework might take a little thought but i think i can make it work
<electronic_eel> yes, I think this will cover the use cases I have in mind well
<azonenberg> basically i want it usable for both motor shaft and UI wheel analysis
<azonenberg> The challenge here will be figuring out how to handle multiple units with the same semantic sense
<electronic_eel> yeah. the ui stuff has the difficulty that you sometimes want acceleration (number entry) and sometimes not (menu navigation)
<azonenberg> Right now for example we have one unit for voltage, one for current, etc
<azonenberg> and one for time
<azonenberg> So i have to figure out how to handle having multiple units for time and converting between them
<azonenberg> and how to handle derived units like angular velocity
<azonenberg> what i might do is create a mode for a unit that's defined in terms of unitA per unitB
<azonenberg> Not sure yet
<azonenberg> Initially i will do tick format only as that's easy, but this ties into more general questions about unit handling
<electronic_eel> where do the units matter? is it for using them as inputs for further decodes or math channels?
<azonenberg> Both. And just display in the Y axis of this trace
<azonenberg> My plan is to have one canonical unit internally that everything uses
<azonenberg> then multiple output scaling factors
<electronic_eel> hmm, couldn't you just output a string for display?
<azonenberg> so for example all time is in ps, you can use SI prefixes to scale to arbitrary numbers of seconds
<azonenberg> but i want to support min/hr too
<electronic_eel> ah, ok, that makes sense, a string wouldn't be enough for that
<azonenberg> And Unit::ToString() converts a double or float to a string
<azonenberg> including scaling and prefix generation etc
<azonenberg> sorry it's PrettyPrint()
<azonenberg> so 1300 ps will pretty print as "1.3 ns" (i forget how many decimal places are shown by default)
<azonenberg> and it will scale up from there. but I only do SI scaling
<azonenberg> And there's no support for second-order units like deg/sec right now
<azonenberg> so the question is, if i have a time value in the native picoseconds and i want to display it as, say, hours
<azonenberg> how do i do that?
<azonenberg> It seems to me that i should still have picoseconds be the native unit and just have the pretty print function take some kind of argument to say how to display it
<azonenberg> But i'm not quite sure how that will work yet. maybe i should have two types in the unit object, the native unit and the display unit?
<azonenberg> electronic_eel: so thinking more i'll simplify it a bit
<azonenberg> I think the quadrature decode will only output phase
<azonenberg> And i will then have a derivative filter that gives you velocity
<azonenberg> or, applied twice, acceleration