> 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

_______________________________________________
ath5k-devel mailing list
[email protected]
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to