hello if anyone is still hanging out on this thread.
I have gone away and done some research
Talked to technical representatives of Raytheon
, and Garmin
They all had the same story, and the words that come to mind in response do not bear repeating. (ever watch Deadwood? you get my drift).
They all will use NMEA2000/0183 as the transducer bus to the
first control head
. Then they convert to ethernet for subsequent
transfers of data and inter-head communications
None of them will disclose the data sentences, interface, ports
In fact they were just plain rude at even being asked the question.
As usual, they are doing lip service
to open systems but really
the only standard is the transducer bus.
Their philosophy still seems to be the same, sell transducers at
a "reasonable" price
and then charge ungodly horrible markups on the
heads which lock you into a proprietary protocol that prevents you
from intermixing systems in their most profitable items.
So, I have decided to press ahead with creating my own instrument set.
I have been evaulating performance of display devices and implementations (which i need some help with, more in a moment).
The solution i am implementing will be a server based system so that
any device that can host a browser can act as a marine
This means pc's, smartphones, ipods, ipads, even a kindle will be able
to be an instrument and control your boat.
My requirements list are as follows:
1. Purchased transducers (wind, depth
, speed, autopilot
, etc.) from any vendor conforming to NMEA2000/0183.
2. Any wireless browser enabled device capable of supporting
, PC etc.).
3. Total systems cost <$200 exclusive of transducers.
4. Wireless communications
among devices. (save for initial 2000/0183 entry point to server. as valuable as it is, wireless tranducer interfacing is deferred to release 2 mostly due to current
cost of interfaces devices).
gateway integral so both access to the internet
and control boat from the internet
6. Interface to OpenCPN
so every instrument head
is also a wifi
7. Video streaming on server so legacy radar
systems (composite video)
and on-board entertainment systems may be viewed and controlled
from instrument heads.
8. Extensible architecture so additional instruments may be added by users and/or submitted for approval and download from bulletin board by other users.
9. Total system power exclusive of heads <2 amps@12VDC.
10. Total system availability (exclusive of cabling and tranducers) >.9995.
I welcome any additions or extensions to this list provided the
submitter is open to discussion and critique (as am i).
every requirement involves work and i would like to see this finished
in my lifetime.
As to the architecture, I have made a few preliminary decisions.
1. Debian or Centos linux
sbc with Apache as central server.
2. DDWRT with DNSmasq as wifi control and gateway repeater.
3. NMEA2000 to ethernet gateway PIC based (i can get
both interfaces in a single
chip with a CANBUSS stack to start).
I am leaning toward the BeagleBoard-XM (not the regular beagle board)
or the gumstix as the SBC. While the raspberryPI would be very attractive, so far it is just that; pie in the sky.
No one can actually get one.
The BeagleBoard has excellent support and has been in continuous production for three years now.
Finally, where i need a bit of help.
I coded up a test wind
instrument to measure graphic performance
graphic performance of the device and page updates perfromance over the wifi to the sbc).
I have found wide differences
in the implementations.
I need some more info from other devices as my test base is relative limited.
To download the test fixture, go here.
There are two buttons. The right button adjusts the number of degrees
the needle moves per tick. Its setting doesn't matter much it is only
there to allow movement to even be seen on slow devices. Set it to
one degree if you have a fast device. Move it up toward 10 if it appears not to move.
The important button is the left one. As you click it and move the time between ticks down, at some point you will notice the needle start to lag, jump, perhaps the screen
to flash, or even hang and quit.
I am interested in the lowest time value where the needle moves smoothly without
artifacts such as this.
To date i have the following results:
2.4Ghz P8600 Windows 7 PC:
Under firefox: 100mS.
Under chrome: 50mS,
3G (yes, an antique): 1000ms,
Two different Android smartphones: 100mS
I don't need much more PC information unless you have a particularly
old or fast one. (a 32bit pentiumII would be interesting for instance).
However, I would love to hear from IPAD
IandII users, iphone3GS/4 users, and some more android based phones and tablets if you can include the make and model of the phone
. And hey, if anyone has
XBOX/WII/playstation that would be a curiosity. This instrument set should run on whatever you have. Wanna stick an LCD TV at the helm
and run it on WII while controlling it with movements in the air
like some kind of marine hawaii
5-0 console that sounds cool to me.
I will try and publish the architecture diagram when i get the spare time to put it in computer readable format. (its fall here in tennessee
and i do have to get wood in the shed lest i freeze on this mountain).
I appreciate any and all feedback either here on the forum or via
welcome. I tried to code it to run quickly but remain in layers so a basic instrument could be defined (buttons, screen
, etc) and then extended by layering atop it.
And finally, I AM NOT an artist though i wish i had that talent.
the colors on my test fixture are awful. any suggestions there
will be taken quite seriously. layout suggestions are welcome as well.