The manual mentions zero'ing the probes, which may be stored in the eeprom that differed. Also, calibration data may be stored there. The manual mentions firmware updates but I don't see any available on their website. As always, your diagnostic skills, repair skills, and knowledge are a pleasure to follow.
Congratulations on repair! My THDP0100 have input attenuator potted with silicon gel from both sides. I'd expected that would be necessary since THDP0100 rated for much higher 6kV voltage rating. Also P52XX series probes use very similar design, but have smaller bandwidth. THDP/TMDP are just updated version for TekVPI.
It will be interesting to see how this repair holds up over time. It can very well be that that little Mega8 has worn out its internal EEPROM (like those Teslas a few years back) and this fix is only temporary.
EEPROM data corruption is huge problem with atmega. Sometimes first byte of the EEPROM gets corrupted durring power-down or in high-noise enviroment. There is workarounds, but it might bite you bad in high-volume product.
Perhaps that EEPROM data is calibration information? It would make sense to store that there, and you probably wouldn't notice a slight change in calibration (from using the calibration from the other device)?
Would have to check the EEPROM info after the autocal, and see if it has changed slightly. Very likely the EEPROM stores both the switch states and the autocal constants in it, and this means that it has a large number of writes to it. One either finally killed a bit, or the power failed from the broken cable during a write, corrupting a few of the bits. Looks like there is no wear levelling done there, just write the same blocks over and over, without even doing the simplest thing and writing multiple copies, and reading them, with a checksum, to see the valid ones. Simple in the firmware, unless they were running out of ROM space, to implement that with only a small amount of code, and then either rewrite the faulty data, or have the UI pop up an error message that the probe calibration is inconsistent and it needs service, or just log this as an error and continue with a degraded reading warning.
@@SeanBZA It's straightforward to do, not necessarily simple. I'm assuming they're using C*, so Checksumming is easy provided that they read/write a struct and always call the function. It's even easy to do replication of that struct. However, this naieve solution has multiple problems: * If you do data replication, you're also replicating the checksum. * You could be doing a 4 byte checksum of a single bit of data! * It's easy to forget to call the checksum function. (C++ solves this) If you want to just do data replication, then you either need a translation layer, or at least several helper functions. With the danger being that it's easy to forget to use it for one critical part of data. Now, you can work around some of these issues by doing a checksum on startup and after every write, but that doesn't solve the wear leveling issue. Personally, that would be my approach. Just because the failure mode during development is the MCU reports a problem instead of silently working. * I personally prefer using C++ even in embedded applications, but there's a crowd of rabid C users.
It remember me to a Philips TV set, when switch off the processor getting corrupted from the CRT discharge. The sollution was a shield connected to ground.
That's great. Pooch in person means empty or void. And it preferably matches with cat's character, because it looks like he can handle (claw) any instrument readily ... Just like a C void pointer
Hello, you introduced the RIGOL DM3068 a long time ago. Now it's 10 years later and I'm asking you, does it still make sense to buy this device new today or is there something better in this price range. Many greetings.
Yes. The capacitors provide the HF reading and the resistors provide the LF detection (and DC if they have magic to send that signal through the transformer). The resistors also provide a passive balancing for the capacitor voltages so a weaker capacitor or one with different leakage currents does not get a lager share of the divided voltage with slow signals.
@@jessicav2031 Probably makes the service centre life easier, seeing as they do have to update them during service, and with a long model life unprotected code is easier to fix. After all you are paying big for the scope, so will pay equally high for certified accessories as well. Cheap copy will be hard to certify and still sell.
@@SeanBZA It's possible to only read protect AVRs without disabling programming. You can't read the code, but erase the whole thing and flash new content.
maybe the eeprom contains a checksum that was corrupted, and the probe AVR refused to do its work? A lot of Thinkpads died that way, back in the day :D
Guessing scope must update probe firmware and someone’s scope crashed or they unplugged mid-update. Or maybe hit auto-zero and unplugged leaving eeprom in corrupted state.
Could be, or it simply hit the write endurance of the eeprom, at least till the entire device was erased during the copy of the new firmware, which might silently have swapped out the failed bit using a spare row. After all during manufacture you want to have higher yield, so having a device erase, rather than block or bit erase, might also include a memory zero check as part, and failed bits are replaced with the spare row in the device, till the few spares run out. Tiny bit of extra silicon, often otherwise unusable, and a few extra cells to do the swap permanently.
"read out the firmware" - this is the first time I heard of a case is not read-out protected.... Also: normally this type of probes are not isolated. Are you sure this one is ?
Not isolated, just has very high common mode impedance, so ground current is very small in almost all cases, and with a balanced connection to both channels affects them identically.
Wow, getting more and more technical... both an X-Ray AND a cat scan all in the one video!
I'm surprised that the lockbits aren't set. In consumer electronics, it's quite rare to be able to pull firmware from MCU's.
I was shocked!!
Thanks to the guys at Tektronix for not Lock-bitting everything out.
And TIN for downloading the original firmware, nice collaboration ;-)
I've used that trick of auto detecting board type/rev in firmware using pullup resistors. Makes life so much easier!
Nice job on the probe repair!
The manual mentions zero'ing the probes, which may be stored in the eeprom that differed. Also, calibration data may be stored there. The manual mentions firmware updates but I don't see any available on their website. As always, your diagnostic skills, repair skills, and knowledge are a pleasure to follow.
Always good to have friends who can help out!
Congratulations on repair! My THDP0100 have input attenuator potted with silicon gel from both sides. I'd expected that would be necessary since THDP0100 rated for much higher 6kV voltage rating. Also P52XX series probes use very similar design, but have smaller bandwidth. THDP/TMDP are just updated version for TekVPI.
you are the best man and we all love you for it 😇
It will be interesting to see how this repair holds up over time. It can very well be that that little Mega8 has worn out its internal EEPROM (like those Teslas a few years back) and this fix is only temporary.
That would sound about right!
If this happens again it would be a simple matter of swapping the processor with a new one.
@@Thesignalpath lucky you, that Tek didn't blow the read protect fuse in the Mega.
👍 for Beyond Compare. Great diffing program.
EEPROM data corruption is huge problem with atmega. Sometimes first byte of the EEPROM gets corrupted durring power-down or in high-noise enviroment. There is workarounds, but it might bite you bad in high-volume product.
You have a very special cat which is compatible with electronic lab. My congratulations!
Perhaps that EEPROM data is calibration information? It would make sense to store that there, and you probably wouldn't notice a slight change in calibration (from using the calibration from the other device)?
Would have to check the EEPROM info after the autocal, and see if it has changed slightly. Very likely the EEPROM stores both the switch states and the autocal constants in it, and this means that it has a large number of writes to it. One either finally killed a bit, or the power failed from the broken cable during a write, corrupting a few of the bits. Looks like there is no wear levelling done there, just write the same blocks over and over, without even doing the simplest thing and writing multiple copies, and reading them, with a checksum, to see the valid ones. Simple in the firmware, unless they were running out of ROM space, to implement that with only a small amount of code, and then either rewrite the faulty data, or have the UI pop up an error message that the probe calibration is inconsistent and it needs service, or just log this as an error and continue with a degraded reading warning.
@@SeanBZA It's straightforward to do, not necessarily simple. I'm assuming they're using C*, so Checksumming is easy provided that they read/write a struct and always call the function. It's even easy to do replication of that struct. However, this naieve solution has multiple problems:
* If you do data replication, you're also replicating the checksum.
* You could be doing a 4 byte checksum of a single bit of data!
* It's easy to forget to call the checksum function. (C++ solves this)
If you want to just do data replication, then you either need a translation layer, or at least several helper functions. With the danger being that it's easy to forget to use it for one critical part of data.
Now, you can work around some of these issues by doing a checksum on startup and after every write, but that doesn't solve the wear leveling issue. Personally, that would be my approach. Just because the failure mode during development is the MCU reports a problem instead of silently working.
* I personally prefer using C++ even in embedded applications, but there's a crowd of rabid C users.
It remember me to a Philips TV set, when switch off the processor getting corrupted from the CRT discharge. The sollution was a shield connected to ground.
Thanks for the heads up on what would present a real headache!
That's great. Pooch in person means empty or void. And it preferably matches with cat's character, because it looks like he can handle (claw) any instrument readily ... Just like a C void pointer
Very interesting, thanks for the video! We have two of those probes in the lab, so I was curious to see what's inside. Thanks again 🙂!
great repair, I would be interested in the teardown and review of micsig differential probes, specifically the DP750
i think there is some kind of strap resistors on the probe body board to determine the bandwith
Thank you for uploading tNice tutorials video , so much information!
Hi,
Did you try setting 0x01 at offset 0x04 in your EEPROM? Looks like it could be a bit flip:
06 09 72 08 0*0* 00 01 00 01 00
Another potential bit flip, this time from 0 to 1 is the 0x09 at offset 0x01
Did you already own this unit, or did you buy it on Ebay/etc. for cheap? In other words, how did you come to have it?
Picked it up from eBay. I think it was about $200.
Hello, you introduced the RIGOL DM3068 a long time ago. Now it's 10 years later and I'm asking you, does it still make sense to buy this device new today or is there something better in this price range. Many greetings.
Nice.
Why are there capacitors in parallel with the resistors for the input divider network? Is it to allow for AC measurements?
Yes. The capacitors provide the HF reading and the resistors provide the LF detection (and DC if they have magic to send that signal through the transformer). The resistors also provide a passive balancing for the capacitor voltages so a weaker capacitor or one with different leakage currents does not get a lager share of the divided voltage with slow signals.
@@KallePihlajasaari Awesome explanation! Thank you!
it'd be interesting to see if that flash chip keeps its memory, or fails again.
So, they didn't enable "code protection" option in Microcontroller?😮😯
This also shocked me, but ATMega8 is also quite ancient.
@@jessicav2031 Probably makes the service centre life easier, seeing as they do have to update them during service, and with a long model life unprotected code is easier to fix. After all you are paying big for the scope, so will pay equally high for certified accessories as well. Cheap copy will be hard to certify and still sell.
@@SeanBZA It's possible to only read protect AVRs without disabling programming. You can't read the code, but erase the whole thing and flash new content.
👍👍
If it's external resistors that set the model, why did a corrupt eeprom show the wrong model at the start?
maybe the eeprom contains a checksum that was corrupted, and the probe AVR refused to do its work? A lot of Thinkpads died that way, back in the day :D
@@tomteiter7192 but it displayed the correct serial number
@@TheFool2cool yeah, but that was stored in the "connector AVR" not in the frontend AVR
Interesting
Guessing scope must update probe firmware and someone’s scope crashed or they unplugged mid-update. Or maybe hit auto-zero and unplugged leaving eeprom in corrupted state.
Could be, or it simply hit the write endurance of the eeprom, at least till the entire device was erased during the copy of the new firmware, which might silently have swapped out the failed bit using a spare row. After all during manufacture you want to have higher yield, so having a device erase, rather than block or bit erase, might also include a memory zero check as part, and failed bits are replaced with the spare row in the device, till the few spares run out. Tiny bit of extra silicon, often otherwise unusable, and a few extra cells to do the swap permanently.
Maybe replace the eeprom and program again just in case the part is unreliable? Also nice to see a tool I use daily, beyond compare.
"read out the firmware" - this is the first time I heard of a case is not read-out protected....
Also: normally this type of probes are not isolated. Are you sure this one is ?
Not isolated, just has very high common mode impedance, so ground current is very small in almost all cases, and with a balanced connection to both channels affects them identically.
Compare the components on the two versions and try to make a 0200 out of 0100.
High time for an official firmware update that can detect and fix EEPROM corruption.
👍 for Pooch's opinion :-)
Classic AVR brownout issue....
Interesting fault with a nice repair! Did you extract the firmware over the SPI bus, or another way? I've not seen that done before.
For the science, zero eeprom and test it.
That fix just does not quite seem right to me.
Why not?
@@Thesignalpath Just the spidey-sense factor.
In my other comment, I agreed with a suggestion that the EEPROM might be worn out.