<_whitenotifier-7>
[scopehal-apps] azonenberg 6e6bce1 - Run vulkan SDK in msys2 shell
<bvernoux>
@azonenberg, nice I see someone have helped for the Vulkan to build on Windows
<bvernoux>
I have checked on my side but as I have 0 experience with Vulkan or any other OpenGL stuff I could not really help on that stuff
<azonenberg>
bvernoux: it's not finished yet, i'm still tweaking. This is infrastructure still
<azonenberg>
right now we don't *need* vulkan for anything but one unit test yet, but I'm initializing it in glscopeclient so we can catch major platform issues early on
<azonenberg>
But that's going to be changing over the coming days
<azonenberg>
bvernoux: any chance i can get you to update scopehal-docs with some of these changes from that PR?
<_whitenotifier-7>
[scopehal-apps] azonenberg 0ec5f20 - CI: run Vulkan installer from current dir which isn't in $PATH
<bvernoux>
@azonenberg, you want doc about the bridge ?
<bvernoux>
to build it with windows ?
<azonenberg>
That would be helpful too, but i meant adding the new Vulkan dependencies to the Windows build instructions in scopehal-docs getting started section
<azonenberg>
any and all work you can do to improve the Windows user experience would be helpful though
<azonenberg>
also cmake isnt finding the vulkan sdk on the github actions CI build
<azonenberg>
if you can debug, that would also be helpful. probably some env var not set or something
<Johnsel>
I would be a willing tester for Vulkan on Windows.
<Johnsel>
I started an attempt to build yesterday but got stuck on what seems to be a filesystem permission issue when installing msys2 on exFAT. I will start over on ntfs, if there are updated steps to test I can do that in one go
<Johnsel>
glscopeclient-manual.pdf has some weirdness when opened in Google Chrome btw, if you try to copy over command lines they often have extraneous space characters
<d1b2>
<louis> Lot of noise in initial commit moving things around. UART decoder has been updated to the new pattern.
<mxshift>
azonenberg: want a challenge? PSI5 is a bidirectional automotive interface at 128kbps _but_ one direction transmits by sending manchester encoded current pulses while the other direction sends voltage pulses
<mxshift>
there is also a management series channel sent as 2 bits per frame
<mxshift>
s/series/serial/
<azonenberg>
mxshift: lolwut
<azonenberg>
and i thought mipi was nuts
<azonenberg>
louis: back, got called out for sar. let me look
<azonenberg>
so the first thing is, i wouldnt make it a uartwaveform class. i'd make it asciiwaveform
<azonenberg>
the theory being, we can reuse it for any generic byte oriented transport
<azonenberg>
there's nothing uart specific (unless we want to be a more low level uart decode that also has fields for start/stop bits etc)
<azonenberg>
other than that, yes that looks like what i was envisioning
<azonenberg>
or maybe just "bytewaveform"
<azonenberg>
and then in the future we can have display options to print as ascii, hex, decimal, etc
<azonenberg>
So yeah go ahead and do all the other filters like that
<azonenberg>
mxshift: i think the best way to do such a thing would be an active mitm based test fixture that includes a shunt
<azonenberg>
and takes the left and right sides of the shunt as inputs (or a differential measurement across the shunt plus a single ended measurement of one end,
<mxshift>
there's folks in a car hacking Discord who have been trying to figure out how to both intercept _and_ emulate this.
<mxshift>
you've got to be careful about putting in another shunt as there are overall limits on resistance
<azonenberg>
so the other option would be some kind of hall sensor or similar
<azonenberg>
or a rogoski coil etc
<mxshift>
but yes, you need some way to get both voltage and current
<azonenberg>
in any case i think this would be best done w/ a dedicated fixture
<azonenberg>
i plan to make such fixtures for a lot of other protocols, this can just get added to the list
<mxshift>
at least it is somewhat slow
<mxshift>
but even once you have the waveforms, the decoding is a whole nother level
<mxshift>
kinda feels like it's an open spec because they never expect anyone to be able to implement it
<azonenberg>
lol
<azonenberg>
one of those, eh?
<azonenberg>
like perl :p
<azonenberg>
or... intel motherboards? :P
<mxshift>
oh, it's readable but they used all sorts of tricks
<mxshift>
on the other hand, this is used for airbag control so it must be quite robust
<azonenberg>
I meant more like "deviate from the reference design at your own peril"