Another Ice Tube Clock Design for the Holidays

For RTC breakouts, etc., use the Other Products from Adafruit forum

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
User avatar
phild13
 
Posts: 247
Joined: Mon Sep 10, 2012 1:05 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by phild13 »

John,

Is there room or ability to add a second temp sensor that would be installed on the bottom of the board?

If you drilled a hole in the proper place in the case bottom plate and installed the temp sensor correctly on the bottom of the board, make the top of it flush with the hole, or stick out slightly, I think in most cases it would provide a reasonably accurate outside case temp.

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

rcb wrote:Now all we need is reliable external temperature... I suppose one could put the sensor on a pigtail lead & run it outside to the bottom...but I guess then it can't do its other job?
In your case, you will have a GPS module installed, so software temperature compensation is superfluous. On the hardware-side, a pigtail should work just fine, but my firmware would need to be modified to display the temperature and to not perform temperature-compensation. I'd be willing to help with that if it's something you really want to do.

But without a GPS, you and Phil are correct. The temperature sensor is intended to measure the crystal oscillator temperature for software temperature compensation. But the DS18B20 uses the 1-Wire protocol, and the 1-Wire bus supports multiple devices. My firmware doesn't support multiple 1-Wire devices (yet?), but you could have two temperature sensors on the 1-Wire bus: one near the crystal oscillator and one on a pigtail.

The clock would need to distinguish between the two temperature sensors. That would probably mean reading the device codes for both sensors before installing them and defining which sensor was which when compiling the firmware. Alternatively, I suppose the clock could autodetect the sensor identity, as the internal temperature sensor would usually be slightly warmer when the display is active, but making a robust autodetection algorithm might be tricky.

On the hardware side, there is probably room for me to add expansion holes for a pigtail-type external temperature sensor. I briefly considered using a pigtail a while back, but scratched the idea because I did not like the aesthetics. I wanted everything to be contained in the acrylic case.

Of course, if there is interest in adding a pigtail-type external temperature sensor to the xmas design, I'd be willing to help with that project.
PhilD13 wrote:If you drilled a hole in the proper place in the case bottom plate and installed the temp sensor correctly on the bottom of the board, make the top of it flush with the hole, or stick out slightly, it would provide a reasonably accurate outside case temp.
A year ago, I was convinced this would work, but when I tried, I was unsuccessful. My commit comment has more information.

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

PhilD13 wrote:If you drilled a hole in the proper place in the case bottom plate and installed the temp sensor correctly on the bottom of the board, make the top of it flush with the hole, or stick out slightly, I think in most cases it would provide a reasonably accurate outside case temp.
When I tried this a year ago by modding the original Adafruit clock, I was quite frustrated at not being able to get consistent temperature measurements. So I gave up. My being frustrated was a poor reason to give up and also prevented me from being truly objective.

So the fact that I was unable to get this to work, doesn't mean it won't work. I already have the hole drilled in the bottom of the modded clock, but have removed the temperature sensor. When I have time, I'll stick a thermocouple in the hole and compare that to ambient temperature to see what the difference is.

User avatar
phild13
 
Posts: 247
Joined: Mon Sep 10, 2012 1:05 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by phild13 »

I just felt the bottom of the Rev. D clocks case. It is much warmer on the driver end than on the buzzer end so depending on where the temp component is placed may still have a great affect on it through conduction even if placed through the bottom of the case. Case temp may also eventually affect any temp components mounted outside of the case, but attached to the case in some way.

It might be possible to compensate fairly accurately in software, but may take trial and error

Ambient temp on my desktop is about 64.5F
I have a temp probe inside the case in free air above the crystal area, and just below the tube. Temp there is about 89.5F.
If I remember correctly, the top of C6 is about 93 or so.
The TO92 regulator for the AC drive is anywhere from about 104 to 115


I think you have to read the devices 64 bit serial number in order to identify/talk to a specific device on the bus.

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

PhilD13 wrote:Case temp may also eventually affect any temp components mounted outside of the case, but attached to the case in some way.
Yeah... I'm starting to remember why I got so frustrated. The case would be affected in a predictable way by the heat produced (milliwatts consumed) by the clock. But the case has a large exposed surface area, so the movement of air in the room (drafts and such) will also have a significant effect, but that's not predictable. :-(
PhilD13 wrote:It might be possible to compensate fairly accurately in software, but may take trial and error
If my memory is good, a constant temperature offset doesn't come close to doing a good job, and I didn't see any obvious method that would do the trick. But if anyone else wants to have a go at this, I'd be happy to assist... perhaps by writing mods to xmas to help collect or analyze temperature data. I'm not willing to devote a lot of time to this project, but I'm certainly willing to help out.
PhilD13 wrote:I think you have to read the devices 64 bit serial number in order to identify/talk to a specific device on the bus.
That is consistent with my limited understanding of 1-Wire. To identify the crystal sensor and pigtail/external sensor, I was considering two options. The second option may just be silly, but I'm just throwing out ideas at this point.

(1) Define the serial numbers of the internal temperature sensor and the pigtail at compile time. The firmware would use those numbers to identify each device.

(2) Have the firmware go through 1-Wire device discovery to get the serial numbers of both temperature sensors. Even though it's possible for the firmware to determine both serial numbers, it's impossible for the firmware to determine which sensor is inside the case and which sensor is the pigtail. The firmware would need to distinguish the sensors somehow, perhaps by keeping a cumulative sum of the temperature difference between the sensors. The warmer sensor would be used as the internal sensor. But I can see how that particular scheme might go awry, so developing a robust heuristic to identify the crystal sensor and pigtail sensor could be tricky.

User avatar
phild13
 
Posts: 247
Joined: Mon Sep 10, 2012 1:05 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by phild13 »

Something that may be of interest to you is this link
http://www.pjrc.com/teensy/td_libs_OneWire.html

I don't see why option 2 would not work with some effort.
Sorry this is kinda long. Take a good look and see if this will work.

Here are ideas

Hardware:
* Probably easiest if sensors are same type
* Multiple sensors on 1-wire are in parallel for all three pins GND, Vdd, and DQ The parasitic mode should still work with multiple sensors as your using now.
* Only store the serial number in eeprom of the sensor used for temp compensation. This makes code easier and smaller, not error prone.
*Consider using the SO package for the external sensor (they are pretty easy to hand solder with an iron, hard to accidentally damage by grabbing it when on clock), mounted on a small board with a 3 pin male header connector. Mount a female connector in a slot on the back of the clock. This way the external sensor can be easily plugged in.

Procedure to accurately determine internal sensor:
* Set up the sensors separately by including a removable jumper or just leave the pigtail cable to the external sensor unplugged.

* Plug the clock in and have the firmware go through 1-Wire device discovery to get the serial number of the temperature sensor used for temperature compensation. This would be automatic in code if eeprom register is empty.

* Code will store the serial number in eeprom. This will be the internal device used for temp compensation.

* If eeprom register is empty (meaning initial clock startup or a sensor reset was successfully performed) , then throw an error code display if more than one sensor is found during 1-Wire device discovery at initial startup or after a "sensor reset" is performed.
Solution - unplug clock, unplug the external sensor, plug clock back in, or just do a "Sensor reset" from the menu after unplugging the external sensor. This is so the code can determine which serial number is the internal sensor to store in eeprom

* Unplug the clock, and install the jumper or pigtail cable to the external sensor

* Plug in the clock The clock will now see the eeprom register is not empty and expect that there may be a second sensor.

* Clock will run the 1-Wire device discovery code to get the serial numbers of the temperature sensors.

* Compare the serial numbers to the one stored.
The serial number that marches is the internal temp compensating one.
The one that does not match is the external one.

* Poll for the sensor serial numbers at a reasonable interval to detect an unplugged external sensor or a newly plugged in external sensor.

* If external sensor is lost (unplugged) then code zeros or nulls the memory register and not display temperature

* We only care about the serial number of the external sensor while it is plugged in so we can talk to it.

* By not storing the external sensor serial number, we can plug in different serial numbered external sensors

* Provide a "reset sensors" to allow for component replacement in case of failure/corruption/processor replacement (replacment processor could have serial number eeprom register set) of the sensor used for temp compensation

* Maybe perform an auto "reset sensors" if one sensor is detected but does not match what is stored in eeprom.

Edit:
* Perform a periodic poll of serial numbers to make sure things are still attached and working. This would detect if the external sensor is disconnected.
Last edited by phild13 on Wed Jan 15, 2014 12:15 pm, edited 1 time in total.

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

PhilD13 wrote:Sorry this is kinda long.
You're making me feel guilty! (For anyone new to the clocks forum, I make lots of posts that are way too long.)
PhilD13 wrote:Take a good look and see if this will work.
What you propose should work and is a definite improvement over my suggestion. If a pigtail mod appeals to you or anyone else, I am willing to help out. I have no idea how 1-Wire device discovery works, so I would probably have a lot of fun writing the code to do it. (No sarcasm intended. I enjoy playing with new things.)

User avatar
phild13
 
Posts: 247
Joined: Mon Sep 10, 2012 1:05 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by phild13 »

I don't know how to do the reading either, but the link I posted gives one example of how to write it and the Arduino playground gives an example http://playground.arduino.cc/Learning/OneWire
Both have links to more examples.

My idea was to try to make it easy and as automatic as possible to determine accurately which sensor is which, make it easy to fix if the procedure was done wrong, make it easy to fix a hardware failure, make it easy to plug/unplug a sensor, not have an error or fake external temp reading if the sensor is missing.

I prefer to have everything internal as much as possible, but I have seen a number of people wish that the clock displayed ambient temp.

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

PhilD13 wrote:I don't know how to do the reading either, but the link I posted gives one example of how to write it and the Arduino playground gives an example http://playground.arduino.cc/Learning/OneWire
Both have links to more examples.
I have used that library in the past and believe you are correct. If memory serves, the code is well-written.

EDIT: I just looked at the Book of iButton® Standards (Maxim Application Note 937), and 1-Wire device discovery with the search ROM command would be quite straightforward to implement.
PhilD13 wrote:My idea was to try to make it easy and as automatic as possible to determine accurately which sensor is which, make it easy to fix if the procedure was done wrong, make it easy to fix a hardware failure, make it easy to plug/unplug a sensor, not have an error or fake external temp reading if the sensor is missing.
Your scheme seems great, as long as the sensor is detachable. If I do implement pigtail-sensor support, I would be inclined to have four compile-time options: (1) software temperature-compensated timekeeping only, (2) external pigtail only, (3) your autodetection scheme, and (4) hard-code both 64 bit serial numbers at compile-time. For the dual-sensor crowd, your scheme would appeal to most people, but I'd think those with a soldered/nondetachable pigtail or those who upgrade their firmware frequently would prefer the fourth option.
PhilD13 wrote:I prefer to have everything internal as much as possible, but I have seen a number of people wish that the clock displayed ambient temp.
I know we were both interested in having the clock display temperature, but neither of us seems enthusiastic about adding a pigtail. ;-)

If at least two people post here or email me stating that they'd like to have a temperature display and would like to do so by adding a pigtail, I'd be willing to put that project on my hobby to-do list.

User avatar
phild13
 
Posts: 247
Joined: Mon Sep 10, 2012 1:05 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by phild13 »

What your proposing sounds reasonable.

Your compile time options also sound reasonable.

rcb
 
Posts: 25
Joined: Sun Sep 15, 2013 6:25 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by rcb »

Here's my replication of jarchie's wonderful hw & sw/firmware redesign (pic 1). Every mod works beautifully, thanks, jarchie!
The code truly is clever -- e.g., the compile set the proper offset from gmt for my locale, very cool. There's one trivial case change: the gps lines run thru the case bottom where the adafruit gps perches beautifully (pic 2) and is entirely hidden, as you'll note from pic 1. Here I've used the option to backup the gps using the clock battery. (Case now redesigned w/ the hole, @ pokono.) So my thoughts too turned to more...
So, yes, count me in for an external temp sensor. I've started hacking some sw additions: display date @ user set intervals (or default to current); display gps lat, long; chimes @ settable intervals; and (when the temp sensor is done), temp @ settable intervals.
Jarchie's code is so clean that it's easy to add things - another big thank-you to jarchie.
ic1.jpg
ic1.jpg (124.15 KiB) Viewed 1528 times
ic2.jpg
ic2.jpg (110.48 KiB) Viewed 1528 times

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

rcb wrote:Here's my replication of jarchie's wonderful hw & sw/firmware redesign (pic 1).
Nice build! And thank you for the kind words about the design and firmware.
rcb wrote:There's one trivial case change: the gps lines run thru the case bottom where the adafruit gps perches beautifully (pic 2) and is entirely hidden, as you'll note from pic 1.
That really looks nice. I would have thought there could be problems with reception if the GPS was mounted upside down under the case, but I take it you haven't had any issues?
rcb wrote:I've started hacking some sw additions: display date @ user set intervals (or default to current)
I added a similar feature for a friend a week ago. If you haven't already seen that, it might be a good place to start.

rcb
 
Posts: 25
Joined: Sun Sep 15, 2013 6:25 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by rcb »

Hi jarchie,
No problems at all w/ the GPS on the case bottom...in 3 builds now. Thx for the code ptr, I shall indeed check it out.

User avatar
jarchie
 
Posts: 615
Joined: Sun Jun 24, 2012 2:16 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by jarchie »

rcb wrote:No problems at all w/ the GPS on the case bottom...in 3 builds now.
Very cool; I'll remember that. :-)

rcb
 
Posts: 25
Joined: Sun Sep 15, 2013 6:25 pm

Re: Another Ice Tube Clock Design for the Holidays

Post by rcb »

Hi Jarchie,
I forgot to ask you a question: since the GPS-run units don't need the temp. sensor correction, I assume it's possible just to omit those 2 parts, the sensor and R9 from the build, and then compile the firmware w/ config.h suitably modified to comment out those def lines for the temp sensor. What happens if you use a chip flashed with the temp code left in as defined, and you leave out the sensor and R9 from the build? (I ask simply because that sensor is a bit costly, relatively speaking -- $3.28 each at Mouser, and not available from Digikey it seems.)
Thanks!

Locked
Please be positive and constructive with your questions and comments.

Return to “Clock Kits (discontinued)”