Please send help requests to the list and not me directly.... Especially in this case since I'm reasonably clueless.
As far as I know UART0 is not implicated with SPI or the radio. USART1 is...maybe...I haven't done any SPI stuff..one of these days. Flash and the radio do share some pins, and I'm not clear what you are doing with the flash. From what I understand of your description, the CRC is bad at the receiving end, which is almost certainly radio transmission bit errors. The only thing I can think of on the transmit end is that there might be an interrupt conflict between UART0 and the radio transmit register loading. Or maybe some electrical interference in the wiring to your sensor. But I don't think there is anything that gets blocked for much longer than single register rd/wr cycles, like for the length of a uart message or something. What program did you use to validate the radio reception? Can you use your offending program and just disable the UART read? It sounds like you started down that path with the fixed data pattern, and still got the bad messages... MS [EMAIL PROTECTED] wrote:
Hi Micheal, Sorry to write to this address but i had a problem with mica2 that I posted in help archives and think you may have the answer. I had a mica2 conected to a digital oximeter through the UART0. The baudrate of the conexion is 4800 baudrate and the sensor sends data at a rate of 1920 bit/s (60 packets per seconds of 4 bytes each one). I merge sensor data into a TOS_Msg packet, and when it is full I send it over the radio. On the other side I have a tipical TOSBase aplication conected to a PC. A lot of packets seems to be lost, but when you dig in you realise that the lost are due to bad CRC code. Digging depper you find that the messaje differs from the original in one "random bit" (statistically taking, some times you get more than one, but in different bytes). To do this I replace the oximeter data with a known pattern. So my first thought was of segmentation fault. I log the SPI SPDR register into the Flash to then check the corresponding values, and everything seems OK!. My only guess now is that the radio and the UART0 share hardware lines. I dont know if this may be related to the prog_miso/mosi UART0 conection. And if this is true I dont know why this doesnt fail in tha case of UART0 comunication with PC and radio transmision. The only difference I see is the low baudrate of 4800 that may block more time the lines, I dont know?? I am pritty sure it is not a sofware problem. And I am sure it is not ambient noise in the RF comunication (I did other test with other aplication and they work fine, no packet is lost at a rate of 30 TOS_Msg packets per second, far from the test that fails), something get mess onboard. thanks in advance, any guess would help -Bill
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
