Erronious data with iBlue 747 A+

liquidcool's picture

Hey All,

I recently got an iBLue 747A+

I went for a couple of cycle rides this weekend. One of them was a 34 mile ride with a friend of mine. He used his iphone (Trails app) and I used the 747. The result were very different. The iphone was more accurate especailly with the elevations when uploaded onto Everytrail.

I have set the logging on the device to every 2 seconds. Is there something I can tweak on the BT747 to make it log better and more accurately ?

First impressions of the iBlue are not that good ....

androu's picture

I use both my iPhone and the

I use both my iPhone and the iblue 747 for logging activities and in general find the latter much more precise, especially in terms of elevation (which is dodgy at best with any GPS). 

Logging every 2 seconds should be fine. 

What were the innaccuracies apart from altitude?  Jittering around the path you actually took, or distance miscalculated?

liquidcool's picture

Speed is also inaccurate.

Speed is also inaccurate. jumps around a bit. I find some waypoints are missing also. I don't see any jitter on the path or distance (They both come out exaclty the same).

The iphone's elevations are spot on.

Would setting the update frequency to 5hz make it better ?

androu's picture

That's surprising.  I've

That's surprising.  I've found the iPhone's GPS (using trailguru app) to be very innaccurate with speed, often (I assume) losing signal and jumping to a calculated position and increasing the recorded max speed to something entirely wrong.  To the extent that I now use my iblue 747A+ through RoqyBT connected to my iPhone, cutting the phone's GPS out of the complication.

You might try increasing the fix frequency, or just decreasing the log period to 1s.

My normal settings are:

Fix: 1000ms

Log by: Time 60s, Distance 40m for city walking.  Sometimes, if doing sport i reduce the distance log and add Speed 10, 20 or 30kph depending on what i'm doing

I've never used Everytrail, so perhaps I have the same innaccuracies as you.

liquidcool's picture

I thought it could also be

I thought it could also be everytrail, the way it may interpret the gpx file I upload, but I tried another viewer online that shows me elevation according to the gpx file. It was EXACTLY the same. So definitely not Everytrail.

I set the device last night to 5hz and tried it this morning on my way into work, and it seems to be better. Though I also played around with the NMEA settings. Are there any NMEA settings anyone knows of that can be turned off to save on processing, and others to be turned on for extra data? I have set : GSA, RMC, GGA, GSV (Which is set as default)

liquidcool's picture

Just to add to this thread. I

Just to add to this thread.

I disabled GSV from the NMEA settings and set the device to run at 5hz. It seems to be logging better now.

I have now found a wierd inconsistancy.

Doing a few test runs on my commute. from my house to the office, the both times I have done it, they log pretty much the exact same data (elevation, speed...), BUT from my office back home the elevation is completely different. The elevation is almost 200ft out in some places.

Any ideas on this ?

mdeweerd's picture

I've been on vacation this

I've been on vacation this week, so responding only now.

1) How the iBlue 747 logs height.

The height stored by the iBlue is the difference of the current position to the WGS84 reference ellipsoid.  That difference is not he same as the altitude value that we commonly refer to : the altitude compared to the Mean Sea Level (MSL).


2) Correcting height.

By default corrects the height base on the input log format and the output log format.  This is the 'Automatic' Altitude mode (configureabe in the Output Settings).  For instance, CSV format is supposed to be MSL and the binary format is supposed to be WGS84.  So when converting from binary to CSV, a correction will be applied.

It is possible to change this behaviour and 'Keep the height' value found in the original log format, or to apply the correction whatever the input and output format is.

BT747 also has two height correction models.  One is a model that has a height every 10° and interpollates from these values.  The other is more precise and uses a model that has a value every 1° and interpollates from that.  You can select the precise model in the top menu: Settings/Use precise Geoid.

3) Precision of height.

The measured height is not very precise: the primary purpose of the GPS is to measure lat/lon positions.  To indicate the precision of a measurement, PDOP, VDOP and HDOP values are calculated.  These values indicate precisions: the higher the value, the less precise.  DOP = Dillution of Precision.  V= Vertical, H=Horizontal, P=Positional.   The PDOP gives an idea of the 3D precision of the position, and the VDOP of the vertical position (height).

Even then height can be imprecise and it is not uncommon to find a substantial difference on the same track in one direction when compared to the return path.

4) Influence of WAAS/EGNOS (DGPS)

WAAS/EGNOS information is commonly believed to improve the precision of the measured position.  This information comes from fixed stations of which the position is known.  Because the position is known, the can provide correction information related to the actual GPS information they receive.  Other than the trajectory of the satellites, the signals are influence by the atmosphere and that is measured by these stations.

In my experience, the WAAS/EGNOS information does not really improve the positional information and can actually distort it.  The first effect that can happen is that sometimes you have the information and sometimes you do not have it. Hence, the correction will not be applied all the time and the difference between a position that has no correction and another that has the correction can be in big part due to the correction data itself.  Therefore, I switch it off all the time.

Also, the number of sats you can actually see with your device, not only depends on the reception conditions (weather, bushes, position of the receiver, ...), but also on the time of day (constellation of the active satellites).

5) Differences in models.

Assuming that the WGS84 height is correct, the MSL height (or altitude) heavily depends on the model used.  The WGS84 height is indisputeable: there is only one reference elipsoid, the MSL is not an elipsoid: it is measured data that evolves in time.  I did not find a lot of references to that data - I did not find how it is calculated in the GPS.  So I got some help to pull that data of some NASA site for the precise geoid model.  The less precise model come froms another opensource tool (I'ld need to look at the source code to remember which one) and that tool does not mention where its model comes from. 

So, I know even less where the everytrail information comes from.  If somebody proposes me other MSL data to integrate in BT747, this can be done quite easily.

In the mean time, you can appreciate the difference between the models in a graphic .

I hope that this clarifies things for you. 

First, thanks for an amazing

First, thanks for an amazing program. I-Blue should be sending you a royalty check for making their product so much better!

Sorry to drag up an old thread, but reading the above one might assume that disabling WAAS/EGNOS might improve height accuracy, or at least help avoid drastic shifts between readings so it will at least be uniform in it's inaccuracy. Will disabling WASS/EGNOS have a negative affect on the precision of the other position data? Consistent height would be nice but not at the cost of less accurate trails. 

While I'm at it, another question - in the manual you mentioned the main GPS Fix Types and said there are others but you wouldn't see these under normal circumstances. I got my BT747A+ today and straight out of the box, logged for the first time while walking and riding the train. I saw that while many points were DGPS many were SPS. Any idea why? Is SPS less preferred?

Lastly, if you have a sec, some noob questions about NMEA - Is there a good resource that describes what each of the NMEA output settings are? Also what are the key benefits of maintaining NMEA data. What's a typical use case? 


mdeweerd's picture

Hi if old thread give part of

Hi if old thread give part of the information and new posts are in line with the content, that is perfectly fine for me ;-).

WAAS/EGNOS has the same effect on the other position data (lat/lon).  I think that speed is not impacted, but distance is.

DGPS means that WAAS/EGNOS information was available and used.  SPS is a Standard Position not using such data.  When you disable WAAS/EGNOS, in practice "all" your positions will be SPS (some will be "Estimated" or "No fix").

You can have a look at to know what the sentences mean.

The key benefit is that it is the standard format used by most GPS Devices and also a format known by most programs.  You can expect NMEA readers to be available on the long term while device specific bin file formats will not be and tend to change.  BT747 may not be available 10 years from now and with the change of computer systems, it may be difficult to get the current version running.  So if you want to keep the track information for the long term, save it in NMEA, GPX which is also quite known.  Plain CSV is pretty good too since that can easily be transformed to another format in a tool like Excel (by putting the right formulae of course).

Thanks for the info and link

Thanks for the info and link to NMEA, very helpful. Is there something which covers what the Type 8 - 12 are (maybe not as evidenced by the "?" next to them) and the items starting with M? (MALM, MEPH, MDGP,etc)

I did some searching on EGNOS (I'm in the UK) and found out a couple interesting things, especially about yesterday when I was recording my track. 

Yesterday, March 2nd, EGNOS was finally certified for 'safety-of-life' signal for aviation use. I don't think much of anything has changed because of it, just that it's now certified for use. See:

I also thought I had found that the primary EGNOS satelite had an outtage during my recording yesterday, but I was a month off. It was Feb 2nd, not March. See:

I'm wondering if I can get more consistent DGPS signal if I allow the test server as well. I did see where buildings and hills can interfere easily with EGNOS. I'm planning a trip to the Scottish Highlands, plenty of hills, plus it's well north of the EGNOS satellites which are quite south in their orbit, so may just disable it for that. It's just that the idea of 2m accuracy is a hard thing to resist if achievable with any regularity.

Do you know if there is an app for either windows or preferably my android phone that will show in real time the current values being sent from the BT747A+ like HDOP,PDOP,VDOP, and GPS Fix Type? Or if not, a tool where I could analyze the logs visually after logging by hovering over any specific spot on the track and see the quality data for it in a pop up?

Would like to understand as I'm walking around what the detailed quality of signal is in various situations.

Last question (sorry!), I've been reading through the forums about device settings for how often to log and working on settings that will work well for hiking and taking of photos. I want to error on the side of more data points than normal just because I'll be doing a once in a lifetime walk through the scottish highlands. I need to balance the accuracy with not filling the bt747a+ buffer before the end of the day. (I'll download and clear the log at the end of each day) I'll be walking around 33 km a day. Here are my proposed settings:

fix - 500ms, time - 150 seconds, speed above 5km/h, Distance - 6m.

Thoughts? Thanks!

mdeweerd's picture

If I would know about Type

If I would know about Type 8-..., it would be mentioned in BT747 ;-).

For windows showing HDOP and so on could be added to BT747 somewhere, I do not know about other apps from my mind.

Settings.  Remind yourself that you can log 120k positions.  That is at most 120kx6m = 720km, at most 120kx150s= = 33000Ms = about 2Mhours. = about 100 days (if I calculate that right).  And, in case you walk faster than 5km/h, that is at most 120k x 0.5s = 60000 seconds = (/3600) just over 15hours.

=>Throw out the speed condition

If anyone else is reading

If anyone else is reading this and cares to know, here are the descriptions of the 'M' items:


"MALM", // 13 // PMTKALM interval - GPS almanac information
"MEPH", // 14 // PMTKEPH interval - GPS ephemeris information
"MDGP", // 15 // PMTKDGP interval - GPS differential correction information
"MDBG", // 16 // PMTKDBG interval � MTK debug information
"ZDA", // 17 // GPZDA interval � Time & Date
"MCHN", // 18 // PMTKCHN interval � GPS channel status
 I also found that NMEA monitor will display H/P/Vdop and other stats realtime in windows. You can get it here: Haven't seen anything for android though.Good point on the speed condition, but if I remove it, 720km is way more than I need. I could reduce it down to every 3 meters and still have room for error each day. What I'm unsure of is drift will cause me to use significantly more positions than I have or if I'll even get good enough accuracy to make a recorded point every 3 meters useful. I think real world testing will answer all this for me.I do wonder, why would anyone ever use speed as a condition over distance?

mdeweerd's picture

Here is an example where one

Here is an example where one might want to use all conditions:

The end user is interested in tracking when he uses his car and want to be sure that even when moving pretty slowly the a position is recorded every 100 meters (to have a consitent track).  Further to have some indication that the logger was still working, he logs one position every hour.  To make sure that something is logged, the fix condition is removed (also positions with no fix will be logged).


- Time = 3600 s to log one position every hour for logger 'actif' checking;

- Distance = 100 to avoid have too much separation on track points;

- Speed = 10 because that is when he will be driving his car and he wants to have more detail on that.

- Fix = adjusted to the distance precision he wants.  For instance if that user wants 10m precision when driving, I calculate speed at 10km/h which is 10000/3600 m/s which is 2.78 m/s, and speed at 130km/h, which is 36m/s.  So I need to log every 277 ms.  It'll be more precise at 10km/h, but that may be what is wanted and when driving speed likely exceeds 45km/h most of the time.


Speed may also be used for sport analysis at 5Hz while limiting filling the memory when not driving.

On android you can use

On android you can use

It shows some of the data and also the raw NMEA data.
Also you can use it as GPS on your phone instead of the internal one

Hi, I have just bought a

Hi, I have just bought a iblue 821E and it works very good with BT747 but I want to use it to check if our drivers aren't wasting too much time and taking long work breaks. So it is good to see where they drove but how do I get a good visual of the parking time ? I like to see when they are parked up for longer then 15 minutes. Kind Regards Tom

mdeweerd's picture

Hi Tomas BT747 does not

Hi Tomas

BT747 does not identify stops.  For what you want to do, I can propose SW to do so using a logger - please send me a private message.

Kind regards