[Lcdproc] Cfontz fan temp

Stewart W. Putnam stewartputnam@comcast.net
Tue May 9 19:34:02 2006


The temperature probes:

*WRDOWY17
DS18B20 based temperature sensor for the CFA-633 and the CFA-631,CFA-635 
SCAB

*are on the bottom this page

http://www.crystalfontz.com/products/cables/index.html

The probe circuit is not hot pluggable AFIK, so power down the module -- 
and if you've soldered the jumpers to run the module off +5 VSB to use 
it as a power on / off reset switch, then disconnect the +5VSB and / or 
+5 power switch and reset switch leads if you are drawing the +5 VSB 
from those.

The probes from CF come with the exact plug connectors to fit the CF 
products, about 75 cm from plug to sensor, with the daisy chain female 
in the middle of that 75.  ( scale on the CF products page pictures : 
plugs are 2.5 cm long. )

The Dallas Semiconductor / Maxim Integrated Products Inc.  part number 
is DS18B20 if you want bare sensors for building into things with DIY 
wiring.

Andrew Foss wrote:

> Stewart,
>
> this is great thank you, I was considering trying to do this myself. I 
> have a CF633, what do you use for temp probes and such? That wasn't 
> clear to me reading the docs...
>
> thanks,
> andrew
>
> Stewart W. Putnam wrote:
>
>>    I put up another revison of my fan / temperature / system 
>> performance project on the CrystalFontz board:
>>
>> http://www.crystalfontz.com/forum/showthread.php?s=&threadid=3019
>>
>>    I'd like to thank Jannis Achstetter on the list here for an 
>> example of how to read the hddtemp daemon.  ( Aside; I own only one 
>> hard drive that hddtemp can read, so I my implementation might be 
>> broken for reading multiple drives. )
>>
>>    Frow the start my interest in in the Crystalfontz's Dallas / 
>> MaximIC has been off the main focus of LCD ( "oh, the temperature 
>> driven fan manager has a display screen too? Neat." )  The packet 
>> send-receive round robin que system in multiple threads in shared 
>> memory for gauranteeing fan management is quite divergent.  And the 
>> parts that most directly violate the lcdproc plan by spawning a 
>> socket screen client with access to the Driver * and writing directly 
>> to struct widget->text are all bracketed by #ifdef <>#endif, for 
>> what  it's worth ;)
>>
>>    That much said ... anyone from here who finds something broken in 
>> it please let me know.
>>
>> Stewart Putnam
>> _______________________________________________
>> LCDproc mailing list
>> LCDproc@lists.omnipotent.net
>> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>