This problem has been seen when the application level performs a large amount of computation inside its message arrival event. This exposes a race condition in the lower level components. The result is that the next packet received is garbled. This should be fixed in the lower level.
However, it can be avoid by performing long-running computation inside of application tasks. Jason -----Original Message----- From: Xiaoyan Li [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 7:00 PM To: [EMAIL PROTECTED] Subject: [tinyos-users@mm] possible problem with GENERIC_COMMU There seems to be a problem with the GENERIC_COMMU module. In this module: * RFM module is responsible for receiving bits, it upcalls SEC_DED_RADIO_BYTE module for each bit it gets * SEC_DED_RADIO_BYTE module is responsible for receiving byte, it upcalls PACKETOBJ module for each byte it gets * PACKETOBJ module is responsible for receiving packet. So, it will accumulate the bytes and decide the packet boundary according to the count. When it detects a packet, should upcall the upper layer (AM module) and ALSO inform the lower SEC_DED_RADIO_BYTE module about the completion of a packet, which will then tell the RFM module to start looking for start symbol of a new packet. The problem is, PACKETOBJ module delays the informing lower layer about the packet completion until the upper layer modules finish processing the received packet. When this processing takes too long, RFM and SEC_DED_RADIO_BYTE module will keep on getting bytes and later on mess up the PACKETOBJ module state. One way we could do with this is to add another interaction between PACKETOBJ and SEC_DED_RADIO_BYTE module. When PACKETOBJ detects a packet, use this command to inform the SEC... module immediately
