Re: [Tinyos-help] CC2420 Vs. CC2420X
Wasif: Regarding setting the backoff values to 1us in the cc2420x stack: this clearly doesn't work, because the code would schedule an alarm 1us in the future, which is simply not possible. By the time the operation of scheduling the alarm completes, that time instant is going to be in the past, and the alarm will fire after the counter overflows and reaches that particular value again. To put it in another way: backoff values under (approximately) 200 microseconds are not valid. To get rid of CSMA logic altogether, you need to remove the collision avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have described in my previous email. Janos On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote: Hi all, I am trying to measure the message delay on Telosb platform and now comparing the CC2420 stack with CC2420X stack. Below are the two Histograms showing the delay spread of Cc2420 and CC2420X stacks respectively. The experiment is perfromed for around 1 hr at the same time using two different frequency channels. For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface and have calculated the delay at the receiver end as delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg) and for CC2420 Stack, I have used TimeSyncAMSend with Milli sec precision and have calculated the delay as : delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg) in case of CC2420 stack CCA is disabled and for CC2420X stack, I have changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such a way that all types of backoff values ( Initial, minimum and congestion) are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct way to disable it). Now, what I observe is a bit interesting since the two histograms show a completely different delay behaviors, ie. with the Cc2420X stack the delay ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to 150ms. Is this also what any of you experience or is there something I am missing here? here are the histograms: http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420 Vs. CC2420X
Thanks Janos, now these stacks seem to have some relevance, see the histograms below: http://s7.postimage.org/3oh7d6gln/cc2420.png http://s9.postimage.org/qswev86xr/cc2420x.png Miklos, Thanks for the reply but I was referring to timestamping accuracy in Ucmini, so the question was does ucmini needs a separate timestamping stack like cc2420x or does the current implementation of it does not require that since timestamping already works fine on it. Regards, Wasif! On Wed, Jan 9, 2013 at 10:45 PM, Janos Sallai janos.sal...@vanderbilt.eduwrote: Hi Wasif, The cc2420x stack should be straightforward to set up with the z1. Just follow how it's set up on the telos. One thing it needs is a fast SPI bit rate. My suspicion is that the SPI on the z1 is configured with 256 or 512 kbps bit rate, though I can't confirm this. You might want to take a look at the directory tos\platforms\telosa\chips\cc2420x\tmicro to see how I have reconfigured the telos clock subsistem to speed up the SPI. Most probably, the same has to be done with the z1. Since it has a slightly different MCU than the telos, the code in that directory will probably have to be altered a bit to work on the z1. Janos On Wed, Jan 9, 2013 at 2:28 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Wasif! Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is fully supported in tinyos, just type make ucmini. Miklos On Wed, Jan 9, 2013 at 11:55 AM, wasif masood rwmas...@gmail.com wrote: Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side. Another Questions, make z1 CC2420x doesn't work. Do u ever have any experience with that! and also neither for UCMINI. Regards, Wasif! On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Wasif: Regarding setting the backoff values to 1us in the cc2420x stack: this clearly doesn't work, because the code would schedule an alarm 1us in the future, which is simply not possible. By the time the operation of scheduling the alarm completes, that time instant is going to be in the past, and the alarm will fire after the counter overflows and reaches that particular value again. To put it in another way: backoff values under (approximately) 200 microseconds are not valid. To get rid of CSMA logic altogether, you need to remove the collision avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have described in my previous email. Janos On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote: Hi all, I am trying to measure the message delay on Telosb platform and now comparing the CC2420 stack with CC2420X stack. Below are the two Histograms showing the delay spread of Cc2420 and CC2420X stacks respectively. The experiment is perfromed for around 1 hr at the same time using two different frequency channels. For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface and have calculated the delay at the receiver end as delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg) and for CC2420 Stack, I have used TimeSyncAMSend with Milli sec precision and have calculated the delay as : delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg) in case of CC2420 stack CCA is disabled and for CC2420X stack, I have changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such a way that all types of backoff values ( Initial, minimum and congestion) are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct way to disable it). Now, what I observe is a bit interesting since the two histograms show a completely different delay behaviors, ie. with the Cc2420X stack the delay ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to 150ms. Is this also what any of you experience or is there something I am missing here? here are the histograms: http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420 Vs. CC2420X
Hi Wasif, On Thu, Jan 10, 2013 at 10:05 AM, wasif masood rwmas...@gmail.com wrote: Thanks Janos, now these stacks seem to have some relevance, see the histograms below: http://s7.postimage.org/3oh7d6gln/cc2420.png http://s9.postimage.org/qswev86xr/cc2420x.png Miklos, Thanks for the reply but I was referring to timestamping accuracy in Ucmini, so the question was does ucmini needs a separate timestamping stack like cc2420x or does the current implementation of it does not require that since timestamping already works fine on it. The atmega128rfa1 (the MCU in the ucmini) has a built in time capture register which is based on a 62.5 KHz 32-bit low power timer that is always running. No extra configuration is necessary, everything works by default. Miklos Regards, Wasif! On Wed, Jan 9, 2013 at 10:45 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Hi Wasif, The cc2420x stack should be straightforward to set up with the z1. Just follow how it's set up on the telos. One thing it needs is a fast SPI bit rate. My suspicion is that the SPI on the z1 is configured with 256 or 512 kbps bit rate, though I can't confirm this. You might want to take a look at the directory tos\platforms\telosa\chips\cc2420x\tmicro to see how I have reconfigured the telos clock subsistem to speed up the SPI. Most probably, the same has to be done with the z1. Since it has a slightly different MCU than the telos, the code in that directory will probably have to be altered a bit to work on the z1. Janos On Wed, Jan 9, 2013 at 2:28 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Wasif! Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is fully supported in tinyos, just type make ucmini. Miklos On Wed, Jan 9, 2013 at 11:55 AM, wasif masood rwmas...@gmail.com wrote: Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side. Another Questions, make z1 CC2420x doesn't work. Do u ever have any experience with that! and also neither for UCMINI. Regards, Wasif! On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Wasif: Regarding setting the backoff values to 1us in the cc2420x stack: this clearly doesn't work, because the code would schedule an alarm 1us in the future, which is simply not possible. By the time the operation of scheduling the alarm completes, that time instant is going to be in the past, and the alarm will fire after the counter overflows and reaches that particular value again. To put it in another way: backoff values under (approximately) 200 microseconds are not valid. To get rid of CSMA logic altogether, you need to remove the collision avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have described in my previous email. Janos On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote: Hi all, I am trying to measure the message delay on Telosb platform and now comparing the CC2420 stack with CC2420X stack. Below are the two Histograms showing the delay spread of Cc2420 and CC2420X stacks respectively. The experiment is perfromed for around 1 hr at the same time using two different frequency channels. For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface and have calculated the delay at the receiver end as delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg) and for CC2420 Stack, I have used TimeSyncAMSend with Milli sec precision and have calculated the delay as : delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg) in case of CC2420 stack CCA is disabled and for CC2420X stack, I have changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such a way that all types of backoff values ( Initial, minimum and congestion) are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct way to disable it). Now, what I observe is a bit interesting since the two histograms show a completely different delay behaviors, ie. with the Cc2420X stack the delay ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to 150ms. Is this also what any of you experience or is there something I am missing here? here are the histograms: http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood
Re: [Tinyos-help] CC2420 Vs. CC2420X
thanks Miklos, that is convenient! On Thu, Jan 10, 2013 at 10:23 AM, Miklos Maroti mmar...@math.u-szeged.huwrote: Hi Wasif, On Thu, Jan 10, 2013 at 10:05 AM, wasif masood rwmas...@gmail.com wrote: Thanks Janos, now these stacks seem to have some relevance, see the histograms below: http://s7.postimage.org/3oh7d6gln/cc2420.png http://s9.postimage.org/qswev86xr/cc2420x.png Miklos, Thanks for the reply but I was referring to timestamping accuracy in Ucmini, so the question was does ucmini needs a separate timestamping stack like cc2420x or does the current implementation of it does not require that since timestamping already works fine on it. The atmega128rfa1 (the MCU in the ucmini) has a built in time capture register which is based on a 62.5 KHz 32-bit low power timer that is always running. No extra configuration is necessary, everything works by default. Miklos Regards, Wasif! On Wed, Jan 9, 2013 at 10:45 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Hi Wasif, The cc2420x stack should be straightforward to set up with the z1. Just follow how it's set up on the telos. One thing it needs is a fast SPI bit rate. My suspicion is that the SPI on the z1 is configured with 256 or 512 kbps bit rate, though I can't confirm this. You might want to take a look at the directory tos\platforms\telosa\chips\cc2420x\tmicro to see how I have reconfigured the telos clock subsistem to speed up the SPI. Most probably, the same has to be done with the z1. Since it has a slightly different MCU than the telos, the code in that directory will probably have to be altered a bit to work on the z1. Janos On Wed, Jan 9, 2013 at 2:28 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Wasif! Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is fully supported in tinyos, just type make ucmini. Miklos On Wed, Jan 9, 2013 at 11:55 AM, wasif masood rwmas...@gmail.com wrote: Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side. Another Questions, make z1 CC2420x doesn't work. Do u ever have any experience with that! and also neither for UCMINI. Regards, Wasif! On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Wasif: Regarding setting the backoff values to 1us in the cc2420x stack: this clearly doesn't work, because the code would schedule an alarm 1us in the future, which is simply not possible. By the time the operation of scheduling the alarm completes, that time instant is going to be in the past, and the alarm will fire after the counter overflows and reaches that particular value again. To put it in another way: backoff values under (approximately) 200 microseconds are not valid. To get rid of CSMA logic altogether, you need to remove the collision avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have described in my previous email. Janos On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote: Hi all, I am trying to measure the message delay on Telosb platform and now comparing the CC2420 stack with CC2420X stack. Below are the two Histograms showing the delay spread of Cc2420 and CC2420X stacks respectively. The experiment is perfromed for around 1 hr at the same time using two different frequency channels. For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface and have calculated the delay at the receiver end as delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg) and for CC2420 Stack, I have used TimeSyncAMSend with Milli sec precision and have calculated the delay as : delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg) in case of CC2420 stack CCA is disabled and for CC2420X stack, I have changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such a way that all types of backoff values ( Initial, minimum and congestion) are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct way to disable it). Now, what I observe is a bit interesting since the two histograms show a completely different delay behaviors, ie. with the Cc2420X stack the delay ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to 150ms. Is this also what any of you experience or is there something I am missing here? here are the histograms: http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu
Re: [Tinyos-help] CC2420 Vs. CC2420X
Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side. Another Questions, make z1 CC2420x doesn't work. Do u ever have any experience with that! and also neither for UCMINI. Regards, Wasif! On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai janos.sal...@vanderbilt.eduwrote: Wasif: Regarding setting the backoff values to 1us in the cc2420x stack: this clearly doesn't work, because the code would schedule an alarm 1us in the future, which is simply not possible. By the time the operation of scheduling the alarm completes, that time instant is going to be in the past, and the alarm will fire after the counter overflows and reaches that particular value again. To put it in another way: backoff values under (approximately) 200 microseconds are not valid. To get rid of CSMA logic altogether, you need to remove the collision avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have described in my previous email. Janos On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote: Hi all, I am trying to measure the message delay on Telosb platform and now comparing the CC2420 stack with CC2420X stack. Below are the two Histograms showing the delay spread of Cc2420 and CC2420X stacks respectively. The experiment is perfromed for around 1 hr at the same time using two different frequency channels. For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface and have calculated the delay at the receiver end as delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg) and for CC2420 Stack, I have used TimeSyncAMSend with Milli sec precision and have calculated the delay as : delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg) in case of CC2420 stack CCA is disabled and for CC2420X stack, I have changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such a way that all types of backoff values ( Initial, minimum and congestion) are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct way to disable it). Now, what I observe is a bit interesting since the two histograms show a completely different delay behaviors, ie. with the Cc2420X stack the delay ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to 150ms. Is this also what any of you experience or is there something I am missing here? here are the histograms: http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420 Vs. CC2420X
Hi Wasif! Ucmini uses the atmega128rfa1 chip (and not the cc2420) and it is fully supported in tinyos, just type make ucmini. Miklos On Wed, Jan 9, 2013 at 11:55 AM, wasif masood rwmas...@gmail.com wrote: Thanks alot Janos! it seems to work now, it was a clumsy mistake on my side. Another Questions, make z1 CC2420x doesn't work. Do u ever have any experience with that! and also neither for UCMINI. Regards, Wasif! On Wed, Jan 9, 2013 at 4:25 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Wasif: Regarding setting the backoff values to 1us in the cc2420x stack: this clearly doesn't work, because the code would schedule an alarm 1us in the future, which is simply not possible. By the time the operation of scheduling the alarm completes, that time instant is going to be in the past, and the alarm will fire after the counter overflows and reaches that particular value again. To put it in another way: backoff values under (approximately) 200 microseconds are not valid. To get rid of CSMA logic altogether, you need to remove the collision avoidance layer altogether and rewire the stack (CC2420XRadioC.nc) as I have described in my previous email. Janos On Wed, Jan 9, 2013 at 5:31 AM, wasif masood rwmas...@gmail.com wrote: Hi all, I am trying to measure the message delay on Telosb platform and now comparing the CC2420 stack with CC2420X stack. Below are the two Histograms showing the delay spread of Cc2420 and CC2420X stacks respectively. The experiment is perfromed for around 1 hr at the same time using two different frequency channels. For CC2420X I have used the TimeSyncAMSendTMicro,uint32_t interface and have calculated the delay at the receiver end as delay = call LocalTimeMicro.get() - call TimeSyncPacket.eventTime(msg) and for CC2420 Stack, I have used TimeSyncAMSend with Milli sec precision and have calculated the delay as : delay = call LocalTimeMilli.get() - call TimeSyncPacket.eventTime(msg) in case of CC2420 stack CCA is disabled and for CC2420X stack, I have changed RandomCollisionConfig implementatoin in CC2420XRadioP module in such a way that all types of backoff values ( Initial, minimum and congestion) are now just RADIO_ALARM_MICROSEC value (because I couldn't find a direct way to disable it). Now, what I observe is a bit interesting since the two histograms show a completely different delay behaviors, ie. with the Cc2420X stack the delay ranges between 1 to 13ms, but with CC2420X stack the delay goes from 70ms to 150ms. Is this also what any of you experience or is there something I am missing here? here are the histograms: http://s14.postimage.org/55bs7ni0x/Telosb_CC2420x.png http://s8.postimage.org/8paur8s6d/Telosb_CC2420.png Regards, Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
