Lightning is the "new" connector supported by iPhone 5 and newer, iPad mini 1G and newer, iPad 4 and newer, and iPod touch 5G. (For the old connector, see 30-pin Connector.) It was presented by Tim Cook at an Apple Special Event on September 12, 2012. According to Apple, it as an all-digital connector and "features an adaptive interface that uses only the signals that each accessory requires and also is 80% smaller as well as orientation independent."
- Lightning is adaptive.
- All 8 pins are used for signals, and all or most can be switched to be used for power.
- The outer plug shell is used as ground reference and connected to the device shell.
- At least one (probably at most two) of the pins is used for detecting what sort of plug is plugged in.
- All plugs have to contain a controller/driver chip to implement the “adaptive” thing.
- The device watches for a momentary short on all pins (by the leading edge of the plug) to detect plug insertion/removal.
- The pins on the plug are deactivated until after the plug is fully inserted, when a wake-up signal on one of the pins cues the chip inside the plug. This avoids any shorting hazard while the plug isn’t inside the connector.
- The controller/driver chip tells the device what type it is, and for cases like the Lightning-to-USB cable whether a charger (that sends power) or a device (that needs power) is on the other end.
- The device can then switch the other pins between the SoC’s data lines or the power circuitry, as needed in each case.
- Once everything is properly set up, the controller/driver chip gets digital signals from the SoC and converts them – via serial/parallel, ADC/DAC, differential drivers or whatever – to whatever is needed by the interface on the other end of the adapter or cable. It could even re-encode these signals to some other format to use fewer wires, gain noise-immunity or whatever, and re-decode them on the other end; it’s all flexible. It could even convert to optical.
Top (DHC marked)
When a Lightning adapter is plugged in to the device it will connect to
where, similar to an OTA iOS update, it looks for any new update bundles. This would only be for any in-between updates, though, since both iOS 6.0 and 6.1 come with predownloaded adapter firmware bundles located at /System/Library/PreinstalledAssets. (Each firmware bundle is about 11MB uncompressed.)
For fun, you can also monitor the device Console using Xcode or iPCU while connecting the adapter; you’ll see logs very similar to what happens during an iOS DFU restore, as the device loads firmware onto the Lightning adapter, as the boot chain starts off very much like a normal iOS device, but img3 files for iBSS are uploaded, along with an APTicket. This APTicket remains static for every digital AV adapter. The kernel is then uploaded and then booted.
Lightning to 30-pin Adapter
This adapter lets you connect devices with a Lightning connector to many 30-pin accessories but some 30-pin accessories are not supported. The adapter supports analog audio output, USB audio, as well as syncing and charging. Video output not supported. The chips inside look unfamiliar and some have lasered text. They all appear to be custom and probably some are integrated audio circuitry in a larger processing chip. One of the chips reads Apple on it with a very long serial number. Another reads 8533 23AP CAB.
Lightning Digital AV Adapter
It appears the Lightning Digital AV adapter is based off the Samsung S5L8700 series of chips. This series of processors is mainly used in the iPod nano, and the iPod touch 2G. Based on the ChipID found in /System/Library/PreinstalledAssets/com_apple_MobileAsset_MobileAccessoryUpdate_haywire.xml it seems the ARM SoC used is the Samsung S5L8747. Its part number is H9TKNNN2GD with 256MB RAM. The SoC peripherals look very much akin to other Samsung chips.
There is some discussion regarding the outputs image quality of this adapter as it seemingly the video-out is upscaled from max 1600×900 resoultion to 1080p with visible (MPEG) compression artifacts. Apparently an Apple Engineer explained details of the adapter at www.panic.com:
Airplay is not involved in the operation of this adapter.
It is true that the kernel the adapter SoC boots is based off of XNU, but that’s where the similarities between iOS and the adapter firmware end. The firmware environment doesn’t even run launchd. There’s no shell in the image, there’s no utilities (analogous to what we used to call the “BSD Subsystem” in Mac OS X). It boots straight into a daemon designed to accept incoming data from the host device, decode that data stream, and output it through the A/V connectors. There’s a set of kernel modules that handle the low level data transfer and HDMI output, but that’s about it. I wish I could offer more details then this but I’m posting as AC for a damned good reason.
The reason why this adapter exists is because Lightning is simply not capable of streaming a “raw” HDMI signal across the cable. Lightning is a serial bus. There is no clever wire multiplexing involved. Contrary to the opinions presented in this thread, we didn’t do this to screw the customer. We did this to specifically shift the complexity of the “adapter” bit into the adapter itself, leaving the host hardware free of any concerns in regards to what was hanging off the other end of the Lightning cable. If you wanted to produce a Lightning adapter that offered something like a GPIB port (don’t laugh, I know some guys doing exactly this) on the other end, then the only support you need to implement on the iDevice is in software- not hardware. The GPIB adapter contains all the relevant Lightning -> GPIB circuitry.
It’s vastly the same thing with the HDMI adapter. Lightning doesn’t have anything to do with HDMI at all. Again, it’s just a high speed serial interface. Airplay uses a bunch of hardware h264 encoding technology that we’ve already got access to, so what happens here is that we use the same hardware to encode an output stream on the fly and fire it down the Lightning cable straight into the ARM SoC the guys at Panic discovered. Airplay itself (the network protocol) is NOT involved in this process. The encoded data is transferred as packetized data across the Lightning bus, where it is decoded by the ARM SoC and pushed out over HDMI.
This system essentially allows us to output to any device on the planet, irregardless of the endpoint bus (HDMI, DisplayPort, and any future inventions) by simply producing the relevant adapter that plugs into the Lightning port. Since the iOS device doesn’t care about the hardware hanging off the other end, you don’t need a new iPad or iPhone when a new A/V connector hits the market.
Certain people are aware that the quality could be better and others are working on it. For the time being, the quality was deemed to be suitably acceptable. Given the dynamic nature of the system (and the fact that the firmware is stored in RAM rather then ROM), updates **will** be made available as a part of future iOS updates. When this will happen I can’t say for anonymous reasons, but these concerns haven’t gone unnoticed.
- Rainer Brockerhoff’s blog
- Dynamic pin assignment
- Chipworks teardown of cable
- Chipworks teardown of 30-pin adapter
- Case Design Guidelines for Apple Devices i.e. page 17
- Patent #: US2013011582
- Patent #: US20130115817
- Patent #: US20130117470
|This hardware article is a "stub", an incomplete page. Please add more content to this article and remove this tag.|