[Tinyos-help] Photo sensor
Hi
I wanted the sensor to send me the light value it
detects only if its value is above a particular
threshold. I used XSensorMTS300 and xlisten, TOSBase.
I modified th nesC code in TestSensorM.nc
msg_uart-data[PHOTO] = data 0xff;
msg_uart-data[PHOTO+1] = data 8;
to if(dataALPHA){msg_uart-data[PHOTO] = data
0xff;}
else{msg_uart-data[PHOTO]=0 0xff;}
msg_uart-data[PHOTO+1] = data 8;
I expect the output to be around 2345ADC which is the
normal light in the room. and when i cover it to
become 0 if my threshold is less than 2345ADC.
But I get light= or 0100 or 0200 or 0300
depending on the amount of light the sensor is exposed
to.
my guess is its doing some kind of averaging. If so
where is the code where the averaging is performed?
another guess is its related to the temp/photo Pin
being shared.
Can someone please tell me what is wrong, any help
would be highly appreciated.
Thanks in advance.
SS.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: turning radio off
you can look at CC2420Control interface, the VREFOff method roberto ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: ack
thank you for your help, I will try it next week! roberto ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] (no subject)
Spam detection software, running on the system mail.Millennium.Berkeley.EDU, has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dear Sirs, I'm a new user of tinyos, i've to develop an application able to read a botton connected in 51-pin interface, but i'm having a serious difficult to that, because a i don't know how to read a pin. I've been reading the source code of many application contained in it, but until now i still not to understand how they read a pin connected in 51 pin interface.. [...] Content analysis details: (5.3 points, 5.0 required) pts rule name description -- -- 0.8 DEAR_SOMETHING BODY: Contains 'Dear (something)' 0.1 HTML_30_40 BODY: Message is 30% to 40% HTML 0.0 HTML_MESSAGE BODY: HTML included in message 1.2 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.4 DNS_FROM_RFC_ABUSE RBL: Envelope sender in abuse.rfc-ignorant.org 1.4 DNS_FROM_RFC_POST RBL: Envelope sender in postmaster.rfc-ignorant.org 1.6 MISSING_SUBJECTMissing Subject: header 0.0 MSGID_FROM_MTA_HEADER Message-Id was added by a relay The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ---BeginMessage--- Dear Sirs, I'm a new user of tinyos, i've to develop an application able to read a botton connected in 51-pin interface, but i'm having a serious difficult to that, because a i don't know how to read a pin. I've been reading the source code of many application contained in it, but until now i still not to understand how they read a pin connected in 51 pin interface.. Thanks Gonga, Antonio Oliveira Department of Electrical Engineering and Computers(LEEC) HomePage: HTTP://mega.ist.utl.pt/~aogo ---End Message--- ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 51-pin Reading
Dear Sirs, I'm a new user of tinyos, i've to develop an application able to read a botton connected in 51-pin interface, but i'm having a serious difficult to that, because a i don't know how to read a pin. I've been reading the source code of many application contained in it, but until now i still not to understand how they read a pin connected in 51 pin interface.. Thanks Gonga, Antonio Oliveira Department of Electrical Engineering and Computers(LEEC) HomePage: HTTP://mega.ist.utl.pt/~aogo ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Sending Commands to Mica2 Motes From a PC
Hello All, Please help! The problem I have is in sending commands to motes from a PC. These were the steps I took: 1. programmed three mica2 motes with Surge_Reliable and designated one of them as the base node (ID of 0). 2. started serial forwarder 3. ran the java program, BcastInject with parameter: led_on BcastInject displayed a message that it was sending the payload and the payload itself was also displayed. But the problem is that the motes are not responding to the led_on command. I have poked into almost all the codes that make up Surge_Reliable, but still dont know why the motes are not responding. I placed calls to led in strategic places in the code just to find out which parts of Surge_Reliable are being executed. However, it looks like the base node is not picking up the message from UART through AMPromiscuous. Im at my wits end after sleepless nights on this problem. I need all the help I can get!! Once again, the task I want to perform is: SEND COMMANDS TO MICA2 MOTES FROM A PC. Thanks! Adesola ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Rationale for 29 bytes payload
Hi Matt, Thanks for your response. Yes, the number of bytes transmitted over radio is simply the length parameter passed to SendMsg.send( ) and not fixed 29 bytes. However, if we always have packets with payload larger than 29 bytes to send, it is necessary to increase the payload size. Regards, Vinai. Matt Thompson wrote: I know with the CC2420 radio, the payload size you select does not affect how many bytes are actually transmitted over RF. I'm not sure about the CC1000 though. I use a payload size of 90, but if I send 4 bytes of payload, only MSG_HEADER_SIZE + MSG_FOOTER_SIZE (FCF) + payload len bytes are transmitted. Cheers, Matt Vinai Sundaram wrote: Hi David, Thank you for your response and the graphs attached. Can you explain the experimental setup used to obtain the results? Specifically, is this the throughput seen at the application layer ( packets that passed CRC Check)? How many motes were used in the experiment and were they competing for the radio? Regards, Vinai. David Moss wrote: Hi Vinai, I'm interested in this topic as well, and I have no answer as to why 29 bytes was chosen, but I've found that the optimal payload size depends on what type of environment your network exists within. With any radio, if you increase the available data length you're effectively decreasing the packet header:data ratio. By increasing the data length as much as possible, you're going to increase your data throughput to its maximum - in ideal cases. This is because it takes less header information per data information to transmit, and because on some radios (CC1000) the radio kicks back and forth between Tx-Rx-Tx between every packet which takes an extra 512 uS per back-to-back packet. So by decreasing the number of transmitted packets while still getting the same amount of data through, you're obviously going to increase throughput. However, if your network is in a noisy environment, then there's more chance for the packet to get corrupted during transmission. In this case, it will take longer to recover that packet because of its length - instead of losing only a little bit of data, you're losing a lot of data. And this is what I think your question is about - what's the nominal packet length that minimizes the effects of noise while maximizing throughput? It's a design problem. I'm sure this can be simulated with some kind of packet success rate probability for various environments, but it may be difficult to port that over to the real world because the packet success rate in your network environment may change over time, even by the minute. The best answer I can give you is, increase your TOS_Msg payload length as much as you're comfortable with while leaving enough free RAM on the mote to execute the app, and run it in the environment you plan to deploy in. If it's indoors with tight spacing, max out the payload. If it's outdoors on the ground with wider spacing, might as well keep the payload size pretty modest. The ultimate solution would involve some kind of back-end architecture that provides the ability to recommend how much data the payload of the current packet should be loaded with to maximize throughput based on an RSSI or LQI or something, and also provide the ability to increase/decrease the transmit power automatically to save battery on motes that are sitting near each other in a noiseless environment. I've attached several spreadsheets showing the packet throughput for mica- mote types with varying payload sizes. Noise was not a factor in any of these tests. -david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vinai Sundaram Sent: Friday, April 21, 2006 1:39 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] Rationale for 29 bytes payload Hi , I need to send more than 29 bytes for the application I am working on. However, I do not want to increase the payload size so much that it will reduce the throughput of the network. Is 29 bytes found to give close to optimal throughput? Are there any empirical/analytical studies that suggest a payload size range that would give near-optimal throughput? I didn't come across the reason for 29 bytes in any of the documents. Thank you for your help, Vinai. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Rationale for 29 bytes payload
Hi Vinai, My guess of the default max payload size is to reduce RAM overhead, since each TOS_Msg structure will use more RAM when the max payload size is increased. I can't see that using a larger payload size would adversely affect performance. There would be more overhead fragmenting larger packets into 29 byte payloads, due to the header overhead, not to mention extra CPU cycles and complexity of fragmentation and reassembly. Cheers, Matt Vinai Sundaram wrote: Hi Matt, Thanks for your response. Yes, the number of bytes transmitted over radio is simply the length parameter passed to SendMsg.send( ) and not fixed 29 bytes. However, if we always have packets with payload larger than 29 bytes to send, it is necessary to increase the payload size. Regards, Vinai. Matt Thompson wrote: I know with the CC2420 radio, the payload size you select does not affect how many bytes are actually transmitted over RF. I'm not sure about the CC1000 though. I use a payload size of 90, but if I send 4 bytes of payload, only MSG_HEADER_SIZE + MSG_FOOTER_SIZE (FCF) + payload len bytes are transmitted. Cheers, Matt Vinai Sundaram wrote: Hi David, Thank you for your response and the graphs attached. Can you explain the experimental setup used to obtain the results? Specifically, is this the throughput seen at the application layer ( packets that passed CRC Check)? How many motes were used in the experiment and were they competing for the radio? Regards, Vinai. David Moss wrote: Hi Vinai, I'm interested in this topic as well, and I have no answer as to why 29 bytes was chosen, but I've found that the optimal payload size depends on what type of environment your network exists within. With any radio, if you increase the available data length you're effectively decreasing the packet header:data ratio. By increasing the data length as much as possible, you're going to increase your data throughput to its maximum - in ideal cases. This is because it takes less header information per data information to transmit, and because on some radios (CC1000) the radio kicks back and forth between Tx-Rx-Tx between every packet which takes an extra 512 uS per back-to-back packet. So by decreasing the number of transmitted packets while still getting the same amount of data through, you're obviously going to increase throughput. However, if your network is in a noisy environment, then there's more chance for the packet to get corrupted during transmission. In this case, it will take longer to recover that packet because of its length - instead of losing only a little bit of data, you're losing a lot of data. And this is what I think your question is about - what's the nominal packet length that minimizes the effects of noise while maximizing throughput? It's a design problem. I'm sure this can be simulated with some kind of packet success rate probability for various environments, but it may be difficult to port that over to the real world because the packet success rate in your network environment may change over time, even by the minute. The best answer I can give you is, increase your TOS_Msg payload length as much as you're comfortable with while leaving enough free RAM on the mote to execute the app, and run it in the environment you plan to deploy in. If it's indoors with tight spacing, max out the payload. If it's outdoors on the ground with wider spacing, might as well keep the payload size pretty modest. The ultimate solution would involve some kind of back-end architecture that provides the ability to recommend how much data the payload of the current packet should be loaded with to maximize throughput based on an RSSI or LQI or something, and also provide the ability to increase/decrease the transmit power automatically to save battery on motes that are sitting near each other in a noiseless environment. I've attached several spreadsheets showing the packet throughput for mica- mote types with varying payload sizes. Noise was not a factor in any of these tests. -david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vinai Sundaram Sent: Friday, April 21, 2006 1:39 AM To: tinyos-help@Millennium.Berkeley.EDU Subject: [Tinyos-help] Rationale for 29 bytes payload Hi , I need to send more than 29 bytes for the application I am working on. However, I do not want to increase the payload size so much that it will reduce the throughput of the network. Is 29 bytes found to give close to optimal throughput? Are there any empirical/analytical studies that suggest a payload size range that would give near-optimal throughput? I didn't come across the reason for 29 bytes in any of the documents. Thank you for your help, Vinai. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU
[Tinyos-help] Getting system time and clock ticks in tinyos
Hi All!Can anyone please tell how can I get the system time and count of clock ticks in my tinyos program.Thanks,Manik GuptaMs.Manik GuptaGPON GroupCDOT Delhi Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
