<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 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
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>
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