I think a fair bit of Garmin Express for Mac users will appreciate that Garmin clarifies if the Mac version is supposed to be able to "sync" pre-cached satellite data to Fenix/Fenix 2
As I understand it's a feature that the Mac version of Express is supposed to support, however it doesn't work because of a bug or something. They are aware of the problem; I guess it will be solved soon.
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.
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.
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)
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.
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.
