Jump to content

Sending log to Geocaching.com (Garmin Oregon 750)


Raiden38

Recommended Posts

Hi. So I have a Garmin Oregon 750 and I found two ways of sending my logs to the Geocaching Website:

 

1) Enable Auto-Upload: The issue is that it will send a "Found using Garmin..." log so once I get home, I need to go back to all caches and edit all my logs

 

2) Disable Auto-Upload: The logs will be saved in a .TXT file so when I get home, I need to connect my Garmin to a computer, go into Drafts, Import the Drafts, delete the file.

 

Since the 750 is a connected GPS, wouldn't be a way to perhaps Auto-Upload as a Draft (so I can see my draft and then edit and publish) or synchronise directly to the website when I get home and connect to the wifi (without having to physically connect my gps to my laptop? There must be an easier way? 

 

Thanks!

Link to comment

I guess no one finds your option #2 onerous enough to warrant a wireless transfer of draft files.  Also, there are quite a large number of users who never delete the geocache_visits.txt file for whatever reason - including not being aware of it, so the amount being sent each time would grow larger and larger and ...

 

There's also an option when uploading drafts when connected to avoid any accidental duplication of older logs by restricting by oldest log date to be accepted as part of the draft file.  That can be helpful in catching any glitches that could cause a huge online draft file of duplicates.  Almost always, the default date supplied on the gc.com site is the right one, but the option needs to remain to change that.  Any auto upload of drafts should also include a similar option, but would require the last draft logging date to be supplied from gc.com as it appears on the website, and I'm not sure the API knows how to accomplish that.

 

Link to comment

Hi ecanderson. Thanks for the reply, I totally agree with you. To be honest, I was not aware of the txt file before searching for a fix, and I feed this is a huge pain in the … process! My suggestion would be to be able to continue using auto-upload like I do now, but have an option to send them as a draft, and not as real log. This way, when I get back home, I could go into my drafts, edit them and post them for real.

 

And it's probably not cool for the owner of the cache to receive email saying "Submitted via Garmin Geocaching live" instead of real nice logs with a story!

 

Thanks!

Link to comment

This has been requested of Garmin since the Oregon 7x0 was released. Until such time they implement it (if they do), connecting a USB cable and opening a single html link in your favorite web browser to upload and edit any new geocache logs hardly seems inconvenient or difficult. A few of us like to do it this way via GSAK for in-house record keeping, and do not find it to be much trouble. Actually typing full geocache logs into my GPSr when I find them, at least for me, is off-putting and cumbersome. I usually just type a word or two as needed to remind myself of important details (FTF, FAV, NM, etc.) when I finally type the full log out later on a computer with full size QWERTY keyboard!

Link to comment

Soooo, I'm confused. I have a Oregon700. I have wifi enabled all the time. I find a cache, click found it on the GPS and select edit logs to add my log text. When I walk in my house and turn my GPS on it tells me that xxx logs have been updated, which is always the number of caches I logged on the current trip. I take no actions whatsoever. I usually keep a separate list of the caches I found to spot check and embellish some memorable finds, because of the text limitations in the log field ( it only takes like 40 characters). I never stopped to think that the text was in one file and it was uploading the entire file each time. I had assumed that a separate file was created for each find, and only new logs were uploaded. Should I find and delete text files on the GPSR? I just looked at gpsrchive. It tells me that , y gpsr has 2 text file directories., One in the unit itself, one on the SD card. How do I direct the GPSr to use the SD card?

Edited by ras_oscar
Link to comment

Assuming you meant Oregon 700.... (there is no Montana 700)

 

Where do you see two text file directories? I only see the one on the GPSr, but this has nothing to do with geocache logs. Those are stored in the geocache_visits.txt and geocache_logs.xml files, both located in the Garmin directory on the GPSr itself, never on the microSD card.

 

These are both simple text files, and each log upload when you are in Wi-Fi range only sends the 'new data' since last upload. Your old logs are not sent to GC.com again and again.

 

I do not recommend deleting these text files.

 

If everything is working OK, why are you messing with it?

 

8^)

 

 

Edited by Atlas Cached
Link to comment
On 1/16/2020 at 1:47 PM, Atlas Cached said:

each log upload when you are in Wi-Fi range only sends the 'new data' since last upload

How do you do that??? I used to connect my gps via USB then get the txt file, import it into GC.COM, delete all previous already filles draft and submit new ones…..? Guess I'm not making it correctly!

Link to comment
On ‎1‎/‎25‎/‎2020 at 12:31 PM, Raiden38 said:

How do you do that??? I used to connect my gps via USB then get the txt file, import it into GC.COM, delete all previous already filles draft and submit new ones…..? Guess I'm not making it correctly!

Does your GPS have wifi  and have you eabled it and entered your wifi network password?

Link to comment
On 1/16/2020 at 11:47 AM, Atlas Cached said:

Assuming you meant Oregon 700.... (there is no Montana 700)

 

Where do you see two text file directories? I only see the one on the GPSr, but this has nothing to do with geocache logs. Those are stored in the geocache_visits.txt and geocache_logs.xml files, both located in the Garmin directory on the GPSr itself, never on the microSD card.

 

These are both simple text files, and each log upload when you are in Wi-Fi range only sends the 'new data' since last upload. Your old logs are not sent to GC.com again and again.

 

I do not recommend deleting these text files.

 

If everything is working OK, why are you messing with it?

 

8^)

 

 

Actually, the geocache_visits.txt file is ALMOST a simple text file.  It may appear so in a simple text editor like Notepad and will just have some odd spaces showing in Wordpad, but do NOT try to edit one with a simple text editor unless you're paying VERY close attention to what you're doing.  It's full of embedded zeros (00h) that are probably there in the event that a 16 bit character set is used.  If you drop out even ONE of those zero bytes during an edit (except perhaps the very last one), the one byte offset of the data in the file will bomb it at gc.com when it is uploaded.

 

gc.com has a default threshold date for how new an individual log must be before it's excluded from the larger list that is sent.  That's clearer on the web page method for uploading where the default date appears on that page.

 

Unless logging caches at the old Garmin site (does it still exist?), the geocache_logs.xml file is of no use at all -- except for a few of us using it with GSAK as an option.  It's essentially a duplicate of the geocache_visits.txt data but in .xml format as the Garmin site once required it.  It's a space waster, so apart from possible GSAK use, no reason NOT to delete it.  After a couple of years of active caching, they can grow quite large, especially if field notes are being added for each find.  The only major difference is that times in geocache_visits.txt are in UTC, and those in geocache_logs.xml are in 'local' time.

 

 

 

 

 

 

  • Helpful 1
Link to comment

This discussion appears to be about two distinct topics: uploading drafts via cable connection to a computer, and logs being sent automatically wirelessly as posted logs rather than drafts. The latter is of much more interest and value to me, as I have been connecting my Garmin GPS units to my computer to upload my drafts (previously “field notes”) for years, and am ready for a better way. I would much rather the logs be sent wirelessly automatically as drafts, and not posted as the generic “Submitted via Garmin Geocaching live” post.

 

Until and unless Garmin gives us the option to send our logs as drafts, rather than as posted logs on each geocache page, the value of this feature is essentially zero to geocachers like myself who prefer to type a unique log for each find.

Link to comment

Your intermediate option is to use the GPS to find the geocache, but use your phone to log it either outright or as a draft. Since the Live feature requires you have your cell phone with you, you have it. I'm not sure if this would be equally or more cumbersome than plugging into a computer at the end of the day to upload your field notes. 

Link to comment
56 minutes ago, ras_oscar said:

Update:  had a few issues with the autolog feature and have disabled it. Now when I find a cache I enter a few words on my GPSr that remind me of the experience and download that file when I get bck home to allow me to enter proper logs using GSAK.

 

Exact same process I use. Writing out meaningful logs in the field is time consuming. I just make a note or two on the GPSr to remember important details, then use that for review when I compose my final upload logs at home in GSAK.

Link to comment

> Actually, the geocache_visits.txt file is ALMOST a simple text file.  It may appear so in a simple text editor like Notepad and will just have some odd spaces showing in > Wordpad, but do NOT try to edit one with a simple text editor 

I went back to a conversation with Raine in 2008 when geocache_visits first roamed the earth. It was officially decreed to be UTF-16. (I didn't get a vote. Windows digs UTF-16, but the rest of the computing world  largely considers it a mistake.)

Most of the better text editors (not word processors) allow you to control the character set if they can't automatically detect it. I don't remember if it's big or little endian (and that ambiguity is on of the problems with UTF-16) but it should be pass fail to try either setting. The difference is whether a latin 'A' is encoded as bytes 0x00 0x41 or 0x41 0x00. It looks like Notepad can be set to work with either one: http://www.herongyang.com/Unicode/Notepad-Open-UTF-16BE-Text-File.html

HTH people editing those files directly.

Link to comment

Makes sense.  As noted, figured "...probably there in the event that a 16 bit character set is used."  FWIW, it's little endian (low byte, high byte).

 

The gotcha with simpler editors like Notepad (the 'stock' version) is that if you just open the file, it all looks like straightforward 8 bit plaintext.  You do not see the embedded 00h characters, not even as spaces between the characters, so there's an inclination to go ahead an attempt to edit the file without realizing that it may be becoming mangled. 

 

Wordpad (the 'stock' version) shows spaces between each character since the 00h bytes aren't displayed as anything else.  Editing can be done at that point, but has to be exceptionally carefully to pull out every high order 00h byte (blank space) after every low order byte of character data. 

 

Word displays the square box for each character not known in the current character map, so at least you can see where the 00h characters are more readily than just spaces as is the case with Wordpad, but the opportunity for an error is almost the same.

 

Link to comment

These mostly invisible failures are another reason why the non-Windows world just doesn't do UTF-16. Risking damaging your file on an edit is a most unfortunate side effect. "Breaking" the file on a benign change is just defective in design. Lots of UNIX-y tools flip out if you treat UTF-16 files as UTF-8 or ASCII because they often "look" mostly right.

Also, TBC, I wasn't disagreeing with you. I was underscoring your assumption, offering up the comments of one of the original designers of that, and confirming your guess was right. For our readers: geocache_visits.txt files are encoded in UTF-16-LE (without BOM).

Thanx for helping to clarify this messy topic.

Link to comment

No, I understood we were in agreement, just providing some additional clarification/warning to others about the dangers of edits.  Thanks for fighting the original good fight ... even if you lost.  The problem was compounded by the error of assuming that no one would attempt to manually edit one of these files. 

 

  • Helpful 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...