PeterGo2

OK, sorry, you want to transfer from the iFinder Go to a PC (not the other way around)... I don't think this can be done, as the NMEA Output sentence selections are limited and generaly only apply to what you would need when using the iFinder as a GPS receiver (for example, sending realtime position data to mapping software on a laptop). FYI, I've also tried sending query sentences to the iFinder Go2 and it just ignores them. "Output" only broadcasts the selected sentence identifiers, and "Input" only accepts waypoints. So if you want to download trail data from the iFinder Go to your PC, I think you're out of luck. Hope this answers your question. Feel free to IM me instead if you still have questions.

Routes and distances, no. Individual waypoints, absolutely (regardless of what you may have heard ). Once uploaded, you can "stitch" your individual waypoints together into a route(s). Adding appropriate prefixes to your waypoints (e.g. 001<name>, 002<name>, etc.) before you upload them helps alot. You can either make a cable or buy one. Enable NMEA Input in the iFinder Go2 GUI using the default settings. (Also, you should disable NMEA Output - unless you have the iFinder connected to another device for use as a GPS receiver.) Then use an appropriate program to upload (I like gpsbabel myself). With HyperTerminal, remember to set the correct line-endings (CR-LF). This thread has a lot of useful info on the subject. Try reading carefully from the first post. Good luck.

kg340, Sorry, my German is very weak. You might want to try translating your message into English here: Babel Fish Translation And then edit for clarity's sake, and repost in English in this thread. (PeterGo2)

My firmware revision is like budd-rdc's : Version 1.3.0, Build: JR210C. This gives street-level detail here in the U.S., although most smaller streets are not named (not in my area at least). What version do you have over there?

Yes, I forgot that the default COM port settings won't work with NMEA. I use this line in my batch file to reset the COM1: mode com1 baud=4800 parity=n data=8 stop=1 xon=off odsr=off octs=off This will make COM1 match the default settings on your iFinder (which defaults to the NMEA 0183 v2 standards). HyperTerminal by default doesn't use the correct line endings for NMEA and I would avoid it; other wise you will have problems with bulk uploads. I don't know if you can also configure COM settings via the GPSBabel GUI (as I've never used it). (Peter)

Mike (Dan?), GPSBabel includes native support for Magellan 315 models, as well as NMEA 2.0 support (for units like the iFinder Go). You'll have to be comfortable with a command-line, though. Something like this (for reading a Magellan route file, converting to NMEA sentences, and sending it to the iFinder on COM1) might work: gpsbabel.exe -s -i magellan -f "MyMagellanFile" -o nmea,snlen=20 -F com1 (Peter)

AFAIK the only output sentences IDs supported are those listed in the iFinder GUI; and the only input sentence available (but not officially "supported") is WPL. Edited to add: As far as free map programs, I don't know much about that. I currently use TOPO! only because that was the first one I found (purchased at REI). It's convenient for a beginner but I wouldn't recommend it as it stores data internally using the "North America 1927 mean" datum, and converts to WGS84 for display and output.

There seems to be no way to download a particular waypoint. But if you enable NMEA Output and choose an appropriate identifier (say GLL) then the iFinder will broadcast that info every second. GLL would give you all you need to use the iFinder as a GPS Receiver (e.g. hooked up to a laptop with full-blown mapping software).

That part number is the same as what Lowrance tech support quoted me, but I can't tell from the picture if it really has the correct connector for the Go series. You should probably verify with the vendor that you can return it if it's not the correct item. If you're handy with a soldering iron you could try building a cable yourself per posts #6 and #10 of this thread. I don't know much about EasyGPS, as it's been several months since I looked at this. Whatever software you use needs to be able to send NMEA WPL sentences with the required <CR><LF> line endings. You could always use HyperTerminal (free with Windows) or gpsbabel (free also).

I did a search on Google for SiRF "iFinder Go" and most of the returned results indicate SiRF Star III for this model (I think the original iFinder was SiRF IIe). I have a table for Lowrance GPS model <-> SiRF chipset somewhere that I'll try to dig up.

You wouldn't want to use any handshaking. The limited pinout doesn't support hardware handshaking, and the NMEA protocol doesn't require it anyway. Just include <CR><LF> at the end of each line per the protocol. This perfoms essentially the same function as XON/OFF software handshaking. Track and Route uploads (via the RTE identifier) don't seem to work, but let us know if you can make this happen. At the least, you can name your waypoints in sequential order, bulk upload them via gpsbabel or HyperTerminal, and then stitch them into a route fairly quickly via the iFinder GUI. I have a copy of the SiRF Binary Protocol PDF manual which shows a vendor-specific NMEA sentence to switch the port to SiRF Binary protocol, after which there are specific SiRF Binary codes available for flash updates, etc.

As promised, here's a summary of Lowrance's reply to my request for documentation on the NMEA Input feature: [link]

budd-rdc, that has been my experience as well with my Go2. No line delays needed - just make sure the sending app also sends the correct <CR><LF> line endings. In another thread on this forum I promised I would post the results of my questions to Lowrance tech support regarding NMEA Input support for the iFinder product line. I may as well post those results here. I won't quote Lowrance verbatim as they may have some prohibition against that, but here's the gist of our e-mail exchange: Me: Can you tell me exactly which sentence identifiers are supported for NMEA Input on the iFinder Go and Go2? Lowrance: PC-DI5 (99-74) is a data transfer cable with an iFINDER connector and a DB-9 serial connector on the other end. Me: Thanks, but I already have that cable... I've already figured out that my iFINDER supports the "WPL" sentence. Are there any other NMEA 0183 sentences supported for input? Is iFINDER NMEA Input documented anywhere? Lowrance: The available NMEA sentence strings are GLL, RMC and RMB, APB, GGA, GSA and GSV, as found under NMEA Setup. Me: Those sentence IDs do not appear to apply to what can be sent *to* the iFINDER. In fact, most of those particular identifiers don't make sense in relation to input, as they contain location data that a GPS receiver would send, not receive. Lowrance: The iFINDER Go and Go2 will not accept NMEA input, even though that selection is on that menu. At this point I gave up on e-mail and called tech support. After speaking to someone who appeared to understand my question, I was put on hold for a few minutes while the rep apparently talked to an engineer (but maybe it was just a supervisor). When the rep took me off hold he informed me that NMEA Input is a feature that was incorporated into pre-production firmware and should have been removed from the production firmware, and that NMEA Input was officially "not supported"(!) Of course that didn't sound right to me, but I had already spent enough time pursuing a sensible answer to this question and wasn't going to push this any further. The fact of the matter is that NMEA Input is available in all iFinder models and is mentioned (albeit poorly explained) in all the product manuals for these models. If Lowrance really had no (initial) intention of supporting NMEA Input then why do they still they mention the feature in the manuals? And why haven't they removed the feature from the firmware of those iFinder models that support firmware updates? It's possible that the firmware designers added WPL input support simply because it's available as a feature of the SiRF chipset and relatively easy to implement. In fact, even if the feature was not available in the interface, it might still be possible to enable it via the SiRF Binary Protocol. Unfortunately, it's hard to tell if Lowrance is protecting market share for their more expensive models, or if they really just don't understand how their equipment works. At least we were able to figure it out for them.

casioqv, thanks for the info. The description for USGMGL is "USGM + GUGL". USGM is described as "USB>Serial module" and GUGL is "GPS Interface cable for Lowrance iFinder, iFinder Pro/Go - with built in voltage regulator (3.3v)". But the interface cable itself appears to be iFinder Go style on one end and USB type A mini on the other. So why is the "USB>Serial module" even necessary? Edited to clarify my confusion <g>: This picture of USGM shows what appears to be a USB type A mini on one end, and on the other end a (proprietary?) connector for plugging into their CK203 "Car USB adapter". After plugging the GUGL into the USGM, where/how would I plug the USGM into my computer?

You're welcome. For those iFINDER models that don't include memory card slots, NMEA Input sure beats having to enter waypoints manually. And even for those models that do include card slots, for routes with just a few waypoints, NMEA Input is probably quicker than removing & replacing the memory card. Waypoints uploaded via NMEA must be added to routes manually. We're still looking for a way to upload routes as well, but (as far as I know) nobody's figured out how to do it (if indeed it can be done). I've sent e-mail to Lowrance tech support asking for some documentation on this feature. I'll post a summary here of any answer I receive from them. (Peter)

Info taken from posts here and here in this forum: Most iFINDER models include an implementation of NMEA 0183 version 2.0. NMEA features are disabled by default but can be enabled in Advanced Mode via Menu > System Setup > Com Port. NMEA Output allows the iFINDER to be used as a simple GPS sensor (e.g. connected to a laptop PC with suitable software). Configure NMEA allows you to choose which particular sentences are transmitted to the COM port. NMEA Input allows waypoint data to be uploaded via WPL sentences to the iFINDER. The NMEA 0183 protocol specifies the following parameters: Baud rate: 4800 Number of data bits: 8 (bit 7 is 0) Stop bits: 1 (or more) Parity: none Handshake: none The protocol also specifies that sentences be terminated with <CR><LF> to indicate end of transmission. Be aware that HyperTerminal defaults to different settings, and you will need to reset these to match the protocol and the iFINDER. To do this select Call > Disconnect, then select File > Properties > Connect To > Configure, and make the settings match the parameters listed above. You'll also need to change HyperTerminal's default behavior to send the correct line endings. To do this select File > Properties > Settings > ASCII Setup, and enable "Send line ends with line feeds". You might also want to enable "Echo typed characters locally" to make any commands sent to the iFINDER appear in the HT console. WPL sentences require a specific format with a checksum, and it's easiest to use a program such as GPSBabel to convert waypoint lists from your mapping program to NMEA format. You'll first need to configure your serial port correctly. Here's a command to do that in Windows (you'll need to repeat this each time you restart your PC): mode com1 baud=4800 parity=n data=8 stop=1 xon=off odsr=off octs=off And here's an example command that sends a list of waypoints from National Geographic TOPO! to my iFINDER Go2: gpsbabel -i tpg,datum="WGS 84" -f ColdwaterCyn.tpg -o nmea,snlen=20 -F com1

Robert, As long as GPSBabel implements NMEA 0183 v2.0 correctly by sending <CR><LF> at the end of each sentence, then your program already supports the iFinder. My suggestion about adding line delay for other GPS models was based on what I saw in the GPS Utility program interface, not personal experience - please take it for what it's worth. ($0.02) BTW, the combination of iFinder Go plus the Lowrance cable is right around $100, which doesn't sound too expensive to me. And even though Lowrance doesn't really explain how to use the NMEA Input feature in their iFinder documentation, this doesn't change the fact that the feature is included in the product line, available in the user interface, and mentioned in the documentation. So I wouldn't call this feature unsupported -- just poorly documented. (Peter) P.S. This Windows XP command will set COM1 to the parameters expected by NMEA 0183 v2.0: mode com1 baud=4800 parity=n data=8 stop=1 xon=off odsr=off octs=off And this WinXP version of your command will indeed create and upload a bulk test block via GPSBabel with no problems: for /l %i in (1,1,250) do echo 0.%i, 0.%i, %i| gpsbabel -i csv -f - -o nmea -F com1 Thanks for teaching me how to fish...

OK, I tried setting a 100 ms line delay in HyperTerminal and then uploading my 320 sentence test block (with duplicate waypoint names, some > 20 chars). At first this didn't seem to solve the problem, as the upload was still incomplete. Then I enabled command echo in the HT console (in File > Properties > Settings > ASCII Setup > Echo typed characters locally) and noticed that it was (naturally) taking a lot longer to finish the upload, and I apparently hadn't waited long enough. After giving it a second (longer) try I found that the 100 ms delay did indeed seem to solve the problem. But then I noticed that the commands were all being echoed on the first line of the console. Doh! HyperTerminal was not sending the <CR><LF> at the end of each sentence as required by the protocol. When I copied my test block from Notepad and pasted it into the HyperTerminal terminal window, HT was sending the line endings as simple carriage returns. After changing HyperTerminal's default behavior to send the correct line endings (in File > Properties > Settings > ASCII Setup > Send line ends with line feeds), and resetting the line delay to the default 0 milliseconds, I had no problem uploading my ugly test block. [Edited to correct my description of HyperTerminal's default behavior with regards to handling line endings. And HT's label for the option to fix this, "Send line ends with line feeds", is misleading: enabling the option actually forces HT to send a line feed with each line ending (not the other way around)]. So, once again, I don't think the iFinder NMEA input needs a line delay; but other GPS models may require it, and it still might be a worthwhile option to incorporate into GPSBabel. Thanks for your time... (I think I've finally got this out of my system and can go to sleep now. Hopefully when I awake someone will have figured out how to upload routes via RTE...)

Just had a look at the GPS Utility program recommended earlier in this post by daytrek. The Help file for the program includes these entries applicable to the NMEA Send options: "time interval between NMEA sentences (default is 100 milliseconds)" "The Time value is the minimum time at which NMEA sentences are transmitted. Some GPS receivers cannot accept sentences at a fast rate. The default is 100mSecs - this is the time interval between each sentence. Note: Raytheon users should set this value to at least 300mSecs." So there may be something to this line delay issue after all... Good night!

OK, your test block with unique waypoint names uploaded "almost" perfectly via HyperTerminal using the default 0 ms delay. The only missing entry was the first one named "0" (zero). I tried uploading just that first sentence by itself and the result is the same. I'm guessing that the NMEA input interprets zero as an empty string and as a result refuses to save the waypoint. I can enter a waypoint name of "0" (zero) manually, so this appears to be just a bug with the NMEA input. I'm not sure why my cobbled test blocks wouldn't work correctly, but these blocks did have duplicate waypoint names and some longer than 20 characters... At this point I'm back to my original belief that there's no need for line delay - provided you don't have duplicate waypoint names (which probably aren't allowed by most mapping software anyway), and you don't have names that exceed the 20 character limit of the user interface. I may try to experiment with handshake looping on the DB-9 connector later when I get some time. I need to get some sleep now...

I was/am using Windows XP, and I haven't yet installed or fiddled with GPSBabel, so thanks for the test block. I just made up a larger block of test sentences by taking the 32 sentences that I collected from this post and copying them 20 times into a Notepad document. This created a 640 sentence block of repeating waypoint names with a total byte count of < 32 KB. My objective was to see if I could jam up the Go2 input buffer using the default 0 ms delay in HyperTerminal. After uploading this block via HyperTerminal I tried to open My Waypoints and the Go2 just froze up. I couldn't even power off the unit. I had to remove the batteries for a few minutes and reinstall them to restart the unit. I then tried to open up My Waypoints again and it stalled a bit but soon displayed a list of repeated waypoint names. Nearly every waypoint name in the test block had ~16 (not 20) repeated entries in the list, and at least one name in the block didn't show up at all. I tried another test block created with only a 10x copy of the 32 sentence block, for 320 total sentences with a total byte count of < 16 KB. Strangely enough, this upload fared much worse than the larger test, with most waypoint names only being repeated a few times each (if at all). So at this point it seems that there really is an issue with the Go2 COM port and HyperTerminal's default 0 ms delay. Unfortunately the behavior is inconsistent, and any missing waypoints may go unnoticed by someone who is not aware of this problem. Perhaps implementing handshake looping on the DB-9 connector might resolve the problem? As a side note: The Go2 allows duplicate waypoint names to be entered manually, and these tests proved that duplicate names can also be uploaded via the COM port. This means that there is no way to overwrite current waypoint entries via the COM port (unless perhaps the maximum waypoint limit is reached). I'm going to give your test block a spin now...

My sample upload for the character set test: $GPWPL,4147.078,N,11201.768,W,ßÄÖÜ*4B used a simple copy and paste of the "ßÄÖÜ" string from Eliveras' post. So I don't know the actual encoding for the characters. But I'll bet you know more about this than I do.

Eliveras' posts didn't clearly state whether he had tweaked the default HyperTerm settings to match the protocol/iFinder defaults. I would expect that HT's default hardware handshaking would not play well with the lack of actual hardware support for this. I'm guessing that was the real problem in his case. But my test with the default 0 ms delay used an admittedly small block of 32 sentences. If you can send me a larger block to test with (use the forum e-mail system) I'd be happy to do so (I don't have any software to quickly generate checksums en masse).

Eliveras stated earlier in this post : robertlipe replied: From the iFINDER Go Advanced Users Guide: My Go2 has the default English language selected. The user interface allows me to input the following characters manually for both waypoint and route names: ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 !#&*()-/'., However, the sentence: $GPWPL,4147.078,N,11201.768,W,ßÄÖÜ*4B uploaded via HyperTerminal produced a waypoint with the name "ßÄÖÜ" in My Waypoints. So it appears that character set limitations are only in the manual input interface, based on the language selected. This is just too cool!!!

My own testing of my iFinder Go2 shows that it supports a maximum of 20 characters for both waypoint and route names, when waypoints are entered manually via the user interface. However, this sentence (provided by robertlipe earlier in this post): $GPWPL,5011.888,N,00828.246,E,xxxxxxxxxxxxxxxxxxxx22*44 uploaded via HyperTerminal "as is" into my Go2. In other words, I now have a waypoint with the 22 character name "xxxxxxxxxxxxxxxxxxxx22" in My Waypoints. So the Go2 user interface does not fully exploit the capabilities of the unit. Hmm...