> 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
