The STXON strobe tells the radio chip to start transmitting a packet. After
STXON is issued, the chip transmits the preamble, puts the two SFD bytes on
air, reads the length byte from the TX FIFO, transmits it, and reads and
transmits the subsequent bytes of the message one by one. That is, it does
not need the entire packet in the TX FIFO at the time of the strobe. The
only thing we have to make sure is that the bytes are there when the chip
wants to put them on the air.

To answer your question: there's no second STXON because the first one
already initiated the packet transmission (although only the beginning of
the packet was in the TX FIFO).

Janos


On Mon, Dec 3, 2012 at 11:14 PM, Xiaohui Liu <[email protected]> wrote:

> Hi,
>
> Another question: STXON is strobed when header is loaded in TXFIFO, while
> the payload is loaded later. Why is there no second STXON strobe to
> transmit the payload?
>
> Thanks for your patience.
>
> -Xiaohui
>
> On Mon, Dec 3, 2012 at 9:44 PM, Xiaohui Liu <[email protected]> wrote:
>
>> Hi Janos,
>>
>> I see.
>>
>> I changed the timestamping in CC2420 stack accordingly, but occasionally
>> wrong timestamps still pop up. My speculation is that the following corner
>> case is causing problem:
>>      ____     ____
>> __|        |__|        |_
>>
>> As SFD pin activity shown above, a packet transmission ensues a packet
>> reception. The MCU does not respond to the 1st SFD rising till after the
>> 2nd SFD rises. After the packet is read out of RXFIFO, there is no other
>> packet in RXFIFO and thus the timestamp of the transmitted packet is
>> mistakenly assigned to the received packet. I'm reading CC2420X but haven't
>> found how this case is dealt with. Please give me some hint. Thanks again.
>>
>> -Xiaohui
>>
>> On Mon, Dec 3, 2012 at 5:26 PM, Janos Sallai 
>> <[email protected]>wrote:
>>
>>> The hardware is fairly deterministic: After issuing the STXON strobe the
>>> SFD will be transmitted with a constant delay. It's more efficient to take
>>> a timestamp when issuing STXON and adjust it with a constant TX_SFD_DELAY
>>> than servicing an SFD interrupt.
>>>
>>> Janos
>>>
>>>
>>> On Mon, Dec 3, 2012 at 4:10 PM, Xiaohui Liu <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Thanks for clarifying the reception timestamping.
>>>>
>>>> Why is *TX_SFD_DELAY* accounted for during transmission, but not
>>>> during reception? Isn't *sfdTime* the time SFD byte has been
>>>> transmitted so there is no need to add *TX_SFD_DELAY*?
>>>> * // adjust time32 with the time elapsed since the SFD event*
>>>> * time -= sfdTime;*
>>>> * time32 -= time;*
>>>> *
>>>> *
>>>> * // adjust for delay between the STXON strobe and the transmission of
>>>> the SFD*
>>>> * time32 += TX_SFD_DELAY;*
>>>> *
>>>> *
>>>> *                call PacketTimeStamp.set(msg, time32);*
>>>>
>>>> -Xiaohui
>>>>
>>>> On Mon, Dec 3, 2012 at 1:45 PM, Janos Sallai <
>>>> [email protected]> wrote:
>>>>
>>>>> FALSE
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -Xiaohui Liu
>>>> TelosB
>>>> TinyOS 2.1.2
>>>>  www.cs.wayne.edu/xliu/
>>>>
>>>>
>>>
>>
>>
>> --
>> -Xiaohui Liu
>> TelosB
>> TinyOS 2.1.2
>> www.cs.wayne.edu/xliu/
>>
>>
>
>
> --
> -Xiaohui Liu
> TelosB
> TinyOS 2.1.2
> www.cs.wayne.edu/xliu/
>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to