Bug 627 - Jakes Propagation Loss Model doesn't properly calculate signal loss
Jakes Propagation Loss Model doesn't properly calculate signal loss
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3-dev
Mac Intel Mac OS
: P5 normal
Assigned To: Mathieu Lacage
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-07 16:25 UTC by Trevor Bosaw
Modified: 2009-07-13 14:46 UTC (History)
2 users (show)

See Also:


Attachments
simple script to set up a wifi model and print if packets are received (7.37 KB, application/octet-stream)
2009-07-07 16:25 UTC, Trevor Bosaw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Trevor Bosaw 2009-07-07 16:25:56 UTC
Created attachment 517 [details]
simple script to set up a wifi model and print if packets are received

I'm using a simple point to point wifi setup, with a jakes propagation loss model between two nodes.  It seems that regardless of the settings I put into the loss model, the received signal is always either 'nan' or 0.  I have attached a sample script to show this behavior (logging via the terminal should be turned on).

I have also found that in the source code for the propagation loss model, if you add this print statement to the constructor:

	JakesPropagationLossModel::JakesPropagationLossModel ()
	{
		DoConstruct ();	
		printf("osc: %d, ray: %d\n",m_nOscillators,m_nRays);
	}

Both these values won't necessarily be what they should be.  (For me it says m_nOscillators is 0, and m_nRays is 3, although rays should be 1 and oscillators should be 4)  Also, in jakes-propagation-loss-model.h (lines 127-128), if the declaration of these two variables are switched.  So instead of:

			uint8_t m_nRays;	
			uint8_t m_nOscillators;		

they are switched to this:

			uint8_t m_nOscillators;	
			uint8_t m_nRays;	

Then the print statement will switch the values of the variables (so for me m_nOscillators is 3 and m_nRays is 0).
Comment 1 Trevor Bosaw 2009-07-08 14:55:48 UTC
With some testing, it appears that the error is in the DoConstruct() function placed within the constructor for JakesPropagationLossModel.  DoConstruct() uses m_nRays and m_nOscillators, neither of which has fully been instantiated at this point (valgrind shows a memory fault when Do_Construct is in the constructor, but the memory fault disappears when references to m_nRays and m_nOscillators are changed to local variables in DoConstruct)

It looks like the rest of the propagation models wait to do calculations until the DoCalcRxPower function, so perhaps move this code there?

Comment 2 Tom Henderson 2009-07-08 23:47:05 UTC
The problem is that attributes are assigned after the constructor finishes, and values are not available when DoConstruct() is called.  

Another possible solution is to schedule DoConstruct to occur at Simulator::Now() time, or to call DoConstruct from a setter function that sets the attribute m_nOscillators.

Assigning to Mathieu...
Comment 3 Mathieu Lacage 2009-07-13 03:58:25 UTC
changeset: 7555c9a0564b

please, can you verify that the bug is fixed for you ?
Comment 4 Trevor Bosaw 2009-07-13 14:46:01 UTC
Yes, it appears that the bug has been fixed.