azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
<azonenberg> adamgreig: oooh
<azonenberg> i'll have to try that, that was a big issue in the past
<azonenberg> lain: i would have to disagree in the more commonly used sense. But yes, flat is justice when it comes to probe frequency response :p
<lain> :3
<azonenberg> Just found/fixed a read-off-end-of-buffer bug in the CDR PLL
<azonenberg> (thanks asan)
<_whitenotifier-3> [scopehal-apps] azonenberg opened issue #55: FFT frequency display in timeline is incorrect for frequencies beyond 1 GHz - https://git.io/Jv4hG
<_whitenotifier-3> [scopehal-apps] azonenberg labeled issue #55: FFT frequency display in timeline is incorrect for frequencies beyond 1 GHz - https://git.io/Jv4hG
<_whitenotifier-3> [scopehal-apps] azonenberg labeled issue #55: FFT frequency display in timeline is incorrect for frequencies beyond 1 GHz - https://git.io/Jv4hG
<azonenberg> So, some bandwidth comparisons
<azonenberg> same signal on a HDMI test board measured with both a lecroy 1.5 GHz active probe and the transmission line probe on the test fixture. Eye is actually a bit more open with the lecroy probe, but the fixture's integrated probe produces much sharper edges so it obviously has higher bandwidth (you can see this in the FFT too)
<azonenberg> next step is to compare my transmission line probe on the same signal
<azonenberg> note, this is with the version of the fixture that has the giant pogopin proboscis on the front
<azonenberg> i'm hopeful some of these issues are that unterminated stub and using a more sane-length probe tip will fix is
<azonenberg> right now reflections off the tip are bad enough that the instant i touch the probe to a dut, the hdmi sink loses signal :p
<lain> lol
<azonenberg> well i assume it;s reflections
<azonenberg> i dont want to use this tip long term anyway because the torque on the solder joint is extreme
<azonenberg> even with glue i dont fully trust it
<azonenberg> But it was a good PoC, next step is to play around with different tips and try to improve things
<azonenberg> as well as some with and without the bodged on 50R terminator after the attenuator
futarisIRCcloud has quit [Ping timeout: 248 seconds]
futarisIRCcloud has joined #scopehal
m4ssi has joined #scopehal
maartenBE has quit [Ping timeout: 265 seconds]
maartenBE has joined #scopehal
apo has joined #scopehal
<apo> \o
<azonenberg> o/ apo
<apo> needs more docs =P
<apo> ah
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 1 commit to master [+13/-0/±1] https://git.io/JvBsw
<azonenberg> That's for the client software
<apo> this seems to be realtime stuff?
<_whitenotifier-3> [scopehal-docs] azonenberg 9208267 - Added lots more screenshots and writeups for various UI elements
<azonenberg> the library itself has decent doxygen coverage but no formal manual with high level introductory material etc right now
<azonenberg> yes, this is intended for realtime acqusitions, control, analysis, etc
<apo> yeah, not really the scope of what I did
<azonenberg> Importing savefiles from scopes is certainly of interest though
<apo> although I got the sigrok people to implement support for the ds4k series
<azonenberg> i have no file load/save support now but plan to support both saving sessions to disk, and importing single waveforms from CSV and vendor file formats
<apo> *nod*
<azonenberg> Eventually i want to enable fully headless scopes with no front panel controls at all, just SMAs and an ethernet port. Right now i still rely on front panel controls for some stuff like configuring timebase
<azonenberg> that i haven't implemented UI for
<azonenberg> (if you're interested in the tool, even if it's not a great fit for your project in particular... i'd love better testing and support for rigol gear
<azonenberg> )
<apo> oh, that was no project
<apo> that was just me trying to get proper tooling for my tools =P
<azonenberg> Lol i see
* apo , professional yak barber and knight who says NIH
<azonenberg> Well, scopehal provides a C++ API for a lot of test equipment in a much lighter and less awful format than stuff like VISA
<azonenberg> and permissively licensed unlike sigrok
<azonenberg> so compatible with non-GPL stacks
<apo> I'll prod it later today :)
<azonenberg> (btw that manual link is a periodically uploaded LaTeX render of the scopehal-docs repo for conveneince. The repo is the authoritative source for documentation)
<apo> *nod*
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvBGU
<_whitenotifier-3> [scopehal-docs] azonenberg 096f7b8 - Finished initial writeup for history window
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvBG3
<_whitenotifier-3> [scopehal-docs] azonenberg ff9bceb - Fixed a few typos
<apo> azonenberg: do you have a clang-format or something so I don't have to worry about formatting when I work on your code? =P
<azonenberg> apo: roughly speaking i use visual studio style since that's what I learned C++ on. One \t = four columns of indenting, curly braces on their own line, camel case identifier names
<azonenberg> I use m_ prefix on class members to avoid confusion with constructor arguments or local variables but no hungarian otherwise
<azonenberg> oh and g_ on the very few globals
<azonenberg> pretty sure astyle can be configured to do this format, it's likely a preset
<azonenberg> oh also unix line endings and no whitespace or indentation on blank lines
<azonenberg> doxygen comments on all functions, i'm not at 100% coverage on all of the driver code etc yet but most of the critical APIs and base classes are pretty well documented
<azonenberg> The project is split across a few repos for historical reasons as with most of my ex-antikernel code: -cmake is the build system, -docs is documentation, -apps is client utilities and UI stuff, then scopehal itself is the core libraries
<azonenberg> The github trackers are chock full of TODO items if you're looking for somewhere to get started
<azonenberg> this channels is the primary coordination/discussion for the project
<apo> *nod*
<azonenberg> oh and when using a prefix, no cap on the initial camel
<azonenberg> so Baz::m_fooBar
<azonenberg> but OscilloscopeChannel has both capitalized
<azonenberg> At some point i should write up a formal coding style document for my projects, both C++ and SystemVerilog, but i've been too busy writing code to write how-to-write-code :p
<azonenberg> now that i'm starting to get some users for the project i'm working on at least getting end user documentation going
<apo> "Receives" =P
<azonenberg> Submit a PR :p
<apo> https://github.com/azonenberg/xptools/blob/d296dafb976b26c212c31b023fa8199be541349c/Socket.cpp#L304 would replace this with bytes_left > 0, so a call with len==0 would still work
<apo> can't atm
<azonenberg> well i'm about to leave for $dayjob and this isn't a huge priority. So whenever you get to it
<azonenberg> Anyway docs are my priority for the next couple days. Once the manual is usable and only missing detailed docs on specific filters/decodes, i'll move back to code. Still a bunch of baseline features left to implement
<azonenberg> the most notable is that double clicking the X axis timeline to open the timebase properties dialog, which will let you configure memory depth and sample rate, is not implemented and many of the APIs for doing this don't even exist yet in the Oscilloscope class
<azonenberg> (this is less trivial than you'd think, because of interleaving conflicts between channels meaning the set of legal sample rates varies depending on what channels are turned on)
<azonenberg> And creating a standardized way of representing this across hardware is nontrivial
<azonenberg> e.g. some rigols have different sample rate sets for 1/2/4 channels enabled, some lecroys let you interleave any of 1/2 with 3/4, others only let you do 2/3
<azonenberg> to say nothing of some of the HMCAD1520 family ADCs where you can trade sample rate off against bit depth
<miek> some notes on how to write a good driver would be really handy for me, like what's expected for timings / can i block at all / etc. i've been struggling a bit to make my driver run well
<azonenberg> So designing an API to represent all of these possibilities isn't easy
<azonenberg> miek: Some of that is still in flux as i'm figuring that out myself
<azonenberg> Right now i assume downloading a waveform is a blocking operation so i do that in a separate thread
<azonenberg> but some menus and such query settings from the scope, which leads to freezes on high latency connections or during download of deep captures
<azonenberg> multiple sockets to the scope normally doesnt work as a lot of the firmware is single threaded
<azonenberg> So i cant have one thread asking for the vertical gain on channel 2 while another is pulling waveform data
<azonenberg> one possibility is to use commands for "download part of a waveform" on deep acquisitions, and free/re-acquire the mutex periodically during that
<azonenberg> so that there's time for the UI to get in edgewise between blocks of samples
<azonenberg> But this is not as well developed as I'd like. Better performance on slow scopes, or scopes accessed via VPN/WAN, is a priority but i havent had time to work on it much
<miek> ahh that makes sense, that's probably at least part of my problem
<azonenberg> When i build a scope myself it will have separate socket servers for streaming waveform data and control plane traffic
<azonenberg> precisely to avoid this problem
<azonenberg> it will also have massive hardware fifos - like 1-2 sodimms of ddr3 per adc - so you can atomically read data and settings from one acquisition *while* another trigger is running into another portion of memory
<azonenberg> then pop the entire capture en masse once you've downloaded everything of interest
<azonenberg> oh also scopehal also aggressively cache settings from the scope so as to avoid a round trip every time you right click etc
<azonenberg> look at the lecroy driver for examples of this
<azonenberg> if you don't make use of the caching, that will definitely slow down the ui a lot
<azonenberg> The downside of this is front panel changes may not be reflected in the UI for several seconds or until you hit the refresh button
<azonenberg> but it beats constant polling as there's no support for push notifications in most of the scpi protocols
<miek> azonenberg: also, on a complete tangent, i wonder whether a few of these would go well with your HDMI fixture, for differential conversion: https://www.ti.com/tool/LMH3401EVM
<azonenberg> I actually am already looking at that for building active differential probes
<miek> ah cool :)
<azonenberg> as well as possibly the front end buffer and gain block for my homebrew scope
<azonenberg> Details TBD. First priority right now is getting the low-Z probes to work well
<azonenberg> That is using a ground lead from a LeCroy ZS1500 and a pogo pin tip from a Pico TA061. Going to experiment with some different tip designs etc moving forward
<azonenberg> I'm still getting not-great eye quality with this probe and not yet sure why
<azonenberg> see bottom waveform
<azonenberg> https://www.antikernel.net/temp/fixture-vs-zs1500.png compared to a lecroy active probe
<azonenberg> top waveform is the test fixture output after probe loading
<azonenberg> i mean dont get me wrong, the output of my probe is totally good enough for data recovery of gigabit serial signals. But it actually messes up the signal enough the DUT loses lock on the signal :p
<azonenberg> i think it might be reflections of the long pogopin tip but not sure
<azonenberg> Going to experiment more with it tonight after i get home from work
<azonenberg> i have some other tips i want to play with including just phosphor bronze wire
<azonenberg> as well as comparing waveforms with and without the source side 50R terminator to ground
alexhw_ has joined #scopehal
alexhw has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
maartenBE has quit [Ping timeout: 258 seconds]
maartenBE has joined #scopehal
m4ssi has quit [Ping timeout: 248 seconds]
m4ssi has joined #scopehal
m4ssi has quit [Ping timeout: 255 seconds]
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
azonenberg_work has joined #scopehal
m4ssi has joined #scopehal
m4ssi has quit [Client Quit]
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]