EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Ed.Kloonk on July 13, 2020, 07:35:36 am
-
I had a chat today with a code rat that flashes consumer hardware for poops and giggles. And for beer if a willing customer is willing. :)
Turns out many of these cheap DSOs are prime for some full-tilt firmware tweaks like the common router or even the android phones.
What I am interested to know is the implication of any major firmware tweaks.
We are talking stepping away from the manufactures' code in the way that you can flash a router with dd-wrt or tomato.
My questions.
Would you use it?
What features would you like to see?
1054z looks like the perfect initial target.
Bottom line, I am trying to gauge the investment value of this idea.
-
:o :o :o
You make out like it's not being done around here big time already.
70 MHz to 150, 100 to 200
100 MHz to 350 and all options
350 MHz to 1 GHz " " "
And that's just scopes, then there's PSU's, AWG's, Spectrum analyzers, RF gens and so on.
-
:o :o :o
You make out like it's not being done around here big time already.
70 MHz to 150, 100 to 200
100 MHz to 350 and all options
350 MHz to 1 GHz " " "
And that's just scopes, then there's PSU's, AWG's, Spectrum analyzers, RF gens and so on.
I'm talking walking away from the base firmware. Where the interface is somewhat standardized across several models and makes.
I'm talking completely nuking the standard firmware. What would your ideal Frankenstein creation look like?
Again, just starting out with a couple of cheap scopes. Not taking over the world.
-
:o :o :o
You make out like it's not being done around here big time already.
70 MHz to 150, 100 to 200
100 MHz to 350 and all options
350 MHz to 1 GHz " " "
And that's just scopes, then there's PSU's, AWG's, Spectrum analyzers, RF gens and so on.
I'm talking walking away from the base firmware. Where the interface is somewhat standardized across several models and makes.
I'm talking completely nuking the standard firmware. What would your ideal Frankenstein creation look like?
Every few months there is someone with that idea.. And they find a way to flash new empty linux on the scope (mostly reference,base distribution from chip manufacturer). Basically taking perfectly functioning instrument that took 100-200 engineer years to develop, and make it useless linux computer with crappy processos, not much memory and small screen.
An to prove how smart they are they run Doom on it to prove they did it.
And then, when they realize they have no clue how do real work (the scope part) it dies silent death...
Fact that DS1054Z is 300-400 USD makes people think it is simple. It's not. It cannot be done in makers, hobby or even open source community. Because there is no skillset to do it, among people that would want to do it. Those that know how, do it for (good) money. And it is a hard, coordinated work, that is not compatible with people hacking and twiddling some code up.
It is not possible, not by people that are "code rat that flashes consumer hardware for poops and giggles. And for beer if a willing customer is willing."
-
I'm talking walking away from the base firmware. Where the interface is somewhat standardized across several models and makes.
I'm talking completely nuking the standard firmware. What would your ideal Frankenstein creation look like?
Again, just starting out with a couple of cheap scopes. Not taking over the world.
IMO it's a much bigger task than you might imagine and for what real gain ? :-//
Even cheap scopes are pretty complex these days.
-
IMO it's a much bigger task than you might imagine and for what real gain ? :-//
I don't know. It's why I'm asking. :D
I'm looking for the silver bullet. What is missing from the software? When you move around your scope or even from scope to scope, what is the biggest thing that futzes with your productivity?
Even cheap scopes are pretty complex these days.
Yeah nar. As with a mature software stack such as dd-wrt, you spin off model-specific modules.
The scope business is on a race to the bottom like the router industry was a decade ago.
I think there might be a buck in it.
-
IMO it's a much bigger task than you might imagine and for what real gain ? :-//
I don't know. It's why I'm asking. :D
I'm looking for the silver bullet. What is missing from the software? When you move around your scope or even from scope to scope, what is the biggest thing that futzes with your productivity?
Even cheap scopes are pretty complex these days.
Yeah nar. As with a mature software stack such as dd-wrt, you spin off model-specific modules.
The scope business is on a race to the bottom like the router industry was a decade ago.
I think there might be a buck in it.
To quote you , yeah nar...
Routers ARE simple. Scopes are not.
I already explained everything. Read again.
I know my English is horrible, but it was clear enough on this, I think.
Or to put it Apple like simple: Waste of time. That includes even discussing it. Just do something else, that is useful.
-
IMO it's a much bigger task than you might imagine and for what real gain ? :-//
I don't know. It's why I'm asking. :D
I'm looking for the silver bullet. What is missing from the software? When you move around your scope or even from scope to scope, what is the biggest thing that futzes with your productivity?
Lack of familiarity.
Simple to fix if we take the time.
This stems mainly from the many and varied tasks that one wants to do with a scope are vastly different and with modern scopes being quite complex it takes a mo to get it all as you like for each task at hand. Pro users are better positioned in this regard as they mostly know their scopes inside out and back to front yet we each have our own usage 'style'.
That alone makes one users methodology a nightmare for another which is why scopes have evolved to attempt to suit a variety of usage styles. For that reason you can often find the same settings in multiple menus.
Experienced users generally have little trouble using any decent scope whereas the novice has a lot to learn about just driving a scope let alone knowing what one should expect to see before even connecting a probe.
The scope business is on a race to the bottom like the router industry was a decade ago.
Ya think so ?
From where I sit much advanced functionality has been added into scopes than might have even been expected just a few years ago and for even less cost !
As a good few have said in the last year or two, we live in exciting times that so much good TE is so affordable.
-
if you really want to horse around then pick up some siglent scopes that are already linux based :popcorn:
-
Ya think so ?
From where I sit much advanced functionality has been added into scopes than might have even been expected just a few years ago and for even less cost !
Sorry, but I don't understand how that isn't precisely a race to the bottom.
One preliminary use case I saw is a substitute for an Arduino data logger with really nice front end. Live updater.
Of course DSO's are not as simple as a ordinary router - at the moment.
The router analogy is prolly flawed. But..
It's a whole paradigm shift. I know that 95% of people won't see it, but 99% of people use their ordinary router without needing anything more.
I'm not asking for how the software can do what it can do better, I'm asking what you could use the hardware for and what the standard software prevents you from doing so.
-
The scope business is on a race to the bottom like the router industry was a decade ago.
Ya think so ?
From where I sit much advanced functionality has been added into scopes than might have even been expected just a few years ago and for even less cost !
As a good few have said in the last year or two, we like in exciting times that so much good TE is so affordable.
WTB 8 channel analog + 32 channel digital and all touchscreen for... 500 bucks! :-+ :-DD :-DD
-
The scope business is on a race to the bottom like the router industry was a decade ago.
Ya think so ?
From where I sit much advanced functionality has been added into scopes than might have even been expected just a few years ago and for even less cost !
As a good few have said in the last year or two, we live in exciting times that so much good TE is so affordable.
WTB 8 channel analog + 32 channel digital and all touchscreen for... 500 bucks! :-+ :-DD :-DD
Only 8 + 32 ? :o
:popcorn:
-
The scope business is on a race to the bottom like the router industry was a decade ago.
Ya think so ?
From where I sit much advanced functionality has been added into scopes than might have even been expected just a few years ago and for even less cost !
As a good few have said in the last year or two, we like in exciting times that so much good TE is so affordable.
WTB 8 channel analog + 32 channel digital and all touchscreen for... 500 bucks! :-+ :-DD :-DD
I know, but if you're young and broke and you do have a basic scope sitting on the shelf. I understand for you $500 bucks is a couple of hours at work. :D
But if you're a hacker and you've got nothing but perhaps something you got given for your birthday I can see a use case.
-
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.
:popcorn:
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.
-
I've worked with the Rigol DS10x4Z (and similar) and Siglent 1104X-E (and similar).
The Rigol has a CPU that's not a lot of fun to work with (ARMv5T still). I've ported Linux with framebuffer, and then couldn't figure out how they actually stream the data from the ADCs, and overall it was painful.
I've then joined an existing effort (https://github.com/360nosc0pe/fpga) to re-write the bitstream and software for the Siglent. It's a much nicer hardware - Zynq-based, so a standard ARM linux binaries work - and we've reverse engineered almost all of the pinout, frontend control, clock etc., sufficient to make it receive data from both ADCs. In theory, at that point it's already useful, for example if you want to stream data and don't need a UI.
Then again nobody ever wrote a UI or more code so now it just bit-rots. But if I ever need a fast ADC on an FPGA, I'll likely pull that board out and continue that work. Or if LiteX zynq support gets better.
I don't understand the hostility here though. There are things that the manufacturers firmware can do incredibly well. But every user is different, and every use case is different. Fact is that freely-programmable hardware that is competitive to a cheap scope in terms of specs is significantly more expensive (like NI PXIe stuff), and that there are some low-hanging fruits (for example a realtime UART decoder - how useful would that be if we'd have a /dev/ttyCH1..4 on the scope that just works? That's not even a lot of effort - just use a threshold output to drive an instantiated UART).
I love OpenWRT, but at the same time it's not what I'd recommend if someone just asks for a nice router. But there are enough use cases that justify the existence, and in these cases OpenWRT can be just the right tool for the job.
-
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.
:popcorn:
Holy cow.
-
Only 8 + 32 ? :o
:popcorn:
Physical limitations... That makes a nice bottom row, give it a decade to hit sub 2k
-
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.
:popcorn:
Holy cow.
Yep but very useful if needed.
You could pull the rug from right under 8ch scope manufacturers. :popcorn:
-
I've then joined an existing effort (https://github.com/360nosc0pe/fpga) to re-write the bitstream and software for the Siglent. It's a much nicer hardware - Zynq-based, so a standard ARM linux binaries work - and we've reverse engineered almost all of the pinout, frontend control, clock etc., sufficient to make it receive data from both ADCs. In theory, at that point it's already useful, for example if you want to stream data and don't need a UI.
I started writing a UI for the MSO5000 (also Zynq) and got a simple example to run. The issue is that I didn't want to touch the FPGA firmware (I know my limitations) and therefore didn't have enough reverse engineering documentation to control the capture subsystem. Without that, wasn't much point in continuing for the sake of a dummy UI.
Thanks for that link... looks like an interesting potential avenue to explore.
-
I've worked with the Rigol DS10x4Z (and similar) and Siglent 1104X-E (and similar).
The Rigol has a CPU that's not a lot of fun to work with (ARMv5T still). I've ported Linux with framebuffer, and then couldn't figure out how they actually stream the data from the ADCs, and overall it was painful.
I've then joined an existing effort (https://github.com/360nosc0pe/fpga) to re-write the bitstream and software for the Siglent. It's a much nicer hardware - Zynq-based, so a standard ARM linux binaries work - and we've reverse engineered almost all of the pinout, frontend control, clock etc., sufficient to make it receive data from both ADCs. In theory, at that point it's already useful, for example if you want to stream data and don't need a UI.
Then again nobody ever wrote a UI or more code so now it just bit-rots. But if I ever need a fast ADC on an FPGA, I'll likely pull that board out and continue that work. Or if LiteX zynq support gets better.
I don't understand the hostility here though. There are things that the manufacturers firmware can do incredibly well. But every user is different, and every use case is different. Fact is that freely-programmable hardware that is competitive to a cheap scope in terms of specs is significantly more expensive (like NI PXIe stuff), and that there are some low-hanging fruits (for example a realtime UART decoder - how useful would that be if we'd have a /dev/ttyCH1..4 on the scope that just works? That's not even a lot of effort - just use a threshold output to drive an instantiated UART).
I love OpenWRT, but at the same time it's not what I'd recommend if someone just asks for a nice router. But there are enough use cases that justify the existence, and in these cases OpenWRT can be just the right tool for the job.
Thanks.
I forgot about OpenWRT. The last time I rolled up my sleeves, there was DD-WRT and tomato if you were adventurous. :scared:
I just use routers out of the box, so I'm the worst. :P If I'm in a good mood they might get an admin password change.
Thanks again for the information. I'll pass it on.
:)
-
Every few months there is someone with that idea.. And they find a way to flash new empty linux on the scope (mostly reference,base distribution from chip manufacturer). Basically taking perfectly functioning instrument that took 100-200 engineer years to develop, and make it useless linux computer with crappy processos, not much memory and small screen.
I agree. And the existing oscilloscope hardware isn't such a good start anyway because it is very limited. Also the hardware isn't the hard part; the software is 100 times more complex. If an open source oscilloscope is ever feasible the software must be as easy to develop as possible and the use of FPGA must be minimal. One of the ideas I have been toying with is to take an extremely simple FPGA design which can do basic triggering and buffering. After acquiring data the FPGA just streams the data into a SOC (with a beefy GPU) using a PCI express bus. From their the GPU which is A) easy to program and B) has a massive amount of processing power can crunch the data into a trace on the screen (which can be a 4k or ultra-wide monitor for all I care). But for me this needs to be a paid project.
-
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.
:popcorn:
Holy cow.
Yep but very useful if needed.
You could pull the rug from right under 8ch scope manufacturers. :popcorn:
Tomorrow's thread: Tablet DSO's and why MS are A holes.
:)
-
Every few months there is someone with that idea.. And they find a way to flash new empty linux on the scope (mostly reference,base distribution from chip manufacturer). Basically taking perfectly functioning instrument that took 100-200 engineer years to develop, and make it useless linux computer with crappy processos, not much memory and small screen.
I agree. And the existing oscilloscope hardware isn't such a good start anyway because it is very limited. Also the hardware isn't the hard part; the software is 100 times more complex. If an open source oscilloscope is ever feasible the software must be as easy to develop as possible and the use of FPGA must be minimal. One of the ideas I have been toying with is to take an extremely simple FPGA design which can do basic triggering and buffering. After acquiring data the FPGA just streams the data into a SOC (with a beefy GPU) using a PCI express bus. From their the GPU which is A) easy to program and B) has a massive amount of processing power can crunch the data into a trace on the screen. But for me this needs to be a paid project.
I'm glad that you can explain that it is hard instead of just saying it's impossible.
-
1054z looks like the perfect initial target.
Why? It's about the only one in the pack that doesn't run Linux.
-
1054z looks like the perfect initial target.
Why? It's about the only one in the pack that doesn't run Linux.
Yeah. Pity.
-
Me, I'd start with something like this:
https://www.aliexpress.com/item/4000861098295.html (https://www.aliexpress.com/item/4000861098295.html)
Cheap, simple hardware. Existing firmware is very basic and lacking in many areas. Easy to improve upon.
I don't know. It's why I'm asking. :D
I'm looking for the silver bullet. What is missing from the software? When you move around your scope or even from scope to scope, what is the biggest thing that futzes with your productivity?
The single biggest problem is that to be able to add anything at all you first have to reproduce all the existing functions.
There's a lot of them, they involve an awful lot of advanced math and signal theory. This isn't something you can knock together in a couple of weekends.
-
I don't understand the hostility here though. ..........................
There is no hostility... Simple facts..
You are THE example of how it is waste of time.... After all the effort, you achieved nothing that would even resemble the scope.
That is not to tell that you don't have impressive technical skills, or that it is in any way some kind of failure on your side.
Quite the opposite, you have my respect for demonstrated skills.
It is just a testament, that despite your high skill level, you would need 3,4,5 more years to achieve something that would be similar to what you started with, the DS1054Z... Because it is so hard...
And even if by some miracle you could get 10 open source people that share common vision and are extremely efficient in pumpin out code
and after few years of hard work, they create new scope app that transforms lowly DS1054Z into mini LeCroy, with advanced math and histograming, Rigol might (or any other manufacturer you chose to build upon) can simply discontinue it.... And all the work is without future..
There is a huge amount of confusion between making open source oscilloscope and using one. If you want to make one for the sake of learning how scopes are made, go for it. But most of people talking about it are people who have limited knowledge and money, hoping that they could buy cheap scope and magically transform it something more powerful if only someone would write open source software for it...
That is just waste of time.... Because it's not realistic, as evidenced by many examples so far...
-
Take for instance a siglent, the firmware has been offloaded, and I've even patched some SCPI stuff on occasion, its just linux with some locked file system areas,
To a more experienced firmware guy, it would not be anything left field to start replacing chunks of that code base to open up, overall the total complexity of the program is not high, its the FPGA stuff that you would not want to poke at, but the UI and linux side, go ahead, Its not particularly complex, its not obfuscated, and they where really helpful with there naming scemes.
This is how I would approach it to add new functionality / decoders, the decoding seems to run on the linux side, but was a little beyond my experience to reverse out.
-
I'm glad that you can explain that it is hard instead of just saying it's impossible.
I never said it was impossible at any cost, just that it is impossible for some code jockey that have no clue what is really needed.
Whatever you do, it is going to be much more expensive than just buying scope that is ready made and works well for your use.
My main point was that it was WASTE OF time, including explaining it again. It was done in detail before and I just summarized it for you. If you don't trust me, fine. Go verify. Waste your time, not mine...
-
Ed, Here is the main system app for the siglent, 99% of the UI stuff, decoding, etc all happen in this process, have a play, see if you like what you see, and from there see if its something you want to go through
I should add parts of the app literally run hard coded SCPI scripts, so adding stuff does not need much rewriting, it would involve working out where to hook for say displaying the data however.
-
Ed, Here is the main system app for the siglent, 99% of the UI stuff, decoding, etc all happen in this process, have a play, see if you like what you see, and from there see if its something you want to go through
I should add parts of the app literally run hard coded SCPI scripts, so adding stuff does not need much rewriting, it would involve working out where to hook for say displaying the data however.
Thanks. That will be interesting to have a look at. :)
Little use to me though since I can't even be bothered to change the blinking flouro above me let alone hack someone's scope.
Seems hacking the rigol is a no-go. A kid expressed a bit of interest and I thought I'd ask some the curmudgeonly experts on here what the chance is. And boy, did I get told. ;)
If it comes up again I might spring for a cheap siglent.
-
There's been some work on an alternative firmware for the Fnirsi 5012H.
Maybe that could be used as a starting point?
https://www.eevblog.com/forum/projects/reverse-engineering-fnirsi-5012h/ (https://www.eevblog.com/forum/projects/reverse-engineering-fnirsi-5012h/)
-
I was actively working on doing just this using an Instek GDS-2072E as the base HW when I destroyed the HW in an accident. Much of what needed to be done on the FW side had already been worked out. IIRC the only remaining issue was generating the correct checksum for a FW update file. Once that was worked out one would be able to login and develop new FW on the DSO using the Zynq ARM cores.
I got the GDS-2027E for very cheap from Amazon by luck. I've not felt inclined to pay full price for a replacement and another project appeared.
So since then I have focused all my attention on the AFE design and DSP. In particular, for the last week I have been working on how to create the correct minimum phase interpolation operator so that there is no precursor artifact as is commonly seen with the sinc(t) zero phase interpolators. I finally have that sorted and will be posting an explanation shortly.
Have Fun!
Reg
-
.. A kid expressed a bit of interest and I thought I'd ask some the curmudgeonly experts on here what the chance is. And boy, did I get told. ;)
.
Sorry for grumpiness... Not the intention, just had enough of repeating for my own children, I guess i ran out of it.... :-)
Point being, simply, 1 year of minimum wage buys more scope than crappy scope + 1 year of coding, even if you know what you're doing.
Simply wanted to stop you from going down that rabbit hole. Energy can be spent better by getting functional instrument and than doing fun projects, for all age brackets.. Of course if making a scope is what tickles your fancy, then, by all means, you should do exactly that... But in that case it's the journey that counts, not destination..
And quite frankly, for a beginner, even DS1054Z is amazing. It is infinitely better from what generation that sent human race to the space had as kids. I still remember the day when at age of 14 I was allowed to use 20 MHz analog Tek for the first time... And the glory of Lissajous curves...
And I was privileged to have limited access to it then.
Whining about how you don't like font on scope and how it is crap because you don't like the look if it just bothers me...
Stop whining, be happy you have it and start making projects with it. That is what counts..
-
I should say I was kind of playing it fast and loose, just renaming and replacing the system app via telnet. the firmware packaging might care, but it does not care about a checksum when it runs.
-
I had a chat today with a code rat that flashes consumer hardware for poops and giggles. And for beer if a willing customer is willing. :)
Turns out many of these cheap DSOs are prime for some full-tilt firmware tweaks like the common router or even the android phones.
What I am interested to know is the implication of any major firmware tweaks.
We are talking stepping away from the manufactures' code in the way that you can flash a router with dd-wrt or tomato.
My questions.
Would you use it?
What features would you like to see?
1054z looks like the perfect initial target.
Bottom line, I am trying to gauge the investment value of this idea.
Your research should include "Red Pitaya".
-
There is no hostility... Simple facts..
You are THE example of how it is waste of time.... After all the effort, you achieved nothing that would even resemble the scope.
That is not to tell that you don't have impressive technical skills, or that it is in any way some kind of failure on your side.
Quite the opposite, you have my respect for demonstrated skills.
It is just a testament, that despite your high skill level, you would need 3,4,5 more years to achieve something that would be similar to what you started with, the DS1054Z... Because it is so hard...
[...]
That is just waste of time.... Because it's not realistic, as evidenced by many examples so far...
I don't necessarily disagree with you. However, I've seen projects start like that (for example d-Box 2 linux), and they turned out to be really good. For d-box 2, a group of enthusiasts started to take apart a satellite receiver that was "cheaply available" (for some definition of cheap), removed all software other than the bootloader, and proceeded to build all software from scratch. It took over a year or so until you could watch TV on the thing again. It took multiple years to have a UI that was worth the name "_User_ Interface". Said UI (or derivatives of it) has been the "industry standard" (in a certain - but really relevant subset - of the market, i.e. that part of the market where you could have a decent profit margin). Dozens of companies eventually built commercial hardware (some of them clones, but most of them own developments with significant improvements) that was powered by this ecosystem. It didn't come without drama of course, and due to satellite TV losing versus online streaming, it's not highly relevant anymore, but I consider it a 15y+ success story.
Some projects take their time and need the right alignment of stars to happen and to properly scale. We're taking open-source projects for granted that were seen as "impossible", "too complex", "not viable" for years. Just take a look at what happens with open-source FPGA toolchains right now. And at the same time we're seeing many projects failing for exactly the reasons you've mentioned. But even "Linux Desktop" isn't the counter-example anymore that it used to be...
-
I was actively working on doing just this using an Instek GDS-2072E
I was just about to mention the Insteks. They allow "apps" to run on them to expand their functions.
-
They are written in Lua. @nctnico and I were beating on it until I killed my test bed :-(
The reason for wanting to generate the checksum correctly was so that one could reopen a locked down scope. Good Will turned off the telnet port. So the idea was to be able to take the current FW update, unpack it, modify the startup scripts and repack it.
Bothe the Instek and Siglent scopes are Zynq based. So one should be able to support a common code base on both with some conditionals for model variations.
Have fun!
Reg
-
There is no hostility... Simple facts..
You are THE example of how it is waste of time.... After all the effort, you achieved nothing that would even resemble the scope.
That is not to tell that you don't have impressive technical skills, or that it is in any way some kind of failure on your side.
Quite the opposite, you have my respect for demonstrated skills.
It is just a testament, that despite your high skill level, you would need 3,4,5 more years to achieve something that would be similar to what you started with, the DS1054Z... Because it is so hard...
[...]
That is just waste of time.... Because it's not realistic, as evidenced by many examples so far...
I don't necessarily disagree with you. However, I've seen projects start like that (for example d-Box 2 linux), and they turned out to be really good. For d-box 2, a group of enthusiasts started to take apart a satellite receiver that was "cheaply available" (for some definition of cheap), removed all software other than the bootloader, and proceeded to build all software from scratch. It took over a year or so until you could watch TV on the thing again. It took multiple years to have a UI that was worth the name "_User_ Interface". Said UI (or derivatives of it) has been the "industry standard" (in a certain - but really relevant subset - of the market, i.e. that part of the market where you could have a decent profit margin). Dozens of companies eventually built commercial hardware (some of them clones, but most of them own developments with significant improvements) that was powered by this ecosystem. It didn't come without drama of course, and due to satellite TV losing versus online streaming, it's not highly relevant anymore, but I consider it a 15y+ success story.
Some projects take their time and need the right alignment of stars to happen and to properly scale. We're taking open-source projects for granted that were seen as "impossible", "too complex", "not viable" for years. Just take a look at what happens with open-source FPGA toolchains right now. And at the same time we're seeing many projects failing for exactly the reasons you've mentioned. But even "Linux Desktop" isn't the counter-example anymore that it used to be...
Thank you for response. I must distress that I don't "root" against it. Quite the opposite, I'm saddened that Open Source anything is not more successful.. Those ideas were conceived by my generation, many moons ago, and I still remember the promise it held...
Some things happened, but frankly, compared to expectations back then, not much. We really thought it will change the world. It didn't, but it did make a world a slightly better place... Still a good thing...
Now a not why I think this way specifically about scopes. Scopes are highly custom, proprietary and highly non standardized platforms.
If some manufacturer would really make a scope and make it Open platform, without royalties, and fully documented, that would stand a chance of maybe be a successful Open Source scope.
It was much easier making operating system for highly standardized and very inexpensive PC platform, because, as the time passed by, brand new PC still had to be backwards compatible and had to run 7 years old code perfectly.
That was very important factor that gave Linux community 25 years of continuity to develop evolutionary, as code and as a community. Same goes for other PC targeted software, to some extent.
Scopes are more like big bang event, there is hectic hardware /software effort at one very concentrated and short time period, and then some period of debug, then team dilution and just long term support for minor bugs.
All new development happens on next model cycle...
Fact that many of these scopes run ARM/linux is not important. That doesn't make it standardized platform. On a scope platform is the data acquisition engine and connected parts, and different manufacturers make it a point to be as different as possible. So every effort will probably be isolated for specific manufacturers model and will have very limited reuse for something else.
All of that makes it very much harder than PC based software.
-
I had a chat today with a code rat that flashes consumer hardware for poops and giggles. And for beer if a willing customer is willing. :)
Turns out many of these cheap DSOs are prime for some full-tilt firmware tweaks like the common router or even the android phones.
What I am interested to know is the implication of any major firmware tweaks.
We are talking stepping away from the manufactures' code in the way that you can flash a router with dd-wrt or tomato.
My questions.
Would you use it?
What features would you like to see?
1054z looks like the perfect initial target.
Bottom line, I am trying to gauge the investment value of this idea.
Your research should include "Red Pitaya".
I forgot about that thing. Looked it up. Software is open, but hardware is not. It would be a bit of a worry if you're heavy-handed on the inputs.
-
Sorry for grumpiness... Not the intention, just had enough of repeating for my own children, I guess i ran out of it.... :-)
No problem. Takes a lot more lively conversation to upset this little **** duck.
When I get frustrated, I find something laying around the house and take my frustrations out on it. Like the wife.
-
Actually, Linux was very quickly ported to the DEC Alpha and IBM Power systems by Linus long before most people had even heard of Linux. And it now runs on a huge range of stuff as does *BSD.
So the argument about standardized platform is specious. DSOs are different, but rather less different than x86, Alpha, Power, ARM, etc.
Reg
-
Actually, Linux was very quickly ported to the DEC Alpha and IBM Power systems by Linus long before most people had even heard of Linux. And it now runs on a huge range of stuff as does *BSD.
I suppose anything that didn't have that stupid byte order would be refreshing to hack on.
So the argument about standardized platform is specious. DSOs are different, but rather less different than x86, Alpha, Power, ARM, etc.
Reg
Someone I know hacked a GoPro. Not to add or unlock any features, no just to have the thing display his ugly face when it booted.
-
Actually, Linux was very quickly ported to the DEC Alpha and IBM Power systems by Linus long before most people had even heard of Linux. And it now runs on a huge range of stuff as does *BSD.
So the argument about standardized platform is specious. DSOs are different, but rather less different than x86, Alpha, Power, ARM, etc.
Reg
You have propensity to take theoretical concept and present it as a fact that is easy to accomplish. Like it doesn't take additional work.
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...
-
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 - as an electronics novice/hobbyist & owner of a 1054Z - have read the entire thread and I agree that the functionality is plenty enough for me.
However, if I could wish for something I'd like to have custom color settings for the four channels -> *especially* to change the dark blue color of channel 4.
I've searched the forum but haven't seen anything like this. Is there already a hack for this or would it indeed be something new?
-
I've searched the forum but haven't seen anything like this. Is there already a hack for this or would it indeed be something new?
That wouldn't need a firmware rewrite, just a hack.
There's a Rigol hacking thread somewhere. All you need to do is search for 0x00ff0000 (or is it 0x000000ff) and replace it with something and see if you found the right one. If not, try the next one.
(maybe :P )
It's not actually "dark blue", it's just "blue". It looks dim compared to cyan, magenta and yellow (the other channels) because the human eye isn't very sensitive to blue and the other colors have two colors enabled, not just one.
-
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
-
Creating your own oscilloscope software is definitely not on the table, unless scopes become more standardized like the PC platform. Booting linux on the scope achieves nothing. It is just another embedded device doing nothing. The big work is creating drivers to the FPGA and other interfaces, signal processing etc. You need a team of specialized developers and several years.
Here is a series of blog posts of reverse engineering an Owon oscilloscope:
http://blog.weinigel.se/2016/05/01/sds7102-hacking.html (http://blog.weinigel.se/2016/05/01/sds7102-hacking.html)
There are some surprises, for instance they are using the second DDR memory bus as an interface between the SoC and the FPGA.
Here is the source he created:
https://github.com/wingel/sds7102 (https://github.com/wingel/sds7102)
I didn't count the blog posts, but it looks like he put an enormous amount of work in it. It is still not usable other than for academic interest.
-
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)??
-
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.
-
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
-
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
-
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.
-
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.
:popcorn:
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 ...
-
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
-
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
-
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.
-
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.
:scared:
-
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.
-
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
-
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.