On 06/26/2018 07:23 AM, Roger Oberholtzer wrote:

On Tue, Jun 26, 2018 at 12:58 PM, Dave Howorth wrote:

...

No experience, sorry, but a vague interest. A good source of info seems to be https://elinux.org/CAN_Bus but it doesn't mention MobilEye, which is not encouraging, and likewise https://www.mobileye.com/our-technology/ doesn't mention CAN Bus. But The MobilEye is CANBus. That's how it finds out about the state of the vehicle (e.g., is the turn indicator on? What's the speed? How to control the cruise control, etc). And they add their information on the bus. They state that one should use the Cable A interface on the CANBus. Whatever that is. I believe it is the physical connectors. I think there is a Cable B interface as well.

...

http://docs.polysync.io/sensors/mobileye-560/ does claim "The ECUs CAN network needs to be configured to use one of the two compatible CAN interfaces: Kvaser’s linuxcan or socketcan." So perhaps there's some hope. There seems to be a choice of a character-based and a socket-based interface. I am guessing that this is not so much a matter of the card itself but of the driver that access the card.

I wonder what this statement at http://docs.polysync.io/articles/configuration/runtime-node-configuration/co... implies:

"All nodes on a given host must use either linuxcan or all nodes must use socketcan drivers to communicate with CAN interface hardware."

I would imagine that the vehicle is also on the CANBus. How is that communicating?

I think all will become clear when I get the actual hardware. Perhaps I just need to choose a card to get going.

What or where does the card plug into in the car? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/29/2018 11:12 AM, Roger Oberholtzer wrote:

On Fri, Jun 29, 2018 at 3:56 PM, ken wrote:

...

On 06/26/2018 07:23 AM, Roger Oberholtzer wrote:

...

On Tue, Jun 26, 2018 at 12:58 PM, Dave Howorth wrote: What or where does the card plug into in the car? We have measurement systems in the vehicles with computers running openSUSE. Lots of lasers, accelerometers, 3D video/laser scanners, GPS, high speed cameras, retroreflectivity devices, and the like. This will be one more device that the system will manage.

Yes, of course, all that.  But my question is: Where, or into what, in a car does the card plug into?  That is, if I buy such a card, it will accomplish very little if it is lying on my desk.  It needs to connect into my car, yes?  So where in the car does it plug into? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/30/2018 06:46 AM, Carlos E. R. wrote:

On Saturday, 2018-06-30 at 12:24 +0200, Dave Plater wrote:

...

On 25/06/18 12:58, Roger Oberholtzer wrote:

...

  Anyone using a CANBus card with openSUSE? We will soon have a MobilEye   device that we want to test integrating with our system. And it speaks   CANBus. We are on our own to provide the CANBus card. So something   that is known to play nice with Linux/openSUSE is what we are looking   for. So any suggestions or experiences are welcome.

A canbus is based on rs232 at least in the microcontrolers I use it is. There are level shifting devices that work with usb that are available. Don't know about software that's available though.

Let me try to understand. The card you people are talking about is a card for the computer, not for the car, and allows a computer to at least read what goes on the car's CAN bus, right?

Understanding is good, a very laudable goal.  I'm with you 110% there.  I know nothing about the aforementioned card, never heard of it, so can't really speak to what it's for or what it does.  But CAN/OBD devices are normally connected to a vehicle so they can (at minimum) collect data about the vehicle from sensors installed (mostly, but not necessarily) during manufacture.  They're useful because they can provide information about the functioning of the vehicle they're installed in and even about the physical environment the vehicle is currently in.  Originally the OBD system (now part of CAN), an open standard, was meant to optimize the performance of a vehicle (in real time) in order to minimize pollution and increase fuel efficiency.  It's the system which can cause your car's "Check Engine" light to go on. Of course all of that impossible to do any of that unless the device is connected to the car.  The original open standard doesn't preclude additional, proprietary functionality to be built into the same system.

On 07/02/2018 04:20 AM, Dave Plater wrote:

On 01/07/18 19:02, ken wrote:

...

On 06/30/2018 06:46 AM, Carlos E. R. wrote:

...

On Saturday, 2018-06-30 at 12:24 +0200, Dave Plater wrote:

...

On 25/06/18 12:58, Roger Oberholtzer wrote:

...

   Anyone using a CANBus card with openSUSE? We will soon have a MobilEye    device that we want to test integrating with our system. And it speaks    CANBus. We are on our own to provide the CANBus card. So something    that is known to play nice with Linux/openSUSE is what we are looking    for. So any suggestions or experiences are welcome.

A canbus is based on rs232 at least in the microcontrolers I use it is. There are level shifting devices that work with usb that are available. Don't know about software that's available though.

Let me try to understand. The card you people are talking about is a card for the computer, not for the car, and allows a computer to at least read what goes on the car's CAN bus, right?

Understanding is good, a very laudable goal.  I'm with you 110% there.

I know nothing about the aforementioned card, never heard of it, so can't really speak to what it's for or what it does.  But CAN/OBD devices are normally connected to a vehicle so they can (at minimum) collect data about the vehicle from sensors installed (mostly, but not necessarily) during manufacture.  They're useful because they can provide information about the functioning of the vehicle they're installed in and even about the physical environment the vehicle is currently in.  Originally the OBD system (now part of CAN), an open standard, was meant to optimize the performance of a vehicle (in real time) in order to minimize pollution and increase fuel efficiency.  It's the system which can cause your car's "Check Engine" light to go on. Of course all of that impossible to do any of that unless the device is connected to the car.  The original open standard doesn't preclude additional, proprietary functionality to be built into the same system.

To be precise OBD and current OBD2 standards use several busses CAN being one of them. You can get cheap usb and bluetooth OBD2 readers. best regards Dave P

Yeah, my post above was meant only as brief intro.  There could be several volumes written on the topic.  I was definitely speaking in generalities definitely at the brink of my comfort level. I've purchased three of those "OBD2 readers"....  (For people looking for more info on them or to buy one, they're more often called "OBD scanners".)  One tip I'd pass along, before buying, check the operating temperature range.  One of the "scanners" I bought died in the first year I had it, most likely due to my running it on a really hot summer day... in the mid-30s C.  The AC didn't help it because I'd mounted it behind the dashboard (hidden away, attached to a Raspberry Pi).  However, the only website listing operating temps of the scanners they sell which I've seen is scannet.com (IIRC the URL).  They sell higher-quality scanners (said another list I was on), their prices reflecting that slightly.  And no, I have absolutely no financial interest in that site... or in any other part of that whole industry. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2018 06:37 AM, jdd@dodin.org wrote:

Le 02/07/2018 à 12:32, ken a écrit :

...

scanners".)  One tip I'd pass along, before buying, check the operating temperature range.  One of the "scanners" I bought died in the first year

they a most of time time sold to fix engine problems, not to be there all along :-(

jdd

Some vehicle problems, perhaps most, first appear intermittently.  The logic in an ECU, however, will routinely erase what it sees as a one-off error and not report it via "Check Engine" or with a code reader until it recurs multiple times within a specified amount of time.  I was once able to anticipate a problem, long before the ECU's logic deemed it a problem, because my home-brew system provided me longer term raw data, which was much more informative. In addition, a problem may appear only within a particular constellation of other varying conditions; just reading the lone problem code will not reveal those other relevant conditions, conditions which may well normally vary over time... or perhaps should not vary significantly.  E.g., ask most any auto mechanic, quite often an error code points to some part which is not the problem at all; instead the "problem" is the fault of the reporting sensor, something which can't be determined simply by reading one, single code after the fact, but is obvious in the context of other data.  Maybe it's a choice of mindset.  Am I satisfied with the binary and oversimplistic mindset of "Either Problem or No-Problem"...? or would I prefer to understand as much as possible what's actually going on?  It's a little like that other, more common choice:  When I look at the dashboard, do a want to see a little light that might suddenly go on, or do I want the continual visual of a gauge? And the entire issue of problem diagnosis is just part of possible uses for a code reader.  As the OP pointed out, a lot more is possible.  For example-- one of countless thousands--, you might correlate map data specifying your travel plan with GPS data and the data indicating speed of your vehicle with logic that would tell you, "You'd best slow down or you'll miss your upcoming turn."  Years ago some cars offered functionality which automatically lowered the volume of the sound system when the driver slowed and/or stopped the vehicle.  I found that a very considerate feature.  The possibilities are endless, but only if the code reader is continually operational. Not so much an apologist for profiteers, I would rather just say, that, technically they are intended for reading codes from the ECU(s).  Much more complex electronics than that have easily survived years long journeys past all the planets in the solar system.  I don't think it's asking too much for it to weather a summer's day. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/02/2018 02:42 PM, jdd@dodin.org wrote:

Le 02/07/2018 à 20:35, ken a écrit : (many things I agree with :-)

...

journeys past all the planets in the solar system.  I don't think it's asking too much for it to weather a summer's day.

may be not the same price. I'm just these days afraid of how high can be a t° in a car exposed to sun :-(

It's worth noting that the Raspberry Pi, which was crammed into the same small place in the dashboard, and which remained there the same entire time, so under exactly the same heat conditions, came away fine.  It still runs.  So there is a difference, and a decisive difference, in manufacturing quality.

but then we should go to OT list, I guess

jdd

I've already written way more than I really wanted to.  A more relevant list can be joined at http://icculus.org/mailman/listinfo/obdgpslogger ... for anyone interested. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-07-02 20:35, ken wrote:

On 07/02/2018 06:37 AM, jdd@dodin.org wrote:

...

Le 02/07/2018 à 12:32, ken a écrit :

...

scanners".)  One tip I'd pass along, before buying, check the operating temperature range.  One of the "scanners" I bought died in the first year

they a most of time time sold to fix engine problems, not to be there all along :-(

jdd

Some vehicle problems, perhaps most, first appear intermittently.  The logic in an ECU, however, will routinely erase what it sees as a one-off error and not report it via "Check Engine" or with a code reader until it recurs multiple times within a specified amount of time.  I was once able to anticipate a problem, long before the ECU's logic deemed it a problem, because my home-brew system provided me longer term raw data, which was much more informative.

In addition, a problem may appear only within a particular constellation of other varying conditions; just reading the lone problem code will not reveal those other relevant conditions, conditions which may well normally vary over time... or perhaps should not vary significantly.  E.g., ask most any auto mechanic, quite often an error code points to some part which is not the problem at all; instead the "problem" is the fault of the reporting sensor, something which can't be determined simply by reading one, single code after the fact, but is obvious in the context of other data. 

Happened to me. An alarm popped up "take the car to the garage". They replaced something, charged me something, I went away, and after some days I was back with the same alarm. The mechanic only found out what was wrong after driving for a while with his laptop connected to the car for some time and scanning the logs. Intermittent failure in a different sensor that what the initial report said. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

A bit of progress on this thread. I got a CANBus <-> USB interface (Peak USB). It appears as a network device (can0). I just plugged it in to my Leap 42.3 system and all the drivers were in place. One programs it via sockets. When I finally get the device connected (not an obvious thing...), I expect data collection to be rather straight forward. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org