Created on 1.7.20
Here’s my little article about (almost) everything I know about Apple Lightning and related technologies: Tristar, Hydra, HiFive, SDQ, IDBUS and etc. But first a tiny warning…
Read this article on your own risk! The information in this artcile is based on a lot of AppleInternal materials (leaked datasheets, schematics, source codes) I read in a diagonal direction. And of course on my own research too. I have to warn you, the reader, that I have never done such a research before. Thus, this write-up might use incorrect or just weird terms and turn out partially or completely wrong!
Before going deeper, let’s briefly sort out the terms:
What’s Lightning?
Lightning – is a digital interface used in most of the Apple’s iOS devices since late 2012. Replaced the old 30-pin connector
You can see the female port pinout on the picture above and the connector pinout on the picture below:
Please pay attention to the fact that in the connector, pins on both sides of connector aren’t wired in exact same order. Thus, a host device have to detect orientation of a cable before doing anything else
Though it’s not always applicable. Many Lightning accessories I’ve played with have mirrored pinouts in their connectors
What’re Tristar and Hydra?
Tristar – is the integrated circuit embedded in every device shipped with Lightning female port. Basically, it’s a MUX:
Among many other things, its main purpose is to communicate with Lightning male connector once one was connected – detect orientation and detect Accessory ID and route internal interfaces like USB, UART and SWD accordingly
Hydra – is the new variant of Tristar used since iPhone 8/X. The most significant change appears to be a support of wireless charging, but that’s to be verified:
There’re 5 major Tristar/Hydra variants known to me:
- TI THS7383 – first-gen Tristar used in iPad mini 1 and iPad 4
- NXP CBTL1608A1 – first-gen Tristar used in iPhone 5 and iPod touch 5
- NXP CBTL1609A1 – mysterious first-gen Tristar used in iPod nano 7 – source
- NXP CBTL1610Ax – second-gen Tristar used since iPhone 5C/5S and apparently everything else that doesn’t support wireless charging. There’re multiple generations of this one (x – number of generation)
- NXP CBTL1612Ax – Hydra used since iPhone 8/X and apparently everything else that supports wireless charging (x – number of generation)
From now on, I’ll only use the term Tristar, but keep in mind that it will also mean Hydra as well, as they are very similar in the most of aspects that are gonna be covered in this text
What’s HiFive?
HiFive – is Lightning slave, i.e. a male connector. It contains a logical element as well – that chip is known as SN2025/BQ2025
What’re SDQ and IDBUS?
These 2 terms are often referred as kind of synonyms. For convinience, I’ll only use term IDBUS from now on, as it seems more correct to me (and that’s how this technology called in the THS7383 datasheet)
So, IDBUS – is a digital protocol used for negotiations between Tristar and HiFive. Very similar to Onewire protocol
Now we can play
Let’s sniff the negotiations between Tristar and HiFive. Take a logic analyzer, a Lightning male-to-female passthrough breakout board, some accessory (normal Lightning to USB cable would fit just fine) and of course some device with Lightning port
First connect logic analyzer’s channels to both ID lines of the breakout (pins 4 and 8) and connect the breakout to the device, but do not connect the accessory just yet:
Right after that start sampling (any rate from 2 MHz and up should be fine). You’ll see something like this:
As you can see, Tristar polls each ID line by rotation – one after another. But since we didn’t connect any accessory, the polling obviously fails. At some point the device will grow tired of this endless stream of failures and stop it. Meanwhile let’s examine what exactly happens while polling:
First, we can see a long interval (~1.1 milliseconds) when the level is just high and nothing else is happening:
Apparently that time is used to charge internal HiFive’s capacitor – the energy from it will be then used to power-up its internal logic chips
What happens next is far more interesting:
Obviously, that’s some data flowing. But how to interpret it? How to decode it? Let’s virtually split it to almost the least least significant parts – to something that I call words:
So basically a word is a combination of fall–rise–fall:
- Meaningful Stage – time interval taken by this stage defines meaning of a word
- Recovery Stage – time interval which is apparently required for processing the Meaningful Stage on recieving side and/or preparing the next word on sending stage
Here is a table of known word types with their time intervals for both stages we discussed above (all units are in microseconds):
Meaningful | Recovery | ||||
---|---|---|---|---|---|
Word | Min | Typ | Max | Min | Typ |
BREAK | 12 | 14 | 16 | 2.5 | 4.5 |
WAKE | 22 | 24 | 27 | 1100? | |
ZERO | 6 | 7 | 8 | 3 | |
ONE | 1 | 1.7 | 2.5 | 8.5 | |
ZERO with STOP* | 6 | 7 | 8 | 16 | |
ONE with STOP* | 1 | 1.7 | 2.5 | 21 |
* – STOP is used when it’s a last bit in a byte
Using the above table we can now build a simple decoder of the protocol:
As you can see, the first word a host sends is BREAK – when Tristar wants to send a new requ