electronic_eel_ has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg>
welp, now that i have the final PCB pinout for MAXWELL i'm starting an FPGA skeleton for the main FPGA to make sure all of the clocks and pinouts etc are right
<azonenberg>
Raw Win32 is a pain, this is why things like GTK exist :p
<katharina>
yea, im currently building a cross platform alternative to the task dialogs from Windows in gtkmm, just to get back into things
<katharina>
but for that i have to inspect what the windows thing can do, which is a pain haha
<azonenberg>
Lol
<azonenberg>
Lovely
<azonenberg>
katharina: btw, not sure if you've seen the new UI icon set yet?
<katharina>
i have! they look awesome
<katharina>
seen it on twitter i think
<azonenberg>
the artist supplied them as SVG, i rasterized them to 24x24 but i need to do 48x48 exports of them
<azonenberg>
and at some point i want you to add a preference for icon size
<azonenberg>
i think there's a ticket open already
<katharina>
out of interest, how much did you pay for the set? I am totally not aware what the price range for something like this is
<azonenberg>
$50 per icon
<katharina>
azonenberg: i can do that
<katharina>
azonenberg: thats fair
<azonenberg>
no idea what the going rate is but this was a studio i've worked with in the past
<azonenberg>
they had never done UI work before and offered a good rate because of that
<azonenberg>
they're mostly an anime studio LOL
<azonenberg>
they did the "furry boat" and "tiny schoolgirls building a PCB" pics i commissioned before
<azonenberg>
(different artists, but the same studio)
<azonenberg>
i need icons for "auto trigger" and "force trigger" still
<azonenberg>
but haven't decided what they should look like, so if you have any ideas comment on the issue for that
<katharina>
thats an interesting switch from anime to UI haha, if I asked that my furry art contacts they would laugh at me :D
<azonenberg>
The artist has no idea what oscilloscopes are and just drew what i tell her to :p
<azonenberg>
well the girl that did the icons is kinda their outcast
<azonenberg>
she's their non-anime-project artist :p
<azonenberg>
although she probably does anime stuff TOO
<azonenberg>
the studio as a whole is mostly anime style though
<katharina>
regarding the "schoolgirls building a PCB" pic, how much did you pay for that?
<azonenberg>
I believe $800? they gave me a discount for it being noncommercial
<azonenberg>
@shapoco did the ORIGINAL schoolgirls building a PCB pic but i didn't know that at the time
<azonenberg>
or i would have commissioned him/her instead
<azonenberg>
i had just seen the pic floating around the internet and wanted more like it :p
<azonenberg>
I plan to do more in the series, my plan for the next one is a rework themed piece
<katharina>
nice. good to see theyre not undercharging. furry artists are almost always criminally undercharging
<azonenberg>
a telecom truck with a giant spool of magnet wire on the back
<katharina>
azonenberg: that sounds awesome
<azonenberg>
and probably jackhammering off soldermask from a trace
<azonenberg>
but i havent figured out the exact scenery yet
<azonenberg>
and most furry artists IME are indies
<azonenberg>
This is an actual professional art studio
<azonenberg>
(Singapore based)
<azonenberg>
Collateral Damage Studios
<katharina>
right, that definitely plays into it
<azonenberg>
But yeah i intend to continue using them for my art needs in the future. Reasonable pricing and great work
<katharina>
yea. i also got my go-to artists where I can expect good communication etc
<katharina>
hm the question about the auto and force trigger icons is interesting...
<azonenberg>
start/stop/single map well to media player icons
<azonenberg>
auto/force are less obvious
<pepijndevos>
I'm getting a warning from cmake about two different opengl, is this significant?
<azonenberg>
pepijndevos: I see it too, it should be safe to ignore for now
<pepijndevos>
Will it break horribly if you pick the wrong one? I've set the non-legacy version now. I just updated my system, maybe this version of my graphics drivers is actually functional...
<pepijndevos>
I just had an idea that is approximately my level of crazy: do my entire thesis presentation with the scope in XY mode as display
<pepijndevos>
I'd consider it if I had a good signal generator and old analog scope that directly controls the CTR beam
<azonenberg>
lol
<pepijndevos>
next-level: control the scope with the IQ components of my receiver
<pepijndevos>
Oh shit, now I got to do it. I can do a QAM thing with my laptop audio to draw pictures. The digital scope has arbitrary persistence so it could be very slow
katharina has quit [Quit: Lost terminal]
<pepijndevos>
uhhhh nope still not working very well
<pepijndevos>
it's doing 0.06 WFM/s and the display look kinda wrong
<azonenberg>
Sounds like more driver problems with the Rigol side
<azonenberg>
(I normally use the default GL and that works fine for me, not GLVND)
<pepijndevos>
my scope is currenty set at 200us/div doing 2GSa/s with 40Mpts, and the GUI is showing picoseconds. If I zoom out, the time scale just vanishes after a while
<azonenberg>
That definitely sounds like a driver bug
<pepijndevos>
if only I had another scope to cross-check
<pepijndevos>
Should the timescale of the UI match that of the display on the scope?
<pepijndevos>
Could it be helpful to try ehternet instead of usb? or it's at a higher level
<azonenberg>
The UI timescale can be zoomed in and out, but it should be sane. Not picoseconds
<azonenberg>
that suggests the driver is failing to get the scope's actual sample rate
<pepijndevos>
Any suggestions how to debug that?
<azonenberg>
Add "--debug --trace SCPITMCTransport" to the argument list when launching glscopeclient
<azonenberg>
look at the data coming and going specifically related to the timebase
<azonenberg>
See if that gives any hints
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+7/-0/±5] https://git.io/JJnWM
<_whitenotifier-b>
[starshipraider] azonenberg 3686351 - Began work on initial MAXWELL HDL skeleton
<azonenberg>
ok so i did a bit more refactoring. The new design calls for the trigger and compression datapath to run at 312.5 MHz
<azonenberg>
With a 496 bit bus (4 samples on each low-speed input and 32 on each high speed)
<azonenberg>
Sooo now i have to start thinking about what the trigger and compression logic will actually look ilke
<azonenberg>
I feel like allowing arbitrary pattern logic on the full 96 channels would be impractical
<azonenberg>
I'm thinking of something vaguely similar to the greenpak state machine IP, where you have a series of event sources and a state counter or something like that
<azonenberg>
not sure yet
<azonenberg>
Part of the challenge is going to be figuring out if there's a way to make more than one state transition per clock
<azonenberg>
or if i'm going to be limited to running the trigger logic at 312 Mbps max
<azonenberg>
Anybody have ideas here?
<azonenberg>
i'd really like to be able to do hardware decodes of arbitrary serial protocols
<azonenberg>
With fairly high complexity, like triggering when a SPI flash reads from a certain address
<azonenberg>
lain, monochroma: ideas?
<pepijndevos>
azonenberg, can you explain the problem a bit more? I'm missing a lot of context to have any idea at all.
<azonenberg>
pepijndevos: I'm trying to figure out how to create complex logic triggers for MAXWELL
<azonenberg>
The basic idea is, I have 96 channels that are sampled at 1.25 Gsps and deserialized by a factor of 4, giving 4 bits per clock @ 312.5 MHz
<azonenberg>
92 channels*
<azonenberg>
and 4 channels sampled at 10 Gsps and deserialized by 32, giving 32 bits per clock @ 312.5 MHz
<azonenberg>
In total i have 496 bits @ 312.5 MHz representing the state of the inputs since the last clock cycle
<azonenberg>
So the question is, what do you do to that data stream in order to decide that an interesting event has happened and you want to trigger?
<azonenberg>
LAs generally have far more complex trigger conditions than oscilloscopes, you're not just triggering on a rising edge
<azonenberg>
I want to be able to look for specific fields within packets and such
<pepijndevos>
(intermediate question, for lan, do I just enter the IP? can;t connect, but can ping the scope)
<azonenberg>
pepijndevos: if it's a rigol, ip:port, port is probably 5555
<azonenberg>
rigol is weird, the default port for SCPI is 5025 and they don't use it
<pepijndevos>
connected!
<pepijndevos>
So the data arrives in an FPGA, and you want to design something that lets you express what to trigger on?
<pepijndevos>
I managed to zoom out and see a whole capture but now everything is completely frozen.
<azonenberg>
pepijndevos: interesting
<azonenberg>
so still some issues. Is it idle or using high cpu?
<azonenberg>
And yes, that's the idea
<pepijndevos>
idle. The play button is just stuck in highlighted mode
<azonenberg>
is the UI frozen and unresponsive? menus not working etc?
<azonenberg>
that sounds like a mutex deadlock perhaps, try attaching gdb and see
<azonenberg>
i've had a few of those in the past, i thought i got rid of them all but there might be a few still hiding
<pepijndevos>
I restarted and let's see...
<pepijndevos>
Can you just do some partial reconfiguration magic to insert arbitrary trigger logic?
<azonenberg>
PR is not really good for such fine grained stuff
<azonenberg>
you have to swap out fairly large chunks of the chip
<azonenberg>
What i'm thinking of doing instead is "poor man's PR" in which you string luts together in predefined patterns but reconfigure the lut truth tables dynamically
<pepijndevos>
your debug trace command just told me it made a connection and what the trigger source is, nothing else
<azonenberg>
this is portable, doesnt need any bitstream RE, and can be done with arbitrarily fine grained design
<azonenberg>
pepijndevos: if connecting over ethernet you want to trace SCPISocketTransport
<azonenberg>
not SCPITMCTransport
<pepijndevos>
looks fine to me, matches what i see on the display
<pepijndevos>
ill try gdb
<monochroma>
azonenberg: i would probably have a fairly simple generic trigger system that would work for a lot of simple things (basically, do what you can with without going way out of your way for the generic triggers) then have dedicated bitstreams for more complex dedicated triggers
<azonenberg>
monochroma: So my thought was a bit different
<azonenberg>
I want to have a bunch of pattern matching engines
<azonenberg>
and then some reconfigurable lut logic you can use to string them together
<azonenberg>
So for example there will be a couple of "serial capture" blocks that take in a channel for data and a channel for clock
<azonenberg>
and sample on rising/falling/both edges, your choice, of the clock
<azonenberg>
then output a parallel data block of up to N bits width (N fixed at bitstream synthesis time)
<pepijndevos>
yea, stuck in __lll_lock_wait
<azonenberg>
pepijndevos: check other threads
<azonenberg>
and get backtraces
<azonenberg>
open a bug report with as much info as you can get
<pepijndevos>
tbh not sure how to do that
<azonenberg>
"info threads" and "thread N" to jump from one thread to another
<azonenberg>
"bt" to get a backtrace
<pepijndevos>
yea, just never done any multithreding in gdb, i'll have a look
<azonenberg>
monochroma: then there will be a bunch of comparators that can take in either the output of a serdes block or a bunch of parallel digital channels and return a match/no-match result against an arbitrary value and bitmask
<azonenberg>
then a state machine block that has a table of transitions based on current state, output of comparators, etc
<azonenberg>
kind of a greenpak-y architecture
<azonenberg>
So for example you could set up an 8-bit serial block to have pod3 channel 2 as data and pod3 channel 3 as clock, looking at a SPI bus
<azonenberg>
reset by pod3 channel 4 falling edge
<azonenberg>
then this will give you a byte of spi data each time a byte is sent
<azonenberg>
You then feed that byte output into a comparator looking for the value 03, and another looking for the value 00
<azonenberg>
Then set up a state machine reset by falling edge pod3 ch4, advancing to state 1 when the 03 match is hit, advancing to state 2-3-4 when the 00 match is hit, then triggering in state 4
<azonenberg>
now you have a trigger for "spi flash read address 0x000000"
<azonenberg>
There will also be support for arbitrary LUT logic to do boolean condition searches etc
<_whitenotifier-b>
[scopehal-apps] pepijndevos opened issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJnRZ
<pepijndevos>
gdb'ing done
<pepijndevos>
seems to be stuck on the lock_guard in rigolscope,cpp
<azonenberg>
yeah what's important is the backtraces of who holds that mutex and why they're waiting for each other
<azonenberg>
let me see
<azonenberg>
pepijndevos: so it's blocking on the lock in Start()
<azonenberg>
what about the other threads though?
<azonenberg>
ah ok i see
<pepijndevos>
c++ noob question: how is it unlocked? when that lock_guard goes out of scope?
<azonenberg>
Yes
<azonenberg>
So the problem is, AcquireData() is holding the mutex in ScopeThread
<azonenberg>
Which means Start() in the UI thread is unable to get it
<azonenberg>
The question then becomes, why is AcquireData() not returning in a sane amount of time
<pepijndevos>
that would make sense if aquiredata... right
<pepijndevos>
so still rigol driver bug after all I guess?
<azonenberg>
Everything points to that, yes
<azonenberg>
See if you can do a bit more digging. try using shorter memory depths etc
<azonenberg>
different sample rates
<azonenberg>
try and narrow down the conditions causing it
<azonenberg>
also poke Degi, she's the current maintainer for the Rigol driver
<pepijndevos>
I changed the memory depth to 1k, and it actually works kinda okay, just slow as molasses
<azonenberg>
yeah the rigol driver is likely not nearly as optimized as it could be. and rigol hardware is slow in general
<azonenberg>
But that suggests that the bug is related to deep memory
<pepijndevos>
So... it's not a bug it's a feature?
<azonenberg>
try and bound the depths at which it does/doesnt work and add that to the issue
<azonenberg>
Well there's two unrelated issues
<azonenberg>
first, AcquireData hanging
<azonenberg>
second, the rigol driver being slo
<azonenberg>
slow*
<azonenberg>
We're focusing on the first
<pepijndevos>
I mean... if it takes a second to load 1k, imagine how long 40Mpts is going to be.
<azonenberg>
Hmmm
<azonenberg>
It is possible that it's actually stupidly slow and not hanging
<pepijndevos>
I'd say probably it wasn't even actually frozen just unreasonably slow
<azonenberg>
just for kicks, try opening wireshark and capture with the 40M point memory
<azonenberg>
See if you keep seeing network activity
<azonenberg>
if you do, then it's probably not hanging
<azonenberg>
At which point we can pivot the issue to "rigol driver is slow, can we make it faster?"
<azonenberg>
This may just be an inherent limit of the Rigol firmware, who knows
<pepijndevos>
fwiw, I tried their own software, and tbh it kinda looks like this: 1sec updates at low sample depth
<pepijndevos>
Only difference is in their case the scope still runs at full speed and bit depth
<azonenberg>
It's likely not pulling the full waveform
<azonenberg>
It's entirely possible rigol just sucks this bad :p
<pepijndevos>
:((((
<azonenberg>
You see why i'm designing custom hardware now?
<pepijndevos>
gigabit ethernet with 1kbps data
<azonenberg>
a lot of current scopes are just terrible for remote operation
<pepijndevos>
lol
<azonenberg>
they're software limited
<azonenberg>
my lecroy with a five digit price tag can hit a few hundred Mbps but not get close to saturating gig IME
<pepijndevos>
installing wireshark...
<pepijndevos>
always such a pita to set up in the past...
<azonenberg>
monochroma: ok first crack at a serial oversampling core is failing timing
<pepijndevos>
in general the delay between me pressing anything and anything getting sent is several seconds it seems
<azonenberg>
What's probably happening is that AcquireData() takes forever and it's hung up in there
<azonenberg>
and the UI can't do anything until it gets the mutex to send
<pepijndevos>
uh... does it make sens that if I press get configuration, it oly starts doing that when I hover over the play button?
<azonenberg>
Hovering shouldn't trigger any updates
<azonenberg>
"refresh config" in fact only clears the cache
<azonenberg>
pulilng config from the scope happens on the next UI update iirc
<pepijndevos>
Right so if no updates happen until I hover over some buttons...
<azonenberg>
hmmmm prety sure i trigger an update regardless
<pepijndevos>
also it *specifically* the play button
<azonenberg>
that is really weird
<azonenberg>
i dont have any event handling for hovering on buttons
<pepijndevos>
I can make a screencap if you want haha
<azonenberg>
monochroma: It works now, i'm using a one-hot counter instead of a true counter
<azonenberg>
need to actually simulate it, but at least it meets timing :p
<pepijndevos>
it's at 10MSa that it stops working.
<pepijndevos>
No data is being transmitted at all
<pepijndevos>
it worked for a few cycles
<pepijndevos>
I'll add that to the issue
<_whitenotifier-b>
[scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJnE2
<_whitenotifier-b>
[scopehal-apps] pepijndevos edited a comment on issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJnE2
<azonenberg>
That is definitely a driver and/or firmware bug then, if it's not sending anything
<_whitenotifier-b>
[starshipraider] 5l1v3r1 forked the repository - https://git.io/JvVvX
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+4/-0/±8] https://git.io/JJnoq
<_whitenotifier-b>
[starshipraider] azonenberg 7487d39 - Continued initial HDL work for MAXWELL
juli964 has joined #scopehal
bluezinc has joined #scopehal
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JJn11
<_whitenotifier-b>
[starshipraider] azonenberg 7d43bce - Continued initial HDL work on MAXWELL. Set up preliminary timing constraints, two trigger deserialization blocks not going anywhere yet.