Hello. I have some problems networking the mica platform. Ill rather enumerate them here:
- I found that the GENERIC_COMM component never initializes the CRC component, I think the problem is on the .desc file.
-The CRC component seems to reject messages that are originated on other motes using the same component. It works fine when I use the generic base station to transmit messages, but there the CRC, I believe, is generated at the PC side. In general when I use GENERIC_COMM to exchange messages between motes I have to disable the crc check in order to make them work, otherwise all the messages are rejected for bad crc.
-Another experiment I did was to use the timer running at 1ms to measure the time delay on packet exchange. Basically I have a mote to transmit a beacon that is returned back by another mote. The "beacon" mote measures the time between the transmission of the message and the reception of its echo by the other mote. Many of the messages where dropped (using a separation between of less than an inch, an external antenna, and max power.) Then I repeated the experiment using a time interrupt every 1 second. This time almost no messages where dropped even at a bigger separation. It seems to me that the transmission is made byte by byte, while the reception is done by having the SPI synchronized (by the preamble) to sample every certain period. Is it possible that the reception side is desynchronized by interrupts appearing in the middle of byte transmissions on the transmitter side? Is it possible to have the communication stack interrupts to have more priority?
-Finally is there any document where I can see what are the uC resources used by each component? (ie interrupts, timer modules, registers, etc.) Im trying to generate a 2 channel PWM signal but it seems that all timers are taken. Im using timer 1 with a slight modification of SPI_BYTE_FIFO and RADIO_TIMING.
Please if someone can clarify me these points I would greatly appreciate it. Thanxs!
Luis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the mica platform,
AM_STANDARD:AM_INIT GENERIC_COMM:COMM_INIT
...
AM_STANDARD:AM_SUB_INIT CRC:PACKET_INIT
From these combinations, we know that the CRC:PACKET_INIT is being called.
2) You are correct in that on the PC the application that injects the message onto the network must generate the CRC. You can also
modify generic_base_high_speed to generate the
crc. On the motes,the CRC Packet component generates it. I don't know what might be going on there.
3) I will send email to Jason Hill on this. (However, he is out of town right now.)
4) Please see platform/mica/include/hardware.h to
see what resources are reserved. (I assume you're using mica because you mentioned generic_base_high_speed.)
-kw
(Thanks to Joe for helping me with this stuff.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I mentioned in my previous post that I'd forward your question that started "Another experiment I did..." to Jason Hill. Here is what Jason had to say:
"It is possible and it does seem that you have exposed a bug? Currently, the low-level radio interrupts to have priority over the timer interrupts. You?d have to investigate why the packet transmission was failing to get to the root cause."
I hope that helps.
-kw
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Kristin, thank you for your help. Regarding point 2, I checked the file CRC.comp and PACKET_INIT is a command that is used by CRC not accepted by it. Instead CRC_PACKET_INIT is the one accepted by CRC. Now the only thing CRC_PACKET_INIT does is to call PACKET_INIT. What happens on this cases?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. I have some problems networking the mica platform. Ill rather enumerate them here:
- I found that the GENERIC_COMM component never initializes the CRC component, I think the problem is on the .desc file.
-The CRC component seems to reject messages that are originated on other motes using the same component. It works fine when I use the generic base station to transmit messages, but there the CRC, I believe, is generated at the PC side. In general when I use GENERIC_COMM to exchange messages between motes I have to disable the crc check in order to make them work, otherwise all the messages are rejected for bad crc.
-Another experiment I did was to use the timer running at 1ms to measure the time delay on packet exchange. Basically I have a mote to transmit a beacon that is returned back by another mote. The "beacon" mote measures the time between the transmission of the message and the reception of its echo by the other mote. Many of the messages where dropped (using a separation between of less than an inch, an external antenna, and max power.) Then I repeated the experiment using a time interrupt every 1 second. This time almost no messages where dropped even at a bigger separation. It seems to me that the transmission is made byte by byte, while the reception is done by having the SPI synchronized (by the preamble) to sample every certain period. Is it possible that the reception side is desynchronized by interrupts appearing in the middle of byte transmissions on the transmitter side? Is it possible to have the communication stack interrupts to have more priority?
-Finally is there any document where I can see what are the uC resources used by each component? (ie interrupts, timer modules, registers, etc.) Im trying to generate a 2 channel PWM signal but it seems that all timers are taken. Im using timer 1 with a slight modification of SPI_BYTE_FIFO and RADIO_TIMING.
Please if someone can clarify me these points I would greatly appreciate it. Thanxs!
Luis
Hi,
1) The GENERIC_COMM component does indeed initialize the CRC component. For the rene platform, in nest/tos/shared/GENERIC_COMM.desc you see:
AM_STANDARD:AM_INIT GENERIC_COMM:COMM_INIT
...
AM_STANDARD:AM_SUB_INIT CRCPACKETOBJ_SIGNAL:PACKET_INIT
In the mica platform,
AM_STANDARD:AM_INIT GENERIC_COMM:COMM_INIT
...
AM_STANDARD:AM_SUB_INIT CRC:PACKET_INIT
From these combinations, we know that the CRC:PACKET_INIT is being called.
2) You are correct in that on the PC the application that injects the message onto the network must generate the CRC. You can also
modify generic_base_high_speed to generate the
crc. On the motes,the CRC Packet component generates it. I don't know what might be going on there.
3) I will send email to Jason Hill on this. (However, he is out of town right now.)
4) Please see platform/mica/include/hardware.h to
see what resources are reserved. (I assume you're using mica because you mentioned generic_base_high_speed.)
-kw
(Thanks to Joe for helping me with this stuff.)
Hi Luis,
I mentioned in my previous post that I'd forward your question that started "Another experiment I did..." to Jason Hill. Here is what Jason had to say:
"It is possible and it does seem that you have exposed a bug? Currently, the low-level radio interrupts to have priority over the timer interrupts. You?d have to investigate why the packet transmission was failing to get to the root cause."
I hope that helps.
-kw
Hello Kristin, thank you for your help. Regarding point 2, I checked the file CRC.comp and PACKET_INIT is a command that is used by CRC not accepted by it. Instead CRC_PACKET_INIT is the one accepted by CRC. Now the only thing CRC_PACKET_INIT does is to call PACKET_INIT. What happens on this cases?