I have MICA hardware, and I am trying to run the Router (router_base/router/router_test) application, but I am experiencing something what looks like a radio communication problem. First shortly about the things that already work:
- toscheck completes without error
- all the testing steps described in the Tutorial Lesson 0 (mica_hardware_verify) work
- cnt_to_leds works
- listen.java prints a bit more then what is stated at http://today.cs.berkeley.edu/tos/test.html, but I think it is still OK:
mania:~/nest/tools$ java listen COM1
listen started
printing all ports...
- COM1
- COM2
- LPT1
- LPT2
done.
baud rate: 9600
data bits: 8
stop bits: 1
parity: 0
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
...and it stops and waits here for data from the serial port
- oscilloscope works: red LED is steady, yellow LED blinks, and "java listen" prints:
- SerialForwarder works (Pckts Read is increasing ~ 1/second)
- Oscilloscope GUI works (however, could not connect both the serial port and the sensor board at the same time - I use the MICA programmer board for serial connection)
- generic_base/generic_base_high_speed + cnt_to_leds_and_rfm: LEDs are blinking on the sender, but "java listen" and SerialForwarder do not see anything on the serial port - should they?
- cnt_to_leds_and_rfm + rfm_to_leds: steadily works from a distance of about half meter
I am using the TinyOS distribution from the 02/05/2002 NEST PI meeting, patched with the POT.c fix from the SourceForge. My devel environment is Win2k.
To run the Router application, I upload router/router into an indermediate node, and router/router_base into the base node. Red LED on the base node blinks as it sends out the route update messages.
The intermediate node can easily receive the first message from ~half meter distance, but the consecutive messages are difficult to receive, even from 1-2 centimeters. I had put some debug output (LED toggling:) to the networking code, and saw that the messages arrive with bad CRC. What is more interesting, not all messages are equal: the ones, which should turn on the green LED, are easier to receive (again works from the normal distance), only the turn-off messages have problems.
If I start with an inverse LED setting on the init, the behavior also inverts itself, at least for me it means that the problem is not connected to the power consumption of the LED, rather to the inner state of the protocol in the intermediate node.
But this is the point where I do not have more ideas to continue with..
Does the problem arise also for somebody else?
Thx for any suggestions,
--
Stefan Bartok
ISIS, Vanderbilt University
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you using the built in antenna or the "can" antenna? With the built in antenna, the range is ~0.5-1 meter in bad radio interference environments (900mhz cordless phones, etc...). With the external antenna, the range significantly increases. Remember when putting an external antenna on the mote to remove R28. If you don't have any "can" antennas, a piece of wire ~8.2cm long works just as well. The antenna goes in the hole directly to the right of R28.
-Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have MICA hardware, and I am trying to run the Router (router_base/router/router_test) application, but I am experiencing something what looks like a radio communication problem. First shortly about the things that already work:
- toscheck completes without error
- all the testing steps described in the Tutorial Lesson 0 (mica_hardware_verify) work
- cnt_to_leds works
- listen.java prints a bit more then what is stated at http://today.cs.berkeley.edu/tos/test.html, but I think it is still OK:
mania:~/nest/tools$ java listen COM1
listen started
printing all ports...
- COM1
- COM2
- LPT1
- LPT2
done.
baud rate: 9600
data bits: 8
stop bits: 1
parity: 0
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
...and it stops and waits here for data from the serial port
- oscilloscope works: red LED is steady, yellow LED blinks, and "java listen" prints:
listen started
printing all ports...
- COM1
- COM2
- LPT1
- LPT2
done.
baud rate: 9600
data bits: 8
stop bits: 1
parity: 0
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
7e 00 0a 7d 01 00 70 03 01 00 1b 01 1b 01 1b 01 1b 01 1b 01 19 01 17 01 17 01 17 01 18 01 00 00 00 00 00 00
7e 00 0a 7d 01 00 7a 03 01 00 19 01 1a 01 1b 01 1b 01 1c 01 1c 01 1c 01 1b 01 1b 01 1b 01 00 00 00 00 00 00
7e 00 0a 7d 01 00 84 03 01 00 1c 01 1b 01 1b 01 1b 01 1b 01 1b 01 1b 01 1b 01 1b 01 1b 01 00 00 00 00 00 00
...
- SerialForwarder works (Pckts Read is increasing ~ 1/second)
- Oscilloscope GUI works (however, could not connect both the serial port and the sensor board at the same time - I use the MICA programmer board for serial connection)
- generic_base/generic_base_high_speed + cnt_to_leds_and_rfm: LEDs are blinking on the sender, but "java listen" and SerialForwarder do not see anything on the serial port - should they?
- cnt_to_leds_and_rfm + rfm_to_leds: steadily works from a distance of about half meter
I am using the TinyOS distribution from the 02/05/2002 NEST PI meeting, patched with the POT.c fix from the SourceForge. My devel environment is Win2k.
To run the Router application, I upload router/router into an indermediate node, and router/router_base into the base node. Red LED on the base node blinks as it sends out the route update messages.
The intermediate node can easily receive the first message from ~half meter distance, but the consecutive messages are difficult to receive, even from 1-2 centimeters. I had put some debug output (LED toggling:) to the networking code, and saw that the messages arrive with bad CRC. What is more interesting, not all messages are equal: the ones, which should turn on the green LED, are easier to receive (again works from the normal distance), only the turn-off messages have problems.
If I start with an inverse LED setting on the init, the behavior also inverts itself, at least for me it means that the problem is not connected to the power consumption of the LED, rather to the inner state of the protocol in the intermediate node.
But this is the point where I do not have more ideas to continue with..
Does the problem arise also for somebody else?
Thx for any suggestions,
--
Stefan Bartok
ISIS, Vanderbilt University
The problem is solved by platform/mica/SPI_BYTE_FIFO.c, version 1.5.
Download it from here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tinyos/nest/tos/platform/mica/SPI_BYTE_FIFO.c
--
Stefan Bartok
Are you using the built in antenna or the "can" antenna? With the built in antenna, the range is ~0.5-1 meter in bad radio interference environments (900mhz cordless phones, etc...). With the external antenna, the range significantly increases. Remember when putting an external antenna on the mote to remove R28. If you don't have any "can" antennas, a piece of wire ~8.2cm long works just as well. The antenna goes in the hole directly to the right of R28.
-Joe
We do not use any external antenna as we do not have any, and did not wanted to play around with the soldering iron. :)
But the problem was not this type anyway: the range was OK with the CNT_TO_RFM app, and was not with the router app.
It seems that it was really caused by the sw error that was fixed in the new SPI_BYTE_FIFO.c - at least now it works for me..
--
Stefan Bartok