6C Master Hub lockup problem

[JoeKane]

I have been using the 6 Channel Master Hub, in conjunction with digitemp monitoring software to read a bunch of 1820s.

Every once and a while, the master hub appears to lockup. In each case, the 'Channel 1' red LED gets stuck on, until I power-cycle the Hub. I'm logging temps 24/7 every 15 minutes, and it takes months for the lockup to occur, and I haven't found any pattern to it yet.

Looking at my own error logs, I see that the failure appears to initiate a series of 'Setting switch to main on state failed' errors as the logger iterates through the master hub channels, none of which succeed. On the very next read (15 minutes later), the failure becomes (and remains) 'DS2480b is not detected'.

I would look to the software first, but it does initiate a one-wire reset at the beginning of each read cycle, and it really looks like the hub will no longer respond to it once its in this state. the fact that I initially get the 'setting switch to on' errors implies that rs232 is working fine.

And like I said, its consistently a locked up LED on channel 1, and a power cycle of just the hub fixes the problem every time.

 

[nightwalker]

I'll be watching this thread with a bit of interest. I had the same problem with the master hub. I never did solve it and finally moved to a temp08 unit that has not missed a beat since I swapped them. I have the master hub sitting in a box gathering dust at the moment. I thought it was software problem but was never able to pin it down to say for sure what the problem is. According to Eric there isn't really any test you can do for the hardware so in the box it sits.

It seemed strange to me that it would run sometimes for a day sometimes for a week, a few times for several weeks but then the lockup would come and I was SOL till i rebooted and then the cycle began again.

 

[ericvic]

What software are you using to read the 1-Wire network?

It seems like the DS2480B is getting in some strange state that only a power reset and fix.

Eric

 

[JoeKane]

What software are you using to read the 1-Wire network?

It seems like the DS2480B is getting in some strange state that only a power reset and fix.

Eric

The software is 'digitemp', if you're familiar with that: http://www.digitemp.com. Have been through the code quite a bit, seems like its doing everything on the up and up as far as one wire goes.

I found it curious that Nightwalker had/found a similar problem, possibly with a different software drive.

 

[nightwalker]

I was using mine to interface temp sensors with HomeSeer using the xapmcs1wire and xapmcshub along with the drivers and the plug-in to get that information into HomeSeer Devices. I never did figure out the problem. I kept going back and forth between hardware and software but never could pin it down. I know some are using it with the exact same software so for all I know it was system specific with mine or hardware. Since I'm using the exact same sensors and wiring with the temp08 I figured I could rule that out. I spent almost a year struggling with it until I just couldn't fight it anymore and threw in the towel.

 

[sda]

I would look to the software first, but it does initiate a one-wire reset at the beginning of each read cycle, and it really looks like the hub will no longer respond to it once its in this state. the fact that I initially get the 'setting switch to on' errors implies that rs232 is working fine.

It seems like the DS2480B is getting in some strange state that only a power reset and fix.

A 1-wire reset only resets the 1-wire bus, not the ds2480b.

http://datasheets.maxim-ic.com/en/ds/DS2480B.pdf

Read the first paragraph on page 5 which talks about sending a master reset to the device. That may not be possible with canned software, but if you've got the source have at it.

Did you by any chance extend the serial cable between the computer and the hub? This might create timing issues.

What if you restart the logging software instead of power cycling the hub? Could indicate a software problem if it starts working again. Could also be that the software sends a master reset when starting.

What if you reboot the computer instead of power cycling the hub? Could indicate a hardware problem if it starts working again.

Is the computer dedicated to 1-wire logging or is it general purpose? If the computer "gets busy", it may not respond to serial interrupts fast enough.

As a last resort, you could have another process that monitors for the problem and if its detected use a usb relay to automatically power cycle the hub.

I've been using the USB adapter and a plain 6 channel hub for a nearly a couple of years without any of these problems. This setup made more sense for me since I can locate the hub anywhere.

 

[JoeKane]

SDA,

Yes, I have tried all of the combinations that you have mentioned. I have stopped/restarted the software, power cycled the host etc. The serial cable is not extended, as it runs from my ethernet-serial device server that's co-located with the hub. So that's lets me put the hub anywhere too. I have also checked the device server and power cycled it, restarted it etc. Yeah, I know, that makes it more complicated. But when the failure condition occurs, I've confirmed that in all cases I still have serial port connectivity and functionality and the serial port device server is running fine. And I don't have any delay/latency issues for these commands, and the serial buffers in the server are appropriately sized etc.

Your note on the 2480b spec is valid, and I've studied that section many times. Yes I do have the source code for the S/W and have made other customizations. The one issue with my current setup is that I cannot send a break command over the serial port with the particular device server. I *can* change the server's baud rate temporarily down to 4800 to simulate the break with a 4800 baud NULL. However thats pretty ugly in terms of implementation, as I have to reconfigure the server in and out of that 4800 baud each time via telnet. Real ugly.

There was a work-around solution that someone came up with for this problem (which common on bluetooth and other serial-to-ethernet adapters), by sending the 0xE3 command first to 'force' the 2480b into command mode, confirm its in command mode (carefully checking the response bytes) and following it up with the necessary config information, timing, and one wire reset etc. This works very well for the most part.

This may actually be one piece of commonality between myself and Nighthawk. I'm not really familiar with xAP and don't use it, but I *thought* it was IP based. Don't know if xAP supports breaks across the serial interface to the hub.


It still doesn't get me closer to what causes the lockup to begin with. But I guess the next time it happens, I can try sending a manual break to the hub via direct pc connection to the hub and see if it responds to that.

 

[ericvic]

Ah, the Ethernet to Serial device may be the cause. I am not trying to say there is anything wrong with the device it is just that the serial interface on the DS2480B is very timing dependent and I have seem problems with USB<->Serial devices are well. If I am remembering correctly Nighthawk was using a Edgeport USB<->Serial device (correct me if I am wrong Nighthawk). 1-Wire masters that have a true serial command interface like the TEMP08 and the Link45 will work better on Ethernet<->Serial and USB<->Serial devices.

Can you try connecting it directly to a real serial port on your PC and see if the problem goes away?

Eric

 

[JoeKane]

Eric,

I would expect the serial bit timing to be very good. I'd expect the timing byte itself to be pretty good too.

I could try to do a direct connect to a pc serial port, but its not easy as the hub is not closely located to the server. The setup works most of the time, and so it would take months to know it still occurs or not.

Maybe there's a little more in terms of debug that I can pull out at the time of the failure itself.

 

[JoeKane]

In case anyone is still wondering:

It took me some time to catch it in the act again, but I encountered the lockup scenario again this morning.

I also tried the work-around that I described previously: temporarily changing the ethernet to serial device's serial port to 4800 baud and sending a few 0x00 bytes to simulate a break condition ( the device cannot generate a true rs232 break on its own). This trick did bring the device back to normal (no power cycle of the master hub was required).

I believe I can reliably detect the error condition in software, since it has presented the same way each time, each time so far the 2480b goes into the same state, with the same error code. I can write a software reset script based on the above to see if it always recovers; a little messy but doable.

 

[ericvic]

Glad to hear that you have found a workable solution.

Eric