IOS

[Thomas Cross]

Any updates on plans for IOS?

thanks, TC

[Christopher Peplin]

Hi Thomas,

We're actively investigating this as we'd love to able to support all platforms, but I can't say for sure what will be possible or when yet.

Actually, this would be a great place for some help and advice from the community. Are there any iOS experts in the group? What do you think would need to happen to make the OpenXC vehicle interface compatible with iOS?

Namely, these are the problems and questions we have:

Bluetooth and USB I/O (besides the A/V protocol stuff) requires support for the iPod Accessory Protocol (iAP), and that requires an Apple authentication chip on the vehicle interface. It's currently difficult to impossible to do this even for hobbyist-oriented parts without an expensive and proprietary license agreement with Apple (the MFi program).

Bluetooth low energy doesn't require iAP, but it would require a completely different Bluetooth module on the vehicle interface (from either SparkFun's BlueSMIRF RN-42 based board that we recommend right now for the chipKIT vehicle interface, or the RN-41 that we're using in the prototype of a streamlined kit that we just unveiled). There are very few (or no?) Android devices that support Bluetooth 4.0 or BLE right now, too, so it would effectively mean the vehicle interface would fork to support iOS. Lastly, the max throughput over BLE is much less than Bluetooth or USB, so we would have to add throttling to the data stream to intelligently decide which data elements should be allowed through. A vehicle that implements every OpenXC data point at the frequencies specified on the OpenXC site right now runs at ~38KB/s. Granted, some of the frequencies could be decreased without too much practical effect on applications (torque at 60Hz is likely more than most applications need), but restricting data is counter to our goals of opening up as much as possible. We are trying to add more signals all of the time, and if we're fighting a ~35KB/s max throughput on BLE it would be unfortunate (but not a dealbreaker).

If we were somehow able to get the data into iOS (e.g. over wifi, since the chipKIT-translator does have an Ethernet port and could be hooked up to wifi router), it's not clear what is the best way to keep the data stream alive and present the data to applications. The Android library for OpenXC depends quite a bit on Android's freedom and flexibility with background services. We have one background service running in a remote process to manage the connection to the vehicle, and the data stream is multiplex to any and all OpenXC-enabled apps running on the device. With iOS the focus on foreground app performance means that background apps are significantly restricted and killed off after a relatively short time. From our own iOS experience and from our consultations with a few other experts, the best suggestion seems to be that each OpenXC application in iOS would need to manage its own connection to the vehicle interface, and no more than 1 could be running at any time. As soon as you switch away from an OpenXC data logging application, for example to check an e-mail or switch music tracks, the data stream would stop. That's a significant blocker for many applications. That said, we have been focused almost exclusively on Android for the last year, and there seem to be some applications out there that manage to keep a data stream going in the background - if anyone has ideas on that, please speak up!

Chris

On Thu, Mar 28, 2013 at 8:23 AM, Thomas Cross <talkn...@gmail.com> wrote:

Any updates on plans for IOS?

thanks, TC

--
You received this message because you are subscribed to the Google Groups "OpenXC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openxc+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Kalin]

Thanks for clarifying the challenges in bringing OpenXC to the iOS platform.  I think you're okay with iOS background processes (there are a few ways to bypass the 10-minute limit on running in the background) so perhaps a possible way to work it would be the Ethernet/Wifi method, but I agree that's a kludge at best. 

As for the iPod Accessory Protocol (iAP), I don't think the license agreement is expensive as you think, especially for an OpenSource project.  And even so... aren't you partially funded by Ford Motor Company?!?  :)

[TJ]

Heh, yes, we are at this point funded by Ford :)  One of our concerns is how to make the hardware accessible to the open source community in such a way that Ford doesn't have to directly manufacture every OpenXC vehicle interface.  Right now, to even order the iAP chip needed to interface with iOS devices, you must have an MFi license from Apple, so even if we were to release an open source board design that was compatible with iOS, it wouldn't necessarily do the community at large much good.

--T

[Gabriel Weis]

As far as I know you need to be an electronic hardware manufacturer or have one in the back to get the MFi. At least for commercial projects. For open source I'm not quite sure.

[Biplab Deka]

Hi Chris,

A digression here: you mentioned "streamlined kit that we just unveiled". Could you point us to it please. A google search for a streamlined kit did not get me anywhere.

Thanks,

Biplab

[Christopher Peplin]

Hey Biplab, nothing posted yet but we will be sure to make a post in the group when it is available.

Chris

[Robert Vogt IV]

We are looking into making an interface available.  We make a PIC32-based triple-CAN OBD-II interface.  We are MFi licensed, but we've found it easier to use Bluetooth 4 Low Energy as an interface for iOS.  Possibly looking at making a different Android and iOS unit, or using a dual-mode BT interface.

-Robert Vogt

IOSiX

[George Mueller]

That sounds interessting, how long will it take until someone can actually buy this interface for iOS?

  GM

[Gabriel Weis]

What about this ones:

http://redpark.myshopify.com/collections/all

Have you tested one?

[Al Linke]

An idea for iOS:

The IOIO board which is a PIC24 based development board supports both USB and Bluetooth connections today to Android devices and PCs. For the Bluetooth support, the IOIO board leverages btstack which is an open source bluetooth stack for embedded devices. So for users who want Bluetooth, these users simply plug in a Bluetooth USB dongle into the IOIO board's USB port and for those who want USB, simply unplug the bluetooth dongle and connect your phone directly over USB. So if you could get btstack going on the ChipKit32, then perhaps something similar could be done.  Or perhaps porting OpenXC to the IOIO platform would be another route. 

Note that IOIO does not support BLE or iOS today, that would need to be added. I am actually working on a project now to add BLE and iOS support to the IOIO so if interest, that could be a collaboration.  btstack does support BLE so its possible at least in theory.

As reference, here is the USB BT 4.0 dongle I use today for my project which works great on Android in non BLE BT mode. I am hoping BLE will be supported using this same dongle but haven't got that far yet.

[Douglas Lowder]

Perhaps it would be possible to use the new background refresh feature in iOS 7 to keep the data stream up to date for an iOS app.  The basics are described in this tutorial:

http://www.doubleencore.com/2013/09/ios-7-background-fetch/

Cheers,

Doug

On Thursday, March 28, 2013 2:29:24 PM UTC-7, Chris wrote:

[Ashok Yalamanchili]

The background refresh is controlled by iOS itself, which means we cannot force a background refresh from the app itself. 

[Chris]

There's a team of students at Carnegie Mellon University's Silicon Valley campus who are working on an  iOS port at the moment (hi Mari and Albert!) and they recently hit a stumbling block - it seems that even if you have iAP enabled Bluetooth hardware, there is no facility to use the Serial Port Profile (SPP) from iOS! That's what the current VI uses and without some sort of workaround, it seems like Bluetooth 3.0 on iOS is a dead end. Anyone have any insight? Can we jam data through the HID profile at a reasonable data rate?

Chris

[Robert Vogt IV]

In terms of iOS, the best method would be Bluetooth low energy, as this doesn't require the hardware to have an apple auth chip. Data rates aren't great but you probably don't need much. Thanks. 

Robert Vogt IV

CEO

IOSiX, LLC

315 East Eisenhower Pkwy

Suite 211

Ann Arbor, MI  48108

P: +1-734-707-7720

C: +1-734-730-9690

rob...@iosix.com

--
You received this message because you are subscribed to a topic in the Google Groups "OpenXC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openxc/mUEiJDZ0oXg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openxc+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/openxc.
To view this discussion on the web visit https://groups.google.com/d/msgid/openxc/e58e2061-4d02-495b-84d0-232badbf856c%40googlegroups.com.