I have a CR900X in a remote location, accessable via cell phone. It has become unresponsive although the phone is working and has good signal strength.
I used the device configuration utility to try to reach the logger as an unknown device. I get a response from the logger, "wdogerr".
I assume that is a watch dog error of some variety. I had an unresponsive CR9032 a few weeks ago and had it swapped with the current CPU. When I got the original one back in my lab, it worked perfectly. I had exactly the same thing on a second logger a week later. Both are running the same program.
The data card light is off so I don't think it is a faulty card crashing the system. I have had the data card removed and repowered the system. Even then the logger was unresponsive. An engineer on site was not able to communicate with the logger even through the serial port.
Next the field engineer pulled the 9032 card out in order to separate it from the battery backup of the 9011. After having removed it for about 30 seconds he reinstalled it but he still couldn't communicate with it.
Is there a supercap or something on the 9032 that is holding it in a crashed state? That could explain why failed cards worked after being in transit for a few days from the field to the lab.
My next step for the field engineer is to short the <2.0 pin and repower the logger. I don't know of anything else except to swap CPUs again.
The OS is CR9000s.std.06.
Installed cards are, 9011, 9032, 9041, 9050, 9050, 9050, 9052, 9071, 9060.
Hello Rlwoell,
I know we are working on your problem, because I was looking at logs files and collecting data from one of your stations earlier this week. It would appear so far to be a hardware or card issue, but I don't know what they have determined.
Yesterday (Thursday) was a State holiday, so I think many people are out of the office today as well. If you can hold on until next week, I'm sure the AE you were working with will get back with you. I'll notify him of your post in case he misses it.
Dana W.
Thanks for the update, Dana. I didn't know you were actively looking at this too. I am impressed, but not surprised at the level of attention.
I posted here just in case someone somewhere else might have seen something similar and have a suggestion. I get many good ideas from this board.
This has not been a simple problem to solve but with the help of CSI engineers I think we are getting close to fully understanding what is happening. The communication logs have been valuable for this.
It appears to be a problem associated with one table. Suggestions have been made in regard to mixing of IEEE4 and FP2 in the same table so I will start there. When we arrive at a solution, I will post again.
Thanks for your support.
Robert