Hi Omprakash,
Thanks very much for the reply. I also have a small irrelevant
question here. I am doing some experiments about the performance of
the new 4bit link estimator using tmotes, which use Chipcon CC2420
radio chip. I noticed in the chips/cc2420/packet/CC2420PacketP.nc, a
channel is considered of high quality when the LQI value is greater
then 105 (line 107). That's where the white_bit come from. I am
wondering why LQI > 105 indicates a high channel quality? Is there
any physical or empirical reason behind the value?
Tao
On Mon, Aug 11, 2008 at 5:17 PM, Omprakash Gnawali <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 11, 2008 at 5:10 PM, Tao Liu <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I am studying the 4bitle link estimator in the TinyOS 2. In the
>> tos/lib/net/4bitle/LinkEstimatorP.nc (line 647), the 4bit estimator
>> signals the CompareBit.shouldInsert() event when it received a beacon
>> message from a new neighbor when there is no room left in the neighbor
>> table, and the only implementation of CompareBit.shouldInsert I can
>> find is in the tos/lib/net/ctp/CtpRoutingEngineP.nc, starting from
>> line 634:
>>
>> /* This should see if the node should be inserted in the table.
>> * If the white_bit is set, this means the LL believes this is a good
>> * first hop link.
>> * The link will be recommended for insertion if it is better* than some
>> * link in the routing table that is not our parent.
>> * We are comparing the path quality up to the node, and ignoring the link
>> * quality from us to the node. This is because of a couple of things:
>> * 1. because of the white bit, we assume that the 1-hop to the candidate
>> * link is good (say, etx=1)
>> * 2. we are being optimistic to the nodes in the table, by ignoring the
>> * 1-hop quality to them (which means we are assuming it's 1 as well)
>> * This actually sets the bar a little higher for replacement
>> * 3. this is faster
>> * 4. it doesn't require the link estimator to have stabilized on a link
>> */
>> event bool CompareBit.shouldInsert(message_t *msg, void* payload,
>> uint8_t len, bool white_bit) {
>> bool found = FALSE;
>> uint16_t pathEtx;
>> //uint16_t linkEtx = evaluateEtx(0);
>> uint16_t neighEtx;
>> int i;
>> routing_table_entry* entry;
>> ctp_routing_header_t* rcvBeacon;
>>
>> if ((call AMPacket.type(msg) != AM_CTP_ROUTING) ||
>> (len != sizeof(ctp_routing_header_t)))
>> return FALSE;
>>
>> /* 1.determine this packet's path quality */
>> rcvBeacon = (ctp_routing_header_t*)payload;
>>
>> if (rcvBeacon->parent == INVALID_ADDR)
>> return FALSE;
>> /* the node is a root, recommend insertion! */
>> if (rcvBeacon->etx == 0) {
>> return TRUE;
>> }
>>
>> pathEtx = rcvBeacon->etx; // + linkEtx;
>>
>> /* 2. see if we find some neighbor that is worse */
>> for (i = 0; i < routingTableActive && !found; i++) {
>> entry = &routingTable[i];
>> //ignore parent, since we can't replace it
>> if (entry->neighbor == routeInfo.parent)
>> continue;
>> neighEtx = entry->info.etx;
>> //neighEtx = evaluateEtx(call
>> LinkEstimator.getLinkQuality(entry->neighbor));
>> found |= (pathEtx < neighEtx);
>> }
>> return found;
>> }
>>
>> According to the comment, this event should do the comparison based on
>> the white_bit argument. However, the actual code here does not take
>> the white_bit into account. Instead, it just compare the path ETX
>> value of the new beacon message with the neighbors that is already in
>> the routing table (different from the neighbor table in the link
>> estimator).
>>
>> When the 4bit link estimator signals the CompareBit.shouldInsert
>> event, the white_bit is set to true if the LQI value in the message
>> header indicates the wireless channel quality is high; false
>> otherwise. Can somebody explain why the white_bit is ignored here? Or
>> it's just I missed something?
>>
>
> You did not miss anything :)
>
> We found this problem about two weeks ago but it was too close to the
> 2.1 release and did not update the code. The comparison statement
> disappeared when we did code refactoring as we moved from experiments
> to code in the repository.
>
> I am redoing some of the experiments before I update the code so stay tuned.
>
> - om_p
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
