Onboard Computers

MOVING this discussion to Wiki: "Onboard Computers" discussion page

OK, this thread will be moved to:
http://www.boatdesign.net/forums/showthread.php?t=16413
(That's the only link I could find....) which is the discussion for "Onboard Computers. I'm not sure the best way to 'move' this. I may just 'copy' it unless I find a better way.

The Wiki section "Onboard Computers" is at:
http://www.boatdesign.net/wiki/Onboard_Computers
NOTE: The "Discussion" tab at the top brings you to the thread above.

 

"MOVE" of thread started in " Using 12v System to Directly Power Computers and other"

OK, I'm trying to "Move" or copy the old thread to continue it here...... hold you nose...
*****************************
----( Well, this WASN'T too great... Thanks, Jeff, for moving it! )------

 

Tim, please continue this over in the "Onboard Computers" Wiki discussion area. You've got a lot to offer to this discussion.

I'd like to discuss how we could help a user build a DIY "More embedded" system than using XP. I like the idea of a more bulletproof system (if that's truly what they end up with).

 

Continuing discussion with Tim B about O/S

----( copy )--------
Tim, please continue this over in the "Onboard Computers" Wiki discussion area. You've got a lot to offer to this discussion.

I'd like to discuss how we could help a user build a DIY "More embedded" system than using XP. I like the idea of a more bulletproof system (if that's truly what they end up with).
----( end copy)-----

Tim, I can see this from fourteen different directions, and none of them come with a guarantee of bulletproofness. (The 15th would be the guys I met while at IBM who wrote and tested the code that ran the Lunar Lander !!)

Nothing is perfect, and any sailor who isn't prepared to pull out his backup handheld compass and stashed waterproof chart is foolish.

I have witnessed, or been involved with managing, Jeezum! I bet 1000 software failures in running factories. From the IBM 1800 - System/7 - Series/1 - Industrial AT - Gearbox to assorted PDP-11's - SUN - Motorola - etc etc. EVERY one of them crashed with hardware or software errors!

So, what the heck do we do??

Let's not slam any doors. Let's try to learn as much as possible about the different possibilities, and learn as much from the work and mistakes of others as possible.

The immeasureably cool thing about this to me, is we get to try stuff out on our own and really use it, and bulls*** about it with people who have a clue and who care to spend their time figuring stuff out.

My fantasy is that a year from now several of 'us' will have built different working systems based on different hardware / OS-kernel / software and documented it well enough here so than someone else can pick up where we left off.
------------------------------------------------
The one who dies with the most (Toys, Parts ) or (unpublished software) LOSES! What do you need that I have??
------------------------------------------------

 

This Thread Moved

This thread is now at: http://www.boatdesign.net/forums/showthread.php?t=16413

 

Tim B;

I don't want to argue with you, so here is an excerpt from http://www.linuxdevices.com/articles/AT6449817972.html that I think makes my point better than I could.

"A few words about Linux on Embedded-PC SBCs

These days, most manufacturers of PC-compatible single board computers claim to support embedded Linux on their products -- either directly, or via third-party relationships with embedded Linux software providers. However, be careful not to get too complacent when the sales rep says "Sure, we support Linux."

In general, Linux support for PC-compatible embedded SBCs tends to be straightforward -- provided: (1) the chipsets used are mainstream and fairly current; and (2) the chipsets have been used in the normal manner. Always ask the SBC vendor what specific versions of Linux they have tested, how they conducted the tests, which interfaces on the SBC were exercised, and what functions are either untested or unsupported.

Specifically, areas to watch out for include . . .
Display controller modes beyond VGA

LCD panel control signals

SCSI

PCMCIA

Onboard solid-state disks

Nonstandard functions like watchdog timers, digital I/O, and analog I/O

Ethernet (in some cases)
Knowing that Linux drivers or in-kernel support exists for the chips used is encouraging, but that's not sufficient. SBC manufacturers often take shortcuts to save money or board space, and in the process may unwittingly sacrifice compatibility. In short: there's no substitute for testing! "

P.S. This whitepaper was written by LinuxDevices.com founder Rick Lehrbaum

 

Maybe I'm too much of an engineer at times, but if I'm investing time and money into a system I want it to work. Not need replacing every 500 miles.

Personally I'd love to use an Acorn A7000 motherboard as the base for a system. Simply because they don't fail. Unfortunately, I don't think many other people would support the decision. So we go to the next-best thing, an ARM chip and Linux. THese guys seem to have the right idea:
http://www.embeddedarm.com/

Of course there are 1001 things that Linux might not support, but Linux does allow you to write the routines yourself without holding certain vital organs to ransom (a la Microsoft).

I would personally always advise caution when considering reliance on a proprietry OS, particularly a closed-source, poorly documented one, which is geared towards word-processing, not development.

Tim B.

 

I find it personally difficult to understand a problem with "Too much of an Engineer": You'd could have a discussion with my wife, however ...

After designing hardware (since vacuum tubes) and writing code for 33 years, and spending many $100,000 of other people's money on both successful systems and multi-year disasters that never were finished, I have a simple perspective:

There is no one right answer! And especially in software, software development, and systems software. As a guy I once met said, "There is No Silver Bullet". (Frederick Brooks).

It's been a heck of a long time since I wrote ALL the code for a working system of any size. (Well, maybe a small, simple PIC project). We are always dependent on other's work, and that's how it should be. We HAVE to reuse tools humans have built, or stay in the Dark Ages.

Since we're on a philosophical bent (or I am ) here's a quote:

MAN IS A TOOL-MAKING ANIMAL. WITHOUT TOOLS, HE IS NOTHING. WITH TOOLS, HE IS EVERYTHING. THOMAS CARLYLE 1795-1881

Pardon the CAPS, but I first entered that quote on a cassette-tape storage system on a 6502 system that I wrote the drivers for, and which had no "case" and so I keep it that way to remind me.

OK, so I'm Old! What's my point??

We all are going to be dependent on other peoples designs and code in any attempt at a modern shipboard computer system. Their system software, their compilers, linkers and utilities. And (shudder) their DRIVERS. What I'm worried about most, after many IBM O/S, DOS(n.n), OS/2, Win3.1, WIN-XP, UBUNTU, etc. the worry is the doggoned drivers! With a protect-mode OS it's pretty hard to really crash a system with code that WE write that runs as an application. But we're dependent on drivers.

So, bluntly, in 2007, I'm more confident in mature WIN-XP drivers from major hardware manufacturers like Intel, VIA, SIS, Radeon etc, than I am in those that are available for Linux or the various "Real-Time" OS systems that might run on applicable hardware. That said, I think there CAN be a stable Linux-based boat system, with careful selection of devices and drivers. And WIN-XP Embedded should be looked at too..

Oh, man, I once wrote a real-time multitasking OS, sort as a learning experience. Ran some stuff with it. I sure would NOT want to be on a boat running it!! I almost forgot about it. Then there was EDX. Spent part of my life debugging errors in it. Then there was WIN3.1 and my group's DSP drivers. I spend months of my life finding errors in that!

Nothing we can do will be perfect. There are many ways and O/S that can work on a shipboard system. There is no one answer.

I'd love it if we (in various collections of 'we') put together systems based on the hardware and software we like, make it work, and get navigation and monitoring software running, and then RUN it for 100's of hours.

THEN we'll have something that we can use, and others can decide to use as an example if they want.

Wow.. wound off again. Sorry for the excess...

 

I tend not to be enough of an accountant. My projects have a tendancy to stay just about in budget (usually. Well, I say usually...) and doing at least a few things that were nice, but not strictly necessary. All the best of British engineering really.

I remember the 6502 processor with a BBC Micro Model B wrapped round it. for it's time that was a damn nice machine.

Tim B.

ps. I know I can't write all the code myself. So I like to start with the most reliable system I can. Maybe my views are skewed from my usage of Linux on the desktop, but try it, I think you'll be impressed.

 

Sorry I'm a little late to the party on this thread. Terry, do feel free to quote me in the Wiki, if you think my advice means anything

I'm not an elec eng type, although I do work closely with them on the solar car. The Vicor DC/DC modules are the heart of our low-voltage power conversion system, which takes battery voltage (120-160 V ish, depending on pack structure and charge state) and gives us 12 and 5 volt taps that are stable enough for microcontrollers (the PIC18F is probably the most common in our setup). Vicor does sell complete ready-to-use modules that would be ideal for an onboard computer. http://vicr.com/products/custom_solutions/edp/ for example, their product range is huge and it shouldn't be too hard to find something that can give you ATX power specs from your main batteries.

Regarding OS.... OK, now this is a hairy topic I know. I wouldn't write off Linux so quickly. Perhaps the biggest difficulty there is there's nothing (at least that I know of) in the way of navigation/charting software for Linux; all of it is Win32 based. Which is bad, IMHO, because my experience with Windows is that you do not trust it with anything important. Let's get some nav software for Linux, shall we? A good thing to pressure the software companies on. I wouldn't even consider the CE or Embedded versions of Windows- at $1k for the development tools and a lot of work to get them configured for your device, it's not worth it.

A big question, that will probably be the main factor in choosing a system, has got to be "What is it going to do?" If your goal is to interface with radar, sonar and chartplotter, you'll be looking down very different lines than if you want to interface with four televisions, HD DVD player, 7.1 channel surround sound, etc. I suppose you could go down the Starship Enterprise route and build one massive honking computer that sails the boat, sets the coffee machine, monitors the engines and shows you Seinfeld reruns.... but then there's the danger of it turning into HAL and shutting down the whole works.

Personally I'm in favour of small, reasonably independent machines, each capable of doing its own task alone, but networked with enough sophistication that I can plot a course from my laptop or check the weather instruments from belowdecks. Redundancy is key.

 

Tim B;

As a Systems Engineer I tend to look at the main applications that I want to run and the drivers for the expansion modules that I can't live without and see what operating systems they require or support.

In this case I believe the main application that most boats want / need is an Electronic Chart Display and Information System (ECDIS). If the DIY boater can build his own chart plotter that uses free NOAA charts and is reasonably reliable then he can forgo purchasing a commercial chart platter and buying proprietary charts. This has the potential to save a lot of money and make all this effort worth the bother. I have reviewed all the ECDIS applications under "Systems that use ENCs" at http://chartmaker.ncd.noaa.gov/mcd/enc/resource.htm and I found none that run under Linux. In fact with the exception of MacENC(TM) they all require some version of Windows.

I think your opinion of Windows XP is unfounded. I use Windows XP everyday and I find it very stable. I hibernate often because I don't want to take the time to shut-down and restart when I carry my laptop from meeting to meeting. Despite this I go several weeks between restarts and crashes occur once or twice a year. I plan to run Windows XP (possible embedded) and Rose Point Coastal Explorer.

 

Converging on "What an Onboard Computer Should Do"

OK, I think we're getting somewhere! The point was made that we should talk about what we want an onboard computer to DO. Let's try to prioritize and categorize these things.

The initial Wiki layout has these broad categories:
*Navigation Systems
*Onboard Systems Monitoring and Control
*Leisure Time and At-Anchor Activities

Please take a look at that section and add to/modify it!

Now, what about Priorities???

Any modern boat will have more than one processor of some type executing code. Here's the way I think about it:

----( ABSOLUTE Highest Reliability and Availability )----
The old BoyScout Silva compass on it's cord around my neck and under my shirt...

----( Highest Reliability and Availability )----
GPS running it's own Engine and Firmware, with it's own battery backup, and display readable at the Helm.

Onboard Alarms: Fire, Gases, Bilge Flooding with it's own battery backup, audible and visible alarms.

Dedicated Engine Gauges and Alarms visible/audible at the helm.

----( High Reliability and Availability )----
Electronic Chart Display and Information System (ECDIS). Moving-Chart WhereAmI.

Depth Sensors/Recorders/Alarms

Radar/Collision Avoidance Systems

VHF/HF Radios and antenna systems

----( Medium Reliability and Availability )----
GPS / Compass interface: up/download waypoints, maps, tracks

Chart/Recorders

Monitoring Systems for:
* Propulsion systems
* Onboard power systems
* Heating/cooling
* Lighting
* Water/sanitation systems
* Environmental and weather instruments
* Safety/Security Monitoring: Intrusion, Bilge Flooding, Heat/Fire, Dangerous Gases, Anchor Drag

* Communications thru Email and WWW

----( Optional Availability )----
* MultiMedia: Audio/Music(MP3), DVD/Movie playback
* Writing, Photo viewing and editing, Log-Keeping
* Other typical personal-computer activities


So, if we had to make decisions about how to collect these needs and assign them to one or more onboard computer systems, what would we do??

If I had to choose right now, I'd do something like:

1. Standalone dedicated stuff for "HIGHEST"
2. Stripped-down X86 WIN-XP (possibly Embedded) system for "HIGH"
3. Separate X86 WIN-XP for "MEDIUM" and "OPTIONAL"

What do you think?? What other possibilities are there??

 

I think you need to look at computer usage pattern of sailors in different situations. The demands of coastal sailors are going to be different from liveaboards, and people cruising in high latitudes may have different demands to those bobbing along in the trades.

Many of the questionaires conducted after the ARC and other similar rallies have thrown some light on this, at least for their type of sailing.

I'm been amazed that this discussion has got so far without deciding what USE the computer will have to perform. For me, I would only consider one if it could add value beyond what was available in stand alone instrument systems. A need for a degree of redundancy would mean it would never replace core functions, only suppliment them.

Therefore my requirement would be to run MaxSea with its necessary interface to an Iridium Sat phone, which would also allow for emails. Now if this requirement enabled me to have a choice of Windows or Linux, I would have to think about it, but the reality is that there is no choice, so therefore little point in discussing it further. Fiddling with tools that have no use is what sad old men do in their sheds. For the rest of us we just want a means to an end. In this case, a better sailing experience.

 

Contrary to popular opinion, you do have a choice. Just because most people do it one way, doesn't mean that a different system is any worse. I've come across the excuse "That's how we've always done it" far too many times in the last few years (in all walks of life), and it's quite amusing to see people's reaction when you prove that a newer method is better than the one their using.

I couldn't care less if no-one started using Linux because of me. The real message (from many "minority" groups) is "PLEASE ENGAGE BRAIN AND START BEING RESPONSIBLE".

As for usage, I see no problem in a rock solid system that will run power control and navigation software, and also give you web-access etc.

I see no problem in developing something because you want to see if you can. It's just called learning, so what if there's no great purpose in it. If everything you do is a means to an end, then it's a bit of a sad life, where everything has function and nothing has form or elegance about it.

One should remember, that no computer-based system on-board a yacht is actually ever that critical. You'd be surprised what you can do with binoculars, compass and a few lengths of rope.

Thoughts of a Philosophical Nature - Tim B.

 

"........a rock solid system that will run power control and navigation software, and also give you web-access etc......."

Can you give us a list of all the charting packages, weather routing programs and Sat Com bundles that are available for Linux so I can check them out?
Cheers.