[Energy] RV-battery model: No output when creating a trace connect for Remaining Energy

[David]

Hi there,

I tried to get the remaining Energy for an RV-Battery installed on a node. That parameter is not set by default, so I modified the code. The build is ok but no information is shown while executing. I am wondering if I forgot something on the topology file, or either of the battery's design files (.cc and .h).

What I included is:

1.- On the RV battery header file:

TracedValue<double> m_remainingEnergyJ;

2.- On the RV battery cc file:

    .AddTraceSource ("RemainingEnergy",

                     "Remaining energy at RVEnergySource.",

                     MakeTraceSourceAccessor (&RvBatteryModel::m_remainingEnergyJ),

                     "ns3::TracedValue::DoubleCallback")

2.1- Also used a function to pick-up the variable:

double

RvBatteryModel::GetRemainingEnergy (void)

{

  NS_LOG_FUNCTION (this);

  UpdateEnergySource ();

  m_remainingEnergyJ= m_alpha * GetSupplyVoltage () * m_batteryLevel;

  return m_remainingEnergyJ;

}

3.- And finally, on my topology file:

void

RemainingEnergy ( double oldValue, double remainingEnergy)

{

        NS_LOG_UNCOND (Simulator::Now ().GetSeconds () << "s Current remaining energy = " << remainingEnergy << "J - ");        

}

[...]

Ptr<RvBatteryModel> rvBatteryPtr = DynamicCast<RvBatteryModel> (sources.Get (1));

rvBatteryPtr->TraceConnectWithoutContext("RemainingEnergy", MakeCallback (&RemainingEnergy));

I have double-checked the default TraceSources available on RV and Li-ion battery models and the coding looks pretty similar. In all of them, the desired variable gets updated in other functions. I guess the mistake is on the RV battery cc model file: How should I set the value of the m_remainingEnergyJ there? 

Thanks in advance,

David.

[Tommaso Pecorella]

Hi,

all is right, except for one thing.

m_remainingEnergyJ is only updated if you call GetRemainingEnergy, basically making the TraceSource pointless.

A TraceSources is handy because when the variable is updated, the callback is automatically fired. However, you have to update the value, or no callback will be fired.

I'd say that you should update it when one of the 3 components change. In this way you'll have the trace working.

Cheers,

T.

[David]

Night Tommaso,

once again thanks for such a smooth reply. Understood, fixed and working. 

But I found a discrepancy with all the info given by the callbacks. The output, at the end of the simulation, is:

9.00087s Total energy consumed by radio = 8.72442J - ID: 1  

9.00087s Current battery level = 98.6926% - ID: 1  

9.00087s Current remaining energy = 123396J - ID: 1  

--

9.00087s -- Received one packet! Socket: 10.1.1.1 port: 49153

--

So according to that (and due to default values of the RV Battery model), the initial energy is 125031 Joules. According to the remaining Energy the quantity left is 123396. So the energy spent is 1634.6 Joules. The energy is calculated as (alpha * supply voltage * battery level).  

On the other hand, the total energy consumed by radio is 8.72442 Joules. It is calculated on the WifiRadioEnergyModel as the product of time length (s) * status-current *  rv battery supply voltage.

Is the difference between values-1634.6J and 8.72442J- due to the non-linearity effects or it is a coding mistake?

Thanks in advance.

David.

[Tommaso Pecorella]

Hi,

I never noticed this, and tbh the difference is a bit too large to classify it as a rounding error or a non linearity.

I'll leave the floor to Cristiano Tapparello (the energy module maintainer) for further investigations - he's in copy. It could be a bug.

Please get in touch with him, and please provide a simple script showing the wrong behaviour.

Cheers,

T.

[David]

Morning Tommaso,

thanks for replaying and pinging Cristiano to have a look.

I attach all the information required:

1.- Rv-battery-model.cc which has been modified to provide the remaining energy info.

2.- Rv-battery-model-h with the same purpose as above.

3.- Script file where a simple net of 2 nodes is set with an energy model (RV Battery and WifiRadioEnergyModel).

4.- Terminal output after executing the script.

Please notice the difference between the Remaining Energy callback (f.e last one):

9.00087s Total energy consumed by radio = 8.72442J - ID: 1  

basicRadioModelPtr->TraceConnect ("TotalEnergyConsumption",PrintID(sources.Get(1)->GetNode()), MakeCallback (&TotalEnergy));

And the info shown at the end of the simulation:

Node 1

------

Initial Energy: 125031 J.

Remaining Energy: 123396 J (alfa * voltage * battery level).

Consumed energy: 1634.6 J.

(rvBatteryPtr->GetInitialEnergy())-(rvBatteryPtr->GetRemainingEnergy())

Which value is the correct one, the provided by the subtract of the Initial energy minus the remaining energy?

Shall I ignore the total energy consumption? My goal was to get the same information on the three battery designs (ideal, RV and Li-ion) and compare them in the same scenario with the same values (remaining Energy, ConsumedEnergy, etc.). What is your advice? I mean, which values should I compare on the three scenarios?

Thanks in advance,

David.

[David]

Morning Cristiano,

just wondering if you had a gap to check the above issue. Of course I know and I understand that the forum is not your main task (Actually, I appreciate how Tommaso and yourself give away your spare time here for helping) so no problem at all if you couldn't. 

In fact, I am not currently using TotalEnergyConsumption on my simulations as it is the suspicious parameter, but it would be great if the mystery could be solved anytime. 

Thanks in advance,

David.

[Cristiano Tapparello]

Hi David,

Thank you Tommaso for answering to the initial questions and bringing me in the conversation.

I noticed this problem in the past but I was not 100% sure about the solution that I found for it and, in the end, I ended up forgetting about it... :-)

The problem derives from the fact that the papers that present the Rakhmatov and Vrudhula (RV) battery model don’t clearly specify the unit of measure used for the different parameters of the model. In particular the papers define alpha as a Coulomb value but, most of the later results refer to it as mA/min. The different tables inside those papers are also confusing... 

The default value of our implementation is taken from one of the original papers, that defined alpha in Coulomb. However, the discrepancies in the ns-3 results suggest otherwise. 

You can see that if you get the consumed energy from the RV battery as  

alpha * voltage * (1-battery level)

and then multiple this by 60/1000 (thus converting alpha to Coulomb (i.e., Ampere * seconds)) the results that you get make more sense. Taking your example, the consumed energy from the RV battery goes from 1634.6 (?) to 98.076 J. 

It is important to note that the energy consumption of the WiFi radio will most of the times not match the RV battery energy depletion (they will never match if you consider a non-zero idle current). This is because the RV battery model includes the effect of charge redistribution. Due to the internal battery charge redistribution, when applying a load the battery level decreases faster than the actual energy consumed by the load, while when no load is applied the remaining energy slowly increases. I refer you to [2] for additional details on this model (Fig. 3 is particularly descriptive).

If you ran extensive simulations you will see that when considering alpha as mA/min the model actually behave properly (see, e.g., the results in [2]).

I hope this help you understand your results!

As a final note regarding our implementation of the model, I will double check the values of the model across different papers and then implement the appropriate changes. I think that we should (at least) include some comments in the documentation.

Best,

Cristiano

[1] D. Rakhmatov, S. Vrudhula, Energy Management for Battery-Powered Embedded Systems, ACM Transactions on Embedded Computing Systems. (http://dl.acm.org/citation.cfm?id=860179)

[2] C. Tapparello, H. Ayatollahi, W. Heinzelman, Energy harvesting framework for network simulator 3 (ns-3), Proc. of ENSsys. (http://dl.acm.org/citation.cfm?id=2675685)

[David]

Wow,

Thank you SO MUCH for such a good explanation. I've been working on it since Thursday and now everything is clear and it makes sense. 

Once again Tommaso, Cristiano and in other topics konstantinos, thanks for your selfless help.

Regards,

David.