Products > Test Equipment
Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)
boggis the cat:
--- Quote from: BravoV on May 15, 2017, 09:50:52 am ---"What if" .. the modded firmware is so bad that put the scope into infinite loop once booted ?
Assuming they released "all" including the boot code, and the user screwed the initialization code so bad that made the scope just sit there doing nothing in the deadly infinite loop.
--- End quote ---
The 'un-brick' option.
--- Quote ---When its time to RMA, and as usual, "few" users >:D will be pretending innocent, and as expected, the fight dispute between seller and user on RMA ... and so on, you just need a little imagination to think of the next scenes.
--- End quote ---
"Someone snuck into my house and flashed dodgy firmware onto my 'scope!"
Yeah... Not seeing the big problem there. 🤔
--- Quote ---"What if" .. the un-brick process only can be done if the initialization code also is not modded, and alas, because of the low cost constraints, design wise, protecting the init code is not possible. :-//
--- End quote ---
Then those people 'hacking' this 'scope right now had better be careful. I am assuming that Rigol would know a bit more about their products than the people tinkering with the firmware, so would be able to make that call.
--- Quote ---"What if" ... the modded firmware is so shitty, forgot to switch the front end relay to switch to less sensitive input level, while the screen is prompting its ok to plug and pump in high voltage signal ? :palm:
--- End quote ---
The DS1054Z doesn't have a 50 Ohm input. I don't see how you could damage it through a firmware issue.
--- Quote ---... another "what if" ... the over temperature mechanism is triggered, and the ISR for handling shutdown sequences is ignored or buggy ... >:D
--- End quote ---
Un-bricking time again...
--- Quote ---Too many "what ifs" ... and back to my previous post, its never about these "what ifs" scenarios anyway, the "fact" is, these scopes are selling like hot cakes, so why bother ? :-//
--- End quote ---
To lure the adventurous / foolish into spending their cash on your now out-classed product while you prepare your next true competitor. Money in your business, rather than your competitor's.
--- Quote ---Rather than sink deep in this fuss and mess, why not focus and concentrate on designing and making another new generation low cost scope, sort of DS1054Z successor, as DS1054Z is considered quite old now, and the new beast is specifically targeted to hit very hard to those new competing products. >:D
--- End quote ---
Opening up an obsoleted code base costs you nothing. Every 'tech' site and blog will wibble excitedly about your awesome 'open' system, yada yada...
Are there possible down-sides? Sure. Are they significant? I don't think so, but Rigol would decide that, not me.
BravoV:
--- Quote from: boggis the cat on May 15, 2017, 10:11:05 am ---The 'un-brick' option.
--- End quote ---
If you mean this option is to revert the firmware back to factory's original firmware, are you absolutely sure the "current design" capable of doing that ? Of course, no hardware modding say like soldering headers to do some on board hacking firmware override.
Do you even own or even ever used this DS1000Z scope ? :-DD
boggis the cat:
--- Quote from: Karel on May 15, 2017, 07:55:34 am ---It's my impression that one of the reasons for the "shitty" firmware is that there's not enough space (memory/cpu-power) to implement all the features in the correct way.
They are strugling with it. Probably, the only way to improve the firmware is to throw out half of the features...
--- End quote ---
You can tell the problem is resources -- processor power is definitely lacking, tight memory possibly.
Turn on features and it slows down. Turn on everything and it isn't really usable. Rigol could have chosen to ration out what you can set 'on', but they obviously went for the maximum features and leave it up to the end user to decide what they're willing to trade off.
Perfectly sensible approach, but it does mean that you can't just compare feature lists then assert that this inexpensive 'scope can match another. (Same issue as assuming that every 6000 count DMM with the same feature list is equivalent. They really aren't.)
boggis the cat:
--- Quote from: BravoV on May 15, 2017, 10:17:56 am ---
--- Quote from: boggis the cat on May 15, 2017, 10:11:05 am ---The 'un-brick' option.
--- End quote ---
If you mean this option is to revert the firmware back to factory's original firmware, are you absolutely sure the "current design" capable of doing that ? Of course, no hardware modding say like soldering headers to do some on board hacking firmware override.
--- End quote ---
I have no idea. I don't have one of these 'scopes, and have no interest in getting one. (Maybe I will want a new 'scope later, and see no reason to not consider whatever Rigol are making then. I don't much like the DS1054Z or variants thereof, but Rigol might put a much better 'scope on the market tomorrow, for all I know.)
Perhaps you are assuming that by "un-brick" I mean a simple process. I mean 'whatever it takes' -- what they would do in the factory. You could provide a series of steps from firmware updates right through to flashing the chips via the headers -- or even replacing them. Tell some YouTube techies how it works and let them produce your 'documentation' for the processes.
frozenfrogz:
Dudes!
It would be really nice to keep the chatting in the New Rigol D1054Z thread and stick to strictly bug-related issues here.
That way, I have a chance in catching up with adding stuff to the first post.
I tried to establish something like a pipeline for bug reporting with Rigol here in Germany. They are aware of this forum and know that the buglists and device discussions exist. However, there was no interest in chiming in / setting up an account here.
I also tried to get in touch via the "official" Rigol feedback/forum, but that is just a waste of time.
Can someone please break down the :FUNCtion:WREPlay:FEND // :FUNCtion:WRECord:FEND issue for me? I have not used the remote commands and am not sure if I understand correctly what is going on.
To my understanding, setting the frame size should be two different variables for record and play, but both functions seem to be using the same variable. -> or something like that.. Sorry, I did not have the time to dig into what is going on yet.
Regards,
Frederik
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version