sleep mode with single board RIO 9631 embedded evaluation kit

[a-man]

Hi!

Is there any examples available on using a single-board RIO 9631 embedded evaluation kit and the sleep mode? I found the help on how to activate the sleep mode (http://zone.ni.com/reference/en-XX/help/370984R-01/criodevicehelp/enabling_sleep_mode/) and it works in that I can activate the sleep mode and see the current of the board drop. I would however want to do it in every iteration of the main loop to save power.

I'm having a main loop running at a certain interval (currently 250 ms) and an inner VI in it in which the FPGA is waked up, then some IO is done and then it is put back to sleep. (see Main loop: controller.vi and Inner VI: RealTimeController.vi)

The sleep mode and its execution interval is set in a separate loop in the same FPGAIO.vi as all other IO is processed. (see FPGAIO.vi)

I have three parameters, 1) main loop interval 2) sleep loop interval 3) wake up time, with which I set the timing of the loops. All are “wait until next multiple"-waits.

I cannot find a combination of parameter values at which the FPGA enters sleep mode at every iteration of the main loop (I see it from a current measurement which I have attached to the power source of the board) AND the reading of the inputs is not laggy.

Any ideas?

Another question: How long does it take for the sbRIO 9631 to "fall in sleep" vs. "wake up"? Suppose it should not be very long...

Thanks in advance!

-       Axel

[a-man]

Is there anybody out there? An answer would be nice if there is one...

[Andrew_E · Accepted solution]

Hello,

First, can you tell me  a little about your application? Are you using a battery and trying to save power or are you powering from the wall?

There a couple of things to remember. First the onboard DIO  will never go to sleep. So you will not see a draw down with that, which would most likely be pretty minimal. So really we are really only concerned about the AI/AO. Next, each module has a given time span before data is good, so if you put the sbRIO in sleep, turning off power to AI and AO, then your voltage out of AO will go to zero and your data read in by AI will be invalid (currently you are not checking for invalid data on AI, which may be an issue for your program). Also, you need to make sure that your application is fine reading, not necessarily clean, ramp up and ramp down voltage of the AO. Finally, since there is a possibility of a long delay on power up on the c series modules, there is a possibility that your AI/AO is not good for up to a couple of seconds after powering up. You can probably characterize this by graphing how fast your AO comes back up each time the sleep is turned on and off.

The best architecture you can do is to have the AI/AO in a master loop where you turn the sleep off, perform your AI/AO, turn sleep on. However, when you turn the power line back on, your modules will take some time to output "good" data so you may have to wait alot longer than your loop rate (and hence the problem you are most likely seeing).

The sleep enable line was not designed for how you are trying to use it unfortunately. It was designed to enable for a relatively long time and then disable when your system needs to come out of sleep and  perform some action.

[Andrew_E]

Hello again,

So i double checked an it looks like the "data good" state of 9205 will be in the magnitude of around 200 ms and for the 9263 it will be on magnitude of 100-500 ms for the module to fully power up.

[a-man]

Thank you very much for your answers!

So the sleep can actually be used only for loop times of around 1 second or more. My application is a control system for a 1.5 W fuel cell system so it should be possible to use longer sleep times than I have done now. However, the current system is only a prototype and for the moment I'm powering most devices from the wall. Additionally, the power consumption of the sbRIO is way too high for a final application as the fuel cell, which finally shuold provide all power to the system, is low power and the power consumption of all auxiliary devices should be as low as possible. So probably the system will be implemented with another microcontroller + FPGA combination. The information is very useful though since the microcontroller might find use in another application, perhaps with a higher power fuel cell.

Thanks once again for the help!

- Axel