FLIR
LEPTON® Engineering Datasheet
The information contained herein does not contain technology as defined by the EAR, 15 CFR 772, is publicly available,
and therefore, not subject to EAR. NSR (6/14/2018).
Information on this page is subject to change without notice.
Lepton Engineering Datasheet, Document Number: 500-0659-00-09 Rev: 203
52
4.2.2.3.1
Establishing/Re-Establishing Sync
The basic process for establishing synchronization is listed below:
•
Deassert /CS and idle SCK for at least 5 frame periods (>185 msec). This step ensures a timeout of the
VoSPI interface, which puts the Lepton in the proper state to establish (or re-establish) synchronization.
•
Assert /CS and enable SCLK. This action causes the Lepton to start transmission of a first packet.
•
Examine the ID field of the packet, identifying a discard packet. Read out the entire packet.
•
Continue reading packets. When a new frame is available (should be less than 39 msec after asserting /CS
and reading the first packet), the first video packet will be transmitted. The master and slave are now
synchronized.
4.2.2.3.2
Maintaining Sync
There are three main violations that can result in a loss of synchronization:
•
Intra-packet timeout. Once a packet starts, it must be completely clocked out within 3 line periods.
•
Provided that VoSPI clock rate is appropriately selected and that /CS is not de-asserted (or SCLK
disrupted) during the packet transfer, an intra-packet timeout is an unexpected event.
•
Failing to read out all packets for a given frame before the next frame is available. Two examples of this
violation are shown in
and
. Note that the vertical blue line shown in the illustrations
represents an internal frame-sync signal that indicates a new frame is ready for read-out.
•
Failing to read out all available frames. This violation is depicted in
. Note that the requirement
to read out all frames applies to both the unique and the duplicate frames.
A CRC error does not result in an automatic loss of synchronization. However, as mentioned previously, it is
recommended to intentionally re-synchronize (de-assert /CS for >185 msec) following a CRC error.
The following figures are examples of violations that result in a loss of synchronization.
Figure 26 - Valid Frame Timing (no loss of synchronization)