Some data sheet excerpts regarding the temperature sensor:
17.12 Temperature Measurement
The temperature measurement is based on an on-chip temperature sensor that is coupled to a single ended ADC4 channel. Selecting the ADC4 channel by writing the MUX[3:0] bits in ADMUX register to “1111” enables the temperature sensor. The internal 1.1V reference must also be selected for the ADC reference source in the temperature sensor measurement. When the temperature sensor is enabled, the ADC converter can be used in single conversion mode to measure the voltage over the temperature sensor.
The measured voltage has a linear relationship to the temperature as described in Table 17-2. The sensitivity is approximately 1 LSB / degree C and the accuracy depends on the method of user calibration. Typically, the measurement accuracy after a single temperature calibration is ±10degreeC, assuming calibration at room temperature. Better accuracies are achieved by using two temperature points for calibration.
Table 17-2. Temperature vs. Sensor Output Voltage (Typical Case)
Temperature -40C +25C +85C
ADC 230 LSB 300 LSB 370 LSB
The values described in Table 17-2 are typical values. However, due to process variation the temperature sensor output voltage varies from one chip to another.
There is some more info and reference tables on pages 134 - 137 that will be needed to make the Thermal Protection Code ("TPC").
Elsewhere, this is written:
The ADC is enabled by setting the ADC Enable bit, ADEN in ADCSRA. Voltage reference and input channel selections will not go into effect until ADEN is set. The ADC does not consume power when ADEN is cleared, so it is recommended to switch off the ADC before entering power saving sleep modes.
The ADC generates a 10-bit result which is presented in the ADC Data Registers, ADCH and ADCL. By default, the result is presented right adjusted, but can optionally be presented left adjusted by setting the ADLAR bit in ADMUX.
If the result is left adjusted and no more than 8-bit precision is required, it is sufficient to read ADCH. . . . When ADCH is read, ADC access to the ADCH and ADCL Registers is re-enabled.
The ADC has its own interrupt which can be triggered when a conversion completes. When ADC access to the data registers is prohibited between reading of ADCH and ADCL, the interrupt will trigger even if the result is lost.
BTW....ALL of you are making huge inroads!! I just think about what can been done with double the space. We aren't talking guppies anymore, we are looking at whales if not actual sharks LOL
^ I hear you brother. It sounds like Greek to me for the most part too.
So Programming Gurus, if I may pick you brains (yum, brains. Oh, don't tell the BLF Zombie Slayanator I said that). Please learn me something here.
Base on the data sheet, it appears that much of the code for LVP can be adapted for the temp sensing. For example:
Bit ADEN appears to already turned on as needed by the existing code.
ADC feeds are left adjusted in the code by turning ADLAR on (= 1).
We only need to read register ADCH because we don't need more than 8 bits of resolution. So the existing code read seem appropriate.
The If, Then, Else loop for LVP just need to be copied and modified for temp sensing purposes.
So, I have 2 questions as follows:
Can we not have LVP and Temp Sensing at the same time as both feed ADC feeds dump in Register ADCH?
I appears we need 1111 in the 4 MUX# bits. Can we just insert the following for the first line and then squeeze the second bullet text below into the code below "inline void ADC_on()" in the existing code?:
#define ADMUX ob00001111
ADMUX = (1 << REFS1) |
EDIT: If the answer to my first bullet is "yes", than can we some how use one of the various memory capabilities of the 25 to collect and report one of the ADC feeds?
EDIT2: Or maybe a loop that, clears ADCH, turns ADC1, waits for feed to populate ADCH,, reads ADCH, turns off ADC1, clears ADCH, turns on ADC4 (temp sensor), waits for feed to populate to ADCH, reads ADCH, steps down if needed, turns off ADC4, rinse and repeat
Sorry for asking the above without researching more, but I want to get the OSH Park Attiny 13/25/45/85 piggyback PCB designed and published.
I was rather surprised to hear that one of my projects compiled and worked on the attiny25, with no modifications!
So, it sounds like we already have a few firmwares which work (or almost work) on nicer hardware, and it’s time to get the hardware out there to more people.
If I understand correctly, it should be fairly straightforward. Just toggle back and forth between voltage and temperature every other cycle, with different code to handle each. I think the MCU can only measure one at a time, but it’s not hard to swap between the two fast enough for it to be useful.
+1, I read it the same - only one at a time, based on the MUX bit definitions (allows only one channel to be selected), and the description of free running mode, which states one conversion at a time, then auto starts the next conversion. But certainly/definitely the firmware can be written to support LVP A-D conversions and temp sensor A-D conversions.
The accuracy doesn't sound too great though for the temp sensor. Even after a single cal point at room temp, the accuracy is only within +/- 10C. I would think we would want better? Better to get two points, but I'm not sure how to best create then measure a 2nd point. Guess I could use a heat/hot air gun, but not sure how to accurately measure the temp of the chip. I wouldn't trust my cheap IR thermometer. Dunno if my Chinese $15-$20 meter is any good, or would the Fluke or Extech units be that much better in the $70-$80 range? Or is an IR meter the right tool?
. . . Just toggle back and forth between voltage and temperature every other cycle, with different code to handle each. I think the MCU can only measure one at a time, but it’s not hard to swap between the two fast enough for it to be useful.
Cool. Thanks. So my EDIT2 idea should work. You conveyed the idea much more eloquently than I did.
TK wrote:
I was rather surprised to hear that one of my projects compiled and worked on the attiny25, with no modifications!
So, it sounds like we already have a few firmwares which work (or almost work) on nicer hardware, and it’s time to get the hardware out there to more people.
I would stress "almost work". In that example you cite, I believe said he reported LVP didn't work. Although Atmel only changed a few Memory Names, they did change the Addresses a good bit. Also, some bits changed. So a full port is really needed for all FW one wishes to install on the 25.
Tom E wrote:
The accuracy doesn't sound too great though for the temp sensor. Even after a single cal point at room temp, the accuracy is only within +/- 10C. I would think we would want better? Better to get two points, but I'm not sure how to best create then measure a 2nd point. Guess I could use a heat/hot air gun, but not sure how to accurately measure the temp of the chip. I wouldn't trust my cheap IR thermometer. Dunno if my Chinese $15-$20 meter is any good, or would the Fluke or Extech units be that much better in the $70-$80 range? Or is an IR meter the right tool?
Perhaps a hidden mode that lets the user click when the light gets too hot. That way, no calibration is needed. The loop switching from LVP to Temp would be by-passed and just ADC4 would be active during the user :"calibration". Boy, it seems that extra 1K of memory can get used up fast with new code like this.
It’s already possible to have that functionality with a turbo timer - without a temp sensor. If using the temp sensor, it should be easier than this (for the end user).
^ Great. So some code already is available to start out with. Good to hear.
I think the FW could have a default setting that would have margin for the -+10 degrees C and thermal lag for heat to get to a typical MCU. That way there is some safety measure in place in case the user doesn't calibrate. I think user calibration is pretty critical as each light is so different and as each person will have their own level of heat tolerance they are comfortable with.
Yeah, but my point is that if you are doing a user calibration, you don’t need the temp sensor at all, because a turbo timer will do fine. Well, I could understand user calibration of a temp sensor if the user had multiple different cells that they might use with that light. One cell gets it hot at 2 minutes, but a different cell takes 4 minutes to get it to the same temp, etc.
Well I'm think'n/hoping someone could chime in on the best way to get a somewhat accurate temp measurement. I'll ask my EE buddy here today. Think Richard has a pretty good external temp sensor working. led4power would probably have good ideas too. Ideally having the calib built-in to the firmware. Wait.. I know someone did this already. HHmm.... Maybe Everett, or led4power? Dunno, but I would think the calib would be fairly consistent in the same design driver. Of course the effect on the temp of the MCU will vary greatly from a light's design I would suspect. MCU temp of course is important, but so is LED temp. Still like the idea proposed to build a MCPCB with a thermal sensor mounting spot next to the LED.
^ The problem with calibrating is that it will require every chip to be calibrated while there are bigger issues such as how long the heat takes to get to the MCU in any particular light. Another issue is each user will have different heat tolerance levels. I think UI adjustable is the way to go.
I like the idea of temp sensing at the LED too, but that uses up a MCU pin and requires a new driver board from the ones we are using.
Yeah, but my point is that if you are doing a user calibration, you don’t need the temp sensor at all, because a turbo timer will do fine. Well, I could understand user calibration of a temp sensor if the user had multiple different cells that they might use with that light. One cell gets it hot at 2 minutes, but a different cell takes 4 minutes to get it to the same temp, etc.
Turbo time out is a make shift solution. Things like environmental temperature changes, how hot the light is already from usage, whether the light is in hand or accidentally turned on in a container all are factors turbo timeout doesn't really address.
Ohh - +1. I wasn't thinking/understanding - if you do a UI calibration then you are right - turn the light ON hi til the heat gets uncomfortable for the user, click, then record whatever the A-D reading is at that time, and use that value as your trigger point.
There's no need to know what the temperature is. It's not perfect of course, because under cooler air conditions, maybe the MCU hits the trigger point before the head gets hot, or in the calibration process, the MCU may not be heating up as fast as the outer body, so the trigger point might get set lower than you'd like in other conditions. But whatever the downsides are, definitely worth experimenting with, and should still be better than a turbo timeout. This all sounds familiar - someone did this already - Richard, Dr. Jones, someone... Wish I could recall where I saw this posted - maybe it was only discussed and not implemented, not sure.
^ You got it. And it would be great if the current could continue to step down if the light continues to not adequately cool down. That would be great for situations were a high power light turns on in a gym bag. If the light is insulated, it may still continue to escalate in temp even on the next mode down from High. That would make is much better than turbo timeout.
I agree about not being perfect, but it's progress. The better the user thermally connects the MCU to the host, the better it will work. I'm hoping that the OSH Park board I'm trying to design will help some with that.
Now I understand better. I wasn’t accounting for all potential high-heat situations. I’m really looking forward to what you guys come up with! :bigsmile:
I'm interested in trying to get the temp sensor to work - I'll work on it this weekend. I'll attempt to add a UI into the eswitch firmware to support the calibration. I didn't swap 45's yet - 2nd one is dead now. Wonder if something flaky about my setup - dunno what's causing the bricking of the 45's. I have 25's and 85's on the way from Mouser, so I'll see if they are any different.
If I may....and feel free to tell me to shut up. An auto sensing temp monitor is great...and welcomed..BUT..just making this thing work and having all that extra space available is great thing. If you guys feel the same functionality of the 13 is already there...hell..rock and roll. :)
^ Yes, Tom E has already got his version of Star Momentary to full 13a functionality plus new features his previous version didn't have.
I personally think temp sensing is way overdue. We are building beasts these days that can be dangerous at times. This MCU with some programming talent won't make them completely safe, but it will make them a bit safer. Users will still have to exercise caution when using these lights, but at least a lapse in focus at the wrong time might be compensated by better thermal protection.
Tom E wrote:
I'm interested in trying to get the temp sensor to work - I'll work on it this weekend. I'll attempt to add a UI into the eswitch firmware to support the calibration.
This sounds like a very big challenge to do. Seems it will take the FW to a new level of complexity. Best wishes on the endeavor. I wish I had the skill to assist. I have a vague idea on the logic I would want, but turning that into code is another story. I can help with testing when you get to that point.
One important thing is driver's self heating,and it can course large errors.This is why LD-2 has external temp. sensor for flashlight temperature measurement and internal sensor is used for driver overheat protection.DD driver doesn't generate as much heat as linear(extra heat is generated in LED),but at for example at 10Amps(triple or similar setup),dissipated power in driver (let's say with 5mOhm resistance) would be 10^2*0.005=0.5Watts which is enough to increase driver PCB temperature by 10-15C in host without silicone cubes or similar stuff for better thermal conduction.
Useful document about internal temp. "indicator"(PIC but it's probably similar to atmel):
