Some thoughts.... First I would make sendPacket() a task rather than calling it directly from the two events. I suspect that each of those events is a task as well -- I know Timer.fired() in T1 is -- but it makes the partitioning a bit cleaner.
Second, I wonder if printf() is corrupting something? The simplest thing would be to just toggle an LED when you get a bad CRC just to make sure. With a little more pain, you could implement a separate serial message for reporting. One would expect parts of the header and regular CRC to get corrupted if it was a radio or hardware problem. And you have no way of counting how many messages fail at that level. Perhaps add a sourceID and serial number to each message so you can keep track? Otherwise the code looks ok to me... MS Alan Marchiori wrote: >> So it seems that you have multiple base-stations? >> Or how are you getting log messages from different motes? > > there are no base stations or every mote is a base station, depending > how you view it. It is a testbed configuration where all motes have > serial forwarders connected and I connect to all of them to receive > printf messages. Every mote both transmits and receives. > >> I have never checked the internal integrity of messages >> but have also not noticed any glaring bit errors in >> "normal" use. >> >> Anyway...KISS...I would reduce everything to the simplest >> configuration with the most basic program, no queuing, and >> probably just the default payload size. Start with one >> re-mote and one base and then scale up. Try using known >> message content as well as random. Ramp up the speed. >> All the usual... It could be that you have a loose pointer >> in your program that corrupts the message before transmission. > > I created a version without queuing and still see similar error rates. > I then modified the code to send out a constant bit pattern (all > 0xa55a) and then print out the received values in the case of an > error, here are the first two I saw after about 60k received packets > (right around a uint16 rollover....): > > 2011-04-14 16:30:59,070 - printf - INFO - (9005): CRC ERROR: 725a b8b8 > 6ab8 9ce9 15ff 8ba9 7b97 b8de 4e7 7847 714e 7d4e cd43 cd42 cde3 cd43 > 2011-04-14 16:31:41,620 - printf - INFO - (9005): CRC ERROR: a55a a55a > a55a a55a a55a a55a 665a 66cc dec6 6756 464e 6655 6666 c66f ee66 d55d > > the first one is total garbage, the second is more interesting that it > starts out as correct (a55a) and then on the 7th byte becomes corrupt. > > The new code is at: > http://thor.mines.edu/trac/attachment/wiki/Projects/Crc/crcAppQueueless.nc > > If anyone can see anything wrong with this code, I'd be very > interested to solve/better understand this problem. > > Thanks, > Alan > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
