I just committed some tweaks to the estimator. Can you check now? - om_p
On Thu, Oct 21, 2010 at 11:07 PM, Qiu Ying <[email protected]> wrote: >> I would need a little bit more information to help you debug CTP. How >> can I reproduce this bug? > It's easy to reproduce it on my platform(atmega1281+rf230). Use 2 mote > with TestNetwork application, suppose root id is 0, the other is 1. > Start the root first, then start mote 1, the etx changes as follows: > (I add a printf in updateETX(), LinkEstimatorP.nc) > etx=6553 > etx=5906 > etx=5320 > etx=4791 > etx=4314 > etx=3885 > etx=3498 > etx=3150 > etx=2836 > etx=2554 > etx=2300 > etx=2071 > etx=1865 > etx=1679 > etx=1512 > etx=1362 > ... > > but in the reverse power on order(start mote1 then start root), it's OK. > etx=10 > etx=14 > etx=13 > etx=15 > etx=14 > ... > > 2010/10/22 Omprakash Gnawali <[email protected]>: >> On Thu, Oct 21, 2010 at 12:42 AM, qiu ying <[email protected]> wrote: >>> Hi,all >>> I found mote(ctp+4bitle) sometimes failed to send ctp packet as no >>> parent is chosen, even the root is very close the mote. >>> The reason I found is VERY_LARGE_ETX_VALUE is set to 0xffff in >>> tos/lib/net/4bitle/LinkEstimatorP.nc, it is too large maybe, once >>> used in computeETX(), the etx is much larger than ETX_THRESHOLD for a >>> long time due to the EWMA algorithm. SVN r4975 make this >>> change(0xff-> 0xffff), anyone know the reason? >> >> We wanted the largest 16-bit value we could return to indicate an >> invalid ETX. Setting this constant to 0xFF can confuse exceptionally >> large ETX (e.g., ETX=25) as an invalid ETX. >> >> I would need a little bit more information to help you debug CTP. How >> can I reproduce this bug? >> >> - om_p >> > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
