I am using linux as my platform and is trying to run the router application on the mica motes. I have both pathes POT.c and SPI_BYTE_FIFO.c installed. My router_test application is running smoothly. But I am not able to do the communication b/w the motes while running the router application. I have downloaded router base on one mote and the router application on 2 others. I put the base into the serial port and run listen , but i am not able to get any data on the screen. The red light of the base station mote and the green led of the router mote blinks , but no data comes on t he screen while using the listen .java..
THe out put is like this
[root@Friday tools]# java listen COM1
listen started
printing all ports...
- LPT1
- COM1
- COM2
- COM3
- COM4
done.
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
The data stops here. I am not able to see any transmission.
How is the data being sensed??
Can anyone please give some info about the route application
thanking you
kiran simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What version of TinyOS are you running? If its as recent as 6.0, can you sent your output to 'toscheck'. Since your router test application ran fine, I doubt there's a problem in your setup -- just want to make sure.
Thanks.
-kw
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-04-20
Hi,
Thank you for your reply.. There is no error while running the toscheck. I am using the tinyos version 6.0 (latest).. Also all my colleagues are also having the same problem
kiran
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-04-20
Hi, folks. To add the comment above, we have verified hardware, toscheck, and RF component using mica_hearware_verify. Everything checks out. It is strange that base mote broadcast with red blink and remote mote only blinks green when hears the broadcast from the base station. I'm not sure but it appears that we are losing all packets due to the CRC check. We have not verify this fact however. It is strange that router_test will work but not the router app. My understatnding is that both apps are identical except router_test sends dummy data back. Unless some one call tell me difference in two apps that will cause such odd behavior, we are really unsure how to proceed. Hope some one out there can give us some pointer. By the way, both Linux and win2000 platform cause same issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, There I posted a message some time ago about an issue with the CRC. It seems that the CRC is not correctly calculated due to an error on the packet length calculation. The transmissions originated from the base_station are accepted since the CRC is calculated on the PC rather than in the mote. But, any mote using the generic_comm component was unable to succesfully transmit a packet since the receiving mote (using generic_comm too) rejected the packet for bad CRC. So in order to still be able to communicate I just disable it (on the CRC.c file). After that a new CRC.c was posted on the CVS that had the disable/enable feature. Finally some days ago a brand new radio stack was posted that has the CRC problem fixed. I havent personally try it. The only thing is that it has a different name and thus you will have to modify some .desc files. Other issues that you might want to keep an eye on are that the random generator for the mac layer is not initialized, as well as the crc component itself, this are rather small details that might let communication to happen but not always in the way you expected. Hope this helps.
Luis Montestruque
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe that there has been a fix to the CRC code made within the last month. You might try that and see if it helps. You probably already know this but there are two choices for updating your code: do a CVS download from sourceforge (directions are on sourceforge) or get the tinyos update tarball from the tinysos website
(webs.cs.berkeley.edu/tos/).
In the meantime, I'll ask the team more about this.
Thanks very much.
-kw
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using linux as my platform and is trying to run the router application on the mica motes. I have both pathes POT.c and SPI_BYTE_FIFO.c installed. My router_test application is running smoothly. But I am not able to do the communication b/w the motes while running the router application. I have downloaded router base on one mote and the router application on 2 others. I put the base into the serial port and run listen , but i am not able to get any data on the screen. The red light of the base station mote and the green led of the router mote blinks , but no data comes on t he screen while using the listen .java..
THe out put is like this
[root@Friday tools]# java listen COM1
listen started
printing all ports...
- LPT1
- COM1
- COM2
- COM3
- COM4
done.
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
baud rate: 19200
data bits: 8
stop bits: 1
parity: 0
The data stops here. I am not able to see any transmission.
How is the data being sensed??
Can anyone please give some info about the route application
thanking you
kiran simon
Hi,
What version of TinyOS are you running? If its as recent as 6.0, can you sent your output to 'toscheck'. Since your router test application ran fine, I doubt there's a problem in your setup -- just want to make sure.
Thanks.
-kw
Hi,
Thank you for your reply.. There is no error while running the toscheck. I am using the tinyos version 6.0 (latest).. Also all my colleagues are also having the same problem
kiran
Hi, folks. To add the comment above, we have verified hardware, toscheck, and RF component using mica_hearware_verify. Everything checks out. It is strange that base mote broadcast with red blink and remote mote only blinks green when hears the broadcast from the base station. I'm not sure but it appears that we are losing all packets due to the CRC check. We have not verify this fact however. It is strange that router_test will work but not the router app. My understatnding is that both apps are identical except router_test sends dummy data back. Unless some one call tell me difference in two apps that will cause such odd behavior, we are really unsure how to proceed. Hope some one out there can give us some pointer. By the way, both Linux and win2000 platform cause same issue.
Hi, There I posted a message some time ago about an issue with the CRC. It seems that the CRC is not correctly calculated due to an error on the packet length calculation. The transmissions originated from the base_station are accepted since the CRC is calculated on the PC rather than in the mote. But, any mote using the generic_comm component was unable to succesfully transmit a packet since the receiving mote (using generic_comm too) rejected the packet for bad CRC. So in order to still be able to communicate I just disable it (on the CRC.c file). After that a new CRC.c was posted on the CVS that had the disable/enable feature. Finally some days ago a brand new radio stack was posted that has the CRC problem fixed. I havent personally try it. The only thing is that it has a different name and thus you will have to modify some .desc files. Other issues that you might want to keep an eye on are that the random generator for the mac layer is not initialized, as well as the crc component itself, this are rather small details that might let communication to happen but not always in the way you expected. Hope this helps.
Luis Montestruque
I believe that there has been a fix to the CRC code made within the last month. You might try that and see if it helps. You probably already know this but there are two choices for updating your code: do a CVS download from sourceforge (directions are on sourceforge) or get the tinyos update tarball from the tinysos website
(webs.cs.berkeley.edu/tos/).
In the meantime, I'll ask the team more about this.
Thanks very much.
-kw