<d1b2>
<MP> @azonenberg watched your talk and started using your tool - absolutely amazing! Dashed off a few emails to folks at the usual suspect manufacturers this AM telling them in no uncertain terms that going forward compatibility with your software would be a major purchasing decision (we buy enough every year that they care about that) . Love it ! [and love the fact that the business model of holding customers over a barrel for software decoders is
<d1b2>
about to get real hard as is vendor lock in] . Would love to contribute if you need anything and assign some hardware/software engineers from my team to contribute to this
<azonenberg>
Awesome, glad to hear. At this point the #1 need is probably GUI work
<azonenberg>
With a close second being documentation
<azonenberg>
i'm basically the only person doing frontend work and i wrote the vast majority of the docs
<azonenberg>
We have a bunch of people doing good work on the back end with instrument driver stuff, not that i'd complain about help there too
<azonenberg>
And of course there's always room to do more work on decodes and analysis etc
<azonenberg>
MP: If you have any engineers interested in helping out, please have them drop in the channel here and we can talk about what tickets make sense for them to get started on
<azonenberg>
As far as vendor support, right now Siglent and Pico are the only manufacturers who are actively working with us closely, and Digilent sent along some free hardware but hasn't been super closely involved
<azonenberg>
All of the other driver work was done on our own from vendor programming guides without direct manufacturer assistance
<azonenberg>
Teledyne LeCroy has the best support/performance at the moment because that's what I run in my lab, so I have a lot of time with the equipment to find bugs and such
<azonenberg>
There's OK Tek support, at least for MSO5/6 family, but nobody is actively maintaining it AFAIK
<azonenberg>
i did all the work off a loaner/demo mso6 last year
<azonenberg>
and there is ~no support for modern keysight gear because nobody with a UXR, V-series, etc scope has been involved in the project yet
<azonenberg>
As far as good tickets to work on here's a few quick suggestions
<tnt>
MP: Compatibility is one thing, usability is another. They need to work on improving the bandwidth of the datapath from sample ram <> {network,usb} ... With a decent programming guide, drivers can be coded by anyone, but internal bottlenecks, only the vendor can work on.
<d1b2>
<MP> @azonenberg I have access to R&S's latest RTO6 , a Keysight MXR as well as plenty of MSO5/6 - my preference for device support - MSO5/6 since I have more of those than the others (it's also got the best UI) - dashed off an email specifically
<azonenberg>
Correct. Currently the winners for that are Pico (by a long shot) and LeCroy
<azonenberg>
Tek MSO5/6 performance was notably bad in my testing
<azonenberg>
i was very disappointed actually. the scpi stack also was very pedantic and frequently crashed
<azonenberg>
As far as R&S we have a somewhat bitrotted RTM3000 driver
<azonenberg>
i have no idea how similar that is to RTO6 but support for that is certainly on the wishlist as well
<d1b2>
<MP> @azonenberg @tnt i sent a very strongly worded email to various product managers this morning 😂
<azonenberg>
Nice :)
<azonenberg>
What kind of work do you do? What features are important to you?
<azonenberg>
My day job is infosec and in my spare time i do a lot of high speed serial stuff, mostly Ethernet
<azonenberg>
hence why we have decodes for everything from 10baseT to 10Gbase-R
<d1b2>
<MP> @azonenberg also excited to see you developing probes and an open source ~1GHz instrument - let me know if you need help there - have a full machine shop and have our own SMT line if there needs to be stuff made quickly
<azonenberg>
Awesome. At this point I'm just starting to gear up for scope development again after a hiatus doing other stuff
<azonenberg>
the immediate focus is going to be prototyping a single channel AD9213 based instrument with ~500 MHz frontend bandwidth, 50 ohm input only, 5 Gsps 12 bit, 1000baseT uplink with a few 6 Gbps SERDES lanes I could plausibly hook XAUI to
<d1b2>
<MP> @azonenberg i own my own consulting company - so we work on pretty much whatever customers want (a lot of consumer electronics, industrial, datacenter etc devices - and debugging pretty much everything on the planet)
<azonenberg>
this is a stepping stone to a 4/6/8 channel (depending on PCB area) 1U instrument with several copies of that same channel into a 10G SFP+
<azonenberg>
the single channel is purely a prototype and i do not intend to produce in any kind of quantity
<d1b2>
<MP> @azonenberg sick of spending literally millions for software licenses to decode stuff - when i saw your PCIE demo i about fell over.
<azonenberg>
the final one, ZENNECK, is going to be modular so you can start with as little as one channel and add channels as budget permits
<azonenberg>
The prototype will be hyper modular with frontend, ADC, and FPGA/memory on separate boards to aid development. Some of that may be consolidated in the future, TBD
<d1b2>
<MP> @azonenberg that is definitively the correct way to do it !
<azonenberg>
Then VOLLUM will be the next-gen system using the full speed AD9213 (10 Gsps vs 5), swithcing from Xilinx 7-series to UltraScale or UltraScale+ FPGAs
<azonenberg>
at least 1 GHz frontend bandwidth TBD
<azonenberg>
and MURDOCK is a proposed beast competing with major high end scopes interleaving four AD9213s to get 40 Gsps 12 bit per channel
<d1b2>
<MP> wow !
<azonenberg>
with bandwidth in the high single or low double digit GHz
<d1b2>
<MP> thats amazing
<azonenberg>
thats' a long ways out
<azonenberg>
but in general, i am not aiming to be the open source competition to Rigol and Siglent
<azonenberg>
I want to compete with Keysight, Tek, LeCroy, and R&S
<azonenberg>
maybe on the ultra high end stuff but their upper midrange for sure
<azonenberg>
maybe not*
<d1b2>
<MP> @azonenberg sign me up - happily throw engineers at this
<azonenberg>
I'll let you know when I'm ready
<azonenberg>
Near term the software is a higher priority. and probe R&D is coming along nicely
<azonenberg>
did you see my recent tweets on the AKL-PT5?
<d1b2>
<MP> I did indeed ! they look great !
<azonenberg>
I ordered 100 each of the two tip resistor values i am considering for the final design (450 and 100 ohm), all testing to date has been with 100
<azonenberg>
once that characteriztion is complete i will be ready to move into small run production (double digit quantities) of AKL-PT5s immediately
<azonenberg>
i intend to get the remainder of the mechanical design done between now and then
<azonenberg>
Also working with a couple of cable vendors trying to find the perfect cable to include with them
<azonenberg>
SMA to SMPM, highly flexible, low loss
<d1b2>
<MP> sounds perfect
<azonenberg>
And yeah as you can probably tell from glscopeclient's feature set, i am very much aiming at competing with big name vendor software options too :p
<d1b2>
<MP> @azonenberg yeah as far as passive probes the TPP 1000 (1G ) is about as good as it gets (and not truly passive)
<azonenberg>
Not quite there yet, but e.g. PCIe decoding is unheard of in the open source space otherwise
<azonenberg>
even if it only supports gen1/2 so far and isn't as polished as i want yet
<d1b2>
<MP> @azonenberg it gives us customers SO MUCH bargaining power its worth >>$$$$$$ a year to any reasonably sized team
<azonenberg>
Exactly. The small instrument vendors are starting to embrace it too
<azonenberg>
Like siglent and pico
<d1b2>
<MP> love pico !
<azonenberg>
because they realize it is such an asset to them in terms of feature parity with the big names
<d1b2>
<MP> you can tell them your software sold a couple of their scopes (which i bought specifically cause of how well they work :P)
<azonenberg>
I talk to the CEO of Pico probably once a week or so with updates on progress and discussing hardware etc
<d1b2>
<MP> hell yeah !
<d1b2>
<MP> love that the vendors are helping
<azonenberg>
No instrment vendor has yet put paid engineering time into developing glscopeclient yet
<azonenberg>
they've thrown free hardware at us, fixed bugs we've reported, and generally been helpful though
<d1b2>
<MP> @azonenberg hey if you want a sponsor , shoot me a proposal - no kidding
<azonenberg>
Long term, i want libscopehal to kill VISA
<d1b2>
<MP> fuck.visa 😂
<azonenberg>
and have it be an open standard API where it's just assumed vendors will have a driver for libscopehal shipped with new platforms
<d1b2>
<MP> pyvisa-py is a little better , but its such a nightmare for *nix
<azonenberg>
We're not there yet but pico is actively working in that direction
<azonenberg>
i'm working directly with their engineering team for support of some not-yet-announced stuff
<d1b2>
<MP> @azonenberg any concern about the scope manufacturers locking you out ?
<azonenberg>
Not to date
<d1b2>
<MP> you basically would murder their cash cow / "decoder" ransom
<azonenberg>
Yes, that is definitely a thing
<azonenberg>
But I'm also a buyer of scopes, and i'm a public enough figure on twitter etc that it would be really bad press
<azonenberg>
multiple people have openly tweeted that they've bought a scope because of good glscopeclient support
<d1b2>
<MP> "oh you already spent 100k+ on the scope ? well you can give us another 40k for the decoder or else i guess you'll have to buy another 100k scope from another vendor even through their license is only 10k" kind of shit drives me insane
<azonenberg>
pretty much every major instrument vendor is following me on twitter so i know they're paying attention
<d1b2>
<MP> @azonenberg also i about fell over again when i looked at your cross correlation feature across different scopes
<azonenberg>
Yeah that needs some fine tuning, it does not support MSO channels yet for example. And it's a bit flaky sometimes, i often miss trigger events when doing it and i'm not yet sure why
<d1b2>
<MP> can use a fast GHz class scope for the fast stuff but monitor all the lower speed serial IO with a cheap device and have them all correlated
<azonenberg>
probably a race condition somewhere
<azonenberg>
but yes that is the goal
<azonenberg>
also things like a high bit depth scope vs a high BW scope
<d1b2>
<MP> absolutely
<azonenberg>
now imagine combining it with an on-FPGA logic analyzer
<azonenberg>
for full system debug visibility
<d1b2>
<MP> yeah would be amazing
<azonenberg>
Reverse engineering the vivado ILA JTAG protocol is high on my wishlist
<azonenberg>
Being able to trigger on an ILA detection of, say, a bad ethernet frame CRC
<azonenberg>
then trace back to an analog capture of the PHY layer source of the bit error
<azonenberg>
it would be amazing for troubleshooting SI issues
<azonenberg>
This level of full system cross vendor stuff is, of course, antithetical to the lockin based business models that currently exist
<azonenberg>
But it's the kind of thing i'm aiming at
<d1b2>
<MP> yeah !
<d1b2>
<MP> also like being able to write decodes
<azonenberg>
Yeah
<azonenberg>
And chain them
<azonenberg>
for example, you can build your own decode for a proprietary serial interface that takes 8b/10b codewords as the input
<azonenberg>
all the CDR and lower level line coding stuff is already done in other filter blocks
<azonenberg>
you just turn 8b10b symbols into whatever
<d1b2>
<MP> i spent like 3 months tracing a silicon errata that caused memory to be corrupt in some rare circumstances where the same bank of memory was accessed in just the wrong way - it would manifest as corrupt display data . impossible to find and trigger on
<azonenberg>
Yeah, imagine being able to trigger on a bad image
<azonenberg>
I have a decode for MIPI DSI and DVI already
<d1b2>
<MP> yep - would have found it in an hour
<d1b2>
<MP> as opposed to many months
<d1b2>
<MP> I saw (and again about fell off my chair :P)
<azonenberg>
One thing i want to work on is software post-triggering
<azonenberg>
i.e. running the filter graph on acqusitions then filtering waveforms by some decode condition
<azonenberg>
i kinda sort ah ave the beginnings of that with the "conditional halt" feature but i want to make it better
<d1b2>
<MP> @azonenberg also like you know instead of whatever stupid embedded processor they put in these scopes , can run a nice big beefy threadripper + quadro card and just throw compute at the problem
<azonenberg>
Assuming you can get high enough WFM/s throughput, you'll be able to crunch through thousands of waveforms and only show ones of interest
<azonenberg>
Exactly
<azonenberg>
My dream scope is a 1U appliance with a bunch of SMAs on the front and a QSFP+ on the back
<d1b2>
<MP> cost of hardware <<<< cost of stupid decoder ransomware
<d1b2>
<MP> that would be about perfect
<azonenberg>
basically a JESD204 to Ethernet converter :p
<azonenberg>
And that's what my scopes are going to be
<d1b2>
<MP> maybe a bigger form factor for low speed fan cooled on bench solution + a 1U "loud as heck, but fast as fuck" solution
<azonenberg>
They won't even do frontend flatness correction or anything, most likely (I might push a bit to FPGA but we'll see)
<d1b2>
<MP> i think thats the smartest architecture
<azonenberg>
my plan is to instead just have the scope have a little flash chip storing a .s2p for each channel
<azonenberg>
that you then de-embed in software
<azonenberg>
to flatten out response of the frontend and adc
<azonenberg>
you can then cascade that with a de-embed of the probe, cable, etc to flatten response all the way to the probe tip
<d1b2>
<MP> yep
<azonenberg>
Anyway, i'm very interested in getting funded development time if you want to throw engineers at the project. Lack of time (I'm stretched between a baby, full time job, and occasional side gigs) has been the biggest reason it's not even more awesome
<d1b2>
<MP> yep!
<d1b2>
<MP> @azonenberg totally happy too - its a no brainer
<azonenberg>
Yeah the ROI is massive if you have more than a few engineers/scopes
<azonenberg>
vs buying N copies of a decoder
<d1b2>
<MP> yesp
<d1b2>
<MP> yep
<d1b2>
<MP> and honestly "make it cheaper else we write our own" is a rather delightful tool
<azonenberg>
That too :p
<azonenberg>
I'm beginning to push it internally at $dayjob and have written a bunch of decodes, like the one for SPI flash and Intel eSPI, on the job
<azonenberg>
Do you have any technical writers / engineers who can write well who are interested in helping with docs?
<d1b2>
<MP> like its something like 12k to decode SPI on a MSO6
<azonenberg>
:O
<azonenberg>
LeCroy's embedded trigger/decode package was like $2K and i thought that was exorbitant
<tnt>
wtf ?!?
<azonenberg>
that was an i2c/spi/uart/rs232 combo too
<d1b2>
<david.lenfesty> we have some internal tooling that could probably use ILA integration
<d1b2>
<MP> @tnt 3k and you only get I2C, SPI, RS- 232/422/485/UART
<d1b2>
<MP> you want CAN or I2S or like USB LS even - immediately jump up to 13k
<azonenberg>
We have fairly decent usb 1.x / 2.x support already
<azonenberg>
no superspeed yet but that's an open ticket
<d1b2>
<MP> yep
<d1b2>
<MP> @tnt point is they cripple the 3k package to the point it's a joke and force you to buy the 12k one (you dont get credit if you upgrade later btw)
<electronic_eel>
don't these decoder packs also include the data triggers? since these scopes aren't that fast in pushing the data out over ethernet, you'd still need the triggers for many kinds of debugging, even if glscopeclient can do the decode
<tnt>
yeah, probably.
<d1b2>
<MP> Yeah thats true
<d1b2>
<MP> but also with multi gigabit USB 3 - it should be fast enough for a lot of stuff
<d1b2>
<MP> especially since from @azonenberg's comments it looks like picoscope is playing ball
<electronic_eel>
yeah, pico seems currently be the fastest in pushing out data to glscopeclient. but this is still too slow for pure software triggering on some protocol detail when you have a serial line with some load on it and you are looking for some special pattern
<d1b2>
<MP> i mean you can walk into a bestbuy and buy a laptop with 64G of ram , thunderbolt and 8++ cores - as soon as pico or one of the other guys supports something faster we're fine - e.g signalhound already sells the SM200C with 10GE
<azonenberg>
yeah i still use lecroy triggering options for some stuff since it's nice
<electronic_eel>
now you can easily buy network cards with 400 GBit/s...
<azonenberg>
as far as the SM200C, adding glscopeclient support for that is also on the wishlist
<azonenberg>
i hope to buy one later in the year
<azonenberg>
do you have one already?
<d1b2>
<MP> electronic_eel - the data triggers are often kinda (to very) stupid
<d1b2>
<MP> yep
<azonenberg>
Well, i won't say no if you start developing a driver before i get one :P
<azonenberg>
I have some preliminary I/Q processing filters so far but nowhere near a full decoding pipeline
<azonenberg>
there is also spectrum support
<d1b2>
<MP> @azonenberg i'll add to the list but the scopes are definitely a higher payoff - though it would be lovely to use the SM200C to look at and decode every BLE channel
<azonenberg>
That is the kind of use case i have in mind, yes
<azonenberg>
I've also done the opposite
<azonenberg>
for my last project at $dayjob I stuck an H-field loop over the tx antenna on a DUT
<d1b2>
<MP> @azonenberg or to chain and sync three BB60C (cheaper - by half)
<d1b2>
<MP> hahaha nice
<azonenberg>
and hooked it into a DSO channel
<azonenberg>
then did digital downconversion in software
<d1b2>
<MP> lol - did you mix it down to an IF or just stuff the whole thing in ?
<azonenberg>
I pulled the full bandwidth in, it was 900 MHz so i sampled at 2.5 Gsps
<azonenberg>
then i used the glscopeclient "downconvert" filter to generate 900 MHz sin and cos waveforms and mix with it
<azonenberg>
then a FIR lowpass filter on the resulting I and Q channels to remove the 1800 MHz image and LO feedthrough, decimation to save processing time on the rest of the filter chain
<electronic_eel>
yeah, that is the nice thing about fast scopes, you don't have to mess with hardware downconversion or knowing beforhand where you frequency will be and so on...
<azonenberg>
Yeah. I have a 16 GHz LeCroy SDA
<azonenberg>
i have used it as a 16 GHz direct RF sampling receiver on occasion lol
<azonenberg>
Doesn't have the dynamic range of a real specan but if you want a buttload of bandwidth and all you have is a fast scope...
<azonenberg>
i could totally demodulate an X-band signal with it if i had to
<azonenberg>
But that's the beauty of a filter graph architecture
<azonenberg>
you don't care if the I/Q came off a SDR or a RTSA or a saved file exported from gnuradio or digital downconversion on a scope channel or whatever
<azonenberg>
it's all the same
<azonenberg>
(on that note, interop with gnuradio is also on the wishlist)
<d1b2>
<MP> yep thats one of the amazing leaps in your software - R&S kind of tries this on theirs , but yours is so much more flexible
<azonenberg>
I'm also working on adding VNA support, and filter graph blocks that work on S-parameters
<azonenberg>
as well as IBIS (kinda done) and IBIS-AMI (pending) support
<azonenberg>
so you can do full serial channel design work
<d1b2>
<MP> one of keysights lock in things has been the ADS component
<azonenberg>
here's s-params from a Sonnet simulation of an FPGA-to-SFP+ transmission line and connector launch
<d1b2>
<MP> oh thats really pretty great
<azonenberg>
loaded into glscopeclient and displayed as TDR, TDT, group delay, time domain PRBS waveform, and eye pattern
<d1b2>
<MP> wow
<azonenberg>
The tx waveform here is a simple 28ps linear rise/fall model because while i have IBIS waveform generation support
<azonenberg>
i do not have IBIS-AMI support yet
<d1b2>
<MP> still wow
<azonenberg>
and xilinx only supplies their serdes models as IBIS-AMI
<azonenberg>
but yeah i do a lot of my channel design work with Sonnet and glscopeclient now
<d1b2>
<MP> nice
<azonenberg>
You can also do this on real time data coming off an instrument
<azonenberg>
take your EM simulation of a channel and apply it to a live scope measurement
<azonenberg>
or measure a fixture on a VNA then de-embed that from your waveform
<d1b2>
<MP> yeah
<d1b2>
<MP> @azonenberg by the way keysight was trying to sell me on the UXR + even more software blood money to do this like literally last week
<azonenberg>
:D
<azonenberg>
I'm also working on adding filter graph processing to s-params
<d1b2>
<MP> which is kind of why i'm pretty amazed - its not like catch up
<azonenberg>
so for example, you will be able to measure a 2x thru on a VNA
<azonenberg>
then use a filter block in glscopeclient to split it into left and right half de-embedding networks
<d1b2>
<MP> the damn thing in your eaaarly release is threatening a pathway to feature competitive with literally the best in the world
<azonenberg>
:D
<d1b2>
<MP> 😛
<azonenberg>
I havent done that yet, i literally implemented support for filters on s-params last week and the first s-param filter will be simple ref plane extension
<azonenberg>
so just rotating phase by a constant time delay
<azonenberg>
as kind of a proof of concept for the architecture before doing anything more complex
<azonenberg>
but yes, you see what i mean about not being the open source competition to rigol? :p
<azonenberg>
Go big or go home
<azonenberg>
My open source probes are already world class passive probes
<d1b2>
<MP> agree
<d1b2>
<MP> @azonenberg how much loading does the circuit see?
<azonenberg>
And i'm working on active differential designs too :D
<azonenberg>
500 ohm DC loading. as far as RF goes... sec
<azonenberg>
blue is soldered across a CWPG on one of my own test boards
<azonenberg>
(this is without de-embedding mismatch of the connector on the fixture too)
<azonenberg>
But return loss better than -15 dB to 8.5 GHz which is the limit of my VNA
<d1b2>
<mubes> Keysight is off my shortlists (unless unavoidable) because of their no-private-sale policy. Lord knows why they've decided that's a good idea.
<tnt>
no private sale ?
<azonenberg>
tnt: I think he means they don't sell to private individuals
<azonenberg>
only to businesses
<tnt>
yeah, wasn't aware of that ... seems to be new.
<tnt>
also seems to be EU only ? Probably because of EU consumer protection (which doesn't apply to business buys).
<d1b2>
<esden> Considering all the trouble I went through EU related paperwork over the last few weeks I would love to not sell to "private" people either...
<tnt>
lol
<d1b2>
<mubes> :-)
<d1b2>
<esden> I would not have to do any of this CE UKCA work if I was only selling to companies for the use in a controlled lab.
<d1b2>
<mubes> Yep...that seems to be the logic keysight are using.
<d1b2>
<mubes> Also seems to be the basis of approval for the jlink as far as I can see.
<d1b2>
<esden> Considering that majority of their sales are to companies they figured it is not worth the effort.
<d1b2>
<mubes> I'm not sure theres not a pretty big rump of 'influencers' that are effectively private individuals though....otherwise why bother with that summer long giveaway they've been doing for the past few years.
<electronic_eel>
is that policy only for direct sales? usually you can convince some distributor to sell it to you. at least that was what i did some years ago when JBC hat a similar policy
<electronic_eel>
they dropped it since then BTW
<d1b2>
<esden> (I still would not buy directly from JBC but rather use a distributor... considering my recent experience with them)
<d1b2>
<mubes> It seems that they won't even offer warranty support for private individuals. Trouble is, in this situation, there's likely to be a lot of misinformation around, so I'm not 100% certain where the truth lies.
<electronic_eel>
@esden did you have problems with your soldering station?
<d1b2>
<esden> No I love the soldering iron. I was trying to test some of their hardware and consider a purchase. They completely screwed that process up on a dozen layers. So I don't want to deal with JBC directly based on that.
<d1b2>
<mubes> @tnt my suspicion is it's down to CE certification restrictions that can only be applied to corporate labs.
<d1b2>
<esden> JBC should fire their complete US facing sales people and hire someone competent...
<electronic_eel>
@esden ah, ok. I always bought through a distributor and also got some demos from them. always worked without issues
<electronic_eel>
them = distributor
<d1b2>
<esden> Yeah here it was a complete failure. Took months and at the end we did not get anything.
<d1b2>
<esden> Plus they wanted us to pay in advance for the "demo" hardware 🤦
<electronic_eel>
ughh.
<electronic_eel>
I got two different tip cleaners for demo, kept the better one and sent the other one back. no issues
<electronic_eel>
I can really recommend the JBC electric tip cleaners with the turning brushes btw
<d1b2>
<esden> I am glad it worked out better for you. I think the issue was the pandemic, plus some bad sales person mixed into all that. (they don't work there any more afaik)
<d1b2>
<esden> I was considering getting that mechanical brush cleaner at some point. Good to hear that it works as well as I imagine it would.
<azonenberg>
I can't comment on JBC stuff but i've had good experienecs with Hakko
<azonenberg>
including *their* motorized brush tip cleaner
<azonenberg>
and at least in the US i've had no trouble just buying direct from hakko usa
<d1b2>
<esden> I bet buying is less of an issue. I wanted to try the stuff out before buying. As they have a big BOLD "you can get demo units no strings attached" on their website.
<azonenberg>
ah ok i've never tried getting demo units from hakko
<azonenberg>
we had the same stuff at work and i liked it
<azonenberg>
so i knew exact models to buy
<azonenberg>
and just ordered them
<d1b2>
<esden> yeah, I wish I had "work" to refer to 😉
<electronic_eel>
yeah, you really want to test such things out before buying
<d1b2>
<mubes> It frustrates me when I have to go via a 'work' account to get stuff.
<d1b2>
<esden> the hardware was several $k of gear... this is not something I can spend to "just try out" 😦
<azonenberg>
Yeah
<d1b2>
<esden> shell company FTW? 😛
<d1b2>
<mubes> Yeah, there are plenty of work arounds...none of them should be nessessary.
<d1b2>
<esden> work arounds seems to be "just life" at this point sigh
<azonenberg>
and yeah i'm sure having a company name to put on things has helped at times
<d1b2>
<tnt> Heh ... I kind of understand not shipping demo units to individuals ...
<d1b2>
<tnt> way easier to verify the credibility / validity of a registered company to make sure they're not just gonna keep it.
<d1b2>
<esden> They do that with glasses and other things already. These are genuine business models these days.
<d1b2>
<esden> But yeah, it is something one has to work to establish protocols for.
<d1b2>
<tnt> @esden but glasses main target market are individuals . Lab equipement, pretty sure most of their sales is companies.
<d1b2>
<esden> Sure, chasing after some halfwits that think they can get away with a demo unit is not worth the effort.
<d1b2>
<mubes> ..and the prices are often phone numbers, and it's mishandling leads to easy damage.
<d1b2>
<gatecat> ironically in the UK registered companies are probably harder to trace or hold liable than individuals
<d1b2>
<mubes> Yeah, just go to companies House and see how many have Michael Mouse as a director.
<d1b2>
<tnt> @gatecat But how easy is it to verify identify ? Here in BE ... you can't just verify someone's name or address or another, for privacy reason, so you have no idea who you ship that to. Companies, all infos are public, including real identities of the owner and their address.
<d1b2>
<tnt> Anyway, we're drifint way OT ...
<d1b2>
<gatecat> the problem in the UK is that those details for companies, although public, are never actually verified (and the companies house website now includes a disclaimer to that effect...)
<d1b2>
<tnt> Ah well, not the case here (and elsewhere in the EU), especially with some new anti-laundering rules that entered into effect last year or so, company ownership structure is checked every year.