Post by thread:[PIC:] High sleep current on 16F88

Hello all, I've been tinkering with sleep mode on my data logger project and I seem to be having some trouble. I can't get the sleep current on the PIC to less than 120uA while it is sleeping, it should be less than 5uA. I don't have the PORTB pull-ups on, nor do I have the comparators or their Vref on. No floating input pins, no "loaded" output pins. I've tried turning the ADC completely off but that makes virtually no difference (just like the datasheet indicates). No ADC conversions are taking place while I sleep. I'm using the internal oscillator at 8Mhz. MCLR is disabled and tied to ground. Brown out is disabled and watch dog is disabled. No timers are being used. I wake up with RB0 interrupts once per second and that's all working perfectly. I'm measuring current at the Vcc pin of the PIC. My meter is not the greatest in the world, but it seems capable of giving me reasonable readings at lower currents than 120uA. Any ideas as to what I have missed? The only things I specifically enabled are: the ADC, RB0 ints, the UART in async mode.

michael brown wrote: {Quote hidden}>Hello all, > >I've been tinkering with sleep mode on my data logger project and I seem >to be having some trouble. I can't get the sleep current on the PIC to >less than 120uA while it is sleeping, it should be less than 5uA. I >don't have the PORTB pull-ups on, nor do I have the comparators or their >Vref on. No floating input pins, no "loaded" output pins. I've tried >turning the ADC completely off but that makes virtually no difference >(just like the datasheet indicates). No ADC conversions are taking >place while I sleep. I'm using the internal oscillator at 8Mhz. MCLR >is disabled and tied to ground. Brown out is disabled and watch dog is >disabled. No timers are being used. I wake up with RB0 interrupts once >per second and that's all working perfectly. > >I'm measuring current at the Vcc pin of the PIC. My meter is not the >greatest in the world, but it seems capable of giving me reasonable >readings at lower currents than 120uA. Any ideas as to what I have >missed? The only things I specifically enabled are: the ADC, RB0 ints, >the UART in async mode. > > > Running the PIC at 8Mhz is the cause. Run the internal; oscillator at 31Khz and watch. -- Note: To protect our network, attachments must be sent to spam_OUTattachTakeThisOuTengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Oh, SLEEPing. Sorry. Sure its sleeping? Try turning all the outputs to a state that the pins draw no current. --Bob michael brown wrote: {Quote hidden}>Hello all, > >I've been tinkering with sleep mode on my data logger project and I seem >to be having some trouble. I can't get the sleep current on the PIC to >less than 120uA while it is sleeping, it should be less than 5uA. I >don't have the PORTB pull-ups on, nor do I have the comparators or their >Vref on. No floating input pins, no "loaded" output pins. I've tried >turning the ADC completely off but that makes virtually no difference >(just like the datasheet indicates). No ADC conversions are taking >place while I sleep. I'm using the internal oscillator at 8Mhz. MCLR >is disabled and tied to ground. Brown out is disabled and watch dog is >disabled. No timers are being used. I wake up with RB0 interrupts once >per second and that's all working perfectly. > >I'm measuring current at the Vcc pin of the PIC. My meter is not the >greatest in the world, but it seems capable of giving me reasonable >readings at lower currents than 120uA. Any ideas as to what I have >missed? The only things I specifically enabled are: the ADC, RB0 ints, >the UART in async mode. > > > -- Note: To protect our network, attachments must be sent to .....attachKILLspam@spam@engineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Bob Axtell wrote: >> I've been tinkering with sleep mode on my data logger project ... > > Running the PIC at 8Mhz is the cause. Run the internal; oscillator at > 31Khz and watch. The OP said this was during sleep, so the oscillator doesn't matter since it will be shut down. At 8MHz it should take a lot more than 120uA. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

From: "Bob Axtell" wrote: > Oh, SLEEPing. Sorry. > Sure its sleeping? Thanks for the reply. I'm sure that it's sleeping correctly. I have a Dallas RTC that generates an RB0 int every second. After 30 ints (30 seconds) I write to a serial EEPROM via bit-banged I2C. That's all working perfectly. I have my DVM connected between my PS and the Vcc pin of the PIC. The rest of my circuit obtains power directly from the PS. > Try turning all the outputs to a state that the pins draw no current. Currently, I have only one output pin feeding a max232 for my serial out, the other outputs are unconnected. I even disconnected that from the max232 just in case it was drawing all that current, it wasn't of course. The only inputs I have are my Vref+, the ADC input and RB0. The errata has a note on high sleep current, but that's only if you switch oscillators. I don't do that, plus I'm using the one (INTOSC) that doesn't apply to the errata. I'm really stuck here.

> No floating input pins What is connected to RB0 and any other i/ps ? Is it maybe the external components using the power rather than the PIC ? What power do the ADC, UART take ? (personally interested as I'll shortly be needing to use F88 in SLEEP and don't yet have any to test) Does this affect you (from the F88 errata) ? 4. Module: PORTB Pull-ups When RBPU = 0 (OPTION register), the PORTB weak pull-ups will not be disabled by the input functions of the SSP and/or CCP (Capture mode) module as indicated by the RB1:RB5 I/O block diagrams in Section 5.0 "I/O Ports". Work around 1. If the SSP and/or CCP (Capture mode) module is enabled, do not enable the PORTB weak pull-ups and use external pull-up resistors. 2. If the SSP and/or CCP (capture mode) module and PORTB pull-ups are enabled, then evaluate the functionality of the SSP (I2C™/SPI™) or CCP (Capture mode) module to ensure proper operation within your application.

From: "Olin Lathrop" wrote: > Bob Axtell wrote: > >> I've been tinkering with sleep mode on my data logger project ... > > > > Running the PIC at 8Mhz is the cause. Run the internal; oscillator at > > 31Khz and watch. > > The OP said this was during sleep, so the oscillator doesn't matter since it > will be shut down. At 8MHz it should take a lot more than 120uA. Yep, it takes about 2-3mA when it's running. Any ideas on what the problem might be? One comparator or the Vref ladder are good candidates for the amount of extra current being consumed, but they are off AFAIK.

----- Original Message ----- From: "Jinx" <joecolquittKILLspamclear.net.nz> To: "Microcontroller discussion list - Public." <.....piclistKILLspam.....mit.edu> Sent: Saturday, March 26, 2005 8:09 PM Subject: Re: [PIC:] High sleep current on 16F88 > > No floating input pins > > What is connected to RB0 and any other i/ps ? Is it maybe the > external components using the power rather than the PIC ? RB0 is driven by the square wave output of a Dallas 1307 RTC. It's setup to trigger an int on the falling edge. That's working fine. > What power do the ADC, UART take ? (personally interested > as I'll shortly be needing to use F88 in SLEEP and don't yet have > any to test) ADC takes about 1uA (pretty insignificant to me right now) AIUI, the UART is dead when the PIC is asleep. Synchronous transfers can occur during sleep mode though. > Does this affect you (from the F88 errata) ? > > 4. Module: PORTB Pull-ups > > When RBPU = 0 (OPTION register), the PORTB > weak pull-ups will not be disabled by the input > functions of the SSP and/or CCP (Capture mode) > module as indicated by the RB1:RB5 I/O block > diagrams in Section 5.0 "I/O Ports". I'm not using capture mode and I don't have the pull-ups enabled, so I don't think this affects me. {Quote hidden}> Work around > > 1. If the SSP and/or CCP (Capture mode) module > is enabled, do not enable the PORTB weak > pull-ups and use external pull-up resistors. > > 2. If the SSP and/or CCP (capture mode) module > and PORTB pull-ups are enabled, then evaluate > the functionality of the SSP (I2C™/SPI™) > or CCP (Capture mode) module to ensure > proper operation within your application. > > -

I am interested because I have an LF88 in a current sensitive app, but I THOUGHT it worked OK (currents lower than that). er.. maybe a leaking cap? a Tantalum or ceramic disk? A WRONG value R someplace? Swap any standard electrolytics for Tantalum. Are those the LF88 specs or the F88 specs? If I recall, the LF88 was MUCH better. Can you try an LF88? I have an extra SOIC18 version.. --Bob michael brown wrote: >{Original Message removed}

Olin Lathrop wrote: >Bob Axtell wrote: > > >>>I've been tinkering with sleep mode on my data logger project ... >>> >>> >>Running the PIC at 8Mhz is the cause. Run the internal; oscillator at >>31Khz and watch. >> >> > >The OP said this was during sleep, so the oscillator doesn't matter since it >will be shut down. At 8MHz it should take a lot more than 120uA. > > >***************************************************************** >Embed Inc, embedded system specialists in Littleton Massachusetts >(978) 742-9014, http://www.embedinc.com > > I corrected immediately, but you might not have seen it. <G> --Bob -- Note: To protect our network, attachments must be sent to EraseMEattachspam_OUTTakeThisOuTengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Jinx wrote: >>RB0 is driven by the square wave output of a Dallas 1307 RTC >> >> > >That's the only i/p ? > >Have you tried starting with a totally disconnected F88 and adding >connections, measuring as you go ? > > > Yes, how about just raising the VDD pin, see if its REALLY caused by the F88. --Bob -- Note: To protect our network, attachments must be sent to attachspam_OUTengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Jinx wrote: >>>MCLR is disabled and tied to ground. >>> >>> >>MCLR tied to ground seems just "odd". >>Tied to VCC seems more correct... >> >> > >Pin4 is ST input-only and can be set in CONFIG1 as /MCLR >or RA5. If set as RA5, /MCLR is tied to Vdd internally. RA5 >can be pulled low or high > > > I think what he was thinking (as was I), Jinx, is that MCLR has an internal pullup in some modes, it would be on all the time if grounded. But I don't THINK it should be active... but maybe the documentation is faulty and that is it... --Bob -- Note: To protect our network, attachments must be sent to @spam@attachKILLspamengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

> I think what he was thinking (as was I), Jinx, is that MCLR has > an internal pullup in some modes, it would be on all the time if > grounded. Yes, a pulldown+pullup would cause unnecessary power usage > But I don't THINK it should be active... but maybe the > documentation is faulty and that is it..... I inferred from the OP's "disabled" that pin4 is set as RA5, in which case (functionally, maybe not from a consumption POV), up or down doesn't matter as /MCLR is inactive

On March 26, 2005 08:10 pm, Jinx wrote: > > I think what he was thinking (as was I), Jinx, is that MCLR has > > an internal pullup in some modes, it would be on all the time if > > grounded. > > Yes, a pulldown+pullup would cause unnecessary power usage > > > But I don't THINK it should be active... but maybe the > > documentation is faulty and that is it..... > > I inferred from the OP's "disabled" that pin4 is set as RA5, in > which case (functionally, maybe not from a consumption POV), up > or down doesn't matter as /MCLR is inactive No problem, but Bob was right, I thought pullup (old school thinking). Well, rather than looking at who's right or wrong, how about having the O/P try it? Probably means desoldering some pin and attaching some resistor (more work than reprogramming). Here's the reference again: ww1.microchip.com/downloads/en/DeviceDoc/30487c.pdf very bottom of page 145: The documentation also mentions to place the pin at "Vihmc" additionally, page 163 seems to follow more of the same thought: note#2 connect MCLR to Vdd using a pullup resistor. Short of those, the O/P needs to verify that he has in fact turned-off other things which are turned on during reset such as PWM, serial I/O and other kitchen-sink hardware on the chip.

----- Original Message ----- From: "Bob Axtell" <KILLspamengineerKILLspamcotse.net> To: "Microcontroller discussion list - Public." <RemoveMEpiclistTakeThisOuTmit.edu> Sent: Saturday, March 26, 2005 9:40 PM Subject: Re: [PIC:] High sleep current on 16F88 {Quote hidden}> Jinx wrote: > > >>RB0 is driven by the square wave output of a Dallas 1307 RTC > >> > >> > > > >That's the only i/p ? > > > >Have you tried starting with a totally disconnected F88 and adding > >connections, measuring as you go ? > > > > > > > Yes, how about just raising the VDD pin, see if its REALLY caused by the > F88. I put the same PIC on another breadboard and got exactly the same results. Sleep current is right at 119uA-120uA. I'm going to try another PIC right now......well I'm back and a different chip does exactly the same thing (well it's 118uA-119uA). Now, I'm sure that it's something I've missed, does anyone have any ideas? There must be something turned on (at reset) that I don't know about. Could it be the internal oscillator block? The datasheet doesn't show a SLEEP "input" to it like the xtal oscillators have. Is it possible that the internal oscillator block is really running all the time, even during sleep? Perhaps I don't understand the oscillator block fully and I am subject to the errata after all. I will try setting the clock back to 31.25 (by clearing OSCCON) before I sleep and see if that makes any difference. Here is my CONFIG word stuff: __CONFIG _CONFIG1, _CP_OFF & _CCP1_RB3 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_ON & _WDT_OFF & _INTRC_IO Ends up a 0x2F10 for __CONFIG1 __CONFIG _CONFIG2, _IESO_OFF & _FCMEN_OFF Results in 0x3FFC for __CONFIG2

Olin Lathrop wrote : > Bob Axtell wrote: > > > I corrected immediately, but you might not have seen it. > > I process PIClist mail in the order received. I saw your > correction right after posting mine. This time the messages was just a short time apart, which might be understandable. But sometimes when you have returned from a couple of days off and begin to reply with duplicated replies (due to your "method" of not taking the time to read the whole thread so far), it can get a bit anoying, Sometimes I've been close to writing a post just saying "wasn't that exactly what I said before ??"... :-) But, now I know about your way of handling the list , so I don't. > That's the nature of email lists. Hm, well maybe in this specific case. But when you reply to several days old posts with (more or less) duplicate posts, it's more an effect of how *you* have selected to handle the list. Not something related to the nature of mail lists as such... Personaly I prefer to check all replies so far so I don't clutter the list with stuff already said... Don't get me wrong here, this isn't a major problem. I just thought I had to react on your statement about the "nature of email lists". I don't agree on that point. Best Regards, Jan-Erik.

Jan-Erik Soderholm wrote: > But sometimes when you have returned from > a couple of days off and begin to reply with duplicated > replies (due to your "method" of not taking the time > to read the whole thread so far), it can get a bit > anoying, Sorry about that. When I've been gone for more than a day or so, I usually do try to look thru future posts a bit before replying. In this case I've been on regularly, and it couldn't have been more than half a day since the last time I checked the mail and responded. When I know I'm going away for a while, I usually set NOMAIL, if for no other reason than to keep my input queue from getting overrun. Scanning forward to look for future replies is rather awkward, so it's not something I want to do regularly. That's what I meant by it being an email list instead of a web forum where you see all replies to something immediately there. Don't get me wrong, however, I find the email interface more convenient than a web forum, although it has this issue. I think people just need to understand that chronological order and cause/effect can get scrambled within about a 24 hour window due to various effects. > Personaly I prefer to check all replies so far so I don't clutter > the list with stuff already said... That is rather awkward to do for me, at least with the setup I've got. Maybe there is a way to set it up differently, but this is desirable for all my other email, and it works fine for the PIClist in most cases too. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Sun, 2005-03-27 at 14:10 -0500, Olin Lathrop wrote: > Scanning forward to look for future replies is rather awkward, so it's not > something I want to do regularly. That's what I meant by it being an email > list instead of a web forum where you see all replies to something > immediately there. Don't get me wrong, however, I find the email interface > more convenient than a web forum, although it has this issue. I think > people just need to understand that chronological order and cause/effect can > get scrambled within about a 24 hour window due to various effects. > > > Personaly I prefer to check all replies so far so I don't clutter > > the list with stuff already said... > > That is rather awkward to do for me, at least with the setup I've got. > Maybe there is a way to set it up differently, but this is desirable for all > my other email, and it works fine for the PIClist in most cases too. I see you're still using OE. Aside from avoiding all the problems associated with using OE switching to pretty much ANY other more modern alternative will get you a feature VERY useful for email lists: threading. Threading makes checking replies a joke, which results in less of your time and other people's time wasted. ----------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/

Olin Lathrop wrote : > > Personaly I prefer to check all replies so far so I don't clutter > > the list with stuff already said... > > That is rather awkward to do for me, at least with the setup I've got. > Maybe there is a way to set it up differently, but this is desirable for > all my other email, and it works fine for the PIClist in most cases too. Fine, as I said, no major problem. :-) The way I've set my mail client up (Outlook 2000, b.t.w), I get all piclist related mails moved into a separete subdir in my "Inbox". Each "tag" has it's own sub-subdir. In each subdir, all mails are sorted and grouped per "thread" and, in each thread, sorted by date/time. So, if I've been away for some time, I can rather quickly browse a particular thread and update myself before "diving in", so to speak. Sometimes the last (most current) entry in each thread is enough to get the hang of it. Actualy saves me time, since I don't have to take time writing what someone else already have written. I seems to remember that you use Outlook Express, and it might very well be that OE don support "group by subject", I don't know. (Right know, while writing this, Herbers post on the same topic (OE) arrived, so, maybe I should have removed this section ! :-) :-) ) B.t.w, I use the "sort/group by subject" option on all my regulary Inbox subdirs also. Makes it realy easy to follow multiple cuncurrent mail conversations. Anyway, I've probably spoiled to much of everyones time already... Best Regards, Jan-Erik.

Herbert Graf wrote: > I see you're still using OE. Aside from avoiding all the problems > associated with using OE switching to pretty much ANY other more modern > alternative will get you a feature VERY useful for email lists: > threading. I use what I use for a variety of reasons. The PIClist just tags along. It seems to me that more than one person occasionally replying with the same thing is a very minor issue, and certainly not worth changing a tool suite over. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Jan-Erik Soderholm wrote: > I seems to remember that you use Outlook Express, and it might > very well be that OE don support "group by subject", I don't know. I sortof remember trying something like that a few years back and it had some other undesirable effects. As you pointed out, this is a minor problem, and I don't want to spend time changing the way I do things because of it. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Sun, 2005-03-27 at 17:01 -0500, Olin Lathrop wrote: > Herbert Graf wrote: > > I see you're still using OE. Aside from avoiding all the problems > > associated with using OE switching to pretty much ANY other more modern > > alternative will get you a feature VERY useful for email lists: > > threading. > > I use what I use for a variety of reasons. The PIClist just tags along. It > seems to me that more than one person occasionally replying with the same > thing is a very minor issue, and certainly not worth changing a tool suite > over. You're right, this ONE issue isn't enough to change tools, but I think all the OTHER issues that OE brings makes it MUCH more valid to switch tools, this issue being the "final straw". I can't of course force you, but given the amount of pain OE has caused THE PLANET I certainly can't help suggesting someone changes. To me it's like smoking... ----------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/

From: "Bob Ammerman" > What current does your multimeter read if placed in series with your power > supply and a 1M resistor, how about a 5M or so? With a 1M, I get 5uA With a 5M the reading starts to get a bit "jumpy" but still gets the point across. 10M is hopeless though. > when all else fails: check your tools Thanks for the advice. I guess I can admit that my meter is from radio shack (looks just like a Fluke, just the wrong color). It's a Micronta 22-167 circa 1992ish. I don't know whose design/build it is, but it has been a decent meter. Any recommendations for something in the $100-$200 range from Fluke? Maybe a Fluke 179? ;-) > Bob Ammerman > RAm Systems > > {Original Message removed}

From: "Bob Axtell" > I am interested because I have an LF88 in a current sensitive app, but > I THOUGHT it worked OK (currents lower than that). > > er.. maybe a leaking cap? a Tantalum or ceramic disk? A WRONG value > R someplace? Swap any standard electrolytics for Tantalum. > > Are those the LF88 specs or the F88 specs? If I recall, the LF88 was MUCH > better. Can you try an LF88? I have an extra SOIC18 version.. Even though my problem turned out to be an apparent bug in the hardware, I wanted to comment on this last part. AIUI, all parts have the same specs except that the L (low voltage) parts are guaranteed to work at a lower voltage. Voltage certainly plays an important role in how much current is drawn, so the L parts are "better" in that respect, but they aren't otherwise different from the 'non-L' parts. IOW, at 5V they are all the same. ;-) The DS1307 requires at least 4.5V, but I'm sure there are some 2V or 3V minimum parts available. I've been experimenting, now before I put it to sleep, I power off the EEPROMs, DS1307, LM34 and my external Vref for the ADC. Sleep current for the whole circuit is <5uA. The DS1307 runs off a lithium backup cell when the circuit is asleep. The square wave output of the DS1307 continues to function with no power applied to the Vcc pin (Vbat does the job). I use a way big (3.3M) pull-up on the square wave output for super-low current draw (1.5uA) during the low half of the cycle. The RB0 int fires on the falling edge with no problems caused by the really weak pull-up. The duty cycle is only 1Hz so rise time is not an issue. The 1.5uA is small but it still accounts for a large chunk of the total sleep current of the circuit.

Thanks, Mike, good stuff. --Bob michael brown wrote: {Quote hidden}>From: "Bob Axtell" > > > > >>I am interested because I have an LF88 in a current sensitive app, but >>I THOUGHT it worked OK (currents lower than that). >> >>er.. maybe a leaking cap? a Tantalum or ceramic disk? A WRONG value >>R someplace? Swap any standard electrolytics for Tantalum. >> >>Are those the LF88 specs or the F88 specs? If I recall, the LF88 was >> >> >MUCH > > >>better. Can you try an LF88? I have an extra SOIC18 version.. >> >> > >Even though my problem turned out to be an apparent bug in the hardware, >I wanted to comment on this last part. AIUI, all parts have the same >specs except that the L (low voltage) parts are guaranteed to work at a >lower voltage. Voltage certainly plays an important role in how much >current is drawn, so the L parts are "better" in that respect, but they >aren't otherwise different from the 'non-L' parts. IOW, at 5V they are >all the same. ;-) The DS1307 requires at least 4.5V, but I'm sure >there are some 2V or 3V minimum parts available. > >I've been experimenting, now before I put it to sleep, I power off the >EEPROMs, DS1307, LM34 and my external Vref for the ADC. Sleep current >for the whole circuit is <5uA. The DS1307 runs off a lithium backup >cell when the circuit is asleep. The square wave output of the DS1307 >continues to function with no power applied to the Vcc pin (Vbat does >the job). I use a way big (3.3M) pull-up on the square wave output for >super-low current draw (1.5uA) during the low half of the cycle. The >RB0 int fires on the falling edge with no problems caused by the really >weak pull-up. The duty cycle is only 1Hz so rise time is not an issue. >The 1.5uA is small but it still accounts for a large chunk of the total >sleep current of the circuit. > > > -- Note: To protect our network, attachments must be sent to spamBeGoneattachspamBeGoneengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

> weak pull-up. The duty cycle is only 1Hz so rise time is not an > issue. The 1.5uA is small but it still accounts for a large chunk > of the total sleep current of the circuit. Michael, the best combo I've found so far for a data logger is a 12F675 + kitchen clock coil driver. Sleeping 12F675 is ~10nA and coil driver is < 100nA (0.5Hz o/p). It also has much better long-term stability than anything with a 32k xtal like an RTC chip but no inherent calendar or comms functions of course. The above combo may be too simple for your requirements but even a small battery will last a very long time

----- Original Message ----- From: "Jinx" <TakeThisOuTjoecolquittEraseMEspam_OUTclear.net.nz> To: "Microcontroller discussion list - Public." <RemoveMEpiclistTakeThisOuTmit.edu> Sent: Monday, March 28, 2005 3:36 PM Subject: Re: [PIC:] High sleep current on 16F88 > > weak pull-up. The duty cycle is only 1Hz so rise time is not an > > issue. The 1.5uA is small but it still accounts for a large chunk > > of the total sleep current of the circuit. > > Michael, the best combo I've found so far for a data logger is a > 12F675 + kitchen clock coil driver. Sleeping 12F675 is ~10nA 10nA huh, that's pretty small. The F88 datasheet claims 100nA, but that's at 2V. It also claims 600nA at 5V, I thought this stuff was supposed to be linear? ;-) I'm way above 600nA at 5V (3.3uA), but I didn't make all the pins inputs or set all the pins in ANSEL as analog. That would probably lower my sleep current a bit more, but at this point I'm kinda skeptical of seeing 600nA. OTOH, changing the oscillator speed before sleeping shaved >115uA off the sleep current. > and coil driver is < 100nA (0.5Hz o/p). It also has much better > long-term stability than anything with a 32k xtal like an RTC chip I don't understand, what does it use for the timebase if not a xtal? > but no inherent calendar or comms functions of course. The above > combo may be too simple for your requirements but even a small > battery will last a very long time That's interesting to me as it's certainly low power. I'm really just tinkering right now to see what I can come up with.

> > Sleeping 12F675 is ~10nA > > 10nA huh, that's pretty small The ones I've tried are actually 6nA > > long-term stability than anything with a 32k xtal like an RTC chip > > I don't understand, what does it use for the timebase if not a xtal? They do use a crystal - must be factory-trimmed or compensated or something. Probably around a minute or so per year accurate. Which implies overall stability of 0.00002% or tuning a 32.768kHz crystal to within 0.00655Hz and keeping it there BTW, I've dropped a "please enlighten me" email to Microchip about the F88 errata

On March 28, 2005 11:30 pm, Jinx wrote: > > > Sleeping 12F675 is ~10nA > > > > 10nA huh, that's pretty small > > The ones I've tried are actually 6nA > > > > long-term stability than anything with a 32k xtal like an RTC > > > chip > > > > I don't understand, what does it use for the timebase if not a > > xtal? > > They do use a crystal - must be factory-trimmed or compensated > or something. Probably around a minute or so per year accurate. > > Which implies overall stability of 0.00002% or tuning a 32.768kHz > crystal to within 0.00655Hz and keeping it there I think what may have been snipped was that the timebase came from a kitchen timer running from the AC power line... which means it is "atomic clock" accurate over the long run (despite the slow drifts back-n-forth over a day). So yes, that would definitely beat-out crystal time bases if you are looking for long-term stability. ;-)

> > Which implies overall stability of 0.00002% or tuning a > > 32.768kHz crystal to within 0.00655Hz and keeping it there > > I think what may have been snipped was that the timebase came > from a kitchen timer running from the AC power line No, I was talking about the common-or-garden wall clock with a 1.5V battery. Think about how far adrift they get over 6 months or a year - not very much at all. When our clocks recently went back an hour my bedroom clock was just 25 seconds out (slow) when compared to the radio, which is how I always set it when DST starts or finishes. Honest !! Call me freakin' daffy but I like my clocks and VCRs etc to be as accurate as they can be so I do notice. I'd use a coil driver over an RTC for a long-period datalogger any time

----- Original Message ----- From: "Jinx" <joecolquittEraseME.....clear.net.nz> To: "Microcontroller discussion list - Public." <EraseMEpiclistmit.edu> Sent: Tuesday, March 29, 2005 1:30 AM Subject: Re: [PIC:] High sleep current on 16F88 > > > Sleeping 12F675 is ~10nA > > > > 10nA huh, that's pretty small > > The ones I've tried are actually 6nA How do you measure that? > > > long-term stability than anything with a 32k xtal like an RTC chip > > > > I don't understand, what does it use for the timebase if not a xtal? > > They do use a crystal - must be factory-trimmed or compensated > or something. Probably around a minute or so per year accurate. I've been running a 1307 with a 32k crystal (on a solderless breadboard no less) and it's keeping great time. After two weeks it's still within a couple of seconds of where I set it. It didn't seem that accurate at first, but after I grounded the case of the tiny crystal, this seemed to really make a difference. AIUI, if you're having trouble with them running fast then noise is the most likely culprit. > Which implies overall stability of 0.00002% or tuning a 32.768kHz > crystal to within 0.00655Hz and keeping it there Shouldn't that be .0002% ;-) > BTW, I've dropped a "please enlighten me" email to Microchip > about the F88 errata This should be interesting. I wonder how long it will take them to respond?

> From: "Jinx" <RemoveMEjoecolquittEraseMEEraseMEclear.net.nz> > > Michael, the best combo I've found so far for a data logger is a > > 12F675 + kitchen clock coil driver. Sleeping 12F675 is ~10nA Jinx, Can you give a pointer to a kitchen clock coil driver? Google didn't pop up anything useful under that designation. I have a project with a 32 kHz crystal that drifts like an unmoored sailboat. I was planning on reengineering with a optoisolated interface to the power line, but would be interested in investigating other solutions. Thanks, BAJ

> > The ones I've tried are actually 6nA > > How do you measure that? Voltage drop across a 1M resistor (from memory - it was last year), suggested by Herbert. I've a meter that goes down to 100nA which seemed to confirm that method was OK > I've been running a 1307 with a 32k crystal (on a solderless > breadboard no less) and it's keeping great time. After two > weeks it's still within a couple of seconds of where I set it. It > didn't seem that accurate at first, but after I grounded the case > of the tiny crystal, this seemed to really make a difference 1s per week sounds good. The current consumption for an RTC is maybe 4-5 times higher though I generally ground crystal cases too, it does help stop external noise upsetting the PIC, even if it's not necessarily a clock > > Which implies overall stability of 0.00002% or tuning a > > 32.768kHz crystal to within 0.00655Hz and keeping it there > > Shouldn't that be .0002% ;-) Yes, it should. For some reason I had 5259600 instead of 525960 for sec/year so (sec/sec-1)*100 came out 10x too big

The newer crops of inexpensive clock movements are far less accurate than they used to be so, in the future you may need to try quite a few before you get the 2ppm accuracy you have seen. All of the large manufacturers have changed their standard products to 20ppm. To painlessly get better than 2ppm at indoor temperatures you can use the DS32KHZ from Dallas-Maxim. This temperature compensated crystal oscillator works with most Dallas RTC chips. Paul >{Original Message removed}

> >>> Which implies overall stability of 0.00002% or tuning a > >>> 32.768kHz crystal to within 0.00655Hz and keeping it there > > Do you really believe that the crystal/oscillator in your $10 kitchen > clock is really more accurate and/or better tuned than a purchased > crystal in an CPU oscillator? You might have gotten lucky... Sure I believe ;-) The evidence is on everybody's walls. What's not to believe ? (although the figures above are a magnitude too good) Oh, and shop around

William Chops Westfield wrote: > Do you really believe that the crystal/oscillator in your $10 kitchen > clock is really more accurate and/or better tuned than a purchased > crystal in an CPU oscillator? Yes. A typical cheap CPU crystal is accurate to 50ppm if wired up right. That's an error of about 130 seconds/month. You wouldn't tolerate that from a watch or a battery operated clock. Because of this, the manufacturing technology for making very accurate but cheap 32768Hz crystals is more advanced and the volumes are very high. I would expect a $10 kitchen timer to contain one of these crystals because it's the cheapest way to go. They probably use a lower grade than watch crystals, but they still likely do better than 50ppm. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com