xenoDisplay (was: xDisplay)

This looks very nice.

WiFi seems a little bit like overkill - did you consider a Bluetooth (BT) version? Is BT SPP (serial port profile) available via the iPhone SDK?

On my todo list is a BT interface to our BCU. I have a Droid so Android will be the first target client I develop - but it would be great if the user could choose your iPhone app and software and have it work with our BCU+BT setup.

There are a bunch of Android based mini tablets coming out - so I'm hopeful that not only phone users will be able to "get in on the game". My ultimate solution would be a suitable dock on the dashboard of the C7x and user gets to specify it at time of order: the iPod, the Droid, the Archos media player...

:-)

Best of luck - and keep us posted.

I totally agree wifi is overkill and bluetooth is the way to go, or even wired USB, or a docking station/cradle/USB. iPhones have gotta have bluetooth (and a bit of yahoogling shows they do)

We chose wifi for these reasons:

- The Iphone SDK doesn't allow bluetooth communication protocols like serial, its completely locked down and only allows for audio transmission. That means no SPP support in the latest SDK.
- The serial port on the iPhone is disabled for use. If you want to use it, the company must apply for "Made for Iphone" developer status. The process is long, drawn out and they take away a lot of profits to license each product sold. Plus, apple may reject the program at will.
- The USB port on the iPhone is a device-only USB connection. The Iphone doesn't enable USB Host, which would be needed for Communication to another device. This is also locked out on the SDK, its for sync only.

We chose iphone because the audience is large and there are many devices already out there. Android will prove to be much easier, but there aren't as many devices out there. If we develop worst case for the iphone, the product can easily be ported to other wifi platforms. From a developer standpoint, its one hardware device for multiple hardware plaforms.

Unfortunately, Blue Tooth is out of the question (until Apple decides to change their draconian hardware rules).

Sigh, you (don't) gotta love Apple... they are the master of the closed system and yet folks do love 'em. Shame about that.

OOhh, looks rather cool. I'm definitely going to keep an eye on this. Maybe we can get you guys interfaced to John's bike design and I'll be a beta tester for that too. ;)

I think WiFi might be better than other, shorter range options.

The ability to monitor the charging process remotely would be great!

And Bluetooth is then still available to listen to music etc whilst riding.

I think WiFi might be better than other, shorter range options.

The ability to monitor the charging process remotely would be great!

And Bluetooth is then still available to listen to music etc whilst riding.

Those are good points. I must confess I don't know Bluetooth's ability to multitask - I'll need to investigate that. I know it's point to point but can one multiplex different profiles?

The idea of getting a longer range for monitoring charging is a neat idea. I must admit I've been mostly concentrating on the discharge side of things (shortsighted of me!) My feeling on monitoring charging is that it should become less critical as we manufacturers get better at it and you customers get confidence in the fact that we've gotten better at it. Of course there will always be folks (me very much included) who will want access to the data stream - but probably not the "average customer"?

The BT solution is very easy for us to implement - it's simply implementing the standard BT Serial Port Profile (more accurately getting someones pre-packaged solution!). I'll have to look at serial to WiFi bridges and see if they exist (I'm sure they do) and how much they cost and how well they could be integrated.

Thanks Mik I stand corrected! I can now see some advantages to WiFi over BT. However, BT may still have a place in a "complete solution".

Sorry if this is a little off track from the original announcement...

I think only one BT connection at a time, I can't connect 2 devices from my laptop, phone or home PC.

FYI, We are using a serial to wifi bridge, that's what allows us to go from two serial devices to the iPhone. That's what this whole project is, to integrate that solution for others to use on their EV's. This device allows us to connect controllers/bms/etc to the locked-down phones, and the open phones, and to laptops/desktops etc.

FYI, We are using a serial to wifi bridge, that's what allows us to go from two serial devices to the iPhone. That's what this whole project is, to integrate that solution for others to use on their EV's. This device allows us to connect controllers/bms/etc to the locked-down phones, and the open phones, and to laptops/desktops etc.

Great to hear - can I be a beta tester? (seriously!) What's the target price?

Is it simply a bridge or does it do some form of conversion from whatever the controller/bms stream provides and whatever the xDisplay (or other) wants to consume?

I'd love to get involved as a potential customer, possibly a manufacturing partner (but my guess is you've got that covered).

Looking very pretty, chaster.

And I really need a temp gauge on the C130 I'm testing for Current Motor Company. When's the beta test opening up, and when can you support a Kelly Controller? :)

Well, unless the kelly supports a temp sensor, I think you're going to be out of luck.....

Support for the kelly is forthcoming, we're going to work on Curtis and Elithion first, then alltrax, kelly, zilla, etc. We plan to release different versions as we add devices.

Also, its not known about the unit that the Kelly plugs into, we need transparent visibility to the kelly. If custom software is needed for a particular item, it would have to be contracted to Xenopi Studios (Eric's company).

Well, unless the kelly supports a temp sensor, I think you're going to be out of luck.....

Support for the kelly is forthcoming, we're going to work on Curtis and Elithion first, then alltrax, kelly, zilla, etc. We plan to release different versions as we add devices.

The Kelly deals with two temperatures: a temperature input from the motor and an internal controller temperature.

In the documentation for the RS232 interface (the stuff I sent you) you can find how to read the internal controller temperature. I'm not sure if you can get the motor temperature via this interface (I suspect you can but it doesn't seem to be documented).

You can get access to the Kelly and this data stream directly via the RS232 / DB9 port on the device itself. So, for the general Kelly population you should have everything you need to support the Kelly.

Also, its not known about the unit that the Kelly plugs into, we need transparent visibility to the kelly. If custom software is needed for a particular item, it would have to be contracted to Xenopi Studios (Eric's company).

For CuMoCo's bikes we will be covering the RS232 / DB9 port with a tamper evident sticker. Unfortunately we can't support general access to the Kelly via this port because that also allows the owner to change the calibration. However, we will allow read only access to the same data from our own BCU. This would amount to the custom software that you mention. We'd be happy to collaborate with Xenopi if there's enough demand for the xenoDisplay on our bikes - however, at this stage we're not in a position to pay for Xenopi to develop software to support their product on our bikes. I fully understand your position - there's not many C1x's out there.

Yet... ;-)

It's a bit of chicken and egg for both of us. We plan on supporting Kelly controllers within a few revisions, so once that milestone is reached, doing a slight modification to get data from your BCU shouldn't be THAT hard (unless you decide to make it hard.. LOL). We're making good progress so far so by the time you have C1x's out there in the public "en masse" (hopefully) we should be ready to work something out. =)

Agreed. We'll be happy to work with you when it makes sense for both sides.