<_whitenotifier>
[scopehal-apps] azonenberg opened issue #301: Preference file loading fails on locales that use commas as decimal separator - https://git.io/JLtVO
<_whitenotifier>
[scopehal-apps] azonenberg assigned issue #301: Preference file loading fails on locales that use commas as decimal separator - https://git.io/JLtVO
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #301: Preference file loading fails on locales that use commas as decimal separator - https://git.io/JLtVO
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>
https://www.antikernel.net/temp/v0p4-risetime.png 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
<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
<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>
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>
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 - https://git.io/JLmhQ
<_whitenotifier>
[scopehal-apps] pd0wm edited a comment on issue #300: December 19th hackathon meta-issue - https://git.io/JLmhQ
<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 - https://git.io/JLYem
<_whitenotifier>
[scopehal-apps] azonenberg commented on issue #300: December 19th hackathon meta-issue - https://git.io/JLYf4
<_whitenotifier>
[scopehal-apps] azonenberg edited a comment on issue #300: December 19th hackathon meta-issue - https://git.io/JLYf4
<_whitenotifier>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JLYLK
<_whitenotifier>
[scopehal-apps] azonenberg da51f6c - FilterGraphEditorWidget: correctly refresh when we change stuff
<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
<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
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. - https://git.io/JL3Vq
<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] https://git.io/JL3KA
<_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?
<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