[Tinyos-devel] problem of using FTSP and CTP

[Miklos Maroti]

Hi Andreas,

On Mon, Mar 23, 2009 at 7:09 PM, Andreas Köpke <koepke at tkn.tu-berlin.de> wrote:
> I agree with Phil here: components that use the AMSend virtualizer should not
> be influenced by components that do not use it.
>
> But is it really necessary for FTSP do use ActiveMessageC directly? I think
> not. In my opinion, there are two reasons why FTSP uses ActiveMessageC
> directly, one is ease-of-porting and the other, more important one, is that it
> uses a message _footer_ on tmote. On the sender side, the footer contains the
> time when the message was generated, whereas on the receiver side it contains
> the time that passed between the message generation time and the time its SFD
> was transmitted. A footer is a sensible choice here, since it allows the CPU
> enough time to compute the deltaT and modify the message on the fly.
>
> So the fact that FTSP attaches directly to ActiveMessageC is actually a hack
> that circumvents the lack of dynamic footers in message_t. As  a case study, I
> implemented a time synchronization on top of the AMsend virtualizer, using a
> standard AMSenderC component. It works, I just have to handle the footer the
> way TimeSyncActiveMessageC does: attach a uint32_t at the end of the message,
> set it to the current local time and expect that it has been modified to
> contain deltaT on reception. Perfect, simple and without any side effects on
> other components that use AMSend. Unfortunately, it requires that the
> application is "footer aware" and "time stamp aware" -- no big deal for FTSP,
> though.

FTSP does not use ActiveMessageC (look it up), it uses the
TimeSyncActiveMessageC and that is not a hack. Of course
TimeSyncActiveMessageC could be implemented on top of the AMSenderC
and not the ActiveMessageC. Maybe that is what you are proposing? That
would work. By the way, we are not talking about FTSP or CTP per se,
that is just where people see the bad interaction of
TimeSyncActiveMessageC, AMSenderC and ActiveMessageC.

Miklos