New firmware for scopes. Open or otherwise.

[tv84]

One thing is installing linux on a machine. Another thing is creating the device drivers that are needed to address the specific HW of that machine.

If the scopes that we usually talk about in this forum were so "universal" we didn't need to buy them! We would be using the processor development boards running our "magical" FOSS.

Everyday a new thread is created with "scope wars" because they have different HW! It's not only the software. The secret of a scope is precisely the interaction between the HW and its SW.

And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??

[2N3055]

OS is useless without applications. Linux was obscure little toy, until it took off on x86 as application support grew.
You need to recompile every single piece of crap on every platform. Including applications..
So when Linux core was ported to DEC Alpha, that was initially more development system than OS usable by end users.

And scopes are vastly more different than computers that are nowadays wery architecturally similar. Unlike LeCroy scopes and Keysight Infiniivision for instance...

There is this minor detail you have overlooked. There were all the Minix utilities and a lot of Gnu utilities already available in source format as well as a pretty staggering amount of other stuff available as source.  Of course, you did have to know how to edit Makefiles and resolve library dependencies, *nix version quirks and such.

I missed the Linux announcement on comp.os.minix because I got laid off and lost Usenet access.  No matter.  I'd bought a Sun 3/60 and spent days compiling the Gnu utilities and a lot of other stuff like Octave and gnuplot.  So there is nothing theoretical about it.  On my first contract job I maintained a huge suite of Gnu and other utilities on 6 different platforms, SunOS, IRIX, CLIX, AIX, Ultrix and HP-UX which were NFS automounted everywhere.  This was just a Swiss Navy project I started on my own.  I got a nice email from an admin about a year after I left.

He had to do this massive update of admin tables across all these different systems and was dreading the task.  "But Reg had been here and expect was everywhere".  Instead of spending half the night he was done in an hour or less.

I wore out that T shirt 20 years ago.  I was the guy everyone went to when their code would not compile on their new computer during the workstation wars of the late 80's and early 90's.

Have Fun!
Reg

Which part of your post is not exactly proof of what I am saying?

I don't want to waste my time compiling parts of OS. I don't want to waste time to maintain huge suite of GNU utilities.
I'm not a programmer. I don't want to waste time compiling Octave for my computer. I want to use Octave to calculate things for my projects. And if you're smart, you get a Windows or mainstream Linux distro and all of these things are ready to use.

You obviously are a programer and do it well.  To me it is waste of time.. I have other things to do. And by that I don't think it's something beneath me. No, it simply something I don't do. It's not my job.

[Elasia]

What is missing from the software?

I am missing the ability to trigger on CAN FD frame with ID 0x18FDxx32 and byte 59 containing the pattern x11x111x. Two beers are on me, trappist or otherwise.

I swore I saw somewhere that siglent is planning a mask fix by adding the x to the keyboard menu

In the mean time I use a microchip pic to read the can fd bus and send out a trigger pulse usually on a digital input line

The mask is done in hardware before hitting ram so as soon as i see any packet i just pulse the trigger line

Annoying? Yes... but i tend to find this is almost always the best option on newer protocols if you are willing to make your own secondary trigger fixture

You would have a slightly larger delay from having to read the ram for your data packet

[Elasia]

One thing is installing linux on a machine. Another thing is creating the device drivers that are needed to address the specific HW of that machine.

If the scopes that we usually talk about in this forum were so "universal" we didn't need to buy them! We would be using the processor development boards running our "magical" FOSS.

Everyday a new thread is created with "scope wars" because they have different HW! It's not only the software. The secret of a scope is precisely the interaction between the HW and its SW.

And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??

Better to know your vendor...  we actually use a local company that makes daq products... issue? phone call away or go pound on their door

[nctnico]

And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??

Well, that problem is more of a resource problem than a technical issue. In the end an oscilloscope is developed & produced to make money. If too much time is spend on a product which doesn't make a profit then the company won't survive. This means that at the technical side the software & hardware has to be easy to maintain and scalable. So rest assured that oscilloscope manufacturers are not using extremely obfustigated ways to make the hardware interact with the software. But it is hard to come up with a good architecture. A company like Siglent likely has started from scratch 3 times (if not more) to get where they are now.

[free_electron]

Here's one for ya Ed;
Cascading DSO's for multi channel work with an I/O to I/O on another and some method of nulling delay times so scope displays can be aligned in time for 6/8/12/16 channel operation.....not MSO.
 

Edit to add
First DSO in the line assumed as master as it's triggered on a trace of interest with any further DSO's displays time aligned.

so last century ... Grab a bunch of infiniium scopes , hook em to a 168700, 16800 or 16900 series logic analyzer with expansion rack. shov in 9 bleades with 64 channeles each. a couple of coax cables, the timing lock fixture from agilent. click a few menu buttons. sample all you can eat ... these scopes and la's run windows 95 ... so that's how long ago it could already be done. and these machines go 8 Gs/s with 128 Msample deep memory PER CHANNEL.

IF you don;t want ot buy the fixture you can built it yourself. it's a bunch of inverter gates which are basically a signal distribution amplifier. the scope sends a trigger out to the LA , who pings it back to the scope's aux channel. the scope measures the delay. Then the la does the same : it pings the scope first and looks for the reply. They now know each others time alignment. so you can set up trigger like : here's a digital pattern for the LA and here is the trigger qualifier for the analog channels. If all is a match we initiate the trigger. of course you can only do midpoint trigger (50% pre event and 50% post event. Hook both machines up on the same network and the logic analyser will pull the acquired waveform form the scope(s) and visualize it in the same explorer window next to the digital data.

soooo last century ...

[rhb]

Which part of your post is not exactly proof of what I am saying?

I don't want to waste my time compiling parts of OS. I don't want to waste time to maintain huge suite of GNU utilities.
I'm not a programmer. I don't want to waste time compiling Octave for my computer. I want to use Octave to calculate things for my projects. And if you're smart, you get a Windows or mainstream Linux distro and all of these things are ready to use.

You obviously are a programer and do it well.  To me it is waste of time.. I have other things to do. And by that I don't think it's something beneath me. No, it simply something I don't do. It's not my job.

I only recently condescended to use Windows and Linux.  I was forced to do so by all the stuff that will not compile on anything else because of borked autoconf scripts or is not available in source form.

My attitude is very basic.  If I need it done, I learn to do it.  I do have major limits. I do not do life sciences or general chemistry, just physics and geology.  And geology is just something I used to do.   There is only so much time and as Harry Callahan said in "Magnum Force", "A man's got to know his limitations.".

Stay tuned.  Something quite amazing is coming.  I'm on record saying it could not be done, but I was clearly wrong.

Have Fun!
Reg

[delfinom]

And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??

Well, that problem is more of a resource problem than a technical issue. In the end an oscilloscope is developed & produced to make money. If too much time is spend on a product which doesn't make a profit then the company won't survive. This means that at the technical side the software & hardware has to be easy to maintain and scalable. So rest assured that oscilloscope manufacturers are not using extremely obfustigated ways to make the hardware interact with the software. But it is hard to come up with a good architecture. A company like Siglent likely has started from scratch 3 times (if not more) to get where they are now.

Yep, and they wouldn't have a product to sell if any newb out of college could cobble together an oscilloscope from parts in a bin. There's a reason why we want to simply buy a premade piece of equipment that fits our needs. We all individually don't have infinite man-hours and life to develop our own tools. So we instead find someone to pay for the work they did but with guarantees that it performs to a spec and outline of functionality so that we may use it to build other things with our limited man hours.

And I'll quickly devolve into the basics of capitalism :3
Open source has its place in the world but its not the be-all solution to everything, not everything needs to be highly configurable and customizable to get the job done, it sure would be nice but you'll spend more time thinking about it than using the oscilloscope to complete your task in the first place.

It's not different than "innovating" pipe wrenches and hammers. I'm sure the industry is ripe for innovation with a open source robot in there with automation to tighten pipes and hammer things for us.....are you just buy a bloody thing and do your job to make money

[luma]

I think the OP's comparison with consumer routers is forgetting that nearly all of the work had already been done for these groups.  Linux already exists, and it can route packets.  DD-WRT et al is mostly an exercise in cross porting and UI, the overwhelming portion of functional code in use comes from the mainline Linux distribution underneath.

A scope won't be like that.  You get Linux for the core device handling, but you essentially need to start from scratch to deal with all of the functionality of a scope.

Do-able?  Sure, if you have a large team and several years.  It's a much larger undertaking than a router.

[Ed.Kloonk]

I think the OP's comparison with consumer routers is forgetting that nearly all of the work had already been done for these groups.  Linux already exists, and it can route packets.  DD-WRT et al is mostly an exercise in cross porting and UI, the overwhelming portion of functional code in use comes from the mainline Linux distribution underneath.

A scope won't be like that.  You get Linux for the core device handling, but you essentially need to start from scratch to deal with all of the functionality of a scope.

Do-able?  Sure, if you have a large team and several years.  It's a much larger undertaking than a router.

As with Linux, it starts with one man. (Not me! I'm only the piano player)

The router analogy was sloppy on my part, I realize that. It was from a user standpoint not a hardware one.

But if the need was there for an alt system and it gained enough traction, manufactures would adjust the hardware and quite possibly help with the software. Who knows, someday nearly every scope could be running a standard OS such as Windows.

Oh wait.

 

[newbrain]

As with Linux, it starts with one man. (Not me! I'm only the piano player)

And here is where the fastidious Stallman's nitpick of calling it 'GNU/Linux' comes into play:
without the efforts of a multitude of people since the mid-80s that made a decent user plane available, Linux would only have been a nice kernel experiment.

[robca]

I think the OP's comparison with consumer routers is forgetting that nearly all of the work had already been done for these groups.  Linux already exists, and it can route packets.  DD-WRT et al is mostly an exercise in cross porting and UI, the overwhelming portion of functional code in use comes from the mainline Linux distribution underneath.

A scope won't be like that.  You get Linux for the core device handling, but you essentially need to start from scratch to deal with all of the functionality of a scope.

Do-able?  Sure, if you have a large team and several years.  It's a much larger undertaking than a router.

It's even more than what you mention. DD-WRT started after the original code was shared by Linksys, given that Linksys used GPL code and was forced to share it.  I'm familiar with AsusWRT Merlin, and as much as that firmware is awesome, it's still mostly based on the GPl code shared by Asus. And AsusWRT Merlin uses binary blobs coming directly from Asus

A lot of the functionality of a modern scope comes from the FPGA, and I doubt that even motivated hackers could make much progress there without the manufacturer sharing a lot of info.

I can see the possibility to improve the UI functionality somewhat using an approach similar to Magic Lantern for the Canon cameras, which in most cases uses clever overlays https://magiclantern.fm/ and had no help from Canon. But it's falling more and more behind the Canon release train.

The risk for an enthusiast project is that by the time there is enough functionality to be useful, the state of the art will have moved to the point where that effort is obsolete (say, having an open source firmware for a Rigol DS1052a today, when the DS1052e is pretty long in the tooth even for many hobbyists), and very likely the maintainers will have moved on before that point is reached

I can see more value in hacking simpler and cheaper scopes, like the FNIRSI scopes (already mentioned), with simpler HW and much crappier software. But for Rigol/Siglent, I'm not sure it's energy well spent, given the investments made by the manufacturers and the complexity/functionality of the existing firmware

[tv84]

But for Rigol/Siglent, I'm not sure it's energy well spent, given the investments made by the manufacturers and the complexity/functionality of the existing firmware

I would say you are sure. I know I am.