Hi,

Thanks for the program files. I think they should help us a lot to track 
down the problem.

When I do "make telosb install" (or reinstall), it will just copy the 
.ihex file instead of changing the symbols, so there seems to be a 
difference between your setup and mine. In any case, from the tests I 
did now this should not be relevant.

I just tried with the BlinkToRadio program. Your binary version 
(installed with the bsl command) does indeed not work on my motes. I 
then recompiled your version of the BlinkToRadio program, and it works 
fine. I tested this on two different systems (GNU/Linux and Mac) and it 
works on both. I then upgraded my TinyOS source tree to revision 5244, 
and it still works. So my guess is there is something not working with 
your installation.

I compared the generated app.c files, and they are quite a bit 
different. From what I can see, I doubt you are really using revision 
5244. From your app.c file, the declaration of timesync_footer_t is a 
struct. This was changed in Revision 5221 to nx_struct (as found while 
checking the revision history of 
tos/chips/cc2420/CC2420TimeSyncMessage.h). So my guess is your system 
somehow uses an old TinyOS source tree (maybe there is another copy of 
the source tree and your compiler doesn't use the one you'd like it to use).

Another problem could be different versions of the hardware libraries. 
The libraries for the msp430 microcontroller are not part of TinyOS but 
rather of the compiler. Maybe your system has a different version of the 
compiler that somehow does not work as intended with the current version 
of TinyOS.

Cheers,
Urs

On 12/03/2010 10:40 AM, 徐瑞涛 wrote:
> Hi,
>
> Actually, I use the three different ID for three nodes. At most case,
> only receiving mote(0) and sending mote(1) is open.
>
> I haven't try allocate ID explicitly for receiving mote. But by default,
> it really is 1. The following output from make telosb install will
> confirm this.
>
> writing TOS image
> tos-set-symbols --objcopy msp430-objcopy --objdump msp430-objdump
> --target ihex build/telosb/main.ihex build/telosb/main.ihex.out-1
> *TOS_NODE_ID=1 ActiveMessageAddressC__addr=1*
> installing telosb binary using bsl
> tos-bsl --telosb -c /dev/ttyUSB3 -r -e -I -p build/telosb/main.ihex.out-1
> MSP430 Bootstrap Loader Version: 1.39-telos-8
> Mass Erase...
> Transmit default password ...
> Invoking BSL...
> Transmit default password ...
> Current bootstrap loader version: 1.61 (Device ID: f16c)
> Changing baudrate to 38400 ...
> Program ...
> 13016 bytes programmed.
> Reset device ...
> rm -f build/telosb/main.exe.out-1 build/telosb/main.ihex.out-1
>
> And the attachment including the standard BlinkToRadio (intactly),
> my SendingMote and ReceivingMote code.
> There is only one difference between SendingMote and RecevingMote:
> whether call send command when radio start successfully.
>
> Best Regards,
> Ruitao Xu
>
>
>
> 在 2010年12月3日 下午5:11,Urs Hunkeler <urs.hunke...@epfl.ch
> <mailto:urs.hunke...@epfl.ch>>写道:
>
>     Hi,
>
>     If you use all three motes, maybe you could try giving them different
>     IDs (instead of having two receiving nodes with the same ID).
>
>     Did you try to explicitly give the NodeID to the sending mote (instead
>     of relying that the default ID is ok)? I remember that the nodeID is set
>     in two different places, and if by chance they differ for some reason
>     when not set explicitly, maybe a mote refuses to send (or receive) a
>     message?
>
>     There is a special packet sniffer application in the contribution tree
>     of TinyOS:
>     
> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/tub/apps/PacketSniffer_802_15_4/
>
>     Maybe I should have mentioned it: The idea for you to send me your code
>     is so that I don't have to update my TinyOS installation and can see
>     whether it works with an older version. Best is if you could send me
>     your program folders with the compiled version (the build directory) as
>     well, so I can first try your binaries before trying to compile the
>     application.
>
>     Cheers,
>     Urs
>
>     On 12/03/2010 09:55 AM, 徐瑞涛 wrote:
>      > Hi Urs,
>      >
>      > FIrst of all, many thanks for your help.
>      >
>      > 1) Receiving mote always get the TOS_NODE_ID=0, and Sending mote
>     always
>      > use the
>      > default TOS_NODE_ID, it's 1.
>      > Programming commands looks like:
>      > make telosb install,0 # for receiving mote
>      > make telosb install # for sending mote
>      >
>      > 2) I always send the broadcast pkt.
>      > 3) I have three telosb motes. With each mote programmed the standard
>      > BlinkToRadio app,
>      > I tested BlinkToRadio under C(3, 2) different combinations. Any mote
>      > never blink.
>      > I really suspect that it's hardware problem. Because these three
>     motes
>      > never received any
>      > pkt and this is the first time that I test whether they can
>     communicate
>      > with each other since I
>      > bought them.
>      >
>      > 4) No any receive event has been signaled, so I think sniffer is also
>      > unable to receive pkt.
>      > I tried to programme the BaseStation app to the receiving mote,
>     but it
>      > CAN'T receive any pkt.
>      > (Serial communication is OK. I can send bytes to mote and mote
>     can echo
>      > thoes bytes.)
>      >
>      > If BlinkToRadio(on rev 5244) runs correctly on your telosb motes,
>     it's
>      > probable my motes's
>      > problem.
>      >
>      > Here's my code for Receiving Mote: (based on BlinkToRadio, just make
>      > little change)
>      > Sending Mote just use the BlinkToRadio source intactly.
>      >
>      > event void AMControl.startDone(error_t err) {
>      > if (err == SUCCESS) {
>      > * // call Timer0.startPeriodic(TIMER_PERIOD_MILLI); # no need to send
>      > periodically*
>      > }
>      > else {
>      > call AMControl.start();
>      > }
>      > }
>      >
>      > event message_t* Receive.receive(message_t* msg, void* payload,
>     uint8_t
>      > len){
>      > if (len == sizeof(BlinkToRadioMsg)) {
>      > BlinkToRadioMsg* btrpkt = (BlinkToRadioMsg*)payload;
>      > * //setLeds(btrpkt->counter);
>      > call Leds.led0Toggle(); # when receiving, just toggle led0*
>      > }
>      > return msg;
>      > }
>      >
>      >
>      > On Fri, Dec 3, 2010 at 4:25 PM, Urs Hunkeler
>     <urs.hunke...@epfl.ch <mailto:urs.hunke...@epfl.ch>
>      > <mailto:urs.hunke...@epfl.ch <mailto:urs.hunke...@epfl.ch>>> wrote:
>      >
>      > Hi,
>      >
>      > This gets difficult to debug. Here are just a couple of ideas:
>      >
>      > Do you use different NodeIDs for the different motes?
>      >
>      > Do you send messages to a specific NodeID or do you send messages as
>      > broadcasts?
>      >
>      > Have you tried with other motes? (in case there is a hardware
>     problem)
>      >
>      > Have you tried to reverse the roles of the mote? (in case one of the
>      > motes can't send but can receive, or vice versa)
>      >
>      > If you have MicaZ motes (they have the same radio and can
>      > communicate), does your program work on the MicaZ motes? If so, does
>      > it work with a MicaZ and a TelosB mote?
>      >
>      > If you have a sniffer, do you see data transmissions from the
>      > sending mote? (If yes, could you send us a trace?) If you don't have
>      > a dedicated sniffer, but you have additional motes, there are
>      > sniffer programs available for TelosB and MicaZ.
>      >
>      > If this still doesn't help you can send me your program and I'll try
>      > it on TelosB motes here.
>      >
>      > Cheers,
>      > Urs
>      >
>      >
>      > On 12/03/2010 08:13 AM, 徐瑞涛 wrote:
>      >
>      > Hi Urs:
>      >
>      > I add the following line to the Makefile
>      >
>      > CFLAGS += -DCC2420_DEF_RFPOWER=15 (Because 16 isn't is a valid
>      > value in
>      > the datasheet)
>      >
>      > But it doesn't work, either.
>      > I also increase the send interval to 1024 ms and test again. The
>      > horrible situation remains.
>      >
>      > Thanks for your help.
>      > Looking forward to any tip.
>      > I will try more solution and expect mote receiving correctly
>      > earlier.
>      >
>      > Best Regards,
>      > Ruitao Xu
>      >
>      >
>      > On Fri, Dec 3, 2010 at 2:07 PM, Urs Hunkeler
>      > <urs.hunke...@epfl.ch <mailto:urs.hunke...@epfl.ch>
>     <mailto:urs.hunke...@epfl.ch <mailto:urs.hunke...@epfl.ch>>
>      > <mailto:urs.hunke...@epfl.ch <mailto:urs.hunke...@epfl.ch>
>     <mailto:urs.hunke...@epfl.ch <mailto:urs.hunke...@epfl.ch>>>> wrote:
>      >
>      > Hi,
>      >
>      > One problem that I encountered personally is that sometimes the
>      > Moteiv Tmote Skys seem to have difficulties communicating when they
>      > are too close together (maybe the receiver gets saturated?). If this
>      > is the case, I found that lowering the transmission power helps. You
>      > can try this by adding the following line to the Makefile and
>      > recompiling the application:
>      >
>      > CFLAGS += -DCC2420_DEF_RFPOWER=16
>      >
>      > To ensure that the program is really recompiled, I recommend the
>      > following command sequence:
>      >
>      > make clean && make tmote
>      >
>      > Did you check whether AMSend.send(..) returns any errors?
>      >
>      > Cheers,
>      > Urs
>      >
>      >
>      >
>      > On 12/3/10 4:24 AM, 徐瑞涛 wrote:
>      >
>      >
>      > Hi everyone, It's a strange problem. I tried my best to fix it,
>      > but I
>      > can't.
>      >
>      > First of all, I installed BlinkToRadio under T2 source tree on two
>      > Telosb motes. But two motes didn't have any response both. Three
>      > Leds
>      > never be toggled.
>      >
>      > ps: T2 Source Tree revision is 5244 and last modified at 2010-06-30
>      >
>      > And I want to know the reason: 1) Mote can't send pkt ? 2) Mote
>      > can't
>      > receive pkt ? 3) Mote doesn't work ?
>      >
>      > So, secondly, I change the BlinkToRadio source a little. Make a mote
>      > as sending mote and another as receiving mote. And Leds' denotes
>      > different event:
>      >
>      > Led0: When receiving mote received a pkt., code below: event
>      > message_t* Receive.receive(message_t* msg, void* payload, uint8_t
>      > len){ if (len == sizeof(BlinkToRadioMsg)) { BlinkToRadioMsg*
>      > btrpkt =
>      > (BlinkToRadioMsg*)payload; //setLeds(btrpkt->counter); call
>      > Leds.led0Toggle(); } return msg; }
>      >
>      > Led1: When motes booted successfully! event void Boot.booted() {
>      > call
>      > AMControl.start(); call Leds.led1Toggle(); }
>      >
>      > Led2: When sending mote sended a pkt successfully event void
>      > AMSend.sendDone(message_t* msg, error_t err) { if (&pkt == msg) {
>      > busy = FALSE; if (err == SUCCESS){ call Leds.led2Toggle(); } } }
>      >
>      > Under the configuration above, the running results as follow: 1)
>      > Sending and Receiving motes both start successfully. Because led1
>      > keep on and led2 blinks periodically, it at least also means
>      > that the
>      > sending mote's radio start successfully. And I guess the Receiving
>      > mote's radio start successfully too. 2) Sending mote can send pkt
>      > successfully because of led2 blinks periodically.
>      >
>      > But the question is why the receiving mote's led0 (when it receive a
>      > pkt) doesn't blink. It appears that it can't receive any pkt and
>      > that also can explain why BlinkToRadio doesn't work.
>      >
>      > If any of you have met the similar situation or know how to
>      > solve it,
>      > please help me.
>      >
>      > Best Regards, Ruitao Xu
>      >
>      >
>      >
>      >
>      > --
>      > Be Your Personal Best!
>      >
>      >
>      >
>      >
>      >
>      > --
>      > Be Your Personal Best!
>
>
>
>
> --
> Be Your Personal Best!

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

Reply via email to