@dty
Yes, you might be right about overloading the MCU with interrupts. It doesn't look like this though as it seems to always be the same few devices which suffer the *INCOMPLETEs and I think this seems to point more towards a signal/CC1101 problem. It could be though that these devices send a burst of consecutive messages, causing an overload of interrupts. I'm really not sure yet. The alternative approaches in your firmware should help with troubleshooting.
Yes, we're using the synchronous clock approach. The RFBee has an Atmega168/328 running at 8Mhz (3.3V). There are two different versions of the RFBee in circulation; v1.1 has the 168 with an internal clock that can be tweaked via OSCCAL, v1.2 has the 328 with double the memory, but uses an external clock.
Dan
Yes, you might be right about overloading the MCU with interrupts. It doesn't look like this though as it seems to always be the same few devices which suffer the *INCOMPLETEs and I think this seems to point more towards a signal/CC1101 problem. It could be though that these devices send a burst of consecutive messages, causing an overload of interrupts. I'm really not sure yet. The alternative approaches in your firmware should help with troubleshooting.
Yes, we're using the synchronous clock approach. The RFBee has an Atmega168/328 running at 8Mhz (3.3V). There are two different versions of the RFBee in circulation; v1.1 has the 168 with an internal clock that can be tweaked via OSCCAL, v1.2 has the 328 with double the memory, but uses an external clock.
Dan
Comment