Discussion- Multi-purpose Onboard Computers

The tutorial that Billy submitted is a good overview, but of interest to our group is a piece of missing information in the list of variants--among other protocols that are built atop the CANbus is the NMEA 2000 protocol. Many of us are hoping that the NMEA will make the standards for NMEA 2000 open (at no or little cost for developers) so that people like us can afford to write software and design hardware that talks to the rest of the devices on the boat. At this point, buying a copy of the standards manual is keeping all but the major players out of the game.

It is amazing how slick CANbus can be, however. One of my consulting jobs right now is designing interfaces for Caterpillar industrial/marine engines, which all use J1939 protocols. It's pretty gratifying to tie just about any gauge or sensor into the J1939 CANbus dataline and had it instantly communicating with everything else on the engine.

 

Tim,

I'll certainly do what I can . . . but I'll be interfacing to a Zilog Z16F series embedded microcontroller via it's SPI port, and I don't know how relevant that will prove to be. Also, I will be working in ANSI C and assembly, not C++ (which I have never used), so I'm afraid my contribution will be very limited. I will try, though.

BillyDoc

 

We can always link to C routines, or combine them into the code as required.

Alternatively, any information you can give us on the protocol would be very helpful.

Cheers,

Tim B.

 

OK, that's good to know . . . about the possibility of linking in C++ I mean. It also occurred to me that the SPI port on an embedded processor is, in fact "serial" so it may be possible to put together a USB to CANbus box with fairly little difficulty. I'll look into this when I get to it, which I don't expect to happen until at least the end of March (when my hardware is promised for delivery). Assuming, of course, that the USB route would be worth the fuss with the drivers. RS-232 is another possibility, albeit rather dated, slow, and not as available as it once was.

Maybe by then someone will have figured out if the NEMA 2000 standard is compatible with "ordinary" CANbus (whatever that is!).

Cheers to you too,

Bill

 

I'm sure there are CAN to USB, serial and network convertors around. If that gives a "virtual" serial port then there's no problem. Perhaps not the lowest component count for an embedded system, but it should reduce the complication massively.

see:
http://www.canusb.com/

Cheers,

Tim B.

 

Hi Tim,

Actually, for my embedded system I'll be going directly from the on-chip SPI port to the MCP2515 chip I gave the data sheet for a few posts up. I was thinking of the problem associated with getting data into a PC for shipboard use when I suggested USB. Glad to know it's a common problem though, I'd much rather buy a cheap "dongle" than develop my own!

Cheers,

Bill

 

I love the simplicity of using a USB dongle to bring in CANbus info, especially if we're just tapping into one point in an existing CANbus network. Trying to establish an entire CANbus control/monitoring system, however, this would not be a practical way to operate. The CANbus physical layer specs call for a data rate of 250 KBits/sec, twisted pair cable of 120-ohm impedance (most commercial twisted pair cable does NOT meet this spec, but something like Raychem 2021D0309-O does), and two terminating resistors, 120 ohms each, at opposite ends of the backbone; maximum bus length of 40 meters; maximum stub length of one meter each. Bit timing is essential, too, which I assume is dealt with by the USB dongle, but why have a bunch of hardware all messing around with speed translation? It seems to make more sense to just tap in at one point only, and let the CANbus/NMEA 2000 hardware do its thing--which is probably exactly what you wanted in the first place, so OpenPilot can just read and send info?

Just so nobody else is confused, the picture of the CANUSB adaptor dongle is showing an RS232 part, not USB... But they're advertising USB, so I assume they've really got one.

 

drshaddock,

I was confused by that DB9 plug in the picture as well, but it turns out there is a CAN pinout for DB9 and the picture is showing this. Here's the pinout below and a better picture of the converter. And thanks for the details on the bus. I assume that this converter either has a termination resistor built in (or provision for one) or is intended as a "pigtail" in the loop somewhere. Looks like a nifty device to me, priced at US $154.

BillyDoc

 

One more note I forgot, to you guys who are looking to incorporate CANbus communication into OpenPilot--the www.canusb.com link provided by Tim will also get you to some opensource drivers and utilities for CANbus--in Linux as well as Windows. They've got code already written in C and C++.

Another note for programmers--if you're working with a CANbus-enabled chip, usually this is taken care of in hardware, but if you're writing software from scratch and you expect the hardware to be operating in an electrically-noisy atmosphere (around air conditioners, inverters, gas generators, electro-hydraulic pumps, etc.), it helps a great deal to set a bit sample point of about 87 percent of the waveform height. This is a relatively late sample point, but it gives the best compromise between noise immunity and propagation delay. (I don't want to go into too much technical detail here; hopefully any software engineers who've done communications programming will understand what I'm suggesting.)

Another point on the CANbus--it's a busy bus, and not specifically designed for huge numbers of nodes. However, it can handle large numbers, and there are some tricks to making it work well. One way is let people like Tim create filters in their hardware, checking the message header to see if the particular piece of hardware is 'interested' in it, and if not, just ignore it so the transmission doesn't have to be acknowledged. Another technique is to broadcast information on a schedule that matches the needs of the system--for example, an engine might broadcast its speed every 20 ms but 'hours run' info only if another node (like OpenPilot software) requests it, and a GPS might broadcast course every 200 ms and VMG every second. Note that there is no real overhead in just 'listening' on the network; all messages get sent out to the entire bus without addresses (which is a way that CANbus is different from TCP/IP). So OpenPilot can monitor all it wants and not load up the system's limited bandwidth. However, if you want to send control messages out from the software--change engine speed, lower the anchor, turn the rudder using the autopilot, and so forth--you could certainly do so, and it wouldn't be much of an impact on the system. What you DON'T want is to design, say, a fuel gauge that's sending out 50 readings a minute!

 

So, the next obvious question is who wants to incorporate CAN/NMEA2000 into OpenPilot?

Unfortunately, I don't have any NMEA2000 devices to play with!

Reading all the data and discarding what isn't needed shouldn't be too hard. you just need a routine to parse the data on collection, and that's easily done with QT4 by using a QSocketNotifier, and running a routine when there is data to be collected.

Tim B.

 

Ladies and gentlemen,

I have just released V0.2.0 of the OpenPilot Gauge widget.

I have also written a lot of the Linux-based NMEA 0183 code. It now needs the proper signals setting up and porting to Win32.

I have also tried to port the Map widget to Win32. I am having trouble with the GDAL library. Consequently this will take some time to do.

The Website has also been updated.

Fancy joining the team? Sign up to the mailing list via the website!!

Tim B.

 

The UnDead...

My abject apologies for having disappeared from this group for over 2 months...!!

I went back to the USA in December-Early January, and THEN:
I got an unusual opportunity to travel for almost a month to the interior of China with a Chinese writer friend as guide and interpreter.

I spent several days in a small Mountainside village in Hunan province where the villagers told me a foreigner had never been before. And I visited and photographed a number of very rural areas in Hunan and along the Milou river, and in MuFuShan National Park. I was greeted by friendly people in every little village, with "Chee-Nai, Chee-Nai" (Come IN, Come in). And I was warmed by sitting close to their tables, pulling the blanket on top over my legs (There's a charcoal burner under the table!). Food, fiery Rice Wine, smiles. It was just incredible. What a friendly culture!

My friend was asked to speak at his former "Mother School" and somehow I was also asked to speak to the students, so I did a quick 1-day writeup of my readings and prejudices on "Multiple Intelligences", "Dare to be Naive", "Say 'I don't know the answer' " etc., and other ideas about Education that are very much non-traditional in Chinese Education. I ended up speaking at 4 different schools, with no more formal Educational credentials than a beard and long white hair... Weird.

For over 3 weeks, I never saw another Western face.. and I got used to being the Curiosity on the street. It's COLD in China: there is no central heating, and students wear their coats all day in class and write with fingerless gloves. I wore two pairs of pants or long underwear for at least 2 weeks. Day and night.

OK, I'll point to some off-boat-electronics-topic photos in a couple days when I wade through over 1000 images and some audio recordings. Did I mention the constant fireworks??

SO: Please accept my apology, and my strongest kudos to Tim B. for his amazing hard work and to the many others who have contributed. I will read all the posts in better detail soon.

I hope I can still help with this and similar projects.

 

Hi Terry, if you post the pics I'd really like to see !!

 

Lo there Terry good to see you, and thanks, never travelled in Asia, apart from Siberia
went here though lately

 

Good to have you back, Terry.

Ok, Code update:

NMEA now works under both Windows and Linux. The windows code is not too efficient, but it does work. I have also changed the sample code to look more like the "finished" article. It will now do moving maps and show speed/track on gauges. I have also thrown together a small app which shows heading and speed (see below).

I have been having problems compiling against the GDAL library on Windows. GDAL provides the S-57 chart file interface. This only affects the Map component.

So, if anyone wants to work on improving windows NMEA, or compiling against GDAL, that would be great.

Cheers All,

Tim B.