<bvernoux>
Issue with 2.92mm connector is they are very "fragile"
<bvernoux>
any mistake and you can trash it ...
<azonenberg>
For the time being my lab is going to continue to use SMA as the primary connector
<azonenberg>
I will mate these SMA-2.92 adapters to the ProLink-2.92 adapters as soon as they arrive
<azonenberg>
and leave them mated semi-permanently
<bvernoux>
ha yes in that case it is great
<azonenberg>
So i'll pretend it's ProLink - SMA
<azonenberg>
the thing is, the ProLink-SMA adapter costs about $100 more than the ProLink-2.92
<azonenberg>
And a SMA-2.92 adapter is about $100
<bvernoux>
as the danger is to connect/disconnect 2.92mm too much with high risk to destroy it especially internally it is very "fragile" compared to SMA
<azonenberg>
So for the same price i can upgrade to 2.92 in the future
<azonenberg>
and not have to buy a new adapter
<azonenberg>
And actually from what some other RF folks tell me 2.92 and 3.5 are actually more robust in a way
<azonenberg>
because they don't mate the center pin until the threads are engaged several turns
<azonenberg>
SMA mates the center pin first, so if misaligned it can bend
<bvernoux>
The probe tip does not seems to impressive for 13GHz
<bvernoux>
Does it can be replaced ?
<azonenberg>
which one?
<azonenberg>
the SI tip resistors can be replaced, they include i think five spares with each of the two tips
<azonenberg>
the PT tip is only rated for 10 GHz
<azonenberg>
they include several spare pogos and two spare sockets
<bvernoux>
ha ok
<azonenberg>
and the SP tip is only rated for 3 GHz
<azonenberg>
including that with the 13 GHz diff amplifier seems stupid :p
<azonenberg>
That's the SI tip
<azonenberg>
the full bandwidth one
<bvernoux>
ha ok it is the one which can reach 13GHz
<azonenberg>
i havent checked what the Dx30-SI costs but the Dx20-SI for my 4 GHz probe retails for $800ish at digikey
<azonenberg>
they're almost identical construction
<azonenberg>
probably just the 30 is a lower loss material or something
<azonenberg>
but yes it's fragile, they ship it in a plastic tray as you saw i nthe overview photo
<azonenberg>
i'm keeping it in the tray for its own protection
<bvernoux>
Will be interesting to compare that probe to your latest results on your passive probes
<bvernoux>
When do you plan to receive your new scope >+10GHz BW IIRC ?
<azonenberg>
Monday
<azonenberg>
16 GHz, SDA 816Zi
<azonenberg>
it's on a fedex truck halfway between lecroy's factory and me now
<azonenberg>
the probe outran it
<azonenberg>
the rack kit was in the same box as the probe so i've got that already too
<bvernoux>
ha great
<azonenberg>
That is the only thing left for the AKL-PT2 to be ready, pretty much. I wanted to get some rise time measurements
<azonenberg>
But I may delay a few more days
<azonenberg>
because the new test fixture is expected to ship on Wednesday
<azonenberg>
so by the end of next week i should have that
<azonenberg>
I might re-measure some of the probes and see if i get more repeatable S21 measurements from that
<azonenberg>
in any case though i have 20 assembled probes, boards to make over 200 more, and about 30 more boards worth of SMAs
<azonenberg>
i forget exactly how many resistors i have but i can start producing them in fairly significant quantity as soon as i have the full characterization pipeline worked out
<bvernoux>
Will be interesting to checl AKL-PT2 with the 16GHz scope
<bvernoux>
check
<bvernoux>
you need a good clean sig Gen to test with freq up to 16GHz
<bvernoux>
I'm planning to build one ;)
<bvernoux>
mine are limited to 8GHz to far
<bvernoux>
I can basicaly check Power Level of basic signal up to 20GHz with +/2dB accuracy
<bvernoux>
but I can also use my Spectrum Analyzer up to 14GHz
<bvernoux>
I'm clearly thinking to buy a Realtime Spectrum Analyzer like SM200C it is a must have for advanced features and Spike is a must have to check EMC precompliance without buying expensive option as it is available free
<bvernoux>
Also thinking to buy a high end scope extensible to 6GHz+ like Tek MSO64B ;)
<bvernoux>
But they do not have such refurbished they are too new
<bvernoux>
I'm interested to check Eye diagram on USB 2.0 HS too
<bvernoux>
Could be possible to do that on my Rigol MSO5k and glscopeclient but Rigol MSO5k are so slow so far with SCPI ...
<bvernoux>
Also I cannot do that with diff pair I could test only D+ or D- as the BW is about 500MHz only on 1 chan
m4ssi has quit [Remote host closed the connection]
maartenBE has quit [Ping timeout: 240 seconds]
<azonenberg>
Yeah i need to work on usb eye patterns in glscopeclient
<azonenberg>
i havent tried yet but i'm pretty sure it will be tricky because the packets start and stop and the line goes idle between
<azonenberg>
so i dont think my current cdr pll will work
<azonenberg>
I'm going to have to build something separate
azonenberg_work has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
Guest90458 is now known as Error_404
Error_404 is now known as Guest55843
Guest55843 is now known as Error_404
azonenberg_work has joined #scopehal
azonenberg_work has quit [Ping timeout: 250 seconds]
<d1b2>
<mubes> @azonenberg; Quick Q if I may. How does SCPISocketTransport::readReply know when a packet is complete? It seems to rely on \n or ;, but when collecting raw data (e.g. wavedescs or a sample buffer) how does it know that it's finished? I'm using LeCroyOscilloscope.cpp for reference and everything is now done & seems to be working apart from the binary transfers...I think I'm missing something.
<miek>
@mubes use ReadRawData instead, that takes a length
<d1b2>
<mubes> Yeah, that's what I'm looking at.... but I'm confused how anything could have worked...and it obviously did 🙂 So what did I miss?
<azonenberg>
mubes: there is actually a separate method for reading raw data blobs in scpi format
<azonenberg>
iirc
<azonenberg>
But yes, for the most part you will want to use ReadRawData() for anything with a fixed length
<azonenberg>
ReadReply() is for scpi text commands
<d1b2>
<mubes> Ah, OK. I just brewed something that reads the header and then collects the data...works fine for wavedescs, let's see if it works for data 🙂
<azonenberg>
this is because of scpi's ugliness of having in-band data and control on the same stream
<azonenberg>
rather than having a control and data plane socket which would make a lot more sense
<d1b2>
<mubes> I am using the ReadRawData to get the header, followed by a second call to get the content
<azonenberg>
Yes
<d1b2>
<mubes> (So many of these protocols need lessons in basic datacomms....very irritating)
<azonenberg>
that's what's typically done
<azonenberg>
They do, it's annoying. what annoys me more is that scpi scopes are normally polling based
<d1b2>
<mubes> Yup!
<azonenberg>
if you look at the PicoOscillscope class, i wrote my own transport layer over TCP that bridges Pico's API over LAN
<azonenberg>
this is a much saner protocol i will probably use a very similar form of for my own fpga-based scopes
<miek>
i think the confusion is that the lecroy driver seems to be using ReadReply to read raw data, and somehow doesn't break?
<d1b2>
<mubes> Don't ever go near the arm debug protocols. I doubt they can spell 'Layer'.
<azonenberg>
miek: So the reason for that is probably that the lecroy driver uses VICP
<azonenberg>
Which internally has length framing on every "packet" which is typically one scpi data block
<d1b2>
<mubes> @miek Yeah, that's the bits thats confudsing me!
<miek>
aha
<azonenberg>
none of the other scpi transports do this
<azonenberg>
and all of the siglent scopes use raw scpi not vicp
<d1b2>
<mubes> So the siglents would have broken using the LeCroy driver?
<d1b2>
<mubes> I don't mind fixing stuff, but sometimes it just means I haven't understood something.
<azonenberg>
AcquireData() was subclassed in SiglentOscilloscope for exactly this reason
<d1b2>
<mubes> OK, I'll crack on
<azonenberg>
But now many of the other methods have bitrotted away too
<azonenberg>
Hence why i'm trying to make a clean break between the drivers
<azonenberg>
i.e. siglent should no longer be derived from lecroy
<d1b2>
<mubes> TBH that 'old' Siglent stuff will fade into the background eventually. The new scopes are all using the new protocol stack....which isn't that robust yet.
<azonenberg>
newer siglents use the lecroy-compatible protocol? are they windows ce based ?
<azonenberg>
like, with com and everything?
<d1b2>
<mubes> Siglents until the SDS2000X+ seem to use the LeCroy stack. The SDS2000X+, SDS5000 and SDS6000 all explicitly use this new unified firmware
<azonenberg>
my understanding was only the wavesurfer 3000 series, and the siglent 3000 series equivalent, called that
<azonenberg>
Interesting
azonenberg_work has joined #scopehal
<d1b2>
<mubes> (which is why it's worth the effort)
<azonenberg>
So maybe we will want to have two different siglent drivers or something?
<d1b2>
<mubes> We do at the moment 🙂
<azonenberg>
or use the lecroy driver for some and a separate siglent driver for the others?
<azonenberg>
not exactly
<azonenberg>
right now we have a lecroy driver that may work with some siglents
<azonenberg>
and a driver called siglent that doesnt work
<azonenberg>
on anything
<azonenberg>
:p
<d1b2>
<mubes> We can select the correct stack based on scope ID, but I've kept it partitioned for now to avoid breaking anything unintentionally
<d1b2>
<mubes> There's some irritating stuff missing out the new SCPI stack too...no way to tell if you've received a trigger since last time you checked, for example.
<azonenberg>
eeew
<d1b2>
<mubes> Well, that I've found, anyway
<azonenberg>
see, that's what my own protocol does properly
<azonenberg>
it's *push* based
<d1b2>
<mubes> Mmmmm
<azonenberg>
by enable channels you "subscribe" to notifications
<azonenberg>
then on the data plane socket you get a header plus a bunch of channel data ever trigger
<azonenberg>
which you can read at your leisure
<d1b2>
<mubes> Yeah, they've not even implemented *OPT? or *INR
<azonenberg>
lovely
<d1b2>
<mubes> ...unless they've hidden it really well.
<d1b2>
<mubes> anyway, back to it...
<monochroma>
find buffer overflow, hotpatch better driver in