Reading DS1620 (SPI Temperature) from 18F46k22 Micro at 16MHz

[Dave]

Jim, Looking at the data sheet, I would change the "SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9]" statement to "SHIFTIN TDAT, TCLK, LSBPOST, [tempIn\9]" According to the data sheet, the data is valid until the next rising edge of the clock. Also, it takes 750 Milliseconds for each new conversion to complete. I am assuming that your TRS1 and TRS2 port bits are connected to the respective NOT RESET lines on the DS1620's?

[JimAvanti]

Dave,
I will make that change to the Shiftin statement tonight and let you know if it helps. The TRS1 and TRS2 bits are connected to the respective NOT RESET lines on the DS1620s. This same code worked well on the slower Micro years ago. Maybe reading on the wrong edge didn't have enough of an affect on the slower clock speed, but made the difference at 16MHz. Hopefully that fixes the issue I am seeing. If not, it is always more fun when you have to figure things out.

Thanks,
Jim

Jim, Looking at the data sheet, I would change the "SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9]" statement to "SHIFTIN TDAT, TCLK, LSBPOST, [tempIn\9]" According to the data sheet, the data is valid until the next rising edge of the clock. Also, it takes 750 Milliseconds for each new conversion to complete. I am assuming that your TRS1 and TRS2 port bits are connected to the respective NOT RESET lines on the DS1620's?

[JimAvanti]

Dave,
I tried changing the LSBPRE to LSBPOST as you suggested, but it seemed to make things worse. I changed DEFINE SHIFT_PAUSEUS to 1 and it seemed to make things the closest to the 8MHz Micro as possible (Looking at the timing on a logic analyzer). I can get temp readings, but they are not always reliable. I should also note that the DS1620s are on the end of a cable about 15' from where the micro is. The temp readings seem to be a little low (reading 58F where it should be closer to 69F, however when I try LSBPOST the reading drops in the 40's (Must be dropping a bit or something). Maybe the 18F46k22 can't handle the cable length as the 18F4620 did so well for all these years.
I will keep it running for a while and monitor the results.

Thanks for your help
Jim

Jim, Looking at the data sheet, I would change the "SHIFTIN TDAT, TCLK, LSBPRE, [tempIn\9]" statement to "SHIFTIN TDAT, TCLK, LSBPOST, [tempIn\9]" According to the data sheet, the data is valid until the next rising edge of the clock. Also, it takes 750 Milliseconds for each new conversion to complete. I am assuming that your TRS1 and TRS2 port bits are connected to the respective NOT RESET lines on the DS1620's?

[Dave]

Jim, When you have the logic analyzer connected to the PIC pins, are you seeing consistent data between transfers meaning reading to reading? 15 feet is quite a ways for an un-buffered SPI bus. The DS1620 device shouldn't be changing temperature that drastically.

[JimAvanti]

Dave,
from one reading to the next, the data does look consistent, but the temp is off which seems weird. I have been logging the results and they are smooth changes in temp. I think it will be a bit easier to follow what is going on with the logic analyzer if I remove the fahrenheit conversion and compare the data read to the bits on the analyzer, but that will be for another day since I don't have the analyzer set up next to where the device is mounted. Maybe then I will be able to see if I am dropping a bit someplace. I may try a different type of Temp IC also (Maybe one that also does humidity)

Jim, When you have the logic analyzer connected to the PIC pins, are you seeing consistent data between transfers meaning reading to reading? 15 feet is quite a ways for an un-buffered SPI bus. The DS1620 device shouldn't be changing temperature that drastically.