May 28, 2024, 01:15:31 PM

Duinomite to low power mode

Started by johnny, January 30, 2016, 07:44:56 PM

Previous topic - Next topic


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
80 SETPIN 20,8
100 SETPIN 21,1
120 V$ = DATE$
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
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,



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 ....



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?



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.



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)
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
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.



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.



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


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.


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,


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.



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,


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.



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.



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 ?