azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
Bird|otherbox has joined #scopehal
Bird|ghosted has quit [Read error: Connection reset by peer]
Bird|ghosted has joined #scopehal
Bird|otherbox has quit [Remote host closed the connection]
juli964 has quit [Quit: Nettalk6 -]
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
katharina has joined #scopehal
<katharina> This WinAPI structure definitely is a hellspawn:
<azonenberg> lol
<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]
<_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 -
<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 -
<_whitenotifier-b> [scopehal-apps] pepijndevos edited a comment on issue #146: glscopeclient hangs on Rigol MSO5000 -
<azonenberg> That is definitely a driver and/or firmware bug then, if it's not sending anything
<_whitenotifier-b> [starshipraider] 5l1v3r1 forked the repository -
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+4/-0/±8]
<_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]
<_whitenotifier-b> [starshipraider] azonenberg 7d43bce - Continued initial HDL work on MAXWELL. Set up preliminary timing constraints, two trigger deserialization blocks not going anywhere yet.
<azonenberg> this is with pins color coded by functional group (pink = ram, yellow = probes, green = 1G eth, orange = everything else)
<azonenberg> serdes not hooked up yet, just 1g ethernet
<azonenberg> Making MAXWELL trigger off the 10Gbit signals will be challenging
<azonenberg> The initial trigger engine i think is going to work on the 92 channels only