New SFE Lassen iQ Fat 16 Datalogger doesn't work correctly:(

GPS/GNSS Development Boards
1

Hi there:

I was excited to receive today the new SFE Lassen iQ Fat 16 Datalogger. Sadly, I haven’t had any luck getting it to work correctly. I’m trying to get it to write KML. Yes, I’ve read the data sheet and have changed the mode in GPSCONF.txt from normal to KML (mulitple times). I have reformatted the card to FAT16 (mulitple times). I have waited for up to 30 minutes in various locations to see if it’s simply a problem of the GPS not finding a lock (as the data sheet forewarns). Still no joy. The STAT1 light never comes on. All datafiles are empty.

Normal mode seems slightly more promising, with the STAT0 light flashing about once per second after the unit finds a lock. However, even after taking the unit down the street and around a few blocks, all the data in the text file is the same:

$GPVTG,N*30

$GPGGA,0,00,*66

$GPVTG,N*30

$GPGGA,0,00,*66

$GPVTG,N*30

$GPGGA,0,00,*66

etc. (although sometimes there’s an occaisional extra $ or other special character)

Could it be a defective unit?

Any other advice?

2

Same problem with the gps logger. I changed to KML in the text file and still get the normal format.

Any ideas?

3

At least you get data! When I change to KML, I get nothing. Even in “Normal”, data doesn’t look correct.

Hoping to hear from the SFE team…

4

OK, let’s see if I can clear this up.

Let the device run in normal mode for a while. It will log everything that the Lassen IQ puts out. When the device locks, the LED (STAT1 I think), will actually stay on a little bit longer because it’s logging more characters. See if you can see that (tricky, I know, sorry). If you let it run for an hour, pull the SD out and all you have is a huge file with no coordinates, the Lassen isn’t locking and you need to find a better location. I’m really sorry, but that’s an RF thing and I can’t do a thing about it.

When you’re running in KML mode, the device only logs after a lock has been acquired. So if it hasn’t locked, the file will be empty.

I hope this helps a bit. I’m really happy with the little board and I want you guys to be happy with it, too. I test every one of them before they leave, so I’m hopeful that this gets sorted out.

Pete

5

Pete- Thanks for the tip. I think our issue may not lie in the RF reception.

Tonight, I ran a few tests… here are the results:

GPSCON.TXT set to NORMAL mode… contents of file in uppercase.

#1. Cleared the memory of the device by taking out the on-board battery and AA battery pack. From what I understand, this clears the almanac. I also wiped clean the SD card, except for the GPSCON.TXT file.

#2. Plugged everything back in and left the entire unit on my car dashboard for 45 minutes.

#3. Drove around a bit and successfully logged the coordinates.

At this point, the unit worked without issue in NORMAL mode.

Now for the “other” settings…

GPSCON.TXT set to KML mode… contents of file in uppercase.

#1. Pulled the SD card and edited the GPSCON.TXT file so that the NORMAL text was changed to KML. The text of the document is: MODE = KML

#2. Put the SD card back in the unit, while it was in the same physical location as was tested in NORMAL mode.

#3. Powered the unit up and let it run for 45 minutes. During this test, I noticed that the STAT1 LED continued to blink as it did in NORMAL mode.

#4. Drove around and collected data.

#5. Checked the SD card to find out that the data collected was the same as NORMAL format and not KML.

Conclusion: Even with a modified GPSCON file, the unit will not switch to KML mode. Other than that, my unit works fine.

Pete, can you think of any issues that may prevent the unit from running the conversion code and save the data in KML format?

6

For some reason, it’s not reading the “KML” in the config file. The parser that reads the config file waits for the line feed char (10), then counts backward to find defining letters to determine the mode. So there’s a carriage return after the “KML”. If you’ve inadvertently gotten rid of that, it’ll miss the “KML” and run in normal mode. Or I suppose it’s possible that if you’re editting with something other that notepad it might place a different number of white space chars for the carriage return (I think there are actually two 13’s and a 10), but I don’t think so.

Pete

7

Pete,

My logger device is functioning properly now. Thanks for the tips… Here’s what I did to resolve the issue.

I created two new files in NOTEPAD (for ease of use). They are called GPSCON-KML and GPSCON-Normal. When I want to switch, I simply rename the file to be GPSCON.TXT.

In each file, I verified the existance of a CR after the NORMAL and KML strings.

So, after running in Normal mode successfully, I powered down the unit, changed the file name, and restarted with the KML file. When the device was powered up, it sat for around 10 minutes with none of the lights blinking (this is after the initial 1 second of both lights blinking). Eventually, the STAT0 light started to blink and the logger started logging.

Examination of the SD card verified that the device was saving in KML format.

Yipee!!!

If this solution work for the rest of you, please post a reply indicating so.

Take care

8

Turns out, the data logger doesn’t like downtown SF too much. I thought I had a pretty good site line to the sky, but taking the unit to my home in Berkeley and waiting 15 mins for the initial lock, and I’m in business!

I logged my commute from Berkeley to SF this morning and tweaked it for Google Earth (anywhere I can post the file?). It all looks great until you get to the “urban canyon” area of SF where, it seems, reflections make it look like I went a little crazy bouncing off of buildings before finding my office.

Anyway, I’m up and running! Great unit. Thanks for the pointers, Pete!

Rock on, SFE!!

9

Ah, good. Now that we’re all happy-happy, I wanna tell you guys some stuff.

I’ve found a couple of quirks in the device and I think it’s best that everybody knows about them up-front like. This is stuff that didn’t show during development, and it all seems to do with using really big SD cards.

I’ve noticed that when using a large SD (like the 1GB I’m using now) vs. a small one (like the 256MB I used when testing) a couple of things can happen. First, sometimes the text parser can get confused on power-up and the LED will stay predominantly on and it will log goofy. Sometimes it sorts itself out after a few seconds, sometimes longer. The easy fix is to just hit the reset button. That generally clears it up, but it also leads us to the second thing…

While using the 1GB card, I’ve noticed that sometimes after hitting reset the device will start logging, but when read the SD it says that the file’s corrupt. The data logger didn’t seem to have a problem making the file, why’s this bad? Don’t know at this time. The easy solution is to use a 256MB SD. The larger cards work, but it seems to be “iffy”, although I’ve found that if it starts up without the problem previously mentioned (that’s from power up, not from reset) that it’s generally fine.

OK, now for some good news. We’re going to make the programmer available for $15 so you can load firmware updates. There have been a fair number of good suggestions made so firmware updates are inevitable. BTW, the programmer can also double as a serial port for the logger (should that get incorporated into the firmware). And, of course, all the code is open source.

Pete

10

Yay Pete! Thanks for the openness. I will say, though, I got the same “corrupt” message with the 256MB card. I reformatted it and haven’t seen the problem since.

I’ll start a new topic to keep track of the datalogger improvement requests.