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.
Another Ice Tube Clock Design for the Holidays
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
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.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?
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.
A year ago, I was convinced this would work, but when I tried, I was unsuccessful. My commit comment has more information.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.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
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.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.
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.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Another Ice Tube Clock Design for the Holidays
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.
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.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
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:Case temp may also eventually affect any temp components mounted outside of the case, but attached to the case in some way.
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:It might be possible to compensate fairly accurately in software, but may take trial and error
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.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.
(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.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Another Ice Tube Clock Design for the Holidays
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.
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.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
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:Sorry this is kinda long.
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.)PhilD13 wrote:Take a good look and see if this will work.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Another Ice Tube Clock Design for the Holidays
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.
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.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
I have used that library in the past and believe you are correct. If memory serves, the code is well-written.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.
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.
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: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 know we were both interested in having the clock display temperature, but neither of us seems enthusiastic about adding a pigtail.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.
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.
- phild13
- Posts: 247
- Joined: Mon Sep 10, 2012 1:05 pm
Re: Another Ice Tube Clock Design for the Holidays
What your proposing sounds reasonable.
Your compile time options also sound reasonable.
Your compile time options also sound reasonable.
-
- Posts: 25
- Joined: Sun Sep 15, 2013 6:25 pm
Re: Another Ice Tube Clock Design for the Holidays
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.
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.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
Nice build! And thank you for the kind words about the design and firmware.rcb wrote:Here's my replication of jarchie's wonderful hw & sw/firmware redesign (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: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.
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 wrote:I've started hacking some sw additions: display date @ user set intervals (or default to current)
-
- Posts: 25
- Joined: Sun Sep 15, 2013 6:25 pm
Re: Another Ice Tube Clock Design for the Holidays
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.
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.
- jarchie
- Posts: 615
- Joined: Sun Jun 24, 2012 2:16 pm
Re: Another Ice Tube Clock Design for the Holidays
Very cool; I'll remember that.rcb wrote:No problems at all w/ the GPS on the case bottom...in 3 builds now.
-
- Posts: 25
- Joined: Sun Sep 15, 2013 6:25 pm
Re: Another Ice Tube Clock Design for the Holidays
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!
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!
Please be positive and constructive with your questions and comments.