[what is the minimal power consumption rate with wifi?]

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

[UDP sendto producing duplicated packets?]

I used wifi_example1 as a skeleton for Wifi and I modified it to transmit UDP packets.

 

For some reason, I am getting duplicated UDP packets (I discovered this by using Ethereal). What am I doing wrong?

 

I have attached the code I am using.

 

In addition, I also seem to be having an issue that sendto is returning before it has actually transmitted the packet. What do I need to check in order to not call sendto again too soon?

 

Thanks.

 

Replying to myself, the duplicated packets were a bug in my understanding not a bug in the library.

[UDP sendto producing duplicated packets?]

I used wifi_example1 as a skeleton for Wifi and I modified it to transmit UDP packets.

 

For some reason, I am getting duplicated UDP packets (I discovered this by using Ethereal). What am I doing wrong?

 

I have attached the code I am using.

 

In addition, I also seem to be having an issue that sendto is returning before it has actually transmitted the packet. What do I need to check in order to not call sendto again too soon?

 

Thanks.

template.c.txt