Re: [Madwifi-devel] DFS status in Madwifi
Status: Beta
Brought to you by:
otaku
From: Brett W. <Bre...@el...> - 2009-06-30 01:19:15
|
Hello Benoit, I have been looking at ETSI EN 301 893 carefully for a while now and it seems that dynamic TPC is required, but only in cases where one wants to transmit with the maximum allowed Tx power. If TPC (dynamic) is not implemented then the maximum power that one is allowed to Tx with is reduced only by 3dB. So, implementing dynamic TPC would only benefit those applications requiring higher powers (and arguably 3dB is not a huge benefit anyway). FCC regulations also require a 3dB reduction when not TPC is implemented. (Of course both FCC and ETSI have a low power frequency band at 5150-5250MHz where neither DFS nor TPS are required) What does seem to be even more important for high Tx power applications is DFS. The madwifi DFS branch seems to be implementing DFS master with radar detection for the case of an AP, or DFS slave device for the case of a STA. However, ETSI requires that DFS slave devices without radar detection reduce their Tx power limits by a further 7dB (in the highest Tx power frequency band). So again for those applications requiring the highest Tx power this is an even bigger limitation than not implementing TPC. (Note FCC does not limit the Tx power in this case). >From what I can see of the DFS branch, when configured as a STA then we really can have a slave device with radar detection, but the problem is that the current madwifi does not implement any notification of radar detection event to the master (i.e. AP). So, it seems to me not particularly useful to detect a radar and stop transmitting, but not being able to notify the AP to change channel. 802.11h provides a mechanism to do this, and thereby implement a slave device with radar detection, which would benefit those applications requiring high Tx power. I have been working on modifying the madwifi DFS branch to implement this functionality with some success so far, but this is still a work in progress. I would be interested to hear if this functionality would be of benefit to others out there... Brett. > -----Original Message----- > From: Benoit PAPILLAULT [mailto:ben...@fr...] > Sent: Tuesday, 30 June 2009 7:55 AM > To: Pavel Roskin > Cc: Pommnitz Jörg; mad...@li... > Subject: Re: [Madwifi-devel] DFS status in Madwifi > > Hello there, > > Right, not all the DFS code has been merged to trunk and shame on me, > I still have not found the time for month, to do this work. I saw > recent effort from Pavel in order to reduce differences between trunk > and madwifi-dfs and I'd like to thank him about this work since it was > one of the reason why I failed to merge the code (I'm not an expert > with svn merge .... ). I have no short term plan to work on DFS but > would be happy to answer questions about it, so feel free to bug me if > you need help. I have written an internal document about the > mathematic aspect of the DFS pulse analysis algorithm and some way to > enhance it (to be more reliable). > > BTW, I'm still not sure TPC (the DFS companion) is implemented > correctly. Does DFS/TPC regulation requirements requires a dynamic > adaptation of the TX power or not? Said it in another : does settings > the TX power with iwconfig is enought to say that the driver is > compliant with TPC. I'm mainly thinking about ETSI EN 301 893 and FCC > Part 15 here. > > Regards, > Benoît > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkpJOEgACgkQOR6EySwP7oLOlgCdEeIAURUm/kq2CJPbIQ1EvOPq > YBYAoKrq6iwQoD/9upXOcFtliNrBQY/I > =DhD4 > -----END PGP SIGNATURE----- > > > -------------------------------------------------------------------------- > ---- > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > > |