[CUWiN-Dev] Transmit power control / RSS measurement

Jeongkeun Lee jklee at mmlab.snu.ac.kr
Tue May 2 09:54:03 CDT 2006


Dave,

Now I can see the RSSI and average RSSI on UDP packets with getsockopt() in
an application program. I had to touch the Atheros driver and a number of
NetBSD header and c files implementing networking functions such as
udp4_realinput() and ip_ctloutput().

And I wrote some codes to pass txpower value from the application program to
the driver through setsockopt() API, and I could see the value passed to the
driver by printf. Then, I loaded the new txpower value into the descriptor
by ath_hal_setuptxdesc(). 

         ath_hal_setuptxdesc(ah, ds
                , pktlen                /* packet length */
                 , hdrlen                /* header length */
                 , atype                 /* Atheros packet type */
                 , ni->ni_txpower        /* txpower */
                 , txrate, try0          /* series 0 rate/tries */
                 , keyix                 /* key cache index */
                 , sc->sc_txantenna      /* antenna mode */
                 , flags                 /* flags */
                , ctsrate               /* rts/cts rate */
                 , ctsduration           /* rts/cts duration */

The txpower parameter 'ni->ni_txpower' is replaced by the new value
'txpower_set'. Because the type of ni->ni_txpower is u_int16_t and its value
was zero, I have tested with various txpower_set values: from 0 to 50,
unsigned short.
But the RSSI at the receiver did not show any change besides usual 1~2 dB
fluctuation. When txpower_set was set to 80 and 100, there was no received
packet (from the power controlled transmitter) at the receiver.
 When hw.ath0.tpscale was controlled, the receiver's RSSI demonstrated
correlated change regardless of the descriptor value, txpower_set, given by
ath_hal_setuptxdesc(). 

Do you any idea about this?

Thank you so much for your helpful answers.

-- JK

> -----Original Message-----
> From: cu-wireless-dev-bounces at lists.cuwireless.net [mailto:cu-wireless-
> dev-bounces at lists.cuwireless.net] On Behalf Of David Young
> Sent: Monday, April 24, 2006 5:44 AM
> To: cu-wireless-dev at cuwireless.net
> Subject: Re: [CUWiN-Dev] Transmit power control / RSS measurement
> 
> On Fri, Apr 21, 2006 at 06:00:53PM +0900, Jeongkeun Lee wrote:
> > Dave,
> >
> > Any guidance (or samples codes) on per-packet TPC will be highly
> > appreciated.
> 
> You will have to write the code.  You need to pass the transmit power
> to the driver with either sendmsg() or setsockopt().  The driver has
> to see the transmit power (which will probably be a m_tag-type label
> on the mbuf that contains the packet to transmit) and put it into the
> transmit descriptor.  In the Atheros driver, the transmit power is
> loaded into the descriptor by ath_hal_setuptxdesc():
> 
>         ath_hal_setuptxdesc(ah, ds
>                 , pktlen                /* packet length */
>                 , hdrlen                /* header length */
>                 , atype                 /* Atheros packet type */
>                 , ni->ni_txpower        /* txpower */
>                 , txrate, try0          /* series 0 rate/tries */
>                 , keyix                 /* key cache index */
>                 , sc->sc_txantenna      /* antenna mode */
>                 , flags                 /* flags */
>                 , ctsrate               /* rts/cts rate */
>                 , ctsduration           /* rts/cts duration */
> 
> > And I'm also trying to get a per-packet RSS measurement.
> > "tcpdump -ne -y ieee802_11_radio -i ath0" is helpful, but it was not
> easy to
> > get RSS for a specific packet. For example, I want to know the RSS of a
> > packet whose payload contains specific contents.
> 
> Filtering based on payload contents might be tricky.  Is the payload a
> fixed offset from the start of the packet?  Do you need to find the RSS
> in real-time?  This question might be more appropriate for the tcpdump
> mailing list.
> 
> If you want to see the RSS on UDP packets in an application program,
> then the best way may be to pass information from the wireless driver
> to the application.  The driver could load the RSS into an m_tag label
> that your socket receives through recvmsg().
> 
> Dave
> 
> --
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev



More information about the CU-Wireless-Dev mailing list