TDS3014 adventures

[ArcticGeek]

DS1558 won't work, the register map is different, it has a lot more features and some things are moved around. Maybe there is another similar part that is the same as used in the DS174x parts.

@James
Yea, I was aware of the difference between the DS1742 and DS1558, but I believe it will still work.  You will notice that address range XXX8 thru XXXF are identical between the two parts, its just that the DS1558 has some extra regs from 0 thru 7.  Since the DS1558 has a full 512K of address space and the SRAM is only 2K, you can play a trick on the address bits of the DS1558 to fool it.  The DS1558 will forward the chip select to the SRAM only if the address lies outside of the range of 0-F.  If the address lies within the FFFFF0 and FFFFFF range then the DS1558 does not assert CS to the SRAM and it responds on the bus.

I believe the following trick will work:

The address pins A[0:10] of the SRAM are wired to the scope address pins A[0:10] as they should be.

Address pins A[0:2] of the DS1558 are wired as they should be to pins A[0:2] of the scope address bus.  Address pin A3 of the DS1558 would be tied high to 5V.  Addr A[4:10] of the DS1558 is connected to A[4:10] of the scope as well.   But address pin A11 (or any other higher address for that matter) of the DS1558 is connected to A3 of the scope.  In this way, anytime A3 is low (such is the case in address range 0-7), the DS1558 will not recognize it as a valid range for it to respond on the bus and will forward the chip select to the SRAM.  All of the other address bits of the DS1558 would need to be tied high to 5v. 

Doing it this way, the DS1558 would respond on the bus anytime the address was in range of 7F8-7FF, and its register map would be identical to the DS1742.  However, when the scope accesses address range 7F0-7F7 the DS1558 would see this address as 7FFE8-7FFEF and would not respond on the bus and forward the CS to the SRAM.  This would have the effect of making the memory map of the DS1558 identical to the original DS1742.
The DS1558 regs at 7FFF0-7FFF7 are never accessible, but that's okay because they'll never be used anyway.

I haven't looked at this in super detail, but I'm fairly sure it would work.  I hope my explanation makes sense!

[james_s]

Hmm ok so looking over these maps again, they're *almost* identical except for one thing, BF the battery flag is at 7FC on the DS1742 and 7FFF3 in the DS1558. In this particular application I don't think that matters since as far as I know these scopes never look at the battery status. I might have to build something at some point just to see if it would work, I looked around and it seems the DS1558 is the only similar standalone RTC IC that they still make.

I've also pondered various solutions with a CPLD or small FPGA which could easily do any kind of address translation desired and it should also be possible to interface a modern serial RTC to the bytewide format. It might even work to use a serial FRAM based EEPROM combined with block RAM in the FPGA to eliminate the need for the SRAM and battery management.

I wonder if the still available TDS3054C still uses the same obsolete timekeeping RAM?

[ArcticGeek]

Yea, I had noticed the battery flag as well, but I would be very surprised if that bit is ever looked at in the Tek firmware.

To answer your question about the TDS3054C, yes, I believe it probably has the exact same DS1742W part.  I have a TDS3014C and it has the DS1742W part.  I haven't replace it yet, but as I recall it is getting close to the 10-year mark and will be due for replacement fairly soon.

[james_s]

Well this scope is fairly old, the DS1742 was date stamped '99 IIRC so you might still have some time. Mine was dead enough that the RTC wouldn't keep time but the RAM would hold its contents, that surprised me since the battery measured 0.6V. Anyway assuming my adapter works I'll send you one of the boards if you want, I had to get 5 of them and I'm unlikely to ever need more than one. I believe the DS1742W went out of production in 2018 which makes me wonder if Tek is still manufacturing these scopes or just selling existing stock. I was a bit shocked to see they still retail for over $20k new. That's a lot of money for something with a 10 year time bomb soldered to the mainboard.

Or you can of course just hack in a new battery, just don't use a programmer that will give the thing 5V to dump the contents. I'm thinking I'll just make up an adapter so I can use the switches, buttons and displays on one of my FPGA dev boards to just hand program the 4 bytes that store the on-hours. Everything else can be set through the menu in the scope.

[ArcticGeek]

Yes, I would definitely be interested in getting one of your PCBs when you get them.   I'll send you a PM for the details - thanks much!

My TDS3014C is fairly old now, too, maybe around 10 years old I'm guessing.   I bought it on Ebay about 5 years ago and it wasn't new then.   I agree that $20K for a TDS3054C today would be a bit of a ripoff, these scopes are great for hobbyist use but a bit long in the tooth for professional use.   I don't know why Tek continues to use these Dallas/Maxim RTC chips that aren't replaceable.  They started to use them in the 2465B scopes and have continued since then.   I haven't opened any of their brand new scopes, but I know that even the higher end TDS5104 and TDS7104 used these things.

[techman-001]

I don't know why Tek continues to use these Dallas/Maxim RTC chips that aren't replaceable.  They started to use them in the 2465B scopes and have continued since then.   I haven't opened any of their brand new scopes, but I know that even the higher end TDS5104 and TDS7104 used these things.

This thread had me worried, then I remembered the scope I use everyday is made by HP (54601A HP DSO circa 1994) , and has no Dallas/Maxim RTC chip in it

I'm pretty sure my only other scope, a Tek 7000 series mainframe doesn't have one either ;-)

[james_s]

I remember thinking years ago that the Dallas chips seemed like a neat idea, this was after spending a lot of time cleaning up huge messes caused by leaking NiCd memory backup batteries on 80s arcade boards and vintage computers. I've also seen a number of computers completely destroyed by leaking lithium thionyl chloride batteries however it's very rare that I've ever seen a lithium coin cell leak and when it has happened the damage was localized to the battery holder. Anyway in retrospect it's an idiotic idea to pot a battery inside a module, just use a battery type that is not prone to leaking!

In case anyone else is interested, I reverse engineered the serial portion of the TDS3GV comm module, there was already another thread on that which I'll link here rather than fragmenting information all over.

https://www.eevblog.com/forum/testgear/reverse-engineering-tektronix-tds3gv-module-for-tds3000-series-oscilloscopes/new/#new

[ArcticGeek]

There are some benefits of using these encapsulated RTC modules.  Obviously, one benefit is that design is relatively simple compared to the added complexity of having a battery, holder, RTC, and SRAM. 

But another benefit is guaranteed battery life.  You would be surprised how poor the battery life of a NVRAM/RTC can be if the PCB is not completely clean of any type of flux residue/contamination. 

I worked on a project some 20 years ago where I designed a custom Intel 386/486 computer platform, and that design used a Dallas RTC chip with an external lithium battery.  As I recall the normal battery current was in the 200nA range; this would yield at least a 12 year life for the product.  However, many boards failed early due to the battery being exhausted, and analysis found that the battery current on those failing cards was in the 20-50uA range - nearly 200 times the current!   It was all caused be boards that were not perfectly clean, but yet even under the microscope they looked good and clean.  The circuit itself was fairly simple, but yet just a little bit on uncleanliness caused dramatic reduction.  it took quite a bit of effort to get the card supplier to keep the process in control.   The lesson I learned from this is you have to be very careful on these sub-uA circuits to make sure you keep stuff very clean.   

Using an encapsulated module gets rid of any of these issues, and I can kinda understand how Tek sees the advantage of using them.

[texaspyro]

The lesson I learned from this is you have to be very careful on these sub-uA circuits to make sure you keep stuff very clean.   

One thing that is often overlooked is handling of watch batteries.  A finger print across the edge of the cell can cause the battery to drain rather rapidly.   Never handle the batteries with bare hands!   Also, it can help to first clean the cells with alcohol.

[james_s]

I think the PowerCap arrangement is a much better design though. One type of PowerCap can work with any number of RTC/NVRAM types, it's a lot more economical than keeping a whole selection of old products in production that all have a use-by date due to the encapsulated battery.

Also I'd much rather have a battery that doesn't last as long as it should than an instrument that needs to be sent in for an expensive repair. I mean Tek didn't even socket the part, clearly they did not intend it to be field replaced and 10 years is not all that long of a life for such an expensive piece of equipment.

[james_s]

So I'm still waiting for my boards to arrive from JLC PCB so no movement there. I do however have some other stuff to share that some might find interesting. I decided to play with the DS1742W and threw together an adapter to connect it to one of my FPGA boards. The FPGA is not really doing much other than serving as a patch panel to conveniently route the switches and buttons as well as provide decoded hex displays. This shows selected address, byte to be written, and byte read with the byte read also shown on the red LEDs, convenient for manipulating individual bits.

So I started poking at the DS1742 while referring to the datasheet, I have a much easier time understanding something if I can actually see and touch it vs just studying the datasheet. Anyway I figured out why I've had difficulty programming these things in conventional EPROM programmers, it turns out that in order to modify any of the clock related registers you must first write a '1' into the 'W' bit of the control register, otherwise they are read-only. By default (with a dead/missing battery) it also seems to power up with frequency test enabled, this causes bit 0 of the seconds output to toggle at 512Hz which can cause strange behavior if it gets enabled by mistake. The DS1642 used in the TDS300 series has the same feature and it causes the displayed time to jump around erratically. Anyway I thought this was pretty cool stuff, I can hand program it, setting the time and date and watch the clock run and a setup like this is fully adequate for setting specific bytes like the power-on hours of the scope, no EPROM programmer needed and very little chance of anything getting accidentally corrupted.

As I was messing with this I happened to be looking at the status register when I bumped the DS1744 and the battery flag LED came on! Additional poking revealed that the fault that set me down the road of building a replacement DS1742W is actually a cracked joint down under the epoxy where the nickel strip that connected the original battery is soldered to the PCB. This means I should be able to repair it easily enough and that would have saved me 60 bucks. Since I already bought the parts I'm going to continue down the path of building a replacement and assuming that works I'll share the design so others can use it and keep the original DS1742W as a spare.

Incidentally the PowerCap version of the DS1744 arrived and it is a bare un-potted PCB with a commodity SRAM and DS1744D TQFP IC on the bottom. I don't think Maxim sells the bare DS1748D but it must be exactly what is in the currently made potted versions as well. Wish I could just buy that IC and build a direct fit DS1742W module.

Something else I think might be interesting to do at some point is further reverse engineer the TDS3000 and other instruments that use these NVRAMs and find out exactly what locations are used to store what. It would be very easy to wire up an FPGA board in place of the DSxxxx and use internal dual-port block RAM which can be monitored/dumped/poked live. This would be of greater interest to me on instruments like the TDS300 series that store the cal constants in the NVRAM, I have two of those and a friend has a third that all work fine but display a calibration error on power up. I was able to calibrate the voltage with difficulty but the timing calibration is too finicky for any sort of pulse generator I have access to. Perhaps it would be simpler to disassemble the firmware and attack it from the other direction, I don't know, I'm more of a hardware guy.

[james_s]

Finally got the boards I ordered from JLC PCB and built the adapter today. I'm pleased to report that it worked perfectly right off the bat, just plug it in and go. After verifying that it worked, I used the FPGA board I was playing with before to set the power-on hours and now it's buttoned up and finished.

Adapter board gerbers and design files here:
https://github.com/james10952001/DS1744WP-to-DS1742W-adapter

This should work for any application of the DS1742W however you'll want to verify the mechanical fit if you are wanting to use it in anything other than a TDS3000.

[giosif]

Congrats on your work and thank you for sharing with everyone else here!

[ArcticGeek]

Nice work - glad to see that it worked right out of box!  Thanks for sharing with the community.

[daveyk]

Hello James.  Do you have any extra boards that you had made up that you would sell?

Dave

[analogRF]

In case anyone cares, I took a look at my notes today and the power-on hours are simply stored as the number of minutes in hex format in locations x7E0 through x7E4 in the DS1742W. I'm not sure why this wasn't immediately obvious to me last night, I guess I was tired.

what about the number of power cycles? I think it must be sitting in this chip because when I lost the data on mine (3054B) that value also got lost

[james_s]

No, not in the non-letter series at least, I don't have a B series to check. My power-on count remained after replacing the NVRAM.

[Kodim]

Known issue. In my TDS3054, the lithium battery in the DS1742 chip died. As I understand it, there are two ways to solve this problem. Replacing the old battery mechanically in the original DS1742 and making an adapter for the DS1744. I do not have a programmer. Can I perform any of these operations without a programmer? Thanks.

[james_s]

Yes you can do either one. The only thing you need a programmer for is if you want to retain the power-on hours, though I suspect there is a way to write this via GPIB.

If you power on the scope while holding down a button (B Trig I think?) it will initialize a blank NVRAM.

[Kodim]

James, your comments helped me rebuild my TDS3054 oscilloscope. I remove old battery from the DS1742W chip and install an external battery. I did not use the programmer. Operating time was  not reset. Everything is fine! Thanks!

[giosif]

Just wanted to thank James, as well as the other contributors, for the nicely detailed repair and mods here, as I just brought a seemingly dead TDS 3034B back to life.
The culprit? The same 75.757 MHz crystal which had stopped oscillating.
New replacement crystal ordered (currently using a 50 MHz one I happened to have in the spares box).

Now, on to the next issues: acquisition test fails and channels 3 and 4 seem to be "linked" with each other (i.e. if I feed signal straight into channel 4, I don't get any waveform displayed for channel 4; if I feed the signal into channel 3, I get the same trace displayed for both channels 3 and 4).

[james_s]

That's an odd one, there must be some kind of mux? Hopefully it's not inside one of the ASICs.

[giosif]

I suspect the same, but I need to do more investigations.
Will report back any findings.

[james_s]

Put the proper oscillator in there first before you expend TOO much effort. I doubt that's the issue here but it's not impossible. When I put the 27MHz oscillator in mine for testing it booted up but it was not usable. It's possible that the multiplexing is dependent on the timing.

[giosif]

That did cross my mind but, then, strange it would happen only with channel 4.
As you say, it's unlikely that is the culprit but I'll check once I've installed the correct crystal.

From another perspective, I was wondering how it could happen that signal fed into channel 3 shows up for channel 4 as well.
From an analog input perspective, it can't happen, since each channel is independent all the way to the ADC, including.
From a digital point of view, the ADC shouldn't matter (as in, whether it is working or not), since each channel has their own.
So, the problem must be with storing/retrieving the waveform data to/from memory.
Specifically, I'm thinking that maybe one address line might be stuck either high or low and, whenever the memory range for channel 4 is being addressed, it ends up accessing the memory for channel 3.