How can we improve OpenXC's visibility, branding and marketing?

[Chris]

Hi OpenXC devs,

Another day, another OBD-II related project pops up on the web. I'm thrilled to see continued and growing interested, but I have to admit that I'm often frustrated that I see so many other projects starting from scratch. I'm trying to reach out to as many of these other hardware and software projects as I can to see how we can work together to build a critical mass, but I haven't had the best luck.

One of the primary motivators for OpenXC was to collect the distributed group of car hackers under one banner. It's too easy for automakers to dismiss an individual tinkerer with an OBD-II dongle asking for more data. A critical mass of car owners making it clear that access to data influences their purchasing decisions? That's harder to ignore.

I wonder how we can make OpenXC more visible. I know we can do better with marketing and focusing the content on the web page to our target audience. I'd love any feedback, copy edits, web design changes, or whatever else folks can help out with.

For example...

Someone's looking to start experimenting with data from their car. They've heard about OBD-II and they know some Python. I think they might really like the OpenXC Python library and a VI, since it would let them experiment with simple messages but have much higher throughput and an easier to use API than a $15 dongle from eBay. How do we "sell" to that person when they land on openxcplatform.com?

Car hacking is a big topic right now, and a lot of the researches seem to start from ground zero and build a completely new car data tool. How can we let them know we've done a lot of that work already, and they can leverage OpenXC to get to their core research even faster?

...etc.

I've written a large amount of the website content, and I don't think that's ideal. I'm too close to the project's implementation, and I only fit 1 or 2 of the many types of interested users that might be able to use OpenXC. It's usually best if someone besides the person that implemented some code writes the user-facing documentation. I make way too many assumptions that I don't even realize I'm making!

Anyone have thoughts about this?

Chris

[Kevron Rees]

The market is intrinsically fragmented.  OpenXC itself was a fragmentation.  Nobdy, which became Automotive Message Broker predates it, and obdgpslogger predates nobdy.  Nobdy may have represented the first vehicle abstraction software that I know of, but everything subsequent to date has merely been a me-too thing addressing different niches or using different languages.

OpenXC has a few good things going for it: 1) a hardware platform that works with some Ford vehicles.  2) Android bindings which enable readily available mobile hardware and an established ecosystem.  However, OpenXC has a few drawbacks.  First the name isn't clear at first glance what it is.  We know it's open, but to figure out that it's a vehicle abstraction system, you need to do a little reading to figure out what it is.  Nobdy would suffer from the same problem.  Automotive Message Broker (AMB) is a little more clear about what it is and what it does.

Coincidentally, OpenXC's two strengths are the things AMB lacks: a hardware platform that works on real vehicles (aside from OBD-II), and Android support.  AMB, however, is standards based: Implements the GENIVI Vehicle Interface and the W3C Automotive Business Group/Working Group Vehicle Data specification.  Is there a way to combine these strengths while reducing the fragmentation and improving exposure and visibility?

I believe there is.  Here's what I propose: OpenXC and AMB merge.  AMB implements as a "sink" plugin (client facing) the openXC protocol so existing openXC android and python bindings should "just work".  Little to no OpenXC code is lost.  All is gain.  Create a new hardware platform: The Intel Edison + STN1170 running AMB.  Ford rewrites their firmware blob as a closed AMB plugin (or simply generates it using AMB's CAN db 2 plugin tool).  I have a feeling that we may be able to convince other OEMs to produce plugins for the device since AMB has visibility in GENIVI and AGL (automotive grade linux).  The STN1170 MCU will give users access to HS, MS and SW CAN as well as OBD-II.  This would be an improvement over the existing hardware and when used with the Edison platform, will enable some pretty cool features: logging, USB host support, wifi, bluetooth, etc.

I'm just throwing this out there.  I've already started design work on the Edison "super scantool".  I hope to create an open source project for it soon.  I don't think it makes much sense keeping two separate communities.  The communities are small and both can be serviced better by more tight collaboration.

Regards,
Kevron

--
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.
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/f5ce6d97-be43-4601-afa9-ffb0833cb2ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ming xu]

I am thinking maybe we stand more on Developer side and mostly the way we consider a problem is limited. 

If we regard OpenXC as a open source project, it is a rule among developers that better coding and document support are good. But if we consider it as a product, there are lots of problems we need to consider.

1. Who is our target customer?  Do we provide them with enough support tools and communication method?

    

    I would like to separate target customer into different level based on their interests. If some car hackers begin their journal and take a look at OpenXC, their interest might not be enough to dive into coding level.

    OpenXC build a very good foundation, but might not enough for people who has not that much interest. If we want build a eco-system for all interested people, we need to design more tools for different level people.

2. What's the concern of people who know OpenXC but not choose OpenXC?

    For some commercial project, there might be some concern on open source software. Whether they need to put their code public or not? 

Maybe we need focus partially on design the eco-system and marketing. 

Participate in more related conference?

Actively looking for partner?

Actively introduce OpenXC to people who might interest?

Ming

[Ian]

I think the biggest problem is the what can we do with it, we are promoting that it is open source, but there are few actual examples of what to do with it.  I was working on a project for having a dedicated laptop connected to it so I can fiddle with it, but school is in the way right now.  I would think it would be cool if someone could show how to control your car with your phone (i.e. lights, radio, windshield wipers, etc.) then this project could have the publicity it deserves.  We are limited this project very much because we don't have a collective initiative, yea maybe to opensource OBD, but there are no team projects for implementation other than a few things displaying variables.  We need to do something with those variables other than display them.  I am a developer, not a designer (aka good at making something if someone comes up with a "what if we do this..." we'll I'll help make it and see where it goes)

[Christopher Peplin]

Thanks, Kevron, Ming and Ian, I really appreciate all of the different perspectives. I'm still looking for more, if anyone has more comments! This turned into a bit of an essay, so I'll break it up into a few sections.

Everything to Everyone

I think that given this is an open source, volunteer project, we have to avoid trying to be everything to everyone. When I was full-time at Ford working on OpenXC, I was a bit more confident that we could make the car a good the first programming experience a new developers. I spent a lot of time documenting the installation and setup, and a lot of my on-site training was for things like installing and getting familiar with the Android tools and explaining CAN.

I'll admit that was sometimes exhausting. I don't think there's anyone with enough volunteer time or energy to continue with that effort. I think the docs should start to defer a lot more to the rest of the Internet. 

While we don't want to discourage anyone, I don't think that OpenXC should be most people's first experience with programming. If you've never used Android, the command line or Git before, this is probably not the right place to start. We're working to get the Android library updated to work with the new IDE from Google (Android Studio), and at the same time I think I'll trim down the amount of Android setup docs on the OpenXC site to make it more manageable. 

Standards

Kevron, you brought up some great points about the merits of the draft standards and the other projects out there like your AMB. Ideally we do standardize around a data format used throughout the industry. In almost every case I would defer to actual industry members. 

However, from an outsider's perspective (i.e. mine), GENIVI and the W3C are obtuse. Where's the user-facing documentation for the GENIVI Vehicle Interface or the W3C standard you mentioned? I haven't seen any of the automakers really embrace GENIVI's efforts either, so I don't know if that's a winning path. 

Unfortunately I don't think there is very much interest in opening up vehicle data from the OEMs. I spent almost 2 years evangelizing open vehicle data as a Ford engineer and met a lot of people in the industry - I have very few concrete results to show for it. That's not to say someone else can't be successful.

Take a look at Tesla, perhaps the most forward-thinking automaker when it comes to software. A huge part of their car's software supports OTA updates, they have a mobile app that integrates with vehicle functionality, the car has an always-on network connection, and they even do active network monitoring to protect their customers from malicious hacking. 

Even with all of those positive signs, there's no documented data format for their CAN or Ethernet networks, they don't publish or support their web-based API (it's only somewhat known because it's been reverse engineered), and there's no user-facing data port in the car. If they don't have enough incentive to provide a data interface to their customers, I don't have much hope that VW, FCA, GM or Ford will either.

Lack of Data

Ian, this gets to your point about a lack of good examples of what you can do besides read a few variables. Honestly, that's all you can reliably do for all cars out there on the road. You might be able to find some one-off examples of someone that's been able to reverse engineer a message to roll up their windows or pop the trunk, but it's hard to scale that because there is no guarantee it works for anyone else.  

Because of that, Kevron, I totally agree that this space is inherently fragment. I think that's true because we don't have blessing or support by the automakers. Only a tiny part of data in our cars is standardized and legally required, and it's uninteresting to the almost everyone except regulators (I'm talking about OBD-II). Without having any more standardized data, we can say some custom data field might work, but because of the vast array of cars out there, we can't provide very good support. This group is littered with people saying something doesn't work on their particular car, and there's just not much anyone can help with. Sometimes I feel like I'm trying to help someone fix a washing machine I've never seen from 8,000 miles away.

Take a look at Automatic - they use OBD-II and I think even partnered with a few automakers to get some extended non-standard data, and still all they can do with the car is calculate your MPG, decode the check engine light and monitor your speed. If that's all a well-funded company with over 50 employees can do, I think we're fooling ourselves thinking an open source project can be better. most of Automatic's innovations are centered around the smartphone, and just use the Link device attached to your for a little bit of context.

Vehicle Interface Hardware

I like the ideas of AMB a lot, but the hardware is a limiting factor as you mentioned. Intel's Edison has been mentioned a number of times, but one of the advantages of OpenXC that kickstarted it in the early days was having a vehicle interface that fit snugly into the OBD-II port. I haven't seen an Edison board or anything similar in such a form factor. A large percentage of people using OpenXC require something like the existing VIs - no cable, it must be powered by the car, etc.

I don't doubt that some awesome new hardware is possible, but we don't have a regularly contributing electrical or hardware engineer that could design and manufacture such a thing. I've been very hesitant to extend the VI firmware to support any more platforms because there isn't really a critical mass of people around a single, capable CAN interface. They seem to fall into a few groups:

• Expensive and proprietary. No interface for custom code.
• Inexpensive, but of poor quality and poor performance and few features - see the OBD-II dongles on eBay.
• Reasonably priced, but not widely available. I'll include the OpenXC reference VI here because while it's open source, Ford is the only known company to every make them.

Open source hardware would be cool, but it's also not a requirement for me. The CrossChasm C5 is the best, most available VI supported by OpenXC right now, and it's closed source hardware. I don't think the open source hardware community has quite figured out the incentives for releasing something that costs so much money to make (see Makerbot), but that's another conversation. I have a new CANBus Triple that might be another good option if I can get it compatible with the OpenXC message format, but again, it's just one guy with a successful Kickstarter and isn't super widely available.

Summary

This leaves me feeling more like OpenXC should be oriented more towards security researchers and confident hackers, instead of pro-sumer level car owners and tinkerers. Some helpful pointers towards possibilities for data would be nice, but these people can also find our own way.

(Personally, this is an occasional weekend project and spending that time dealing with standards bodies doesn't sound like much fun. I'm not the only voice to speak for OpenXC, so I'm not ruling it out, but I don't think it would happen without direct industry support.)

Chris

On Thu, Mar 26, 2015 at 9:38 PM, Ian <ichr...@gmail.com> wrote:

I think the biggest problem is the what can we do with it, we are promoting that it is open source, but there are few actual examples of what to do with it.  I was working on a project for having a dedicated laptop connected to it so I can fiddle with it, but school is in the way right now.  I would think it would be cool if someone could show how to control your car with your phone (i.e. lights, radio, windshield wipers, etc.) then this project could have the publicity it deserves.  We are limited this project very much because we don't have a collective initiative, yea maybe to opensource OBD, but there are no team projects for implementation other than a few things displaying variables.  We need to do something with those variables other than display them.  I am a developer, not a designer (aka good at making something if someone comes up with a "what if we do this..." we'll I'll help make it and see where it goes)

--

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.
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/0ec1f382-e2dc-40df-86c2-108422b627af%40googlegroups.com.

[Kevron Rees]

On Sun, Mar 29, 2015 at 4:05 PM, Christopher Peplin <chris....@rhubarbtech.com> wrote:

Thanks, Kevron, Ming and Ian, I really appreciate all of the different perspectives. I'm still looking for more, if anyone has more comments! This turned into a bit of an essay, so I'll break it up into a few sections.

Everything to Everyone

I think that given this is an open source, volunteer project, we have to avoid trying to be everything to everyone. When I was full-time at Ford working on OpenXC, I was a bit more confident that we could make the car a good the first programming experience a new developers. I spent a lot of time documenting the installation and setup, and a lot of my on-site training was for things like installing and getting familiar with the Android tools and explaining CAN.

I'll admit that was sometimes exhausting. I don't think there's anyone with enough volunteer time or energy to continue with that effort. I think the docs should start to defer a lot more to the rest of the Internet. 

While we don't want to discourage anyone, I don't think that OpenXC should be most people's first experience with programming. If you've never used Android, the command line or Git before, this is probably not the right place to start. We're working to get the Android library updated to work with the new IDE from Google (Android Studio), and at the same time I think I'll trim down the amount of Android setup docs on the OpenXC site to make it more manageable. 

Standards

Kevron, you brought up some great points about the merits of the draft standards and the other projects out there like your AMB. Ideally we do standardize around a data format used throughout the industry. In almost every case I would defer to actual industry members. 

However, from an outsider's perspective (i.e. mine), GENIVI and the W3C are obtuse. Where's the user-facing documentation for the GENIVI Vehicle Interface or the W3C standard you mentioned? I haven't seen any of the automakers really embrace GENIVI's efforts either, so I don't know if that's a winning path. 

W3C was pretty easy to find.  It's the 3rd and 5th google result for "w3c automotive spec". http://www.w3.org/2014/automotive/vehicle_spec.html http://www.w3.org/2014/automotive/data_spec.html
GENIVI's vehicle interface is AMB's DBus API: http://otcshare.github.io/automotive-message-broker/0.13/dbus/html/index.html

The point isn't to pick W3C or GENIVI.  It's to try to standardize rather than fragment.  Both of these efforts represent *some* industry coordination.  Ford and GM both participated in the W3C specification.  Moreso by GM, but I had discussions with Ford at one of the first meetings in Barcelona.  They had some valuable input.  Other automakers are also involved including JLR, Toyota, BMW and dozens of Tier 1's.

But I suppose that's irrelevant until someone implements it.  The Automotive Working Group is just spinning up.  After they finalize the spec, we'll see who ships a car with it first.  Note: these are high-level APIs and do not require any standardization at the CAN layer.  That's a difficult beast to slay as you probably know.

 

Unfortunately I don't think there is very much interest in opening up vehicle data from the OEMs. I spent almost 2 years evangelizing open vehicle data as a Ford engineer and met a lot of people in the industry - I have very few concrete results to show for it. That's not to say someone else can't be successful.

I think there is interest in at least standardizing on high-level APIs.  Some in the industry is scared of open source or open standards.  However, if the increasing participation in the W3C is any indication, this mindset may be changing.

 

Take a look at Tesla, perhaps the most forward-thinking automaker when it comes to software. A huge part of their car's software supports OTA updates, they have a mobile app that integrates with vehicle functionality, the car has an always-on network connection, and they even do active network monitoring to protect their customers from malicious hacking. 

Tesla seems to have made a conscience decision to "go their own way" in my opinion.  They will pay the price for that, good or bad, when the piper comes to collect.  Some of us believe that collaborating on open source leads to greater innovation in the long run.  I haven't seen participation in any sort of community from Tesla and though they build on open source (AFAIK, they use Linux, Qt, webkit, and more in their headunits), they seem to have little interest in the underlying principle.  The market will ultimately decide who is correct.

 

Even with all of those positive signs, there's no documented data format for their CAN or Ethernet networks, they don't publish or support their web-based API (it's only somewhat known because it's been reverse engineered), and there's no user-facing data port in the car. If they don't have enough incentive to provide a data interface to their customers, I don't have much hope that VW, FCA, GM or Ford will either.

Perhaps we can show them what can be done on an open API?  It we can demonstrate the value to customers, they might take a look.  Showing that value will be difficult if the community is producing dozens of ways of doing the same thing.  Too many resources will be utilized reinventing the wheel instead of building cars on them.

 

Lack of Data

Ian, this gets to your point about a lack of good examples of what you can do besides read a few variables. Honestly, that's all you can reliably do for all cars out there on the road. You might be able to find some one-off examples of someone that's been able to reverse engineer a message to roll up their windows or pop the trunk, but it's hard to scale that because there is no guarantee it works for anyone else.  

Because of that, Kevron, I totally agree that this space is inherently fragment. I think that's true because we don't have blessing or support by the automakers. Only a tiny part of data in our cars is standardized and legally required, and it's uninteresting to the almost everyone except regulators (I'm talking about OBD-II). Without having any more standardized data, we can say some custom data field might work, but because of the vast array of cars out there, we can't provide very good support. This group is littered with people saying something doesn't work on their particular car, and there's just not much anyone can help with. Sometimes I feel like I'm trying to help someone fix a washing machine I've never seen from 8,000 miles away.

Take a look at Automatic - they use OBD-II and I think even partnered with a few automakers to get some extended non-standard data, and still all they can do with the car is calculate your MPG, decode the check engine light and monitor your speed. If that's all a well-funded company with over 50 employees can do, I think we're fooling ourselves thinking an open source project can be better. most of Automatic's innovations are centered around the smartphone, and just use the Link device attached to your for a little bit of context.

Vehicle Interface Hardware

I like the ideas of AMB a lot, but the hardware is a limiting factor as you mentioned. Intel's Edison has been mentioned a number of times, but one of the advantages of OpenXC that kickstarted it in the early days was having a vehicle interface that fit snugly into the OBD-II port. I haven't seen an Edison board or anything similar in such a form factor. A large percentage of people using OpenXC require something like the existing VIs - no cable, it must be powered by the car, etc.

The Edison is really small... I believe it should be very possible to get something that small and much more powerful than what currently exists.  It may be even cheaper than the CrossChasm C5.  The prototype parts I ordered totaled $28 minus the Edison ($49), stn1170 ($11), PCB and housing. Even if the PCB and housing cost $50 we are looking at a similar price point.

 

I don't doubt that some awesome new hardware is possible, but we don't have a regularly contributing electrical or hardware engineer that could design and manufacture such a thing.

The design is simple.  It's the stn1170 circuit that's connected to the uart of the edison.  I plan on doing the PCB layout myself probably with the help of others I know who can tell me where I'm doing something stupid in my layout (I'm not an EE).

- Kevron

 

I've been very hesitant to extend the VI firmware to support any more platforms because there isn't really a critical mass of people around a single, capable CAN interface. They seem to fall into a few groups:

• Expensive and proprietary. No interface for custom code.
• Inexpensive, but of poor quality and poor performance and few features - see the OBD-II dongles on eBay.
• Reasonably priced, but not widely available. I'll include the OpenXC reference VI here because while it's open source, Ford is the only known company to every make them.

Open source hardware would be cool, but it's also not a requirement for me. The CrossChasm C5 is the best, most available VI supported by OpenXC right now, and it's closed source hardware. I don't think the open source hardware community has quite figured out the incentives for releasing something that costs so much money to make (see Makerbot), but that's another conversation. I have a new CANBus Triple that might be another good option if I can get it compatible with the OpenXC message format, but again, it's just one guy with a successful Kickstarter and isn't super widely available.

 

Summary

This leaves me feeling more like OpenXC should be oriented more towards security researchers and confident hackers, instead of pro-sumer level car owners and tinkerers. Some helpful pointers towards possibilities for data would be nice, but these people can also find our own way.

(Personally, this is an occasional weekend project and spending that time dealing with standards bodies doesn't sound like much fun. I'm not the only voice to speak for OpenXC, so I'm not ruling it out, but I don't think it would happen without direct industry support.)

 

Chris

On Thu, Mar 26, 2015 at 9:38 PM, Ian <ichr...@gmail.com> wrote:

I think the biggest problem is the what can we do with it, we are promoting that it is open source, but there are few actual examples of what to do with it.  I was working on a project for having a dedicated laptop connected to it so I can fiddle with it, but school is in the way right now.  I would think it would be cool if someone could show how to control your car with your phone (i.e. lights, radio, windshield wipers, etc.) then this project could have the publicity it deserves.  We are limited this project very much because we don't have a collective initiative, yea maybe to opensource OBD, but there are no team projects for implementation other than a few things displaying variables.  We need to do something with those variables other than display them.  I am a developer, not a designer (aka good at making something if someone comes up with a "what if we do this..." we'll I'll help make it and see where it goes)

--
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.
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/0ec1f382-e2dc-40df-86c2-108422b627af%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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.
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/CAGrXyuyx-tyzJaGP0zjYi%3DLPKAYxJ0n%2Buyi%3D1kr-tN3OsZ3fOg%40mail.gmail.com.

[Christopher Peplin]

Thanks, Kevron - what are you thoughts on my comments about the lack of interesting data or things you can control? It's hard to find the motivation to do all of this other work if in the end, you can't read anything of interest from the car.

To view this discussion on the web visit https://groups.google.com/d/msgid/openxc/CAAOZRYVGiZf8gJe7P-Lfi7PM4ocga_LpAQxuK_0%3Dif6%2BRe_Zgw%40mail.gmail.com.

[Kevron Rees]

On Sun, Mar 29, 2015 at 6:02 PM, Christopher Peplin <chris....@rhubarbtech.com> wrote:

Thanks, Kevron - what are you thoughts on my comments about the lack of interesting data or things you can control? It's hard to find the motivation to do all of this other work if in the end, you can't read anything of interest from the car.

I agree.  OBD-II data alone isn't that interesting.  However, this proposed device adds slightly more interesting capabilities on top of that with video/gps/logging and the option for CAN.  Current devices can't do that, but any device that runs AMB can.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openxc/CAGrXyuxLFUpyR4nRsiviTOL_QjxMQZP9mXBjA1WomA1neRqzxw%40mail.gmail.com.

[Tony P]

My apologies for throwing my very inexperienced hat in the ring on this, but perhaps an outside opinion would help gain some perspective. I have found the openXC community by looking for a way to increase my knowledge of Automotive CAN systems from an automotive enthusiast perspective (if your unfamiliar with that PC term it means i like fast cars, classic cars, race cars, things with motors and wheels, autocrossing etc.).

From that perspective I am thrilled with the possibilities I see your efforts opening up for me. I would be interested in improving my knowledge of keeping my car healthy (i.e. turbo timer implementation), improving my driving performance (shift lights on set rpm). 

I feel like you could market this to a crowd who is already tinkering with their cars everyday for performance/maintenance  gains. Also is there a need for a community of open source CAN expertise in university level competitions (autonomous vehciles, Formual SAE)?

I also agree that allowing the reverse engineering of more communication or adding the ability to add more sensors (brake temperature sensor anyone?) is ideal.

How many of you guys are familiar with Piston Heads or Jalopnik? Huge car culture websites that would likely provide some exposure if you can show them an interesting application.

In particular I would love to understand when my car, Focus ST, is applying its brake torque vectoring in corners. There have been issues with this car deploying this system in long sweeping corners under spirited driving cooking your breaks, leading to break fade in subsequent corners. A good set of pads can alleviate much of the problem, but it would be ideal to have the system be a little smarter considering what conditions your driving under.

Thanks for your work so far! I am poring through the pages as we speak.

[Rodney Fulk]

The biggest issue is that everyone has the next best idea and wants to develop it on their own...

Personally I have been dreaming of making an Open Interface that basically makes a Vehicle just another device you hook to your computer like a Printer. And like a Printer you can have one that has a Scanner and/or Fax machine so there is much room for supporting other features. I say this because I had a discussion with Kevin a few months ago about this and I got interested in both AMB and OpenXC.

As a college student (CIS) with limited time and having some security background as well I am looking at this as a network type setup with different layers to it. Not sure how you can get it out there and expand upon it but I have some plans for the near future. I have to have a project for my Degree and I plan to make communicating to my Truck that Project. I will be getting into operating system programming as well as device drivers and such and am serious about making a Windows/Linux device driver type interface that can help make this stuff easier to use to the normal person.  Since I do NOT want to make this from scratch I plan to use both Open XC and AMB to allow my project to be much more open and expandable.

I don't know how to push it out there and make it more visible but hopefully by publishing in some of the online magazines it could make a big difference.

For me I see OpenXC as a hardware level device that can handle the low level connection stuff. Some vehicles can not be fully serviced by this for whatever reason and thus you will still see additional custom hardware to connect to that as well. For these items it doesn't make much sense to try connecting them to OpenXC unless OpenXC supports communicating to an external device and doing all of the communications with the intended host.

For my project I will likely get involved with OpenXC to get the GM information out there. Using the GMLAN bible and some other information I have I hope to be able to build a firmware that will be as diverse as the Ford stuff. I also have some expert Diagnostic software that I may be able to reverse engineer to pull information I don't already have.

I see AMB as a necessary abstract software layer on top of OpenXC at least for my project. It can tie all of the hardware together and make developing an all inclusive interface as much simpler. Personally I think this is the best way to make use of both of these projects. Similar to how networking has different levels I think OpenXC and AMB can benefit from such a relationship.

I hope this is on topic but I apologize if not. At this point as an outsider and not yet involved I see OpenXC as very limited because if you want to use it with a PC you much use Python or use it with a mobile app. I want to develop it with AMB to develop a .Net library for windows and a lib for linux that then could be used by pretty much anything since it will be a system device.

At this time I am probably 2-3 months from having the time to get involved but I will have limited time to work on this due to my work and school schedule but I think it can drastically expand the potential user base and could be used to base front ends for windows or linux thus making a big impact.

Rodney Fulk

[Christopher Peplin]

New user feedback is exactly what we need, thanks Rodney and Tony.

Rodney, quick question because I think we might be able to clear something up in the docs - what gave you the impression that OpenXC on a laptop only works with Python? 

The Python library is a nice wrapper, but it wouldn't be hard to write a driver in any programming language (.NET included). It's core responsibility is to read data from the USB or serial (i.e. Bluetooth) input and send it to your application. You can do that with a few dozen lines of code in most languages.

--

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.
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/69fdd106-a809-409c-a3a8-fe3f94a0ae55%40googlegroups.com.

[Rodney Fulk]

When I did a quick read through the docs it mentioned to connect via Bluetooth and mentioned that you could use Python to connect to it via a PC. I don't recall seeing any mention of it being a simple matter to connect with other languages. But again, I just peaked at it. I was actually introduced to OpenXC I think from Kevin. I have big plans to use AMB to build a windows interface as I mentioned but OpenXC is also will become a large part of that for me. I suspected I would need to build a C/C++C# interface pretty much from scratch from my quick peak. Anyhow I have no idea how easy it will be to connect via another language and it wasn't real obvious when I took a 30 second look at the online docs.

Is it as simple as opening a serial connection to the device and communicating? And looked like you use real language wording for requests.
I would suggest that it would be a good idea to have a way to tokenize the commands if this is the case. I would much rather send an 8 bit or a 16 bit command than a full word... Would be nice to have the option at least.

I really need to get involved at some point to see where I want to go but I see my project moving both OpenXC and AMB into new directions.

Rodney