Hacking the Rigol MSO5000 series oscilloscopes

[BTO]

Is the Version 01.03.02.02 that was used sucessful available somewhere to download?

@BTO, if you have the 01.03.02.02, could you provide that on your Mega drive please?

Thanks a lot, Seppeltronics

Hi mate,

GOOD NEWS.   I GOT IT TO WORK

I can see why people are tripping up on this .
and thanks again to Dr Mefisto, He is correct it's an Automated script

HOWEVER THERE ARE SOME HURDLES YOU NEED TO GET PAST, But.. it's not that hard
and i'm happy to help anyone who needs the help
if you haven't already upgraded and licenced correctly, i'm happy to help you do this

I'M IN THE PROCESS OF MAKING A VIDEO THAT WILL EXPLAIN IT STEP BY STEP

also.. HUGE THANKS TO SMAS  for laying out clear information

Anyway.. Let's wait for the video and i'm sure we'll all be downgrading to 1.3.2.2
then licencing correctly
then upgrading with all options to 1.3.3.0

Meaning, No need to worry about Future upgrades and patching.
VERY COOL STUFF

I'M HAPPY TO HELP ANYONE VIA ZOOM OR REMOTELY IF THEY WANT THIS DONE....... NO PROBLEM, JUST REACH OUT TO ME AND WE'LL MAKE A TIME

[BTO]

I confirm, rigol_kg2.py script works well.

Me too
I have included all the files necessary for anyone, at this link
https://mega.nz/folder/A8cEgQRI#5FSoMrCurJi71T7VkRPgYQ

[BTO]

@drMefisto
See the Attachments...
I've noticed after upgrading with your script that 2 items are missing

In MEASURE / ANALYZE
The following selections were available when the scope was stock and when the patch was applied
- Counter
- DVM
- Power Analyzer
- Histogram
- Zone Trigger
- Eye Analysis
- Jitter

After downgrading to 1.3.2.2
Then applying your script (Version 2)
then upgrading again to 1.3.3.0

- Eye Analysis
- Jitter
Are no longer in the list

THOUGHTS....... ?
is this something that needs to be switched on or was an oversight ?

[BTO]

I confirm, rigol_kg2.py script works well.

Hey mate, can you check something for me .
in MEASURE / ANALYZE
at the bottom do you have
Eye Analysis
Jitter
?
I don't have them, just want to know if the result is the same.  I've checked and have discovered that Eye Analysis is an available
option in the MSO5000
I'm also gonna have a look over the script and see if perhaps these options were accidentally missed by DrMefisto when writing the script

[Kean]

@BTO - a few points

The thing about the python script method is that it requires additional IT knowledge of setting up a python environment and a network connection.  Not everyone with a scope has this knowledge, so it is great that you are offering the one-on-one assistance as this is where I think people will become unstuck for a process they will likely only ever do once.

I also have some hesitations with the direct FRAM data modification.  While DrMefistO may have reverse engineered the data format for the licensing, there is always the possibility of something being incorrect and causing weird problems or worst case even bricking the scope.  This is why I believe tv84 was suggesting trying to find a hidden SCPI command to do a similar thing.

Regarding Restore Defaults in the Pre Boot Menu, I believe this is a pretty important step when downgrading firmware as the stored settings are not necessarily backwards compatible and could cause weird behaviour.  In my case it even seemed to be the cause a lockup on reboot until I did this.  It may also be worth using this following an upgrade if there are some unexplained issues.

Regarding the Jitter and Eye Analysis, these are not supported options on the MSO5000 platform.  I believe they are supported on the DS/MSO7000 which shares a similar architecture and common firmware, but has extra processing power.  By all means the options can be enabled, but that doesn't mean they will be useful.  I recall there was some discussion of this in a much earlier part of the thread which you might find with some searches.

[BTO]

@BTO - a few points

The thing about the python script method is that it requires additional IT knowledge of setting up a python environment and a network connection.  Not everyone with a scope has this knowledge, so it is great that you are offering the one-on-one assistance as this is where I think people will become unstuck for a process they will likely only ever do once.

I also have some hesitations with the direct FRAM data modification.  While DrMefistO may have reverse engineered the data format for the licensing, there is always the possibility of something being incorrect and causing weird problems or worst case even bricking the scope.  This is why I believe tv84 was suggesting trying to find a hidden SCPI command to do a similar thing.

Regarding Restore Defaults in the Pre Boot Menu, I believe this is a pretty important step when downgrading firmware as the stored settings are not necessarily backwards compatible and could cause weird behaviour.  In my case it even seemed to be the cause a lockup on reboot until I did this.  It may also be worth using this following an upgrade if there are some unexplained issues.

Regarding the Jitter and Eye Analysis, these are not supported options on the MSO5000 platform.  I believe they are supported on the DS/MSO7000 which shares a similar architecture and common firmware, but has extra processing power.  By all means the options can be enabled, but that doesn't mean they will be useful.  I recall there was some discussion of this in a much earlier part of the thread which you might find with some searches.

Hi mate, How are you .

The thing about the python script method is that it requires additional IT knowledge of setting up a python environment and a network connection.  Not everyone with a scope has this knowledge,

hehe, INDEED IT DOES, and even then you'd get stuck.
My goal was to figure out why people were not having a high rate of success with Dr Mefisto's method.
the other thing that didn't make sense was... He seems like a very knowledgeable and capable guy so why would it have such a low success rate ?
Now i know..   Most people doing this have little to no clue about python programming and don't understand the dangers and risks of flashing EEPROMS and RAMS.  so that's that question answered.  it had nothing to do with Dr Mefisto, it has to do with the inexperience of the people
attempting this method.

NO WORRIES, THAT CAN BE RECTIFIED

so it is great that you are offering the one-on-one assistance as this is where I think people will become unstuck for a process they will likely only ever do once.

Yeah, I'm pretty much of that opinion now, The solution absolutely works, and i've even stress tested it (so to speak ) and pushed my luck and found out the following

- If you are on version 1.3.0.3 
You can upgrade to 1.3.2.2  or directly to 1.3.3.0

- If your scope is on 1.3.3.0 (Current Version) You can't downgrade via the Upgrade Utility in the O/S , However you can absolutely
downgrade to 1.3.2.2 via the Pre Boot Menu

- You can even downgrade to 1.3.0.3 DIRECTLY from 1.3.3.0  if you wish
i did this back and forward of upgrade and downgrading like 4 times or so

- Now.. From the patched version 1.3.3.0 ,
If you downgrade to either 1.3.2.2  or 1.3.0.3  YOU WILL LOSE ALL YOUR OPTIONS  (This has the benefit of not having to uninstall them )

If you downgrade from 1.3.3.0 to 1.3.2.2 and fail with dr Mefisto's method, You can always upgrade up again and patch it again, no problem,
Did this around 7 times, no problem

- Quick note on VNC VIEWER,
Version 1.3.0.3 HAS NO SUPPORT FOR VNC    (i was making a video, which will shortly be available, and i had VNC up on screen,
i downgraded to 1.3.0.3 , restarted the scope and reconnected VNC and it was like.....WHAAATT ??  LOL and then it hits me.. Oh, i'm an idiot.

But support is definitely available from 1.3.2.2 for VNC Remote viewing

THIS ONE WAS COOL
- Downgraded from 1.3.3.0  to 1.3.2.2
- then applied Dr Mefisto's Licensing method - All good
- Then upgraded to 1.3.3.0   ALL OPTIONS SURVIVED THE UPGRADE
then just for kicks... Downgraded direct to 1.3.0.3     ,  Go figure, ALL OPTIONS WERE PRESERVED AND SURVIVED THE DOWNGRADE

I have no question that when we get everyone through this process that No one will be using the patch method anymore
and no one will have issues in the future and we'll be free to just update the scope by official download from the Rigol Site.

I NOTICED 2 THINGS THOUGH
In Analyze
JITTER IS MISSING,
EYE ANALYSIS IS MISSING
Now i don't have a clear answer on this yet, but
1. it was working in the patch version
2. Looking at the manual of the MSO500 there is no mention of Eye Analysis, Nor in the MSO7000, it's not until you get to MSO8000 that
eye analysis is mentioned both in the manual and in the features.

Now, i know we can do eye analysis in different ways on the scope, so now i ask myself this question
WHAT EXACTLY WAS THE PURPOSE OF THE EYE ANALYSIS MENU in the MSO8000 ?   If you can do it anyway, what benefit do you have to have the menu option ?

Anywhoo, I was going to share the above results in a separate post, I may as well include them here for everyone to see
so
Upgrade and downgrade is absolutely possible
Dr Mefisto's Method does work   YOU JUST NEED TO KNOW HOW TO DO IT ?

As for helping people, Yeah sure, no worries, Let's get them over the line. I'm in the process of editing a video
and i'll advise when it's ready. so they'll either do it via video or Me helping them one on one and if anyone else wants to help, that'd be awesome.

I also have some hesitations with the direct FRAM data modification.  While DrMefistO may have reverse engineered the data format for the licensing, there is always the possibility of something being incorrect and causing weird problems or worst case even bricking the scope.  This is why I believe tv84 was suggesting trying to find a hidden SCPI command to do a similar thing.

- I wouldn't worry mate, I've looked through the python script, there's doesn't really seem to be anything bad there.
It's just basically getting python to access the FRAM and then (as Dr Mefisto Said) it's just
1. Checking for installed Options
2. Checking for Available Options
3. Checking for Unavailable Options
then
4. Getting Available and uninstalled Options
5. Then Installing them
it's really pretty straight forward

As for Bricking the scope.
 You won't have a problem  ON THE FOLLOWING CONDITIONS
1. DO NOW ALLOW YOUR SCOPE OR COMPUTER TO LOSE POWER DURING THE PROCESS
2. DO NOT UNDER ANY CIRCUMSTANCES ALLOW THE ETHERNET CABLES TO BE DISCONNECTED
3. THE ROUTER MUST NOT LOSE POWER OR CONNECTION UNDER ANY CIRCUMSTANCES
if those conditions are met you won't have a problem and you won't brick the scope, Merely writing to the FRAM is not going to do anything
as that is the job of the FRAM (or.. one of it's jobs)

I've flashed a lot of chips and micro's in my time, I have absolutely no reservation about this method, Given what i did do it in the last
24 hours or more, mate, if it was going to fail it would have .

", there is always the possibility of something being incorrect and causing weird problems "
I call this Paranoia   LOL
it's the same reason why people upgrade once then are scared shitless to downgrade or change anything.
We need to abolish paranoia and apply logic to the problem.    Trust me , it's fine

as for TV84's suggestion...
Sure, bring it on, Let's see which method is better.  Although seriously i reckon we already have a working method
but hey, i'm open to the SCPI method, there is also an SSH Option in the script (-s) which i found i didn't have to use.

Regarding Restore Defaults in the Pre Boot Menu, I believe this is a pretty important step when downgrading firmware as the stored settings are not necessarily backwards compatible and could cause weird behaviour.

- After my testing, i disagree (i was off that opinion 2 days ago as well, I'm off a new opinion now)
2 Points of proof
PROOF 1 - Over 10 times i downgraded the scope without using RESTORE DEFAULTS, it didn't affect it.
In saying that,  I am still advocating (to be on the safe side) i mean, it's just another step, That we do it anyway.  But i have not seen
a reason why it's necessary.
there were concerns of "The Screen Hanging" , I can see where that happened and i can see why  and ... the screen didn't hang.
there are 2 scenarios
1. is , You had to wait for the scope to reboot
2. is the screen goes black and you had to press the power button to restart,
I chalk it up to misunderstanding, but i'm happy to stick to the method where we restore defaults

- KEEP IN MIND, Restoring defaults DOES NOT uninstall those options that you said may be incompatible, it just resets the settings of the scope.

PROOF 2 - With everything upgraded and licensed,  I downgraded to 1.3.0.3
All Options were retained and there were no issues or conflicts.
I wouldn't worry about it,  I did this several times

In my case it even seemed to be the cause a lockup on reboot until I did this.  It may also be worth using this following an upgrade if there are some unexplained issues.

well, i reckon
1. we should keep the RESTORE DEFAULTS procedure in place if for nothing else other than good measure.
2. After the upgrade it's not necessary , Because you've already done it,
3. Although Self Check and Self Cal ARE A MUST !

Regarding the Jitter and Eye Analysis, these are not supported options on the MSO5000 platform.  I believe they are supported on the DS/MSO7000 which shares a similar architecture and common firmware,

This is what i suspect, about the MSO500, However it's also NOT supported on the MSO7000, it starts to be supported on the MSO8000.

so all that being the case, LET'S GET EVERYONE PUSHED THROUGH AND LICENSED CORRECTLY
if you haven't got it done, Let me know, i'll help you out

[Kean]

Regarding Restore Defaults in the Pre Boot Menu, I believe this is a pretty important step when downgrading firmware as the stored settings are not necessarily backwards compatible and could cause weird behaviour.

- After my testing, i disagree (i was off that opinion 2 days ago as well, I'm off a new opinion now)
[snip]
I wouldn't worry about it,  I did this several times

Sure.  You may not see any problems between those two recent firmware releases you tested with, but that is quite a limited test especially if you aren't using the scope feature between versions in such a way that defaults get changed.

There have definitely been issues in the past when going between various releases without defaulting the settings.  So a user who has an unit that they've been actively using with older firmware is more likely to have a problem.

Not a big deal, it just wasted some of my time when I encountered it and had to got back to that menu.  And in my case I was upgrading not downgrading - I believe from 0A.01.03.00.01 to 00.01.03.03.00.

Similarly, it is pretty important to run the self cal after an upgrade (and warm up).  The scope will work without it, but may not meet specifications.  I haven't watched all your videos, but I expect you cover that.

This is what i suspect, about the MSO500, However it's also NOT supported on the MSO7000, it starts to be supported on the MSO8000.

I thought I saw it was available for the MSO7000, but just looking now at Rigol site & datasheets I can only see it listed as option "MSO8000-JITTER".
Clearly they tried to get it working on the 7k platform, but gave up.  They just left the common code in there as it is effectively disabled without a license (unless hacked).

I doubt it is worth wasting any time on it - others have already tried with limited success.
See https://www.eevblog.com/forum/testgear/mso5000-jitter-and-eye-diagrams/
And https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2656659/#msg2656659

[BTO]

Regarding Restore Defaults in the Pre Boot Menu, I believe this is a pretty important step when downgrading firmware as the stored settings are not necessarily backwards compatible and could cause weird behaviour.

- After my testing, i disagree (i was off that opinion 2 days ago as well, I'm off a new opinion now)
[snip]
I wouldn't worry about it,  I did this several times

Hi mate,
sorry i was in a rush before and when i replied i thought it was a P.M.  so let me address those points again for the entire forum to see.

Sure.  You may not see any problems between those two recent firmware releases you tested with, but that is quite a limited test especially if you aren't using the scope feature between versions in such a way that defaults get changed.

- In a way it's limited, because it's limited to only my scope, but if our concern is between "Only 2 versions".. No i have done more than that.
I have gone from 1.3.3.0 - 1.3.2.2   then i have gone down to 1.3.0.3  and i think the other one was 1.1.4.4 (Just to push my luck)
After using Dr Mefisto's method i was able to downgrade to basically any version and still retain my unlock options with NO PROBLEM WITH THE SCOPE.

then i repeated this multiple times, 15 times or more all in all.  I really wanted to test it specifically so that it was not a one-off test. i really tried
to get the scope to fail at certain point.. It never did.
Now, Most users will not even attempt what i have done, Most are just going to go from their current version which is either going to be
1.3.2.2  or 1.3.3.0

There have definitely been issues in the past when going between various releases without defaulting the settings

- I have literally read and re read through the ENTIRETY of Unlocking DS1052E , Unlocking DS2000A and Unlocking MSO5000 .
i did this just to catch up again and when it read through you start to see (with hindsight) what the problems were, so my response to this point is..

- There have been issues, Definitely
- But those issues were made without hindsight and jumping in the deep end and a lot of assumptions took place, then people jumped to conclusions
based on false logic that we should DEFINITELY do the Restore Default thing... or else !!

No that's not the case.
I also read that a few users said that Restore Defaults gets rid of the installed Options.. THAT'S NOT CORRECT.
Restore defaults just takes your scope to default settings (if you have custom settings applied or a .stp setup file applied) that's all it does.
i have tested and proven that it does not uninstall your options , nor does it downgrade your scope to the factory state that you bought it in (after an uprade).

BUT. I AM AN ADVOCATE OF DOING THIS STEP JUST FOR GOOD MEASURE.... i mean.. Why not . it doesn't take long to do so i agree it is a good idea.
but i would stress. it's not a necessity and don't see it as such.

So a user who has an unit that they've been actively using with older firmware is more likely to have a problem.

Ummm,  No, i would say not, Because i downgraded to 1.1.4.4 and had no issues and i don't know anyone who has gone that low.
When i bought my scope it was on 1.3.0.3 , i think at this stage no one is on a lower version, Everyone is one 1.3.3.0  or 1.3.2.2  or 1.3.0.3
i haven't seen any lower.
But i am so confident that this method works that , If a member of the forum has a lower version, i am happy to test their version on my scope
before they upgrade it.
Seriously mate, i have tested the shit out of this, from version to version , up and down and sideways and switching between patched and licensed
and basically combining any option that popped into my head.  Never had a problem.

Not a big deal, it just wasted some of my time when I encountered it and had to got back to that menu.  And in my case I was upgrading not downgrading - I believe from 0A.01.03.00.01 to 00.01.03.03.00.

- Sure and when i started trying this out i also encountered a lot of errors, but as we said before
A Lot of users seem to lack technical experience and programming experince
I had the benefit of having coding experience and I.T. and Electronics for decades. Granted i had to dust off my Python Cobwebs in my brain
from my Uni years but.. it came back to me.
and since i hadn't installed Python for a very very very long time i also had hitches with the modules, but i worked it out pretty quickly.

I can absolutely see how a newbie user would get stuck here.
i can also see how that rumour of the black screen hanging came about,  it doesn't actually hang, you just need to be patient.
worse case scenario, Just restart your scope, it'll be fine
Another thing that accidentally happened, .... while using Powershell (Because i tried it on Powershell and Windows C.L.I.) i accidentally clicked
on the screen while the chip was being flashed.  AND THE PROGRESS BAR STOPPED !!!
i felt like Lefty on Donnie Brasco when he got "sent for " for a second.   then i realized   P.E.B.K.A.C. .
You just need to right click on the screen to take it out of Pause.  the install didn't fail, you just need to know not to click on the screen while
it's progressing

I think a lot of these issues arise from misunderstanding or lack of knowledge

Similarly, it is pretty important to run the self cal after an upgrade (and warm up).  The scope will work without it, but may not meet specifications.  I haven't watched all your videos, but I expect you cover that.

- Yes i've definitely covered that and i agree, it is essential after the upgrade to do a few things

1. DO A SELF CAL
2. DO A SELF CHECK (go through all 3 tests)
3. then DO THOSE 2 BACKUPS AGAIN

I would deem these POST Steps to be mandatory

I thought I saw it was available for the MSO7000

so for everyone's benefit
THIS IS REGARDING JITTER AND EYE ANALYSIS on the MSO5000
Which was seen in the scope with the patched version, And.. For me
- Jitter did work
- Eye Analysis worked for a bit and then it stopped and i couldn't get it to work again

Let me also explain for the benefit of the newbies....
JITTER is a "Software Option Package" they call it a "Bundle" so.. when Rigol unlocks software options they unlock it on a Bundle to Bundle basis.
they don't unlock it on a feature per feature basis, Meaning, if you want Eye Analysis, you MUST take Jitter as well.

so, that being said
Yes i also thought it was on the MSO7000,  Apparently not. Apparently (According to the manuals) it doesn't kick in until MSO8000.
which now leaves me wondering, since you can do Eye Analysis and Jitter on the scope anyway, what is the point of having that option anyhow ?
I"m still looking into that

However if we could figure out a hack to have that option in the MSO500 that would be cool, but as i understand the hardware doesn't support it.
However that doesn't really make sense to me since it's all just a software calculation isn't it ?

i have also seen you tube videos on Eye Analysis, but not many, and of those that i've seen they are using either Tek Scopes (It apparently comes standard) or they are using Rigol MSO8000, there is one guy using an MSO5000 HOWEVER HE IS NOT USING EYE ANALYSIS MODE, But instead
he is just using the scope to show how to troubleshoot with COLOR GRADE while doing Eye Analysis and Jitter.


IN CONCLUSION :
I am EXTREMELY CONFIDENT that Dr Mefisto's full licensing method via the python script works very well.
HAT OFF TO DR MEFISTO

i think we currently have the following issues that are stopping people from proceeding with the upgrade

- FEAR (in general)
- FEAR OF CHANGE

- Perhaps there is a feeling of... "Ohh well it's patched and working so why bother"
The answer is.. Because you'll have to do it eventually.   I can assure you all of you (as i am currently speaking to a senior engineer at rigol)
there will be another upgrade, it will primarily be resolving all the stupid grammatical and spelling errors so that we have a manual that is actually readable and makes sense especially to beginners and they are going to address memory optimization issues , hopefully the scope starts faster
as well as getting rid of 1ks/div Timebase in an effort to make COLOR GRADE more responsive at the lower time frames)  so.. there is another one coming i can assure you.
so if you don't do Dr Mefisto's method now, You'll be doing it later, that's for certain

- Then there are lingering rumours of this and that crashing.  I have found most of these are misunderstandings

- There is "it just seems so hard to do " thing....  No worries, I'm happy to walk anyone throught it, and .. it really isn't that hard to be honest.

- there is the "will it brick my scope" thing.
Well... NO IT WON'T
You just need to ensure a few things and be very careful
1. Ensure it doesn't lose power, so .. maybe like.. you can't kick the power board accidentally or something
2. Dont' do it during a lightning storm or if your area recently had power outages
3. Ensure that under no circumstances does your ethernet cable get disconnected during the flash process
4. Ensure that your router isn't a shit router and that it doesn't lose power during the process

and it's not the entire process we are worried about , it's only for that .. maybe 2mins of Flashing (Where Power and network is critical)
or
When you're doing a firmware upgrade or downgrade (here, Only power is critical, Network doesn't matter)
that aside.. You are not going to brick your scope.

- then there's the "but what if there's something in the script that stuffs up my scope"  thing
well..........THERE ISN'T , I've checked it out

- Then there's the (i have heard rumours)  and maybe Dr Mefisto can she some light.
the rumour is since we all have MSO5000  (5074) for the most part. the script is written for 5074
but,, if you have MSO5014 (as i heard)  it doesn't work on it

- Well, i can't see that making sense as the MSO 5014 is the same scope just with 70MHz - 100MHz Unlocked

SO IF THAT WAS THE CASE,  You could just use the script and since that's a software options, Just uninstall the option.
After that treat is as normal

I can't see how it's relevant, because
- The script checks for installed Bundles
- It then checks for available bundles
- it then installs ALL AVAILABLE BUNDLES FOR THAT SCOPE

I have also heard that there is a solution for the MSO5014 issue and that is to change a line of code.............. OK, WE'LL CHANGE IT,
it's not a big deal


so i think we are at the point where people just need to stop being scared , as i said I'M HAPPY TO TEST THIS AND SHOW RESULTS

so if you guys have any fear (i am that confident in Dr Mefisto's method)  Tell me your fear and i'll test it on my scope and let's put the fears to rest
and get everyone upgraded

I'm still in the process of making that video to upgrade via Dr Mefisto's method,   it will contain a lot of things you guys are talking about and i'll hopefullly put all that to rest.

speak soon
sorry for the long post

[BTO]

FYI - I've created a new post that is dedicated to putting the Dr Mefisto solution in one place .
So far i've only go the post up with the description

AT THIS LOCATION
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-dr-mefisto-licensing-method/new/#new

I will make and attach a PDF (Not ready yet, I need some sleep)
I'm also in the process of creating and in depth tutorial Video to follow along step by step

I believe with everything in 1 place and simple video instructions and my availability to help people if need be, there is no reason why everyone shouldn't start jumping onto this ASAP.

Give me your thoughts.

[BTO]

I've updated the other post and there is a DETAILED PDF there............ GO FOR IT !!!
i still haven't made the video but the pdf should take care of everyone i think

[Protegimus]

...
 I can assure you all of you (as i am currently speaking to a senior engineer at rigol)
...as well as getting rid of 1ks/div Timebase in an effort to make COLOR GRADE more responsive at the lower time frames)  so.. there is another one coming i can assure you.

Can you elaborate on why we need to get rid of 1ks/div timebase (I appreciate you don't see a use) and how (if at all) it is involved with improving the colour grade?
No biggie, just don't want to lose something that may come in useful in future unless it will genuinely lead to a worthwhile improvement elsewhere.

[BTO]

...
 I can assure you all of you (as i am currently speaking to a senior engineer at rigol)
...as well as getting rid of 1ks/div Timebase in an effort to make COLOR GRADE more responsive at the lower time frames)  so.. there is another one coming i can assure you.

Can you elaborate on why we need to get rid of 1ks/div timebase (I appreciate you don't see a use) and how (if at all) it is involved with improving the colour grade?
No biggie, just don't want to lose something that may come in useful in future unless it will genuinely lead to a worthwhile improvement elsewhere.

Can you elaborate on why we need to get rid of 1ks/div timebase

- LOL, Probably not.

(I appreciate you don't see a use)

well yeah, tell me why you think ANYONE needs to be looking at a frequency that has a timebase of 1,000 sec per division.
so in my opinion AND IT IS JUST MY OPINION, I don't see how anyone would go slower than 5 seconds, let's even say 20sec / Div.

but... the important take away is this.....  So that we don't go down an unnecessary rabbit hole

and how (if at all) it is involved with improving the colour grade?

I just figured there was a lot of memory being sucked up unnecessarily,   Feel free to prove me wrong

No biggie, just don't want to lose something that may come in useful in future unless it will genuinely lead to a worthwhile improvement elsewhere.

ABSOLUTELY UNDERSTAND...  and don't even worry about offending me, Say whatever you want, Let it out, after all if you bring something to my attention now I WILL DEFINITELY RELAY IT TO THE SENIOR
ENGINEER WORKING ON THIS

OK, so those are the quick answers to your concerns, Now let me say something else for the sake of clarity .
Let's not go down a rabbit hole here, Let's just understand how that 1Ks/Div idea came about.

1. I was helping people unlock their scopes

2. I made a video series on all the features and getting people to learn how to use their scopes,  at which point i realized COLOR GRADE is going really slow, and on the slower time frames even more so.
and no , No persistence settings were involved.

3. Now.. Obviously it was cool as hell to get a scope and be like ..Aaaawwwwwww   1..... THOUSAND......SECONDS..... PER DIVISION 
for sure.  But really mate,  WHO....THE HELL!!! is going to use that ?

4. When i asked the Engineer about it he said (and it was contradictory) ,  On one hand he said, people out there use their scopes as dataloggers,   However you're not supposed to do that
as that's not what it was designed for, if you want to do data logging, you should do it with a data logger,  and i agree with that .
then on the other hand they said (RIGOL SAID) we wanted to make the data loggers happy     LOL.... So that's how we got that

5. Now, if speeding up COLOR GRADE has nothing to do with the memory usage of slow timebases, then... Go Niuts,  I say, Keep the 1ks/Div  , although i can't fathom when someone would use that.
UNLESS!!!!.........UNLESS THE UPDATE RATE WAS AWESOME,   Now 1,000seconds is like 16mins , and if you had to wait 16 mins and then the waveform would be there, .. Sure, i'm ok with that.
although LOL...  Who has a signal generator that can generate as slow as 1mHz ?  and who would use it ?

The entire point here was that color grade was slow (AND I FEEL STRONGLY ABOUT THIS), If it's in the scope, it should work and should work properly, We pay a lot for these things and should get
what we paid for. it seems to work beautifully in the MSO7000 series.

NOW I HAVE NOTICED THIS AS WELL THOUGH
With the patched up version of the scope, it was slow
With the DrMefisto fully licenced method,  it has gotten to a point where it is... MAYBE... Acceptable, But the scope does definitely respond better on the fully licensed Python script.
if you haven't licensed your scope yet, i strongly suggest you do

then..  I went through the manual in the scope, I found in the scope all in all 124 Errors (that's ridiculous). The senior engineer was humble and apologized, he then brought this to the attention
of the top guys in china for RIGOL. and has assured me that when he gets back to america they are going to look at resolving all these issues.

Now, there's no promise that they are going to get rid of 1ksec/Div , it was just a passing thought,  I brang up the issues with the manual and he asked, is there any other issue.

I BROUGHT UP
- The manual needs serious attention

- the grammar and spelling through the scope needs attention as well

- The LA Probes (which i have purchased) has really shit stickers on them , they just fall off, they did so from day 1, Literally out of the box 3 or 4 fell off,  I think it's a shit adhesive and i said to him
"Mate if you could send me a set of stickers i'll superglue them on myself with a drop of superglue"  HE AGREED TO DO THAT , After all, I put in 4 days of work to sift through the manual and put together
a document showing all the errors

- Then i brought up the COLOR GRADE thing and said, it's a cool option but it really doesn't work well enough for us to get excited about.
in reality, we should be able to have 200Mpts Mem Depth ON and HIGH RES Acquisition ON and  COLOR GRADE  ON and it should work fine.
so if that means optimizing color grade then.. ok
but i didn't say to him that we necessarily had to eliminate 1ks/Div to achieve this,  it was just a suggestion

Now if you have anymore suggestions, Let me know and i'll forward them through to him,  I was actually thinking of starting a post but didn't  YOU CAN FEEL FREE TO START ONE
and i can refer him to the link if you like. and the subject of the post could be....
WHAT WOULD WE LIKE TO SEE IN THE NEXT FIRMWARE UPGRADE ?

it goes without saying that the manual errors are going to be fixed
and they are going to look at using a better team (More competent with english) and a better checking process to confirm no errors are made.
they are also going to look at using a better adhesive on the stickers of the probes

ASIDE FROM THAT.. FEEL FREE TO CHIME IN

[Protegimus]

As there is a legitimate use (even if not 'intended' I appreciate the flexibility) for 1ks/div let's leave that alone.
It could potentially come in useful in automotive for catching issues too.

Colour grading, absolutely, let them get it sorted.
Thanks for raising all the other issues with Rigol.

There is already a thread started by WinnieThePooh for bug tracking:
https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
to which I've contributed.

If they're looking at improvements then anything further they can do for low level signal processing that would be appreciated by everyone I expect.
Oh and change the colour of the on-screen logo back to the original yellow to match the bloody printed label would be good! 

[BTO]

As there is a legitimate use (even if not 'intended' I appreciate the flexibility) for 1ks/div let's leave that alone.
It could potentially come in useful in automotive for catching issues too.

Colour grading, absolutely, let them get it sorted.
Thanks for raising all the other issues with Rigol.

There is already a thread started by WinnieThePooh for bug tracking:
https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
to which I've contributed.

If they're looking at improvements then anything further they can do for low level signal processing that would be appreciated by everyone I expect.
Oh and change the colour of the on-screen logo back to the original yellow to match the bloody printed label would be good! 

As there is a legitimate use (even if not 'intended' I appreciate the flexibility) for 1ks/div let's leave that alone.
It could potentially come in useful in automotive for catching issues too.

- as i said before, my focus was on COLOR GRADE not getting rid of 1ks/Div timebase, the Senior Engineer understands this.  so don't worry.
as for this comment

It could potentially come in useful in automotive for catching issues too.

Do you actually use the MSO5000 for Automotive, Because once upon a time i contemplated using my DS2000A to troubleshoot piston timings and spark plug firing times.
i was told that if i hooked up my scope to the car that i would damage my scope. When i looked into this and discovered Automotive uses a PicoScope, i wondered, what's the difference ?
it turns out our scopes are not rated for Automotive Electrical levels.  NOW DO YOU DISAGREE WITH THAT ? I"m genuinely curious. Since you brought it up.

Also, What Automotive applications would require such slow timebases that are in the mHz ?

If they're looking at improvements

- I wouldn't say they were looking at it, I would say that i found a shit load of problems and their intention is to fix those problems.

anything further they can do for low level signal processing that would be appreciated by everyone

OK, I WILL PASS THAT ON

Oh and change the colour of the on-screen logo back to the original yellow to match the bloody printed label would be good! 

LOL... MATE I'M WAY AHEAD OF YOU , I Didn't mention that because, it doesn't even need to be mentioned

Personally However, i don't mind the blue logo,    buuuuuuutt......... i'm not saying  LOL,  I'm not saying it's gonna stay blue.
i actually don't even know if that was intentional, but i will 100% ask about it
and if they change it back.... YOU MAY HAVE THE HONOUR OF SAYING THAT YOU MADE THAT HAPPEN 

[BTO]

As there is a legitimate use (even if not 'intended' I appreciate the flexibility) for 1ks/div let's leave that alone.
It could potentially come in useful in automotive for catching issues too.

Colour grading, absolutely, let them get it sorted.
Thanks for raising all the other issues with Rigol.

There is already a thread started by WinnieThePooh for bug tracking:
https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
to which I've contributed.

If they're looking at improvements then anything further they can do for low level signal processing that would be appreciated by everyone I expect.
Oh and change the colour of the on-screen logo back to the original yellow to match the bloody printed label would be good! 

Just emailed him.  the Blue Logo was on top of my list of priorities, Let's make sure that this Atrocity never happens again.

[Sergey_21]

Hi all!
I'm trying to unlock additional options on my MSO5074 oscilloscope.
To do this, I use the rigol_kg2.py script, but after the python rigol_kg2.py -r xx.xx.xx.xx command I get an error.
Can anyone help me?

[BTO]

Hi all!
I'm trying to unlock additional options on my MSO5074 oscilloscope.
To do this, I use the rigol_kg2.py script, but after the python rigol_kg2.py -r xx.xx.xx.xx command I get an error.
Can anyone help me?

Sergey.... Tel me something, 
I'm going to do this STEP BY STEP

1. I gave you SPECIFIC Instructions on how to install Python,
You didn't actually CONFIRM that you did that, You just said "I did all you asked"
Now, Let's assume for a second that you did install Python Correctly (On the grounds that you were able to run the information -i command

2. The next step was to run the  -r Regenerate Key command
Now... YOU TOLD ME THAT YOU GENERATED THE priv.pem Key ??
So.. Why now are you failing to generate it ?

3. When you started having problems
- You were using another volume ( D Drive), We changed to C Drive and we got further.
- I then also advised you to delete the EXISTING priv.pem file , YOU SAID you did that
- Then i advised you to run the   

Code: [Select]

python rigol_kg2.py -r 10.0.0.666    where 10.0.0.666 is your I.P. Address that we confirmed as correct

YOU THEN SAID THAT IT GENERATED IT SUCCESSFULLY

- I then told you to put the priv.pem in the same directory location as the python script , which is also the same directory location that shows up when you open a shell.

AFTER THIS, You are NOT supposed to use the -r command again,  You are now supposed to use this

python rigol_kg2.py 10.0.0.666

NOTICE THERE IS NO  -r SWITCH !!!
we do this when we ask python to run the python script

- NOW YOU SAID YOU DID THAT AS WELL
- I then advised you to restart the scope
- Re Load 1.3.2.2
- Restart again
- Run the -i command
- then run the script again

python rigol_kg2.py 10.0.0.666

and then it's supposed to activate,  IT HAS FOR EVERYONE ELSE

someone in this process you are tripping up.

then.. I asked you 4 TIMES.. If you want me to jump on zoom with you -  YOU HAVE NOT ANSWERED


Mate, i can help you with this.  so can the forum, You said you have a MSO5074 specifically, that is on 1.3.2.2
YOU SAID, you think that in some way your scope is unique or different and the script is having a problem with your scope.

Mate, i've looked through the script,  we can get TV8 or DrMefist0 involved if they'll respond of have the time to. But i reckon they are going to tell you the same thing

You're suggesting we contact DrMefist0 because you think he made a mistake with the script

BUT THEN WHY IS IT WORKING FOR EVERYONE ELSE for the most part, ?

Now.. Perhaps you are shy, I Understand
Perhaps you have reasons you don't want to jump on zoom... I Understand that as well
and that's ok if it's the case
and if you want to jump back to the patch method,  THAT WILL CERTAINLY WORK (But not permanently)

Now, You've skipped steps that i've asked you to do  and i think, therein lies the problem

so..
OPTION 1 - If you want to give up on the script method, Let me know,  and that's fine
                  (But it looks like you don't want to )

OPTION 2 - AGAIN.... (and i won't keep asking, ok)    DO YOU WANT ME TO HELP YOU ON A ZOOM SESSION ?   If not, that's ok  but at least answer the question.

OPTION 3 - if you want to keep it on the forum,  so others can help you
DO THIS......


STEP 1 - Uninstall Python,  Delete the Script, Delete the Priv.pem file

STEP 2 - Start Over....... 

STEP 3 - PROVIDE SCREENSHOTS FOR EVERY STEP , Meaning... The following

Screenshot 1 - Show the first 3 screens of installation to show the options you selected
Screenshot 2 - Show the I.P. Address of your scope on it's screen (Don't worry mate, the I.P. Address is not sensitive ) it's not a public I.P.
Screenshot 3 - Show an open powershell showing the directory it's open in
Screenshot 4 - Show that you copied the file (THAT YOU MUST GET FROM THE LINK I SUPPLIED) and confirm that you did.... Show that you copied the script to the same location as the powershell
Screenshot 5 Show a ping command that shows communication to the scope
Screemsjpt 6 Show that yo have run this command

Code: [Select]

python pip list and let us see the modules that are installed
Screenshot 7 show that you are running the command   

Code: [Select]

python rigol_kg2.py -i [Your I.P. ADDRESS] and show the table that follows
screenshot 8 Show that you have run the command

Code: [Select]

python rigol_kg2.py -r [Your I.P. ADDRESS]
Screenshot 9 Show again a screenshot with the same directory of the script, but this time to have the priv.pem in it as well
Screenshot 10 Show that you are running now, the script 

Code: [Select]

python rigol_kg2.py [Your I.P. ADDRESS]    and include progress bar screenshots
Screenshot 11 Show a photo of you running the 1.3.2.2 UPGRADE.... A SECOND TIME over the existing 1.3.2.2
Screenshot 12 Show that you are running the -i command again
Screenshot 13 Show that you are running the

Code: [Select]

python rigol_kg2.py [Your I.P. ADDRESS]   script again
and then show the output of that


DO THAT IN 1 POST EACH SO YOU'LL HAVE LIKE 14 POSTS ALL IN ALL............... I reckon, given the difficulty you are having... You should absolutely do this
Not only for your benefit, but for the troubleshooting benefit of others.


so those are your options
Either you give up on it
or
you let me help you on zoom
or
troubleshoot it here,  But TROUBLESHOOT IT PROPERLY and don't skip steps and confirm things clearly and accurately

as i said before, You are so close to getting this,  we just need to figure out what's going on. But, it's not the script and i reckon DrMefist0 will tell you the same.

You have an MSO5074,  There is no difference between my scope and the several others that have already licensed their scopes.   it's not the script mate


so Get those screenshots done for us and let's figure out what's going on

[BTO]

Hi all!
I'm trying to unlock additional options on my MSO5074 oscilloscope.
To do this, I use the rigol_kg2.py script, but after the python rigol_kg2.py -r xx.xx.xx.xx command I get an error.
Can anyone help me?

Also if anyone wants to help you

- it's more effective to actually state the error.
it's an "Assertion Error"

Now, An Assertion Error occurs when an Assertion is made but the result is FALSE
then program stops and spits out the error.

- It seems to me that you're running the

Code: [Select]

python rigol_kg2.py -r [Your I.P. ADDRESS] command after you have already generated a Priv.pem file.

- Now if we look at the code and the error

LINE 215 -

Code: [Select]

    print('Reading CFRAM done.\n')this is reflected in your screenshot, so we know your scope gets up to line 215

LINE 217 -

Code: [Select]

    return bytes(cfram)
Now.. Line 220 - 261 is as follows

Code: [Select]

def read_rigol_model_serial(ip_addr):
    res = requests.post('http://%s/cgi-bin/welcome.cgi' % ip_addr)
    body = res.content
    m = SERIAL_PAT.match(body)

    if m is None:
        return None

    model = m.group(1).decode()
    ser = m.group(2).decode()
    ver = m.group(3).decode()
    mac = m.group(4).decode()

    print('Model: %s\nSerial: %s\nVersion: %s\nMAC: %s\n' % (model, ser, ver, mac))

    return model, ser


def apply_new_key(ip_addr, new_cfram, new_key):
    print('Applying new CFRAM...')
    exec_rigol_cmd(ip_addr, 'echo -n -e \'\\x03\' > /tmp/byte1', need_res=False)
    exec_rigol_cmd(ip_addr, 'echo -n -e \'\\x3d\' > /tmp/byte2', need_res=False)
    exec_rigol_cmd(ip_addr, 'echo -n -e \'\\x5b\' > /tmp/byte3', need_res=False)
    exec_rigol_cmd(ip_addr, 'echo -n -e \'\\xe5\' > /tmp/byte4', need_res=False)

    exec_rigol_cmd(ip_addr, 'cp /rigol/tools/fram /rigol/tools/fram01', need_res=False)
    exec_rigol_cmd(ip_addr, 'chmod +x /rigol/tools/fram01', need_res=False)
    exec_rigol_cmd(ip_addr, 'dd if=/tmp/byte1 of=/rigol/tools/fram01 obs=1 seek=%d conv=notrunc' % FRAM_OFFSETS[0],
                   need_res=False)
    exec_rigol_cmd(ip_addr, 'dd if=/tmp/byte2 of=/rigol/tools/fram01 obs=1 seek=%d conv=notrunc' % FRAM_OFFSETS[1],
                   need_res=False)
    exec_rigol_cmd(ip_addr, 'dd if=/tmp/byte3 of=/rigol/tools/fram01 obs=1 seek=%d conv=notrunc' % FRAM_OFFSETS[2],
                   need_res=False)
    exec_rigol_cmd(ip_addr, 'dd if=/tmp/byte4 of=/rigol/tools/fram01 obs=1 seek=%d conv=notrunc' % FRAM_OFFSETS[3],
                   need_res=False)

    with tqdm(total=len(new_cfram)) as pb:
        for i, b in enumerate(new_cfram):
            exec_rigol_cmd(ip_addr, '/rigol/tools/fram01 -w %x %02x' % (i, b), need_res=False)
            pb.update(1)

    print('New CFRAM applied.\n')and we are trying to get to  CFRAM APPLIED..

Your error spits out problems with
Line 431 -

Code: [Select]

    main()
Line 417 and 418 -

Code: [Select]

    if not prev_key:
        new_cfram = replace_cfram_key(cfram, new_key)
Line 172 -

Code: [Select]

    write_block(data, 0x100, pub_key, new_key)
Line 143 -

Code: [Select]

    assert len(block['data']) == block_len
AND HERE WE HAVE AN ASSERTION that uses the LEN command (Meaning LENGTH) It's checking the Length of Data.
Now... if the length of your data that it was checking was shorter or longer than expected, it would cause the error

but.. it doesn't explain why it's working for the rest of us.

But also if you were just running the -r over and over it wouldn't licence correctly either

so.. this is a better way to describe the problem for others that are looking at it.
Now let's see where we go from here

Logically.. it follows that the code is correct and working for the rest of us.
it also follows that if your scope is an MSO5074 as is ours and it is not faulty, that there would be no reason why
- it wouldn't work on your scope
- the script would discriminate against your scope

I just think you're not doing some of the steps correctly, whcih is why i think it's useful to do all those screenshots and in the meantime let's see who else responds.

How about that ?

[Sergey_21]

Okay, let's go over the moment of correctly installing Python and its modules; if at least one of the modules is not installed,
the script will not be executed at all, but we see that it is launched.

Here is the sequence I followed (according to your instructions):
1) installed firmware version 1.3.2.2
2) python rigol_kg2.py –i  xx.xx.xx.xx
3) python rigol_kg2.py –r xx.xx.xx.xx (we get an error, but the key file is being created)
4) python rigol_kg2.py     xx.xx.xx.xx
5) flash again firmware version 1.3.2.2
6) python rigol_kg2.py –i xx.xx.xx.xx
7) python rigol_kg2.py     xx.xx.xx.xx

Is everything right?

[BTO]

Okay, let's go over the moment of correctly installing Python and its modules; if at least one of the modules is not installed,
the script will not be executed at all, but we see that it is launched.

Here is the sequence I followed (according to your instructions):
1) installed firmware version 1.3.2.2
2) python rigol_kg2.py –i  xx.xx.xx.xx
3) python rigol_kg2.py –r xx.xx.xx.xx (we get an error, but the key file is being created)
4) python rigol_kg2.py     xx.xx.xx.xx
5) flash again firmware version 1.3.2.2
6) python rigol_kg2.py –i xx.xx.xx.xx
7) python rigol_kg2.py     xx.xx.xx.xx

Is everything right?

Not exactly, and as i suspected,  YOU'RE SKIPPING STEPS,
You've basically taken what i instructed and SUMMARIZED IT.   don't do that.
i we are going to help you, you have to follow the steps EXPLICITLY !!   You already have a problem  , skipping introduces more problems.

RE This

let's go over the moment of correctly installing Python and its modules; if at least one of the modules is not installed,
the script will not be executed at all, but we see that it is launched.

and.. No mention of what options you selected upon install python, You just SKIPPED to the part of installing the modules

Also, you didn't answer my question about zoom (i will therefore no longer ask, it will be upon you to ask if you want it now)

Now you stated 7 steps,  Mate in the PDF there are like 22 steps i think

but let's jump to step 3 in your list

3) python rigol_kg2.py –r xx.xx.xx.xx (we get an error, but the key file is being created)

OK, so if you got an error while creating the priv.pem  why did you proceed ?

but also, we didnt' get a screenshot to show any of this
Now re this

4) python rigol_kg2.py     xx.xx.xx.xx

You said that you ran  -r
then you ran  the script

HOWEVER IN YOUR SCREENSHOT IT IS CLEARLY SEEN THAT YOU RAN 
-r  then
-r
then the error happened

so like i said.... Start it all over again, Follow those instructions that i gave you.
Give us the screenshots, Each and everyone in a separate comment.  I know it's a pain, but it will help immensely and will get your scope
licensed correctly,   ARE YOU ABLE TO DO THAT ?

I want to help you, but at times you're being vague and not precise.
so far i've activated 7 people, its unlikely that your scope is different to their one
and another 3 or 4 people have just done it on their own without a problem, we only had 1 complaint , and that was valid
and that was that i forgot to include the step with the modules in the pdf,  i've corrected this

so..
we know the script works
we know the PDF works
we know our scopes are the same

the only 2 things that are variables are..
You... and Your computer

Are you able to try the process on another computer by any chance ?


Also... You know how you suggested there is a problem with the script and we should get DrMefist0 involved.
here is my opinion of what is happening with him
1. i reckon he's busy
2. i reckon he's see the post and isn't bothering because he knows there isn't a problem with the script.
Guys like DrMefist0 don't just jump in for any reason, but i reckon if there was a valid problem with the script, he would jump in and rectify it.

i reckon he's just waiting for all of us to troubleshoot through it, Exercise some common sense and work through the problem without him
getting invovled as there is no need to.
Again, Many others are doing it without problem.   this problem is isolated to you and we need to weed out what's going on.

Now, he wrote the script, Fair enough,  I know enough python to see what's in the script, but clearly he is more fluent at python that i am.
Not to say that i don't understand it though. but it's a pretty straight forward script to understand what's going on

ON ANOTHER QUICK NOTE and i don't know if this may benefit you, You can go ahead and try it as well.

as per the PDF, we are
Downgrading from 1.3.3.0  to 1.3.2.2
then we are applying the -r     then running the script
then we run 1.3.2.2  again
then we run the script again
and that activates it.

A USER BROUGHT UP... Why don't we just activate it from 1.3.3.0
Now.. there are downsides to this
THE MAIN BEING... when you do the full activation you end up on 1.3.2.2 and then you UPGRADE to 1.3.3.0 and you can see confirmation
that options survived activation.

I have not actually tried to run the script from 1.3.3.0  , MAYBE YOU WANT TO GIVE IT A GO, it can't hurt, Worse case,  it doesn't license it.
you've lost nothing
I'm going to try and give it a go in the near future, just to see what happens

so... I REALLY REALLY BELIEVE if you put in the effort to give us all those step by step screenshots

1. we can get to the root of the problem
2. it was ABSOLUTELY help others if they have the same problem

what are your thoughts

[BTO]

Okay, let's go over the moment of correctly installing Python and its modules; if at least one of the modules is not installed,
the script will not be executed at all, but we see that it is launched.

Here is the sequence I followed (according to your instructions):
1) installed firmware version 1.3.2.2
2) python rigol_kg2.py –i  xx.xx.xx.xx
3) python rigol_kg2.py –r xx.xx.xx.xx (we get an error, but the key file is being created)
4) python rigol_kg2.py     xx.xx.xx.xx
5) flash again firmware version 1.3.2.2
6) python rigol_kg2.py –i xx.xx.xx.xx
7) python rigol_kg2.py     xx.xx.xx.xx

Is everything right?

ATTENTION SERGEY

Mate, You may be in some luck here.
Recently i had a member who had your exact same problem

- After following the standard procedure and then re applying the update and then running the script, it still didn't work.
- We did a bit of troubleshooting and we got there and activated and licensed

CREDIT GOES TO SEPPLETRONICS

I have attached  A NEW PYTHON SCRIPT

I would like you to do the following (No need for screenshots, Just do this)

STEP 1- Download the script called

Code: [Select]

rigol_kg2_3_000 in the attachment

Ensure your scope is on 1.3.2.2

STEP 1 - Delete your priv.pem key from it's location
STEP 2 - Delete the old script from it's location
STEP 3 - Open your command prompt or Powershell and copy the NEW SCRIPT into the location of the directory that the shell opens in
             (I'm assuming here that you still have python correctly installed with all the modules)

STEP 4 - Run the -i command like this

Code: [Select]

python rigol_kg2_3_000 -i 10.1.1.666   replace 10.1.1.666 for your I.P. Address

STEP 5 - Run the -r command

Code: [Select]

python rigol_kg2_3_000 -r 10.1.1.666

STEP 6 - CONFIRM THAT YOU DON'T HAVE ANY ERRORS
             CONFIRM THAT THE priv.pem FILE IS IN THE SAME LOCATION AS THE SCRIPT
             CONFIRM THAT YOU GOT 2 PROGRESS BARS INSTEAD OF ONE
STEP 7 - Run the script without the switch

Code: [Select]

python rigol_kg2_3_000 10.1.1.666
             CONFIRM THAT YOU GOT 2 PROGRESS BARS INSTEAD OF ONE
When this completes, it will NOT have activated Options

STEP 8 - SHUTDOWN YOUR SCOPE

STEP 9 - Put the 1.3.2.2 GEL File on USB and as before , go to PRE BOOT and select Upgrade Firmware , to load over 1.3.2.2 again
Take the USB Stick out and Restart your Scope

STEP 10 -  Run the -i command like this

Code: [Select]

python rigol_kg2_3_000 -i 10.1.1.666 

STEP 11 - Run the script without the switch

Code: [Select]

python rigol_kg2_3_000 10.1.1.666

NOW ..... PLEASE TELL ME THAT YOU ARE SUCCESSFULLY ACTIVATED AND LICENCED WITH "FOREVER"


Give that a go.

If it works.... Do not forget

Step 12 - Upgrade to 1.3.3.0
Step 13 - DO YOUR BACKUP from the 1.3.3.0 Backup files
then..
Step 14- Do Self Check - 3 Tests
Step 15 - Do Self Cal

Mate if this works,  Also do me a favour, can you please send me a list of WHICH OPTIONS YOU HAD INSTALLED AT THE TIME OF PURCHASE.