On 06/26/2018 07:23 AM, Roger Oberholtzer wrote: What or where does the card plug into in the car? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 06/29/2018 11:12 AM, Roger Oberholtzer wrote: 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 06/30/2018 06:46 AM, Carlos E. R. wrote: 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: 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 07/02/2018 06:37 AM, jdd(a)dodin.org wrote: 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 07/02/2018 02:42 PM, jdd(a)dodin.org wrote: 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. 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 2018-07-02 20:35, ken wrote: 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org