<_whitenotifier>
[scopehal-pico-bridge] azonenberg c0fc88b - Do not hold mutex while actively pushing data to the client (can cause deadlock until client socket times out)
<azonenberg>
@louis: see above. this likely needs to be fixed in the dscope driver too
<azonenberg>
tl;dr my earlier "hold mutex while sending waveform" fix introduces a new bug
<azonenberg>
so if you copied my fix you probably copied the bug too
<azonenberg>
we can add more features in the future, and there is still cleanup and refactoring to do
<azonenberg>
but at this point we have a driver which is usable for basic stuff. generally that's been the point at which i close the "add X support" ticket
<azonenberg>
and file new tickets if needed for not-yet-finished features
nelgau has joined #scopehal
massi has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg>
It might be but we have a lot of MSOs with LAs already
<azonenberg>
i think its the first pure LA
<azonenberg>
and yes, same socket architecture as the pico and digilent interfaces
<azonenberg>
that bridge will eventually support lots of other sigrok devices but to date only supports dreamsourcelab stuff
<bvernoux>
yes this sigrok bridge is a very nice things
<azonenberg>
the bridge is dual licensed gpl+bsd and the scopehal side is pure bsd
<azonenberg>
the socket provides a clean license boundary
<bvernoux>
yes the socket is very nice for that
<bvernoux>
to avoid poluting bsd license with GPL ;)
<azonenberg>
(the bridge binaries are gpl since they link to sigrok, but source is dual licensed so we can copy code from the bridge itself to other stuff under BSD)
<bvernoux>
ha interesting especially for distribution of binaries I think
<bvernoux>
It will be nice to add the bridge exe in glscopeclient-windows-portable ...
<bvernoux>
as so far bridge-xxx are not part of glscopeclient build
<azonenberg>
My plan is to package bridges as optional addons in the windows install package long term that you cna check or uncheck
<azonenberg>
and as separate distro packages or linux
<bvernoux>
ha ok
<azonenberg>
for*
<bvernoux>
I see bridges does not have any github/workflows so far
<azonenberg>
Correct. there is no CI for bridges yet
<azonenberg>
We are in the middel of some major refactorig of the bridges if you look at the changelog
<azonenberg>
moving as much as possible of both client and server into common classes and libraries
<azonenberg>
CI for bridges, as well as better unit testing project wide, is very much on the long term wishlist
massi has quit [Remote host closed the connection]
<bvernoux>
It is a total fail to build DSView\libsigrok4DSL with MSYS2 MINGW64 ...
<bvernoux>
So I cannot build & test the bridge on Windows ...
<bvernoux>
It is a shame as they have "stolen" the code from sigrok/pulseview but they have never updated the readme to build stuff
<bvernoux>
I have built sigrok/pulseview with success with MSYS2/mingw64 for information
<azonenberg>
Long term i plan to write our own driver to avoid the sigrok integration for it
<azonenberg>
since sigrok's api is awful
<azonenberg>
but near term this gets it at least somewhat functional on linux
<d1b2>
<louis> Yes, this is not surprising. I can take a look at trying to build it on a windows box; I haven't tried at all.
<d1b2>
<louis> If you download and install DSView from the DreamSourceLabs website, the bridge is intended to build against an unmodified libsigrok4DSL
<azonenberg>
bvernoux: note also that since the bridge is socket based
<d1b2>
<louis> (admittedly, I have no idea if the DSView download works or includes an independantly-linkable version of libsigrok4DSL)
<azonenberg>
you can build the bridge for a linux system and connect to it from a windows glscopeclient instance
<azonenberg>
bvernoux: re picoscope 3000 support, i was actually goign to poke you about it
<azonenberg>
what's the current status of that
<azonenberg>
and is any change needed on the bridge side to make it work?
<azonenberg>
(you will probably notice the bridge has been significantly refactored over the last week or so)
<tnt>
So with the bridge that means cheap fx2 LA are supported now ?
<azonenberg>
tnt: not yet
<azonenberg>
the bridge only works for dreamsourcelab stuff at the moment
<azonenberg>
but this is a big step in that direction
<azonenberg>
and support for all of the cheap sigrok hardware is going to happen as a result of this
<bvernoux>
I have not done any other test with Picoscope 3000 I need to rebuild latest bridge
<azonenberg>
ok
<azonenberg>
We are still working on flow control between glscopeclient and the bridge, sometimes the bridge sends data faster than glscopeclient can keep up and you get some buffer lag
<azonenberg>
the same is true of the dreamsourcelabs stuff
<azonenberg>
so this is a common issue with faster stuff
<azonenberg>
especially when paired with a slower computer
<bvernoux>
ha ok interesting
<azonenberg>
the symptom of this is when you see events (changes to coupling on a channel, pushing a button on the DUT, etc) after several waveforms of latency
<azonenberg>
rather than immediately the next trigger after you do it
<azonenberg>
this is caused by several waveforms getting caught up in queues
<azonenberg>
We will be working on flow control to improve this over the next couple of days
<azonenberg>
it's part of our next focus after the current refactoring we just finished
<bvernoux>
I think the best to have more testers which do not have fast oscilloscope is really to decouple slow oscilloscope to UI
<bvernoux>
like "discussed" on Twitter last time
<azonenberg>
It's a nice idea
<bvernoux>
like that even slow oscilloscope with 1WFM/s could be usable with glscopeclient
<azonenberg>
it's just nontrivial to actually *do* it
<bvernoux>
ha yes I imagine
<azonenberg>
given a combination of real world constraints and the hardware itself
<azonenberg>
the first issue is, if you have a scope that runs at 1 WFM/s
<azonenberg>
and assuming the retrigger delay is fairly short (i.e. it spends most of that second either waiting for a trigger-valid reply or waveform data)
<azonenberg>
any read command you send to the scope comes with a 1-second minimum latency
<azonenberg>
on average
<bvernoux>
yes we cannot do anything about that of course
<azonenberg>
the second issue is, while we cache as much as possible
<bvernoux>
what will be nice is the UI is not slow like menu
<azonenberg>
the first time you access any given setting the cache is cold
<azonenberg>
Prefetching is possible, but will just shift that delay elsewhere
<azonenberg>
So if the menu requires knowing whether a given channel is ac or dc coupled, at some point we have to ask the scope that
<bvernoux>
maybe that could just keep last N WFM
<azonenberg>
and it's going to take a second for that reply to come back
<azonenberg>
And rather than trying to prefetch all of those settings when you first connect to the scope, and adding a long startup delay
<bvernoux>
the idea is just to do now have the UI slow as hell and responsive
<azonenberg>
to me, it seemed logical to instead incur that delay on demand when you first access that setting
<bvernoux>
now->not
<azonenberg>
so for example it won't pull timebase settings from the scope until you open th timebase properties dialog
<azonenberg>
because doing it in advance would require adding that same delay sooner
<azonenberg>
What we *can* improve on somewhat easily is better write queueing
<azonenberg>
such that when you are sending a command and do not need a reply, such as adjusting vertical scale
<azonenberg>
you don't have to wait for the current waveform download to finish first
<azonenberg>
there is some WIP work on that already
<bvernoux>
yes it will be a nice improvement
<azonenberg>
But it's nontrivial to actually implement due to quirks of real world scopes
<azonenberg>
and not being well behaved
<bvernoux>
as so far the UI is linked to the WFM/s
<azonenberg>
Not exactly true
<azonenberg>
The UI is largely decoupled from the actual waveform download
<azonenberg>
what you're seeing is serialization events where some UI event has to block on access to the scope
<bvernoux>
yes probably but the feeling is the same
<azonenberg>
some of that blocking is necessary, such as querying channel coupling before opening the context menu the first time
<azonenberg>
Other blocking is unnecessary and can be fixed by write queueing
<azonenberg>
i experimented with write queueing on the Tek driver some time ago
<azonenberg>
and it was horrifically laggy
<azonenberg>
buggy*
<azonenberg>
i need to spend more time on it
<azonenberg>
part of the problem is that i do not have any slow scopes to test with :p
<azonenberg>
i buy fast ones
<bvernoux>
just try with Rigol and you will understand ;)
<bvernoux>
The same with Siglent IIRC as they are something like 2WFM/s max
<bvernoux>
All cheap scope in fact have such issue except Picoscope which are natively very fast to stream data
<azonenberg>
The dreamsourcelabs stuff is super faast too
<azonenberg>
I am actually going to give Jason at Siglent a call right now while i'm thinking about it
<azonenberg>
and see if he'll send me a demo of one of their lower end scopes, probably a 2000x+, that i can try to optimize on
<azonenberg>
the focus won't be the siglent driver as that's @mubes territory
<bvernoux>
Yes especially the DSLOgic U3Pro as it is direct streaming over USB3.0
<azonenberg>
but on optimizing application core
<bvernoux>
yes I imagine 2000x+ are very similar in "slowness" with SCPI to Rigol
<monochroma>
i think there are enough low cost high speed equipment that focusing on stuff that's slow and broken is a waste, but that's just my $0.02
<bvernoux>
if you can optimize it with a scope with 2WM/s (or even 5WFM/s) it will be clearly a game changer even for ultra slow <= 1WFM/s
<azonenberg>
monochroma: well it's not actually that i care about slow/broken stuff
<azonenberg>
so much as that a fast scope over VPN and a slow scope look very similar from the client's viewpoint
<azonenberg>
and *that* is a use case i do care about a lot
<bvernoux>
monochroma, It is just there's 1000x more people with slow/cheap scope than with fast Scope and that can help to have feedback and PR for glscopeclient
<monochroma>
heh. i was mostly talking about that people keep bringing up rigol, and that just seems like a dead end to me, unless someone REs and patches the firmware (or a replacement firmware)
<bvernoux>
If we do a poll on which have a Scope which cost >15KUSD and use open source tool I imagine there is not lot of people today
<monochroma>
sure, then this software really isn't for them :P
<bvernoux>
as Company so far using >20KUSD scope have bought all SW options and probably does not want to play with glscopeclient
<azonenberg>
bvernoux: you'd be surprised
<bvernoux>
Anyway with time I'm pretty sure more and more company with big scope will join
<azonenberg>
we actually are seeing a fair bit of interest from people with $$$ scopes who are tired of paying $e6 or $e7/year across their fleet to buy software options
<bvernoux>
Yes especially for that I can understand
<azonenberg>
That is my primary target right now. Industry users have decent scopes, not super cheap ones, and they see the obvious business benefit to open tooling
<bvernoux>
TO pay huge money for crappy UART support ;)
<bvernoux>
I do not speak about other option as they are totally crazy price for SW options
<azonenberg>
and at least some of them are willing to contribute because they recognize that it's cheaper to pay someone to implement the feature once
<azonenberg>
than to buy it N times
<azonenberg>
Louis, the guy who wrote the dreamsource driver, works for one of those places :p
<bvernoux>
Yes I'm totally agree it is just I doubt they will contribute
<azonenberg>
He's working ~20 hours a week on scopehal stuff now on his employer's dime
<bvernoux>
You can check big companis using AirSpy product I have developped no anyone have contributed ;)
<azonenberg>
You just don't have the right relationships with users yet
<bvernoux>
And it is used by lot of very very big company ....
<azonenberg>
yes, huge companies are not necessarily the best target. smaller companies run by techies not business people are more likely to contribute back
<azonenberg>
Anyway, point is, for the near term my focus is not on hobbyist users. if the project benefits them, then great
<azonenberg>
but my focus is on myself and other people using it professionally with decent hardware
<azonenberg>
And on adding high end features to attract more serious professional users
<bvernoux>
I just think hobbyist users can bring lot of things before big/medium company start to push something
<azonenberg>
Which is why you saw me build a PCIe decode before an I2S decode
<bvernoux>
For example some will do some Youtube video/tuto
<azonenberg>
like i said, we *already have* commercial users contributing
<bvernoux>
You will "never" see that from big/medium company
<bvernoux>
as it is often forbidden to show anything public
<azonenberg>
And i'm trying to ramp that up
<monochroma>
also there isn't much of a point when something like 80% of the features are useless to low end scopes because they can't even capture the required signals fast enough for the decoders >.>
<bvernoux>
On my side I'm planning to rampup too ;)
<bvernoux>
With lot of chance to buy a Tek MSO64B
<azonenberg>
by end of 2022 I hope to have the equivalent of several full time engineers working on the project (most likely a lot of part time devs vs a few full time, but we'll see)
<bvernoux>
And I could use only glscopeclient
<azonenberg>
Talk to louis before you try using it on a tek mso :p
<bvernoux>
Yes I have exchanged with louis over Tweeter
<azonenberg>
See how his attempts at optimize/stabilize the driver and poking tek to fix their firmware bugs have gone
<bvernoux>
He plan to rent again a Tek MSO64B to evaluate it again in few months
<azonenberg>
You're not talking to the same louis then
<bvernoux>
On my side I need the features of MSO64B with 50GSPS
<azonenberg>
The one here has a couple of mso5/6s
<azonenberg>
well if you buy it to use it as a standalone scope, great
<azonenberg>
but if you buy it to use with glscopeclient you may be disappointed unless tek gets their firmware fixed
<bvernoux>
Lecroy seems to be better on UI & speed but they are clearly far from the Tek MSO64B in term of base price and performances 12bits ADC 50GSPS
<bvernoux>
I have discussed with them and they have nothing comparable
<bvernoux>
in best case they was offering me something with 10GSPS or 20GSPS for the same price
<azonenberg>
yes, lecroy's fastest 12 bit scope is the 10 gsps / 20 interleaved wavepro hd
<bvernoux>
and only 8bits
<azonenberg>
but do you actually need 12 bits?
<azonenberg>
i find for most of my work 8 is fine
<bvernoux>
Yes
<bvernoux>
I need 12bits or more especially for 1GHz BW
<azonenberg>
Have you looked at keysight's offerings?
<bvernoux>
as yes at >2GHz BW anyway at output there is not even 8bits ENOB
<azonenberg>
i know they have a bunch of fast 10/12 bit scopes
<bvernoux>
and the scope switch to 8bits
<bvernoux>
I also need the spectrum view
<azonenberg>
i cannot speak to performance of recent keysight gear w/ glscopeclient
<azonenberg>
(as i dont think anyone has tested)
<bvernoux>
for RF stuff which is not provided by other scope
<bvernoux>
to debug PLL stuff or other advanced RF stuff
<bvernoux>
I clearly do not want to buy KeySight stuff I really hate their phylosophy ;)
<azonenberg>
what philosophy?
<bvernoux>
Yes I hate how customers are locked with their buisness
<azonenberg>
that sounds like every scope vendor
<azonenberg>
lol
<bvernoux>
and their price are totally crazy too ;)
<azonenberg>
Also sounds like every scope vendor
<bvernoux>
yes but they seems worse ;)
<bvernoux>
So far they have nothing interesting in term of price/performance compared to the 12bits 50GSPS Tek MSO64B ;)
<bvernoux>
They have provided me anything in comparison when I have contacted them
<bvernoux>
They are clearly not interested by small company and they do not want to do anything
<bvernoux>
anything->nothing
<azonenberg>
ah yes, keysight does seem to be less interested in small customers lately
<bvernoux>
yes clearly
<bvernoux>
They are far from HP & Agilent ;)
<azonenberg>
yeah well the HP we once knew and loved is dead
<bvernoux>
Which was providing some price "accessible" master piece of hardware in comparison ;)
<bvernoux>
Keysight are even selling some crappy stuff
<bvernoux>
their low cost scope are just awfull
<azonenberg>
well isnt keysight stil lselling the same entry level scope they've had since it was agilent branded?
<azonenberg>
essentially unchanged?
<azonenberg>
msox-3000 or something
<bvernoux>
yes a 100MHz BW scope for 4Keuros ;)
<bvernoux>
what a joke
<bvernoux>
With SW options like UART which cost 1KUSD ;)
<bvernoux>
and the most funny 4Mpoints memory ;)
<bvernoux>
when you have >100Mpoints on a cheap Rigol MSO5K with 8GSPS
<bvernoux>
which cost 5x less
<bvernoux>
Maybe the Infinivision is better polished but that do not justify this stagging price since more than 10years
<bvernoux>
without any improvement and such small BW for such price and this ridiculous 4Mpoints ;)
<bvernoux>
on chipset side Analog Device is like KeySight on lot of components ;)
<bvernoux>
overpriced and crazy I hope some other big chip manufacturer will change that
<bvernoux>
It seems to be the main issue when company are managed only by Marketing guys...
<Degi>
UART analyzer costs WHAT? xD
<bvernoux>
probably 1KUSD the UART analyzer option ;)
<bvernoux>
I have seen that one time what a joke ...
<bvernoux>
If you want UART+I2C+SPI it cost more than 3KUSD ;)
bvernoux has quit [Quit: Leaving]
<d1b2>
<mubes> @azonenberg don't worry about banging on the Siglent...the more eyes the better. If you speak to Jason you might mention that they've all gone a bit radio-silent. We've got a few bugs and enhancement requests outstanding with them, not to mention scheduling the loan of a 6000A for a couple of weeks to test against.