* If you're time-synchronized, then the receiver can turn on for a couple of milliseconds and cost you maybe 50 uC if there's no packet, and 100uC if there is one. If you do this once a second, that's 50uA to get 1/2 second average latency when idle, or 100uA to receive one packet per second. That's TSMP (time synchronized mesh protocol). * If you don't want to time synchronize, you can do preamble sampling. You still turn your receiver on regularly, and listen to hear if anyone is transmitting a long preamble. If they are, you stay awake until the packet shows up. This is LPL (low power listening) if you're a tinyOS person. You burn less charge on the listens - maybe only 20uC if there's nothing to hear - but you probably want to do them more often. If you sample once per second, then maybe you only burn 20uA to get the same 1/2 second latency, but...now the transmitter of a packet has to send a 1 second long preamble before each packet so that you stay awake, meaning a TX now costs 20,000uC, not 100uC. The receiver on average is going to have to listen to half of the preamble, which is going to cost 10,000uC if you only sample once a second. So you probably sample a lot more often, and burn a lot more power on idle listening. Not very efficient, but hey, at least it's easy.
This is a very naive approach, and Kris, we've talked about this. Many protocols can detect when others are sampling the channel (I believe you call this "time synchronization", although really it can be done with LPL) and detect when to receive a packet based will be received on this information. If you can setup a purely peer-to-peer network (please take out that horrible server) and give us an ability to interact with ANY sensor network at any point, a ton of our customers would love to see that functionality. Time synchronization is not the answer, NOR is low power listening. Both are TOOLS, which is what many people forget. We need these tools to enable a networking system that CUSTOMERS (yes, I said it), customers are looking to use. Most of our customers couldn't care less whether a TSMP (WTF is that?) or an LPL (WTF did you say?) is used, they care about how to get alerts to their personnel (an application). This is what we should be focused on, not whose random networking junk is better than the other random startup's networking junk. -Joe,
* If you're lucky enough to have a powered infrastructure, then use WiFi. Hmm. Try again: if you're lucky enough to have a powered infrastructure, and for some reason are still interested in using 802.15.4, then transmit whenever you want, and listen immediately after your transmitions to see if the local powered router has anything to say to you in return. ksjp -- Prof. EECS, UC Berkeley Founder & CTO, Dust Networks ________________________________ From: Ian Chakeres [mailto:[EMAIL PROTECTED] Sent: Wed 5/9/2007 6:34 PM To: 6lowpan; [EMAIL PROTECTED] Cc: Charles E. Perkins (work) Subject: [6lowpan] Re: 6lowpan devices constraints Also, I'm adding RSN. It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
