Re: [Tinyos-help] How to know how much energy the CC2420 is using

[Pablo Marcos]

Thank you very much Manjunath,

I'll have a look and try to replicate that in TinyOS 2 within the cc2420_tkn
driver.

Regards,
  Pablo

2010/11/22 Manjunath Doddavenkatappa 

>
> It is possible to measure the time that cc2420 consumes in different
> states. This is previsouly done in Tinyos-1.x for mica2 and micaZ nodes in
> the implementation of SMAC and SCP MAC protocols. You can download the code
> from the link http://www.isi.edu/ilense/software/scpmac/.
>
> The file that contains the related code is platform/micaz/PhyRadioM.nc,
> This file implements the physical layer that in turn uses CC2420 components.
>
> The idea is simple, there is a routine called updateEnergy() in the file
> which is called every time before you change the radio to a new state. On
> being invoked, the routine updates the time spent in the last state. This
> way it keeps track of time that radio spends in every state.
>
> BTW, I am not sure how easy to replicate this in the latest versions, you
> must be aware of all the places where a change in the radio state is
> invoked. So that you can call updateEnergy() before the change.
>
> Regards,
> Manjunath D
>
>
> 
>
> ***
>
>
> On Mon, 22 Nov 2010, Pablo Marcos wrote:
>
>  Hi all,
>>
>> It's been almost a week and nobody replied. Someone knows anything about
>> this?
>>
>> Thank you very much.
>>
>> Regards,
>>  Pablo
>>
>> 2010/11/16 Pablo Marcos Oltra 
>>
>>  Hi all,
>>>
>>> I would like to know how much energy my node is consuming. In order to do
>>> that, I was planning on measuring how much time the CC2420 is in each
>>> mode
>>> (sleep, idle, tx or rx) and know how much energy is using by knowing the
>>> time it is in each mode and the data from its datasheet.
>>>
>>> Is that even possible? I mean, where could I collect that data? I imagine
>>> from the driver in $TOSROOT/chips/cc2420, but I have been reading files
>>> for
>>> a while and I have not been able to find something useful so that I could
>>> get the time from higher layers.
>>>
>>> Any ideas are very welcome. Thanks in advance.
>>>
>>> Regards,
>>>  Pablo
>>>
>>>
>>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] 802.15.4

[Jan Hauer]

On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
 wrote:
> Hi,
> About the TKN154_DEBUG mode, I couldn't get the coordinator compiled
> correctly because of the lack of memory in some tests. I someone faces the
> same problem, should try the -Os option to optimize the code and add as well
> these few lines to disable in the coordinator some functionalities:
> CFLAGS += -I$(shell pwd)/.. \
> -DIEEE154_SCAN_DISABLED \
> -DIEEE154_BEACON_SYNC_DISABLED \
> -DIEEE154_PROMISCUOUS_MODE_DISABLED \
> This way, there is no error compiling in debug mode. Anyway, does anyone
> know how to print using the dbg_serial the TKN has implemented without
> having the default printfs the TKN is showing?

When TKN154_DEBUG is defined you can also use printf("...") to output
your debug info over serial, but keep in mind that you should be in
sync context (in async command/event handlers you can use
tkn154_dbg_serial(), see tos/lib/mac/tkn154/TKN154_MAC.h line 289). If
you only want your own debug messages, then don't define TKN154_DEBUG,
instead use printf library as described in the tutorial
(http://docs.tinyos.net/index.php/The_TinyOS_printf_Library). To
disable / remove all your debug printf-statements later you can do
something like this:

#define printf(...)

> And what about how to know
> how much energy the CC2420 is consuming? It has to be some way to measure
> how much time the radio is in each mode, and using the datasheet, know how
> much energ is consuming.
> Thanks in advance.
> Regards,
>   Pablo
> 2010/11/19 Aitor Hernandez 
>>
>> Hi,
>> I've tried your app, and it is working with 6 motes + coordinator during
>> ~15min. I don't understand which could be the problem in your case. You
>> could try to change the mote that plays the coordinator role. If your motes
>> are old, it could be a problem.
>> A temporaly solution, coudl be start the MLME_SCAN (startApp();) again
>> after the MLME_SYNC_LOSS but it is not a good idea, because then you won't
>> see this kind of problems.
>> I want to remark what you said about the printf and debug. The printf
>> introduces a lot of delay, around 9x{backoff period}, but if is possible to
>> use TKN154_4, the dbg_serial takes around one backoff period (20 symbols).
>> Hence, it is really important to disable them if they are not completely
>> necessary. These values are approximations :P
>> Best regards,
>> Aitor
>>
>> On 18 November 2010 22:48, Pablo Marcos Oltra
>>  wrote:
>>>
>>> Hi,
>>> Thank you very much for your response Aitor. I had two motes running for
>>> 3 days with BO=14 and I had no problems of sync using the TestSync
>>> application. Not even one beacon was missed. This was the first test I ran
>>> to check if I was about to have clock drift problems in later experiments.
>>> I'm currently using channels 19 and 20 because in my building there are just
>>> a few spare channels to use (20  are mainly being used right now). Besides,
>>> I always set up BO and SO < 7, using usually 5, but not even that way works
>>> properly.
>>> Anyway, I don't really know if it has something to do with using timers,
>>> but I have noticed that the losing of the sync is kind of periodically. I
>>> have noticed today as well that both devices lose sync even if they don't
>>> even start at the same time (I was hoping a different periodicity for each
>>> one), but they both were losing the same beacons. Hence, I'm thinking right
>>> now about the possibility that it has something to do with the coordinator,
>>> cause the other two devices are not even tx packets, just trying to me sync
>>> with the coordinator.
>>> I sent another mail a few days ago to the tinyos-help list cause I
>>> thought that maybe the problems were cause because I was using printf to
>>> debug the application, but without using it is losing sync as well, so...
>>> now I'm the one that is lost :S.
>>> Could you please check if the application attached is working for you? It
>>> is just the original TestData but with a Timer that once is fired sends the
>>> packets. When I try that, the device loses sync after a while.
>>> Thank you very much in advance.
>>> Regards,
>>>   Pablo
>>> 2010/11/18 Aitor Hernandez 

 Hi,
 We have been using this implementation for several wireless process and
 we made a performance evaluation of it. We haven't found any problem with
 the timers (used to start a transmission, or something else). The idea that
 comes up is that maybe there are some interferences on the same channel 
 that
 you are using or you have a high beacon order.
 As we have seen, if we receive packets on the period where we are
 waiting the beacon, we could miss them. Moreover I've just realized that by
 using a high beacon order (> 10) some motes could have problems to
 synchronize with the beacon. I guess that I could be due to the clock 
 drift,
 but Jan can clarify this point.
 What I recommend you, is to use a BO=6 and a SO =5,6 with this values
 you sh

Re: [Tinyos-help] 802.15.4

[Jan Hauer]

On Mon, Nov 22, 2010 at 8:47 PM, Aitor Hernandez  wrote:
>
> Hi,
> @Jan: thanks for the update! I haven't tested yet, but I am sure that it
> will be better.

It is better, but it seems that sometimes there are still problems - I
will take another look.

Jan

> @Pablo: One solution could be replace all the dbg_serial() for dbg() and
> then they won't be shown on the serial port. But it is not nice :P If you
> find another way please let us know.
> For the energy consumption, the best way is to measure the current of the
> mote (I've seen one paper which talks about that, but I don't have the
> reference at the moment). We have measured it and we realized that the mote,
> during the Inactive period does not go to the LPM3 mode because the radio is
> still on during this time. For this reason we have a modification of the
> implementation in order to turn off the radio during the inactive period.
> We are planning to publish the GTS implementation and the energy improvement
> within one week.
> Best regards,
> Aitor
> On 22 November 2010 18:50, Pablo Marcos 
> wrote:
>>
>> Hi,
>> About the TKN154_DEBUG mode, I couldn't get the coordinator compiled
>> correctly because of the lack of memory in some tests. I someone faces the
>> same problem, should try the -Os option to optimize the code and add as well
>> these few lines to disable in the coordinator some functionalities:
>> CFLAGS += -I$(shell pwd)/.. \
>> -DIEEE154_SCAN_DISABLED \
>> -DIEEE154_BEACON_SYNC_DISABLED \
>> -DIEEE154_PROMISCUOUS_MODE_DISABLED \
>> This way, there is no error compiling in debug mode. Anyway, does anyone
>> know how to print using the dbg_serial the TKN has implemented without
>> having the default printfs the TKN is showing? And what about how to know
>> how much energy the CC2420 is consuming? It has to be some way to measure
>> how much time the radio is in each mode, and using the datasheet, know how
>> much energ is consuming.
>> Thanks in advance.
>> Regards,
>>   Pablo
>> 2010/11/19 Aitor Hernandez 
>>>
>>> Hi,
>>> I've tried your app, and it is working with 6 motes + coordinator during
>>> ~15min. I don't understand which could be the problem in your case. You
>>> could try to change the mote that plays the coordinator role. If your motes
>>> are old, it could be a problem.
>>> A temporaly solution, coudl be start the MLME_SCAN (startApp();) again
>>> after the MLME_SYNC_LOSS but it is not a good idea, because then you won't
>>> see this kind of problems.
>>> I want to remark what you said about the printf and debug. The printf
>>> introduces a lot of delay, around 9x{backoff period}, but if is possible to
>>> use TKN154_4, the dbg_serial takes around one backoff period (20 symbols).
>>> Hence, it is really important to disable them if they are not completely
>>> necessary. These values are approximations :P
>>> Best regards,
>>> Aitor
>>>
>>> On 18 November 2010 22:48, Pablo Marcos Oltra
>>>  wrote:

 Hi,
 Thank you very much for your response Aitor. I had two motes running for
 3 days with BO=14 and I had no problems of sync using the TestSync
 application. Not even one beacon was missed. This was the first test I ran
 to check if I was about to have clock drift problems in later experiments.
 I'm currently using channels 19 and 20 because in my building there are 
 just
 a few spare channels to use (20  are mainly being used right now). Besides,
 I always set up BO and SO < 7, using usually 5, but not even that way works
 properly.
 Anyway, I don't really know if it has something to do with using timers,
 but I have noticed that the losing of the sync is kind of periodically. I
 have noticed today as well that both devices lose sync even if they don't
 even start at the same time (I was hoping a different periodicity for each
 one), but they both were losing the same beacons. Hence, I'm thinking right
 now about the possibility that it has something to do with the coordinator,
 cause the other two devices are not even tx packets, just trying to me sync
 with the coordinator.
 I sent another mail a few days ago to the tinyos-help list cause I
 thought that maybe the problems were cause because I was using printf to
 debug the application, but without using it is losing sync as well, so...
 now I'm the one that is lost :S.
 Could you please check if the application attached is working for you?
 It is just the original TestData but with a Timer that once is fired sends
 the packets. When I try that, the device loses sync after a while.
 Thank you very much in advance.
 Regards,
   Pablo
 2010/11/18 Aitor Hernandez 
>
> Hi,
> We have been using this implementation for several wireless process and
> we made a performance evaluation of it. We haven't found any problem with
> the timers (used to start a transmission, or something else). The idea 
> that
> comes up is that maybe th

Re: [Tinyos-help] 802.15.4

[Pablo Marcos]

Thanks a lot Jan.

The problem is that each time I try to use the default printf in the
coordinator, my application loses sync. So right now, the only way I know
about getting results is using another node as sniffer (using
TestPromiscuous), which seems to work fine and cannot lose sync cause it is
not associated and is just listening packets. The problem is that for
instante, if you want to know how much packets the coordinator has rx, you
cannot guarantee that using another node, obviously.

For what Aitor said, it seems the dbg_serial is a lot better than the
default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
dbg_serial, but do with the default printf), so I was wondering if it would
be any way to make the dbg_serial work without having all the TKN154
dbg_serial's by default, just the ones that I write "by hand" in my own app.

Regards,
  Pablo

2010/11/23 Jan Hauer 

> On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
>  wrote:
> > Hi,
> > About the TKN154_DEBUG mode, I couldn't get the coordinator compiled
> > correctly because of the lack of memory in some tests. I someone faces
> the
> > same problem, should try the -Os option to optimize the code and add as
> well
> > these few lines to disable in the coordinator some functionalities:
> > CFLAGS += -I$(shell pwd)/.. \
> > -DIEEE154_SCAN_DISABLED \
> > -DIEEE154_BEACON_SYNC_DISABLED \
> > -DIEEE154_PROMISCUOUS_MODE_DISABLED \
> > This way, there is no error compiling in debug mode. Anyway, does anyone
> > know how to print using the dbg_serial the TKN has implemented without
> > having the default printfs the TKN is showing?
>
> When TKN154_DEBUG is defined you can also use printf("...") to output
> your debug info over serial, but keep in mind that you should be in
> sync context (in async command/event handlers you can use
> tkn154_dbg_serial(), see tos/lib/mac/tkn154/TKN154_MAC.h line 289). If
> you only want your own debug messages, then don't define TKN154_DEBUG,
> instead use printf library as described in the tutorial
> (http://docs.tinyos.net/index.php/The_TinyOS_printf_Library). To
> disable / remove all your debug printf-statements later you can do
> something like this:
>
> #define printf(...)
>
> > And what about how to know
> > how much energy the CC2420 is consuming? It has to be some way to measure
> > how much time the radio is in each mode, and using the datasheet, know
> how
> > much energ is consuming.
> > Thanks in advance.
> > Regards,
> >   Pablo
> > 2010/11/19 Aitor Hernandez 
> >>
> >> Hi,
> >> I've tried your app, and it is working with 6 motes + coordinator during
> >> ~15min. I don't understand which could be the problem in your case. You
> >> could try to change the mote that plays the coordinator role. If your
> motes
> >> are old, it could be a problem.
> >> A temporaly solution, coudl be start the MLME_SCAN (startApp();) again
> >> after the MLME_SYNC_LOSS but it is not a good idea, because then you
> won't
> >> see this kind of problems.
> >> I want to remark what you said about the printf and debug. The printf
> >> introduces a lot of delay, around 9x{backoff period}, but if is possible
> to
> >> use TKN154_4, the dbg_serial takes around one backoff period (20
> symbols).
> >> Hence, it is really important to disable them if they are not completely
> >> necessary. These values are approximations :P
> >> Best regards,
> >> Aitor
> >>
> >> On 18 November 2010 22:48, Pablo Marcos Oltra
> >>  wrote:
> >>>
> >>> Hi,
> >>> Thank you very much for your response Aitor. I had two motes running
> for
> >>> 3 days with BO=14 and I had no problems of sync using the TestSync
> >>> application. Not even one beacon was missed. This was the first test I
> ran
> >>> to check if I was about to have clock drift problems in later
> experiments.
> >>> I'm currently using channels 19 and 20 because in my building there are
> just
> >>> a few spare channels to use (20  are mainly being used right now).
> Besides,
> >>> I always set up BO and SO < 7, using usually 5, but not even that way
> works
> >>> properly.
> >>> Anyway, I don't really know if it has something to do with using
> timers,
> >>> but I have noticed that the losing of the sync is kind of periodically.
> I
> >>> have noticed today as well that both devices lose sync even if they
> don't
> >>> even start at the same time (I was hoping a different periodicity for
> each
> >>> one), but they both were losing the same beacons. Hence, I'm thinking
> right
> >>> now about the possibility that it has something to do with the
> coordinator,
> >>> cause the other two devices are not even tx packets, just trying to me
> sync
> >>> with the coordinator.
> >>> I sent another mail a few days ago to the tinyos-help list cause I
> >>> thought that maybe the problems were cause because I was using printf
> to
> >>> debug the application, but without using it is losing sync as well,
> so...
> >>> now I'm the one that is lost :S.
> >>> Could you please check if the applicatio

[Tinyos-help] [Tinyos-Help] Send Data from PC to TelosB (basestation)

[José Eduardo S . C . Xavier]

Can anyone help me to know how to send data via uart to telosB?

Thanks
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Tinyos-Help] Send Data from PC to TelosB (basestation)

[Michael Schippling]

I believe there is a TestSerial demo program in TOS2.x
that you could use as an example.
MS

José Eduardo S. C. Xavier wrote:
> Can anyone help me to know how to send data via uart to telosB?
> 
> Thanks
> 
> 
> 
> 
> ___
> 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] [Tinyos-Help] Send Data from PC to TelosB (basestation)

[José Eduardo S . C . Xavier]

I have a file named TestSerial.java and i can't see where the packet format
is.
It imports net.tinyos.message and net.tinyos.packet; where should i search
for the solution? inside those files?

regards

No dia 23 de Novembro de 2010 17:53, Michael Schippling
escreveu:

> I believe there is a TestSerial demo program in TOS2.x
> that you could use as an example.
> MS
>
>
> José Eduardo S. C. Xavier wrote:
>
>> Can anyone help me to know how to send data via uart to telosB?
>>
>> Thanks
>>
>>
>> 
>>
>> ___
>> 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] [Tinyos-Help] Send Data from PC to TelosB (basestation)

[Michael Schippling]

I don't use T2 so I can't help trace through TestSerial,
message and packet are the underlying classes for messaging
but they may be extended somehow for the program. Perhaps
there is some other documentation if you search.

I have a rather convoluted example of bi-directional
communication here if you want to see a different approach
using TOS1.x:
 http://www.etantdonnes.com/Motes/robocode.tar.gz

MS

José Eduardo S. C. Xavier wrote:
> I have a file named TestSerial.java and i can't see where the packet 
> format is.
> It imports net.tinyos.message and net.tinyos.packet; where should i 
> search for the solution? inside those files?
> 
> regards
> 
> No dia 23 de Novembro de 2010 17:53, Michael Schippling 
> mailto:sc...@santafe.edu>> escreveu:
> 
> I believe there is a TestSerial demo program in TOS2.x
> that you could use as an example.
> MS
> 
> 
> José Eduardo S. C. Xavier wrote:
> 
> Can anyone help me to know how to send data via uart to telosB?
> 
> Thanks
> 
> 
> 
> 
> 
> ___
> 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] [Tinyos-Help] Send Data from PC to TelosB (basestation)

[Eric Decker]

try the tutorials.

Good place to try.

http://docs.tinyos.net/index.php/TinyOS_Tutorials#Mote-mote_radio_communication

It won't walk you through but you should be able to figure it out from
there.

The first one, "mote-to-mote" talks about communications, the next tutorial,
"mote-to-pc" talks about what's different and talks about SerialAM stuff and
the serialforwarder.   Also look in support/sdk/c/sf (this is where the
serialforwarder lives).   In that directory you'll see things like
seriallisten.c and serialsend.c


As Michael says...   try looking at apps/tests/TestSerial

eric


2010/11/23 José Eduardo S. C. Xavier 

> Can anyone help me to know how to send data via uart to telosB?
>
> Thanks
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>



-- 
Eric B. Decker
Senior (over 50 :-) Researcher
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Shimmer-users] Software auto acknowledgements break packet timestamps in the C2420 driver

[steve ayer]

hi.

miklos, you may be confusing the configurations among the various 
shimmer revs, which have different pin layouts relative to the cc2420. 
on shimmer, the sfd signal is routed to a capture-capable pin on the 
msp430; on shimmer2, due to an oversight it was not, so a capture was 
manually implemented using an interrupt.  this oversight was corrected 
for span and shimmer2r.

the code that you sent will break shimmer and shimmer2r, and the fix for 
shimmer2 was committed in january.

silvan, how old is your tinyos-2.x codebase?  is it from the current svn 
repository at googlecode?

i'll be happy to help untangle this problem if it stems from up to date 
platform code.

-steve

On 11/22/2010 03:14 AM, Miklos Maroti wrote:
> Hi Silvan,
>
> I think the problem is with the configuration of CC2420 on Shimmer. We
> have run into this as well. Can you please two files in your
> platforms/shimmer/chips/cc2420 with the ones I have attached and check
> if this fixes your problem?
>
> Miklos
>
> On Mon, Nov 22, 2010 at 1:57 AM, Omprakash Gnawali
>   wrote:
>> -- Forwarded message --
>> From: Silvan Nellen
>> Date: Mon, Nov 8, 2010 at 7:36 AM
>> Subject: [Tinyos-help] Software auto acknowledgements break packet
>> timestamps in the C2420 driver
>> To: 
>> "tinyos-help@millennium.berkeley.edu"
>>
>>
>> Hello,
>>
>>
>>
>> I’m trying to run the FTSP test application (revision 5215 of
>> http://tinyos-main.googlecode.com/svn/trunk) as described in
>> tinyos-2.x/apps/tests/TestFTSP/Ftsp/README.txt on Shimmer. At first
>> the nodes running TestFtspAppC didn’t seem to respond to the messages
>> sent out by the beacon mote (java FtspDataLogger reported nothing).
>> Using a packet sniffer I discovered that the FTSP motes send ACK
>> packets for each beacon message but they don’t send report messages
>> (which would then be picked up by the base station and ultimately be
>> displayed by the FtspDataLogger).
>>
>>
>>
>> I looked at the CC2420 driver source code in
>> tos/chips/cc2420/receive/CC2420ReceiveP.nc and used printf to see
>> what’s going on, and I think I found the problem:  the outgoing ACK
>> messages trigger the SFD interrupt and cause a timestamp to be put in
>> to the timestamp queue (line 190). If this happens BEFORE the
>> timestamp of the incoming packet is read, the packet timestamp is
>> cleared and the timestamp queue gets flushed (lines 633-635).
>> Consequently all packets received by the FTSP test application contain
>> invalid timestamps and are thus ignored (line 67 in TestFtsp.nc).
>>
>>
>>
>> Does that make sense? Is this a known problem? Has FTSP ever been
>> tested with CC2420?
>>
>>
>>
>> As a temporary fix I added PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS to
>> the Makefile and I get messages from the FTSP motes now, however this
>> fix doesn’t really address the cause of the problem…
>>
>>
>>
>> Silvan
>>
>>
>>
>> ___
>> Tinyos-help mailing list
>> Tinyos-help@millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>>
>>
>> ___
>> Shimmer-users mailing list
>> shimmer-us...@eecs.harvard.edu
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [6lowpan] [blip-users] 6lowpan blip simulation tool

[Ikram Ashraf]

Hi,

Try Cooja from Contiki it uses uIPv6 stack, but I guess it will not work 
with Berkeley Low-power IP stack (blip)


http://www.sics.se/~fros/cooja/cooja.pdf

Br,
Ikram


On 22/11/2010 16:17, alessandro ludovici wrote:

try TOSSIM (tinyos) but I am not sure it will works.
Other network simulator (omnet, ns-3) does not implements 6loWPAN. If 
you know any solution please let me know.


I am interested in simulation to.

2010/11/22 amy wang mailto:whq@gmail.com>>

hi, everyone
I want to do some simulation works of blip header compression, but
I do not know whether there is any existed simulation tool which
can support blip.
Does anyone can give me help?  I want to simulate the node energy
consume.
thanks very much.
amy
-- 




___
6lowpan mailing list
6low...@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Shimmer-users] Software auto acknowledgements break packet timestamps in the C2420 driver

[steve ayer]

aha!

why didn't you say so?  i'll make the change now.

thanks for pointing this out; please tell me when i miss details like 
that when you discover them, it helps me a great deal to have others my 
bugs.

i committed the fix.

thanks again.  silvan, please let me know if this solves your problem 
(if you're using shimmer2, that is).

-steve

On 11/22/2010 08:48 AM, Miklos Maroti wrote:
> Hi Steve,
>
> On Mon, Nov 22, 2010 at 2:35 PM, steve ayer  wrote:
>> hi.
>>
>> miklos, you may be confusing the configurations among the various shimmer
>> revs, which have different pin layouts relative to the cc2420. on shimmer,
>> the sfd signal is routed to a capture-capable pin on the msp430; on
>> shimmer2, due to an oversight it was not, so a capture was manually
>> implemented using an interrupt.  this oversight was corrected for span and
>> shimmer2r.
>
> I am using shimmer2. I know that shimmer2 does not have the hardware
> capture feature and it is implemented in software. However, your
> implementation uses TMilli as a time source and the time
> synchronization on the CC2420 assumes that it has 32khz timers,
> otherwise the TimeSyncPacket interfaces always returns FALSE in
> isValid.
>
>> the code that you sent will break shimmer and shimmer2r, and the fix for
>> shimmer2 was committed in january.
>
> The code I have attached should be applied to shimmer2 only, since it
> does software time capture but uses the 32khz timer to do that!
>
>> silvan, how old is your tinyos-2.x codebase?  is it from the current svn
>> repository at googlecode?
>>
>> i'll be happy to help untangle this problem if it stems from up to date
>> platform code.
>
> We use the latest SVN from google code.
>
> Best,
> Miklos
>
>>
>> -steve
>>
>> On 11/22/2010 03:14 AM, Miklos Maroti wrote:
>>>
>>> Hi Silvan,
>>>
>>> I think the problem is with the configuration of CC2420 on Shimmer. We
>>> have run into this as well. Can you please two files in your
>>> platforms/shimmer/chips/cc2420 with the ones I have attached and check
>>> if this fixes your problem?
>>>
>>> Miklos
>>>
>>> On Mon, Nov 22, 2010 at 1:57 AM, Omprakash Gnawali
>>> wrote:

 -- Forwarded message --
 From: Silvan Nellen
 Date: Mon, Nov 8, 2010 at 7:36 AM
 Subject: [Tinyos-help] Software auto acknowledgements break packet
 timestamps in the C2420 driver
 To:
 "tinyos-help@millennium.berkeley.edu"


 Hello,



 I’m trying to run the FTSP test application (revision 5215 of
 http://tinyos-main.googlecode.com/svn/trunk) as described in
 tinyos-2.x/apps/tests/TestFTSP/Ftsp/README.txt on Shimmer. At first
 the nodes running TestFtspAppC didn’t seem to respond to the messages
 sent out by the beacon mote (java FtspDataLogger reported nothing).
 Using a packet sniffer I discovered that the FTSP motes send ACK
 packets for each beacon message but they don’t send report messages
 (which would then be picked up by the base station and ultimately be
 displayed by the FtspDataLogger).



 I looked at the CC2420 driver source code in
 tos/chips/cc2420/receive/CC2420ReceiveP.nc and used printf to see
 what’s going on, and I think I found the problem:  the outgoing ACK
 messages trigger the SFD interrupt and cause a timestamp to be put in
 to the timestamp queue (line 190). If this happens BEFORE the
 timestamp of the incoming packet is read, the packet timestamp is
 cleared and the timestamp queue gets flushed (lines 633-635).
 Consequently all packets received by the FTSP test application contain
 invalid timestamps and are thus ignored (line 67 in TestFtsp.nc).



 Does that make sense? Is this a known problem? Has FTSP ever been
 tested with CC2420?



 As a temporary fix I added PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS to
 the Makefile and I get messages from the FTSP motes now, however this
 fix doesn’t really address the cause of the problem…



 Silvan



 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help



 ___
 Shimmer-users mailing list
 shimmer-us...@eecs.harvard.edu
 https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>
>> ___
>> Shimmer-users mailing list
>> shimmer-us...@eecs.harvard.edu
>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
>>


___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Shimmer-users] Software auto acknowledgements break packet timestamps in the C2420 driver

[Silvan Nellen]

Hello,

First of all: thank you looking into this!

I updated my codebase to the latest revision and downloaded the Ftsp test 
application to Shimmer 2. I'm still observing the same behavior I described in 
my original email: The shimmer 2 mote sends an ACK for every message by the 
beacon mote, but never replies with a report message. However, if I disable 
auto acknowledgements (PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS) everything works 
as expected.

Silvan

-Original Message-
From: steve ayer [mailto:a...@handhelds.org] 
Sent: November 22, 2010 9:24 AM
To: Miklos Maroti
Cc: shimmer-us...@eecs.harvard.edu; Omprakash Gnawali; Silvan Nellen; TinyOS
Subject: Re: [Shimmer-users] [Tinyos-help] Software auto acknowledgements break 
packet timestamps in the C2420 driver

aha!

why didn't you say so?  i'll make the change now.

thanks for pointing this out; please tell me when i miss details like 
that when you discover them, it helps me a great deal to have others my 
bugs.

i committed the fix.

thanks again.  silvan, please let me know if this solves your problem 
(if you're using shimmer2, that is).

-steve

On 11/22/2010 08:48 AM, Miklos Maroti wrote:
> Hi Steve,
>
> On Mon, Nov 22, 2010 at 2:35 PM, steve ayer  wrote:
>> hi.
>>
>> miklos, you may be confusing the configurations among the various shimmer
>> revs, which have different pin layouts relative to the cc2420. on shimmer,
>> the sfd signal is routed to a capture-capable pin on the msp430; on
>> shimmer2, due to an oversight it was not, so a capture was manually
>> implemented using an interrupt.  this oversight was corrected for span and
>> shimmer2r.
>
> I am using shimmer2. I know that shimmer2 does not have the hardware
> capture feature and it is implemented in software. However, your
> implementation uses TMilli as a time source and the time
> synchronization on the CC2420 assumes that it has 32khz timers,
> otherwise the TimeSyncPacket interfaces always returns FALSE in
> isValid.
>
>> the code that you sent will break shimmer and shimmer2r, and the fix for
>> shimmer2 was committed in january.
>
> The code I have attached should be applied to shimmer2 only, since it
> does software time capture but uses the 32khz timer to do that!
>
>> silvan, how old is your tinyos-2.x codebase?  is it from the current svn
>> repository at googlecode?
>>
>> i'll be happy to help untangle this problem if it stems from up to date
>> platform code.
>
> We use the latest SVN from google code.
>
> Best,
> Miklos
>
>>
>> -steve
>>
>> On 11/22/2010 03:14 AM, Miklos Maroti wrote:
>>>
>>> Hi Silvan,
>>>
>>> I think the problem is with the configuration of CC2420 on Shimmer. We
>>> have run into this as well. Can you please two files in your
>>> platforms/shimmer/chips/cc2420 with the ones I have attached and check
>>> if this fixes your problem?
>>>
>>> Miklos
>>>
>>> On Mon, Nov 22, 2010 at 1:57 AM, Omprakash Gnawali
>>> wrote:

 -- Forwarded message --
 From: Silvan Nellen
 Date: Mon, Nov 8, 2010 at 7:36 AM
 Subject: [Tinyos-help] Software auto acknowledgements break packet
 timestamps in the C2420 driver
 To:
 "tinyos-help@millennium.berkeley.edu"


 Hello,



 I'm trying to run the FTSP test application (revision 5215 of
 http://tinyos-main.googlecode.com/svn/trunk) as described in
 tinyos-2.x/apps/tests/TestFTSP/Ftsp/README.txt on Shimmer. At first
 the nodes running TestFtspAppC didn't seem to respond to the messages
 sent out by the beacon mote (java FtspDataLogger reported nothing).
 Using a packet sniffer I discovered that the FTSP motes send ACK
 packets for each beacon message but they don't send report messages
 (which would then be picked up by the base station and ultimately be
 displayed by the FtspDataLogger).



 I looked at the CC2420 driver source code in
 tos/chips/cc2420/receive/CC2420ReceiveP.nc and used printf to see
 what's going on, and I think I found the problem:  the outgoing ACK
 messages trigger the SFD interrupt and cause a timestamp to be put in
 to the timestamp queue (line 190). If this happens BEFORE the
 timestamp of the incoming packet is read, the packet timestamp is
 cleared and the timestamp queue gets flushed (lines 633-635).
 Consequently all packets received by the FTSP test application contain
 invalid timestamps and are thus ignored (line 67 in TestFtsp.nc).



 Does that make sense? Is this a known problem? Has FTSP ever been
 tested with CC2420?



 As a temporary fix I added PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS to
 the Makefile and I get messages from the FTSP motes now, however this
 fix doesn't really address the cause of the problem...



 Silvan



 ___
 Tinyos-help mailing list
 Tinyos-help@millennium.berkeley.edu
 http

[Tinyos-help] help

[Lei]

Hi,

I'm using TOSSIM to simulate some application in which RSSI/LQI and RF Power
information is needed. Does anyone know whether TOSSIM in tinyos-2.x
supports some cc2420 specified function such as getRssi, getLqi or
setRFPower?

Many thanks,

Lei Shi
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help