开云体育

I recently acquired a TDS 3014B 'scope.
It looks fine and operates as it should, except for its LAN interface.
In the beginning (first half day since I got the 'scope), it could sometimes be configured and would be OK for a while, then stop after a few minutes.
Now, after a few days, the LAN interface does not work at all and even hangs up (blocks) the 'scope when I select the DHCP button in the LAN setup menu:

Immediately after I press the DHCP enabling button, the usual popup telling me it'll try and acquire an IP address appears. After that, everything stays frozen and no buttons or knobs respond. The only way to get out of that situation is power cycling, however after that, the scope shows its normal background, graticule, numbers etc. but no traces appear and it does not respond to operating keys or knobs.
The only remedy seems to be power cycling while doing a Reset by keeping the "B Trig" button depressed during power up.
This to me looks like a hardware/firmware failure. I haven't found a way to completely disable/enable the LAN interface, thereby possibly resetting the thing.

I'd very much appreciate any remedies, ideas or info.

Raymond

On Sun, Sep 20, 2020 at 12:30 AM, Raymond Domp Frank wrote:

This to me looks like a hardware/firmware failure. I haven't found a way to
completely disable/enable the LAN interface, thereby possibly resetting the
thing.

I'd very much appreciate any remedies, ideas or info.

I forgot to mention that after the problem appeared, I upgraded the 'scope from firmware version 3.27 to 3.39 and even to 3.41 (the latest version) to no avail.

Raymond

I seem to recall there being a known issue with these and DHCP.
Have you tried setting a static IP appropriate to your network, leaving
DHCP turned off?

Dave Casey

On Sat, Sep 19, 2020 at 5:33 PM Raymond Domp Frank <hewpatek@...>
wrote:

On Sun, Sep 20, 2020 at 12:30 AM, Raymond Domp Frank wrote:

This to me looks like a hardware/firmware failure. I haven't found a way

to

completely disable/enable the LAN interface, thereby possibly resetting

the

thing.

I'd very much appreciate any remedies, ideas or info.

I forgot to mention that after the problem appeared, I upgraded the 'scope
from firmware version 3.27 to 3.39 and even to 3.41 (the latest version) to
no avail.

Raymond

On Sun, Sep 20, 2020 at 12:36 AM, Dave Casey wrote:

I seem to recall there being a known issue with these and DHCP.
Have you tried setting a static IP appropriate to your network, leaving
DHCP turned off?

Hi Dave,
Thanks for your response. I have tried not using DHCP and using the static address that the 'scope acquired when the LAN interface was still working. I could find it in the router's configuration.
Since the lock-up really looks like the 'scope's program crashing and the instrument becoming blocked, I was thinking about a hardware/firmware problem and processing my disappointment.
In my worries about it being such a problem, I haven't yet configured a different (static) IP address from the time when it still worked and try (ping) that. I'll be in the lab on Monday and will try.

Do you by any chance remember whether the problem you're referring to blocked the instrument altogether?

Raymond

I didn't experience the issue myself; I have always used static IP. I
haven't used it hours on end, but I've had no issues for relatively short
uses of the scope.
Remember to pick a static IP in the range allocated by your router to avoid
the DHCP server from assigning the same IP address to another client.

Dave Casey

On Sat, Sep 19, 2020 at 5:49 PM Raymond Domp Frank <hewpatek@...>
wrote:

On Sun, Sep 20, 2020 at 12:36 AM, Dave Casey wrote:

I seem to recall there being a known issue with these and DHCP.
Have you tried setting a static IP appropriate to your network, leaving
DHCP turned off?

Hi Dave,
Thanks for your response. I have tried not using DHCP and using the static
address that the 'scope acquired when the LAN interface was still working.
I could find it in the router's configuration.
Since the lock-up really looks like the 'scope's program crashing and the
instrument becoming blocked, I was thinking about a hardware/firmware
problem and processing my disappointment.
In my worries about it being such a problem, I haven't yet configured a
different (static) IP address from the time when it still worked and try
(ping) that. I'll be in the lab on Monday and will try.

Do you by any chance remember whether the problem you're referring to
blocked the instrument altogether?

Raymond

I'm pretty sure I've found the answer to my problem, though maybe not a solution.
In my earlier message, I forgot to mention that I replaced the battery in the Clock/NVRAM module, since the time indication was intermittent, as was the functioning of the LAN connection. I was hoping to not only restore the functionality of the clock but also to restore the LAN's functionality, although the RAM would have continued to work even without battery backup. What I hadn't realized was that the NVRAM module could have stored the LAN adapter's MAC address, which of course was lost after disconnecting the old battery and reconnecting a new one. It turns out that the NVRAM does indeed store the LAN adapter's MAC address.
I found that information here:

Unfortunately, I don't think a copy of the MAC address is still stored in my router so, unless any valid MAC address will do, I guess I'm stuck because I don't think there's a label containing the MAC address anywhere on or in the 'scope. I guess the MAC address on an old adapter, no longer in use, would be valid but whether it'll be accepted and how to enter it remains to be seen.
Local time where I live is 2:55 (AM) so it's time to quit for the night.

Raymond

The thread behind the link I gave earlier (yesterday) does indeed exactly describe my problem and my 'scope's behavior.
There's a valid copy of a TDS 3014B NVRAM available as well. That means, I'm now looking for a way to "program" my DS1742W. That device, which basically looks like (and is) an SRAM, isn't directly supported by my programmer, a TL866II plus. A poster on the thread mentioned that he used his TL866II and I have contacted his blog but got no answer yet (it's only been a short while).
I have no problem finding a supported regular SRAM but the 3.3 V Vcc spec for the DS1742 -W version could be a problem.
Would it be safe to treat the DS1742W (3.3 V) as a DS1742 (5 V) for the copying operation? According to the data sheet, Vcc max is 6 V (not mentioned separately for either version) and Vin max is specified as Vcc + 0.6 V.
I'm pretty sure I can find a regular(almost) pin-compatible 2 kbyte SRAM from the supported list and connect that to the TL866II plus, if necessary with a few wires for pin compatibility.

Raymond

On Sun, Sep 20, 2020 at 04:39 PM, Raymond Domp Frank wrote:

Would it be safe to treat the DS1742W (3.3 V) as a DS1742 (5 V) for the
copying operation? According to the data sheet, Vcc max is 6 V (not mentioned
separately for either version) and Vin max is specified as Vcc + 0.6 V.
I'm pretty sure I can find a regular(almost) pin-compatible 2 kbyte SRAM from
the supported list and connect that to the TL866II plus, if necessary with a
few wires for pin compatibility.

This is turning into a monologue. I don't mind.

The closest (and much closer than I expected) 3.3 V (DALLAS) NVRAM device that I have found so far is the DS1250W. It's a 512K x 8 device, RAM only, so no RTC.

A simple pin-converter is needed: A 24-pin socket for the DS1742W is placed above a 32-pin socket + header with pins 7 - 28 of the DS1250W corresponding with pins 1 - 24 of the DS1742W.
Pin 29 of the DS1250W is re-routed to pin 21 of the DS1742W and pin 32 of the DS1250W is re- routed to pin 24 of the DS1742W. The original straight-through connections of these two sets are removed, the remaining 22 connections go straight-through.
I haven't yet looked at possible WE/OE/CE (timing) discrepancies in the programmer but I'm confident things will be OK. Only the first 2K of the "DS1250W" will be written.

I'll report back (or possibly, continue this monologue) with results.

Raymond

On Sun, Sep 20, 2020 at 08:03 PM, Raymond Domp Frank wrote:

The closest (and much closer than I expected) 3.3 V (DALLAS) NVRAM device that
I have found so far is the DS1250W. It's a 512K x 8 device, RAM only, so no
RTC.

... and supported by the TL866II plus, of course, because the main issue is that the DS1742W isn't...

Raymond

Raymond,
I have seen several TDS30XXB scopes with flaky power supplies. The problem is in the optoisolator used for feedback, which looses gain with age and demands too much current from the TL431 reference, causing the supply to sag and the reference to overheat (and sometimes die).
Check to see if the power supplies are behaving during startup. I am not sure, but you might be able to monitor the supply adequately via the +15V output jack on the back.
--John Gord

That may be a very useful hint, John! Simple to check and repair.
I'll check the PSU and its startup behavior, although it seems that the problem with Ethernet connectivity is caused by the NVRAM battery failing, resulting in intermittent running of the clock and loss of the MAC (hardware) address. I found a complete description of my problem, complete with cause and all symptoms, on EEVBlog.

Raymond

On Sun, Sep 20, 2020 at 08:03 PM, Raymond Domp Frank wrote:

A simple pin-converter is needed: A 24-pin socket for the DS1742W is placed
above a 32-pin socket + header with pins 7 - 28 of the DS1250W corresponding
with pins 1 - 24 of the DS1742W.
Pin 29 of the DS1250W is re-routed to pin 21 of the DS1742W and pin 32 of the
DS1250W is re- routed to pin 24 of the DS1742W. The original straight-through
connections of these two sets are removed, the remaining 22 connections go
straight-through.
I haven't yet looked at possible WE/OE/CE (timing) discrepancies in the
programmer but I'm confident things will be OK. Only the first 2K of the
"DS1250W" will be written.

I'll report back (or possibly, continue this monologue) with results.

In my ecstasy about the successful revival of my TDS3014B's Ethernet interface using the procedure described above, I forgot to thank those who helped me.

Thanks!

Raymond