My Hồ Chí Minh clock has a temperature reading on it, alongside the lunar calendar, so I figured the nixie clock should have one too.
In the past one-wire temperature sensors have been cheap and plentiful, and were traditionally hooked up to classic PC serial or parallel ports. Nowadays the sensors seem to start at $US5, though I was fortunate to get some DS18B20s from this bloke on eBay for $AU3 each plus postage. The ts7250's GPIO pins stand in for the less flexible interfaces of yore.
These DS18B20 devices are pretty fancy, being able to source power parasitically from the data bus and yielding 12 bits of temperature data. They're only accurate to 0.5° on average, though, or perhaps a bit better at room temperatures, so I don't understand why one would need more than the 9 bits of the other models.
Anyway, wiring it up took about 5 minutes, and finding a suitable cable another half-hour or so. Fortunately the first four GPIO pins of the DIO header on the ts7250 are supposed to have the requisite pull-up resistors, so the sensor can indeed be powered parasitically.
Getting Linux to talk to it was a bit challenging, as the one-wire
drivers don't seem to be set up for actual use. Apparently you have to
use the non-mainline w1-gpio-custom
module to indicate the GPIO pin to the one-wire driver. I don't know
how to do it any other way; perhaps it is supposed to be hardwired
somewhere. Moreover to get timing right for the parasitic powering,
one needs a few more patches, which
this bloke has hacked together.
It works:
# cat /sys/bus/w1/devices/28-0000027d5e12/w1_slave 09 01 4b 46 7f ff 07 10 bf : crc=bf YES 09 01 4b 46 7f ff 07 10 bf t=16562
but often the w1-therm driver complains:
w1_slave_driver 28-0000027d5e12: 18S20 doesn't respond to CONVERT_TEMP.
and the CRC check fails with occasionally crap data. I'm suspicious
about the device ID as the code apparently does know about the
DS18B20. Unloading the w1 drivers doesn't work
either. Still, this is all much better than I had any right to expect,
I guess.
