[Tinyos-help] tinyviz plugins user manuals
Hi,I am having problems using the built-in plugins for tinyiz. can somebody provide user manuals for them.if not all, if somebody could provide guidance for setting distance between the nodes and setting the radio strength of the motes. Thanks,Nilay ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MAC used on t-mote sky
Yes. On 7/30/06, Tony L <[EMAIL PROTECTED]> wrote: Hi, I use t-mote sky. Is it correct that t-mote sky uses B-MAC, but without LowPowerListening and Clear Channel assessment implemention? Thanks. Best regards Tony _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ 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
[Tinyos-help] MAC used on t-mote sky
Hi, I use t-mote sky. Is it correct that t-mote sky uses B-MAC, but without LowPowerListening and Clear Channel assessment implemention? Thanks. Best regards Tony _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] set distance between motes in tinyviz
Hi, I am usiing tinyviz for my simulations. i need to set
distance between the motes in tinyviz ("directed graph" plugin) so
that motes do not send messages to long distances as they do now. Also, currently tinyviz does show some red/gree/blue lines along with some numbers but i am unable to understand.
Could anyone help me out in this.ThanksNilay
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] inject commands at runtime in tinyviz
Hi, I am running my simulations on TOSSIM ( tinyviz ). Is there any way I can inject commands into the network of motes at runtime.Thanks Nilay ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Source Code for Trickle
NetSync in Boomerang uses a trickle-like system too. Trickle is fairly easy to implement from the paper, the intricacies occur when you try to bind it with a particular data pattern--ie bulk dissemination, network synchronization, or commands. Because of this, you find all these different implementations of Trickle tuned to different use cases. -Joe On 7/29/06, Philip Levis <[EMAIL PROTECTED]> wrote: On Jul 28, 2006, at 2:52 PM, Pradip De wrote: > Hi all, > It would be of real help if someone could tell me where I > could get the source implementation of the Trickle code propagation > protocol? Thanks, Three implementations I know of in the TinyOS tree: tinyos-1.x/tos/lib/VM/components/MVirus.nc tinyos-1.x/tos/lib/Drip/DripStateM.nc tinyos-2.x/tos/lib/net/TrickleTimerImplP.nc Phil ___ 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] tinyos tutorial lesson 7
You probably missed adding Sounder to the SimpleCmd.nc config file.
Follow the example of PotC or LedsC in that file and I think you
may have more success...
MS
jurin dan wrote:
hi
i'm trying to do the exercise of lesson 7 of tinyos tutorial.
i've got a bug in step two which consist of In SimpleCmdM.nc, to
initialize the sounder and add a new command action that will turn the
sounder on and off.
i've joined to the mail the file simplecmdM.nc that i modified.
changes were made at line 64, 80, 124-130 and 148.
when i compile simplecmd i got this error message:
$ make install mica2
compiling Bcast to a mica2 binary
ncc -o build/mica2/main.exe -Os -board=micasb -target=mica2
-DCC1K_DEF_FREQ=9164
0 -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all
-finline-limit=10 -f
nesc-cfile=build/mica2/app.c Bcast.nc -lm
SimpleCmd.nc:56: cannot find `Sounder'
make: *** [build/mica2/main.exe] Error 1
i'm trying to fix the bug. help me please.
_
Play Q6 for your chance to WIN great prizes.
http://q6trivia.imagine-live.com/enca/landing
// $Id: SimpleCmdM.nc,v 1.4 2004/05/04 22:39:07 idgay Exp $
/*tab:4
* "Copyright (c) 2000-2003 The Regents of the University of California.
* All rights reserved.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation for any purpose, without fee, and without written
agreement is
* hereby granted, provided that the above copyright notice, the following
* two paragraphs and the author appear in all copies of this software.
*
* IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
* DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT
* OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE
UNIVERSITY OF
* CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
* ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO
OBLIGATION TO
* PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS."
*
* Copyright (c) 2002-2003 Intel Corporation
* All rights reserved.
*
* This file is distributed under the terms in the attached INTEL-LICENSE
* file. If you do not find these files, copies can be found by writing to
* Intel Research Berkeley, 2150 Shattuck Avenue, Suite 1300, Berkeley, CA,
* 94704. Attention: Intel License Inquiry.
*/
/*
* Author: Robert Szewczyk, Su Ping
*
* $\Id$
*/
/**
* SimpleCmdM is a tiny OS application module.
* This module demonstrates a simple command interpreter for the TinyOS
* tutorial. The module receives a command message from the radio, which
* is passed to the ProcessCmd interface for processing. A task is posted
* to process the command. The command packet contains a one-byte
* 'action' field specifying which action to take; as a simple version,
* this module can only interpret the follwoing commands:
* Led_on (action = 1), Led_off (2), radio_quieter (3), and radio_louder
(4).
*
* This module also implements the ProcessCmd interface.
* @author Robert Szewczyk
* @author Su Ping
**/
includes SimpleCmdMsg;
module SimpleCmdM {
provides {
interface StdControl;
interface ProcessCmd;
}
uses {
interface Leds;
interface Pot;
interface ReceiveMsg as ReceiveCmdMsg;
interface StdControl as CommControl;
interface StdControl as Sounder;
}
}
/*
* Module Implementation
*/
implementation
{
// module scoped variables
TOS_MsgPtr msg;
int8_t pending;
TOS_Msg buf;
bool sound=TRUE;
/**
*
* This task evaluates a command and execute it if it is a supported
* command.The protocol for the command interpreter is that
* it operates on the message and returns a (potentially modified)
* message to the calling layer, as well a status word for whether
* the message should be futher processed.
*
* @return Return: None
**/
task void cmdInterpret() {
struct SimpleCmdMsg * cmd = (struct SimpleCmdMsg *) msg->data;
// do local packet modifications: update the hop count and packet source
cmd->hop_count++;
cmd->source = TOS_LOCAL_ADDRESS;
// Interpret the command: Display the level on red and green led
if (cmd->hop_count & 0x1)
call Leds.greenOn();
else
call Leds.greenOff();
if (cmd->hop_count & 0x2)
call Leds.redOn();
else
call Leds.redOff();
// Execute the command
switch (cmd->action) {
case LED_ON:
call Leds.yellowOn();
break;
case LED_OFF:
call Leds.yellowOff();
break;
case RADIO_QUIETER:
call Pot.increase();
break;
case RADIO_LOUDER:
call Pot.decrease();
break;
case TOG_SOUNDER:
if (sound)
call Sounder.sta
[Tinyos-help] tinyos tutorial lesson 7
hi
i'm trying to do the exercise of lesson 7 of tinyos tutorial.
i've got a bug in step two which consist of In SimpleCmdM.nc, to
initialize the sounder and add a new command action that will turn the
sounder on and off.
i've joined to the mail the file simplecmdM.nc that i modified.
changes were made at line 64, 80, 124-130 and 148.
when i compile simplecmd i got this error message:
$ make install mica2
compiling Bcast to a mica2 binary
ncc -o build/mica2/main.exe -Os -board=micasb -target=mica2
-DCC1K_DEF_FREQ=9164
0 -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all
-finline-limit=10 -f
nesc-cfile=build/mica2/app.c Bcast.nc -lm
SimpleCmd.nc:56: cannot find `Sounder'
make: *** [build/mica2/main.exe] Error 1
i'm trying to fix the bug. help me please.
_
Play Q6 for your chance to WIN great prizes.
http://q6trivia.imagine-live.com/enca/landing
// $Id: SimpleCmdM.nc,v 1.4 2004/05/04 22:39:07 idgay Exp $
/* tab:4
* "Copyright (c) 2000-2003 The Regents of the University of California.
* All rights reserved.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation for any purpose, without fee, and without written agreement
is
* hereby granted, provided that the above copyright notice, the following
* two paragraphs and the author appear in all copies of this software.
*
* IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
* DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING
OUT
* OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY
OF
* CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
* ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
* PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS."
*
* Copyright (c) 2002-2003 Intel Corporation
* All rights reserved.
*
* This file is distributed under the terms in the attached INTEL-LICENSE
* file. If you do not find these files, copies can be found by writing to
* Intel Research Berkeley, 2150 Shattuck Avenue, Suite 1300, Berkeley, CA,
* 94704. Attention: Intel License Inquiry.
*/
/*
* Author: Robert Szewczyk, Su Ping
*
* $\Id$
*/
/**
* SimpleCmdM is a tiny OS application module.
* This module demonstrates a simple command interpreter for the TinyOS
* tutorial. The module receives a command message from the radio, which
* is passed to the ProcessCmd interface for processing. A task is posted
* to process the command. The command packet contains a one-byte
* 'action' field specifying which action to take; as a simple version,
* this module can only interpret the follwoing commands:
* Led_on (action = 1), Led_off (2), radio_quieter (3), and radio_louder (4).
*
* This module also implements the ProcessCmd interface.
* @author Robert Szewczyk
* @author Su Ping
**/
includes SimpleCmdMsg;
module SimpleCmdM {
provides {
interface StdControl;
interface ProcessCmd;
}
uses {
interface Leds;
interface Pot;
interface ReceiveMsg as ReceiveCmdMsg;
interface StdControl as CommControl;
interface StdControl as Sounder;
}
}
/*
* Module Implementation
*/
implementation
{
// module scoped variables
TOS_MsgPtr msg;
int8_t pending;
TOS_Msg buf;
bool sound=TRUE;
/**
*
* This task evaluates a command and execute it if it is a supported
* command.The protocol for the command interpreter is that
* it operates on the message and returns a (potentially modified)
* message to the calling layer, as well a status word for whether
* the message should be futher processed.
*
* @return Return: None
**/
task void cmdInterpret() {
struct SimpleCmdMsg * cmd = (struct SimpleCmdMsg *) msg->data;
// do local packet modifications: update the hop count and packet source
cmd->hop_count++;
cmd->source = TOS_LOCAL_ADDRESS;
// Interpret the command: Display the level on red and green led
if (cmd->hop_count & 0x1)
call Leds.greenOn();
else
call Leds.greenOff();
if (cmd->hop_count & 0x2)
call Leds.redOn();
else
call Leds.redOff();
// Execute the command
switch (cmd->action) {
case LED_ON:
call Leds.yellowOn();
break;
case LED_OFF:
call Leds.yellowOff();
break;
case RADIO_QUIETER:
call Pot.increase();
break;
case RADIO_LOUDER:
call Pot.decrease();
break;
case TOG_SOUNDER:
if (sound)
call Sounder.start();
else
call Sounder.stop();
sound=!sound;
break;
}
pen
Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?
Hi Michael, I think you are still not getting the problem I was having; I do really appreciate your help and responses. I am re-posting just to make the situation clear for future readers. I was not trying to broadcast the packet I was sending over the serial port i.e. to use the mote as a relay. I simply wanted to send the packet to that mote on that serial port and for it to react e.g. flash some leds. The best analogy I can give is as follows: You have a host PC, A,with IP address 192.168.0.2/24 from which you want to send a packet to host B with address 192.168.0.3/24. What I believe I was doing, by sending to 0x7e (UART), was sending to localhost or 127.0.0.1 on host A; the correct thing to do is to send to either 192.168.0.3 (host B) or 192.168.0.255 i.e broadcast to the local network, in which case host B would process the packet. Given the port is connected to only one mote, it is safe enough to just use the broadcast address, in which the mote will process the packet. Clearly packets that come off the radio or the serial port obviously go through the same processing. Thanks again. -- Warm regards, Darren Bishop, MSc, BSc (Hons), MBCS On Sunday 30 July 2006 20:38, Michael Schippling wrote: > OK, if I understand the issue, you were sending a message from the host > to a (or all) mote and you used the UART addr as the destination in the > message, which makes a certain kind (but not the TOS kind of) sense. > That message was never sent, because it was addressed to the UART and > didn't need to be forwarded over the radio. The addressing model is > not entirely symmetrical in this case, and I think this is common to > all TOS platforms. There is no way to specify a radio address from the > host if you have to use that field to get the message over the serial > line to the base station. > > Sorry for my mis-reading of your original help request... > Glad you figured this one out and are now ready for some new sleep loss. > MS > > Darren Bishop wrote: > > Hello Michael, Lei, All, > > > > I have solved the problem. I had been doing everything write except for > > the address I was specifying. I had read in a Tinyos-help thread started > > by Lei Tang (post by Julia) that you had to specify the UART address as > > destination. This does not work for me (maybe due to telosb platform) and > > it is the one reason I have been loosing sleep for 2 weeks; you can > > specify either the broadcast address or the motes address. I have tested > > this both in C going via serial forwarder and in my direct python > > application. > > > > Lei: I could not tell if you ever solved your problem: like the advice I > > was getting from my supervisor, you may have moved on to a different > > task, to come back to this later. > > In my experience the crc does matter. I am using GenericComm and my > > component is not signalled if I deliberatly mangle the crc pc-side before > > sending. Look at Crc.java or serialsource.c for implementations of the > > crc algorithm. You maybe using a component/interface too low-level to > > benefit from the crc i.e. the check fails but you're working at a level > > where processing occurs regardless. Use GenericComm. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?
OK, if I understand the issue, you were sending a message from the host to a (or all) mote and you used the UART addr as the destination in the message, which makes a certain kind (but not the TOS kind of) sense. That message was never sent, because it was addressed to the UART and didn't need to be forwarded over the radio. The addressing model is not entirely symmetrical in this case, and I think this is common to all TOS platforms. There is no way to specify a radio address from the host if you have to use that field to get the message over the serial line to the base station. Sorry for my mis-reading of your original help request... Glad you figured this one out and are now ready for some new sleep loss. MS Darren Bishop wrote: Hello Michael, Lei, All, I have solved the problem. I had been doing everything write except for the address I was specifying. I had read in a Tinyos-help thread started by Lei Tang (post by Julia) that you had to specify the UART address as destination. This does not work for me (maybe due to telosb platform) and it is the one reason I have been loosing sleep for 2 weeks; you can specify either the broadcast address or the motes address. I have tested this both in C going via serial forwarder and in my direct python application. Lei: I could not tell if you ever solved your problem: like the advice I was getting from my supervisor, you may have moved on to a different task, to come back to this later. In my experience the crc does matter. I am using GenericComm and my component is not signalled if I deliberatly mangle the crc pc-side before sending. Look at Crc.java or serialsource.c for implementations of the crc algorithm. You maybe using a component/interface too low-level to benefit from the crc i.e. the check fails but you're working at a level where processing occurs regardless. Use GenericComm. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: [Question] about task in book "TinyOS Programming"
On Jul 29, 2006, at 11:02 PM, Hui KANG wrote: Dr. Levis: After reading Section 4.4 about Tasks in your book, "TinyOS programming", I still have some problem. Please send questions to tinyos-help. That way everyone can benefit from the answers, and they are entered in the online archives for future users. 1: For the code example in pp 31, you said signalling an even from within a command is a bad idea, since it can cause call loops. But actually in this example, Read.readDone does not call Read.read again. So I think it will not cause a call loop. Am I correct? Correct. 2: Second, to prove there exists a call loop, you modify Read.readDone as in pp 32. Herein, it calls Read.read() in Read.readDone(). I agree that in this example call loop occurs. So the modified code in pp 33 post task void readDoneTask() to avoid the call loop. Two problems in this code example: (a) In this example, RawRead.readDone (should it be Read.readDone() ) actually does not call Read.read(). If the answer to 1 is yes, then it seems no improvement by using task. Both have the same effect. The the code example in pp 33 is not suitable to show the benefit of Task. Take a look at the code on page 34. The question is not whether the provider of Read calls Read.read in Read.readDone, but whether the *user* does. Please look at listing 4.12, entitled "Signal handler that can lead to an infinite loop." (b) If assuming that the code example in 33 posted Read.read() in RawRead.readDone, does task avoid the call loop? As said, task can run atomicly to other tasks. But it is possible that Read.read() preempt to the task. So the call loop still exists? No. Look at the next listing. 3: What is the difference between task and an ordinary function, like task void ProcessData() and void ProcessData(); I am a little bit confused. Thanks. A function executes immediately. A task executes later. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Ian McCauley/DPI is out of the office.
I will be out of the office starting 28/07/2006 and will not return until 15/08/2006. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] [Question related to Deluge] unable to reboot
Hello, I have been working on a micaz mote connected to a mib510 programming board. And I have worked on both my laptop and desktop. When working on the desktop, I had no problem in trying the Deluge manual. But on the laptop, I had some problem in reboot. By following the manual, I injected the modified Blink program and checked that the program was succuessfully injected using "java net.tinyos.tools.Deluge --ping." But when trying to reboot using the modified Blink, the current executed image was not changed into the modified Blink program. It was still the DelugeBasic program. I don't think that battery is not a problem because a power cable was connected to my mib510 programming board. And all tinyos environment on my laptop and desktop is same (make systems on my laptop and desktop are 3.80 version.) I am not sure what the reason is. Please help me if anyone knows the solution. Thanks in advance, Regards. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?
Hello Michael, Lei, All,
I have solved the problem. I had been doing everything write except for the
address I was specifying. I had read in a Tinyos-help thread started by Lei
Tang (post by Julia) that you had to specify the UART address as
destination. This does not work for me (maybe due to telosb platform) and it
is the one reason I have been loosing sleep for 2 weeks; you can specify
either the broadcast address or the motes address. I have tested this both in
C going via serial forwarder and in my direct python application.
Lei: I could not tell if you ever solved your problem: like the advice I was
getting from my supervisor, you may have moved on to a different task, to
come back to this later.
In my experience the crc does matter. I am using GenericComm and my component
is not signalled if I deliberatly mangle the crc pc-side before sending. Look
at Crc.java or serialsource.c for implementations of the crc algorithm.
You maybe using a component/interface too low-level to benefit from the crc
i.e. the check fails but you're working at a level where processing occurs
regardless. Use GenericComm.
--
Warm regards,
Darren Bishop, MSc, BSc (Hons), MBCS
On Sunday 30 July 2006 06:57, Michael Schippling wrote:
> Looks to me like your CommandMsg stuff is here, in lsb order:
>
> Pkt: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb 7e
> ^ ^ ^
> cmd mask arg
>
> The 7e's are message sync bytes, and the 7d5e and 7d5d are escaped values
> which map to 7e and 7d (I think...). In any case have a look at the
> OcataveTech page for interpretation of the message stream:
> http://www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Pac
>kets.pdf
>
> was that the question?
> MS
>
> Darren Bishop wrote:
> > Could someone please help me with writing to Moteiv telosb motes? I am
> > working with Python, but I do not expect this will matter much due to the
> > tight coupling with C.
> >
> > The following struct describes what I am trying to send:
> >
> > struct CommandMsg {
> > uint16_t cmd; // = 3
> > uint16_t mask; // = 1<<15
> > uint16_t arg; // = 10
> > };
> >
> > The data I send goes through the following transformations:
> >
> > Data: 03 00 00 80 0a 00
> > Message: 14 7d 03 00 00 80 0a 00
> > Packet: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb
> > 7e
> >
> > I recall reading that motes are LSB byte order, and hence the ordering I
> > use.
> >
> > Can someone please process these threee 16-bit integers and show me how
> > it is done ?
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] problems with programming base station (timer problem)
Hi all
I was wondering if someone can help us regarding this code. What we need
to do is to program the base station to send three anchor packets after
the timer get fired (After 30 seconds). The base station should wait 30
sec and then sends three packets but what happens is the base station
sends packets to UART in the first 30 seconds without receiving any
packets from the network. Attached please have a look to the code:
module InitialBcastM
{
provides
{
interface StdControl;
}
uses
{
interface Timer;
interface TOS_MsgOutput;
}
}
implementation
{
AnchorXY AnchorPacket;
int count;
command result_t StdControl.init()
{
count = 0;
AnchorPacket.X = GLOBAL_X;
AnchorPacket.Y = GLOBAL_Y;
AnchorPacket.hopCount = 1;
atomic
{
AnchorPacket.src = TOS_LOCAL_ADDRESS;
}
return SUCCESS;
}
command result_t StdControl.start()
{
return call Timer.start(TIMER_REPEAT,500);
}
command result_t StdControl.stop()
{
return call Timer.stop();
}
event result_t Timer.fired()
{
TOS_Msg msg;
AnchorXY *ptr = (AnchorXY *)(msg.data);
count++;
if(count == 3)
call StdControl.stop();
*ptr = AnchorPacket;
call TOS_MsgOutput.output(TOS_BCAST_ADDR,
sizeof(AnchorXY), &msg);
}
event result_t TOS_MsgOutput.outputComplete(bool success)
{
return success;
}
}
And then another part of the code which asks base station not to do
anything in the first 30 sec:
module DVHopStageIM
{
provides
{
interface StdControl;
}
uses
{
interface StdControl as IBControl;
interface StdControl as PRControl;
interface StdControl as RPControl;
interface StdControl as StageIIControl;
interface Timer;
interface Leds;
interface TOS_MsgOutput;
}
}
implementation
{
NodeInfo *ptr;
TOS_Msg msg;
AnchorXY *m;
command result_t StdControl.init()
{
dbg(DBG_TEMP, "Stage I init()");
atomic
{
initialize(&headptr);
}
return rcombine4(call IBControl.init(), call
PRControl.init(), call RPControl.init(), call StageIIControl.init());
}
command result_t StdControl.start()
{
dbg(DBG_TEMP, "Stage I start()");
return rcombine4(call IBControl.start(), call
PRControl.start(), call RPControl.start(), call
Timer.start(TIMER_ONE_SHOT,3));
}
command result_t StdControl.stop()
{
dbg(DBG_TEMP, "StageI stop()");
return rcombine4(call IBControl.stop(), call
PRControl.stop(), call RPControl.stop(), call StageIIControl.stop());
}
task void headToUART()
{
atomic
{
ptr = headptr;
}
if(ptr)
{
m = (AnchorXY*)(msg.data);
*m = ptr->packet;
call TOS_MsgOutput.output(TOS_UART_ADDR,
sizeof(AnchorXY), &msg);
}
}
event result_t Timer.fired()
{
call Leds.greenToggle();
post headToUART();
dbg(DBG_TEMP, "This is the end of stage I");
return call StageIIControl.start();;
}
event result_t TOS_MsgOutput.outputComplete(bool success)
{
if(success)
ptr = ptr->next;
if(ptr)
{
m = (AnchorXY*)(msg.data);
*m = ptr->packet;
call TOS_MsgOutput.output(TOS_UART_ADDR,
sizeof(AnchorXY), &msg);
}
}
}
Could someone please help us because this code is working fine with the
nodes of one of my friends who is using mica2 motes and I am using micaz
motes. We tried to figure out what is the problem but we were not
successful.
Thanks in advance
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?
Firstly thanks for replying - I appreciate it.
Secondly, no it was not the question. I have already read the reference you
posted and it did explain a few things that has enabled me to get this far.
The transformations I described are affected by my code; remember I am
attempting to write to the mote, so we are looking at:
Pkt: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03[14] 00 00[16] 80 0a[18] 00
ba[20] eb 7e
cmd == pkt[14,15]
mask == pkt[16,17]
arg == pkt[18,19]
(crc == pkt[20,21])
All the extra bytes near the start of the packet are there for the TelosB
CC2420 radio i.e. it has a different message header to the Micas. Note that
the mote differentiates between a radio packet and a UART packet by the
destination address.
So what I am really asking is for someone to construct a packet ready for the
wire targeting the telosb platform, with 20 as the AM type, 0x7e as the
destination, 0x7d as the group id, three 16-bit numbers (3, 1<< 15, 10), plus
the crc calculation
--
Warm regards,
Darren Bishop, MSc, BSc (Hons), MBCS
On Sunday 30 July 2006 06:57, Michael Schippling wrote:
> Looks to me like your CommandMsg stuff is here, in lsb order:
>
> Pkt: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb 7e
> ^ ^ ^
> cmd mask arg
>
> The 7e's are message sync bytes, and the 7d5e and 7d5d are escaped values
> which map to 7e and 7d (I think...). In any case have a look at the
> OcataveTech page for interpretation of the message stream:
> http://www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Pac
>kets.pdf
>
> was that the question?
> MS
>
> Darren Bishop wrote:
> > Could someone please help me with writing to Moteiv telosb motes? I am
> > working with Python, but I do not expect this will matter much due to the
> > tight coupling with C.
> >
> > The following struct describes what I am trying to send:
> >
> > struct CommandMsg {
> > uint16_t cmd; // = 3
> > uint16_t mask; // = 1<<15
> > uint16_t arg; // = 10
> > };
> >
> > The data I send goes through the following transformations:
> >
> > Data: 03 00 00 80 0a 00
> > Message: 14 7d 03 00 00 80 0a 00
> > Packet: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb
> > 7e
> >
> > I recall reading that motes are LSB byte order, and hence the ordering I
> > use.
> >
> > Can someone please process these threee 16-bit integers and show me how
> > it is done ?
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
