Monday, August 15, 2011

Redpark Serial Cable Electrical Characteristics

I'm currently doing some contract work that involves developing hardware to plug into an iPod device.  Of course, we're inevitably having problems getting the MFi license needed to talk directly to the iPod, so for the short term, We need a different solution.

We decided to develop the hardware to talk over RS-232, which can be fed into an iPod using the Redpark Serial Adapter.  This is a pretty neat little device; selectable speeds up to 57.6k baud (a little slow, but fine for telemetry), comes with a whole SDK to easily integrate into your app, and comes with a loopback test dongle.

Of course, having our hardware talk over RS-232 instead of straight TTL serial has the disadvantage that RS-232 has no provisions for power.  Batteries were a no-go, but we thought it would be possible to maybe "harvest" the needed power for our 3.3V electronics off of the RS-232 data lines coming from the iPod.  This is risky, since many RS-232 adapters cut corners and take liberal interpretations of what +5-15V actually means, so having this vampire power supply work depends on really how well this Redpark cable implements the standard.

Turns out, they implement it quite well!
Scope image of a mark-to-space edge on the RTS line.  2V / 1ms per div. Don't you love my 70's-tastic Tek 468?
 An RTS edge again, but at 2V / 0.2μs per div to check the slew rate.
9600 baud loopback test. 2V / 1ms per div.

Looking at those images, and doing some tests with my volt meter, the Redpark puts out +6V open, 30mA dead-short, and -5.6V open, -22mA dead-short.  That's a lot of power!  I'm going to be able to run my electronics off the RTS line no problem.  The cable also appears to implement all eight data lines, which can also be rare in cheap adapters.  They even meet the slew rate spec of <30V/μs, with a slew rate of only 7.5V/μs.

So long story short, Redpark didn't cut any corners here; The signals are all implemented according to spec.  The iPod connector does feel a little cheapy light, and I'm a little disappointed that their demo app is just a loop-back and signalling line test, and not something at least remotely useful like a little hyperterminal app, but the BB-9 connector feels solid, and I'm certainly not longer apprehensive about building our project on this product.


  1. Hey Kenneth. First-timer on your blog but this is a great post and yes the 70's-tastic scope is awesome and reminds me all too well of my under-funded EE college days (late 90's era). And it's great to know that I can power stuff from RTS (thanks).

    I have just started my own redPark adventure in an effort to save some time for a customer-demanded hardwired interface. So far... meh. Before I nag, let me say that I am a very experienced iOS and hardware dev. I've done iOS external accessory interfaces before yet only over bluetooth.

    And I agree, their demo app is very polished but egregiously useless. I can't believe they shipped a loopback adapter for that. I wish they would have instead put that cash into making a useful app. So today I made my own hyperTerminal companion app just to get things going.

    I am finding that even with the default 9600/8/N/1 settings, that what I send from iOS isn't always what arrives to a hyperTerminal session. What is annoying is that if I wait a good few seconds before sending one single character/UInt8*, the cable mostly works. But if f I get "crazy" and add more characters, then they don't always arrive like they were sent. For instance, the number 5 sent from iOS will show up as a 5 90% of the time, and then eventually it turns into a 7 or some other random character that I can't even replicate here.

    Sigh. This was day one and perhaps a gender-changer adapter that I'm using is the culprit. But I'd like to know how you are doing at this point?


  2. 0_0 That's deeply concerning. I'm going to have to implement some redundancy checks if that is really so. Going to be sending some bit-critical data over it. Clearly they're doing some processing in the dongle, since all the OOB signaling and the channel itself are fed through a 115k serial port on the edge connector (I'm guessing, having not gotten my MFi license yet)

    My custom PCBs have come (, which I'm about to post about, but the iOS software isn't part of my contract. I'll relay your concerns, and things might get real dicey next month when we start tapping the assumption that this thing actually works.

  3. Ron has followed up with me offline that his problems were entirely on part of a faulty adapter, so my glowing review of the cable stands.

  4. Kenneth - new to your blog as well, sounds like you are doing a similar project as I am, but mine is more of a hobby.

    Ron - new to development and am trying to work on a project that uses the Redpark serial cable. Do you have any interest in sharing the hyperTerminal app code that you have developed? Seems like something you could even submit to the App Store.


  5. Kenneth, I've been following your blog for several months through rss, but it's only today that I googled for serial port of ipod and found out this post :-)
    I've checked another project (CADashboard), which utilized the custom version of this redpark cable. It seems, this cable creates a virtual serial port through USB pins of the connector, rather than uses a normal one.
    What I'm thinking of is that both of these projects might actually not need this cable, as ipod/iphone/ipad actually has 3.3v serial port pins in its connector. What I'd like to do is to avoid this needless conversion and connect attiny2313 directly to the serial port.
    Do you know, what's the way of conducting serial loopback test on an ipod? What if ipod's serial port doesn't support hardware control (actually, I don't know)
    Could you please share the Redpark's sdk? And, if it's not a secret, how much would it cost to develop a simple µc device and firmware with you?

  6. @Big Guy: I believe that the Redpark cable actually communicates through the 3.3V 115k serial port, which is why it's limited to 56k (for OOB signals).

    The reason why all of these projects are using the RedPark cable instead of using the 3.3V serial directly is because Apple requires you to get an MFi license before they'll let you develop hardware for iOS. These licenses are expensive and take a lot of time and effort to get, so most projects that do use it require that you jailbreak your iOS device.

    I never had access to the RedPark SDK. I was hired as a hardware contractor, so they provisioned my iPod on their SDK and sent me binaries.

    I typically charge $30/hr plus expenses for custom engineering work, but are currently in the last month of my undergraduate senior project, so of all the things I have enough of this quarter, spare cycles is not it. I've also about had it with supporting people on iOS projects; I end up spending a lot of time and effort on their projects before they finally figure out how incredibly difficult it is to work as a developer in an Apple environment and give up.

  7. Sorry, didn't get email notification.
    Take a look at that CADashboard code, which is based on RedPark SDK. It never uses anything called tty.iap, instead, it uses this string:
    if ([accessory.protocolStrings containsObject:@"com.southernstars.sw9a"])
    sw - skywire - is a branded version of redpark.
    As far as I got it's a USB connection (probably, you can take apart that redpark cable). Or they might use USB to identify their products? But still, I can't find in that code anything that would relate to serial communications.
    What's OOB signals?

    Who cares about MFi? All in all RedPark states that the cable is intended for hobbyists and requires jailbreak, doesn't it? Or may be utilizing a plain 3.3V level connector violates the license, while using RedPark MFi products doesn't? I'd add another reply in iPod+Arduino thread.

  8. OOB is the out-of-band signals, which are the other 6 pins on the DB-9 connector (RTS, CTS, DTR, etc).

    You do not need to jailbreak your phone to use the RedPark cable, which is the entire point. They went through all of the work and effort to get the MFi license from Apple (though I have no idea how; someone must have pictures of someone...) such that they could build this piece of hardware exposing a serial port to iOS software developers. What you can't do is then sell your application that uses RedPark's MFi license, because Apple isn't crazy enough to open the barn door that wide. Without an MFi license, you don't get access to the documentation for their magic keyed IC which must be in every licensed peripheral that does anything more than issue media center control commands (play, pause, skip, etc), which I think you can do unlicensed.

    I simply have had no experience trying to talk to the 3.3V serial directly, and am not willing to risk my iPod to either jailbreaking or even simply poking around on the edge connector. I helped a group jailbreak their phones so they could use Bluetooth serial adapters with them, which may be another way to meet your needs, but again, I had nothing to do with the iOS side, but only the Bluetooth adapter and hardware development.

  9. well, I don't know what "magic keyed IC" is and what you are speaking about, but just now I managed to send various strings from my attiny and to see them in ipod's minicom. without redpark's cable. now I am going to study ios development to alter the code of cadashboard so that it reads data directly from tty.iap ;-)
    by the way, I didn't need any external clocks for that - it just works and works nicely from the internal rc oscillator.

  10. This is with the iPhone jailbroken, correct?

  11. yep.
    all in all, you can't distribute apps that work with Redpark cable on non-jailbroken devices, can you?
    i'm thinking which is easier - learning iOS development or replicating (simulating) the cable. still can't understand what it does. on the one hand, it seems to be sort of a usb device, which i recognized as com.southernstars.sw9a. on the other hand, you insist that it works over the serial pins. does it pass the pointer to the stream (tty.iap) internally to the application? do you think launching a usb packets capturing utility on the ipod (or even connecting the cable to the usb port of the mac, after some soldering) would help to understand how it works? is it at all possible to simulate that cable with another microcontroller? I wonder how much time would it need for the brave guys from China to cope with that task.