when will garmin express mac be able to sync GPS EPO.bin file on fenix 2 ?

Express for Mac version 3.1.3.0 was just released to fix this issue. Please update your Express client and let us know if the ephemeris data (EPO.bin) still doesn't get updated. Thanks again to the users we contacted to collect data on this issue.

Sam

It works! However, the "Device Found" dialog box doesn't show anything when the OS X language is set to Dutch (it flashes briefly just as if the interface elements are hidden behind another rectangular, grey element). When set to English everything is all right.

Yes, it works for me, too. Thanks!

JAVAWA,

I was able to duplicate that issue when my Mac was set to Dutch, so I went ahead and sent this issue up to the engineers. Thanks for letting us know.

Sam

No, it didn't shrink. The EPO.BIN supplied by the iOS Connect App was 4000+ bytes. The EPO.BIN supplied by the curl is 64000+ bytes. I have no idea why they're so dissimilar. It's possible I didn't wait around long enough for the Bluetooth connection to transfer the file, I suppose. Anyway, at the moment I have the EPO.BIN from curl, piped through a little perl script I threw together to cut out the 3 byte segments, installed on my watch. That seems to work on my Fenix so far; today I turned on the GPS several times and satellite acquisition was much faster than normal. I don't know how long it takes for the information in EPO.BIN to become stale, though.

The reason I looked into it in the first place was that the unmodified EPO.BIN from the curl just wasn't working on my Fenix 1. I also noticed the same initial 3 byte difference from the EPO.DAT (and I assume the subsequent 3 byte differences as well) you can download from mediatek itself. But the file from mediatek is even larger, ~ 275 kbytes. I haven't tried to find any documentation on the structure of the EPO file yet to see how it's laid out or why the differences between the three.

I found some more information, including another topic on this forum: https://forums.garmin.com/showthread.php?69652-GPS-Chipset-and-EPO-files
Every block of 2304 bytes is good for 6 hours of satellite data, so the EPO.BIN downloaded with curl is good for 28 blocks / 4 = 7 days (BTW, I created a simple online tool to download the file and to remove the 3 byte headers: http://www.javawa.nl/epo_en.html )
Via the url http://wm.sim.com/MTK30.EPO you can download a file with 120 blocks (good for 30 days); this file is exactly 2304 * 120 bytes long, so no need to strip anything. It does work on my fenix, but I'll have to wait 7 days to see whether the fenix can handle EPO.BIN files larger than the ones from the Garmin server (actually 6 days; looking at the data it seems that the file is one day old)

An update: no, the large file doesn't work anymore after 7 days, so it seems the fenix can only use 7 days worth of satellite data...

Great you found out what was the problem with my curl approach. I updated www.kluenter.de accordingly and wrote a little ruby-hack to drop the 3 bytes. Javawa: could you share your script that does the same? I am shure its better than mine and I would love to use it.

My PHP script does the same as yours; only difference is that it caches the result for 6 hours (just in the case that my web service would get a huge number of users; doesn't seem the case though ;) ) I think your script is better suited for a command line solution.
I have a suggestion though to improve your script a little bit: instead of using a "for" loop for 28 times you could change it to a "while" loop until the end of the data; the length of the file could change in the future.

For what it's worth, here's the perl script I was using:

$buf = "";
read(STDIN,$buf,3);
$buf = "";
while(read(STDIN,$buf,2304)){
print $buf;
$buf = "";
read(STDIN,$buf,3);
$buf = "";
}
print $buf;

Could probably be a little shorter with a "do while{}". Also, I should really check to see if the number of bytes read is correct, and do something sane otherwise.