azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | Online hackathon December 19th all day | | Logs:
<_whitenotifier> [scopehal-apps] azonenberg opened issue #301: Preference file loading fails on locales that use commas as decimal separator -
<_whitenotifier> [scopehal-apps] azonenberg assigned issue #301: Preference file loading fails on locales that use commas as decimal separator -
<_whitenotifier> [scopehal-apps] azonenberg labeled issue #301: Preference file loading fails on locales that use commas as decimal separator -
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 260 seconds]
bvernoux has joined #scopehal
bvernoux1 has quit [Ping timeout: 246 seconds]
bvernoux1 has joined #scopehal
bvernoux1 has quit [Read error: Connection reset by peer]
bvernoux has quit [Ping timeout: 246 seconds]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
<azonenberg> Not bad at all
<azonenberg> There's a huge notch in the response just before 6 GHz, reason unknown
<azonenberg> but it's a reasonably smooth response out to ~5.5 GHz, with -3 dB rolloff at around 4.5 GHz
<azonenberg> No silicone encapsulation yet. and loss tangent may change when i move to a coverlay process vs soldermask
<azonenberg> but at this point i'm fairly happy with it
<azonenberg> also just found a cracked ground connection
<azonenberg> gonna remeasrue and see if that was the cause of the notch
nelgau has quit [Remote host closed the connection]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 240 seconds]
<azonenberg> S11 and input impedance are beautiful
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 272 seconds]
<azonenberg> lain, monochroma, kc8apf, Kliment: Characterization data dump incoming
<azonenberg> This is the latest solder-in probe prototype
<azonenberg> Rising edge response to a 40ps pulse through LeCroy PCF200 test fixture and FL086-24SM+ cable. Neither de-embedded, actual risetime of naked probe is likely quite a bit faster
<azonenberg> S21 soldered to oshpark test board, pcb and cable de-embedded
<azonenberg> this is across 50 ohm load
<azonenberg> s11 across open circuit
<azonenberg> input impedance across open circuit
<lain> :D
vitalmixofnutrie has joined #scopehal
<agg> azonenberg: fyi, i upgraded ubuntu from 18.04 to 20.04 and now not only does glvnd work fine, I also now have the GL_ARB_gpu_shader_int64 extension available, go figure
<agg> I suspect "driver woes"
<azonenberg> Welp, lol
<azonenberg> Probing PCIe on raspberry pi 4 with LeCroy D420A active diff probe ($CALL_FOR_PRICE new, I got mine for a touch under $3K refurb so I suspect around $5K new) and prototype AKL-PT2
<azonenberg> active probe at top, AKL-PT2 at bottom
<azonenberg> it's definitely not *quite* as pretty, but the eye is wide open. And the AKL-PT2 will sell for somewhere in the high tens to very low hundreds of dollars
<azonenberg> I'm also curious how much i could clean it up by putting a second AKL-PT2 on and subtracting them in post
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
vitalmixofnutrie has quit [Ping timeout: 240 seconds]
<azonenberg> lain: Thoughts?
<azonenberg> box is 1cm square, for reference
<azonenberg> The diameter of the clip is slightly smaller than the silicone overmold, the intent is that it will slightly squeeze the probe and excess silicone will smoosh out around the ends
<azonenberg> providing a firm grip and lots of friction to keep it from slipping around
<azonenberg> This is to be printed in SLS nylon
<lain> seems fine
<azonenberg> Just ordered two of them to see
<azonenberg> expecting them plus the new overmold shortly before xmas
<azonenberg> the harder silicone shipped as well and is ETA Friday
<azonenberg> so i will probably do a test cast in the old mold just to see how it feels
bvernoux has joined #scopehal
<bvernoux> I recommend everyone to buy this amazing FPGA board
<bvernoux> On my side I will take the big version with LFE5UM5G-85F
<bvernoux> it is clearly an amazing board to do tons of things
<azonenberg> bvernoux: did you see my tweets with the AKL-PT2 characterization from earlier today?
<azonenberg> 4 GHz bandwidth, a few ripples but not too bad
<azonenberg> 88ps 20-80, 129 10-90 including cable and fixture
<azonenberg> and the S11 is just amazing
<_whitenotifier> [starshipraider] azonenberg pushed 1 commit to master [+1/-0/±1]
<_whitenotifier> [starshipraider] azonenberg b3d9086 - Initial version of AKL-PT2 bracket
<bvernoux> azonenberg, yes very nice results !!
<bvernoux> azonenberg, I'm impatient to see finale probes
<azonenberg> Electrically, it's done
<azonenberg> The only thing left is mechanical
<azonenberg> i need to fine tune the size and placement of stiffeners and get the overmolding figured out
<azonenberg> then order final pcbs etc
<bvernoux> clearly amazing up to 4GHz
<bvernoux> do you have checked the limit ?
<bvernoux> I could test them with ECPIX-5 5G serdes ;)
<bvernoux> and my SA ;)
<azonenberg> The -3 dB b/w is roughly 4 GHz, i believe primarily due to dielectric losses in the polyimide and soldermask
<bvernoux> not with my scope as it is limited to about 500MHz BW ;)
<bvernoux> anyway for a passive prove so low cost it is already an amazing result to reach 4GHz
<azonenberg> Yes exactly
<bvernoux> compared to those crazy expensive diff probe which are just a bit better
<azonenberg> I'm not aiming to be directly competitive with $5K active probes
<azonenberg> I'm aiming to be 90% as good for 5% of the proce
<azonenberg> price*
<bvernoux> yes but it is competitive when we check the price ;)
<azonenberg> Anyway the only way i can get lower loss is by either shortening it (not happening) or switching to air dielectric + not-ENIG plating
<azonenberg> which is doable in something like the AKL-PT1 that has a hollow plastic enclosure
<azonenberg> but with an overmolded rubber shell it's less feasible
<bvernoux> also maybe to produce shorter flex PCB
<azonenberg> i'd need to figure out some way of making an air gap which i can fill the mold cavity with, then remove
<bvernoux> as they seems very long
<bvernoux> maybe 2 version will be perfect
<azonenberg> For my use case this length is about right
<bvernoux> one shorter and the one you have used in proto
<azonenberg> it's actually very close to the lecroy Dx20 series solder-in tip length
<azonenberg> mine is maybe a cm shorter?
<bvernoux> yes for big board to analyze it is convenient to have the long version
<azonenberg> I might make a shorter version. I also intend to make left and right handed variants
<azonenberg> swapping signal and ground conductors at the top
<azonenberg> tip*
<azonenberg> so you can use whichever is more convenient for your pcb layout
<bvernoux> on the photo
<bvernoux> we see for such type of board the flex PCB could be maybe 4cm shorter and it will be fine
<bvernoux> with less loss ;)
<azonenberg> Yes. I will likely make several versions of it
<azonenberg> but i want to get one ready to ship first
<azonenberg> Then i can easily make variants
<bvernoux> yes
<bvernoux> especially with the mold
<bvernoux> to protect the flex PCB as it is quite fragile
<bvernoux> I see you still need to find the good material for the flex PCB
<azonenberg> Well i need to actually go to a real fab
<azonenberg> this is a prototype at oshpark
<bvernoux> you will have probably different loss too with other fab
<bvernoux> especially for flex PCB
<bvernoux> I do not know what is the variation of the loss on such material
<azonenberg> I plan to spec this same Panasonic substrate at Multech for the production boards
<azonenberg> because i've already characterized it
<azonenberg> Felios F775
<bvernoux> ha yes great
<azonenberg> But swap out the LPI soldermask for coverlay
<azonenberg> i will also be adding a small FR4 stiffener under the SMA connector, and either a FR4 or polyimide stiffener under the resistors to keep the solder joints there from cracking
<azonenberg> The timeline right now is
<azonenberg> 1) New, harder silicone rubber (Shore A25, vs current A8, hardness) arrives Friday
<azonenberg> So i can test how that feels in my current mold
<azonenberg> 2) Prototype mounting clip and v2 enclosure mold arrive shortly before Christmas. If it fits, I should be able to try casting an oshpark prototype PCB into it
<azonenberg> 3) If those tests work well, order final PCB revision from Multech, expected arrival some time mid to late January
<azonenberg> 4) Design final enclosure mold to fit production PCB, 3D print prototype mold in plastic
<azonenberg> 5) Once final enclosure is confirmed to fit production PCB, order multi-cavity batch production mold out of CNC'd aluminum
<azonenberg> 3 and 4 can overlap, 5 cannot happen until final PCB and prototype mold have been fit-tested
<azonenberg> Once I get the final mold and have all the PCBs, i can start offering them for sale to the general public
juli966 has joined #scopehal
<bvernoux> yes very nice time line
<bvernoux> I plan to work on glscopeclient stuff in christmas
<bvernoux> but I must finish my secret project with big NFC antenna first ;)
<azonenberg> So prob feb-march i will actually be ready to start offering for sale
<azonenberg> and are you gonna be joining noopwafel and the other guy to work on the picoscope drivers next weekend?
<bvernoux> yes picoscope is clearly a must have especially it shall have lot of WFM/s
<bvernoux> maybe better than Lecroy & Tek ;)
<_whitenotifier> [scopehal-apps] pd0wm commented on issue #300: December 19th hackathon meta-issue -
<_whitenotifier> [scopehal-apps] pd0wm edited a comment on issue #300: December 19th hackathon meta-issue -
<bvernoux> so I plan to work on that next weekend if noopwafel release the beta socket/usb wrapper
<bvernoux> for pico3000 series
<bvernoux> I cannot test other picoscope as I have only have the PicoSCope 3046DMSO
<bvernoux> 3406DMSO
<bvernoux> ok see you
bvernoux has quit [Quit: Leaving]
<_whitenotifier> [scopehal-apps] azonenberg commented on issue #300: December 19th hackathon meta-issue -
<_whitenotifier> [scopehal-apps] azonenberg commented on issue #300: December 19th hackathon meta-issue -
<_whitenotifier> [scopehal-apps] azonenberg edited a comment on issue #300: December 19th hackathon meta-issue -
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier> [scopehal-apps] azonenberg da51f6c - FilterGraphEditorWidget: correctly refresh when we change stuff
pd0wm has joined #scopehal
<azonenberg> o/ pd0wm
<azonenberg> Great. So now you should be all good to go WRT adding checksum verification
<azonenberg> Let me know if you want test data for other protocols. I have, or can acquire, test waveforms for almost every currently implemented protocol and probably some we don't yet have
<azonenberg> I definitely have plenty of Ethernet waveforms if you want to add that checksum code too
<pd0wm> Thanks! Will let you know
<azonenberg> But start by just getting familiar with how glscopeclient works as a user, and learning your way around the codebase
<pd0wm> I'm mostly interested in automotive stuff, so might add flexray. But have some Saleae LA dumps from that myself.
<azonenberg> At a high level glscopeclient is primarily just GUI/rendering although some file I/O logic is there (will likely be refactored later)
<azonenberg> then libscopehal is primarily drivers and base classes for decodes, but no actual decode logic
<azonenberg> and libscopeprotocols is all the decodes
<azonenberg> All decodes inherit from Filter directly or indirectly
<pd0wm> Yeah, doing the CAN stuff was just an excuses to start using it. I've been following the progress on twitter for a while, and always wanted to try it
<azonenberg> some inherit from PacketDecoder which is a subclass of Filter that also provides a wireshark-esque protocol analyzer view
<azonenberg> And yes, FlexRay is a wishlist protocol but i don't have any waveforms for it handy
<azonenberg> CAN-FD would be nice too
<azonenberg> I just don't have any DUTs handy that use it
<azonenberg> I have partial FD code already to identify FD frames, but not fully parse them
<azonenberg> i couldn't go further without waveforms
<azonenberg> Also J1939 is a wishlist item, i forget if i filed a ticket for it or not
<azonenberg> I work in infosec and we occasionally get ECUs from heavy equipment in our lab. We have some fancy stuff from Vector et al as well, but being able to decode off a scope waveform is handy too sometimes
<pd0wm> I have some flexray dumps from an Audi Q8, but no can FD
<azonenberg> Yeah its not a near-term priority. Just something i figured i'd mention given you said you were interested in automotive
<pd0wm> I'll do regular can first :)
<azonenberg> I have a PCAN on loan from $dayjob. But it doesn't like sending into the void
<azonenberg> it needs something that can ACK
<azonenberg> otherwise it gets stuck in a transmit loop resending one frame over and over
<azonenberg> I have other plans for more advanced analytics on CAN stuff BTW
<azonenberg> Bus load measurements, converting sensor readings to analog waveforms, etc
<azonenberg> and of course symbolic decode of higher level protocols like J1939
<azonenberg> these would all be separate filters in the graph that take a decoded CAN data stream as input
<pd0wm> If you're thinking about stuff like that ISO-TP (ISO 15765-2) is also a must, it's the lower layer for a bunch of other protocols like UDS
<azonenberg> Is that a consumer vehicle protocol? I'm not familiar with it, most of what i've done has been on the big diesel side
<pd0wm> Yeah, that's used for all consumer diagnostics
<azonenberg> oh that's the OBDII protocol? yeah that would be good to have
<azonenberg> If you have suggestions on automotive protocols to implement, file wishlist tickets against scopehal and add the "decode" tag
<azonenberg> even if you don't have the time/interest/test data to work on, at least this way we have it on the tracker so somebody else can pick it up
<azonenberg> BTW glscopeclient has CSV import so you should be able to pull waveforms in from the saleae fairly easily. although i think right now we only have good analog import, i forget if i implemented CSV digital support
<azonenberg> or if it will parse as an analog signal jumping from 0V to 1V
<azonenberg> If that's missing it would be easy to add
<pd0wm> OBD and UDS are simmilar, but a different standard. OBD is mostly for emissions. UDS is used for things like tuning, reflashing ECUs, callinng debug functions (e.g. running a motor)
<azonenberg> We do not however have a hardware driver for the saleaes to do live control and waveform download. That is also an open wishlist ticket
<azonenberg> and ah, ok
<pd0wm> Is there any chance of getting a 10 year old Rigol DS 5062 to work? It has a USB port, but never looked into how much you can pull from that
<azonenberg> We have support for the ancient DS1000D/E series and the modern DS1000Z, as well as MSO5000
<azonenberg> Higher end DS series scopes have never been tested. They will likely be painfully slow to use due to the wimpy CPUs, but I see no reason why the driver couldn't gain support for them
<pd0wm> I'll see if I can get it to work. Otherwise I'll put a new Siglent on my wish list
<azonenberg> It will likely require some modifications to the driver, we have quirks coded in for different models
<azonenberg> The siglent driver actually needs a bit of TLC as well. It's based on the LeCroy driver because the two use similar command sets
<azonenberg> but we need to fork them off because recent changes to the LeCroy driver broke Siglent
<pd0wm> If I understand correctly we're just reading the waveform over SCPI over USB? And this is industry standard across all scopes with just some quirks in the command set?
<azonenberg> tom verbeuere told me he plans to work on that
<azonenberg> Yes and no
<azonenberg> Waveform download is done via SCPI over "whatever"
<azonenberg> We use the SCPITransport class to abstract away the details of how to move SCPI between PC and instrument
<azonenberg> so raw TCP socket, LXI VXI-11, RS232, USBTMC, and hypothetically GPIB (not currently supported) all are the same from the driver perspective
<azonenberg> SCPI is "standard" in about the same way as JTAG is
<azonenberg> there's a standard way to identify the instrument, and the syntax of what a query vs a write command look like is standard
<azonenberg> What commands are available (other than *IDN?) and what the commands do / what the return values look like is vendor and often model specific
<azonenberg> e.g. the command you send to download a waveform from the scope, as well as the over-the-wire format of the waveform data, is totally different from scope to scope
<pd0wm> ah, get it. Sounds like some fun reversing. Good holiday project
<azonenberg> It's usually documented in a programming manual
<azonenberg> Although there are often quirks and bugs to figure out
<azonenberg> Analog data is generally raw ADC samples padded to 8 or 16 bits, but sometimes it's IEEE754 fp32
<azonenberg> digital data can be... well, literally anything
<azonenberg> LeCroy's logic analyzer outputs samples as XML containing a <BinaryData> tag that contains, IIRC, base64 coded raw binary samples
<azonenberg> I wish i was kidding
<pd0wm> Great... Gotta use that space efficiently.
<pd0wm> Thanks for the intro. Will let you know if I have any questions!
<azonenberg> If you're interested in support for your 5062 file a ticket against libscopehal so we know it's an item of interest. You can look at the existing Rigol driver and try to find the programming manual on Rigol's website as a starting point
<azonenberg> I would suggest looking at the DS1000 code in RigolOscilloscope class. It's likely very similar to that
<azonenberg> might even work unmodified with just a change to the version detection code to use the DS_OLD protocol mode for DS5000
<_whitenotifier> [scopehal] pd0wm opened issue #384: Add Rigol DS5062 driver -
<_whitenotifier> [scopehal] pd0wm edited issue #384: Add Rigol DS5062 driver -
<pd0wm> There was already an issue for the flexray decode
<azonenberg> Yeah, nobody is working on it but i filed it a while ago. We do not have one for the ISO std you mentioned though
<azonenberg> i think there is one for J1939
<_whitenotifier> [scopehal] pd0wm opened issue #385: Add ISO-TP (ISO 15765-2) protocol support -
<_whitenotifier> [scopehal] pd0wm edited issue #385: Add ISO-TP (ISO 15765-2) protocol decode -
pd0wm has quit [Quit: Connection closed]
codysseus has quit [Read error: Connection reset by peer]
codysseus has joined #scopehal
<d1b2> <j4cbo> I saw your tweet from a few months ago looking for someone with a R&S scope - is there still work needed there?
codysseus has quit [Changing host]
codysseus has joined #scopehal
<codysseus> I am trying to use the demo driver, but glscopeclient says it is an invalid configuration. :/
<codysseus> Aha, if I start glscopeclient with an argument it starts up.
<codysseus> It doesn't work in the menu.
<codysseus> azonenberg_work: Loaded up a Low speed sample in glscopeclient and I am not seeing the issues I saw before. Interesting that you separate the SYNC field from the packet.
<codysseus> Found another issue about my sample. Channel0-Analog is D-, Channel1-Analog is D+
vitalmixofnutrie has joined #scopehal
<codysseus> And sorry for the delay, last week was Finals week.
<_whitenotifier> [scopehal] Codysseus commented on issue #361: USB Decoder does not function correctly. -
<azonenberg> j4cbo: yes
<azonenberg> the R&S driver definitely needs testing and dev
<azonenberg> codysseus: no worries
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier> [scopehal-apps] azonenberg 83bd56d - Fixed bug causing InstrumentConnectionDialog to refuse attempts to select "demo" driver
<azonenberg> codysseus: also, just fixed the invalid config bug
<azonenberg> As far as the channel overlap bug, i'll take another look shortly. Can you send me the exact file you had the issue with?
<codysseus> So both files in question are in the github issue.
<codysseus> Thank you for fixing that issue!
<azonenberg> ah ok same one you had before
<azonenberg> I'll poke at it later
<codysseus> No problem! :)
<azonenberg> codysseus: incidentally, this is one of the reasons why CSV column headers and glscopeclient channel names are nice
<azonenberg> I always like to assign names to my signals as early in the chain as possible so that i don't lose track of what's what later on doing offline analysis
<codysseus> Yeah that makes sense. In my case I was actually looking at an incorrect diagram and got the wire colors mixed up.
<azonenberg> That would do it too
<azonenberg> I do the same thing when reverse engineering hardware at work. if i'm sticking bodgewires onto a DUT I will usually fire up the label maker and tag each wire with a signal name
<azonenberg> and/or have a notes document that records what color wire goes where
<azonenberg> so when i go back to probe something again i know what it is
<codysseus> Yeah that makes sense. I am still in the early days of being an organized EE
<azonenberg> Woop. Tek MSO64 loaner unit acquired
<azonenberg> Hoping to have initial test waveforms by later today and more extensive work later in the week
<azonenberg> I've got it until some time in January so plenty of time for dev
juli966 has quit [Quit: Nettalk6 -]