GPS/Computers

[Searching]

Do GPS manufacturers know that NMEA conections are long gone, and USB and fire wire is here?

I havent got NMEA on my puters for three years now. I cant get theNMEA connection to work well without trying to "spoof" the connection.

Lets get together and strat something to get the manufacturers get it together

<hr width=100% size=1>

 

[BrendanS]

Errr, there ain't no such connection physically. Put your cable on your serial port.

NMEA connection is just a connection standard. Works even on latest MS XP type operating systems.


What problems are you having, someone can probably help


<hr width=100% size=1>

 

[Guest]

[url]http://groups.yahoo.com/group/gps-navigator/[/url]

Join the group -------- all can be explained .....

Oh Yes ---- he's right - NMEA ia an International Standard and actually is the best available.

SEATALK is the real nerd in the business with no cooperation really from Raymarine to release the code to others. IN fact the word is they 'altered' a German guys original code to create SEATALK ....... but its a story ????


<hr width=100% size=1>Nigel ...
Bilge Keelers get up further ! I only came - cos they said there was FREE Guinness !

 

[qsiv]

I dont think spoofing will help at all, as this is a technique that is applied to TCP/IP communications, whereas NMEA is a variant of RS232 serial.

NMEA 2000 is due at some stage and will offer significantly better data rates (whether nav software on computers needs it is very arguable - but it will assist gyro stabilised radars and ARPA systems). As for USB - it is really only a high speed serial connection and as such not really much different to RS232. Given the long (noisy) cable runs that exist on many boats I doubt whether it would always be useful.

<hr width=100% size=1>

 

[Guest]

Given that most NMEA is slow

What is real need to speed up ? OK I can understand for some instruments and data. But average data and instruments that yachts are concerned with are on data repeat of seconds so a slow bit rate of 4800 is more than adequate. Most GPS and nav packages couldn't handle data flooding in/out too quick anyway.



<hr width=100% size=1>Nigel ...
Bilge Keelers get up further ! I only came - cos they said there was FREE Guinness !

 

[qsiv]

Re: Given that most NMEA is slow

I agree - ata practical level for poor hardworking software authors (like me) all it does is to increase the processing load for no particular advantage. What I would like is a box that accepted NMEA, and which I could poll when my system wanted to for data - this would remove the overhead of parsing huge volumes of data when I have no particular interest in it at that moment.

<hr width=100% size=1>

 

[Guest]

What about a variation on ....

You can basically store info in a box when you have a slow printer and want to fre up the PC ... sorry had a beer and my mind can't remember the name for the bloody thing !!!! Is it not possible to adapt something like that ?? But of course you would have to e selective as you don't want the position info. being queued !!!!


<hr width=100% size=1>Nigel ...
Bilge Keelers get up further ! I only came - cos they said there was FREE Guinness !

 

[qsiv]

Re: What about a variation on ....

Sounds like you're talking about an fashioned printer buffer. I dont think that that is exactly what is needed, as that is simply a FIFO queue, and requires you to empty the queue synchronously - broadly speaking as fast as it is filled. What I think would be good would be something that 'ate' the NMEA sentences and stored the 'answers' which could then be asynchronusly queried/read on demand. This would then allow the 'balck box' to provide both time averaged data as well as filtering extraneous data, whilst minimising the load on the plotting software. I find (in my software) that these functions eat about 18% processor time (on a 1.2M machine), which is a significant overhead. I have mimicked this with an NT service on a separate box - but thats a pricey and energy hungry solution. I suspect things like Sailmath's Wave Processor do broadly this task (as well as using the rate gyro to correct AWA from the masthead by the roll and pitch rates) - but it would be nice to provide a lower level of funtionality for less than the £10,000 a solution like this usually costs.

<hr width=100% size=1>

 

[MainlySteam]

Re: What about a variation on ....

I would assume that given the price of seperate boxes to do processing for non high volume market applications, the cheapest solution is to have a seperate PC on the NEMA bus doing that processing and responding to calls from the main PC (assuming you don't have to pay someone to write the software for it that is).

John

<hr width=100% size=1>

 

[qsiv]

Re: What about a variation on ....

The software isnt abig issue (for me at any rate) - but to have another power hungry, fragile PC might well be. I'm just beginning consider using a Pocket PC (which are available in Industrial formats), and by definition draw very little power. The big issue theer is getting a second serial port for the query and answer, although Bluetooth migh be a neat answer.

<hr width=100% size=1>

 

[Rich_F]

Re: What about a variation on ....

18% of a 1.2M processor? That's, umm, 216MHz to process a 4800 baud connection. When my old 16MHz PC was able to handle a 9600 baud serial connection with no difficulty. I think something is being very inefficient in your system.

I'm interested, because I'm thinking of adding a USB port expanded with multiple serial ports, then writing a software NMEA merger and Seatalk converter. And I'd like it to run on a 300MHz PC at the same time as a chart plotter. Am I doomed?

Rich

<hr width=100% size=1>

 

[tome]

You need to understand the origins of NMEA and why it cannot easily be replaced by USB or firewire. It was conceived as a standard method of connecting equipment on ships. The most obvious method was serial data, and for our applications the single ended RS232 standard would have been the best to go for as all computers were fitted with serial ports meeting this standard.

The problem with ships and RS232 is that it is subject to interference and losses which limit it to about 100 feet or less- fine for us but no good on ships where the cable runs can be many hundreds of feet. For this reason the differential RS422 standard was chosen. It is far less prone to interference and losses (I've tested it to over 1,000 feet with no loss of data) and so was chosen as the standard within NMEA. It is possible to run RS422 into a RS232 port provided a differential ground is provided (Garmin do this) otherwise an adaptor is required.

NMEA also defines the protocols, speeds, and message formats.

I suspect that your post is lamenting the demise of serial ports on notebook computers. This is a real problem and the only way round it in most instances is to use a USB/serial adaptor. However, this is not straightforward either as there is considerable overhead to USB which is not the case with RS232 serial comms. This leads to some strange and unpredicted behaviour and can make the connection of real-time data (eg GPS) a headache. I'm sure many have experienced frustration in trying to connect via USB.

I'm not sure that even having a USB port on the GPS would entirely cure the problem as some of it is OS related.

<hr width=100% size=1>

 

[tome]

Re: [url]http://groups.yahoo.com/group/gps-navigator/[/url]

Nigel

Raymarine isn't the only culprit here, and the issue only arises because of speed limitations within NMEA. As you are aware NMEA is a comma delimited text format: great for decoding and reading but highly inefficient in terms of moving data around. This caused the manufacturers to develop more efficient protocols, most being binary.

The Seatalk protocol allows depth to be sent in just 5 bytes. In NMEA it takes 30!

Simrad has their RobLink protocol which is similar, but try to get any decsription and you'll find it more difficult than Seatalk.

Regards
Tom

<hr width=100% size=1>

 

[tome]

Re: Given that most NMEA is slow

Qsiv

This is precicesly what we do with our professional nav system. All incoming NMEA data (lots!) is timestamped and placed into a buffer. It is filtered by message type and frequency so that only the sentences you are interested in are passed through. Likewise, high frequency data (eg gyro at 20Hz) can be filtered to say 2Hz. All filtered data is written to a dual port RAM which can be polled by the application, and an interrupt tells the processor that the RAM is full (at which point it switches to a second bank). Timestamped raw data can also be logged to disk for later replay - very useful for equipment trials.

We are about to develop our 3rd generation system. Without giving too much away this will have an embedded PC and will act as a navigation engine to the application with communications via ethernet. This will allow it to be used with almost any application platform.

Regards
Tom

<hr width=100% size=1>

 

[burgundyben]

maybe here then

my post this morning has been largely ignore on the pbo board so here it is

"I'm sure this has been raised before, but here goes.

I've got a Garmin 128 GPS and a NASA DSC SX35, I have connected the two via the NMEA leads, I've got the NMEA out from the GPS connected to the NMEA in of the radio and vice versa (have tried transposing the wires too).

I've got the GPS set to NMEA output and NMEA input and set to version 2 and baud rate 4800. The radio is set with LL turned on and manual LL turned off.

The screen on the radio has 99 999 999 and 999 999 999 only in the screen handbook say this means NMEA not connected....

How do I go about testing the output from the GPS? and then what do I do?"


<hr width=100% size=1>Sod the Healey - I think I'll buy an E-Type.

 

[Twister_Ken]

Garmin funnies

I also had a problem connecting Garmin to DSC. Called Garmin help line. Can't remember details, but they do something funny in terms of mixing nmea and ground lines in their cables. They told me what to connect to what and everything has been aok since (fingers x'd).

<hr width=100% size=1><A target="_blank" HREF=http://www.writeforweb.com/twister1>Let's Twist Again</A>

 

[tome]

Re: maybe here then

Bugundyben

I connected this same setup for a friend last week, and it's working fine. You need to connect just 2 wires:

Garmin to NASA
Blue to Brown
Black to Red

The baud rate and version is correct on the Garmin, don't recall having to change anything on the Nasa.

Regards
Tom

<hr width=100% size=1>

 

[burgundyben]

Re: maybe here then

I think that's what I've done, have printed the thread and some stuff from the garmin site showing connection of an earth wire, will pop down to the boat tonight.

<hr width=100% size=1>Sod the Healey - I think I'll buy an E-Type.

 

[tome]

Re: maybe here then

Just a thought - have you entered the MMSI number? I believe that some sets disable all DSC functionality until this is done.

<hr width=100% size=1>

 

[qsiv]

Re: What about a variation on ....

Part of the overhead is a USB to serial driver - they seem inefficient. The other workload involves a certain amount of vector maths.. I compare the true TWA against the AWA and if they are different (because the instrumnents are lagging in a manouevre) I recalculate one or other based on previous trends - of course such trends need to be calculated and maintained as well. It is the overhead of the vector maths that is the bigger load - although simply parsing the string does take a measurable quantity of time - say 10 sentences a second, each of which have about 5 string to numeric conversions. Most of this data is just not relevant on a second by second basis. Bearing in mind we are continuously calculating time to mark, time to tack, time to layline and also running statisttical prediction to try and identify the time scale of wind shifts and gusts (lots of Fourier transforms) there is a LOT of maths being done. Drawing the chart is the least of the issues!

<hr width=100% size=1>