CAT 3208 monitoring

[nedb]

(02-27-2013 10:31)davidmbrady Wrote:  

(02-27-2013 03:46)nedb Wrote:  Is anyone else hacking the 3208/Arduino frontier? Care to share?
Ned Bedinger
'91 SP36

...,

Of course my bus is J1587 equipped and I have Silverleaf's VMSpc up front. So the natural thing for me to do is take my fan speed data and push it onto my J1587 bus as a diagnostic PID, but I haven't found a gateway (or shield) to help me do that. Because the J1587 bus is mission critical for the engine, transmission, and ABS brakes I want to be careful about interfacing to it, and I may abandon it all together in favor of a separate network. So maybe we can find a solution that'll work for both of us, maybe an 802.11 Wi-Fi shield: https://www.sparkfun.com/products/11287

David--

I should bone up on J1587 spec to talk to you DD guys. I'm curious about it as a data transmission protocol, and a hardware standard. Is the DDECx computer running a familiar OS?

Since your DDEC data stream between computer and engine sensors is mission critical, I understand why you wouldn't want to intrude on it by slipping in extra data packets that an arduino at the dash could decode. No no no, do not disturb the DDEC! Unless the J1587 has some extra bandwidth in the form of unused conductors in the harness, and even if it does, you probably want to use another network.

I picked up a 10/100 ethernet shield tonight at Radioshack. I think it was around $20. I'll use it while I dink around with getting the arduino to stream data to my laptop.

An Arduino tidbit: Arduino Uno uses an internal reference voltage that limits the voltage range it can read on the pins--zero to five volts DC. You can switch it in software to an external reference voltage, raising the voltage you can read on the pins. You lose some resolution in the readings, but can still resolve millivolts, iirc. This is a fundamental step for my monitor plans, because I have several wiring points at house bank or chassis bank voltage that I want to monitor. You know, the ZF transmission is very touchy about having at least 12V delivered to a terminal ON TOP of the transmission. Hard to get to for maintenance, so why not simply monitor it for resistance/voltage drop. There's no sign of a ZF voltage monitor (yet) in my dashboard. The Primus is likewise voltage sensitive, and somewhat prone to ocassional unexplained issues. I believe I could learn a lot by monitoring/logging voltage at it's key points, for troubleshooting.

I've done my share of Windows database programming, interface design, tool making, and general run academic and work tool making, back in the day. Today you can have your choice from a double-handful of compiled or interpreted programming languages, many of them more or less the same as found on other platforms. Visual Basic was my main tool for a long time, and I expect I could get into it again if you want a code buddy for Windows programming. Gnu C/C++ compiler runs on Windows, if that is your speed. Do you have a virtual Windows environment on Slackware? Slackware! I thought they threw in the towel when RedHat went all big time.

We'll get something off the ground with Arduino before too long.

--Ned

[davidbrady]

Hey Ned,

Being lazy, I'm all for leveraging what's already available.

Maybe a set of requirements might help hone our thoughts:

1) we need a distributed set of sensors to tap into monitoring points anywhere throughout the motorhome,
2) we need a set of arduinos to collect and pre-process the data from the sensors. Any particular arduino may service more than one sensor,
3) we need a data bus to collect, multiplex, and transmit the pre-processed data to the end-user (could be wire and/or wireless), and
4) we need a display device and graphical user interface that allows users to select and configure gauges, logs, alarms, etc.

Number (3) is near and dear to my heart. I'm thinking unless we use something already available we can spend a ton of time here re-inventing the wheel. If we choose a standard path, then we are open to use off the shelf display devices such as Silverleaf's VMSpc or Ray Davis's RV Techtools Ipad display, and many of the other requirements fall into place. Something like J1587 over J1708 or over Ethernet, or J1939. If the application layer is J1587 or J1939 and the physical and datalink layers are Ethernet, J1708, or J1939 then Silverleaf and Rv Techtools can display it w/o modification.

Canduino:
http://code.google.com/p/canduino/

Gotta run, there's furniture sale in Hickory, NC and my wife's pulling me away!

[Ray Davis]

FYI, at present my app only speaks J1587, and it decodes data streaming from the CANpod. Certainly changes can be made to stream from a different source, but I agree that sticking with standards would be best.

I was curious about this comment:

Quote:Of course my bus is J1587 equipped and I have Silverleaf's VMSpc up front. So the natural thing for me to do is take my fan speed data and push it onto my J1587 bus as a diagnostic PID

I am curious what J1587 data you would push down the J1587 bus to change fan speeds? PID 26 is defined for estimated fan speed. I don't believe in any of the testing that I've done that I've seen that PID actively, but I do see that it is one that is marked as "on request", which certainly might explain it.

[davidbrady]

(03-04-2013 19:16)Ray Davis Wrote:  I am curious what J1587 data you would push down the J1587 bus to change fan speeds? PID 26 is defined for estimated fan speed. I don't believe in any of the testing that I've done that I've seen that PID actively, but I do see that it is one that is marked as "on request", which certainly might explain it.

Hi Ray,

I appreciate the feedback. Sorry, pardon my sloppiness, I don't have the J1587 specification in front of me. What I'd like to do is see what user-defined MIDs and PIDs are available in J1587 and use that space to report fan speed. My LXi has a variable speed fan. For the case of older non-electronic Wanderlodges we'd need to do the same; that is, use the user-defined MID and PID space to report "proprietary" sensor conditions. Do you know if what MIDs/PIDs are available?

[Ray Davis]

There is PID 254, which is a data link escape. The spec says: This PID allow transmission of information on the data bus in a nonstandard way (per the protocol outlined in SAE J1587) but specific electronic module vendor's proprietary fashion. The intent of this PID is to allow a means to use the data bus for vendor specific transmissions that do not benefit the general purpose nature of the communications data link.

I have seen this particular PID go by a lot, and in looking at it, it appears it is data intended for my DDEC Pro Driver module (in the case where I've seen this particular message).

[davidbrady]

Thanks Ray, I appreciate it. What about the case of J1578 over IP. I'm thinking open a UDP port. Is this something that RV Techtools can support? For the older birds it could be a data stream dedicated to a UDP port. For the electronic birds it could be two data streams one over the CANbus and one over UDP/IP/Ethernet concurrently.

[Ray Davis]

It's a possibility, but not a slam dunk. The CANpod device is essentially what I would call J1587 over IP (it converts the binary into ascii, and sends ascii data). However, it runs in the default world in ad-hoc mode. I assume in your mixed environment you would connect a hard-line IP into a wireless system? This means a couple of things, to monitor both:

1. CANpod would have to be configured to run in an existing wireless system, do-able, but not trivial.

2. The app would have to multiplex between two IP streams. Currently it doesn't use UDP, but connects into a specific port and IP, and then sets the CANpod into a streaming mode (except when reading error codes). Once streaming the app reads the data as fast as it's coming. Some work would be need to be done to work with a separate UDP stream.

[nedb]

(03-01-2013 12:23)davidmbrady Wrote:  Hey Ned,

Being lazy, I'm all for leveraging what's already available.

...

Canduino:
http://code.google.com/p/canduino/

Wow! It looks like the work is already underway thanks to the CANduino+MCP2515 development project. Coolness. I'll try to stay on it, probably order the beta CANduino and MCP2515 hardware to ramp up on.

But. I have other irons in the fire, too. #1 is re-rigging and readying the SP for a spring road trip out east. I've promised the l'il woman and my family in the RTP area that we'll visit soon, so now I have to come through for them. Maybe I'll come down with mono and have to stay home, passing the time playing with my little CANduino system

Not sure which is more exciting--cross-country road trip or CAN for a '91--they both blow up my skirt

Great to see Ray's experience and input helping to shape the concept, too. Sounds like there is more leverage to be had in existing on-request PIDs and data transport. More power to you guys, I am intrigued by what I've learned from you already. Thank you!

--Ned

[Arcticdude]

For some reason, a good piece of baklava and a glass of ouzo seems really good right now!

[nedb]

Did you have mousaka and a glass of retsina for dinner?