<d1b2>
<azonenberg> Hey @fredzo_72653 I'm getting CI errors in the new siglent code
<d1b2>
<azonenberg> a bunch of -Werror=maybe-uninitialized
<d1b2>
<azonenberg> /home/runner/work/scopehal-apps/scopehal-apps/lib/scopehal/SiglentSCPIOscilloscope.cpp:1902:33: error: \u2018lastSampleValue\u2019 may be used uninitialized in this function [-Werror=maybe-uninitialized] 1902 | if((sampleIndex > 0) && (lastSampleValue == sampleValue) && ((sampleIndex + 3) < numSamples))
<d1b2>
<azonenberg> please fix
pirate_ has joined #scopehal
<azonenberg>
o/
<azonenberg>
everybody welcome pirate_, the new icon artist I've just started working with doing filter graph icons
<pirate_>
henlow!
pirate_ is now known as pirate
joshua_ has joined #scopehal
<joshua_>
\o/ I have always wanted to work with an icon artist for X1Plus stuff so I will definitely be excited to see the outcome of this :)
<azonenberg>
joshua_: nice. yeah she's actually one of three we are / have worked with
<azonenberg>
there's one that is in early trial stage and hasn't sent me any sample work yet, but is supposed to be doing icons for CAN bus and J1939 in the next week or two
<azonenberg>
tetrikitty drew most of the existing stuff but has had some personal / health issues and isn't able to keep up with the amount of stuff we need before release
<azonenberg>
pirate was telling me she's familiar with electronics and can code too, but right now the focus is going to be on icons since that's something she can do that none of the rest of uscan
<azonenberg>
us can*
Stary has joined #scopehal
<azonenberg>
we do need more code contributors but we need icons more :p
<pirate>
as far as electronics, i generally dabble more in the analog realm, but sometimes i play with digital
<joshua_>
I found that there were three iconography questions for X1Plus work: 1) defining and keeping a consistent 'style' between many system icons (how large is an icon? do we radius corners? how about on particularly small icons? what icons need to be larger in order to accurately convey what they mean?); 2) a sketch of an icon ("concepts of an icon", if you will) that accurately conveys what that icon needs to say; \
<joshua_>
and 3) the mechanics of actually putting down into a svg file that will rasterize to something that looks reasonable
<joshua_>
(question 1, unsurprisingly, became a more overarching UI/UX question!)
<azonenberg>
joshua_: yeah consistent style is extra hard when you're working with a team of artists rather than just one lol
Fridtjof has joined #scopehal
<pirate>
i've been using the color picker and just grabbing existing colors
<azonenberg>
yeah i mean more like line width and general "feel"
<joshua_>
yes, that is exactly right! and is the challenge around defining consistent standards ('all icons going forward should feel like these' is a good place to start). and is also why I am really annoying to work with on UI stuff because I have a tendency to micromanage on that kind of thing.
<azonenberg>
i think pirate is the fourth or fifth artist who's had a hand in ngscopeclient actually
<azonenberg>
we had somebody from a singaporean anime studio draw the initial toolbar icons which were better than nothing but definitely need an overhaul
<pirate>
azonenberg: ah, i also copied line widths
<azonenberg>
Great :D
<azonenberg>
then somebody else on mastodon did the upsample and threshold icons i think
<azonenberg>
and we used those to set the feel for all of the others which tetrikitty did
<azonenberg>
Latest version of the SD card and waterfall icons
<azonenberg>
I'm thinking maybe change the contacts on the card to yellow for contrast? while yellow is nominally our output color we also strive for some level of realism to make things understandable, and the Ethernet decodes have a true-to-life-color RJ45 icon now
<pirate>
ah, they are a different color, but i could make them contrast more
<azonenberg>
as far as the waterfall goes, i think you may have misunderstood. I wanted to keep the waterfall display filled in purple, just not under the waveform itself
<azonenberg>
let me make a mockup sec
<pirate>
oh, that's easy enough to do
<azonenberg>
also i think the waveform is a little too flat and fine detail for the size we're rendering it at
<azonenberg>
compare to the icon for the FFT filter which is a bit more "chibi-ified"
<azonenberg>
(also make sure the peaks in the waterfall and FFT are consistent with each other)
<joshua_>
haha yeah I was just about to say 'feel free to ignore me but my OCD would be very disconcerted about the FFT peaks not representing peaks in the waterfall'
<azonenberg>
This is what the actual fft and waterfall filter in a typical pairing would look like
<azonenberg>
it doesnt have to be this exact tone sweep of course
<azonenberg>
but a handful of tall peaks that obviously align to the waterfall display with the purplish fill around the waterfall activity areas
<joshua_>
consider also that the same chibification of that FFT probably will be useful for the design language that denotes various band pass filters
<azonenberg>
joshua_: So that was actually going to be her next task once i'm happy with this round of icons
<azonenberg>
we have programmer-art icons for bandpass, high pass, low pass, and notch filters
<azonenberg>
high and low are probably OK since they were lifted from the bandwidth filter
<azonenberg>
but i wanted the bandpass and notch ones redone
<joshua_>
also 'while I am at it', it was not obvious to me that blue meant in and yellow meant out on overlayed waveforms and/or frequency domain displays
<azonenberg>
pirate: does that clarify what i was looking for?
<joshua_>
(like I did not understand this until you said it now)
<azonenberg>
joshua_: Yeah that was the more high level visual design language we had chosen, it wasn't explicitly stated so much as we needed contrasting colors
<azonenberg>
and we wanted to be consistent about what color we used for what
<joshua_>
the 2:1 aspect ratio may permit something that would make more intuitive sense to me, "x -> y"
<azonenberg>
We do that in some cases, such as "CSV import" and "CSV export"
<joshua_>
including blue -> yellow, or whatever, but 'the input is on one side, and the output is on the other side'
<joshua_>
yes, I think it is also done for 8b10b
<azonenberg>
That's vertical, but yes
<azonenberg>
It's totally dependent on the concept we're depicting and how plausible it is to do in that much space
<azonenberg>
for all of the measurements i think it worked out really well
<azonenberg>
like "rise time"
<joshua_>
yeah, those are single-measurement things, which make sense
<azonenberg>
But also, there's no requirement that we stick to icons forever
<azonenberg>
My goal at this point is to get initial iterations that are better than nothing for every filter
<azonenberg>
once they're done we'll collect feedback from a broader audience and fine tune ones we don't like
<azonenberg>
like, i dont want to cut corners but i dont want to spend a month fine tuning the icon for one filter
<azonenberg>
since we have another hundred or so left to do :p
<joshua_>
(the 8b10b one I should mock up some stuff that says, like, '00111 11000 -> K28.7', since nothing says '8b10b' to me quite like someone mentioning a comma symbol)
<azonenberg>
Yeah i was trying to depict the concept of 10 to 8 bits
<azonenberg>
but i'm not opposed to alternate representations
<joshua_>
yeah I saw the intent
<azonenberg>
there's two parts to iconography - mapping the concept to an abstract depiction, and actually rendering that abstract depiction as vectors that look good at the size/aspect ratio in question
<joshua_>
yes
<azonenberg>
You have to get both right for it to work well
<joshua_>
well, in my book, three, as I mentioned above :) but yes
<azonenberg>
well ok consistency across the family yes
<azonenberg>
pirate: ok so let's see, "spectrogram" is another easy one. just a waterfall turned on its side, with no fft on top
<azonenberg>
the DDR1/DDR3 ones will be the same basic idea as the SD data bus (the dram command bus is parallel) but with a dram bga package instead of a sd card
<azonenberg>
displayport aux can be a displayport connector, probably drawn in a more realistic color scheme like the ethernet ones
<azonenberg>
for FSK I'm thinking of a waterfall display minus the FFT on top (just the waterfall itself) with the signal alternating between two frequencies
<azonenberg>
and then maybe have that on the left half of the icon with a yellow digital waveform on the right and a purple arrow pointing at it?
<azonenberg>
play around with a few concepts and see what you like
<d1b2>
<fredzo_72653> I fixed those two (saw on github build) : /home/runner/work/scopehal-apps/scopehal-apps/lib/scopehal/SiglentSCPIOscilloscope.cpp:1845:13: warning: unused parameter ‘ch’ [-Wunused-parameter] 1845 | int ch) | ~~~~^~ /home/runner/work/scopehal-apps/scopehal-apps/lib/scopehal/SiglentSCPIOscilloscope.cpp:1902:33: error: ‘lastSampleValue’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
<d1b2>
1902 | if((sampleIndex > 0) && (lastSampleValue == sampleValue) && ((sampleIndex + 3) < numSamples)) | ^~ They're not popping on Windows build, hope that's all of them.
<azonenberg>
yeah seems like only newer gcc triggers them
<azonenberg>
they dont show up on my debian box either
<d1b2>
<azonenberg> About to go to bed will look in the morning
balrog has quit [Ping timeout: 252 seconds]
balrog_ has joined #scopehal
<d1b2>
<chille0417> FYI: I do also have a Riden PSU, RD6018 if my memory is correct, that I was thinking about making a driver for.
<d1b2>
<azonenberg> Oh cool. Is that one modbus too?
<d1b2>
<chille0417> Yes, I think all RD* are modbus.
<d1b2>
<chille0417> So I was thinking... maybe we should have native modbus support in ngscopeclient? A class that can map the modbus registers to whatever is used internally. Then a few other classes that can transport the data via TCP, UDP, serial and whatnot. I think the Modbus class should have some kind of configuration so the user could easily map registers to a specific device, without the need to recompile the code. In this way it would be possible to
<d1b2>
use basically every device used for property automation.
<d1b2>
<chille0417> It would be cool to be able to do things like long term datalogging on automation systems.
<d1b2>
<azonenberg> Yeah file a ticket and we'll think about the best way to architect it
<d1b2>
<azonenberg> I think we can probably reuse the SCPITransport layer
<d1b2>
<azonenberg> and have some kind of modbus layer on topo
<d1b2>
<azonenberg> top*
<d1b2>
<azonenberg> (despite the name they're raw data transports and will work with non-scpi data)
<d1b2>
<altracer> If scopehal has an ARM SWO/ITM plugin (well actually past orbcat), I see adding a Modbus RTU master/poller only as an industrial win
<d1b2>
<chille0417> Okay, cool, I will think a bit more about how this could possible work, and also study the SCPITransport and other related classes.
<d1b2>
<altracer> sign me up for the same ticket or I'll try to watch it myself (GH issue?)
<d1b2>
<chille0417> Sure, I'll send you a notice when I have created a ticket.
<azonenberg>
yeah this definitely needs a ticket to track
<azonenberg>
i'm all for adding all kinds of data sources
<azonenberg>
i have it pulling data from MQTT via an external bridge (ugly php script not something i'd upstream) as a test
<d1b2>
<chille0417> It would be nice to have some kind of generic data source/sink that could easily be used by another application. Then it would be possible to to weird or prorietary stuff in a separate application without touching the ngscopeclient code base. Think about it like making a plugin. An easy way (on Linux) would be to use be able to create a named pipe and send/receive data from it.
<azonenberg>
I think you're looking for the csvstream driver
<azonenberg>
this is meant for scalar value not waveforms
<d1b2>
<chille0417> Ah, so it can stream live? Thats nice. 🙂
<azonenberg>
it works with sockets but the server can be localhost
<azonenberg>
i use it with e.g. pulling sample data off my prototypes via orbcat
<azonenberg>
to get temperatures, voltages, and other health metrics
<azonenberg>
works great for low speed real time stuff although its not optimized for throughput
<d1b2>
<chille0417> It would be nice to have it for waveforms too. Or is it possible sample a scalar at a regular interval and create a wavefom from it? It would be nice for logging thinks like temperature over a longer time while running a process of some kind.
<azonenberg>
That's what the "trend" filter does
<azonenberg>
it plots a scalar live over time
<azonenberg>
intended for graphing multimeter, power supply, etc readings
<azonenberg>
but works fine for any filter or instrument with a scalar output
<azonenberg>
the catch is you're limited to one sample each filter graph update and ngscopeclient, as of now, cannot run the filter graph faster than the video update rate
<azonenberg>
so you can't get more than 60 Hz update rates
<azonenberg>
(with a typical monitor)
<d1b2>
<chille0417> Ah cool, I think I have to start experimenting with ngscopeclient to try to learn how it works.
<d1b2>
<chille0417> I'm totally fine with converting scalars to waveforms in less than the monitors refresh rate.
<azonenberg>
yep then the trend filter is your solution
<_whitenotifier>
[scopehal-apps] azonenberg 67d0836 - Updated to latest scopehal
<d1b2>
<fridtjof> oh hey, nice!
<d1b2>
<fridtjof> i'm actually not sure when i'll have the time to sit down and properly think about how to do this, but for now the approach i settled on was basically to offer some modbus facility either through a bridge (with some custom SCPI commands to tunnel r/w) or directly, and implement the whole "what register does what" in scopehal itself
<d1b2>
<azonenberg> Start by filing a ticket so we have a place to track the progress etc
<d1b2>
<fridtjof> technically it's worth looking at riden's network interface but no clue if that is in any way standard modbus
<d1b2>
<fridtjof> (it's kind of cursed to set up anyway so not sure i want to bother)
<d1b2>
<azonenberg> (fast forward two years and ngscopeclient has CIP and BACnet drivers too... lol)
<d1b2>
<fridtjof> lmao
<d1b2>
<azonenberg> and DNP3 and all kinds of other cursed scada protocols
<d1b2>
<azonenberg> i'm only half kidding i work with that stuff at work from time to time
<d1b2>
<chille0417> I almost have a <walloftext> Issue ready to be posted to the GitHub repository!
<d1b2>
<chille0417> @azonenberg And talking about SCADA... What do you think about adding some SCADA stuff? I would personally love to at least have a PID regulator. Or maybe we could wrap a whole PLC in a node, lol. There is some open source PLC projects that could be useful.
<d1b2>
<mpch> Notch filter to FFT seems to be broken Hmmm
<d1b2>
<mpch> @meownik did write a PID filter for it IIRC , it was very hacky but worked ok
<d1b2>
<azonenberg> So the big challenge there is that as of now, the filter graph has to be acyclic
<d1b2>
<azonenberg> if you want feedback it breaks that
<d1b2>
<meownik> IIRC I just escaped data out of it and wrote the control loop in python
<d1b2>
<azonenberg> yeah you can do awkward things like that. but if we want to support full closed loop control in the filter graph it's going to change how we do graph evaluations
<d1b2>
<azonenberg> because right now we treat it as a DAG we can topologically sort then execute filters in sequence, parallelizing where possible
<d1b2>
<chille0417> Okay, nevermind, I think I'll just skip the PID for now... 🙃
<d1b2>
<azonenberg> yeah that is definitely a >v0.1 feature
<d1b2>
<azonenberg> but absolutely more large scale complex closed loop experiment automation is something i would love to have
<d1b2>
<azonenberg> just a question of how best to get from here to there
<d1b2>
<josHua> hm I wonder how to graphically represent a generic FIR filter
<d1b2>
<josHua> "input-styled noise", "⊗", "dotted line sinc filter"?
<azonenberg>
Yeah i'm not sure. like the textbook diagram of how a fir is laid out is too complex and large to fit in an icon this side
<azonenberg>
size*
<d1b2>
<josHua> to represent "the input data", "convolved with", "something that you can configure, but a sinc is definitely typical of the kind of thing you would convolve with"?
<azonenberg>
pirate: also, i glanced over the new icons, i have some thoughts but am at work and won't have a chance to give proper feedback until the evening. Great first drafts, most will probably need some small tweaks
<d1b2>
<josHua> a large ⊗, with three arrows -- one from the upper left, in input style; one from the lower left, from a box with a sinc; one out to the right, in output style?
<azonenberg>
I think this is the kind of thing where we're gonna have to draw up some mockups
<azonenberg>
and see how they actually look at this size etc
<d1b2>
<josHua> a large "\Sigma k_n i(x+n)", with "i(x+n)" being in input style?
<d1b2>
<josHua> yes
<d1b2>
<fredzo_72653> @azonenberg , as a part of my ngscopeclient developer training 😅 I made a thing :
<d1b2>
<fredzo_72653> It's a Parallel Bus Protocol Decoder inspired by the UART Decoder
<d1b2>
<azonenberg> ah cool. i dont know if we'd want to upstream that as is, i'll think about it. but i'm sure you learned a lot about the data model doing it
<d1b2>
<fredzo_72653> I did indeed ! 😉
<d1b2>
<fredzo_72653> Yep let me know if you want me to create a PR, I think it's useful as it is for simple 8/16/32/64 parallel bus monitoring, but I'm not sure it is in line with typical ngscopeclient users, you tell me
<d1b2>
<azonenberg> Also, if you have some home grown plugins that aren't ready to upstream and dont want to constantly maintain patches against mainline scopehal
<d1b2>
<azonenberg> some home grown filters*
<d1b2>
<azonenberg> you can put them in a plugin
pirate has quit [Ping timeout: 252 seconds]
<d1b2>
<azonenberg> that's the express intent of the plugin model. something you either aren't ready to upstream or something proprietary you can't / won't share
<d1b2>
<azonenberg> I'd say lets hold off until we've had some time to think about how the new parallel bus data model is going to work
<d1b2>
<azonenberg> we may or may not go the same direction you went here
<d1b2>
<fredzo_72653> OK no problem, but I don"t think it collides with the parallel bus data model since it is a decoder rather than a filter, well at least it can live side by side with the current Prallel Bus instance
<d1b2>
<azonenberg> Yeah i just feel like having both in there would confuse users
<d1b2>
<azonenberg> i want to spend some time thinking about how parallel buses will work
<d1b2>
<azonenberg> and do it once, properly
<d1b2>
<azonenberg> And right now isn't the time for that since I have so much else on my plate
<d1b2>
<azonenberg> Which is why i suggested moving yours to a plugin so you and anybody else interested can use it without worrying about churn as development conitnues
pirate has joined #scopehal
<d1b2>
<azonenberg> And then at any point in the future if we decide upstreaming is the right course of action it's trivial to move it over
<d1b2>
<azonenberg> (Which actually reminds me... there's currently no way for filters in a plugin to declare what icon to use because icons are selected by a function in the MainWindow class... i need to figure out a solution to that)
<d1b2>
<azonenberg> Will probably have to add a new api somewhere to the filter class or the plugin interface or something