> thats a very good point! if everything was calibrated properly and all delays > taken into account *exactly* that would cause us to go thru a merge all the > time, on every received beacon. i think we have to take that into account, > for different bitrates. what about something like: > > timestamp >= ( mactime + (24 * 8 / beacon_phy_rate_in_mbps )) Looks reasonable, though I'm not entirely sure how we defined 'mactime' and whether it is at the first data or the first phy symbol. I think it's at the first data symbol which makes this correct. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part