what is the minimal power consumption rate with wifi?

[dmc]

Hello,

 

I am a senior in Computer Engineering. Our year long senior design project is to design a paging system(those things people wore on their belts before cell phones got small). What they probably expect us to do is design a simple custom PCB with some cheap radio modem IC. What I'd like to do however, is to implement a software only solution using NDSL's as the pagers and wifi as the backbone. This barely fits into our prototype budget, and the prof seems willing to allow this so far.

 

Asside from the general complexity of NDS homebrew development (my supercard lite and passkey are allegedly in the mail), the biggest question I have is whether or not the NDSL can accomplish this, with a single charge battery life cycle of >=48 hours (our requirements).

 

From all the research I have done, the answer seems to be a definite maybe. Any ideas or relevent facts anyone would care to share with me on the subject would be greatly appreciated.

 

For instance, my thinking has been, regardless of hardware, that I need to do some polling on the signal (poll interval of 15 seconds, means pages would be received generally within 15 seconds of dispatch). Clearly the main issue is how much of the hardware can be put in sleep/standby/low-power mode, and for what percentage of the time. I found one article on dsdev.org describing standby mode, and how it would wake up from standby mode if a message was received in pictochat(or maybe it was an online game).

 

Clearly this pager seems like it could be implemented while almost never using the touchscreen, lcd screens, or audio. I.e. for 95+% of the time, the NDS would be closed, and every polling interval time, would wake up enough hardware to check the WiFi network for any new messages, then go back to sleep.

 

Clear Question #1: What is the least amount of time required to check for the simplest data on the network. I.e. if it takes 10 seconds to do all the 802.11 handshaking, clearly you don't gain that much by putting it to sleep for 5 out of every 15 seconds. But if it only takes 0.25 seconds to wake up, and check for a message, and then go back to sleep, then for 14.75/15 seconds, you can be in sleep mode, and perhaps achieve >48hours of application run time per battery charge.

 

Clear Question #2: How many parts of hardware will I be able to put in sleep mode during the two phases (phase1 - actively checking network for data, phase2 - sleeping before repeating phase1)? And does it seem like this will yield >48hr runtime between charges?

 

Obviously I also want to be able to control the LEDs, and speaker, and supercardlite-RUMBLE while the lid is closed. I'm guessing that is fairly straightforward (as straightforward as anything is).

 

So, does this seem like a sane road to go down? Obviously the major fun is in the extra features and further NDS development after the minimal requirements have been met.

 

Thanks,

 

-dmc

[BSD User]

Asside from the general complexity of NDS homebrew development (my supercard lite and passkey are allegedly in the mail), the biggest question I have is whether or not the NDSL can accomplish this, with a single charge battery life cycle of >=48 hours (our requirements).

 

I don't think anyone can give you a definitive answer. However, I would look at Nintendogs to see. When the DS is closed and another DS with Nintendogs comes within range, the DS will "bark". This means that the two DS machines are emitting and receiving wireless signals even when nominally "asleep". Someone might have made a comment about battery life for Nintendogs.

 

Clearly this pager seems like it could be implemented while almost never using the touchscreen, lcd screens, or audio. I.e. for 95+% of the time, the NDS would be closed, and every polling interval time, would wake up enough hardware to check the WiFi network for any new messages, then go back to sleep.

 

The big advantage would be to keep the screen off. If you really got clever, you could almost completely shut down the ARM9 and do everything on the ARM7.

 

Clear Question #1: What is the least amount of time required to check for the simplest data on the network. I.e. if it takes 10 seconds to do all the 802.11 handshaking, clearly you don't gain that much by putting it to sleep for 5 out of every 15 seconds. But if it only takes 0.25 seconds to wake up, and check for a message, and then go back to sleep, then for 14.75/15 seconds, you can be in sleep mode, and perhaps achieve >48hours of application run time per battery charge.

 

Well, this depends. 802.11b has quite a bit of handshaking ... However ...

 

The DS hardware is extremely low-level in that you can put 802.11 packets right in the air. You don't have to adhere to the full 802.11 standard ... ie. you can put data directly into beacon packets, you don't need to associate with an AP, you can send before you're supposed to, etc. Given that your other solution is to use a cheap radio, you would be doing the same thing.

 

Take a long look at the ARM7 code in DSWifi to see how you can mangle the packets you want.

 

So, does this seem like a sane road to go down? Obviously the major fun is in the extra features and further NDS development after the minimal requirements have been met.

 

Depends. How much time do you have and how good are your development tools for the other solution? The lack of a decent emulator for the DS hurts for embedded development. If your other solution can be emulated, it's going to save you quite a lot of time.

 

Good luck,

-a