NAP command
Archiver
Posts: 46,084
I am using the NAP command to save battery life. I am using NAP 100
but it is difficult from the documentation to determine the
approximate amount of real-time NAPping which it will yield. Also, I
cannot find any reference to what the upper limit of the NAP command
is. Does anyone have experience with the NAP command?
but it is difficult from the documentation to determine the
approximate amount of real-time NAPping which it will yield. Also, I
cannot find any reference to what the upper limit of the NAP command
is. Does anyone have experience with the NAP command?
Comments
>but it is difficult from the documentation to determine the
>approximate amount of real-time NAPping which it will yield. Also, I
>cannot find any reference to what the upper limit of the NAP command
>is. Does anyone have experience with the NAP command?
NAP only accepts values from 0 to 7. Do you have the manual (version
2.0). It is quite clear about the operation.
NAP 7 gives a powerdown interval of about 2 seconds. Other NAPs are
1 second, 1/2 second, 1/4 second and so on down to 1/128 second
(about 16 milliseconds). The original BASIC Stamp with the PIC57 has
slightly longer intervals, 18 milliseconds up to 2.3 seconds.
NAP 100 would probably give 1/4 second, because 100//8=4.
Maybe you want SLEEP instead of NAP. SLEEP 100 would give you very
close to 100 seconds. The Stamp wakes up briefly once every 2.3
seconds to check if the 100 seconds is up yet, and to calibrate the
time against the resonator time base.
Does that answer the question?
-- Tracy
>Thanks for the explanation. I did re-read the doc as well. I
>switched to the SLEEP command. I'm using a SLEEP 10 to get a 10
>second delay in a loop. But, the Debug window which displays date and
>time from a DS1302 IC shows that the SLEEP 10 command is not causing
>a 10 second delay. Perhaps I need to refer this to Parallax. The code
>segment is below:
What delay *are* you getting? About 11.5 seconds? If so that would be as
documented for the Sleep command.
Jim H
>time from a DS1302 IC shows that the SLEEP 10 command is not causing
>a 10 second delay. Perhaps I need to refer this to Parallax. The code
>segment is below:
The SLEEP interval is based on the watchdog timer, which comes down
to an RC circuit inside CPU chip, not a crystal or resonator. So the
time is _approximately_ 2 seconds. The manual says 2.3 seconds,
which I have found to be true for the original BS2, but the it is
more like 1.9 seconds for the SX based Stamps (2sx, 2e and 2p). It
is also dependent on temperature and your individual variation in
chips.
SLEEP 1 gives ~2 seconds, as does SLEEP 2.
SLEEP 10 will give something a bit greater than 10. For example, if
you are using a BS2IC, the granularity will be 2.3, 4.6, 6.9, 9.2,
11.5, etc, so, as Jim points out, you are most likely to see 11.5
seconds, because that is the first test above 10. The granularity
for the SX based Stamps is 1.9, 3.8, 5.7, 7.5, 9.3, 11.1. Was that
what you were seeing?
If you test a longer interval, like SLEEP 60, you will find that it
is much more accurate, as in less than one second error. The reason
for that is that the Stamp tests the watchdog timer against the more
accurate resonator and makes adjustments. That begs the question of
how long a SLEEP interval you need to get within one second, but I
don't know. I am not even sure what adjustment is already made in 10
seconds.
When I need to both use SLEEP and wake up at a certain rate, I key
the SLEEP interval to what I read from the RTC. For example, to wake
up at 10 second intervals:
loop:
gosub readRTC
seconds = seconds.nib1*10+seconds.nib0 ' BCD->binary
debug ? seconds
SLEEP 10-(seconds//10) ' time remaining this interval
goto loop
which won't come out exactly on each 10 second interval, but it will
reliably give 6 loops per minute.
-- best regards
Tracy Allen
electronically monitored ecosystems
http://www.emesystems.com
mailto:tracy@e...
-- Tracy