USB Type C and Power Delivery Technology & Testing Webinar

welcome to today’s webinar USB type-c and power delivery technology and testing I’m Mike Michael Eddie and I’m a product manager here for the USB testers at teledyne lecroy and earlier this year we celebrated our 20th anniversary of working in the USB ecosystem going back to nineteen ninety-five when we work at sea we build analyzers for a lot of different serial interfaces now but we’re in sort of a unique position when it comes to new technologies we can actually predict which emerging standards will get adopted based on the analyzer sales rate and all I can say is that in the first quarter of shipments we broken our own sales record with the new mercury TTC that’s our low-cost type C analyzer and this is in terms of units so that tells us two things that type C is ramping fast and that it’s a little more complicated than people thought they’ve added a lot of capabilities with type C really expanded the number of things you can do over a USB cable we’re definitely seeing more activity more innovation really more excitement about around USB have to cover in a short amount of time here so we’re going to dive right in most of this material is specific to the protocol layers getting a link configured will move quickly through cable detection spend a few minutes on message types before looking at real traffic with actual devices I’ll bring up some some interesting test issues I’m sure there’ll be a lot of questions so please type in any questions using the question box we’ll address everything we can at the end of the webinar and definitely i’ll send out the slides to everyone later today so stick with us at the 30-minute mark will pick one lucky winner for our mercury type C analyzer giveaway this is the fully loaded advanced model so hey the odds are good and I’ll definitely announce the winner at the end of the webinar if you’re on this call you’re probably already familiar with USB type-c features the goal was to create a smaller thinner more robust alternative to the existing USB connectors the design was really modeled on the apple lightning connector the reversible orientation where you insert the plug either up side up or upside down is well it’s overdue because what’s happened is the platforms are getting smaller and people’s eyes are getting older it really does get harder to see the right orientation of the plug so I’m sure this will be popular and we’re we’re surprised by how many vendors have jumped on the alternate mode stuff we originally thought this would be kind of a niche but the majority of chipsets at the last plugfest have alt mode support so well the USB is the USB I f that is is very bullish on type C and are claiming the fastest transition since USB 2.0 was launched power delivery and the type-c connector have really become linked together but they weren’t initially the higher voltages in PD we’re supposed to work over legacy USB connectors using FSK signaling but interest in FSK has completely disappeared there’s really no activity virtually everyone that’s implementing PD has moved to type C so the applications are the same only now it’s over a type-c cable obviously they’re targeting very thin platforms with Type C your notebooks your tablets your smartphones and we continue to hear that reducing ewaste is one of the driving forces with PD the mobile market in particular wants a universal charging cable there’s also a lot of interest in video / type see there are all mode adapters on the market now that will mocks HDMI or display port / type see there’s also audio accessories other other applications in the works there’s a lot going on so the material I’ll cover comes from two specs the power delivery 2 point 0 and the type-c version 1.1 spec anytime you have two complementary specs the technology can be harder to understand it’s easy to miss things if you have to refer back to chi documents and the power delivery spec addresses all the elements of the logical PD protocol like

discovery negotiation role swaps the commands for alternate modes are also defined here but you’ll also need to look at the type C spec where they have a section called functional extensions all the logical state machines for alternate modes are in here but mainly you’ll find the electrical mechanical the physical layer requirements in the type C spec it’s too bad there’s no plan to merge these two specs because there’s several areas that are still a source of confusion for a lot of developers any discussion about power delivery really has to start with the pin out of the type-c receptacle because it’s such a huge part of understanding how the technology works make the cable flippable on the new type C receptacle they’re basically creating a mirror image of the pins in sort of a top and bottom row alignment if you compare that with legacy USB 30 the old pins map to the new pins on this upper row labeled a and then there’s a redundant set of pins on the bottom row that basically won’t get used for USB so if you were to flip the cable you would still connect to a second redundant set of pins on the bottom row in the receptacle apologies if you didn’t see that cool animation but I’m trying to show that you’re basically making the same connections even though it’s a different physical in so the cable plug is flippable but all the intelligence is really in the receptacle side so we need to look at that but before we do the other key feature is that the entire cable is reversible either side can be attached to the host because the the plugs are identical right but we still need to maintain the logical host to device relationship so when you’re connecting the type-c cable to a receptacle which row the pins my going to use okay that’s the first order of business with type C and then identifying the host a device relationship is the next critical step both are accomplished over the configuration channel or CC it’s considered a side band signal to the logical USB link but it’s it’s used to orient the cable and set up the initial data roles and then I even after that it’s it’s used to do to do all the negotiation for power delivery States so I mean it controls the alternate modes it’s a major component of type C this image maps out all the roles of all the pins in the receptacle as I said there are basically duplicates for every line if you’re familiar with USB 3 you’ll see that there are two sets of SuperSpeed pairs only one set is actually get getting used by USB same for D plus D minus only one of these pairs will connect there are two V bus pins in each orientation and SBU stands for sideband use okay not used by USB at all both of these pins can be configured for alternate protocols now currently for example they’re used as the auxiliary channel in display port it’ll also potentially be used for delivering audio / type C but these are of course in the cable in both orientations as well and then the CC line is also duplicated okay so think of this view as though you were looking inside the cable plug and the receptacle housing itself the upper one is the is the cable okay these pinouts look similar but there’s one huge difference that’s really important to understanding this technology only the receptacle side has the fully redundant set of pins the cable is not symmetrical like the receptacle on the upper image the CC line is always on a 5 and if it’s Annie mark cable then Vikan is always on b5 there’s only one D plus D minus one super speed pair the extra pins we see here in the cable plug are are there exclusively for alt modes so the cable can come in on either orientation facing up or facing down and it will always use the same pins for USB it’s the receptacles job to adjust the pin out to match the cable okay before we look at that we need to understand marked and unmarked cables

most of what’s on the market today is unmarked they have no active components but the marked cables are coming and these will have a chip embedded in the CC line so the DFP can actually ping the cable and the cable will answer back with his capabilities the report whether he can handle the higher voltages he’ll report if he’s configurable for alt mode one of the main motivations here is that a type c source cannot supply more than 3 amps of current unless it’s connected using a marked cable so it’s a safety thing the cheaper unmarked cables are going to be limited at three amps still that’s higher than legacy USB also with Type C there’s a provision for active cables where they’re putting repeaters indicating some cases these components may need to be configured using cable messages this will also be done over the CC line with commands that are targeted and specifically for the cable will look at this in a second but the main takeaway here is is that the type C cables are going to be smarter and they’ll definitely require more testing okay another change v bus is still used for powering or charging devices except now there’s a option to source higher voltages up to 20 volts now Vikan is used solely to power the e marked cables well the also there will be something called a V Cohn powered accessory but primarily it’s used to power active components embedded in the cable and that’s supposed to happen before anything else on the link so when the initial source sees any marked cable he’s supposed to drive 5 volts over Vikan the cable will only draw 200 milliamps so it’s a small amount of power but it’s critical to the operation of these market cables pd does allow swapping source and sink for v bus there’s also a way to swap the beacon source and when devices do a Viva swap they’ll typically also do a Vikan swap but we’ll take a look at that okay I’ll give you a high level summary of the configuration process and then we’ll come back and look at each step in more detail it’s required that the initial source come up in USB safe mode the CC lines are used to determine the cable orientation then be kind of supplied to power any e-mart cables so week on first then the devolvi bus voltage gets turned on second are the source that is now as long as it’s a USB type-c and it supports PD you’re going to see see see messages that will use to farragut cable then there’s a two-way negotiation of the power level after an explicit contract is established that default data-role device sends discover commands to the port partner to determine if he wants to enter any alternate modes displayport over C is the most common thing we’ve seen here once there’s an established power contract the DFP sends other vendor to find messages to configure this is alternate modes again if there’s no alt mode support it goes to standard USB signaling again we’ll look at this in more detail here in a second so how does this cable detection work starting with the simplest case a provider only connecting to a consumer left side here is the provider or source and the right is the consumer or sink and on hiding all the other connections in this picture just for simplicity so both receptacles are powered and monitoring the CC 1 and the CC two lines continuously once the cable is connected they look at resistance levels on the CC pins the source attaches a couple of pull-up resistors known as RP and the sink shows a pulldown resistor or rd so this on really on his side so he takes both CC pins to ground they only see this termination on the 1 CC line that’s connected right so they know this is the line they’ll use for PD communications so now they have to route the other signals I’m not showing accordingly you flip the cable over and they’ll see the same termination RP and rd only this

time on the CC to line so they need to use the lower pins in the receptacle in this case for the logical USB connections if there’s a twist in the cable it’s fine because each receptacle needs to be smart enough to figure out which pins to use based on the resistance he’s sensing on the CC line so the receptacle will router mux the other signals to the right pins okay now we’re looking at the same setup simple provider and consumer except now we have an e marked cable so it has the chip inside the cable and these components need a small amount of power so this is where the unused CC pin in the receptacle can now be used to source V Cohn to the cable okay so both length partners are monitoring the CC lines for RP and RD so the DFP here is pulling up on both pins again senses the pull-down resistance at the far end these e mark cables present a load on the line known as RA so the receptacle consents another voltage divider right here so he knows there’s a cable electronics out there that needs Vikan only after the two sides determine which line will be used as the CC channel the DFP then applies power to be con after waiting you know a required timing interval it can now communicate with the cable itself flip the cable over and the receptacles will still see RP and RD but it’s on their CC to line this time so cc1 now becomes Vikan right it’s possible the cable may need decon at both ends if it has three drivers or active components in the plug so it’s up to the cable to propagate power to the far end plug if needed but in all cases Vikan is not passed through its terminated in the electronics of the plug so that connection doesn’t go all the way through in the cable now the pd spec uses the term DRP to define a dual role port this means it can act as a source or sink for power it has nothing to do with being a host or device only the power rule is affected by a dual role port back in the original OTG spec DRP meant something else it meant swapping the hosting device roles not anymore this does introduce some additional complexity because now you have to decide who is going to be the default source in the default sink at power up so a DRP by rule is supposed to switch between showing our P and RD every 75 milliseconds until he sees the opposite on the other side this is what it looks like on the analyzer so we can record this the dr p is toggling between source and sink voltages and then the cable comes in connecting the far end and he finally sees the pulldown the analyzer shows it as sink attached to the left port so right there the source knows he’s attached to a sink you can only have one source in one scene right so they can swap later and we’ll look at that but this is once this is what you see when you’ve got an established contract or an established connection so this is the more complex case where you have to dr PS so both can act as source or sink but you have to figure out which is which they can’t both come up as a source and dr p’s earpiece will be common actually laptops tablets basically any battery-powered device with host functionality will have to operate as a deer pee so here is where both sides are toggling between RP and RD every 75 milliseconds it’s effectively a switch within these receptacles going from pull up to pull down pull up pull down at some point they both see our prd on the CC line the CC pin that’s at the higher voltage will indicate which one should be used here i’m only showing a single CC where but only one of the four possible orientations the other CC becomes V Cohn if needed and the DFP should always be the initial source for V bus so the sensing on the CC pins is what

tells the device how the cable is oriented then they came up with something else clever since they’re monitoring the CC line anyway let’s use the pull up voltage levels on CC to indicate the default V bus current so this is what the source will provide initially you know in legacy USB there’s always been a default voltage for bebas 500 milliamps for USB to that was bumped to nine hundred milliamps for USB 3 XZ type C devices can now source up to 3 amps by default so for example as a source an RP right after power-on no present RP voltages that will advertise his default power if the source shows 22k at 5 volts that would indicate he could provide 1.5 amps if he was capable of providing the three amps he would alter his resistance values to 10k at 5 volts can provide the full three amps / v bus provided it’s a type-c cable inning he needs he needs to see rd terminations from the sink so now it’s a type-c cable so that’s that’s twice the current available in the bc one point to spec and this is still completely independent of pd so you can create a low-cost type c device that doesn’t even use power delivery but can still charge at three amps so that’s that’s nice enhancement so i mentioned that pd and type c have a provision to swap both data roles and power rules again there’s a lot of confusion around this term DRP which used to refer to data swapping in the OTG world but you know this basically replaces OTG is dead great OTG is gone it went away I guess but in the PD world the erp only refers to power rule swapping so a DRP can say I’m getting low on battery you be the source now data-role swapping on the other hand provides a mechanism for a device to switch to the host role in USB maybe a printer wants to send commands to a camera for example so type C effectively replaces OTG with a sideband mechanism for doing the OTG swap for negotiating it you know the data will swap portion because that’s that’s what they need to do who’s the master who’s the slave okay I’ll move quickly through the message types so we can look at some actual captures so the CC pin allows us to detect the cable orientation after that CC becomes the main channel for negotiating and configuring all this added functionality now including power contracts the alt mode stuff both link partners will send and receive packets over the CC line there are 13 control messages and 5 data messages the data messages contains some kind of payload they move in both directions and there are actually a few messages that can be sent asynchronously by the source the sink and even the cable itself you the CC chin is considered multi-drop which means a dfp can target messages to the link partner at the far end or to each end of the cable they just use a slightly different frame delimiter to address each part of the link most of the frames targeted at the UFP the device or the DFP for that matter they use the SOP framing using SOP prime or SOP double prime allows the host to talk to the cable you’ll only see this type of SOP prime traffic if you’re connecting to an e marked cable okay this is pretty simple the start of packet orbit set is the first bits after a preamble this is your SOP delimiter it has a slightly different encoding when targeting it and II marked cable most of your SOP traffic as I said we’ll have the sink 11 12 encoding targeted at the far end but the SOP

Prime and the SOP double Prime again are only going to be used when talking directly to the cable you know we’ll look at an example next but there’s also some other special framing for hard reset cable resets all perfect really all participants in the link only need to receive three out of the four bits to recognize a valid SOP so there’s error tolerance built in cable messages are pretty simple typically you will see these during the initial power on this is a real capture of a key of the actual cable messages with our Voyager analyzer the link comes up we see V bus getting applied remember that this is an e marked cable so V Khan has to be applied first the analyzer doesn’t see V Cohn because remember it’s not past all the way through the cable we do see thee bus going on though so you see that at the top of the screen the source sends the discover identity command and the response coming back you see it’s a passive cable so no signal conditioners the SuperSpeed pins cannot be reconfigured on this cable so it may not support some of the alternate modes completely it’s a gen2 capable cable and it’s limited to three amps so this info gets propagated up where the device apology policy manager really software can use it to configure the link okay i meant i mentioned control and data messages this is the basic format both have a 16-bit header and the same the same basic format really all the fields are shown here the main distinction is that the control messages have no payload or data objects it’s 12 through 14 shown here are used to indicate how many data objects are appended to the message if that field is 0 it’s a control message if it’s greater than 0 it’s a data message so the message type is inferred by the value of this specific field this lists all the different control message types that are defined in power delivery to point o this shows the actual bits you would see in the type field again it’s only a four bit field control messages are sent by both sides and are used to negotiate power contracts and roll swaps this is really the nuts and bolts of power delivery protocol and we’ll look at most of these in more detail in a second the other major component our data messages by definition the data message has at least one data object these are transmitted immediately after the header each data object is 32 bits in length currently there are only four types of data messages defined supposedly there there may be some additional data messages coming in the next revision of the power delivery spec but this is what we have today there’s a few situations like a device making a power request or reporting’s capabilities we’re basically just needs to embed additional information in the message so that’s where these data messages get used and we’ll look at that in a second as well okay both TV link partners are supposed to identify their power role within the header this field I don’t think it gets used much by the protocol because upper layers are all ready keeping track of the power rule but it becomes real important when you start looking at analyzer traces once devices start doing role swaps it gets really confusing so we do show this in the packet header we abbreviate power role as PR and you’ll use this constantly to keep track of the source of the sink another important field the message ID field three bits in length with a value of zero to seven it increments with each sequential message it’s used almost like a tag and scuzzy where it allows a responder to tie an acknowledgment back through a specific command every PD message needs a good crc response from the far end okay and that

good crc needs to have the same message ID as the command that its technology so it’s well it’s a simple error recovery mechanism if you send a message and you don’t get a matching good CRC within 195 microseconds you’re supposed to resend the message with the same message ID just repeat it okay assuming the first one was lost or there can be collisions which can affect those crcs both sides need to keep track of that message ID that’s the key because it tells you if you missed a packet okay so pulling it all together this is a high-level look at the google chromebook initialization this single image represents the entire power on sequence after it’s connected to the type c power supply that comes with it okay so this is it’s an interesting case because it’s it’s one of the first pd products in the market so well what we’re looking at anyway is is not confidential these are production devices and and we’re capturing between the laptop and the on the left and the power brake is on the right port of the voyager in this in this example at the top we see the CC detection of the PD source and as we saw earlier the analyzer can capture these state changes on the CC line they’re labeled CC event and if we unstack these we’d see the left port is flipping between RP and RD terminations approximately every 75 milliseconds that’s the behavior we expect with a DRP in virtually all laptops will be dr p’s because they need to source current for charging and also supply v bus for bus powered devices so they won’t almost entirely exclusively come configured as dr p’s now this the the power brick is connected okay it’s showing our P so it comes up as the source and the Chromebook flips to showing rd and comes up as the defaults sink the analyzer can also detect the pullup voltages on the CC so from the source it knows the default voltage here is 3 amps in it and it specifies that as well in the capture okay if we were using an e marked cable we’d see cable messages next but the power brick uses an unmarked cable so it goes right into negotiating an explicit power contract our software now groups all the messages that are part of a transfer into a single event and again so we’re what we’re looking at here is a complete solid ated view of the power delivery negotiation and configuration process okay so you you if you were to expand these transactions that are part of this power negotiation you’ll see basically all the messages underneath it starts with the source advertising as capabilities the far end makes a request the source needs to accept the request and then send a PS ready looking a little more closely we see source capability message again coming from the brick this is the source advertising how much power he can provide we see object count of three so r ET do is to choose from power brick will typically just report a fixed power supply right battery-powered devices should advertise a battery object but not never likely you see that from a power brick also note that power bricks are generally not dual role okay you will never ask to become a power sink and pull current from the other side right he is a brick plug into the wall so when the Chromebook determines it

wants something being offered it asks for it with a request he uses the object position to make that choice by listing the object position one in his request here that means he wants whatever was advertised in position one the source can optionally accept the request he can also issue reject or wait if he’s not prepared to support the request right now after accept the source sentence p.s ready once his v bus is activated in use ready with the request voltage it’s not an explicit contract until the PS ready is acknowledged with a good CRC which we see at the bottom of this screen okay back to our 10,000 foot view our negotiation the source sends a sink actually I’d get sync capabilities and he’s sending that to the side that came up as a sink right this lets him find out what power levels the Chromebook can operate at so this is the brick sending a message back to the laptop if you expand that gets ink capabilities it’s going to look similar to the source capabilities only it’s coming from the sink there are three 32-bit videos coming from the Chromebook there’s a fixed in a battery PDO there’s also a variable P do the source basically uses this information to set policies at the higher layers okay so next we see the sink requesting a data role swap expanding this we can see the messages that are part of a data role swap so it’s initiated with a control message here it’s sent from the sink okay the source needs to good crc it and then also send a explicit except so why does the Chromebook do a date of role swap recall that by rule the source supposed to come up as a dfp or host by default the power brick so I mean it’s wall wart it’s not really a dfp it doesn’t have any real host functionality so this is one of the quirks of the power delivery spec this laptop is coming up as a device every time it’s connected to its own power supply so it can’t even send it the first command on this port until it switches to the host rule then it needs to interrogate the brick to see if it even supports USB so now the Chromebook is the DFP and I think that he’s the rightful host and he can query the power brick to see if it has any alternate modes whether it supports USB even and of course most most power bricks don’t so this is where the vendor to find messages are used we don’t have too much time to get into V DMS in the alternate mode stuff but what’s basically happening is that the Chromebook uses discover to identify the poor partner the discoverer s fit lets him identify additional vendor ID information it comes back with a Google sv ID if you trust that device ID then he’ll discover any alternate modes looking at that basically the response coming back okay the power brick only supports one mode which is what you’d expect from wall work right laptop sends please enter all mode one just like the power negotiation it uses the object position to pick which mode he really wants them to enter then there’s some additional proprietary messages sent by the google chromebook not clear what these are doing but then the crew the Chromebook issues a new request he wants to renegotiate for more power so he knows what the rick can provide now he request object 3 which is three amps at 20 volts and that’s it so the CC line goes quiet after this and it’s done so the behavior you see in this screenshot is it’s very consistent when attaching power brick to the Chromebook always goes through the same sequence you may see some differences if maybe there’s a low battery situation or some other variable but it’s very consistently the same when you’re

powering up these these two devices you okay just a couple of tips on testing this dude power delivery protocol we use our flagship Voyager system the m3 can see to capture all of this beauty traffic it does support 10 gig gentoo SuperSpeed USB and power delivery it has native type C connectors on it that allow you two to sit in the line and capture these exchanges couple of interesting points to be aware of when trying to test with type C avoid using two marked cables in the analyzer when you have a mark table the DFP can send cable messages right which actually pass through the analyzer to the other side the cable doesn’t eat the messages so these these SOP Prime packets will actually pass all the way through to the UFP and he’s just supposed to ignore it both cables will receive the same message and respond so you can have collisions or even contradicting responses as you know as both cables reply to the same command this could confuse the system because well there’s not supposed to be two marked cables in the link in most cases you can just replace one side with an unmarked cable it’s pretty rare but we’ve seen cases where one link partner won’t come up because he doesn’t see the RA terminations so the behavior of your of your system and so we actually created a custom cable that has ra terminations but no II marker so you would put that on port 2 and basically you’re spoofing the system spoofing that the device on the on the second port again it’s um it’s a cable that we make available and you can certainly contact uh Lacroix if you’re interested in that ok so the USB I F is finalizing the compliance spec for PD we are active with that group and are actually working on supporting the OPD compliance plan they found some vendors actually have configured their devices when they come to these workshops with only a single PDO like 1.5 volts at our 1.5 amps at 5 volts so then basically the testers can’t run a bunch of tests that are designed to verify that he can switch between different voltages properly so they’re ducking a bunch of tests so going forward it’s going to be required that OPD silicon must support at least PD to pdos okay also decon is an optional feature in USB so don’t over rely on it it’s possible it might not be there on some hosts uh roll swaps be sure and test under every condition possible this was another area where we found a lot of problems during the workshops alright well thank you for hanging in there that was fast and furious but I don’t worry very soon you’ll be able to replay this presentation on demand to catch anything you missed so type in any questions you sure you have some and i’ll go ahead and announce our lucky winner yogesh kumar congratulations you’ll be our lucky winner today and we’ll be in touch by email to get your details ok so let’s see if we have any questions we can address here you alright let’s see here’s one will power

delivery and type C systems still support the battery charging spectrum so type C is it’s designed to be fully backward compatible with the bc one point to spec so it’s possible that he could support the higher bc charging voltages as well as pd but it’s it’s always been optional for a host to support bc 1.2 so you can’t really count on that if you’re putting a type-c connector on a phone for example you may want to support both pd and bc 1.2 I could see that that would give you the best backward compatibility story so you could connect to bc 1.2 devices without any any problems so I hope that was helpful okay let’s see let’s see the spec currently states that all full feature type C cables must be electronically mark it slide dear slide 39 DRP logging every 3 75 milliseconds as per the type C spec alternating mode set thirty-seven percent on the milliseconds so the question is why is it fixed in your slides that alternating should be 75 milliseconds where did this requirement come from yes well I’m pretty sure this is a the the current requirement according to the latest spec and i’ll double check it but yeah I don’t think it has to be exactly 70 I think there’s a window there and what we see but most devices in 75 milliseconds on that in the in that range ok I’m sorry I’m having a hard time reading this tiny little chat window you do we require PD for data role switch is pd required for a data role switch that’s a good question power delivery is optional so that piece i believe is not required to do a data role switch so you can implement a type c you’d have to still have all the pd the type c logic for doing type c communication nah but i think theoretically it would be possible to make a mineral only switching mode and skip all the pd stuff okay can we switch roles between host and device on the go you on the go I’m not certain I follow that entirely OTG is basically going away and I think if you support it OTG could certainly there aren’t some a handful of devices out there that implemented some well element of OTG and I’m sure you could continue to support that if you wanted to if you elected to but we don’t see that being a viable market going forward on slide 96 the PD cable provided by Lacroix’s is to be used to spoof the controller how do we test our cable functionality if it’s working properly well this is a case where you would want to use the toilet I lacroix power delivery exerciser so this is a built in to the Voyager platform and it’s a full blonde you know scriptable exerciser that can communicate with / type C to power delivery endpoints including source sink and cable end points so you can actually write scripts to poke at those cables to your heart’s content now that power delivery exerciser actually goes into beta next week and is going to be released in September so definitely contact contact your local tell it on the croix rap if you want to hear more about that you what communication silicon is required

on the link end to support two or more pdos the support two or more p do so again all of these solvent power delivery silicon chip sets we’ve seen today are highly configurable and and they can be you know configured based on the application to support multiple pdos and present multiple options on how much power they can provide as a source so I think that you know this is going to be obviously vendor-specific how much how many p do is they support but if you’re talking with any of the major silicon providers you know they should be able to give you silicon net that gives you a full menu of PDO options does the analyzers support alt mode with DP how can we the user of the analyzer check for alt mode you yes the analyzers do support all mode of course with one caveat we don’t record the ultimo traffic if you go into an alt mode will in fact you’re in fact reconfiguring some pins to use for a different protocol and such as DisplayPort and God DisplayPort gets that signaling gets passed through and and should operate fine on those unused SuperSpeed pins we can see of course the commands that tell the device to enter those modes and some of the commands that configure those modes but we don’t actually see the logical ultimo device traffic these alternate protocols you okay is there a way to physically distinguish between Annie marked cable and an unmarked type-c cable you know that’s a good one we have seen many samples in the last two months and wealthy the marked cables are a little bit bigger on the housing side you could hold them up next to each other and I have a sled somewhere that does that but you can um you can obviously tell by physically comparing them at least the ones we’ve seen now of course with an analyzer it’s also possible to to see cable messages if there’s no cable messages now that’s that could indicate that you’re talking to a cable that doesn’t support Mark II markers you okay let’s see slide 23 someone didn’t raise an issue that I thought unmarked cables can support alt modes and that is a good question in an unmarked able support alt mode actually of course it should be able to because yeah we-well Apple for example ships are displayed after that is unmarked and it does support all modes yeah so I guess that would be an error if I if this slide stated that was not the case but yeah you can’t put all modes over all modes over unmarked tables I think there’s something called a USB 2.0 cable so it’s not full featured it’s not considered a full feature cable and there there may be limits to how much how well they support the all modes okay so that’s it’s good i’m glad you guys are we have this stuff carefully all right so is bc 1.2 still valid for type-c connector okay so i think i touch on that and it it still could be supported / type see if you in fact if you you had a type c receptacle and you want to support bc 1.2 because there are going to be type see the regular standard a

and standard be cables out there you could then implement bc one point to support on a type c receptacle do both control and data messages go over the CC line only in PB messaging both control and data go / cece and again those are power delivery specific but they also may be alt mode specific again they will only that’s the only way they get from one end to the other is over the CC line you