<azonenberg>
AKL-AV1 v0.2 prototype assembled and cooling in the oven
Guest96 has joined #scopehal
<azonenberg>
Hmmm, still not good
<azonenberg>
360ps rise time
<azonenberg>
attenuation is closer to 5.3:1 than the 5:1 i was aiming for
<azonenberg>
and while my new offset trim circuit does allow me to trim to 0V offset at DC, when i apply a signal the offset seems to change
<electronic_eel>
azonenberg: have you considered using the composite loop mode of the buf802 to implement the dc voltage offset? this would prevent any current leaking out of the probe and similar things
<electronic_eel>
or do you think this is not worth the added complexity?
Bird|otherbox has joined #scopehal
<Stephie>
whats the design frequency of the av1 again?
<azonenberg>
Stephie: "as high as i can get"
<azonenberg>
hard upper limit is -3 dB BW of the buf802
<azonenberg>
electronic_eel: i have considered it
<azonenberg>
there are two problems which have prevented me from trying it to date
<azonenberg>
the first is board area
<azonenberg>
the second is that i want to add as little extra capacitance as possible
<azonenberg>
my input now has *extremely* low capacitive loading
<azonenberg>
and i want to keep it that way. adding a second amplifier would ruin that
<azonenberg>
one possible option i am considering is using a buf802 in buffer mode, accepting there will be a lot of offset
<azonenberg>
then putting a *second* amplifier on its output
<azonenberg>
and nulling there, using the buf802 to prevent feeding voltages back into the dut
<Stephie>
at least buf802 is fairly cheap
<azonenberg>
Yeah. i mean i may not use a buf802 for the second stage
<azonenberg>
no reason to use a fancy jfet amplifier there
<azonenberg>
in fact i can even add additional gain in the second stage since the current setup is 10:1 attenuation
<Stephie>
i guess thats beneficial as long as the gain has lower noise than the scope frontend, which shouldn't be too hard
<azonenberg>
Yeah. also with weak signals
<azonenberg>
because a lot of scopes have less BW at the lowest v/div setting
<azonenberg>
e.g. my 4 GHz waverunner below 5 mV/div drops to something like 1 GHz
<Stephie>
wow
<azonenberg>
i actually called support about it, thought something was wrong
<azonenberg>
they pointed me to the section in the datasheet saying the BW spec was at 5 mV/div or greater
<Stephie>
wow, thats nice to know
<azonenberg>
anyway, i have no objection to throwing a second buf802 on the output
<azonenberg>
There are other options though
<azonenberg>
The other thing i want to explore is why i am seeing an extra 2x attenuation
<azonenberg>
i designed the frontend attenuator to give 5:1 but i am seeing 10:1
<azonenberg>
the reason i had weird response earlier is that i tuned the cap to give 5:1 at high freqs but the resistors were giving 10:1
<azonenberg>
so it was horribly overcompensated
<azonenberg>
tuned the trmicap*
<azonenberg>
trimcap*
<azonenberg>
when i tuned the cap to match i got a nice flat 10:1 response
<azonenberg>
i wonder if it might be due to the 50 ohm series resistor i have on the amplifier output (R10) forming a voltage divider wrt the 50 ohm terminator at the scope input
<azonenberg>
but that was in the reference schematic
<Stephie>
does that affect the rise time at all?
<azonenberg>
the impression i get is that the output isn't matched well to 50 ohms without that
<azonenberg>
so i might just have to accept that attenuation and be fine with it
<azonenberg>
honestly i don't have a huge problem with a 10:1 active probe, the point of being active here is not to see ultra weak signals
<azonenberg>
it's to have less loading than you'd get any other way
<azonenberg>
basically the buffer is to avoid both the high resistive loading of the 50 ohm scope input and the high capacitive loading of the 1M || 17 pF input
<azonenberg>
instead you see 5M || ~350 fF at the DUT
<azonenberg>
bottom plot here is the same time scale as the one i linked of my probe
<azonenberg>
this is a LeCroy ZS1500
<azonenberg>
pretty sure the capacitive loading is worse than mine by a sizeable margin :D
<azonenberg>
and my rise times are better
<azonenberg>
even without de-embedding the cable
<Stephie>
awesome
<azonenberg>
So if i can fix my dc offset problem i think the AV1 is a winner
<Stephie>
im surprised one of the scope companies hasn't offered you some money you can't refuse to work for them
<azonenberg>
especially considering how cheap it is :p
<azonenberg>
the zs1500 is like $2k msrp
<azonenberg>
my probe might be a few hundred USD if i sold it at a profit
<azonenberg>
or $150ish at breakeven?
<azonenberg>
and that's considering the $60ish cable which is the most expensive line on the bom lol
<azonenberg>
So far the only scope vendor to formally offer me a job is Pico
<azonenberg>
I told them no for the moment, that i was happy doing this for fun and enjoyed what i do at $dayjob
<azonenberg>
they then asked nicely if i would please not work for a competitor if i wasn't gonna take their offer :p
GenTooMan has quit [Ping timeout: 260 seconds]
<Stephie>
lol
<Stephie>
well, for now, I'm glad you're working on open source
<azonenberg>
The T&M world has been way too closed for way too long
<azonenberg>
i'm doing what i can to fix that
<Stephie>
it took a long while and a lot of work for the "standard" for software tooling to become open source toolchains
<Stephie>
the same will be true for hardware
<azonenberg>
Yes
<azonenberg>
but i very much intend for open hardware T&M to become something the industry simply cannot ignore any longer
<Stephie>
affordability of measurement equipment is definitely quite a barrier to high-speed open hardware in general imo
<Stephie>
signal integrity is hard, EMC is hard, and there's not enough knowledge or tooling in many communities to make the right measurements for good designs
<azonenberg>
Yeah
<azonenberg>
there's only so much i can do wrt scopes because fast ADCs are still very expensive
<azonenberg>
i expect for the near term our open hardware scopes will not be much cheaper than competing commercial ones because we won't have the economies of scale they do
<azonenberg>
but that's for a naked scope w/ no software options
<azonenberg>
which is where glscopeclient compes in to tip the balance in the favor of f/oss
<Stephie>
yeah, agreed
<azonenberg>
and then of course our probes are rapidly catching up to the state of the art in the commercial world at a fraction of the cost
<azonenberg>
the PT5 is already a world class passive probe and i want to push it even further
<azonenberg>
i have dreams of turning an updated version of the PT1 into the world's first >10 GHz handheld passive probe
<azonenberg>
i think i can do it if i borrow some architectural tweaks from active probe designs
GenTooMan has joined #scopehal
<azonenberg>
most notably, moving a damping resistor into the pogo itself
<Stephie>
the chinese scope manufacturers seem to be catching up to american/european manucaturers pretty quick, and siglent at least seems open to glscopeclient
<azonenberg>
i think that will solve the problems i was having with the 5 GHz peaking on the previous pt1 rev
<Stephie>
so I'm hopeful hgardware in general will get more in reach
<azonenberg>
Yes. siglent loves me and is throwing dev scopes at us as fast as they can
<azonenberg>
in fact i have a sds2034x+ hd dev scope on a UPS truck now
<Stephie>
I hope software fixes and more wfm/sec comes out of it
<azonenberg>
arriving by dinner time
<azonenberg>
yes
<azonenberg>
i hope so too
<azonenberg>
i have a call scheduled with some folks from siglent next week to discuss next steps in our relationship and pushing for more wfm/s is high on my agenda for said meeting
<Stephie>
maybe one day a >10GHz realtime scope will be in my price range :P
<azonenberg>
One day lol
<Stephie>
azonenberg, looking forward to the results
<Stephie>
for now, 34GHz sampling is fine for me, I'll probably end up buying a siglent 5000X+ series though
<azonenberg>
ah, the one model i haven't tested with yet :p
<Stephie>
but yeah, my scope is pretty useless without probes so I'm interested in buying something from AKL as soon as it's available
<azonenberg>
(it should work though, there's some support in the codebase)
<azonenberg>
and yeah they'll be ready when they're ready
<azonenberg>
right now the biggest holdup for release of the PT5 is those resistors
<azonenberg>
which i was promised by the end of july, i think the 20th was the last estimated ship date
<Stephie>
did you mean you havent tested the 5000X+ series?
<azonenberg>
Correct
<azonenberg>
I think someone else did briefly
<azonenberg>
but siglent has sent me demos of the 2000 and 6000 and now the 2000hd
<azonenberg>
and some other folks here have played a fair bit with the 1000 series stuff
<Stephie>
for me that line seems to be the best for price/perf
<azonenberg>
so the 5000 is now the least well tested line
<Stephie>
the 6000 isnt *so much* of a step up from the 5000, especially cause the sample rate is the same
<azonenberg>
yeah in fact, the 5000 has an external ref clock input
<azonenberg>
which the 6000 lacks
<Stephie>
oh wow?
<Stephie>
thats cool
<azonenberg>
5000 is afaik the only siglent that has one
<Stephie>
I'm looking to get a 10mhz ref clk from leo bodnar and use it for my PXIe frame at least
<Stephie>
so having it for the scope too would be great
<Stephie>
for that matter I'm still wondering what the best way to handle my PXIe frame in the lab is. The controller is pretty underpowered to run glscopeclient, but it has the PXI bus with some fairly high bw instrumentation on
<Stephie>
some kind of network remote protocol for scopehal would be neat, but hard to graft on when scopehal isnt designed for that
<azonenberg>
look at what we do for the pico, digilent, etc bridge servers
<Stephie>
yeah, presumably I'd have to write bridge servers for each instrument
<electronic_eel>
it would be nice if siglent could add a sfp+ port to the fpga of a future scope. directly connecting it to the fpga instead of the applications processor should allow for much faster data transfer. they also should change to a network protocol that splits scpi commands and data into two different channels
<Stephie>
scpi can be fairly high performance if its queued and buffered properly, but yeah
<Stephie>
attaching an SFP+ to the fpga while leaving a standard port to the application processor would give another option for buffer transfer for those that need super high bandwidth
<electronic_eel>
you'd have to implement at least part of the scpi in the fpga if you want to do the network transfer directly from the fpga. and for speed i would really want that
<Stephie>
would you?
<azonenberg>
yeah all you would need would be the socket layer and raw socket framing
<Stephie>
you could "bolt it on" fairly easily if you just attach a sfp+ to the fpga and have a method for scpi to provide buffers right from the fpga
<azonenberg>
assuming we did dual sockets like we do on the bridges
<Stephie>
no need to implement scpi outside application processor
<azonenberg>
you'd have scpi on the apps processor for the control plane
<azonenberg>
second socket for raw data
<Stephie>
yup
<electronic_eel>
yeah, second socket for data. that is what i meant
<Stephie>
yeah
<Stephie>
would be nice if SCPI performance was higher by default though
<electronic_eel>
but do you need higher scpi performance for anything but data with a scope?
<azonenberg>
(this is exactly what i plan on doing for architecture of our own instruments)
<azonenberg>
well, right now the siglent stack has no buffering and queueing
<azonenberg>
and we have rate limiting up the wazoo
<azonenberg>
max of 20 Hz command issue rate
<azonenberg>
because otherwise the scope chokes and drops commands
<Stephie>
yup
<Stephie>
it's some terrible software architecture
<azonenberg>
the overhead to just trigger in a loop even if you're not actually pulling waveforms off is huge
<azonenberg>
yes, but i cant blame siglent TOO bad given the status quo
<azonenberg>
have you looked at the tek msos or any other scope? :P
<Stephie>
i just wish the status quo wasn't... this
<azonenberg>
lecroy is one of the few that actually has a sane scpi layer
<azonenberg>
wrt being able to properly queue up commands
<azonenberg>
too bad it's just tunneling vbscript and COM method calls over that :p
<Stephie>
just need to hire some decent software engineers
<Stephie>
the industry is definitely moving in the right direction though
<electronic_eel>
at least for the siglent stuff i have looked at it is all implemented in a single monolithic application on the apps processor. scheduling inside this app didn't look too well implemented from looking at it from the outside
<azonenberg>
Yeah
<Stephie>
SCPI until a few years ago was just a feature for a few matlab scripts using VISA unfortunately
<azonenberg>
yeah
<azonenberg>
this is another thing lecroy did right
<azonenberg>
although it is all decades-old COM architecture dating to windows 2000
<azonenberg>
but they have internal app servers for each of the various subsystems and the MAUI gui calls out to those APIs
<azonenberg>
the same apis that glscopeclient does, for the most part (waveform download being an exception)
<azonenberg>
but it means they actually have APIs for basically any knob you can twiddle in the gui
<azonenberg>
you can fully automate all of their software options and everything if you want
<azonenberg>
i just dont bother because to me the scope is a fancy adc :p
<Stephie>
whats the highest waveforms/sec driver right now? lecroy?
<Stephie>
or the pico?
<electronic_eel>
iirc it is the pico with their usb 3
<electronic_eel>
the instrument is designed to be used only over usb, so they have a fast channel to offload the data to the pc.
<Stephie>
presumably you can get >1gbps out of the picoscope too
<Stephie>
yeah, software display scopes usually have a much better API than ones with built in display
<Stephie>
virtualbench, digilent, pico
<electronic_eel>
unfortunately they usually need some proprietary binary running on the pc to make that api accessible...
<Stephie>
or some reverse engineering :P
<Stephie>
I have a PXI/PCI scope which comes with a full register map and description of the API flows in the user manual
<Stephie>
which I appreciate so much
<Stephie>
makes the free software driver not legally iffy at all, however the hardware is unobtanium so :(
<Stephie>
virtualbench API is fairly easily black box reversible however
<Stephie>
they're using an off the shelf RPC protocol which wireshark has a protocol decode for
<Stephie>
so a black box driver isnt too hard
<Stephie>
(and that hardware isn't unobtanium, in fact its identical to the digilent ADP5250)
<Stephie>
I need to try digilent waveforms and see if it's locked to only the digilent sold adp5250 or if digilent waveforms works with the NI-branded ones too
<azonenberg>
yes, i've hit close to 3 gbps of the picoscope
<azonenberg>
the digilent stuff tested on the adp3450 gives pretty decent wfm/s
<azonenberg>
but it's only 64k points of memory
<azonenberg>
which is a disappointment
<azonenberg>
lecroy is quite a ways behind pico in throughput but also has much higher sample rate and bandwidth than any picoscope can deliver
<azonenberg>
so they're the best choice if you need more than 5 Gsps on 1/2 channels