Dear,
For a meteorological instrument I building a simple data logger with software as :
10 REM pin 1 tot 3 analog inputs
20 SETPIN 0,2
30 SETPIN 1,1
40 SETPIN 2,1
50 SETPIN 3,1
60 SETPIN 4,1
70 REM OUTPUT PIN TO SHOW ACTIVITY
80 SETPIN 20,8
90 REM PIN TO LOG BATTERY VOLTAGE
100 SETPIN 21,1
110 OPEN "B:DATA_1.DAT" FOR APPEND AS #1
120 V$ = DATE$
130 REM PRINT TO FILE (BAT = BAT*3.13
140 PRINT #1,V$,TIME$,PIN(21),PIN(1),PIN(2),PIN(3),PIN(4)
150 CLOSE #1
160 REM experimental sleep to go to low power mode
170 SLEEP MINUTE
180 PIN(20) = 1
190 IF PIN(0)=1 THEN PAUSE 1000
200 PIN(20) = 0
210 GOTO 110
but it seems not to do what I was expecting :
1. After startup and executing autorun.bas, it stops after 3 of 4 minutes, so I see in the log file 3 or 4 lines and then it stops somehow, on the consumed current I can see that it's not in sleep any more (note: I only have a tty connected, no screen..).
2. It does consume in normal operation about 120mA, and during the sleep mode about 10mA.
I expect a issue with the sleep command, if I take it out and replace it with a pause, all works fine, but as the devices is installed at a remote location powered by batteries, 120mA is way to much (reason I did choose for this Duinomite was the as published 30uA consumption). I'm running firmware 2.7004.
Any help in getting this Duinomite to as low power mode as possible for one minute and coming back alive on a reliable way ?
Many thanks for your help,
Johnny
Hello Johnny,
Did not know the SLEEP command in DMBASIC 2.7004. As far as I know it is not documented in the Duinomite manual. However it seems to work I noticed, at least at the start.
I just powered my Duinomite MEGA from the USB port and have connected a USB power monitor in between. At startup the power is 5.08 Volt and the current is 0.12A. After SLEEP MINUTE the current becomes 0.01A and after one minute it is again 0.12A. So far, so good. Same measurements as you had.
However after the command the system is hanging indeed. So it seems to have forgotten where it was.
I rewrote the firmware already for my own CAN applications, so I know where to find the source code in DMBasic 2.7004. Unfortunately I'm not in the office in the weekend, but I will check the sources on monday and see if I can find the reason why the program does not continue after the sleep. The SLEEP command can be useful for my applications too. At least if it works ....
Kees
Had a look into the sources and got the impression that the routine was not really edited and screened for the Duinomite modules. A lot of IO functions are disabled. I saw also a reset of the SDcard. Maybe that is the reason for your logging problem. I will check further in detail later. Do you have the possibility to change the firmware youself?
Kees
Did some further tests with the existing firmware. As far as I have seen, the only problem is the USB interface which does not come back after the SLEEP.
I tested the following program with a monitor and keyboard connected:
10 OPEN "log.txt" FOR output AS #1
20 PRINT #1,"Start"
30 CLOSE #1
40 FOR x=1 TO 10
50 OPEN "log.txt" FOR append AS #1
60 PRINT #1,x
70 CLOSE #1
80 PRINT "Go to sleep"
90 PAUSE 1000
100 SLEEP minute
110 PAUSE 1000
120 PRINT "Wake up"
130 NEXT
After 10 minutes my logfile contained: "Start" and the values of 1 to 10.
In your program I think you have to repeat the SETPIN procedures after every SLEEP. The controller forgets the I/O configuration when it gets to SLEEP. Further I advise not to use PIN 20 for indication, because this pin is shared with the horizontal SYNC of VGA. You can use PIN 0 both as input for the USER switch and output for the Green LED. SETPIN 0,x has no function. Print PIN(0) will always print the status of the USER switch and PIN(0)=x will light the green LED whenever x>0.
The only problem I like to solve is the USB control. In fact the USB input is still working after the SLEEP. Characters from my connected PC are shown on the VGA display. Only my PC terminal is not showing the output anymore. So for your application you have to reset the Duinomite, before you have control again and can read out the logfile.
Hope this helps you further.
Kees
Good morning Kees,
Just spend some time on the project, and modified the test program as :
10 REM pin 1 tot 3 analog inputs
20 SETPIN 1,1
30 SETPIN 2,1
40 SETPIN 3,1
50 SETPIN 4,1
60 F$ = "B:"+RIGHT$(DATE$,7)
70 OPEN F$ FOR APPEND AS #1
80 V$ = DATE$
90 PRINT #1,V$,TIME$,PIN(21),PIN(1),PIN(2),PIN(3),PIN(4)
100 CLOSE #1
110 PIN(0) = 1
120 PAUSE 100
130 PIN(0) = 0
140 SLEEP MINUTE
145 PRINT MM.SLEEP
150 GOTO 20
Looking at the green LED, indeed, it seems to work, I'll keep it running for a while and keep you informed if this is stable. I can confirm that the tty does not come alive after the sleep, the print does work.
Just in case, are there other steps that could even lower the consumption more ?
Also for the other readers the sleep command as :
sleep minute // Sleep for 1 minute from current time date
sleep Hour // Sleep for 1 hour from current time date
sleep day // Sleep for 1 day from current time date
sleep week // Sleep for 1 week from current time date
sleep month// Sleep for 1 month from current time date
sleep year // Sleep for 1 year from current time date
after it wakes check MM.SLEEP
1 = Sleep completed
2 = pin 7 ext Interrupt
4 = BUT Interrupt
8 = PS/2 Interrupt
More later, many thanks.
Good news that it is working so far.
As far as I have seen now I can imagine that the power can be lowered further. I will start some project to make the SLEEP command more flexible. I think power can be further reduced by switching off some external components like USB, PS/2, all I/O pins, COM ports, etc. For me it is important that the unit can also awake by a CANbus message. I know the internal CAN controller is prepared for that also. My goal is to get a completely configurable wake-up utility. I will keep you informed.
Kees
More good news today:
1. I succeeded in switching off and on the USB TTY. I disabled all interrupts and switched off the power to the controller. Now you hear the beep of switching off on the PC when the Duinomite goes to sleep. Ofcourse you have to disconnect also the terminal on the PC side now. After the sleep power and interrupts are switched on again and you hear the beep on the PC that the connection is made again. Make a new connection to the Duinomite and everything is up and running again. Unfortunately it is not possible to do it without switching off and on, because the PC driver needs to get the interrupts from the Duinomite during connection, otherwise Microsoft declares the connection dead and you have to give a hard reset by disconnecting the device.
2. I think I have found the reason for still having the 10mA in SLEEP mode. Probably you measured the current in the same way I did. Power from USB and measure Voltage and Current at the 5 Volt of the USB port. Unfortunately my low-cost (3 EURO) USB multimeter only has a resolution of 10 mA. I got the same results as you had 120 mA working, 10 mA sleeping. I also use PIC32-T795 of Olimex, without VGA, KB, CAN, SD. Results now: 100mA/0mA. I use this module with a carrierboard, which has two CAN transceivers and a Powerregulator. I did not use the regulator for the test, but powered also now through USB and ... 120mA/10mA. Reading the specification of the MCP2551 (used CAN transceiver): Power 5V/10mA in normal use. So back to the Duinomite: the current in SLEEP mode is probably mostly caused by the CAN transceiver.
Three solutions:
1. The easy one: If you are powering by a 3.7 V LIPO battery on the board, the transceiver will not be activated anyway, because it is powered by the 5 Volt, so probably the current will be much lower from this battery.
2. The MCP2551 has a standby mode also. This mode is activated by a connection of PIN 8 of the chip to Vcc. This pin is now connected via R49 on the board to GND. To change this you can cut the connection of PIN 8 to R49 (top side of the PCB) and place a resistor of e.g. 10k to 5V.
3. The nicest one and I will try to change this in my new hardware/software is: the connection of the other side of te resistor to a free output of the PIC32 controller and swith this output whenever the SLEEP mode is entered.
Kees
Hallo Kees,
Nice progress :-)
I'm using a duinoMite, not the mega, it does not have the CAM bus controller.
I'm highly interested in you code that does bring back the serial link after a sleep command, I did tests today and my piece of software as above does stop working after a time of 50 minutes to 7 hours (tested with 2 different board to exclude HW issues) and when it's dead (no more blinking of the green led) I do not find a way to find out why, only a reboot does bring it back.
I did tests powering it with battery connector, but also there, when sleeping it does consume 10mA
Many thanks for your information
Johnny
Hello Johnny,
OK Duinomite, no SD-card, no CAN. Do you have a VGA monitor and/or PS2 keyboard connected? Do you use the Duinomite power supply to power your sensors? Except for the VGA and PS2 the hardware is very much like the PIC32-T795. Sorry I cannot test with the Duinomite, because I don't have that module.
Concerning the stop after some times, following suggestions:
1. Delete line 145; it tries to write to the USB, but that does not work, so maybe buffer overflow ??? I suggest to include the MM.SLEEP parameter in the logfile, so add to line 90.
2. Do some extra faster loops by using the USER button, because that also wakes up the loop. See if it crashes earlier.
For your information: the sleep command uses the PIC32 RTCC (Real Time Calender Clock). This is a stand alone running clock, which is not further used by DMBasic. That means that the DATE and TIME commands don't adjust the RTCC date and time. The "sleep minute" command in principle reads the RTCC and sets the alarm to the next minute. I must see what happens exactly, but I can imagine that it will not come out of the sleep whenever a new hour or a new day starts. I will see if I can get the information out of registers using some Basic PEEK commands.
Kees
Correction: For the Duinomite DATE and TIME are based on the RTCC. It was not the case for the original Maximite. So it is interesting to know the date and time when the logger has stopped working.
Hallo Kees,
- I have nothing connected to the Duinomite, it's powered via USB so not possible interference, a clean new board.
- This afternoon I did make the required connections for a screen and keyboard, but I have to say, it did not help in understanding the issue, after a sleep, the screen does not come back, also not if I runs sleep in the prompt.
- Not sure if it's useful, the tests failed at :
Stopped first time :
00-00-2000 04:52:00 4.02402 1.375 1.12847 0.956055 1.04683
Stopped secound time :
00-00-2000 07:34:00 4.0396 1.54688 1.31162 1.1897 1.24287
Stopped the 3 time :
00-00-200000:52:00 4.18945 1.37983 1.1376 1.02104 1.12954
all tests are started with 00-00-2000 00:00:00 and two tests stop at xx:xx:52, but that seems not always the case
- deleting line 145 did not change the behaviour.
- I can simulate the problem with the USER button, if I press it, indeed the green led flashes and data gets on the card. In a test, after 35 times pushing the button, the led was not blinking any more.
- I do not set the time, so my Duinomite always start at 00-00-2000.
So I was wondering if with your board, with screen and keyboard, if you just type sleep minute, does the screen return alive after 60 sec ?
Many thanks,
Johnny
Hello Johnny,
Some remarks for the moment:
1. VGA returns at my Duinomite MEGA. I don't have tested composite video. However I think I introduced some delay after the wake-up. You should pause at least 1000 ms to let the VGA come up again.
2. Also noticed that connecting the keyboard and giving the command with this KB you should pause at least 200 ms before the sleep starts, otherwise the last hit of the keyboard will wake up from the sleep directly.
3. You have nothing connected to the inputs you say. I think that is risky with analogue inputs. When they are floating they can have any value and spikes caused by switching between sleep and awake can disturb the processor, breaking up and even kill it. I would suggest first try the routine without all I/O configuration and measuring. Just eliminate that possible problem.
4. As your test also goes wrong by using the USER button, we can conclude that it is not the RTCC which causes the problem.
5. On monday I continue developing the more flexible software and I will also start to do a long term test with some units.
Kees
Good morning Kees,
Good information, did some new tests, I can confirm that if I make a program as :
10 pin(0) = 1
20 pause 200
30 pin(0) = 0
40 sleep minute
50 goto 10
it also stops working after enough pushing on the USER button, meaning that the first about 50 to 100 times I see the LED blinking, then suddenly the led does not blink any more if I push the button. This may make the checking on the code more easy, at first, no need to check the card writing of pin reading software.
- I also use a VGA with H and V sync signals with a PS2 keyboard, so that's equal in our setup.
Have a nice day,
Johnny
Hello Johnny,
Include following two lines in your code:
35 pause 1000
45 pause 5000
Now you should see the VGA coming back after the sleep. The monitor needs a few seconds to synchronise. I can imagine that something goes wrong if the Duinomite goes to sleep during synchronising. The delay after the blinking is included to not interfering with the LED.
I tested now with a unit with the original DMBasic 2.7 and one with a modified code. The original one goes down after a while; with the modified one I did not notice that up to now. I don't know why. I can imagine that it has to do something with the synchronisation on the USB port. I changed the buffers and a little bit more. I think it is best to test with external power supply, without the connection to a USB communication on the PC.
Kees
Additional information:
I think you can make a reliable solution for your application this way (at least it works for me on the original DMBasic 2.7):
10 REM start do all kind of configuration up to line 90; this can be done by either TTY or KB/video
90 OPTION USB OFF:REM switch off USB port, because USB is not returning from sleep and let the system collapse.
100 REM start loop here; include PIN configuration, etc.
.
.
190 IF .... THEN END:REM include an optional END condition based on time or counter
200 GOTO 100
I'm quite sure that the USB communication was the bottleneck. If you don't need the VGA output you can skip the the long PAUSES.
Ofcourse now you have to reboot ofcourse to read out the logfile and/or restart
I will keep you and others informed about the progress on the more flexible SLEEP command.
Kees
Hallo Kees,
Many thanks for all your help, a quick update on a test I did today :
10 REM pin 1 tot 3 analog inputs
20 OPTION USB OFF
30 SETPIN 1,1
40 SETPIN 2,1
50 SETPIN 3,1
60 SETPIN 4,1
120 PIN(0) = 1
130 PAUSE 100
140 PIN(0) = 0
150 SLEEP MINUTE
160 GOTO 30
and also that one crashes after a while, no more blink and no reaction on the user button... Just in case you wonder, if I replace the sleep with pause, no problems, but as you know the power savings with sleep are important for my project.
There are more option ons the OPTION USB, could I use it to disable more ?
Cheers,
Johnny
Hello Johnny,
I think you did not quite understand me concerning the PAUSES. When the processor comes out of sleep, the video interrupt routine is started again and it lasts about one second to synchronise again with the monitor. If the loop directly continues the interrupt is disabled again. I don't know what is happening with the synchronisation process, but I do know that without the pause the screen will not come back. That is why I included the PAUSE 5000. Also the PAUSE 1000 makes sense, because it is possible that not all previous I/O commands are finished before the SLEEP starts. So the PAUSES are not a replacement of the SLEEP, just some protection.
If you don't need the VGA monitor in the real process, you can also disable that by OPTION VIDEO OFF. However for the moment I think it is good to see on the monitor that the system comes out of the SLEEP.
I did the test with my Duinomite with writing to a logfile a number which increments after every sleep. A number of minute timeouts and also stops by the keyboard and the USER switch and with the OPTION USB OFF it was incremented up to 100 without problems. Also with the monitor coming back everytime.
Kees
Hello Johnny,
Some additional information. I succeeded now in reproducing your problem with the original firmware on one of my Duinomite MEGA's. Used SLEEP SECOND and after that mostly within one minute it does not come out of the sleep. However with another unit running my modified code I cannot reproduce it. As far as I can see now I just included some millisecond delays directly after the sleep and the new initialisation of the SD card. I have seen anyway that the orignal code has a bug concerning the SD card. It will never come back if no drive B is found. I will change that also. However for the time being I like to finish my own project first. After that I will see if I can make the essential changes also available in the original DMBasic 2.7. So I hope you still have some patience.
Kees
Hallo Kees,
We are on page 2 already... I also did some testing today, confirming you latest findings :
This program did run the whole afternoon, no problems :
10 REM pin 1 tot 3 analog inputs
20 OPTION USB OFF
30 OPTION VIDEO OFF
40 SETPIN 1,1
50 SETPIN 2,1
60 SETPIN 3,1
70 SETPIN 4,1
130 PIN(0) = 1
140 PAUSE 1000
150 PIN(0) = 0
155 PAUSE 1000
170 SLEEP MINUTE
180 PAUSE 5000
190 GOTO 40
Then I added what I need :
10 REM pin 1 tot 3 analog inputs
20 OPTION USB OFF
30 OPTION VIDEO OFF
40 SETPIN 1,1
50 SETPIN 2,1
60 SETPIN 3,1
70 SETPIN 4,1
80 F$ = "B:"+RIGHT$(DATE$,7)
90 OPEN F$ FOR APPEND AS #1
100 V$ = DATE$
110 PRINT #1,V$,TIME$,MM.SLEEP,PIN(21),PIN(1),PIN(2),PIN(3),PIN(4)
120 CLOSE #1
130 PIN(0) = 1
140 PAUSE 1000
150 PIN(0) = 0
155 PAUSE 1000
170 SLEEP MINUTE
180 PAUSE 5000
190 GOTO 40
and this one does not run long, so indeed, writing on the card does case a issue. I'm writing on drive b and power it on by a USB power supply.
Just to find a quick (and dirty) solution, can I reboot the board from in software, for me it would be fine if I log the data, sleep a minute and reboot. The reboot command seems not well documented or even hidden :-)
Many thanks for your time and information, it does make a difference.
Johnny
"Quick and dirty (operating system)" made Bill Gates very rich, so let us give it a try :-)
Indeed there is no REBOOT command in DMBasic. After the initialisation of the system the system comes in an endless loop. The only exit of this is doing something wrong like PEEK or POKE to an address which is not allowed. This will reboot the system, however in a predefined state (error message with the PEEK or POKE question) and unfortunately it does not start the "AUTORUN.BAS". So the very Q&D method does not work.
However I think there is simple Q&D method which should work, at least it should re-init the SD card in a correct way. You should give your filename another name as "AUTORUN.BAS", e.g "DATALOG.BAS". Now change line 190 RUN "DATALOG.BAS". This will stop the program execution and load and run the same program again. To start the system automatically add "AUTORUN.BAS" with just one line: 10 RUN "DATALOG.BAS".
I have not tested this with the original DMBasic 2.7, but I guess it should work.
Kees
A few more suggestions:
You can add:
21 POKE &HBF88,&H5080,0
22 POKE &HBF88,&H5210,158
These two lines will switch off the USB Power and Interrupts. You will hear the correct disconnection beep on your PC. Now you have to disconnect your terminal. If you include some END condition in your program and you would like to connect again, you need to execute the following statements:
1000 POKE &HBF88,&H5080,9
1010 POKE &HBF88,&H5210,159
1020 OPTION USB ON
Now you can connect to the Duinomite again without resetting.
Concerning the power consumption.
1. As far as I have seen now, it is best to set all IO to digital input before you start the sleep: FOR x=1 to 22:SETPIN x,2:NEXT. As long as the analog circuit is active or outputs are configured they can draw extra current.
2. Olimex seems to have not designed with low power in mind. There is no possibility to switch the Power LED off. In my MEGA it is even connected via a resistor of 330 ohm to the 5 Volt. This means about 10 mA. In the other Duinomites it is 1k, but this still means 3 mA for the power LED. Maybe it is an option to disconnect.
Kees
Hallo Kees,
A short update, the call from one program to a other with the
10 RUN "DATALOG.BAS"
in autorun.bas and at the end of datalog.bas does not make the sleep stable, it still stops after a while, so it did not solve the issue.
Cheers,
Johnny
Hello Johnny,
It is a pity, but like I said it is not a real reboot.
I have noticed it is a quite complex issue. The original implementor of the SLEEP command also tried to wake up from the serial ports and did not succeed in that. I'm still fighting with that and with the wake up from the CANports. I'm also studying what is really done by calling the SLEEP routine. The implementor just called a routine from a standard Microchip library, but my experience with the CAN library is: debug these libraries before you use them; Microchip did not do this for you.
Kees
A short update for further testing.
I checked what happens if the Duinomite does a softreset (like with x=PEEK(0,0)). At the startup it simply checks the PIC32 RESET register and if the bit for "softreset" is set, it sets "autorun=false" in stead of "autorun=true" like in a cold start. Just for testing I changed this to always "autorun=true". Now the autorun file is always executed also when you make a mistake in your program. This is very tricky as you can imagine. That is why you should have an autorun file which gives you the possibility to stop after reboot. I did some small test and up to now did not detect problems.
In www.si-kwadraat.nl/olimex/sl_test/sl_test.zip I have included 3 files. The HEX file with the new image which can be installed by using the standard firmware program of Olimex, a possible autorun file and the program as was intended to run at your site. I know you will have the problem that with the reset also the real time clock is reset, so you have to calculate the new time from the last measurement.
I hope you are willing to test this and I can use the results also for my further developments.
Kees
I don't know if Johnny or anyone else tested the modified code, but I think we are looking in the wrong direction. I still see the problem; after some time the unit does not reboot after the sleep. Actually I believe it is not really coming out of the sleep (although the current goes back to 120 mA). I did some googling and it seems that more Microchip PIC32 users have problems with the sleep option. Probable causes for the problems are always related to the power supply or to spikes on the I/O. I will do further investigations in this direction.
Kees
Hallo Kees,
I was out for some time, I will check your code at the end of this week.
Many thanks for your help,
Johnny
Hihi,
I did download the firmware to the board, autorun.bas and the logging code, and the device is running now for about 4 hours.
Current goes down to just under the 10mA when at sleep.
More tests to be done, but for now, it looks like the restart in the new code does the job, thanks !
Cheers,
Johnny
That is good news. I believe that my last problem was caused by the fact that I wanted to do the test too fast. If you do a reboot before the SPI connection to the SD-card has been stabilized, you probably run into problems. I have another issue here. For a project I needed some extra digital inputs and I wanted to use PIN 7 up to 10 for this purpose. After SDDISABLE this is no problem. If I want to use the SD card again this can be done by SDENABLE. As long as I don't change the configuration of the PINs this works perfectly, but if I changed the PINs to inputs the SD card is not recognised again. If I first do SETPIN 8,8 and SETPIN 10,8 and after that PIN(8)=0 and PIN(10)=0 and after that SDENABLE, it works again. I don't know why, because it seems that this is also done in the SDENABLE command. It has probably something to do with timing. SD card will stay a critical issue at the Duinomites I believe.
Kees
Morning Kees,
I did let the code run overnight and after 395 minutes (= 395 entrys in the log), it did stop logging. At the moment I checked, the unit was not in sleep (checked at the power consumption). A reset did start it again and went into sleep, no idea why it did stop...
Cheers,
Johnny
A few additional suggestions:
1. Take care of a very good supply. I have seen that the Duinomite does not boot with every USB adapter, because it supplies a voltage of over 5 Volts. Best is to use an adapter from 9 to 24 Volt. But as I understood you will use a battery anyway.
2. I found a better way to do a real reset. The built-in watchdog of the PIC32 controller is disabled in the DMBasic. The instruction POKE &HBF80,&H0001,128 will switch it on with a default time of 1 ms. So as soon as the instruction is seen, it will activated. This is not a soft reset as far as I know, but has the same function as pressing the RESET button.
3. To further reduce the current I would suggest to cut one of the connections to the power LED. On the Duinomite it draws about 3 mA of the 5 Volt (3 Volt over 1 kOhm).
Kees
Good morning,
Ok, good news today, my setup did run for 24h, first time since the start on this topic :-)
A summary :
"Sleep" command does cause problems and is not stable. The work around for now is to do download the new firmware Kees made, sleep and then reboot the device, a working way to reboot is :
190 POKE &HBF80,&H0001,128
In short :
autorun.bas :
10 PIN(0)=1
20 PAUSE 2000
30 IF PIN(0)=1 THEN GOTO 60
40 PIN(0)=0
50 RUN "log.bas"
60 REM Here comes evaluation software
log.bas :
10 REM pin 1 tot 3 analog inputs
20 PRINT "starting routing"
30 PIN(0)=1
35 PAUSE 100
40 SETPIN 1,1
50 SETPIN 2,1
60 SETPIN 3,1
70 SETPIN 4,1
80 F$ = "B:"+RIGHT$(DATE$,7)
90 OPEN F$ FOR APPEND AS #1
100 V$ = DATE$
105 NO=NO+1
110 PRINT #1,NO,V$,TIME$,MM.SLEEP,PIN(21),PIN(1),PIN(2),PIN(3),PIN(4)
120 CLOSE #1
125 PIN(0)=0
130 PAUSE 1000
140 POKE &HBF88,&h508,0
150 POKE &HBF88,&H5210,158
170 SLEEP MINUTE
180 PAUSE 1000
185 PRINT "resetting"
190 POKE &HBF80,&H0001,128
It consumes about 80mA when writing, about 9mA when at sleep.
For my project, I still have some open topics :
- I'm still wondering how I could include a correct timestamp, if the duinomite is without power for some time, I may not have this in the log file. A external RTC seems overkill, so it does make since to get the sleep command stable..
- I did take out the resistor for power on red LED, but still it consumes 9mA, a lot more then what is in the manual for this board(30uA, page 5 of the manual, a big difference for battery powered applications),.
Many thanks to Kees for his work on this topic.
You may be best with a simple and good external RTC such as DS3231.
Cheap with battery.
John
Hello and good evening,
would also work with V4.5 or do I need a software modification?
best regards Ron
A few last remarks for the moment from my side:
1. Using the last POKE command will also work with the original firmware. This will directly activate the watchdog reset and this is a hard reset and not a software reset. This means the autorun.bas is executed anyway.
2. I agree with JohnS that such an RTC is the best solution for the clock problem. The only alternative I can think of is reading the Date and Time from a second file at startup. Add the sleep time + the additional delay and set the new DATE$ and TIME$ with the new values for the logfile and the Date/Time file.
3. What has been forgotten in the SLEEP command is switching off all circuits which dissipate quite a lot of power like the analog circuit, the comparators, the interrupts, the communication circuits, etc. before the CPU is going to sleep. This can also cause the instable functionality. On the other hand I believe a stable power supply is also very important.
4. Concerning the 4.5V of RonnS. I presume this would be supplied to the USB power connection pins. I can imagine that it will work. Anyway there are no software modifications needed for that.