Wanderlodge Gurus - The Member Funded Wanderlodge Forum

I think so, but after the 3.2 jigawatts of information about Canadian iPods and jbird data streams roasted my souvlaki; I'm not sure how much moussaka I actually ingested! Lol!

(03-04-2013 22:27)Ray Davis Wrote: [ -> ]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.

Hey Ray,

That's interesting, thanks. So CANpod only implements the ad-hoc mode? I could do the same.

Probably the cheapest and most proven approach, at least in the Arduino world, would be to equip each Arduino with an ethernet shield and wire them all to a single wireless bridge/hub and transmit J1587 over UDP/IP (or whatever CANpod uses). The wireless bridge could be set to function in ad-hoc mode.

Assuming each wireless device ( the CANpod, bridge, and iPod) implements the usual collision avoidance (CSMA/CA), you'll see a single data stream and you may not need to tell CANpod packets from Arduino packets - no de-multiplexing required on your end, everything on the same port number. Would that work?

David Brady Wrote:That's interesting, thanks. So CANpod only implements the ad-hoc mode? I could do the same.

No, CANpod can participate in an infrastructure wireless network, however that is NOT something that is easily configurable by the customer. I've only tried it one other time, and got it to work, but the handling of the security encryption types is a bit limited, it's not as robust as a good wireless router, for example.

It can be done, but does require a special serial cable, and the ability to connect in via a terminal program and typing some configuration commands. Not something I would want most customers to try themselves.

I had assumed your sensors would connect into a wired network, which ultimately connected into a wireless AP that the CANpod could connect with.

Ray

(03-05-2013 21:48)Ray Davis Wrote: [ -> ]I had assumed your sensors would connect into a wired network, which ultimately connected into a wireless AP that the CANpod could connect with.

Ray

Thanks Ray. Yes, that's exactly what I'd do: multiple sensors per arduino, each arduino ethernet wired to a wireless AP, and CANpod configured to participate in infrastructure mode. I'm just trying to eliminate any extra work for you. I'd like my J1587 to look just like the data stream that you get from the CANpod, same SSID, same transport protocol. I'd like to eliminate the multiplexing step. My data stream simply looks like more MIDs/PIDs coming off the CANbus, of course it's really originating from my arduino sensor network. Any ideas? I guess it depends on what the CANpod transport protocol looks like. In the unix world you'd creat a udp_socket and bind it to a port number and you'd receive everything on the specified port (disclaimer: I know this isn't unix and it isn't UDP ).

(03-05-2013 20:10)davidmbrady Wrote: [ -> ]you'll see a single data stream and you may not need to tell CANpod packets from Arduino packets - no de-multiplexing required on your end, everything on the same port number. Would that work?

David--

Me (3208), being obviously not confined by an existing data bus or existing data stream, I haven't given enough thought to combining data streams. Are you thinking something like: the iPad would see the AP and CANpod stream as coming from one wireless source? I don't know why this wouldn't work, but I haven't spent any time with the node identifiers from the SAE spec.

What if an arduino captured the CANbus stream, assembled data packets from the additional sensors on arduinos, and sent the CAN stream with added sensor data to the CANpod?

I'm trying to understand how to pre-process arduino-supplied data to minimize any need to rework the front end (RV Tech Tools) software.

--Ned

Hey Ned,

Same here. It would be ideal if we could work it so that additional front end work would be minimal or better yet, non existent.

Being an engineer, of course I want to find as general a solution as possible. In your case you have no legacy equipment, in my case I have have J1587 over J1708, others may have J1939. So we might constrain you a little so we can better serve mixed enviroments.

Funny you should mention the idea of an arduino CANbus sniffer. I've been thinking the same thing. The CANpod does a lot of things we don't need. If all we want to do is read the bus, heck all we need is a single RS-485 and an 802.11 wireless shield. Since we don't write to the bus then there's no need for a fancy canduino shield.

Yes, I'd like our SANduino (Sensor Area Network using Arduinos) and the CANpod to look like one data stream going into the front end. For this to work, I think the CANpod transport layer needs to be connectionless, unreliable delivery, similar to UDP. So I think the feasibility of this depends on what the CANpod transport protocol looks like.

(03-04-2013 20:04)davidmbrady Wrote: [ -> ]

(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?

A few things I want to follow up on, from the recent discussion with Ray:

Somewhere I've been on the web (maybe in the CANduino pages?) discussed an issue with buffer filters and masks--if I remember correctly what I read, the CAN data stream will overflow the buffers if every message is accepted, so they configure filters and masks to get only the messages of interest, which I think means the CAN bus will have data for only the MIDs/PIDs requested or allowed by the mask/filter. At any rate, it sounds like it can handle many fewer messages than A SAN or CAN is capable of generating.

If filters/masks are a normal part of your DDEC or CAN configuration, then it *could* be where the fan speed PID 026, identified in the spec but not seen in Ray's tests, could be dropping out. Or, maybe a lot of other things--I bring it up to keep it in play, because it kinda suggests that there is a lode of data waiting to be requested or transported. Talk about the benefits of leveraging existing resources

Does VMSPC let you request PIDs that it isn't already reporting? Any front end would have to know something about the requested data in order to display it in a graphical or otherwise sensible way, and I am guessing that adding PIDs/MIDs to the stream means a big fat change request for the GUI developers. Or maybe they've already included a library of gauge parameters for every CAN PID

Did you get a complete list of PIDs/MIDs? The J1587 spec is available on the SAE web for ~$60 download. Beware, they will try to up-sell you to a subscription to the entire collection of J1939 family of documents. It is all more $$$ than I want to pay--I'm going to beat the bushes some more to see what is freely available. Some CAN books at Amazon look interesting--check the reviews, some aren't as targeted as their titles suggest. But I think I am going to dig around for good web resources. I expect the openCAN spec will reveal a lot.

Have fun.

--Ned

----------------
Ned Bedinger
'91 SP36

A fowl doesn't forget
where the eggs are laid.

Hey Ned,

I need to download a copy of Ray's Techtool to see what's user configurable. I've been using Silverleaf's VMSpc for quite some time now so I'm pretty familiar with it.

In VMSpc, and I imagine in Ray's product too, the user can define new gauges (simple, scan, odometer, transmission indicator, task bar, multiminder, multibar, and histogram). The user can then give the gauge a name, define a PID, and define values (min, max, yellow/redline), and formats, multipliers, and offsets.

For example, I went into VMSpc and I quickly configured an new gauge that I named "Fan Tach", I gave it a range of values, and a PID, and I'm ready to go. I'm satisfied with the level of user customization that VMSpc provides and I think it's adequate.

The issue is whether we can have VMSpc or RV Techtools receive a data stream on a port and not care who the source is. I've had some correspondence with the folks at CANpod and I learned that they do encode their J1578 over UDP/IP. This is great news. As you know, UDP is connectionless, unreliable delivery, so we should be able to intermix our packets with predictable results. Now it depends on the Apple API's that Ray depends upon. Like I said, in unix it's easy to simply ask for all packets on a given UDP port number. I don't know what's required in Apple land, if they negotiate a new port number or if they associate a given port number with the sender's source IP address. Maybe Ray can help here.

I don't see bandwidth or processing power to be an issue. I think a SAN will work great while using almost no bandwidth. I'm envisioning sending PIDs once a second which is incredibly slow. We're only looking to periodically update a user display so anything more than a 1s rate is probably wasteful, and for some sensors we may go even slower than that.

It'd be great to get a copy of the J1578 spec. I may spring for a copy. I'm still confused over MID/PID user defined space, or if it even exists, or what the best way is for us to encode our SANduino!

Sorry for the delayed reply. We had our first grand-child at 4AM on Wednesday morning, so it's been a bit of a whirlwind around here.

So a couple of things to mention.

1. Customization. Currently the app does not allow you to add gauges, where it sounds like vmspc does. I have not downloaded vmspc, as I didn't want to try to copy Silverleaf's product. I would be curious what info you need to provide to add a new gauge. In the J1587 spec, the data coming down the bus can be varying types, varying lengths, different offsets and scale factors, besides specific MIDs and PIDs. So, I am curious how you define a custom gauge.

The ability to add additional gauges is something I want to get in for future version of the app.


2. Working in the rPi/arduino world. I spoke yesterday with a friend who happens to be another rPi/arduino fan. I think we came up with the recipe that would work at least for my app, however I don't personally know how you are going to get the data to vmspc.

In the case of my app, I open a connection on port 23 to the CANpod device directly, send down some initialization commands, and set it in streaming mode. From that point the app reads the data as fast as it's coming, updating gauges.

For my app to work with your arduino network, I think I see it working this way. I believe you indicated you are not going to tap the arduino's into the CANbus, but would have a wired IP network to the sensors?

If so, I would imagine that your sensors would be multicasting on a UDP port of your choice. You would set up an rPi on the wired network that collects these UDP messages, and set up a telnet server, which effectively looks like the CANpod to me. The wired network would plug into a wireless access point that the iPad can connect through.

Instead of my app connecting to a CANpod, it would simply connect to your rPI, and as long as the rPi streams the data in the same format that RV dash expects (basically the binary J1587 turned into an ascii representation), then this should pretty much just work.

The CANpod to me is actually a telnet server, one which understands a few commands. So, as long as your system responded in a similar fashion, then I think it would work.

Ray

---

I was just re-reading Ned's post above. I will admit to a couple of things here.

1. I am not a CAN bus expert. Luckily most of the details of interfacing t the CAN bus was done by the hardware I found to work with, i.e. the CANpod device.

2. I didn't read the link posted much earlier in the thread, which referenced using arduino and rPi devices, so I may have made assumptions about your implementation which were invalid.

In the particular case of my app, and the hardware used in it, the CANpod is set to stream every message coming down the CANbus, and the app reads every message, and updates gauges as the data is parsed. There is the ability in the CANpod control to set filters, which I've not done as the control is at a bit level, not a per-message level.

So far the iPad has not had a problem keeping up with J1587 data. However, J1939 data comes much faster, and that is a concern as I move forward to J1939 support.

One note about the fan-speed PID. As mentioned in my testing, I haven't seen it. In fact, I don't have it coded in the messages that the app does decode. But, the fact that I haven't seen it could be due to two reasons.

1. The 026 PID is marked as "upon request", so it may be simply that my app would need to send a request for that.

2. Or the vehicles I've tested with don't have a fan sensor, so that data would never be available, even if requested.

Next time I am out at my bus, I can certainly find out, however different engines might give different responses.

Ray

Hi Ray,

Thanks for the detailed information, and thanks for hanging in here with Ned and I as we sort this out. BTW, congratulations on your new grand baby, that's very exciting!

I now understand much better what you are doing. Earlier on you kinda thru me off with the J1587 as an ASCII encoded data stream. Now that I see you're running everything, CANpod configuration and J1578 data stream, over a reliable Telnet connection, the ASCII data stream makes more sense. It certainly works, and we could do it with our SANduino as you describe by using extra processing in an rPi. Alternatively we may be able to implement a full TCP/IP stack with a Telnet server in an Arduino, but we have such limited processing power and memory it's doubtful. I'll have to look around to see what's available. A full TCP/IP stack and Telnet connection is great if you want to transmit long distance, say across the internet, but for a SAN inside a bus I think it's kinda heavy weight. Is there another option with CANpod where you can receive the data stream as a UDP datagram? That would be much lighter. Even for your existing product, a lightweight UDP connection for the data might be preferable in terms of processing power needed. I'm wondering about CANpod sending J1578 over UDP/IP. I understand from the folks at CANpod that they can do this - maybe we misunderstood each other. Nonetheless, you're proposal is a solution. Thank you!