CAT 3208 monitoring

[Ray Davis]

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