azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
jevinskie[m] has joined #scopehal
juli966 has quit [Quit: Nettalk6 -]
<_whitenotifier> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+1/-0/±5]
<_whitenotifier> [scopehal-pico-bridge] azonenberg 6e6f13b - Initial "first light" build of ps6000d
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+2/-0/±5]
<_whitenotifier> [scopehal] azonenberg 9f23b9b - Initial "first light" implementation of PicoOscilloscope
<azonenberg> It's alive!
<monochroma> :D
<azonenberg> Triggers don't work yet (right now it's doing nonstop auto capture), memory depth is hardcoded to 100K samples, single-shot trigger doesn't work, you can't change sample rate, etc
<azonenberg> But the basic infrastructure is there via the dual socket bridge
<azonenberg> Which can *easily* saturate gig-e
<azonenberg> It's *fast* too
<azonenberg> over 1GbE I'm getting 88 WFM/s on eight channels with 100K points
<monochroma> :o
<azonenberg> 7.7 WFM/s with 1M points * 8 channels
<azonenberg> Doing the math for 16-bit native samples (adc resolution ranges from 8 to 12 bits depending on config but samples are always output from the API as int16s)
<azonenberg> 8M points per trigger * 7.7 WFM/s * 16 bits = 985.6 Mbps
<azonenberg> so basically it's bottlenecked on the saturated gig-e pipe
<azonenberg> and could probably run 3-5x faster over 10GbE
<azonenberg> With only one channel active, I get 70+ WFM/s at 1M points per channel
<azonenberg> this is throughput i could never dream of getting on my lecroys
<azonenberg> and i'm not even using its full potential yet, it's bottlenecked by the gig-e
<monochroma> which model is this again?
<monochroma> ah 6000?
<azonenberg> 6824E
<azonenberg> is the actual SKU
<azonenberg> basically their current flagship model. Eight analog channels, 500 MHz BW
<azonenberg> Split into two banks, each bank has a 4-lane 1.25 Gsps ADC that can interleave 2/4 ways
<azonenberg> so you can get up to 5 Gsps
<azonenberg> As of now, banks do not support separate config so you can't have four 1.25 Gsps channels and one 5 Gsps channel, but it sounds like the hardware is capable of it
<azonenberg> so that might come in a future firmware
<monochroma> oh for some reason i thought this had native ethernet on it
<azonenberg> no this is usb3
<azonenberg> i wrote a bridge to scpi + binary waveform socket, basically the same interface i'm planning for my instruments to have natively
<azonenberg> 54 WFM/s with one channel at 1M points doing a live GPU accelerated FFT + waterfall
<azonenberg> notbad.jpg
<azonenberg> only using 18% of my GPU too, i wonder why it's not faster... setup overhead? cpu processing?
<azonenberg> Might have to look at that
<azonenberg> Looks like I get ~16 WFM/s using the same bridge etc but running on localhost
<azonenberg> actually no it's closer to 20 WFM/s
maartenBE has quit [Ping timeout: 240 seconds]
maartenBE has joined #scopehal
<d1b2> <Darius> you might want to look at PMC stats for it
<azonenberg> PMC?
<azonenberg> assuming that's not "private military contractor" :p
<kc8apf> guessing performance monitor counters
<azonenberg> oh
<azonenberg> yeah i havent done any profiling or optimization whatsoever yet
<azonenberg> i only got it to work at all a few hours ago
<azonenberg> i'll focus on making it feature complete, then work on the known optimizations like the excessive memory allocation/deallocation every waveform
<azonenberg> and only then think about the trickier stuff
<d1b2> <Darius> yeah performance monitoring counters
<d1b2> <Darius> for high performance stuff like you are doing, percentage of CPU in top is not very helpful in finding bottlenecks because modern computers are insanely complicated
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<kc8apf> <-- wrote performance analysis tools for a decade
<d1b2> <Darius> ooh you sound handy 😉
massi has joined #scopehal
<azonenberg> darius: yeah I make heavy use of VTune when actually optimizing stuff
massi_ has joined #scopehal
massi has quit [Ping timeout: 256 seconds]
massi_ has quit [Quit: Leaving]
massi has joined #scopehal
massi has quit [Remote host closed the connection]
massi has joined #scopehal
<azonenberg> So i just heard back from ADI support regarding the ADL5580
<azonenberg> Bad, but not entirely unsurprising, news
<azonenberg> It sounds like the part was designed for R&S who were primarily using it with a mixer at the input (so guessing specans?) and wanted a fairly high common mode at the input
<azonenberg> the output has a lower common mode for interop with ADCs
<azonenberg> The internal Vcm generator has low resolution and high PTV variation since it's primarily intended to have Vcm supplied by the devices it's interfacing with
<azonenberg> so basically, there's zero chance of using it dc coupled with ground as Vcm
<azonenberg> and i will need to use the diplexer system we discussed with a separate amp for the DC path
<miek> is the lmh3401 still an option?
<azonenberg> miek: I'm using the 6401 in my current prototype
<azonenberg> (at fab now)
<azonenberg> which seems to have better performance
<azonenberg> but i want to push higher
<azonenberg> the 3/5401 seem to top out around 2 GHz of usable BW
<azonenberg> at least one of them is labeled 7 GHz but that's actually GBP
<azonenberg> which is quite misleading
<azonenberg> maybe it can do 7 GHz BW at unity gain :p
<miek> the 3401 is claiming flat frequency response out to about 5GHz with 12dB gain
<azonenberg> that's not what their S-parameters say
<azonenberg> i wouldn't call that flat or even close to flat
<azonenberg> it's below unity gain until 2 GHz
<azonenberg> This characterization data is from a random TI guy on a forum, not on the product page, so i dont know how much to trust. Claims it was measured during silicon bringup across the EVM iirc
<azonenberg> random TI FAE*
<azonenberg> But it's ugly enough looking data i'm not considering the part at this time
massi has quit [Quit: Leaving]
massi has joined #scopehal
massi_ has joined #scopehal
massi has quit [Ping timeout: 256 seconds]
massi_ has quit [Remote host closed the connection]
<_whitenotifier> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier> [scopehal-pico-bridge] azonenberg 9296b8e - Implemented single-shot trigger and setting of timebase. No validity checking for what sample rates are legal under a given channel configuration.
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier> [scopehal] azonenberg 02ea3d6 - PicoOscilloscope: initial support for sample interval control
juli966 has joined #scopehal
<azonenberg> Final (hopefully) 3D printed AKL-PT2 mold received
<azonenberg> Still waiting on the production PCBs
<_whitenotifier> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier> [scopehal-pico-bridge] azonenberg d3df0cc - Initial sample depth control
<_whitenotifier> [scopehal] azonenberg assigned issue #15: Add Picoscope scope driver(s) -
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier> [scopehal] azonenberg 6b96287 - Initial sample depth control in PicoOscilloscope. See #15.
<azonenberg> grrr seems like the sample rate on this picoscope is just not *quite* enough to decode the raspberry pi's mipi interface
<azonenberg> I'm getting occasional valid looking packets and lots of bad ones
vup has quit [Remote host closed the connection]
vup has joined #scopehal
esden has quit [Ping timeout: 272 seconds]
elms_ has joined #scopehal
esden has joined #scopehal
elms has quit [Ping timeout: 272 seconds]
elms_ is now known as elms
<azonenberg> maybe i just needed to use a diff probe or something, single ended might not have been enough. because 1.25 Gbps 8b10b actually works
<azonenberg> obviously the real signal has much sharper risetimes, i'm limited by the scope
<azonenberg> But the data is readable which is nice
<azonenberg> Need to find some more "kinda fast" signal sources for testing, have to think of something good. maybe usb2