electronic_eel has quit [Read error: Connection reset by peer]
electronic_eel has joined #scopehal
<azonenberg>
(23:03:47) azonenberg: Using the SMA pulse generator in real time 40 Gsps mode I get <27.5 and <40.3 ps
<azonenberg>
(23:04:10) azonenberg: and in equivalent time 200 Gsps mode, 23.7 / 34.2
<azonenberg>
So that was the performance i saw with the 16G scope and i think the 40ps pulse gen, going into a 12 inch cable
<azonenberg>
now, using the SMA output pulse gen right into the scope via a LPA-K-A adapter, I get <26.5 and <38.4 in real time, and 23.04 / 33.01 20-80 / 10-90
<azonenberg>
The datasheet rise 10-90 is 28 ps and 10-90 is 21 ps of the scope itself
<azonenberg>
I'm very close to that through a couple of adapters
<azonenberg>
Leo's test report says 27.8 ps rise
<azonenberg>
LeoBodnar: is that rise time you quote 20-80% or 10-90%?
<azonenberg>
(and sorry datasheet rise time is 28 10-90 and 21 20-80% of the scope)
esden has quit [Ping timeout: 258 seconds]
elms has quit [Read error: Connection reset by peer]
elms has joined #scopehal
esden has joined #scopehal
<LeoBodnar>
always 10-90
<LeoBodnar>
20-80 is for digital cheats
<azonenberg>
lol
<azonenberg>
Thought so, just double checking
Tost has joined #scopehal
<azonenberg>
Sooo for the Manchester decoder
<azonenberg>
I'm trying to think what the most logical output format is
<azonenberg>
bytes?
<azonenberg>
data bits plus recovered clock?
<d1b2>
<zyp> bits sounds reasonable, you don't necessarily know where the byte boundaries are
<azonenberg>
That's kinda what i'm thinking, output a digital data stream and a clock
<azonenberg>
and then let whatever the upper level protocol is take care of the rest
<d1b2>
<mubes> For pure Manch that's all you can do...there's no explicit sync or similar...although it's often synced by protocol violation (overlong bit period etc) which makes it a pig to auto-rate-adapt to 😦
<azonenberg>
Yeah I might have to add a hint at the approximate bit rate to the filter
<azonenberg>
so it knows roughly what to expect
<azonenberg>
The plan is to take the current 10baseT filter and split off the manchester part and make it more generic
<azonenberg>
also i want to support both conventions as far as inversion goes
<_whitenotifier-5>
[scopehal] azonenberg opened issue #408: CSV import: don't choke on files with header rows at start - https://git.io/JOsaj
<_whitenotifier-5>
[scopehal] azonenberg assigned issue #408: CSV import: don't choke on files with header rows at start - https://git.io/JOsaj
<_whitenotifier-5>
[scopehal] azonenberg labeled issue #408: CSV import: don't choke on files with header rows at start - https://git.io/JOsaj
<_whitenotifier-5>
[scopehal] azonenberg opened issue #409: CSV import: load name and serial number from Digilent WaveForms CSVs - https://git.io/JOsVL
<_whitenotifier-5>
[scopehal] azonenberg labeled issue #409: CSV import: load name and serial number from Digilent WaveForms CSVs - https://git.io/JOsVL
<_whitenotifier-5>
[scopehal] azonenberg opened issue #410: Add driver for Digilent WaveForms SDK - https://git.io/JOsVK
<azonenberg>
So interesting data point... a lot of protocols on wikipedia, like MIL-STD-1553, have example waveforms and decode screenshots from early generation LeCroy scopes
<azonenberg>
They were contributed by none other than Roland Gamper, the owner (and I think the only person) at Lahniss
<azonenberg>
a small company which appears to write most of lecroy's protocol decodes
<azonenberg>
I think he's ex lecroy and they kept contracting to him
<monochroma>
heh
<azonenberg>
I knew about him/the company
<azonenberg>
but didnt realize that the wiki screenshots were actually made by the guy who wrote the decode
<azonenberg>
also speaking of 1553 I just got some sample waveforms
<azonenberg>
So i'm going to be working on that shortly
<_whitenotifier-5>
[scopehal-apps] azonenberg opened issue #313: Allow importing of multiple CSV files into a session, or adding CSVs to an existing session - https://git.io/JOsM8
<_whitenotifier-5>
[scopehal-apps] azonenberg labeled issue #313: Allow importing of multiple CSV files into a session, or adding CSVs to an existing session - https://git.io/JOsM8
<azonenberg>
but note the bottom left says "lecroy" and not "teledyne lecroy"
<azonenberg>
i define scopes as old if they were made prior to teledyne buying lecroy :p
<azonenberg>
But they're still MAUI based not the really old vxworks stuff
<azonenberg>
Which i've never personally dealt with
StM has quit [Ping timeout: 245 seconds]
<Degi>
yeah
StM has joined #scopehal
<Degi>
I have one old tektronix scope here (but its kinda broken now and doesn't boot up anymore for some reason) which is BW CRT but is still digital
<azonenberg>
yeah i've used a few scopes of that era
<azonenberg>
when i took my fpga class we had an old LA, i dont remember the brand, that was a touchscreen monochrome CRT
<Degi>
With the first generation SMD caps... lmao
<Degi>
Nice
<d1b2>
<theorbtwo> Hm, come to think of it, useful or useless: a thing that converts sigrok files to csvs suitable for loading into glscopeclient? Potentially useful for testing decoders before we have a proper capture?
<Degi>
Maybe we can have sigrok import on glscopeclient
<azonenberg>
Interop with sigrok would be good, we just can't use any GPL licensed code from sigrok itself to do it
<azonenberg>
rather than a csv converter tool i would write it as a full import tool like the csv and agilent/rigol bin importers
bvernoux has joined #scopehal
<d1b2>
<theorbtwo> Is there any infrastructure for import tools to take parameters? Sigrok files don't have voltage levels AFAIK, just on/off.
<d1b2>
<mubes> Sigrok can do analog as well as digital
<d1b2>
<theorbtwo> shrug , will just make it convert zero to 0v and one to 1v if you convert a digital file. It's not like glscopeclient can't handle add or multiply.
<miek>
scopehal's got a DigitalWaveform type for that
m4ssi has joined #scopehal
<d1b2>
<mubes> Yeah, deffo pull it in as a digital channel for that case, otherwise the digital tools won't recognise it as such and you'll have to threshold it before you can use it.
<d1b2>
<theorbtwo> Oooh.
bgamari_ is now known as bgamari
juli969 has joined #scopehal
smkz has quit [Quit: smkz]
smkz has joined #scopehal
Tost has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
m4ssi has quit [Read error: Connection reset by peer]
massi_ has joined #scopehal
<azonenberg>
There is not currently infrastructure for parameters, but yeah - if you have digital input, parse it as a digital channel for sure
<azonenberg>
mubes: also did you see the email chain from jason at siglent?
<d1b2>
<mubes> Yup, just about to reply. Will cc you. Good forward progress.
<azonenberg>
And I just got a ping from Digilent who wants to send me their new model analog discovery platform
<azonenberg>
seems all of the smaller hardware vendors are getting interested lol
<d1b2>
<mubes> Well, it's generally better software than what the majority of the vendors ship...especially on the analysis side.
<azonenberg>
Exactly
<azonenberg>
my long term dream is for proprietary scope apps to not be a thing
<azonenberg>
vendors will write and upstream a libscopehal driver instead
<azonenberg>
if we can outperform the vendor tools sufficiently, we stand a good chance of doing that
<d1b2>
<mubes> Yep. I think there's work to do on the GUI side but tbh that should be the easy part (if you get the chance, cast an eye over the labnation GUI...it has a few nice ideas in there)
<azonenberg>
Yeah there is definitely work to be done on the gui side
<azonenberg>
We urgently need more gui developers
<azonenberg>
other than katharina's work on the preferences system the gui is ~100% my code
<azonenberg>
basically all of the community contributions have been on the back end in drivers and decodes
<d1b2>
<mubes> GUI developers are a very particular breed :-)
<d1b2>
<mubes> I could have sworn that labnation were going to opensourcr everything when they started off, but the GUI doesn't seem to be from what I can see.
<d1b2>
<zyp> how does the SDS2000X Plus compare to the Rigol MSO5000? are there any other options in that price range I should consider?
<d1b2>
<mubes> I'd say its miles ahead in terms of software quality etc.
<d1b2>
<mubes> RTB2004 is the other one to look at
<d1b2>
<zyp> looks nice, but a step up in price
<miek>
also i think the siglent has 50ohm inputs while the rigol doesn't?
<d1b2>
<zyp> yeah, I get the impression that the siglent is overall better, but the rigol is cheaper and thus more bang for the buck
<d1b2>
<zyp> and either should be a decent improvement over my 13 year old rigol DS1042C
<d1b2>
<mubes> Noise performance is much better on the Siglent, software support is better too although I hear there's a new release planned for the Rigol
<d1b2>
<mubes> I have the RTB2004, SDS2104X and a Keysight MSOX4...my preference is the SDS2104X. Keysight is much faster and the RTB screen is a killer, but it's just easy to like the SDS and it's a lot cheaper than either of the others.
<d1b2>
<mubes> Lack of 50R on RTB makes it more of a toy, but they're both limited to 350MHz so you can live with external termination...and easier to fix when you accidentially connect to a high voltage source 50R turned on (which is how I got my MSOX4...someone had blown out Ch1 doing exactly that)
<d1b2>
<mubes> SDS (claims to) decode 20Mbps UART too...RTB is limited to 3M5 and KS to 12M IIRC.
<azonenberg>
mubes: meanwhile glscopeclient will decode Gbps UART if you can produce a suitable signal
<azonenberg>
actually, i kinda want to try that now
<azonenberg>
get an fpga serdes and bypass the 8b10b/64b66b coder
<azonenberg>
and send uart at like 2.5 Gbaud
<d1b2>
<zyp> yeah, I'm not too worried about built-in decoders
<azonenberg>
then decode with glscopeclient for the lulz
<d1b2>
<mubes> I was, until about a week ago 🙂
<d1b2>
<zyp> although I don't have anything that can actually run glscopeclient yet
<azonenberg>
zyp: what do you have?
<azonenberg>
scope wise
<d1b2>
<zyp> no, I meant host wise, macos doesn't do opengl past 4.1 and debian buster doesn't ship a new enough mesa for 10th gen igpu
<azonenberg>
Oh
<azonenberg>
backports?
<azonenberg>
on laptops i find i normally have to run backported kernels as drivers in the debian stable kernel tend to be too old
<d1b2>
<zyp> nope, and with a new debian stable coming in a few months I'm just gonna wait
<azonenberg>
oh new stable coming out soon? i feel like buster was just released lol
<azonenberg>
this is why i run debian - security patches are already enough of a headache
<azonenberg>
i dont need new major versions coming out more than every couple of years
<d1b2>
<zyp> yeah, same
<d1b2>
<zyp> I lost a plane once because I had to wait for a friend to fix some arch breakage before we could go
<d1b2>
<zyp> I'm not interested in wasting time on that 🙂
<azonenberg>
lol
<azonenberg>
yeah i normally wait about 3-6 months after a new debian stable release to get the initial bugs worked out in mass deployment
<azonenberg>
then upgrade one or two machines
<azonenberg>
if that goes well everything elsse
<azonenberg>
Between laptops, desktops, pi's, servers, etc I've got about 20 physical debian/raspbian installs in my environment
<azonenberg>
adding in virtual machines it's somewhere around 34 active, plus six more that I spin up as needed
<d1b2>
<mubes> Increasingly looking enviously at the *BSDs for that kind of stability and longevity
<azonenberg>
then two centos vms, a few windows vms, the scopes... its not a small environment
<azonenberg>
and upgrading this much hardware is not something you do in an hour
<azonenberg>
even monthly patching is an hour or so of work
<azonenberg>
lab-wide OS upgrades are a good chunk of a day including the inevitable breakage
<azonenberg>
if not more
<d1b2>
<zyp> I don't got that much physical hardware
<azonenberg>
but yeah ideally i would like an OS that is stable enough i can deploy it when i build the machine/vm
<azonenberg>
and keep one OS/software version through the entire lifecycle of the system
<azonenberg>
applying security patches only, and new apps if i have a critical feature
<azonenberg>
otherwise it will just keep doing its thing for 5+ years
<d1b2>
<zyp> I've containerized most stuff that fits in a container, and that all fits on a single server
<azonenberg>
The majority of my stuff runs in a single xen server
<d1b2>
<zyp> containers are a lot less hassle than dealing with VMs
<azonenberg>
but i also have a desktop for me and the wife, another in the lab
<azonenberg>
a bunch of pi's
<azonenberg>
the storage cluster is three physical servers
<azonenberg>
the work laptop is included in that list because i update it on my normal home patch cycle
<d1b2>
<zyp> the server running the containers also got a 16 drive zfs array
<d1b2>
<zyp> so it's pretty much taking care of everything headless
<azonenberg>
ah ok. yeah i went with a separate ceph cluster to get more performance and better redundancy against drive failures etc
<azonenberg>
so i have 3x 10G NICs to the storage array
<azonenberg>
super nice for working with large waveform datasets with hundreds of waveforms in history etc
<d1b2>
<zyp> true
<azonenberg>
then i use dedicated pi's for public DNS and WWW in the DMZ, physically separate infrastructure
<azonenberg>
so no chance of a hypervisor exploit etc allowing someone to break out from them and compromise something i care about
<azonenberg>
i have a few more pi's for various monitoring applications around the house where physical proximity to sensors/actuation is needed
<d1b2>
<zyp> I think when the current server is due for replacement I might go for some multi-node setup with ceph for storage and some sort of kubernetes to take care of what runs where and failover and whatever so I can treat each single node as disposable
<azonenberg>
e.g. checking for water leaks in the basement
<azonenberg>
well in my case i have the single xen box, the 3 ceph nodes
<azonenberg>
then most of the other machines are either embedded platforms or otherwise site specific
<azonenberg>
e.g. desktop in the office, desktop in the lab, TV media system
<azonenberg>
i've pretty much consolidated what i can into VMs already
Tost has quit [Ping timeout: 252 seconds]
massi_ has quit [Remote host closed the connection]
<azonenberg>
And just got confirmation from digilent that the scope they're sending me has shipped. In addition to USB access via the SDK they also give you direct access to the on-device Linux OS
<azonenberg>
which is a first of any scope i've seen to date
<azonenberg>
This would let us run our dual socket protocol directly on the instrument
<azonenberg>
Guessing it's zynq based but not sure yet
<d1b2>
<mubes> That should be pretty shifty
<azonenberg>
So now we have three smaller instrument vendors taking active steps to support the project :)
<d1b2>
<mubes> If you can't play on the playing field with the big boys, move the playing field.
<d1b2>
<mubes> In each case the key to high quality support is the quality (speed, robustness, flexibility etc) of the offboard interface.