Parts ordered, Temp still ornery!

[brassfly]

I have confirmed that the wiring is correct. Also, these sensors are the same ones I was using a while back that have stopped working, so they worked in the past. I also have a DS9490R, so I could hook it up that way and make sure they are working if yall think that'd be helpful.

[Teken]

That would be very helpful to isolate if the sensor(s) are indeed still operational.

[ben]

Have you tried cycling power to the GEM?

EDIT: It'll mess up your all of your counters, but it might be worth trying to disengage the battery or super cap before cycling power to clear out memory. If it's black, it's a battery, if it's blue it's the super caps. Super caps are disengaged by removing the header above the Ethernet jack on board. Battery is disengaged by removing the battery by pushing at the back of it. Only remove or add battery/super caps while powered on as it might put in some bad values if it's done while powered off.

Paul is looking into the nc issues, it looks like if you enable a sensor and disable it, it continues to show nc.

[brassfly]

Ok, I pulled the battery, pulled power and the PT jack. Gave it 30 seconds, power and PT back on, Then battery a couple of seconds later. No changes to my counters, and the Temp still reads the same way. 1: nc F

Maybe a hard reset with the button?

[ben]

Ok, I pulled the battery, pulled power and the PT jack. Gave it 30 seconds, power and PT back on, Then battery a couple of seconds later. No changes to my counters, and the Temp still reads the same way. 1: nc F

Maybe a hard reset with the button?

You can try a Factory Defaults with the Firmware tab of the GEM Network Utility to see if that clears the issue.

[paetzold]

It sounds like I may have the same/similar issue. My temp channels have not work for some time (last year) and I am not sure if they stopped during an firmware upgrade. I have not had the time to try to work out the issue but since I seen this post I thought I would chime in to see if my symptoms and troubleshooting indicate this is a larger issue than just one user.

Since my previous eight sensors where working I really did not think that they were the problem but I did go ahead and order a new set of DS18B20 from Amazon (I think they are good quality and they did have 5 star reviews). Currently I only have one new sensor directly installed at the GEM. I select the radio button to Search single connector… to channel 1 but it only comes back with an address of all zeros for channel number 1. However, when I do Search, List all sensors codes I get a listing of all eight sensor codes, all of the first ROM codes are zero except for the last two digits (00-00-00-00-00-00-00-01, 00-00-00-00-00-00-00-81, 00-00-00-00-00-00-00-41, etc.).

With all sensors removed I did a Search, List all sensors codes I get the same results but the last two digits of a few do change. I found this to be strange since I would have expected all zeros,but don’t know if it is normal or not.

When I installed another new single sensor, again, I get comparable results but they are slightly different. Interestingly, each time I do the search (no physical changes) it randomly changes the last two digits in a few of the sensor codes.

Repeating the process, when I removed the sensor and did the Search at least 10 times it always displays the same sensor sets (ROM codes) and when I install a sensor the last two digits change slightly each time I do the search for the next 10 times. This seems to suggest that the GEM does see that there is something attached. When another new sensor was installed I again got very comparable results in that the last two values of the sensor code changed a bit each time I conducted the search.

While I do not think that it is required, being that it has been discussed in other posts, the datasheet from Maxim for the DS18B20 does point out that the control line requires a weak pullup resistor of 4.7K so I did try installing between the Data and VDD lines. However, this did not change what I was seeing.

I also have the 'nc F' in Live Data page for that channel. I did have it for all but I have disabled the other channels for now.

I also already tried the Factory Defaults selection in the Firmware tab but no noticeable change.

I confirmed that the ground to VDD was a perfect 5.0 VDC

I am on COM V4.33 and ENG V 1.49

I hope this helps for brassfly and even myself. Please let me know if there are other tests that would help.

[ben]

Since my previous eight sensors where working I really did not think that they were the problem but I did go ahead and order a new set of DS18B20 from Amazon (I think they are good quality and they did have 5 star reviews). Currently I only have one new sensor directly installed at the GEM. I select the radio button to Search single connector… to channel 1 but it only comes back with an address of all zeros for channel number 1. However, when I do Search, List all sensors codes I get a listing of all eight sensor codes, all of the first ROM codes are zero except for the last two digits (00-00-00-00-00-00-00-01, 00-00-00-00-00-00-00-81, 00-00-00-00-00-00-00-41, etc.).

Are these 3-wire sensors? Make sure you're not using parasitic power.

The 1-wire changed a bit in the newer firmware to match the spec from Maxims manual. Can you try 4.25 to see if it makes a difference?

[paetzold]

I did change to 4.25 but did not see any positive results. I did two other of the new sensors and one old. I am willing to order the sensors from Brultech if you think that would be likely solution. I am using them in 3 wire mode. I did consider that the wires were color coded incorrectly so I tested in all possible configurations.

Just another item that may be of use (or maybe not). My board has a version number of 2.06 (black) and I have been using the USB port for the power supply. The conventional plug port has a broken solder joint so I have been using the USB input for years so am thinking this makes no difference but sense it was a none standard configuration I thought I would bring it up.

[ben]

I did change to 4.25 but did not see any positive results. I did two other of the new sensors and one old. I am willing to order the sensors from Brultech if you think that would be likely solution. I am using them in 3 wire mode. I did consider that the wires were color coded incorrectly so I tested in all possible configurations.

Just another item that may be of use (or maybe not). My board has a version number of 2.06 (black) and I have been using the USB port for the power supply. The conventional plug port has a broken solder joint so I have been using the USB input for years so am thinking this makes no difference but sense it was a none standard configuration I thought I would bring it up.

Brassfly, is yours also a black board? I'll pass that information on to Paul.

[ben]

Paul sent me the following instructions:

1. Disconnect the one wire bus from the GEM and perform a "Search, List all sensor codes". The block should return all "FF"s. If not, there is a problem with the GEM.

2. If step 1 was successful, reconnect the one wire bus connected to all sensors. If you have a resistor (any value between 1.5K & 2.7K) try connecting it between the "Data" and "5V" terminals of the 1-wire header on the GEM. Do a "Search, List all sensor codes" again. If this solves the issue, leave the resistor connected permanently.

3. If step 2 was not successful, try disconnecting each temperature sensor connected to the bus one at a time while doing "Search, List all sensor codes" function after disconnecting each sensor. Use this process of elimination to single out the bad sensor.

4. If all sensors are disconnected and only the 1 wire cable is left connected, the cable used probably has too much capacitance, is too long or has a short/open circuit.

We discovered that once the problem with the buss/rom-code is resolved, the other issue of posting temperature 1 on ch 2 will be resolved. We will need to change the firmware at some point to prevent this