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
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?!? :)
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
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.
Do "Wireless interface" of BT and BLE support SPP?
Would you explain how to inquiry OBDII status by bluetooth protocol?
If we can achieve this by sending JSON format diagnostic request?
BLE does not support SPP as a standard. SPP is BT classic.
We use SPP on BT Classic. We use a generic GATT on BLE.
Both use the openxc-message-format to send/receive commands/data.