This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C129ENCPDT: Questions for Closed Loop USB Application

Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: TM4C1294NCPDT, TM4C123GH6PM

Ralph/cb1_moble,

I need more clarification of USBVBUS and the TM129ENCPDT based on the new information I just received. For some reason I was not getting email notification on the thread updates so I was unaware that there were updates to my original thread which Darren opened for me. Hopefully now that I am opening this up, I will get future updates. 

As for the original post, no worries on misleading me at first with the VBUS. Everyone makes mistakes but I am just glad you caught the error before I went too far. I had my doubts that the Tiva had the ability to output the 5V and thus the reason I asked the question. I also like to take a second to thank you and cb1_mobile for the support and hope to keep tapping that source with the following questions. 

Before I ask anything, I need to give you a little more insight to my application/challenges. We are trying to retro-fit a pre-existing design, with very limited space (about 5mm x 5mm), with a secondary communication path, USB. This path will communicate with our radio module. At present, we have one path that is UART based and it is running at 115.2K. The traffic on this new path will be low so USB1.0 will be fine. The first thoughts here, not mine, is just slap something together and I do not agree. I am trying to see what I need to do to make sure I have a  stable USB interface and don't have any issues with noise. I am by no mean an expert in this, thus the many questions.

1) First question, is there a way in firmware to lock the USB speed at what you want, in this case USB 1.0?

2) Are there different sub speed classes of USB 1.0 or is it 1.5Mpbs? 

If I run at USB 1.0, I assume that the design aspects are far less critical and I might be able to get away with a simpler design which is more forgiving. In early computers I have seen what looks like simple twisted pair wires and headers used to connect USB interface between the front of the tower and the mother boards.

3) Is USB 1.0 so forgiving that simple twisted pair wire and 0.100" center header enough?  Is shielding required? If so, where should shield be grounded?   One side, both sides?  

Assuming this is okay, my radio module is self-powered (it will be the device, Tiva the host) and will be hard wired to the Tiva and thus unable to be disconnected. I was planning on using a cable similar to the old older PC towers, described above, that will be soldered in directly to the board on each side. I expect that cable to be about 6" (or less) and shielded if need be. I could use a 45/90 ohm specific cable if one exists. In the event that this cable is not available and twisted pair is not an option, I could use a small 6" usb cable with connectors of each side but I am not presently set up for this so hopefully the soldered cable option is still viable.

4) Is there a 45/90 ohm specific cable? If so, can you point me to an example?

Now as for VBUS. While I know you are both concerned about VBUS and not being able to reset/shut off, there is more information that I need to provide that may reduce your concerns. The Tiva has the ability to reset the radio chip or totally power down the radio module via two  independent GPIOs.  One is connected to the radio module reset the other to a switcher enable which can turn off the power to the modules 3.9V power rail. This means that if the Tiva detects a fault on the UART/USB interface or radio communication, it has the ability to reset or totally power down the radio at will.  Based on the fact that I can reset or power the entire radio module off, I see function of USB0EPEN as a duplicate and thus the reason I was not planning on using it.

5) Do you agree that USB0EPEN is not needed if I can reset and/or totally power down the radio module itself?

6) Now if I am always connected, not monitoring VBUS, and always have a self-powered device do I really need a connection on VBUS?

7) Is VBUS used to pull the D+ and  D- lines up?

9) If so, does it have to be 5V? Can it be an external 3.9V?

10) Under the described conditions above, is it possible to run the Tiva USB interface with four lines, those being,  VBUS @ 3.9V, D+, D-, and GND?  

Thank you in advance for all your help.

Chris 

  • Greetings,

    First - may my small group thank you for the "kind mention?"    (Our desire to assist & guide is not always welcomed - yet as long-term/tested tech consultants - that IS our role.)   [we are strictly "outsiders" here]

    Your questions reveal great thought - usually that level of "Prep-Work" yields the best results - and (as we sometimes note) "Speeds, Eases & Enhances" our (and others) ability to credibly aid & assist.

    Unfortunately - we have never "dug anywhere near deeply" w/the TM4C129 family.    (we support numerous ARM Cortex MCUs (M0, M3, M4, M7) from 5 total vendors)

    We are highly experienced w/RF and Power Semi-Conductors - operating w/in the 2-10KW Power Range.    To properly drive such Power FETs - we employ a (brutally) expensive Network Analyzer - which is how we noted the "strict" trace details required to achieve your optimum, "MCU to Radio" impedance match/connection.   We will look into your request for guidance regarding the 45/90Ω coax cable.   (we employ large volumes of 50Ω cable - the 10% deviation (may) allow its use - if the newer cable cannot be sourced.)

    The only thing staff & I disagree with in your approach is the, "Absence of or reduced priority Experimentation" especially wrt the (unique) Radio to MCU connection.    A properly designed "Series of Converging Experiments" often "teases out" (unexpected) yet advantaged methods - which would otherwise be missed!    (maybe ... sometimes)

    Your ability to "solidly" enable/disable the radio (via 2 GPIOs under MCU command) - fully meets our (earlier) suggestion.

    Later this week we will meet w/one of our defense clients - this is likely to improve (both) our cable impedance awareness & USB 1.0 knowledge.

    [edit]   Love Ralph's Title/Subject change!   Headlines are important - they CAPTURE eyes!   Staff is checking - thus far - NEVER have one of our "defense or medical device" designs employed "USB" as the connection medium between MCU & Radio.    Might an "FTDI" chip (or similar) achieve USB -> UART conversion - completely eliminating the (unwanted) USB created complications & issues?     Were ALL of our clients' (past) similar (Radio -> MCU) designs wrong?    Worth considering - is it not?

  • Hello Chris,

    Sorry you had that issue with the other E2E thread. If you have issues again with this one, please let me know.

    chris summit said:
    1) First question, is there a way in firmware to lock the USB speed at what you want, in this case USB 1.0?

    So USB 1.0 is what is called 'low speed' and we don't actually support that. You'd be using USB 1.1 which is full speed. That is locked by the usblib, you have to use a specific configuration to change the speed to high speed if trying to use high speed with an external PHY. Not that you are considering that, but just to explain how the library switches speeds.

    chris summit said:
    2) Are there different sub speed classes of USB 1.0 or is it 1.5Mpbs? 

    There is not, but as mentioned the TM4C devices support USB Full Speed which is USB 1.1 and the data rate is 12 Mbps

    You can see this article for the list of speeds: https://www.sony.com/electronics/support/articles/00024571

    chris summit said:
    3) Is USB 1.0 so forgiving that simple twisted pair wire and 0.100" center header enough?  Is shielding required? If so, where should shield be grounded?   One side, both sides?  

    Most USB cables are not shielded so you should be okay without that for a typical application. Twisted pair should be okay for USB, that seems to be the standard. I don't know much about USB cabling so I am not sure about the center header piece. Might be something you can search about. Basics of USB cable: https://computer.howstuffworks.com/usb4.htm

    chris summit said:
    Assuming this is okay, my radio module is self-powered (it will be the device, Tiva the host) and will be hard wired to the Tiva and thus unable to be disconnected. I was planning on using a cable similar to the old older PC towers, described above, that will be soldered in directly to the board on each side. I expect that cable to be about 6" (or less) and shielded if need be. I could use a 45/90 ohm specific cable if one exists. In the event that this cable is not available and twisted pair is not an option, I could use a small 6" usb cable with connectors of each side but I am not presently set up for this so hopefully the soldered cable option is still viable.

    4) Is there a 45/90 ohm specific cable? If so, can you point me to an example?

    I've never looked into using another other than a standard USB cable or had that question posed before so frankly, I don't know. It may be possible to do what you are seeking here, but it's not something I really feel comfortable commenting on because that really gets to more of a system level issue and I only really have detailed knowledge with how our device works. I don't have a ton of background on the USB hardware piece.

    Not sure if cb1 can shed some light here with his firms many many years of experience. :)

    chris summit said:
    5) Do you agree that USB0EPEN is not needed if I can reset and/or totally power down the radio module itself?

    From the D/S, USB0EPEN is optionally used in Host mode to control an external power source to supply power to the USB bus. So if you don't need that functionality then you don't need USB0EPEN 

    chris summit said:
    6) Now if I am always connected, not monitoring VBUS, and always have a self-powered device do I really need a connection on VBUS?

    Given that this is a closed loop system, then yeah I would say you don't need that. I think if you use eUSBModeForceDevice that'd work well.

    chris summit said:

    7) Is VBUS used to pull the D+ and  D- lines up?

    9) If so, does it have to be 5V? Can it be an external 3.9V?

    10) Under the described conditions above, is it possible to run the Tiva USB interface with four lines, those being,  VBUS @ 3.9V, D+, D-, and GND?  

    No, those lines operate at 3.3V. The I/O's for TM4C129x are not 5V tolerant except for VBUS. VBUS is 5V to be able to help with power transfer to devices, not to drive the communication lines.

    Details on USB voltages: USB uses a differential transmission pair for data. This is encoded using NRZI and is bit stuffed to ensure adequate transitions in the data stream. On low and full speed devices, a differential ‘1’ is transmitted by pulling D+ over 2.8V with a 15K ohm resistor pulled to ground and D- under 0.3V with a 1.5K ohm resistor pulled to 3.6V. A differential ‘0’ on the other hand is a D- greater than 2.8V and a D+ less than 0.3V with the same appropriate pull down/up resistors.

    Source: https://www.beyondlogic.org/usbnutshell/usb2.shtml

    P.S. I am going to edit your thread title to be a bit more descriptive of the topic :)

  • cb_1moblie,

    In response to your:  "The only thing staff & I disagree with in your approach is the, "Absence of or reduced priority Experimentation" especially wrt the (unique) Radio to MCU connection.    A properly designed "Series of Converging Experiments" often "teases out" (unexpected) yet advantaged methods - which would otherwise be missed!    (maybe ... sometimes)"

    We are currently running experiments on this interface as I type. Unfortunately, my software engineer is having issues configuring the Tiva to run as a USB host and is asking me for some guidance. I fully plan on testing this configuration out to shake out any issues that may arise.  At present, I have taken our pre-existing radio and wired up the USB interface, to the best of my knowledge, to see exactly how it will work. The only real question I had was with the VBUS signal. I was not sure what exactly to do with it. I was unsure if it was a required input to the TIVA or not. From the radio side, it was just a digital in telling it USB is present. I think at this point, it seems that as long as the Tiva is not set up to look for VBUS, I can delete that connection and connect the VBUS on the radio side to the 3.9V rail and we should be good. 

    As for the cabling, I am presently using a standard USB cable with a micro connector on one side connected to my radio module, and the other side flying leads wired directly to the Tiva micro ports (I cut the other side of the connector off to expose the wires). I could try this approach in the final design if required and all goes well. I would be interested in what you find out about the 45/90 wire. 

    As for the FTDI chip, I have used that on some in house debugging tool we use in house to read serial UART data with much success but in this case, it would not help me. We are presently trying too open a secondary path to our radio module. The primary path is UART and is presently being used. There is no other Uart interfaces so i would neet ot go from USB to FTDI... then FTDI back to USB in too small a space. Not very practical when both sides already support USB. If I was gonig to do that, I should just bite the bullet and add a 5V switcher and run it with VBUS directly under the Tiva's control. 

    Remember here, this is a pre-existing design that we are trying to add a secondary channel to. This means my board footprint is decided and I am somewhat limited unless it is proven that I cannot reliably do it in the manner I am suggesting. Like you said, only testing will prove this. 

    Thanks again for the support and look forward to hearing from you. 

    Chris 

     

  • Ralph,

    Ralph Jacobi said:
    Sorry you had that issue with the other E2E thread. If you have issues again with this one, please let me know.

    Still having issues. i am not getting email notification that anyone responded even though it is checked to notify me.

    Ralph Jacobi said:
    No, those lines operate at 3.3V. The I/O's for TM4C129x are not 5V tolerant except for VBUS. VBUS is 5V to be able to help with power transfer to devices, not to drive the communication lines.

    Does that mean I should just leave VBUS disconnected at the Tiva side? I  think I read that the D= and D- are internally pulled up and do not require anything external. Is that correct? 

    Thank again for your support, 

    Chris 

  • Thank you - always pleasant to have one's work acknowledged.   (especially so when a "young team" invests effort!)

    chris summit said:
    Remember here, this is a pre-existing design that we are trying to add a secondary channel to. This means my board footprint is decided and I am somewhat limited

    Even after the *unique" (and beyond rewarding) experience of founding, working 6.5 days/week for >3 years, & then "Going Public" - I "shudder" at the prospect your quote presents.   Can you say, "Compromised Design?"    My new firm resists (similar) with all of our might - and absolutely insures that client recognizes (and properly acknowledges) - that "Teasing the past design into today's reality" presents significant: Time, Cost & Design Challenges - AND even w/great, focused effort - success may prove elusive!"     (I appreciate your "backed into a corner position" - offer this guidance via my time @ UCLA law-school.)   It is "normal/customary" that firm's (vastly) under-estimate the: cost/time/effort required - and (most always) "Lose Money on such deals!"

    Staff contacted 2 "Avionics Cable Specialist firms" late yesterday.    Great strides have been made in coaxial cable "size reduction" yet their coax inventories converged around 50 & 75Ω - neither offered your 45/90 target.   (we'll look further - visit a key client tomorrow...)

    Smart Staffer recalls one (dreaded) "Save/Extend a past design effort" - which may, "Work for you."    (maybe)    We were able to employ a CMOS-Level multiplexer IC to enable the MCU to, "Switch between 2 UARTs" (of course w/only 1 channel active at a time.)   She sourced a (very) miniature mux chip - this satisfied all parties...

  • Hello Chris,

    chris summit said:
    Does that mean I should just leave VBUS disconnected at the Tiva side? I  think I read that the D+ and D- are internally pulled up and do not require anything external. Is that correct? 

    Yes VBUS can be disconnected. D+ and D- are internally pulled up.

    chris summit said:
    Still having issues. i am not getting email notification that anyone responded even though it is checked to notify me.

    Okay, I alerted someone who supports the E2E forums and will see what I can do to have them look into this.

    When you said 'checked to notify me', do you mean the thread itself? If so, check your E2E user settings as well and make sure you have selected to receive emails from E2E. That should be the case by default, so if not and you didn't change that yourself, let me know because I may need to report that as a bug.

  • The problem with the multiplex is that the two channel are transparent to each other so you could have communication at the same. If we did not care if one interrupted the other, we could probably use the same scheme we have now and push the higher priority signal. 

  • All setting seem to indicate that I should be getting notification

  • Forum Notifications Failing & Virus Avoiding (hopefully, maybe) Greetings,

    Staff & I have uncovered much "high focus USB data" (likely beyond that which you sought) yet it is best that (you) serve as "editor/reviewer" - to absorb that which you most require.   Our source for much of this is a "top-cabin" firm - they were gracious enough to share "much" of their USB-Focused data w/us - for presentation here.

    As our firm's "Data Mine" should have value (FAR) beyond this thread - we'll post a further version in a new thread of our creation.

    chris summit said:

    3) Is USB 1.0 so forgiving that simple twisted pair wire and 0.100" center header enough?  Is shielding required? If so, where should shield be grounded?   One side, both sides?  

    Assuming this is okay, my radio module is self-powered (it will be the device, Tiva the host) and will be hard wired to the Tiva and thus unable to be disconnected. I was planning on using a cable similar to the old older PC towers, described above, that will be soldered in directly to the board on each side. I expect that cable to be about 6" (or less) and shielded if need be. I could use a 45/90 ohm specific cable if one exists. In the event that this cable is not available and twisted pair is not an option, I could use a small 6" usb cable with connectors each side but I am not presently set up for this so hopefully the soldered cable option is still viable.

    As fate would have it - our "expert" client/advisor believes your "least favored" interconnect option to be your best!    "Use a small 6" usb cable with connectors each side!"    Those USB connectors - installed at each end - do the best job of "Avoiding Signal discontinuities" - even at relatively low speeds.   Your alternate plan, "cable soldered in directly to the board on each side" should be avoided.   (massive signal degradation.)    In addition - a "shield" is preferred - such is detailed w/in the "grouped USB literature" we have located in your behalf.

    Your radio module is undescribed - does it not have an existing USB connector?   Our client/advisor recommends that if present - you strive to find an existing USB cable which mates w/your radio - and (hopefully) a "micro USB receptacle" - added to your MCU board.

    This vendor's "Design Guide" - presented here earlier - does a good job of detailing the creation of the "Properly Designed Differential Impedance Pathway" between MCU and (ideally) a proper USB connector.   Again - "how you will ADD this (demanding) pcb trace pathway to an (already) manufactured pcb" - is outside our recommendation & understanding.

    chris summit said:
    4) Is there a 45/90 ohm specific cable? If so, can you point me to an example?

    Indeed such cable exists - and one version is (again indeed) coaxial.  (some here were in doubt of that!)    We'll link two sources for you - (there is a 100 foot minimum) a "well earned" Green Resolving Stamp - may earn you several short lengths (courtesy my firm) w/out charge...   The weakness of such cable acquisition is your "Skill, Tool-Set, & Experience" in properly mating the cable ends to each connector.   (our literature "find" not only describes - but well illustrates - such process.)

    W-3627-26-90OhmUSBAerospaceCables.pdf

    and 

    47_U090-0422-100_90_Ohm_USB_Cable_DataSheet.pdf

    Follows several of those "USB Data Finds" which (both) our client & my group judged as, "Most appropriate for you/similar others."   You may note that my team made the effort, "Not only to search & find these (scattered) documents - but to provide a brief summary of content" - to speed & ease your selection.

    https://www.compuphase.com/electronics/usb_lowspeed.htm 

    Configuring a micro-controller for low-speed USB communication. Makes the case for - while presenting a (likely) eased method of implementation.   

    *** Note: As you yourself believed - "Use of the Low Speed USB mode is highly recommended!"    A vendor agent ruled against such usage - yet the MCU Manuals (for both classes of TM4C MCUs) note Low Speed's availability!    Might the "incomplete" API development have "sacrificed" the use of "Low Speed?"

    21 UniversalSerialBus(USB)Controller
    The TM4C1294NCPDT USB controller operates as a full-speed or low-speed function controller during point-to-point communications with USB Host, Device, or OTG functions. If the integrated ULPI interface is utilized, the USB can operate at high-speed. The controller complies with the USB 2.0 standard, which includes SUSPEND and RESUME signaling.

    18 UniversalSerialBus(USB)Controller
    The TM4C123GH6PM USB controller operates as a full-speed or low-speed function controller during point-to-point communications with USB Host, Device, or OTG functions. The controller complies with the USB2.0 standard, which includes SUSPEND and RESUME signaling.

    https://www.usb.org/sites/default/files/usb_20g.pdf 

    Recap of USB 1.1 Operation - and, "What USB2.0 adds."

    This backwards-compatible extension of the USB 1.1 specification uses the same cables, connectors and software interfaces so the user will see no change in the usage model.

    Design considerations or guidelines are described to minimize the signal integrity impairments like reflection, crosstalk and insertion loss.

    https://www.usb.org/sites/default/files/CabConn20.pdf

    This document describes the mechanical, electrical, environmental, design and performance criteria and voluntary supplier compliance requirements for USB connectors, cable and fabricated cable assemblies. In addition, this document provides detailed requirements for the design, approval and implementation of application specific USB connectors and fabricated cable assemblies.

    https://www.usb.org/sites/default/files/USB_SuperSpeed_CabCon_Whitepaper.pdf

    Indeed "Super Speed" is (for now) well beyond your requirements.    Yet the "lessons learned here" can only "add to & inform/advise" your (easier) design success!

    This document discusses how to manage the USB SuperSpeed connector and cable assembly performance, particularly signal integrity impairments. Key design considerations or guidelines are described to minimize these: including reflection, crosstalk and insertion loss. Though the focus is on signal integrity, some discussions are given to EMI/RFI and mechanical aspects also.   

  • Ralph,

    I think I found the issue with the email notification. It was being blocked on my side. I have since white-listed  the notification emails and hopefully will get them in the future. 

    Thanks,

    Chris 

  • Hi Chris,

    Great to hear.

    Hi cb1,

    Yes Low speed is not supported by TivaWare at all. The requests for low speed are extremely rare and not worth investing development time to do so which is why I said it is not supported. I should have been more clear to mention it's not supported software wise but in theory the hardware is capable. We would not provide any debug support for low speed mode at this time.

    Thanks for providing the details about interconnect options and cabling!!

  • Hi Ralph,

    I understand your position - yet when "Something is not promoted (i.e. Low Speed) - requests (necessarily) dwindle!"

    In the case of this poster - w/his "Off Board USB connection" requirement - Low Speed provides great advantage.    Such was demonstrated to us (Live) while @ our expert client-advisor firm.   Low speed succeeded while Full speed did not - this on (another's) ARM Cortex M4.   We were "shocked" by the amount our client's App paralleled this poster's!   (i.e. Off-board, USB "Command-Control" transfer APP.)

    The first USB article we presented (rather) well illustrated, "How an MCU may "Speed & Ease" the application of "Low Speed."    Perhaps the combination of that article - and your (existing) API (w/very slight modification) may succeed for this poster.   (And others - forced into a similar (i.e. Add-On) design application.)

  • Thanks for all the information. You and your team truly went above and beyond gathering it all and it is much appreciated. I took a quick look through it but I will need to spend some time digesting it all and deciding the best option for me. 

  • Thank you - it should be noted that our Tech Firm is often asked to, "Rescue a past, effective system (or key/critical component)" - which has gone (or approaches) "EOL."    Such has proven (both) knowledge enriching & profitable!

    Similar to your task - we're often presented w/a series of pcbs - and directed to, "Add new or improved/extended functionality."   We will then - most always - create a custom pcb which:

    • can be securely mounted to the client's existing pcb(s)
    • includes those components/intelligence necessary to meet client's spec
    • and then "feeds into" or otherwise communicates/connects w/client's existing pcb(s)

    As the "array of USB data" earlier provided reveals - USB presents a "particularly demanding" challenge.   Especially so "in your case" - as it is believed that, "No properly implemented, USB Differential pcb trace pair" exists upon your (past, fully assembled) TM4C pcb!    (i.e. to enable highly robust, USB transactions w/your radio module.)

    It is our belief - having designed such systems w/high success - that "SPI rather than USB" - warrants your full consideration.   This proves so as:

    • no exacting/demanding, differential pcb trace pair is required ... And may be "impossible" (at least highly difficult) to "add" to your existing (assembled) pcb!   (which had not anticipated nor included your client's (new) request for the ADDITION of that "differential USB pcb trace pair" - upon an (already) finished pcb!)
    • ability to "at will" - adjust the SPI Data Rate to maximize your communication's effectiveness
    • and "accepts" (even may welcome) a far easier "means of interconnect."    (i.e. treat the SPI Clock line w/respect - almost (any) cable or wire grouping has performed (very) well w/SPI - for my group)

    Should you "buy into this approach" - you'll likely require a bi-directional, "USB to SPI" converter.   (of some sort - we can assist!)    This converter may be mounted upon your radio module - or (as earlier described 'this post') - upon your client's existing pcb board set - and discretely "cable or wired in" to your (existing) TM4C MCU.   (you were "clever enough" to leave one of your MCU's SPI ports as "spare" - for such situations...)

    [edit/added]: Reviewing your "Add-On design requirement further" - might the choice of a, "USB based Radio Module" - in light of the (massive) new facts gleaned/presented - warrant (some) review?   Does not an "in depth read" of this vendor's "Design Guide" (earlier presented) highlight the complexity & strict compliance which USB demands?    It must be asked - as the (real benefits) of USB are not sought - "How can a USB-based Radio Module be justified?"   Further - are such radio modules "noted" for strict compliance w/USB's many demands?   Does not the (likely) combination of (potentially) compromised USB interconnects (at EACH End) give you (proper) pause?    Should such "RISK" be invited?

    Sometimes that which is discovered to be the "hardest way" ... proves not to be the "best or most effective way..."    Team having (already) climbed that mountain - may prove optimal in aiding your climb...

  • Hello,

    To poster (Chris) & those w/similar interest - this vendor has (also) recognized the need for a, "USB to SPI (or other serial mode) Converter."

    Young/skilled staff found & presents:

    Note that vendor - being Texas based - produced a "Texas-sized" pcb.    (the converting MCU has "80 pins" - those (possibly) more resourceful have implemented (similar) w/vastly reduced pin-count MCUs.   (Far more suitable for this poster!)   In 'fairness' to the vendor - multiple GPIO, ADC, PWM & DAC functions are included - swelling this board's size...

    Vendor's pcb (or those from others) prove ideal for "development" - then may be "Voodoo Shrunk" for production applications.   Note too that "Any" proves (somewhat) of an over-statement - "CAN" (a long recognized Serial Bus) is Not included.   (yet is - by resourceful others - somehow "USB2(Almost)ANY" does not yield the same "ring!")