Eggfinder / Open Log problems..

[Tim51]

Hi All
Some time ago I added an Open Log board to my Eggfinder Tx which I fly in the NC of my 4”. Whilst the EF Tx continues to work fine, no .txt files appear on the uSD card after flights, so I’ve been unable to create .nmea files for plotting on Google Earth etc. To be double sure, I've checked over the soldering and reflowed the joints on the Open Log , and the blue LED on the OpenLog board blinks as it did before when the TX is transmitting data (three rapid blinks, short pause, repeat). However, when I open the uSD card after a flight it still does not show either a .config.txt file nor a lognnnnn.txt - when I insert the card into an adapter and open it on my laptop, it opens as a blank field showing no file at all (I've tried this with a range of new uSD cards to ensure it wasn't just a faulty one) but in all cases no file is created. I reached out to Cris Erving who suggested I try using Notepad to create the config file 9600,26,3,0,0,0,0 to the uSD card. I did this, but unfortunately the problem persists - when I take the tracker for a walk it doesn’t record anything. Again, the EF Tx itself was working fine. Has anyone any thoughts on what might be the problem here? Any thoughts / prognoses / suggestions welcome. Thanks!

 

[cerving]

Try this... tack a wire to the TX0 and -/GND pad on the OpenLog module, and connect it to an Eggtimer data cable so that the black wire is on "-" and the white wire is on TX0. Fire up Putty or a similar terminal program on your PC at 9600/8/n/1, and power up the TX. You should see data streaming across your screen. If you do NOT, then there is a bad connection somewhere on the OpenLog adapter board. If you DO get data, but it's not recording, then you probably have a bad OpenLog module.

 

[Tim51]

Try this... tack a wire to the TX0 and -/GND pad on the OpenLog module, and connect it to an Eggtimer data cable so that the black wire is on "-" and the white wire is on TX0. Fire up Putty or a similar terminal program on your PC at 9600/8/n/1, and power up the TX. You should see data streaming across your screen. If you do NOT, then there is a bad connection somewhere on the OpenLog adapter board. If you DO get data, but it's not recording, then you probably have a bad OpenLog module.

Thanks Cris I'll try that.

 

[heada]

What size uSD card and how is it formatted? (FAT, exFAT, FAT32) I know that some devices have size limits and format issues. If the test Cris suggested shows data but it still isn't recording, it could be that the module simply can't write to the card. If possible, find a uSD that is less than 2GB and format it as FAT and try that.

 

[Tim51]

What size uSD card and how is it formatted? (FAT, exFAT, FAT32) I know that some devices have size limits and format issues. If the test Cris suggested shows data but it still isn't recording, it could be that the module simply can't write to the card. If possible, find a uSD that is less than 2GB and format it as FAT and try that.

Thanks very much for the input. I hadn't realised card size is/could be an issue. I've been using a 64 GB SanDisk ...too big perhaps?
In terms of format - I'm not au fait with the different types you mention. I simply took it out the pack and secured it in the open log. ..please advise if I'm missing something!

 

[heada]

A quick look at amazon.co.uk shows you can get a 2gb uSD card for between 4 and 10 pounds. Crazy since a 16gb goes for about the same cost.

For formatting, you can insert it into any computer that has a uSD slot or use a uSD to SD adapter and insert into a SD slot. Once inserted, it looks like a normal removable drive and you can reformat it. FAT is the most forgiving but has size limitations but 2gb is within that limit.

Since its recording text data, you could store days and days of data on a 2gb card so no need for a large one. I use a 512mb card from a 10 year old camera.

 

[Tim51]

A quick look at amazon.co.uk shows you can get a 2gb uSD card for between 4 and 10 pounds. Crazy since a 16gb goes for about the same cost.

For formatting, you can insert it into any computer that has a uSD slot or use a uSD to SD adapter and insert into a SD slot. Once inserted, it looks like a normal removable drive and you can reformat it. FAT is the most forgiving but has size limitations but 2gb is within that limit.

Since its recording text data, you could store days and days of data on a 2gb card so no need for a large one. I use a 512mb card from a 10 year old camera.

Again, thanks very much I shall look into that.

 

[cerving]

I use 8 GB cards, they work fine.

 

[heada]

I use 8 GB cards, they work fine.

Do you know how they're formatted? I don't remember if basic FAT works at 8gb or if you have to go to FAT32.

 

[Donnie]

Sounds like the issue may be that the OP isn't formatting the card at all before installing on the open log?

 

[Tim51]

Sounds like the issue may be that the OP isn't formatting the card at all before installing on the open log?

That's correct. I didn't realise it was necessary. What format would you recommend?

 

[Donnie]

That's correct. I didn't realise it was necessary. What format would you recommend?

Full disclosure, I've never used an Open Log, lol... however, when reading this thread last night I googled it and came up with this information from sparkfun: https://learn.sparkfun.com/tutorial...85.1877064299.1559831702-975723592.1551799628

It discusses SD card capacities, as well as the need to format... as to how, it's likely just as simple as plugging it into your PC (through a card slot and/or USB adapter). It'll probably either format it automatically or ask you if you want to format it.

Not saying this is the issue, but it'd be pretty quick to try it out...

Thanks!

 

[heada]

uSD cards come pre-formatted. Most of the newer/larger ones are formatted as exFAT so that all the space on the card is available. Due to filesystem limitations, FAT and FAT32 are only valid up to 32GB (FAT is really only valid up to 4GB but you can use large block sizes to get up to 32GB). A 64GB uSD card would be formatted as exFAT which supports up to 2TB (2048GB) If the OpenLog doesn't support the exFAT filesystem (I don't know if it does) then you have a few options.
1) use a 32GB or smaller uSD card formatted as FAT/FAT32
2) destroy and recreate the partition table on the 64GB card such that you have a 32GB partition formatted as FAT/FAT32 and 32GB of unusable space. You could create a second partition for that unusable space but I don't know how OpenLog would react to a card with multiple partitions since it would appear as 2 different drives.

I would try to find a smaller uSD card, 8GB and 16GB are readily available and dirt cheap.

 

[Tim51]

uSD cards come pre-formatted. Most of the newer/larger ones are formatted as exFAT so that all the space on the card is available. Due to filesystem limitations, FAT and FAT32 are only valid up to 32GB (FAT is really only valid up to 4GB but you can use large block sizes to get up to 32GB). A 64GB uSD card would be formatted as exFAT which supports up to 2TB (2048GB) If the OpenLog doesn't support the exFAT filesystem (I don't know if it does) then you have a few options.
1) use a 32GB or smaller uSD card formatted as FAT/FAT32
2) destroy and recreate the partition table on the 64GB card such that you have a 32GB partition formatted as FAT/FAT32 and 32GB of unusable space. You could create a second partition for that unusable space but I don't know how OpenLog would react to a card with multiple partitions since it would appear as 2 different drives.

I would try to find a smaller uSD card, 8GB and 16GB are readily available and dirt cheap.

Thanks for explaining. I've ordered a 2GB and an 8GB from Mr Bezos's online emporium. I haven't had time yet to run through the test Cris described above but will also do that.

 

[heada]

Thanks for explaining. I've ordered a 2GB and an 8GB from Mr Bezos's online emporium. I haven't had time yet to run through the test Cris described above but will also do that.

I would do the test first because if that isn't working then it wont matter what storage device you use.

 

[heada]

Reading the link from a few posts above, OpenLog only supports FAT/FAT32 filesystems on cards up to 32GB. Your 64GB card is 99% probability formatted as exFAT and thus would never work. Swapping out for the 2GB or 8GB would probably work with no other changes needed.

2GB card storging 16 NMEA 0183 GPS sentences per second (128bits/second) can record non-stop for 194 days. You would probably run out of battery before you ran out of storage capacity.

 

[Tim51]

Reading the link from a few posts above, OpenLog only supports FAT/FAT32 filesystems on cards up to 32GB. Your 64GB card is 99% probability formatted as exFAT and thus would never work. Swapping out for the 2GB or 8GB would probably work with no other changes needed.

Thanks for following up on that - much appreciated. In the meantime I'd looked up some 'how to format' guides online and noticed the point about exFAT for larger cards also. As you say, thinking about it now it makes sense to try out the simplest check first - Occam's Razor and all that.. so I'll wait for the 2GB card to arrive tomorrow or Saturday. If it's no go then I'll run through Cris's test, but I'll need to familiarise myself with Putty etc first. Software and firmware are not my area.

2GB card storging 16 NMEA 0183 GPS sentences per second (128bits/second) can record non-stop for 194 days. You would probably run out of battery before you ran out of storage capacity.

Again, thanks for the info and reassurance - really helpful. I'll post results.

 

[Worsaer]

Full disclosure, I've never used an Open Log, lol... however, when reading this thread last night I googled it and came up with this information from sparkfun: https://learn.sparkfun.com/tutorial...85.1877064299.1559831702-975723592.1551799628

It discusses SD card capacities, as well as the need to format... as to how, it's likely just as simple as plugging it into your PC (through a card slot and/or USB adapter). It'll probably either format it automatically or ask you if you want to format it.

Not saying this is the issue, but it'd be pretty quick to try it out...

Thanks!

Sorry I didn't see this thread sooner. As pointed out, the tutorial on Sparkfun does indeed have your most likely answer:

"All data logged by the OpenLog is stored on the microSD card. The OpenLog works with microSD cards that involve the following features:
>64MB to 32GB
>FAT16 or FAT32"

If it continues to give you problems, let me know.

 

[Tim51]

Sorry I didn't see this thread sooner. As pointed out, the tutorial on Sparkfun does indeed have your most likely answer:

"All data logged by the OpenLog is stored on the microSD card. The OpenLog works with microSD cards that involve the following features:
>64MB to 32GB
>FAT16 or FAT32"

If it continues to give you problems, let me know.

Thanks for posting - I hadn't seen the Sparkfun tutorial. Will update this thread when I get the chance.

 

[Tim51]

Hello again.. well, finally got round to testing the 8GB uSD card (fresh from the packaging and un-reformatted) by taking the EF tracker for a 20minute walk around the neighbourhood. As before all LEDs were flashing normally. Two relatively small .txt files appeared, which I then renamed as .nmea files, saved to my desktop and attempted to open in Google Earth:
However the next prompt has me puzzled as to how to proceed -


The following page is a cul de sac in that it has options for '<Back' and 'Cancel'. Any ideas on what am I doing wrong here gratefully received!
Thanks

 

[heada]

Can you open the text file in a text application (notepad, etc) and copy the first few lines and show us? That'll give us the format it recorded in. Most are comma delimited meaning a comma separates each field in the line. Others are tab delimited and some are just a fixed length.

 

[Tim51]

Can you open the text file in a text application (notepad, etc) and copy the first few lines and show us? That'll give us the format it recorded in. Most are comma delimited meaning a comma separates each field in the line. Others are tab delimited and some are just a fixed length.

Sure - it looks like this:

$PSRF150,1*3E
$GPGGA,,,,,,0,00,,,M,0.0,M,,0000*48
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPRMC,,V,,,,,,,,,,N*53

 

[heada]

So your data is standard comma delimited. Here is an example with explanation of each field.

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *

Further down in your text file, do you have full nmea sentences that match the example?

 

[Worsaer]

So, your hardware is indeed working correctly.

Here are some tips I've used in the past to create a 3D flight profile in Google Earth:

1. Rename your text file to a .NMEA extension. For example, LOG00042.txt -> LOG00042.nmea
2. In Google Earth, select File -> Import [filename]
3. When the popup box displays, be sure to uncheck 'Adjust altitudes to ground height'. This is the key to showing a flight profile instead of a ground profile.

 

[Tim51]

So your data is standard comma delimited. Here is an example with explanation of each field.

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *

Further down in your text file, do you have full nmea sentences that match the example?

Thanks - yes, further down there is (for example) this:

$GPGSV,3,1,12,01,00,000,28,11,00,000,29,14,66,062,34,18,62,206,36*72
$GPGSV,3,2,12,22,00,000,23,31,00,000,37,32,00,000,35,16,64,129,*74
$GPGSV,3,3,12,29,59,275,,24,59,076,,27,41,244,,09,38,229,*7F
$GPRMC,185726.595,V,,,,,,,160619,,,N*42
$GPGGA,185727.597,5131.0626,N,00002.1126,W,1,04,5.9,46.4,M,47.0,M,,0000*74
$GPGSA,A,3,14,18,11,31,,,,,,,,,7.9,5.9,5.2*39
$GPRMC,185727.597,A,5131.0626,N,00002.1126,W,0.41,243.65,160619,,,A*71
$GPGGA,185728.597,5131.0626,N,00002.1125,W,1,04,5.9,46.5,M,47.0,M,,0000*79
$GPGSA,A,3,11,18,14,31,,,,,,,,,7.9,5.9,5.2*39
$GPRMC,185728.597,A,5131.0626,N,00002.1125,W,0.81,243.65,160619,,,A*71
$GPGGA,185729.597,5131.0626,N,00002.1127,W,1,04,5.9,46.4,M,47.0,M,,0000*7B
$GPGSA,A,3,11,18,14,31,,,,,,,,,7.9,5.9,5.2*39

 

[Tim51]

So, your hardware is indeed working correctly.

Here are some tips I've used in the past to create a 3D flight profile in Google Earth:

1. Rename your text file to a .NMEA extension. For example, LOG00042.txt -> LOG00042.nmea
2. In Google Earth, select File -> Import [filename]
3. When the popup box displays, be sure to uncheck 'Adjust altitudes to ground height'. This is the key to showing a flight profile instead of a ground profile.

Thanks. I had renamed the files to .nmea, but when I select File > Import [fle name] the pop up I get does not give me the option to uncheck ground height, but rather this:


..then this (when I click 'Next'):



not sure how to proceed!

 

[heada]

Can you post your 2 files, the LOG files that end in .txt and .nmea? That will allow us to open it and walk through the same process. I see valid position sentences, the ones that start with $GPGGA

 

[Tim51]

Can you post your 2 files, the LOG files that end in .txt and .nmea? That will allow us to open it and walk through the same process. I see valid position sentences, the ones that start with $GPGGA

PM sent

 

[Worsaer]

So, here are the steps...

1. Rename the log file. For example, if it's LOG00010.TXT, rename it as LOG00010.nmea It's really important that the extension ends in .nmea - Sometimes Windows hides the file extension, and you may not know the .TXT extension is there.
2. In Google Earth, select File -> Open (not Import), and select file type GPS. Select your log file ending in .nmea
3. Be sure to unselect the box, "Adjust altitude to ground height' if you want to see the 3D flight profile.

 

[Tim51]

So, here are the steps...

1. Rename the log file. For example, if it's LOG00010.TXT, rename it as LOG00010.nmea It's really important that the extension ends in .nmea - Sometimes Windows hides the file extension, and you may not know the .TXT extension is there.
2. In Google Earth, select File -> Open (not Import), and select file type GPS. Select your log file ending in .nmea
3. Be sure to unselect the box, "Adjust altitude to ground height' if you want to see the 3D flight profile.

Thanks. I'm unclear how to 'select file type' when opening the file in Google Earth. Where do I find that option? I'm using Mac High Sierra, btw.