[Ns-developers] Traced callbacks in WifiPhy
timo.bingmann at student.kit.edu
Fri Jan 9 04:24:23 PST 2009
On Friday 09 January 2009 13:14:14 Mathieu Lacage wrote:
> On Fri, 2009-01-09 at 13:10 +0100, Timo Bingmann wrote:
> > Hallo Mathieu,
> > i'm running into some ugly problems debugging while the WifiPhy.
> > It started out that I wanted to add another parameter to the
> > WifiPhyStateHelper::m_rxOkTrace(), i believe it was rxPowerDbm or
> > txDuration that i required.
> > That didn't work so good, because TracedCallbacks can have only 4
> > template parameters.
> > So I tried to extend the number of template parameters, but that code
> > was too ...erm extraordinary.
> Maybe the patch in bug 412 would help ? I had forgot about it and am in
> the process of merging it.
I now like the WifiPhyTag idea much better. But still Tags cannot be updated easily? I mean like updating a field rxPowerDbm.
> > My next plan was to make a WifiPhyTag class and tag the packet with
> > lots of useful information collected as it travels through the wifi
> > layers. However tags can only have 16 bytes and cannot be updated, and
> > the tag must be updated in at least two phases: send and receive (e.g.
> > txPower and rxPower).
> Tags can contain any amount of information now.
Ok, someone update the manual.
> > So the final plan is to group all wifi info, that is "WifiMode txMode,
> > WifiPreamble preamble, uint8_t txPower, double snr, ...", into a class
> > (proposal: WifiPhyInfo) that is passed through the functions and also
> > exported to the trace callback. That also fixes the problem of the
> > wifi callback's signature, which throws strange runtime-error if you
> > don't get it right.
> > Good idea or bad idea?
> I think you will be happy with bug 412.
> > Also can I rename the WifiPhy::State SYNC -> RX please? SYNC always
> > makes me think of preamble synchronizing.
> SYNC stands for "synchronized" :)
> If you both with a patch to do so, yes. It would also be nice to extend
> the state machine with a real SYNChronizing state, even if it is not
> used in the current codebase.
That's what I'm currently working at, thus the confusion. However currently I believe I can manage the changes without the extra PreSYNC/PreRX state, which is preferred because it also requires one Schedule() less.
More information about the Ns-developers