<d1b2>
<Attie> i take your point about the fact that they aren't analog anymore - everything is in the native units
<d1b2>
<Attie> and i'm not advocating against storing the data behind the scenes as 0=beginning of capture / sample memory
<d1b2>
<Attie> but, when working with a scope, you'll often find yourself triggering on an "interesting" event, and will want to inspect around that event
<d1b2>
<Attie> currently that appears to be quite frustrating, as the waveform shifts in the client based on the size/number of samples in the pre-trigger buffer
<d1b2>
<Attie> it could well be an artifact of the way I use my scope vs. you (and the features that the scopes have available)
<d1b2>
<Attie> for instance, I don't choose sample rate or memory depth, it "just does stuff"
<d1b2>
<Attie> changing the horizontal scale and offset has a direct impact on what ends up in the sample memory
<d1b2>
<Attie> ... don't / can't
<d1b2>
<Attie> it's also quite possibly something that some scopes don't provide (i.e: where the "trigger" event is in time or sample index)... i don't know enough about the protocols
<d1b2>
<Attie> on an unrelated note, it would seem that glscopeclient just crashed and took my scope with it
<d1b2>
<Attie> this also appears to explain some performance issues i was seeing in glscopeclient - the enforced reboot has "fixed" them
<monochroma>
it's usually the other way around, the scope sends (or doesn't...) unexpected data to the driver because it's in a bad state and then that crashes glscopeclient
Degi has quit [Ping timeout: 240 seconds]
<_whitenotifier-f>
[scopehal-apps] attie opened issue #284: Agilent MSOX2024A - Performance issues and crash - https://git.io/JkzJW
laintoo has quit [Read error: Connection reset by peer]
laintoo has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
<azonenberg>
attie: yeah, that's been my experience too
<azonenberg>
The exception code you mentioned c0000094 is a divide by zero error scope side
<azonenberg>
Which could possibly have been the result of glscopeclient sending malformed data, but if everything was slowing down over time there's a good chance the scope was borked
<azonenberg>
Based on the error code i would assume your scope is windows based
<azonenberg>
have you looked at the windows event log?
<miek>
so i think the slowdown & warnings are because the scope was set to glitch trigger but the driver doesn't handle that, so it can't cache the trigger settings and polls for them constantly?
<miek>
reboot reset the config to edge trigger, caching works again, glscopeclient goes brrr
<azonenberg>
miek: That would make sense. The trigger logic should warn if it sees a trigger type it doesnt understand though?
<azonenberg>
in any case, implementing the other trigger types shouldn't be difficult
<azonenberg>
and is probably worth doing
<azonenberg>
i've only implemented advanced triggers for lecroy and recent tek, because that's all i have access to
<miek>
a constant spew of "unknown trigger type" messages was mentioned in the issue
<azonenberg>
Oh
<azonenberg>
well, that's definitely part of it. Comment on the ticket and open a new ticket against scopehal (not -apps) for adding glitch trigger support?
<azonenberg>
in agilent msox2 specifically
<azonenberg>
we have glitch triggers in the API/UI already, its just a matter of adding the marshaling logic to convert that into the scpi commands the scope understands
<_whitenotifier-f>
[scopehal-apps] miek commented on issue #284: Agilent MSOX2024A - Performance issues and crash - https://git.io/Jkza0
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #scopehal
<_whitenotifier-f>
[scopehal] miek opened issue #342: AgilentOscilloscope: add glitch trigger support - https://git.io/Jkzab
_whitelogger has joined #scopehal
<marshallh>
anyone used a nanoVNA v2
<azonenberg>
marshallh: I've heard good things about them but no personal experience
<azonenberg>
I've only used the xaVNA, which is OK-ish for what it is
<azonenberg>
and the picovna, which gives good data when it wants to work
<azonenberg>
but the software and general unreliability makes you want to pull your hair out
<marshallh>
cool, i'll get one and report back. its for 2.4g pcb IFA
<azonenberg>
this is how big my 40G MAC and IP stack is. RX only so far, i'm most of the way done with the IPv4 receiver now
<azonenberg>
haven't touched v6 or any upper layer protocols, ARP, or the TX side yet
<azonenberg>
But it (almost) works in simulation processing a stream of pings
<azonenberg>
and it passes timing which is more important
<azonenberg>
This is on an xc7k160t in -2 speed
<marshallh>
so roughly 8-10%
<azonenberg>
no much less
<marshallh>
yeah, i guess it just depends on PAR
<azonenberg>
Total resource usage so far is 1.3 kLUT for the MAC, 0.2 kLUT for the frame parser, 0.5 kLUT for the IPv4 protocol. the non-highlighted stuff is vivado IP glue that's used to hook up i/os so it wont get optimized out
<marshallh>
neat
<azonenberg>
That adds up to 1798 LUTs on an fpga with 101400
<azonenberg>
So 1.7%
<azonenberg>
total usage including the vivado glue is 3.13%
<azonenberg>
i'm sure when i start implementing TCP it's gonna get a lot bigger
<azonenberg>
or when i throw on a 64-bit ddr3 controller
<marshallh>
how much do you expecT?
<azonenberg>
to say nothing of the 96 channel logic analyzer trigger and RLE compression engines
<azonenberg>
for the full design? i'm seriously worried about running out of gates
<marshallh>
well, for TCP
<azonenberg>
Oh. Too soon to say
<azonenberg>
i never finished my last tcp core
<azonenberg>
so i dont have anything to compare to
<azonenberg>
But i'm concerned because this is the biggest webpack kintex7
<azonenberg>
If i need more gates i have only a couple of options
<azonenberg>
one is to move to the xc7k325t, pin compatible but might need some power supply upgrades to the board, and buy full vivado
<marshallh>
yeah, i think hte largest cyclone 10 GX you can get with free quartus is 220k LEs
<azonenberg>
This means going from a $386 FPGA to a $1450 one
<azonenberg>
plus dropping another $2.5K on vivado
<marshallh>
yeah
<azonenberg>
so it would add $4K or more to the project budget
<azonenberg>
The other option is to go ultrascale
<marshallh>
you could go with a 2-fpga solution and increase your suffering
<azonenberg>
There are two candidates: the xcku025, available only in a 1156 ball package for $994-1391 depending on speed grade
<azonenberg>
or the xcku035, available in a similar sized 676 ball package for $1129-1924 depending on speed grade
<azonenberg>
both ultrascale options are available in webpack but use different vccint and are not footprint compatible with 7 series
<azonenberg>
so i would need a major board layout change
<azonenberg>
I already *have* a 2-fpga solution lol
<marshallh>
hahahaha
<azonenberg>
this is the big one
<azonenberg>
then the small one is an xc7s6 that is RTL complete and tested in simulation
<marshallh>
what's vccint on ultrascale? is it sub-1v?
<azonenberg>
I believe 900 or 950 mV but i dont have that datasheet handy
<azonenberg>
i've never done an ultrascale pcb, only worked on devkits
<azonenberg>
Anyway the spartan7 is just a dozen uarts and small block ram fifos, plus some gpios and timers for managing hotswap power to all of the logic analyzer pods
<azonenberg>
plus a spi device interface to the stm32f777 which handles all of the control plane stuff
<marshallh>
ah yeah
<azonenberg>
then the main fpga needs to fit a 40gbps TCP offload engine, a 64-bit ddr3 controller, a complex LA pattern trigger engine
<azonenberg>
96 LVDS inputs at potentially 5 Gsps
<azonenberg>
(sorry it's 92 at 5 and 4 at 10, complicated)
<azonenberg>
and a RLE compression block that squishes the 0.5 Tbps of sample data from the probes into a single ddr3 1333 sodimm interface
<azonenberg>
I think realistically it may be challenging to run all channels at full rate at once due to bandwidth limits
<azonenberg>
at least with deep sample memorty
<azonenberg>
memory*
<marshallh>
that's 21 gbyte per sec
<marshallh>
if im calculating itright
<marshallh>
on ddr3
<marshallh>
so yeah crunching 500 gb/sec down to 21
<azonenberg>
There's 62.5 GB/s coming off the probes
<azonenberg>
The RAM is 64 bits * 1.3 Gbps per pin = 83.2 Gbps = 10.4 GB/s
<azonenberg>
and that's theoretical throughput assuming no address overhead, realistically i'd take at least 10% off that
<marshallh>
ah right yeah ddr is already factored into 1333
<azonenberg>
So basically i need at least 7-8:1 compression ratio which might be hard to do
<marshallh>
the address overhead should be very small
<marshallh>
less than 1-2%
<marshallh>
as long as you have long bursts, which you will
<azonenberg>
Yeah. My plan is to have each compression engine buffer input data at full line rate in block ram
<azonenberg>
then compress as fast as i can, then stream into a second fifo which is then emptied into the ddr
<azonenberg>
and stop capturing when you either hit the configured sample count or one of the fifos fills up
<azonenberg>
So worst case, you can capture at full sample rate until you run out of block ram
<azonenberg>
and the more compressible your data is / the less channels you have active, the more use you can get out of the ddr
<azonenberg>
If you have only two of the 12 probe pods active you can fit in the available ram b/w even with no compression
<azonenberg>
the more probes you have active, the more compression you need to run at full rate
<azonenberg>
If you run at lower rate, say 2.5 Gsps you can use four pods with no compression and more with
<azonenberg>
at 1.25 Gsps you can use 8
<marshallh>
luckily, the faster the sample rate, the more likely the RLE ratio will be favorable
<azonenberg>
Which means that at 1.25 Gsps with a very achievable ~1.5:1 compression ratio, you can run all channels
<azonenberg>
Yeah
<azonenberg>
I'm not expecting you to be running at 5 Gsps sampling 5 Gbps PRBS31s on all channels
<marshallh>
usually you are oversampling by at least 4x, and 8x is better. the only caveat is if you are sampling on a provided clock for state sampling
<marshallh>
lmao
<azonenberg>
Yeah. Which at least initial firmware will not support
<azonenberg>
MAXWELL should be capable of oversampling 16 lanes of 1000base-X / SGMII
<marshallh>
the agilent analyzers of yesteryear always imposed a 2-3x samplerate penalty when using a supplied clock over free run
<azonenberg>
(at least)
<azonenberg>
unrelated, i paid the invoice yesterday so it's official, i'm getting a new 4 GHz active diff probe
<azonenberg>
the D420 on ebay i think i showed you
<marshallh>
nice
<marshallh>
D420 blaze it
<azonenberg>
lol
<azonenberg>
Anyway the other question is how fast the MEAD logic pods can actually run
<azonenberg>
they were designed to run at ~4 Gbps theoretical best case but that didn't take pcb or cable losses into account
<marshallh>
do you have many active components in the probe heads
<azonenberg>
They're comparator based, so yes
<azonenberg>
the output to the fpga is lvds
<marshallh>
at that point i don't know if you'd use rf amps or comparators
<marshallh>
lmao
<azonenberg>
the input of MEAD is 50 ohm MMCX using an external transmission line probe
<azonenberg>
then i use a mini-SAS (SFF-8087) cable to connect it to the LA
<azonenberg>
using the sideband signals for 12V power and UART control
<azonenberg>
and the four tx and four rx pairs for lvds data
<marshallh>
neat
<marshallh>
so the inputs are single ended
<marshallh>
or coudl use a different pod for differntial probing
<azonenberg>
There will be three different probe pods long term
<azonenberg>
MEAD is 50 ohm single ended
<azonenberg>
CONWAY will be high-Z on 100 mil headers like a saleae, mostly for low speed
<azonenberg>
then there will be a differential one, details TBD
<azonenberg>
(not named yet as there's not enough engineering to be worthy of one yet)
<marshallh>
usually my go-to for logic analysiss is to just drop a fpga on whatever it is i'm making or build an adapter to do such. then use signaltap lool
<azonenberg>
yeah, chipscope/signaltap cant go this fast
<azonenberg>
this is designed to oversample with the io serdes
<azonenberg>
also it will give you extreme memory depth and very high refresh rates
<azonenberg>
Hence the 40GbE
<marshallh>
yup
<marshallh>
ILAs only got to about 200-300mhz
<azonenberg>
The hardware was originally designed for a research project that's a joint collaboration with a German university
<azonenberg>
i decided to kill two birds with one stone and design hardware that could double as a general purpose LA
<azonenberg>
since the requirements of lots of probe inputs, an FPGA, and a fast interface to a PC were essentially the same
<azonenberg>
and i had wanted to build a LA for a while anyway
<azonenberg>
until the uni approached me about the project, i had been planning to have a DSO be my first test equipment project other than probes
<azonenberg>
and i still have a half finished DSO design i want to get back to but the LA has been eating my time lately
<marshallh>
yeah the DSO is the same storage problem. just the acquisition is more complicated
<azonenberg>
Yeah. I have a 100 MHz 50 ohm frontend and ADC subsystem designed, prototyped, and mostly characterized
<azonenberg>
(the frontend is designed to run to 500 but you'll need to upgrade the ADC for that)
<marshallh>
i assume you know of the LM97600
<azonenberg>
Yes. That's not the direction i plan to take. also i belive it's EOL or NRND now
<azonenberg>
My roadmap calls for five scopes
<azonenberg>
BLONDEL uses the HMCAD1520, the switchable 8/12 bit cousin of the HMCAD1511 used in the entry level rigols
<azonenberg>
but there's two of them on four channel acquisition boards, so you get 8 channels
<azonenberg>
with 1 Gsps of 8 bit or 500 Msps of 12 bit ADC shared among each set of 4
<azonenberg>
individually switchable
<azonenberg>
so you can have, say, four 250 Msps 8 bit channels and one 500 Msps 12 bit channel
<marshallh>
yeah
<azonenberg>
When in 12 bit 4 channel mode a 50 MHz antialiasing filter will be switched in
<azonenberg>
since 125 Msps is below nyquist for 100 MHz frontend bandwidth
<azonenberg>
you will also be able to switch that filter in on request at higher sample rates or in 8 bit mode
<azonenberg>
Anyway, the big thing holding me back on that is the active probe subsystem
<azonenberg>
I hate the 1M passive probe design and i didn't want to make another scope with 1M BNC inputs
<azonenberg>
So my scopes will all be 50 ohm SMA only
<azonenberg>
but they will support high-Z active probes for probing low speed sensitive signals
<azonenberg>
The plan is for each SMA input to have a usb-c port next to it
<azonenberg>
It will negotiate an alt mode that provides +/- 7VDC power on the SSTX/SSRX pairs, then uses the usb 2.0 data lines for control
<azonenberg>
adjusting probe gain/offset etc
<marshallh>
you could use i2c over the SBU1/SBU2 pins
<azonenberg>
That's an option but i wanted to use the actual usb lines in order to negotiate the alt mode
<azonenberg>
either via PD or usb 2.0, tbd - depends on how standards compliant i want to be
<marshallh>
yeah i figured you wouldn't be crazy enough to acutally do usb2.0 though
<azonenberg>
goal is to make it so you can't kill a probe or the scope or a peripheral
<azonenberg>
by plugging incompatible stuff in
<azonenberg>
it has to be standard enough that at best it will safely shut down
<marshallh>
PD is more flexible but also annoying
<marshallh>
if you put crap on the SBU1/2 pins you will be safe as long as its logic level
<azonenberg>
Yes. But true PD only gives you unipolar power
<azonenberg>
i need bipolar
<marshallh>
then you can do anything you want
<azonenberg>
hence my plan to use the SS pins for power
<marshallh>
i did this at work
<azonenberg>
as long as you dont use an active cable you're fine
<marshallh>
i put a uart tx/rx over the sbu1/2 pisn
<marshallh>
it works as long as you dont reverse the cable, which isn't a problem
<azonenberg>
My tentative thought was to use a mcu with actual usb 2.0
<azonenberg>
have it powered by vbus, run all the digital stuff off that
<azonenberg>
then negotiate the desired bipolar analog power over the usb channel
<azonenberg>
and then apply analog power to sstx/ssrx
<marshallh>
usb stacks suck big doo-doo, what are you going to do when you have 8 downstream usb ports with your probes on them
<azonenberg>
I won't be supporting hubs
<azonenberg>
If you plug the probe into a legit usb host, it will enumerate and run in digital-only mode, you might even be able to DFU it
<azonenberg>
if you plug a real usb device into the LA the host MCU will ignore it
<azonenberg>
and if you plug the probe into the LA it will work and negotiate power
<marshallh>
how is your host mcu going to have 8 ports though
<azonenberg>
It's not. there's going to be one on each port
<marshallh>
ok so 8 mcus
<marshallh>
that all have to be upgraded
<marshallh>
that's why i'm saying i2cd :)
<azonenberg>
anyway, the fine points of this still have to be worked out
<azonenberg>
that's the big missing part
<azonenberg>
If you're interested and have time, go for it :p
<azonenberg>
einthecorgi2 said they wanted to do it, then i never heard any updates and it's been almost a year
<azonenberg>
so i'm assuming it's not happening
<marshallh>
i can tell you some usb ports are not made equal
<azonenberg>
The end goal is to design a circuit i can throw down on a 4-channel acquisition card
<marshallh>
some of them short Vbus to the CC pins when you plug in
<marshallh>
imagine having 20v VBUS and then unplugging the cable and it blwos up your PD chip
<azonenberg>
which interfaces with a host fpga or mcu via an i2c or spi interface
<marshallh>
the usb-c ecosystme now has dedicated ICs for just this purpsoe
<azonenberg>
bipolar analog power? :P
<azonenberg>
PD is great if you only need one rail
<azonenberg>
the whole point of the custom system is that i want to avoid noisy SMPSes on the probe
<marshallh>
yeah
<azonenberg>
i want to feed bipolar rails to the probe than LDO on the probe
<azonenberg>
then*
<marshallh>
they make nice hand warmers too
<marshallh>
i can always tell when i'm using my zs1500
<azonenberg>
Yeah my d400a-at isn't cool either
<azonenberg>
Anyway, if you're interested and want to throw together a prototype go for it
<azonenberg>
i need both the probe and scope sides of the thing designed
<azonenberg>
ultimately i want something that runs on a cheap ass stm32 probe side that handles all communication with the host and can interface to i2c/spi dacs and such on the probe
<marshallh>
yeah, configure your PGAs and such
<azonenberg>
and something host side that does some kind of negotiation to confirm we're talking to one of my probes, then generates the requested analog voltage(s) from a single 12V intermediate rail
<azonenberg>
then switches it to the probe
<azonenberg>
for at least the initial version i don't need dynamic voltages on the analog rails
<azonenberg>
it will be fixed, tentatively +/- 7V which provides plenty of headroom for LDOing to 5.5V or so on the probe
<azonenberg>
and shared by all four probes on a 4-channel acquisition board
<azonenberg>
however i need individual switching for each usb port
<azonenberg>
and individual control
<azonenberg>
so i don't get problems if i mix up cables and plug a probe into channel 1 and my phone into channel 2 or something
<azonenberg>
is that something you'd be willing to work on? I just dont have the time now
<marshallh>
probably not sadly
<azonenberg>
:(
<marshallh>
i'm one of 2 engineers at my company running 24/7
<azonenberg>
Lol fun
<azonenberg>
anyway, continuing the discussion of the roadmap
<azonenberg>
DUDDELL will essentially be a non-oversubscribed BLONDEL
<azonenberg>
same form factor but one ADC dedicated to each AFE rather than one shared by four
<azonenberg>
so you get 1 Gsps 8 bit / 500 Msps 12 bit on all channels regardless of number of enabled channels
<azonenberg>
(This is the true baseline design, BLONDEL is just a cost optimized prototype)
<azonenberg>
DUDDELL will probably be 250 MHz bandwidth but i havent decided for sure
<azonenberg>
Then ZENNECK will interleave four HMCAD1520s per channel, 500 MHz bandwidth, 4 Gsps 8 bit / 2 Gsps 12 bit per channel
<marshallh>
nice
<azonenberg>
This may have to be a multi FPGA design because 32x ADCs is a lot of LVDS pins
<azonenberg>
And ram bandwidth
<azonenberg>
I think that's as far as i can sensibly push the HMCAD1520. It won't use any S&Hs, the ADC has ~600 MHz of analog bandwidth
<azonenberg>
so i plan to just put a 4-port passive splitter in the frontend
<marshallh>
and one day, a ADC08DJ3200 maybe :)
<azonenberg>
Why so wimpy?
<azonenberg>
VOLLUM will be the first of the second generation of scopes
<azonenberg>
Completely new frontend (the other 3 will be essentially the same other than the filter bandwidth)
<azonenberg>
10 Gsps, 12 bit all the time, 1-2 GHz analog bandwidth, using one AD9213 per channel
<marshallh>
hnggg
<azonenberg>
This will be serious ultrascale/ultrascale+ territory, likely multiple, to process 120 Gbps * 8 channels = 960 Gbps of JESD204B
<marshallh>
yeah ~Tbps
<azonenberg>
On top of the $3500 per ADC and the massive Rogers PCB
<azonenberg>
not going to be a cheap project
<azonenberg>
Then MURDOCK, which will likely never happen due to budget but is on the roadmap
<marshallh>
I like how 4.5W is consdiered "low power dissipation"
<azonenberg>
interleaves four AD9213s per channel to get 40 Gsps at 6 GHz
<azonenberg>
times 8 channels and you're seriously competitive with midrange tek/keysight/lecroy hardware
<azonenberg>
it will need multiple ultrascale fpgas and a buttload of DDR4 to keep up with the 3.84 Tbps of ADC bandwidth
<marshallh>
yeah
<azonenberg>
That is my endgame right now though. I don't want to be the open hardware rigol alternative
<azonenberg>
I want to take on the big guys
<azonenberg>
i know i can't compete with the ultra high end 100 GHz scopes etc because they're all ASIC
<azonenberg>
but silicon has advanced to the point that midrange scopes are doable with COTS parts
<azonenberg>
I'm also going to be putting in features that nobody else has. for example, 10GbE on even the baseline scopes, 40GbE on the higher end ones
<azonenberg>
And hopefully by that point glscopeclient will be fast enough to keep up
<azonenberg>
also in addition to 10 MHz sync reference inputs, there will be PPS inputs on everything
<azonenberg>
So if you really want precise timing of events, you can put a stratum 1 GPS NTP server on your LAN, have the scope get approximate timing from that
<azonenberg>
then use PPS for +/- a few ns timestamping of each trigger
<azonenberg>
i'm not sure how useful it will be, but a hardware clock that works in unix time and doesn't care about hours/minutes/days is basically just a big counter that rolls over every second
<marshallh>
yeah
<azonenberg>
and having an external sync input that resets the fractional count to zero (pushing the second up/down depending on which is closer) is trivial
<azonenberg>
and i was going to be timestamping triggers with NTP anyway
<azonenberg>
so it's just a matter of having an external reset on the fractional count
<azonenberg>
That, plus running the timestamping logic on a PLL multiple of the 10 MHz GPS time reference, should give you *extremely* accurate timestamping of waveforms
<azonenberg>
If you don't need that level of accuracy you can disable the PPS input, sync the hardware clock to NTP on the internet or set it by hand
<azonenberg>
and use the internal OCXO as a timebase
<azonenberg>
But i feel like certain fields might benefit from having a scope that has that level of traceability for trigger times
<azonenberg>
not sure if it would be accurate enough for stuff like particle physics
<azonenberg>
but it would certainly be enough for almost anything else
<d1b2>
<theorbtwo> Hm, going to have support for fibre -- possibly even fibre asap -- to keep EMI well away from your dut? Conformance folks like that sort of thing.
<azonenberg>
theorbtwo: at the moment, the plan is for all instruments i build to have one 10/100/1000baseT copper ethernet port
<azonenberg>
and either one 10G SFP+ or one 40G QSFP+ port
<azonenberg>
you will be able to use one or the other, not both at once
<azonenberg>
The 40G port will be able to run in 40G or 1x 10G mode (using the first lane and a breakout cable)
<azonenberg>
or did you mean optically isolated probes?
<azonenberg>
hey at least it was a sticker and not silkscreen
<azonenberg>
This is why any time i'm getting boards made, i explicitly specify the location of the date code etc on an extra gerber layer
<azonenberg>
also woo 40gbit IPv4 RX is now finished and makes timing
<azonenberg>
i still have to compute the pseudoheader for upper layer checksums but other than that everything is done
<azonenberg>
Total latency from the start symbol on the XLGMII bus until the upper layer protocol beginning to get data is 51.2 ns or 16 clock cycles at 312.5 MHz, or 2048 UIs at 40 Gbps (this does not include latency in the SERDES or PCS)
<azonenberg>
Which i think is pretty decent
<sorear>
"unix time" so what does your stack do if you're capturing a trace when a leap second happens
<azonenberg>
sorear: Good question, i'll have to look into that
<sorear>
because unix time handles those Badly
bvernoux has joined #scopehal
<_whitenotifier-f>
[scopehal] bvernoux opened pull request #343: Add specific define for MINGW to support C *printf Format %z - https://git.io/JkgqI
<_whitenotifier-f>
[scopehal] bvernoux edited pull request #343: Add specific define for MSYS2 mingw64 to support C *printf Format %z - https://git.io/JkgqI
<bvernoux>
Hello
<bvernoux>
I have just pushed a pull request to fix the "%zu" things with MSYS2 mingw64
<bvernoux>
I have tested it with success
<bvernoux>
I can say latest glscopeclient is better and better (test on Windows7 64bits)
<bvernoux>
In order to rebuild on MSYS2 mingw64 I have modified the CMakefile
<bvernoux>
I do not remember how to disable BUILD_TESTING with cmake parameter
<bvernoux>
...
<bvernoux>
Any hint is welcome or better to modify the scopehal-apps\CMakeLists.txt to disable BUILD_TESTING by default
<azonenberg>
bvernoux: -DBUILD_TESTING=OFF
<azonenberg>
on the cmake command line
<bvernoux>
Issue is Catch2 package does not exist
<bvernoux>
ha ok
<azonenberg>
Yes, it's not shipped in mingw and i havent looked into installing it on windows
<bvernoux>
so maybe add that option by default ?
<bvernoux>
and people who want the BUILD_TESTING will add the option ?
<azonenberg>
we could make testing default to off i guess
<azonenberg>
on windows
<bvernoux>
as it is very confusing error ;)
<azonenberg>
did you read the updated manual? we did mention the dependencies :)
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #343: Add specific define for MSYS2 mingw64 to support C *printf Format %z - https://git.io/JkgqI
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/Jkgqp
<_whitenotifier-f>
[scopehal] bvernoux 0092573 - Add specific define for MINGW to support C *printf Format %z Add #define __USE_MINGW_ANSI_STDIO 1 Required for MSYS2 mingw64 to C *printf Format "%zu" ... For more details see https://www.msys2.org/wiki/Porting chapter C *printf Format Specifier issues
<_whitenotifier-f>
[scopehal] azonenberg d64ceef - Merge pull request #343 from bvernoux/patch-1 Add specific define for MSYS2 mingw64 to support C *printf Format %z
<bvernoux>
ha no I was not aware the manual was updated
<bvernoux>
I have my own readme.txt to build on windows
<bvernoux>
which is very easy
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jkgmf
<_whitenotifier-f>
[scopehal-apps] azonenberg 9ae0ff2 - Updated to latest scopehal
<bvernoux>
with lot of part from the manual
<azonenberg>
The manual is being updated pretty frequently
<azonenberg>
at least with critical build info
<azonenberg>
docs on specific filters and UI updates are lagging a bit just because there's only so many hours in th eday
<bvernoux>
nice
<bvernoux>
ther is still the annoying 1 2 3 step for the commands
<bvernoux>
where not intuitive to copy paste ...
<bvernoux>
-where+very
<azonenberg>
BTW, any thoughts on the VSG60A?
<bvernoux>
yes for RF only it seems great
<bvernoux>
especially for the price
<azonenberg>
Yeah. i'm thinking that plus an AWG for baseband work is probably a reasonable compromise
<azonenberg>
vs an ultra expensive broadband AWG
<bvernoux>
I'm checking SIglent AWG ;)
<azonenberg>
like one of the 60 Gsps or whatever keysight ones
<bvernoux>
siglent sdg6000x is clearly amazing
<bvernoux>
it can do both RF & AWG
<bvernoux>
and can be hacked and fully unlocked ;)
<bvernoux>
they even have option to put it in rack for few USD
<bvernoux>
I know you like instrument in rack ;)
<bvernoux>
yes SDG6000x anyway is limited to max 500MHz
<bvernoux>
but can be mixed to reach multi GHz
<azonenberg>
Yeah i want to get a baseband AWG too
<azonenberg>
But i think a vector siggen would be good to have as well
<bvernoux>
I'm not happy with my Agilent E4432B anyway
<azonenberg>
i'm not sure which i really would need more urgently
<bvernoux>
for oscilloscope stuf definitely AWG I think
<bvernoux>
except if you want to validate 50 ohms RF stuff with oscilloscope which is a bit overkill I think
<bvernoux>
as Oscilloscope are not good to replace a Spectrum Analyzer for that ;)
<bvernoux>
or they are clearly too expensive
<azonenberg>
Well i also want a specan :p
<bvernoux>
Dynamic Range will be always an issue with oscilloscope vs Spectrum Analyzer for >GHz RF signal ...
<bvernoux>
so I'm checking SDG6022X for <1500USD ;)
<azonenberg>
I want a SM200C
<bvernoux>
which can be unlocked to full features AWG+RF(IQ) by software ;)
<bvernoux>
ha yes this one is a beast
<azonenberg>
and the SDG6000x doesnt upconvert right?
<bvernoux>
no
<azonenberg>
it only does baseband but you can add to an external mixer?
<bvernoux>
you need external upconverter for RF stuff
<bvernoux>
>500MHz
<bvernoux>
yes it shall work fine with an external mixer
<bvernoux>
and a good source
<bvernoux>
good clock
<azonenberg>
yeah see that was why i wanted a vector siggen, since for RF i would probably want calibrated performance at the RF side
<bvernoux>
SDG6000X is vector siggen
<bvernoux>
just limited to 500MHz
<azonenberg>
i mean RF vector not baseband
<bvernoux>
and it has latest DAC 16bits
<bvernoux>
totally amazing for the price
<azonenberg>
whereas if i use an external mixer now i have to correct for losses in the cabling and other stuff
<azonenberg>
Yeah i like it
<bvernoux>
2.4GSa/s
<azonenberg>
i had been eyeing some of the competing 16 bit AWGs that cost a lot more
<bvernoux>
and the fun is Teledyne resell the Siglent SDG6000X on their brand ;)
<bvernoux>
exactly the SIglent ;)
<bvernoux>
but the price is 2x more hahaha
<azonenberg>
That's a T3AFG right?
<azonenberg>
but the T3AWG is a lecroy in house design?
<bvernoux>
yes
<azonenberg>
(i dont see a siglent that looks like it)
<azonenberg>
T3AWG is a completely different instrument
<bvernoux>
ha yes I speak about T3AFG
<bvernoux>
let's check T3AWG
<azonenberg>
It's the Active Technologies AWG-5000
<azonenberg>
or similar
<bvernoux>
ha yes T3AWG is totally an other instrument
<azonenberg>
I had been considering the T3AWG3352
<azonenberg>
but at the time was unable to find the OEM
<bvernoux>
I doubt it beat SDG6000X except maybe less noise but I really doubt
<bvernoux>
and SDG6000X is 10x less expensive
<azonenberg>
Look up the Active Technologies AWG5062
<azonenberg>
16 bit, 6.16 Gsps, 2 GHz max
<bvernoux>
ha yes
<azonenberg>
(This is better than the T3AWG)
<bvernoux>
this one is better on paper
<bvernoux>
but I think it is ultra expensive
<azonenberg>
Yeah i'm trying to see if i can find at least a list price
<bvernoux>
when you can buy a SDG6000X which is amazing + external mixer for RF stuff >500MHz ;)
<bvernoux>
which can be probably added on the same rack ;)
<bvernoux>
but clearly ARB Rider AWG-5000 is an other beast
<bvernoux>
not comparable ;)
<azonenberg>
That's the class of instrument i really want to get. The question is will i be best off waiting until i can afford one
<bvernoux>
I imagine the price >20KUSD ;)
<azonenberg>
or buying a cheap siglent or something in the meantime, so i at least have something?
<azonenberg>
Considering the T3AWG is based on a lower end ArbRider, and that's $13K MSRP i think? for 350 MHz
<azonenberg>
yes
<bvernoux>
I think you can start with a cheap Siglent SDG6000x as it is 20x less expensive and you can always sell it later
<bvernoux>
big advantage is you can unlock it ;)
<bvernoux>
so it is ultra cheap for the feature at end
<azonenberg>
also you can tell siglent and active tech are all lecroy partners
<azonenberg>
every screenshot they have of their products' waveforms is on a lecroy scope lol
<azonenberg>
The other option rather than one of those new would be looking at refurbs
<azonenberg>
last time i looked at used AWGs i didnt see much good though
<azonenberg>
bvernoux: So i'm wondering if it might make sense to get a SDG6052x *and* a VSG60A
<bvernoux>
yes good question
<bvernoux>
I think maybe VGS60A is better as software are better to generate any signals easily ...
<bvernoux>
I doubt Siglent have amazing software like SignalHound
<bvernoux>
SignalHound have amazing Hardware and especially some very advanced (free) software working on Windows/Linux ...
<azonenberg>
Yeah
<azonenberg>
If i got a SDG6052 i wouldn't be using it for i/q probably
<azonenberg>
i would be using it for baseband only
<azonenberg>
i wish signalhound made a baseband awg lol
<azonenberg>
i'd buy it
<bvernoux>
woo it is crazy PNCS-1 Phase Noise Clock Standard => Note: This product is only available for sale within the United States.
<bvernoux>
Why only USA ?
<bvernoux>
because of Trump ?
<bvernoux>
Totally crazy
<azonenberg>
No, it's probably export controls
<bvernoux>
I have not tested my EMC Near-field Probe Set with 40 dB Wideband Amplifier from TekBox ;)
<bvernoux>
I should check it work fine
<azonenberg>
also it's amazing how big the xcvu9p is
<azonenberg>
i just recompiled my 10G ethernet switch prototype design in vivado 2020.1
<bvernoux>
with CRC32 in // ?
<azonenberg>
this is my old switch core, nothing to do with the 40G stuff i'm working on now
<azonenberg>
It's 42K LUTs which is ... 3.62% of the fpga
<azonenberg>
meanwhile it would be ~45% of the xck7k160t
<bvernoux>
41KEuros the FPGA
<azonenberg>
The 40G IP stack is going to run on a kintex-7, xc7k160t-2ffg676c
<d1b2>
<daveshah> You can get 'bitcoin' vu9p boards (vcu1525 design) for $1k...
<azonenberg>
daveshah: I'm using a pair of vcu118s that i had left over from a consulting gig some years ago
<bvernoux>
yes on FPGA which cost >300euros ;)
<azonenberg>
bvernoux: anyway, for that fpga i actually managed to get the 40G CRC to run without any weird parallel tricks
<azonenberg>
i can do a 128 bit CRC32 in one clock cycle
<bvernoux>
ha great
<azonenberg>
i did have to add some pipelining to the end for processing partial data words
<azonenberg>
at the moment the total latency of my stack from XLGMII-128 start symbol until the layer-4 protocol sees the first full 16-byte word of data (not including SERDES or PCS latency)
<azonenberg>
is 16 clocks at 312.5 MHz or 51.2 ns
<bvernoux>
ha very nice
<azonenberg>
this includes the MAC, the ethernet frame parsing and vlan tag stripping (if any), and IPv4
<azonenberg>
RX only, no TX logic yet
<azonenberg>
no ipv6 yet
<bvernoux>
I'm not sure IPv6 is required for such things
<bvernoux>
it will add overhead for nothing
<azonenberg>
1839 LUT so far
<azonenberg>
I intend to write it eventually but probably not in the initial firmware
<bvernoux>
yes IPV4 warranty things are simpler faster especially for the latency ;)
<azonenberg>
Anyway, i still have plenty of room in the fpga, so far my stack is just under 2% of the chip
<bvernoux>
and it is mainly for local network to use the 40Gbit/s ;)
<bvernoux>
until you have direct fiber optic with ethernet ;)
<azonenberg>
but i have to fit the TX logic, all of the TCP/UDP/ARP/ICMP code still
<azonenberg>
the compression engines and associated fifos
<azonenberg>
application layer protocol logic
<azonenberg>
triggering
<azonenberg>
and a 64-bit ddr3 controller
<azonenberg>
So this is going to be a very full fpga
<bvernoux>
the idea is to use that with glscopeclient correct ?
<bvernoux>
so very specific to that
<azonenberg>
Yes
<azonenberg>
Also, glscopeclient is going to be getting a single lane pcie gen2 protocol decode soonish
<bvernoux>
in that case you can just add minimal stuff like IP/UDP ...
<azonenberg>
I want to use TCP for various reasons
<azonenberg>
the alternative would be basically reimplementing TCP inside UDP
<bvernoux>
because TCP add lot of latencies and complex things to manage ...
<azonenberg>
Anyway i have a raspberry pi4 arriving in a few hours and need a test subject for my shiny new diff probe
<azonenberg>
So i'm gonna try sniffing the pcie and writing a decode
<bvernoux>
ha nice
<bvernoux>
latest rpi4 have PCIe available ?
<azonenberg>
the usb3 chip is pcie attached
<azonenberg>
there are popular mods that remove the usb3 chip and jumper the pcie lanes to the usb lanes and then use an adapter cable to get external pcie
<bvernoux>
ha yes interesting for a cheap board to test very high speed signals ;)
<azonenberg>
but in my case i would want to just stick a diff probe across the pcie diffpairs
<azonenberg>
and see what i can see
<bvernoux>
yes clearly a very good test to see if the diff probe are fine with all the chains ;)
<bvernoux>
I'm still testing NanoVNA 2.4plus ;)
<bvernoux>
to compare it vs a real VNA ;)
<bvernoux>
and it has better than 90dB noise floor !!
<bvernoux>
Amazing for such cheap product
<azonenberg>
Niice
<azonenberg>
marshallh: you were asking about the nanovna? ^^
<bvernoux>
with crappy calibration things provided with it ;)
<bvernoux>
I will do a full comparison with using great calibration too ;)
<bvernoux>
but that take time
* azonenberg
imagines bvernoux using a nanovna with a super fancy maury microwave cal kit
<azonenberg>
and maybe a sliding load
<bvernoux>
I have already some test with JFW Model 50BR ;)
<bvernoux>
it is attenuator from 0 to 110dB ;)
<bvernoux>
a must have
<bvernoux>
very clean up to 3.5GHz
<bvernoux>
perfect to check dynamic range ...
<bvernoux>
I'm waiting some sharp filter too, to check extreme case where we see the old VNA are better than NanoVNA2 ;)
<bvernoux>
also a big difference NanoVNA2 is just T/R vs my old HP VNA which is Full 2-port ;)
<marshallh>
yeah i ordered a couple nanovna2's
<marshallh>
ah yeah i dont think it does s12/s22
<bvernoux>
I also plan to upgrade the MCU GD32F303CCT6 by STM32L4P5CGT6 ;)
<bvernoux>
it is fully compatible
<marshallh>
cool
<bvernoux>
and STM32L4P are really better
<marshallh>
i am just trying to make a bluetooth pcb antenna, lol
<bvernoux>
better ADC, plenty of flash and RAM to have >1601pts in live ;)
<marshallh>
i got into qualcomm's dev program and have all the stuff on their bluetooth chips
<bvernoux>
as actual version is limited to 201pts on live measurement which is very bad
<bvernoux>
because of lack of ram
<azonenberg>
marshallh: traitor :p
<bvernoux>
the one which I have is NanoVNA V2 Plus4
<bvernoux>
yes 201pts is a joke for mesurements ;)
<azonenberg>
marshallh: qcom is up there with marvell, vitesse, and broadcom on the list of companies i refuse to do business with because of their anti-engineer practices
<bvernoux>
I always use 1601pts
<marshallh>
you wouldn't believe the level of red tape and hassle it was to get in
<azonenberg>
oh i would
<azonenberg>
i didnt even try
<azonenberg>
when you make it that hard for people to use your products, i honor your wishes
<marshallh>
and the acutal info from the CSR buyout... well, some of it is lost/not archive
<bvernoux>
with Type N connector strange
<azonenberg>
And i don't use your products :p
<bvernoux>
I prefer SMA ;)
<marshallh>
yeah i got a backup unit with SMA also
<azonenberg>
bvernoux: i usually use 10k points on my picovna and that's because it's the max they can do :p
<azonenberg>
normally when i'm doing vna measurements i don't need ultra fast sweep speeds
<azonenberg>
i want a lot of data and the more points the merrier
<azonenberg>
especially when doing de-embeds etc
<bvernoux>
azonenberg, yes more is always better but on my HP VNA i'm limited by the speed and memory too so 1601pts with full s2p calibration ;)
<marshallh>
hmm only $5995
<marshallh>
a dollar per mhz :)
<azonenberg>
but then again i am also usually sweeping from 300 kHz to 6 GHz
<azonenberg>
marshallh: what, picovna?
<marshallh>
yeah
<azonenberg>
Don't buy it
<azonenberg>
:p
<azonenberg>
I'm seriously considering getting rid of mine, i just havent found something i'm confident will be less painful to use yet
<marshallh>
I just need to charcterize the antenna and build a matching network for it
<azonenberg>
since i can feed it directly into my sma fixtures
<bvernoux>
and use the adaptor ;)
<azonenberg>
Re the adapter, i currently have two SMA jack - BNC plug versions of that adapter
<azonenberg>
I love them, and i want more
<bvernoux>
even if it cost 2 times more it is better for future
<azonenberg>
i plan to purge all of my other cheap ones
<bvernoux>
and it has 30ps pulse
<azonenberg>
i also have some cheap SMA plug - BNC jack adapters i want to get rid of
<azonenberg>
I also want to get some nicer terminators
<marshallh>
yeah i have that BNC pulse gen
<bvernoux>
the 2.92mm pulse gen is even better ;)
<bvernoux>
but 2.92mm is fragile vs SMA
<bvernoux>
I'm afraid to break it easily
<azonenberg>
Yeah
<azonenberg>
I plan to skip 3.5mm for my projects, I think
<azonenberg>
It seems to be a bit of a niche connector
<azonenberg>
high grade SMAs go to 26.5 GHz
<azonenberg>
and if you need higher go to 2.92
<bvernoux>
yes high grade SMA are more robust I think too
<azonenberg>
NeroTHz doesnt like them
Bird|ghosted has joined #scopehal
<bvernoux>
ha ?
<azonenberg>
he prefers 2.92 and says they're actually more sturdy than SMA
<bvernoux>
yes but as which price ;)
<azonenberg>
his reasoning is that 2.92 is designed so the pin and socket don't engage until the connector nut has engaged several threads and is well aligned
<azonenberg>
while with SMA there's a flaw, the pin mates first
<marshallh>
Very cool
<azonenberg>
so if you're not aligned well you can bend it
<bvernoux>
yes it is interesting
<marshallh>
is V2Plus4 still rendering low-res smith chart? can it display high-res? since display seems to be 800x480
<marshallh>
maybe framebuffer size limit?
<bvernoux>
so far I have few 2.92mm but my issue was more related to center pin of the SouthWest Microwave which is not good
Bird|otherbox has quit [Ping timeout: 264 seconds]
<bvernoux>
at the end they shall be soldered to work correctly what a shame for such expensive connectors
<bvernoux>
they are all 2.92mm ;)
<bvernoux>
I only use minicircuits SMA cable for that
<azonenberg>
Yeah right now i have two N cables (the VNA test leads)
<azonenberg>
then some older BNC-to-whatever cables i bought for interfacing with my scope
<azonenberg>
I'm probably going to be retiring those as at least some of them have detectable impedance mismatches at the BNC side of the connection
<azonenberg>
while the SMA-SMA ones made by the same vendor on the same cable are fine
<bvernoux>
ok so let's buy that amazing Leobodnar "Fast risetime pulse generator (2.92mm output)" ;)
<azonenberg>
Pretty much I'm standardizing on high grade SMAs for everything, then using adapters as needed
<azonenberg>
i still need to find a good longer cable
<azonenberg>
the minicircuits FL086-24SM+ is nice but a little bit stiffer than i'd like, and only available up to 2 feet in length
<azonenberg>
its too stiff to use with a probe comfortably IMO
<azonenberg>
but great for test fixtures to scopes
<azonenberg>
then the Crystek semi-rigid is awesome
<bvernoux>
I plan to buy 2x CBL-1FT-SMSM+
<azonenberg>
I've heard semirigid has a limited life but so far all of the semirigid i've VNA'd has still been in spec
<bvernoux>
and 4x FL086-24SM+
<azonenberg>
even despite having been bent a bunch of times