[sim-wg] Re: Regarding the Radio profiling

[Philip Levis]

On Mar 26, 2007, at 11:13 PM, Venkatesh S. wrote:

> Hello :
>
>      I would like to thank phillip for asking me to go through the  
> Timer0 implementation.  This was good task for me to take up.  I  
> really understood how the interrupts are signalled in TOSSIM.
>
> Regarding ADC:
>     The HPL files for ADC has been modified to work in TOSSIM, by  
> using the event scheduler.  An interrupt SIG_ADC() is signalled  
> when the enableAdc() command is called.  A random number is  
> returned to the ADC register.  I need one more clarification  
> regarding the same.  If I consider the DemoSensorC application  
> which is in the mica2 platform, it uses the VoltageM which is  
> binded to the A7 pin for battery.  Whenever my application calls  
> the ADC.read(), it calls the AsyncStdControl.start() which enables  
> the ADC interrupt, and AsyncStdControl.stop() which disables the  
> ADC interrupt.  I thought this will be done for all the other ADC  
> pins, but while measuring the RSSI value which is connected between  
> the Radio Rssi pin and the A0 pin, i didnt get back an event  
> triggering the data ready().  When I saw the implementation, it  
> used to do the following:
> 1) Enable ADC On
> 2) Start of conversion
> 3) ADC Interrupt Flag On
> 4) ADC Interrupt Enable On
> in the ADSR register, and was waiting for the EndOfConversion which  
> it was not getting, and the resource used to be busy all the time.   
> When i tracked down to the HPL file, the command setAdcsra(x), sets  
> the above flags in the ADSRA register.  Since the event SIG_ADC()  
> was given through the enableAdc() command, I thought of calling  
> this command, then wait for some time and again call the disableADC 
> (), which will trigger the event.  Is this the way to do, or is  
> there any other way?

The best way to do this, really, is to simulate the ADC registers as  
best you can. If you need to add functionality -- such as an  
enqueueing an event -- then do that at the lowest level possible  
(i.e., the HPL).

That being said, I don't understand your question, e.g. "the resource  
used to be busy all the time."


> Regarding Radio Profiling:
>
> Measuring RSSI:
>
>     I had few thoughts in my mind.  I had a look of Tossim version  
> of CC2420 Implementation in T1.  I felt that the whole MAC  
> implementation along with the HPL was implemented into a single  
> file.  I am thinking to do only the HPL part, so that the existing  
> MAC files should work as it is.  To do so, the RSSI part has to  
> brought into simulation.

Yes. I've been working on this.

>
> If  I consider the CC1000 Radio, then it has B-Mac implemented.   
> The MAC checks the medium to be free or busy, based on the RSSI  
> value.  This RSSI value is got through the ADC port.  Can't we  
> bring the notion of RSSI, based on the transmissions that is being  
> done at the lower layer of TOSSIM.  Hopefully if we have a option  
> to find the on-going transmission, then the Received Power can be  
> computed by Received power = TxPower +  Gain.  In CC000, there is  
> way to compute the Received power
> RxPower = -51.3*Vrssi - 49.2 [dBm]
> So, Vrssi = (RxPowr + 49.2) / (-51.3).
> from this we get back a analog voltage.  Depending upon the pre- 
> scalar values, we get a corresponding digital ouput of the Vrssi,  
> which is given to the ADC register.
>

Yes. The best way to do this, from a simulation standpoint, is to  
write a TinyOS app that measures a high-frequency trace of RSSI  
values for an environment. You can them have TOSSIM recreate a  
similar trace using probabilistic methods. I have a paper on this in  
IPSN this year.


> Simulation SPI:
>
>      I triggered an event whenever SPI.Write is called, and the  
> event used to trigger the SIG_SPI().  The SPI in CC1000 Radio has  
> no buffer management in it.  It gets a byte, sends to the medium  
> and again sends an interrupt to send the next byte.  The current  
> implementation just signals back the SIG_SPI() for the Transmission  
> part and not for the reception part.  There might be two  
> possibilities in doing the this part.
>
> 1)  Buffer byte by byte till the end of the Transmission.  Then use  
> the TossimPacketLevel model to send the packet on the medium (once  
> the packet has come to SPI layer, it is sure that there is no  
> transmission going on by any other nodes, so just give the packet  
> to all the neighbors).  Again here, schedule the events to deliver  
> the packet to all the nodes, which eventually triggers a byte by  
> byte SPI events.
>
> 2)  Implementing a new ByteLevelInterface Model, which will trigger  
> an SPI receive events to all the neighbors for every byte, and the  
> MAC reframes that into packet.  This is more realistic when  
> compared to CC1000.
>
> Feedbacks are greatly appreciated, which will help in moving further.

In theory, if the SPI is dedicated, then you'd like to have a  
particular chip implement the functionality. E.g., calls to the  
atm128 SPI actually call the simulated CC2420 or simulated CC1000.

I would start with approach 1) and move to approach 2) later if it's  
worthwhile. Doing a byte-by-byte model will greatly harm efficiency,  
and given that the CC1000 is being used less and less, it's not clear  
the effort would be worth it. It's much better to focus on the CC2420.

Phil