<azonenberg>
and you can scroll around it interactively fast
<azonenberg>
it's only 25 million points
<azonenberg>
What are the channels, CH0 = D+ and CH1 = D-? or vice versa?
<codysseus>
Yes
<codysseus>
0 is D+ 1 is D-
<d1b2>
<Attie> re cross compile: ok, i'll make that my number one i think
<azonenberg>
codysseus: and is this full speed, just to confirm? not low speed?
<codysseus>
Yes
<codysseus>
oh
<codysseus>
No this is Low Speed
<codysseus>
It's a keyboard.
<azonenberg>
Ok
<codysseus>
1.5 Mb/s
<azonenberg>
That might be part of the problem, unless you patched the usbcsv example i wrote
<azonenberg>
the decode isnt currently smart enough to know which speed you are using
<azonenberg>
it expects you to tell it
<azonenberg>
and usbcsv hard codes full speed
<azonenberg>
it's nice to have low speed test data though. I've never actually got any low speed test waveforms
<azonenberg>
in fact scopehal issue #63 is now closed, because i have test data :p
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #63: Find a USB 1.0 Low Speed device to test decoders on - https://git.io/JIYWO
<_whitenotifier-f>
[scopehal] azonenberg closed issue #63: Find a USB 1.0 Low Speed device to test decoders on - https://git.io/fjZ1v
<azonenberg>
We've literally never tested the usb decode on low speed
<azonenberg>
because nobody had a low speed device handy to test with lol
<codysseus>
haha wow
<azonenberg>
So thanks for the test data, now to see if we actually have a bug when the data is interpreted as low speed
<azonenberg>
Or whether you just need to update usbcsv to specify the correct operating mode
<codysseus>
No problem, happy to help!
<azonenberg>
There is a kinda-sorta bug in that i print lots of errors if a waveform starts midway through a packet
<azonenberg>
ideally we should filter it better to just ignore any data before we have a full packet
<_whitenotifier-f>
[scopehal] azonenberg opened issue #362: USB decode: cleanly discard partial data if waveform begins halfway through a packet - https://git.io/JIYW7
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #362: USB decode: cleanly discard partial data if waveform begins halfway through a packet - https://git.io/JIYW7
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
<codysseus>
I need to jet. Good luck with debugging!
<_whitenotifier-f>
[scopehal] azonenberg a639676 - DecodeData: correctly calculate DATA packet length. See #361.
<_whitenotifier-f>
[scopehal] azonenberg 04fa6b3 - USB2PCSDecoder: discard garbage before a packet begins. Fixes #362.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #362: USB decode: cleanly discard partial data if waveform begins halfway through a packet - https://git.io/JIYW7
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JIYEn
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pepijndevos has quit [Ping timeout: 240 seconds]
pepijndevos has joined #scopehal
<codysseus>
Wow, a flurry of commits! I will give it a try!
<azonenberg>
codysseus: a639676 is the only one that actually fixes your specific issue. the rest are some other cleanup, as well as making it easier to specify the USB speed the link is running at
<azonenberg>
when using the usb decode in glscopeclient you'll now see in, out, setup, and malformed/bad CRC packets highlighted in different colors
<codysseus>
Oh sweet. Ah I see there's an enum for specifying speed.
<azonenberg>
Yep. The color coding has been supported in the GUI for quite some time, but i didn't get around to retrofitting color coding logic into the individual decodes until recently
<azonenberg>
i guess i never got around to doing usb
<azonenberg>
I don't know what the status of high speed (480 Mbps) in mainline is. I know miek was doing development on it, but idk if that code got merged yet
<azonenberg>
and we don't support the... PRE, I think it's called? packet type which is used for low-speed USB in the upstream of a hub
<azonenberg>
but if you're sniffing on the device side, not between a hub and the root, that should be a non issue
<codysseus>
That would be cool to be able to do that, but my LA is too slow ;_;
<codysseus>
What protocols do you normally work with?
<azonenberg>
A bit of everything. In my own hardware designs I'd say my #1 protocol is Ethernet (and TCP/IP on top of that) although obviously there's heavy use of uart, i2c, spi, etc for low speed stuff on the FPGA boards
<azonenberg>
At work, whatever the customer's gizmo is using
<azonenberg>
i wrote a quad spi flash protocol analyzer in glscopeclient that lets me sniff a QSPI bus and see address+data read/write packets which is great for understanding boot-time behavior of devices, finding secure boot bugs, etc
<azonenberg>
for glscopeclient dev. any time i get my hands on a protocol implementation that's within my scope bandwidth i'll write a decode for it
<azonenberg>
right now for example i'm working on PCIe gen2 because i just bought a raspberry pi 4
<azonenberg>
and they use pcie 2.0 x1 between the SoC and the USB controller
<azonenberg>
USB 3.0 is probably next on my to-do list because i already have the pi on my bench with probes on it
<codysseus>
It's cool to be able to see how your devices are communicating. I assume you have played around with Glasgow too?
<codysseus>
That's really cool!
m4ssi has quit [Remote host closed the connection]
<azonenberg>
I dont actually have a glasgow (at least intact, long story)
<azonenberg>
been on my list of things to play with
<azonenberg>
My goal lately with glscopeclient has been trying to implement a ton of protocol decodes as well as implementing advanced signal integrity capabilities like eye patterns, jitter analysis, channel emulation, emphasis, equalization, etc
<codysseus>
Oh that is big for Open Source EE software.
<azonenberg>
not sure if you saw this when i tweeted it
<azonenberg>
But i think i'm getting to the point that i'm competitive with pretty expensive SI tools from the big names
<azonenberg>
there's definitely still things they can do that we can't, but when you're comparing "free and open source" to "several thousand dollars per seat"...
<azonenberg>
even only half the functionality is still a good start lol
<codysseus>
Very true.
<codysseus>
Wow PCIe looks very strange
<azonenberg>
What about it is strange?
<codysseus>
I guess I am not as familiar with different protocols. I am used to LH + LL, but the varying peaks are interesting
<codysseus>
I have a lot to learn about low level protocols
<azonenberg>
That's because of the de-emphasis
<azonenberg>
it's still only a 2-level signal
<azonenberg>
but they are boosting the signal on rising edges in anticipation of loss on the cable
<azonenberg>
or on the motherboard
<azonenberg>
it looks strange here because you're looking at it on the transmit side, at the receiver it should look bimodal
<azonenberg>
although, as i go into later on in the video, i think the pi4 in particular overdid it
<azonenberg>
the drive strength is way too high for such a short run
<codysseus>
That creates a lot of EMR right?
<azonenberg>
It does produce more EMI than necessary, yes
<azonenberg>
But they probably get away with it and pass FCC test limits because of the spread spectrum clocking
bvernoux has joined #scopehal
<codysseus>
Really neat video. glscopeclient is powerful
<azonenberg>
That's the idea lol
<azonenberg>
incidentally, i believe you're our first user trying to use libscopehal for headless applications. everyone else is using the GUI
<azonenberg>
So if you have any suggestions/feedback on the API in the library itself, let me know
<bvernoux>
hello
<bvernoux>
yes headless usage is interesting
<bvernoux>
I have pain to imagine how it works ;)
<azonenberg>
bvernoux: it's easy
<azonenberg>
you put the oscilloscope in a guillotine
<azonenberg>
chop off the head
<azonenberg>
and use the other half
<azonenberg>
:p
<bvernoux>
yes ;)
<bvernoux>
you have no display and you just do blind oscilloscope ;)
<bvernoux>
It remember me the latest challenge I was doing with Ledger to inject exploit remotely and try to do hardware fault with the MCO of the CPU ;)
<codysseus>
Sure thing! I am honored lol. I do have a question, how do I set the speed of the PMA decoder if it is within a filter? I am still a bit new to the interface.
<azonenberg>
codysseus: in the GUI? double click the little channel name box for the PMA decode
<azonenberg>
There will eventually be a graphical filter graph editor, similar to gnuradio companion, that shows all of the filters in the graph (even those which are not actively being rendered on screen) and lets you reconfigure or reconnect them
<azonenberg>
but that will be a major coding project and i haven't had the time to do it yet
<codysseus>
No, I am talking about in the program that you wrote. There's a filter created for the USB2PMADecoder, but I am not sure how to get at the underlying PMA2Decode object.
<azonenberg>
Oh, Filter is the base class for all of the other filters
<azonenberg>
just dynamic_cast it
<azonenberg>
rather than saying pma = Filter::CreateFilter(...)
<azonenberg>
do pma = dynamic_cast<USB2PMADecoder*>(Filter::CreateFilter...)
<azonenberg>
The other option you can do is set parameters by string name. This is how the GUI does it
<codysseus>
Aaah I see! Should have looked a little closer at the class definition.
<azonenberg>
that will work on just a base Filter object
<azonenberg>
but i try to discourage that as it requires hard coding strings
<codysseus>
I do like that better than casting.
<azonenberg>
Up to you, both will work
<azonenberg>
Internally the parameters are a std::map from string to FilterParameter objects
<azonenberg>
which is a variant type
<azonenberg>
this way we don't need to write custom GUI code for each new type of filter
<azonenberg>
it dynamically discovers the name of every input and parameter and constructs a dialog on the fly
<codysseus>
That's really neat! Good design.
<azonenberg>
The one thing i don't like is that the map has no inherent ordering, so i sort the names alphabetically for display in the GUI
<azonenberg>
which sometimes produces counterintuitive ordering of parameters
<azonenberg>
so i'm thinking of eventually adding some way to hint the gui that certain parameters should be grouped together or something
<azonenberg>
the other thing i don't like is that it's not i18n friendly
<azonenberg>
in particular, there's not a good way to translate the GUI using this model because the displayed name of the parameter is used as an index into the map and also saved in .scopesession files
<azonenberg>
so if you naively replace the text name of the parameter in a translation, files created with the gui set to one language won't be interchangeable with the gui set to another
<azonenberg>
i think the better long term solution would be to keep using the English name internally as a key, but have a remapping function that takes in the English parameter name as an argument and returns a display name in your local language. Or something like that
<azonenberg>
or alternatively, switching from string names to integer IDs. This would allow easily sorting parameters because you could use the ID as a sort key independently of the lexical sort order of the string name
<azonenberg>
but it would break compatibility with existing .scopesession files
<azonenberg>
unless i added some kind of compatibility layer that would accept either an english strnig or numeric ID in the file, but always write numeric IDs moving forward
<azonenberg>
Anyway, that's a long ways out but something in the back of my mind
<codysseus>
That is the sort of thing to think about for long term management. I would say integer representation makes sense since it would be agnostic to locale
<azonenberg>
Yeah. And it also has a sort order independent of the lexical sort. We can also use a vector instead of a map which will be slightly faster
<azonenberg>
Let me actually make a ticket for that now, while i'm thinking about it
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #363: Change indexes for FilterParameter from ASCII strings to numeric IDs - https://git.io/JI354
<_whitenotifier-f>
[scopehal] azonenberg opened issue #363: Change indexes for FilterParameter from ASCII strings to numeric IDs - https://git.io/JI354
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #363: Change indexes for FilterParameter from ASCII strings to numeric IDs - https://git.io/JI354
<codysseus>
I have another question, I am getting compilter errors saying "SPEED_LOW" is not a member of USB2PMADecoder
<codysseus>
Which is weird, because the enum is in the class definition :/
<azonenberg>
Did you not pull all of the submodules?
<azonenberg>
that's one thing git doesn't do well by default
<azonenberg>
"git config submodule.recurse true" in the scopehal-apps checkout then pull
<codysseus>
Ah-ha, I believe that was the case.
<azonenberg>
i have no idea why git defaults to not giving you all of the code
<azonenberg>
i struggle to think of a situation in which this is desired behavior
<azonenberg>
in particular, while i can somewhat understand the desire to default to a "light" checkout that doesnt include all of the submodules
<azonenberg>
once i've checked out a module, it seems reasonable that i want to keep it in sync with the version pointed to by .gitmodules
<azonenberg>
except in git's case the users are developers
<azonenberg>
one would think devs understand devs
<azonenberg>
clearly not :p
<codysseus>
lol
<codysseus>
So I set the speed to low using the second method you specified and it yielded 0 packets in the Packet Decoder. Is that something I need to set for all filters?
juli966 has joined #scopehal
<codysseus>
Hmm, the waveform is full of USBPacketSymbol::TYPE_ERROR
<bvernoux>
I'm seriously thinking to buy a PC Tower (silent) with AMD Ryzen 9 5900X
<bvernoux>
for development ...
<bvernoux>
It clearly destroy all Intel CPU ;)
<miek>
do it :)
<azonenberg>
codysseus: see what happens if you open the csv in the gui and decode by hand
<azonenberg>
well not by hand but on screen
<azonenberg>
so you ca nsee what's going on
<azonenberg>
just "glscopeclient file.csv"
<codysseus>
I will give that a shot!
<azonenberg>
Right click on each waveform to apply the next decode in the chain, or double click the channel name box to reconfigure
<azonenberg>
note that it is strongly typed, e.g. you cannot apply a USB PCS decoder to anything but a USB PMA waveform
<azonenberg>
So it's important to right click *on the PMA waveform* to apply the PCS decode
<azonenberg>
This is something that throws new users off sometimes
<codysseus>
Noticed that in section 3.4.1 in the Fedora section it uses `apt`
<codysseus>
Will take a bit, I was using the program on a remote machine
<azonenberg>
I didnt realize there was a fedora section, i thought we only had debian/ubuntu and mingw build instructions. guess somebody contributed that and i didnt read it in detail :p
<Bird|otherbox>
azonenberg: re: the i18n thing: strings vs. integer indexes as keys kind of depends on what you use for an i18n/l10n API/lib
<Bird|otherbox>
older APIs (catgets() and a variety of others) use integer keys, while newer APIs (gettext() and friends) use strings -- the latter does have the benefit of making things way easier for *translators*
<Bird|otherbox>
let me look up what gtkmm does, in particular
<_whitenotifier-f>
[scopehal] tarunik commented on issue #363: Change indexes for FilterParameter from ASCII strings to numeric IDs - https://git.io/JIsCu
<_whitenotifier-f>
[scopehal] tarunik edited a comment on issue #363: Change indexes for FilterParameter from ASCII strings to numeric IDs - https://git.io/JIsCu
<azonenberg>
Bird|otherbox: so there's a couple of different things
<azonenberg>
one is i18n friendliness
<azonenberg>
the other is allowing clean sort orders
<azonenberg>
i.e. having property names sorted independently of lexical sort ordering
<azonenberg>
We'd also have to figure out how we want to serialize property names in save files
<azonenberg>
right now we use the actual property name
<azonenberg>
I guess the other option would be to have some kind of group ID added to a property
<azonenberg>
or sort key, etc
<Bird|otherbox>
yeah, there are a couple different ways to skin this cat
<azonenberg>
Anyway at least there's a ticket so we can work on it later
<azonenberg>
Just didn't want to forget
<azonenberg>
Bird|otherbox: BTW are you actively working on any scopehal stuff right now? or are you too busy to do anything? or what's your current dev status
<Bird|otherbox>
kind of busy over here
<azonenberg>
Ok, just checking
<Bird|otherbox>
(actually been trying to WFH but with...some limits to my success)
<azonenberg>
bluezinc: also, did you have a chance to fix up the i2s decode as we discussed?