azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://freenode.irclog.whitequark.org/scopehal
<Bird|otherbox> hm, they are, kindasorta
juli966 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> Bird|otherbox: pretty sure i've seen them in mems
<azonenberg> But i dont know if they're low enough power for rtc/standby usage
<azonenberg> I generally don't do much that needs that though
Construct has joined #scopehal
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
Construct has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_whitenotifier> [starshipraider] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/JtGQU
<_whitenotifier> [starshipraider] azonenberg 0e3ceed - AKL-AD1 v0.2
<_whitenotifier> [starshipraider] azonenberg pushed 8 commits to master [+1/-0/±15] https://git.io/JtGQm
<_whitenotifier> [starshipraider] azonenberg 817899b - Updates to MAXWELL main FPGA
<_whitenotifier> [starshipraider] azonenberg 3aaa946 - Updating MAXWELL power spreadsheet
<_whitenotifier> [starshipraider] azonenberg 0323d5a - Updating MEAD diffpair simulation
<_whitenotifier> [starshipraider] ... and 5 more commits.
juli966 has joined #scopehal
bvernoux has joined #scopehal
<azonenberg> bvernoux: new differential probe ordered
<azonenberg> Probably going to turn my focus to an overmold of the probe tip soon
<bvernoux> nice
<bvernoux> I see you have bought a Picoscope 500MHz BW (probably Picoscope 6000) ?
<azonenberg> It's a 6824E i believe, and i didn't *buy* it
<azonenberg> The CEO of Pico is giving it to me free as a dev unit so i can add scopehal support
<bvernoux> it is sampling scope IIR
<bvernoux> IIRC
<azonenberg> no this is full realtime
<bvernoux> ha great
<azonenberg> their sampling scopes go to 25 GHz bw iirc
<bvernoux> yes as Picoscope IDE is ugly ;)
<azonenberg> This one is realtime, 500 MHz, i think 5 Gsps?
<bvernoux> PicoScope6 UI is just awfull and very old school ;)
<bvernoux> yes it is 5GSPS IIRC
<bvernoux> yes it is a real scope ;)
<bvernoux> I do not like sampling scope
<bvernoux> they are too limited and they are not "oscilloscope" for me ;)
<bvernoux> but the 6824e is a real scope with 5GSPS and lot of memory 4GB
<bvernoux> with 8 chan ;)
<azonenberg> I plan to pair it with my lecroy scopes
<azonenberg> to sniff the low speed signals and save the lecroy channels for high speed
<azonenberg> set them up off a shared refclk and trigger cascade under glscopeclient
<bvernoux> yes Picoscope are a must have for "low speed signals" in realtime especially with the SDK API
<bvernoux> as it is clearly not possible to do that with any other scope
<azonenberg> Yeah. Well, i'll let you know how it goes
<azonenberg> It's coming monday
<bvernoux> ok great
<bvernoux> it includes also a 14bits 200MS/S AVG
<bvernoux> so it is not bad to generate some low speed signals up to 20MHz
<azonenberg> Yes i plan on playing with that a bunch
<bvernoux> and with 50MHZ integrated generator too
<bvernoux> but I suspect they use the 200MS/S AWG for that which is clearly at limit for 50MHz signal
<bvernoux> for me 200MS/S DAC is 20MHz ;)
<bvernoux> with the rule of 10 the same I use for Oscilloscope ;)
<bvernoux> to have something correct
<bvernoux> max sampling rate over USB 3.0 is about 312MS/s
<bvernoux> so it clearly beat lot of high end scope
<bvernoux> for tha purpose
<bvernoux> that
<azonenberg> Yeah i'm looking forward to seeing the WFM/s i can push with it
<azonenberg> i suspect i will have to do a lot of optimization to keep up with it
<bvernoux> yes it is a good test to push the limit of OpenGL/GFX Card ... ;)
<bvernoux> there is also a Max sampling rate to on-device buffer which can reach 1.25GS/s (8-bit mode)
<bvernoux> it seems also even this high end Picoscope does not have 50 Ohms input feature
<bvernoux> very strange
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<bvernoux> I do not see it in the datasheet
<azonenberg> i could have sworn it did
* azonenberg double checks
<azonenberg> they sell 50 ohm probes for a reason
<azonenberg> input characteristics: 1M +/- 0.5% || 12 pF +/- 1 pF, or 50 ohm +/- 2%
<bvernoux> ha yes it is 50 ohms have I missed that ;)
<bvernoux> so great
<azonenberg> it also seems to support dynamic ADC resolution configuration
<azonenberg> 8/10/12 bits
<azonenberg> So it will be fun to play with that
<bvernoux> yes you have FlexRes option
<bvernoux> which seems to be part of the ADC HW
<bvernoux> it is not just a SW Decimation as it is done in ADC IIRC
<azonenberg> Correct
<azonenberg> i've had a bit of a chat with Alan about that. It's likely similar to what the HDO9000 does WRT adc reconfiguration
<azonenberg> anyway, i'll find out more when the hardware comes in on monday
<azonenberg> Looking forward to playing with it
<bvernoux> the main advantage of Picoscope is mainly the SDK+USB 3.0 streaming I think vs normal scope
<bvernoux> you can also compress the frames
<bvernoux> which does not exist in scope
<bvernoux> I have that feature with my Pico3000 too
<azonenberg> I'm going to spend a little while playing with the SDK and the pico GUI first
<azonenberg> then figure out how much of you/noopwafel's code is going to work on the 6000 series
<bvernoux> the Pico GUI is disappointing ;)
<azonenberg> i dont know how similar the APIs are
<bvernoux> slow
<bvernoux> it is >10x slower than using the SDK API
<azonenberg> i'm sure the complete lack of hardware acceleration doesn't help
<bvernoux> there is hw acceleration for GUI stuff
<azonenberg> there is?
<bvernoux> to be checked ;)
<bvernoux> the famous HAL4
<bvernoux> The PicoScope 6000E Series’ HAL4 hardware acceleration can achieve update rates of 300 000 waveforms per second in fast persistence mode
<bvernoux> So there is like a "DSP" doing stuff in Pico
<bvernoux> it seems there is a mode where the Picoscope create the picture
<bvernoux> and you just stream the picture data which is faster than doing that for each chan
<bvernoux> especially for Eye Diagram ....
<bvernoux> but it seems very specific for that use case
<bvernoux> where you have a slow PC
<bvernoux> I'm clearly not sure it is interesting for glscopeclient anyway as it is not planned it just display some GFX frame so far
<bvernoux> an interesting old topic about speed of Pico vs normal scope
<bvernoux> Tektronix DPO5054B 9 waveforms in 10 seconds
<bvernoux> PicoScope 6404C 180 waveforms in 10 seconds
<bvernoux> it is very old ;)
<bvernoux> test was At 500us/div both oscilloscopes sample at 5GS/s and collect 25 million samples per screen update. The measured screen update rates are as follows:
<bvernoux> so 18fps with 25MSPS/5GSPS is clearly better that what you have with your best Lecroy IIRC
<bvernoux> it seems to be a very good compromise to be checked if the noise is good enough for the diff probe ...
<bvernoux> interesting point is it can convert 3.3v or 5V to +/-2.5V
<bvernoux> the part is LM27762
<bvernoux> Output noise seems to be 22uVRMS which is quite good
<bvernoux> it will be great for the AKL-AD1 and just to plug it on an USB ...
<azonenberg> No i dont need the supply
<azonenberg> i was looking for a DAC that ran on +/- 2.5V
<azonenberg> 18 FPS with 25 megasamples is a very nice framerate
<bvernoux> I was speaking about doing the +/-2.5V with LM27762 from +5V
<azonenberg> that's 450 Mpoints/sec or 3.6 Gbps of actual waveform data
<azonenberg> ~400 M5ps is the most i've usually seen streaming from my lecroy scopes
<azonenberg> Msps*
<azonenberg> Mbps*
<azonenberg> gaah
<bvernoux> yes it is clearly a killer feature with a very fast PC/GFX card(GPU) ;)
<azonenberg> as far as the +/- 2.5V the plan is for all of our active probes to be given bipolar +/- 7V over the USB connector
<azonenberg> Which they will then regulate to whatever rails they need internally
<azonenberg> at the scope side, the +/- 7V will be generated via some sort of DC-DC from a single +12V input
<bvernoux> USB C with PD could provide +12v ;)
<bvernoux> it is a convenient connector for that to avoid something non standard
<azonenberg> Yes, but PD gives a unipolar supply
<azonenberg> the whole point is to avoid noisy switching regulators inside the active probe head
<azonenberg> I want it to be all LDOs
<azonenberg> We've already worked it out, we're using PD negotiation over the CC channel but negotiating an alternate mode
<azonenberg> which uses +/- 7V over SSTX/SSRX
<azonenberg> We are using USB-C
<azonenberg> It's just not using the normal PD because that doesn't provide a negative rail
futarisIRCcloud has joined #scopehal