Field Notes won't upload

[Frank Drebbin]

I have a Colorado 400t and until recently I was able to upload Field Notes from the unit to the GC site and then post finds etc. I load caches onto the Colorado via a PQ using EasyGPS.

 

Now when I do the upload to Field Notes, nothing uploads. The Geocache-visits file is on the unit and the individual cache finds/dnfs are also on the unit.

 

If I load caches individually from GC.com those caches will work with the Field Notes function.

 

Any ideas as to what's happening or how to fix this?

 

Thanks

[+Unobtainium]

There are a couple of things that spring to mind.

 

1) I seem to remember somwone saying that certain characters in the logs will screw up the upload. I think it may have been quote marks, but I may be wrong.

 

2) The file may have become corrupt.

 

Can you open the file in notepad? If so are your latest logs there? Did you use a special character in the first one that didn't work?

 

You can try deleting the file from your GPS and trying to log again.

[wwjd7]

Make sure your comment is wrapped with an opening and closing quote. I’ve inadvertently removed a closing quote while editing my field notes on my computer then get an error uploading it. Restored the closing quote and all was well again.

[+UPSgirl]

I have an issue similar to Drebbin's: Until recently, I have been able to consistently upload field notes from my BB (after exporting from cachesense -- which I have been using for about three years). Now, I consistently cannot upload my field notes, at all, from any source. I've tried copying the file to my computer from the BB, with no better luck. Of the 51 logs/field notes I have from today, 0 upload.

 

Here are examples from today, again this is a .txt file on my hard drive:

 

GCW1XR Land of the Gnomes,2011-05-07T15:17:11Z,Didn't find it,""

GCGP1K Big Green Monster,2011-05-07T14:55:06Z,Found it,"TFTC glad it was the big tube!"

 

Any troubleshooting suggestions? It has been at least a month that this stopped working. I was hoping with the gc.com update, it might have corrected.

[+Chrysalides]

I have an issue similar to Drebbin's: Until recently, I have been able to consistently upload field notes from my BB (after exporting from cachesense -- which I have been using for about three years). Now, I consistently cannot upload my field notes, at all, from any source. I've tried copying the file to my computer from the BB, with no better luck. Of the 51 logs/field notes I have from today, 0 upload.

 

Here are examples from today, again this is a .txt file on my hard drive:

 

GCW1XR Land of the Gnomes,2011-05-07T15:17:11Z,Didn't find it,""

GCGP1K Big Green Monster,2011-05-07T14:55:06Z,Found it,"TFTC glad it was the big tube!"

 

Any troubleshooting suggestions? It has been at least a month that this stopped working. I was hoping with the gc.com update, it might have corrected.

Mine don't contain the cache name in the first column, only the GC code.

 

Try editing it to this:

 

GCW1XR,2011-05-07T15:17:11Z,Didn't find it,""

GCGP1K,2011-05-07T14:55:06Z,Found it,"TFTC glad it was the big tube!"

 

I saved those 2 lines into a text file and it uploaded as field notes fine. Now you need to figure out how to change your export so that the GC code field doesn't contain the cache name. I don't use a Blackberry so I can't help there, sorry.

Edited May 8, 2011 by Chrysalides

[+Red90]

The first field MUST be ONLY the GC code. If it is anything else, the notes will not upload.

 

Check your field note file. If it not in that form, the software you are using to put the caches on the GPS is not doing it correctly.

[+UPSgirl]

Hi Chrysalides and Red90:

 

THANK YOU, that worked! Interesting as this was the format which Cache Sense has always used. Perhaps it changed with one of their software updates. I did check their forums first, and found nothing specific to this topic. I will send them a message about the issue.

 

Sincerely, UPSgirl

Edited May 8, 2011 by UPSgirl

[+ecanderson]

There are a couple of things that spring to mind.

 

1) I seem to remember somwone saying that certain characters in the logs will screw up the upload. I think it may have been quote marks, but I may be wrong.

No, you are correct. Any extra " marks in the field notes will foul up the parsing. I tend to add some pretty detailed descriptions of caches to my notes (e.g., 4x6x2 LNL = 4" x 6" x 2" Lock-n-Lock) and discovered quickly that " marks are a train wreck!

 

Another thing - and I noted someone else talked about editing their file using a standard text editor ... the formatting of the geocache_visits.txt file is very peculiar. EVERY character is followed by a 00h. A single 0Dh 0Ah pair must terminate each line. I tried to edit one of these files only to find that my editor was adding a double line termination (0Dh 0Ah 0Dh 0Ah) and those notes refused to upload as well. Further, even the line terminators are followed by 00h, so it's really 0Dh 00h 0Ah 00h. I assume that this is leaving space down the road for unicode, and that the Garmin is plugging in only the LSB of what may eventually become two byte pairs.

[+Chrysalides]

Another thing - and I noted someone else talked about editing their file using a standard text editor ... the formatting of the geocache_visits.txt file is very peculiar. EVERY character is followed by a 00h. A single 0Dh 0Ah pair must terminate each line. I tried to edit one of these files only to find that my editor was adding a double line termination (0Dh 0Ah 0Dh 0Ah) and those notes refused to upload as well. Further, even the line terminators are followed by 00h, so it's really 0Dh 00h 0Ah 00h. I assume that this is leaving space down the road for unicode, and that the Garmin is plugging in only the LSB of what may eventually become two byte pairs.

Once upon a time, Groundspeak was rejecting field notes that are not in UCS-2 format (the double byte that you mentioned). However, that changed at least 6 months ago. Give it a try - create a field notes file from scratch in your text editor, and upload it. That's what I did last night.

 

The extra CR/LF issue is also fixed. Not sure when this happened, but I just uploaded a file with extra CR/LF at the end. I also tried empty lines in the middle, it ignored them just fine, accepting the valid lines.

 

Finally I tested Unix style line feeds, and that failed. Not surprising, since Groundspeak runs Windows Server I believe.

 

Groundspeak has made field notes much more robust and fixed numerous date / time issues in the last few months. My thanks to the lackeys / programmers / hamsters who did this. I promised them donuts once for fixing the date issue, I still need to deliver on my promise

[+ecanderson]

Once upon a time, Groundspeak was rejecting field notes that are not in UCS-2 format (the double byte that you mentioned). However, that changed at least 6 months ago. Give it a try - create a field notes file from scratch in your text editor, and upload it. That's what I did last night.

 

The extra CR/LF issue is also fixed. Not sure when this happened, but I just uploaded a file with extra CR/LF at the end. I also tried empty lines in the middle, it ignored them just fine, accepting the valid lines.

 

Finally I tested Unix style line feeds, and that failed. Not surprising, since Groundspeak runs Windows Server I believe.

 

Groundspeak has made field notes much more robust and fixed numerous date / time issues in the last few months. My thanks to the lackeys / programmers / hamsters who did this. I promised them donuts once for fixing the date issue, I still need to deliver on my promise

Edits to files such that there's a mix of two byte data and 1 byte data is likely to cause the file to be unable to upload. Creating a fresh file from scratch with a text editor is OK as no 00h characters will be added. Trying to edit an existing Garmin file can be problematic. I use CodeWright for such edits just to be certain I've made no mistakes.

 

I just had the double CR/LF pair bomb on me last week (tweaked an entry with WordPad and forgot about that problem), so if they've 'fixed' it, it's news to me - although it could have been related to a missing 00h between them as well. Haven't tried the 0Dh only to see what happens, but I'm prepared to take your word for that one. No surprise, as you say.

[+Chrysalides]

Edits to files such that there's a mix of two byte data and 1 byte data is likely to cause the file to be unable to upload.

That would mess pretty much anything up, unless it is in UTF-8. I don't think any "sane" text editor would save ASCII in a mixture of 1 and 2 bytes per character (and not in UTF-8). For UCS-2, there is a special 2 byte header in the beginning of the text file denoting that, and also whether it is big or little Endian.

 

Not sure if UTF-8 is supported by Groundspeak, but ASCII in UTF-8 only takes 1 byte anyway.

[+ecanderson]

That would mess pretty much anything up, unless it is in UTF-8. I don't think any "sane" text editor would save ASCII in a mixture of 1 and 2 bytes per character (and not in UTF-8). For UCS-2, there is a special 2 byte header in the beginning of the text file denoting that, and also whether it is big or little Endian.

Which is why the geocache_visits.txt file can't be considered UCS-2. It has none of those header features. And 'sane' text editors (vs. perhaps some word processors) don't recognize the 'alternate 00h' for every character as an attempt at unicode, either, and will simply work in single byte mode, causing a mix of situations where characters are followed by a 00h byte and sometimes not. Makes quite a mess. What's even more peculiar is the variety of ways in which a typical editor will even attempt to display 00h chars.

 

Try a text edit of any file where every character (including each 0Dh and 0Ah) is followed by a 00h. Off the top of my head, I don't think I have even one that will continue to honor the alternating 00h requirement.

[+Chrysalides]

Try a text edit of any file where every character (including each 0Dh and 0Ah) is followed by a 00h. Off the top of my head, I don't think I have even one that will continue to honor the alternating 00h requirement.

I don't know why Garmin does it in that way. But opening that file in Windows notepad (XP and later) and Notepad++ works, and when you save the file, Notepad will automatically add the required header, and notepad++ will preserve the same double byte mode.

 

I'm sure there are editors that will royally mess this one up. Let's just give a list of editors that work well with field notes files. Notepad and Notepad++ does. Windows Wordpad (write.exe) appears to choke on it.