The timestamp is the system time when the packet was read in from the radio chip on receives and when the packet was sent on transmits. If you consider all the steps involved in transmitting & receiving a packet things will (hopefully) become clear:
on sending spot:
1. user app packs data to send into a radiogram packet.
2. user app initiates send of packet
3. radio stack checks for route to destination, etc.
4. finally ready to send so write data to radio chip
5. data written, wait for transmission to start
6. record time packet was actually sent
7. user app can now query when transmission occurred
on receiving spot:
1. user app blocks waiting to receive a radiogram
2. radio stack receive thread blocks waiting for interrupt
3. radio receives incoming packet and stores it in fifo buffer
4. Squawk VM responds to radio interrupt and restarts receive thread
5. receive thread reads in radiogram packet from radio's fifo buffer
6. record the current time to mark when packet was received
7. radio stack processes packet and passes it to user app
8. user app does whatever it needs to with packet
As you can see from the many steps a fair amount of time can pass between when a packet is physically received & when the user program finally gets handed the packet (& ditto when sending). The timestamp on the packet is a way to minimize some of this latency.
For most applications the latency doesn't matter, but it's essential for anyone who wants to do a time synchronization protocol in order to have the clocks on several spots all be within a few milliseconds of each other.
--rgoldman
没有评论:
发表评论