[Tinyos-devel] Lqi and CC2420

[Andreas Koepke]

This is how the diff would look like:
      interface CC2420Packet;
becomes
      interface LinkCost;

     uint16_t adjustLQI(uint8_t val)

moved to separate component (together with the accessor functions)

***************
*** 336,342 ****
     event message_t* Receive.receive(message_t* msg, void* payload, 
uint8_t len) {
       lqi_beacon_msg_t* bMsg = (lqi_beacon_msg_t*)payload;
       am_addr_t source = call AMPacket.source(msg);
!     uint8_t lqi = call CC2420Packet.getLqi(msg);

--- 330,336 ----
     event message_t* Receive.receive(message_t* msg, void* payload, 
uint8_t len) {
       lqi_beacon_msg_t* bMsg = (lqi_beacon_msg_t*)payload;
       am_addr_t source = call AMPacket.source(msg);
!     uint16_t linkcost = call LinkCost.getCost(msg);

This is where it has most impact: debug can not report raw LQI values 
anymore...


Philip Levis:
> 
> On Feb 28, 2008, at 8:36 AM, Andreas Koepke wrote:
> 
>> I'd like to make MultiHopLqi independent of the CC2420 radio. Anybody 
>> against it?
>>
>> The idea is to introduce a separate component LinkCostC that is 
>> specific for each radio chip and computes a suitable LinkCost. 
>> Eventually we could think about using the LinkEstimator interface in 
>> MultihopLqi...
> 
> I'm currently the maintainer of MultihopLqi. It's part of the code that 
> net2 supports.
> 
> I'd rather avoid churn on it. MultihopLqi isn't perfect, but it's 
> something people know and understand. One of the recurring issues in 1.x 
> was the tension between continual improvement and having something which 
> was stable. E.g., if mlqi starts changing, then we might get people 
> stuck on 2.0.2 because they depend on the 2.0.2 implementation.
> 
> Instead, if this is something you want to pursue, I'd recommend forking 
> the code into a new protocol. It will, after, all, be different. If you 
> want it to be in tos/lib rather than tinyos-2.x-contrib, you should talk 
> to Om about joining net2. Net2 is currently the only WG with network 
> protocols under its charter. More protocol options are always good.
> 
> Phil
>