Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Phones with heading and HDOP working?

Help
Mayeul
2012-03-26
2013-05-29
1 2 > >> (Page 1 of 2)
  • Mayeul
    Mayeul
    2012-03-26

    Hi,
    I would like to buy a smartphone to use GPSmid, that's for an 80 OSM mapping party in the Alps!
    I'm planning to take a few thousands geotagged images (with heading, and HDOP - Horizontal Dilution of Precision in GPS tracks) for OSM mapping.
    It seems that even when a given phone has a compass and GPS, some related functions do not always work with GPSmid (heading, HDOP).
    Could you tell your experience about phones, saying whether the following really works:
    * Take picture
    * Save lat-long GPS position + heading (angle to North) of picture , in exif or other format (save tilt as well if possible)
    * Save precision-related GPS (NMEA) fields, as many as possible (at least HDOP, other if possible)

    My first best would be using GPSmid under Android, but I can look at other platform and other open-souce software (like OSMtracker and Mytracks).
    If I need to do some postprocessing I will write some scripts if needed (and release as GPL3+ of course!).
    Ideally a phone with HD video capability ;-)
    Thanks!
    Mayeul

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-26

    Hi,

    GpsMid doesn't seem to have HDOP support at all, and I don't think it logs PDOP or heading  either.

    I added a simple Android native locator to GpsMid recently, but the only quality-related things I came across are PDOP and number of satellites. Now when looking at it, it does look like HDOP could be gotten from NMEA sentences, see http://www.gpsinformation.org/dale/nmea.htm - but not all devices output NMEA sentences. I don't know if it's easy to find out in advance which do.

    If you're willing & able to write some Java code, it might not be a huge task to add HDOP support. Adding 3D heading support probably could also be doable but require more Android knowledge. Also I don't know the state of camera support of GpsMid on Android.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-27

    Hi,

    Android does give out satellite info, might be HDOP can be calculated from it. Currently the code (below) just counts how many satellites are used in the fix, but according to the documentation - http://developer.android.com/reference/android/location/GpsSatellite.html - the info should also have satellite position.

    If you write the math, I can add calculation of HDOP to GpsMid.

    That still leaves storing HDOP and possible other quality parameters to the GPX track, which appears to be the more complicated part of the addition. The recordstore storage format would need to be changed, and GPX export will need to be changed. GpsMid should work also on low-resource phones, so I wonder if the quality info should be made optional. Is there a customary way of storing the info in GPX tracks?

    Iterable<GpsSatellite> satellites = gpsStatus.getSatellites();
    Iterator<GpsSatellite> sat = satellites.iterator();
    int i = 0;
    while (sat.hasNext()) {
    GpsSatellite satellite = sat.next();
    if (satellite.usedInFix()) {
    i++;
    }
    }

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-27

    Looking at your example code, adding HDOP & VDOP support to the GpsMid NMEA parses would be very simple.

    Currently there's code for PDOP:

    pos.pdop = getFloatToken((String)param.elementAt(15));

    So we'd just need to add the fields to position, then add

    pos.hdop = getFloatToken((String)param.elementAt(16));
    pos.vdop = getFloatToken((String)param.elementAt(17));

    and we'd have hdop & vdop (assuming the GPS device provides NMEA sentences which have them). For the devices which don't produce NMEA sentences with *DOP values, apparently the formulas you mention can be used to calculate the values from satellite positions.

    @sk750, what do you think of the size impact of adding fix quality support to GpsMid - HDOP and VDOP and perhaps heading to Position, those and perhaps heading to GPX log?

     
  • Mayeul
    Mayeul
    2012-03-27

    That was fast, great!

    A few comments:

    - If I'm correct PDOP is simply the quadratic mean of HDOP and VDOP, i.e.: sqrt((HDOP)^2 + (VDOP)^2) so it is not necessary to keep all the three fields (HDOP, VDOP, PDOP). (fast math derived from Wikipedia article).

    - Vertical accuracy is typically much lower than horizontal accuracy, that's why good GPSr have a barometer and use this instead for altimetry. Finally GPS altitude data can be less consitent with GPS-based altimetry than with digital elevation model. So IMHO, VDOP could be dropped (just a personal opinion)

    - For (compass-based) heading in the GPX I do not see any real use. Some GPSr do add "course" (the direction you are moving to) but this can be easily computed afterwards (it is the direction of the path between two fixes). Heading changes very fast as you rotate your body and your hand, so no need to track this every second.
    Hope this helps,
    Mayeul

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-27

    The latest GpsMid snapshot (nightly) now shows HDOP in tachometer, if it's available from NMEA sentences. It seems to work at least on the Samsung Galaxy Note. For some other devices, calculation from satellite data may be required.

    Also, I did a patch to store HDOP & VDOP in the GPX track, it's at  https://sourceforge.net/tracker/?func=detail&aid=3512012&group_id=192084&atid=939976  - but the trouble with this is that as the recordstore format changes, old recorded tracks won't work. That's not nice to users (so I won't add this to the GpsMid devel version), some kind of versioning & backwards compability mode should be added first so this can be added. But for your specific purpose I guess that's not necessarily a showstopper; I could just upload the patched .apk for you to use.

    This is how GPX looks like with the patch (coordinates removed), I hope it's the right format:

    <?xml version='1.0' encoding='UTF-8'?>
    <gpx version='1.1' creator='GPSMID' xmlns='http://www.topografix.com/GPX/1/1'>
    <trk>
    <trkseg>
    <trkpt lat='0.00' lon='0.00'>
    <ele>50</ele>
    <time>2012-03-28T16:52:14Z</time>
    <hdop>2.2</hdop>
    <vdop>3.5</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>3</ele>
    <time>2012-03-28T16:52:21Z</time>
    <hdop>2.9</hdop>
    <vdop>3.0</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>-6</ele>
    <time>2012-03-28T16:52:22Z</time>
    <hdop>2.9</hdop>
    <vdop>3.0</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>13</ele>
    <time>2012-03-28T16:52:37Z</time>
    <hdop>2.2</hdop>
    <vdop>2.9</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>21</ele>
    <time>2012-03-28T16:52:45Z</time>
    <hdop>1.5</hdop>
    <vdop>3.4</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>17</ele>
    <time>2012-03-28T16:52:48Z</time>
    <hdop>1.5</hdop>
    <vdop>3.4</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>16</ele>
    <time>2012-03-28T16:52:52Z</time>
    <hdop>1.5</hdop>
    <vdop>3.9</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>17</ele>
    <time>2012-03-28T16:52:55Z</time>
    <hdop>1.4</hdop>
    <vdop>2.8</vdop>
    </trkpt>
    <trkpt lat='0.00' lon='0.00'>
    <ele>14</ele>
    <time>2012-03-28T16:52:58Z</time>
    <hdop>1.5</hdop>
    <vdop>3.9</vdop>
    </trkpt>
    </trkseg>
    </trk>
    </gpx>

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-27

    About heading - I was thinking if you want to store heading in images (taken with GpsMid), maybe you want to store in in track also.

    Anyway, as I said, I don't know about the state of the camera code for Android, at least with the default settings it doesn't seem to work. Don't know what's wrong how complicated that would be to fix. But if the camera code can be gotten to work, I suppose it might not be too hard to get heading & HDOP stored with the picture.

     
  • sk750
    sk750
    2012-03-27

    @sk750, what do you think of the size impact of adding fix quality support to GpsMid - HDOP and VDOP and perhaps heading to Position, those and perhaps heading to GPX log?

    If the values for each track point is not stored in memory but rather written only to the record store that's ok I think. Otherwise on some low end mobiles this will have a big size impact on the number of possible track points they are able to record (though I think there's also a limit on the size of some record stores, but for those it could be made optional - simply store the old format in the record store which you have to support for reading anyway)

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-27

    I added satellite info handling to the Android location provider; now satellite info is gotten from Android API, not from NMEA sentences, and thus works even on devices which don't give out NMEA sentences. Turns out I have access to a Samsung Galaxy Mini which the kids have a few of, it now started to show satellite info.

    If you can provide the math in something close to java code, perhaps we can work out the code for HDOP (and maybe VDOP) calculation. The data is in form of a satellite array, in which each satellite has floats for azimuth and elevation in degrees, see http://developer.android.com/reference/android/location/GpsSatellite.html

     
  • Mayeul
    Mayeul
    2012-03-27

    @jkpj "This is how GPX looks like with the patch (coordinates removed), I hope it's the right format"

    Yes, it's great, see JOSM screenshot:


    I needed to save the above image somewhere, so decided that it deserved a blog post. ;-)

    I modified your gpx file as follows (I only changed latitude and longitude):

    <?xml version='1.0' encoding='UTF-8'?> <gpx version='1.1' creator='GPSMID' xmlns='http://www.topografix.com/GPX/1/1'> <trk> <trkseg> <trkpt lat='45.010' lon='6.590'> <ele>50</ele> <time>2012-03-28T16:52:14Z</time> <hdop>2.2</hdop> <vdop>3.5</vdop> </trkpt> <trkpt lat='45.010' lon='6.591'> <ele>3</ele> <time>2012-03-28T16:52:21Z</time> <hdop>2.9</hdop> <vdop>3.0</vdop> </trkpt> <trkpt lat='45.010' lon='6.592'> <ele>-6</ele> <time>2012-03-28T16:52:22Z</time> <hdop>2.9</hdop> <vdop>3.0</vdop> </trkpt> <trkpt lat='45.010' lon='6.593'> <ele>13</ele> <time>2012-03-28T16:52:37Z</time> <hdop>2.2</hdop> <vdop>2.9</vdop> </trkpt> <trkpt lat='45.012' lon='6.592'> <ele>21</ele> <time>2012-03-28T16:52:45Z</time> <hdop>1.5</hdop> <vdop>3.4</vdop> </trkpt> <trkpt lat='45.012' lon='6.593'> <ele>17</ele> <time>2012-03-28T16:52:48Z</time> <hdop>1.5</hdop> <vdop>3.4</vdop> </trkpt> <trkpt lat='45.013' lon='6.594'> <ele>16</ele> <time>2012-03-28T16:52:52Z</time> <hdop>1.5</hdop> <vdop>3.9</vdop> </trkpt> <trkpt lat='45.012' lon='6.594'> <ele>17</ele> <time>2012-03-28T16:52:55Z</time> <hdop>1.4</hdop> <vdop>2.8</vdop> </trkpt> <trkpt lat='45.012' lon='6.595'> <ele>14</ele> <time>2012-03-28T16:52:58Z</time> <hdop>1.5</hdop> <vdop>3.9</vdop> </trkpt> </trkseg> </trk> </gpx>
    

    Unfortunately copying the GPX from this page destroyed the indentation. I decided to save it from JOSM as a new GPX (below). Note that JOSM removes the vdop.

    <?xml version='1.0' encoding='UTF-8'?>
    <gpx version="1.1" creator="JOSM GPX export" xmlns="http://www.topografix.com/GPX/1/1"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
      <metadata>
        <bounds minlat="45.01" minlon="6.59" maxlat="45.013" maxlon="6.595" />
      </metadata>
      <trk>    <trkseg>
          <trkpt lat="45.01" lon="6.59">
            <hdop>2.2</hdop>
            <time>2012-03-28T16:52:14Z</time>
            <ele>50</ele>
          </trkpt>
          <trkpt lat="45.01" lon="6.591">
            <hdop>2.9</hdop>
            <time>2012-03-28T16:52:21Z</time>
            <ele>3</ele>
          </trkpt>
          <trkpt lat="45.01" lon="6.592">
            <hdop>2.9</hdop>
            <time>2012-03-28T16:52:22Z</time>
            <ele>-6</ele>
          </trkpt>
          <trkpt lat="45.01" lon="6.593">
            <hdop>2.2</hdop>
            <time>2012-03-28T16:52:37Z</time>
            <ele>13</ele>
          </trkpt>
          <trkpt lat="45.012" lon="6.592">
            <hdop>1.5</hdop>
            <time>2012-03-28T16:52:45Z</time>
            <ele>21</ele>
          </trkpt>
          <trkpt lat="45.012" lon="6.593">
            <hdop>1.5</hdop>
            <time>2012-03-28T16:52:48Z</time>
            <ele>17</ele>
          </trkpt>
          <trkpt lat="45.013" lon="6.594">
            <hdop>1.5</hdop>
            <time>2012-03-28T16:52:52Z</time>
            <ele>16</ele>
          </trkpt>
          <trkpt lat="45.012" lon="6.594">
            <hdop>1.4</hdop>
            <time>2012-03-28T16:52:55Z</time>
            <ele>17</ele>
          </trkpt>
          <trkpt lat="45.012" lon="6.595">
            <hdop>1.5</hdop>
            <time>2012-03-28T16:52:58Z</time>
            <ele>14</ele>
          </trkpt>
        </trkseg>
      </trk>
    </gpx>
    
     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-27

    Hmm, still thinking about saving the heading in the track. This could be useful for same reasons as you want the heading to be saved in images, if video is taken, for mapping or maybe even a distributed google streetview -type service as well as "black box" applications (for storing vehicle state e.g. for possible crash compensation reasons). Also for recording video if the device and video camera are mounted to face the same direction (or if the device itself records video with another program).

    Other interesting info to log with phone-internal or external sensors might be acceleration, pedalling (from bicycle), heart rate, fuel consumption (via an OBD-II interface) etc :-)

    Well, I guess HDOP & perhaps heading could be extensions of the current track format. But for other stuff, perhaps instead of extending the current binary recordstore format, a direct-to-GPX recording function could be added. It would be easier to change in the future. Would of course put more demand on the device.

    Back to the topic, it appears there's also HDOP in NMEA GGA sentences. I added support for that, might be that gives HDOP on some more devices.

     
  • Mayeul
    Mayeul
    2012-03-28

    Two good references I found for the math of accuracy are:

    http://scholar.lib.vt.edu/theses/available/etd-51198-162850/unrestricted/Thesis18.pdf

    (which incidentally says HDOP is far from enough to get horizontal accuracy!)

    And:
    http://users.erols.com/dlwilson/gpshdop.htm

    The first link is a thesis (15 years old) but includes a criticism of hdop. Reading it rapidly, I was more convinced than by the second link (which says nothing of vertical error. I presume this omission is made invisible for subsets measured with thousands of points!)
    HDOP is still very usefull but maybe not enough. Other factors such as type of fix (2D, 3D?), signal strength (and VDOP?) may matter as well.
    So this needs to be investigated further… Anyway, getting those data in GPSmid will certainly help make empirical assesments.

     
  • Mayeul
    Mayeul
    2012-03-28

    "still thinking about saving the heading in the track"
    Yes, you are correct, video mapping is also probably a good candidate.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-28

    Thanks for the pointers. Considering the pressure of backwards compatibility and the wide variance of sensor data which might  be useful or interesting, I'm tempted to do this by creating a new recordstore format with non-fixed content. So, instead of choosing that we'll store HDOP but not the number of satellites, that wouldn't need to be chosen.

    So, I would leave the current recordstore as is, to not make things any worse than currently for small devices which might have strict limitations on recordstore size.

    In the new recordstore, each track would contain a header

    - version number
    - list of data stored for each trackpoint, each list entry consisting of
      - name of data (e.g. "lat", "lon", "hdop", "vdop", "sats", "heading")
      - number of bytes (0 for string?)
      - data type ("int", "float", "short", "string", ..)
      - GPX export method type (not that familiar with possible GPX formats to mark auxiliary data, but perhaps more than one method)
      - something else needed?
    - the data

    The data itself would be in binary much the same way as in the current recordstore format.

    Benefits over writing GPX directly would be that the data wouldn't take as much space as writing directly in GPX format. Also that one could selecte after recording, what fields to export to GPX. Benefit over the old format would be extensibility.

    This format would make it possible to choose the palette of data logged on per-track basis, and the format wouldn't take space for data not available.

    Aside, probably won't pursue this:

    Not sure if this would be of any use (perhaps rarely in the case someone is in the habit of moving raw recordstore data from one device to another) latitutude and longitude and other basic info could be stored in the old format and extra info in other. Well, probably better to strip out the writing of the old format, and just keep the reading code.

     
  • Mayeul
    Mayeul
    2012-03-28

    Hi,
    I'm not familiar with the terminology, so asking: "recordstore" means saving in memory or in a new format?
    (In that case what appends if battery stops before saving to file?)
    I've read this "A record store consists of a collection of records which will remain persistent across multiple invocations of the MIDlet" so maybe my question is stupid.
    Why not saving continuously to file as GPX, live during acquisition of position? At the end, we just need to add "</trkpt> </trkseg> </trk> </gpx>", even manually if saving was interrupted. And XML is robust against truncation of the tail: the following perfectly displays all 9 points in JOSM (with a warning), even if the tail is missing.

    <?xml version='1.0' encoding='UTF-8'?> <gpx version='1.1' creator='GPSMID' xmlns='http://www.topografix.com/GPX/1/1'> <trk> <trkseg> <trkpt lat='45.010' lon='6.590'> <ele>50</ele> <time>2012-03-28T16:52:14Z</time> <hdop>2.2</hdop> <vdop>3.5</vdop> </trkpt> <trkpt lat='45.010' lon='6.591'> <ele>3</ele> <time>2012-03-28T16:52:21Z</time> <hdop>2.9</hdop> <vdop>3.0</vdop> </trkpt> <trkpt lat='45.010' lon='6.592'> <ele>-6</ele> <time>2012-03-28T16:52:22Z</time> <hdop>2.9</hdop> <vdop>3.0</vdop> </trkpt> <trkpt lat='45.010' lon='6.593'> <ele>13</ele> <time>2012-03-28T16:52:37Z</time> <hdop>2.2</hdop> <vdop>2.9</vdop> </trkpt> <trkpt lat='45.012' lon='6.592'> <ele>21</ele> <time>2012-03-28T16:52:45Z</time> <hdop>1.5</hdop> <vdop>3.4</vdop> </trkpt> <trkpt lat='45.012' lon='6.593'> <ele>17</ele> <time>2012-03-28T16:52:48Z</time> <hdop>1.5</hdop> <vdop>3.4</vdop> </trkpt> <trkpt lat='45.013' lon='6.594'> <ele>16</ele> <time>2012-03-28T16:52:52Z</time> <hdop>1.5</hdop> <vdop>3.9</vdop> </trkpt> <trkpt lat='45.012' lon='6.594'> <ele>17</ele> <time>2012-03-28T16:52:55Z</time> <hdop>1.4</hdop> <vdop>2.8</vdop> </trkpt> <trkpt lat='45.012' lon='6.595'> <ele>14</ele> <time>2012-03-28T16:52:58Z</time> <hdop>1.5</hdop> <vdop>3.9</vdop>
    

    (Sorry if this does not make sense at all).

     
  • Libor Striz
    Libor Striz
    2012-03-28

    AFAIK, HDOP ( resp. PDOP ) is just a partial readon of GPS position error,

    PDOP multiplies error due satellite position geometry,
    but does not cover primary errors of determination of particular satellite distance.

    This error has multiple parts, the major part is ionospheric signal delay, that is typically equivalent to 2-7 meters.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-28

    The terminology and the model of operation is inherited from J2ME, and might be a bit unfamiliar if one thinks in computer terminology.

    GpsMid was created to work also on small devices with no external file system at all. A recordstore is GpsMid-internal data, and it's up to the Java virtual machine how it's stored, but as you read it's persistent, in other words it's non-volatile storage which won't go away at power off.

    There's a relatively small buffer in saving (before writing to the recordstore), and a part of the track can be lost if power is cut off in the middle. There's an autosave feature however, don't remember the details.

    GpsMid originally doesn't save continuously to a file, as there might not be a concept of file on devices which GPS runs on. J2ME has extensions for file access, so on a device which supports the extensions, writing to a file would be possible. But using the recordstore has the benefit that even the devices with no file system can be used to records tracks, and then send them to another device e.g. via bluetooth or via a network connection.

    With devices like Android devices with big memory cards, filesystems and relatively powerfule CPUs, it wouldn't be a big issue to write GPX directly. But GPX takes more space than the binary format recordstore, so using the recordstore can make GpsMid run more smoothly even on smaller-resource devices. And recording couldn't be used at all on the devices with no support for filesystem. For these reasons I'm thinking keeping the recordstore is a thing to aim for. It's also faster to show recorded tracks on the screen when they're in binary recordstore format.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-28

    Addition to that - with the recordstore model, currently a track has to be separately exported as GPX. That might be an unnecessary bother for the user if he just wants the logs to the memory card, so I see how nowadays your question is valid, why not just simply log directly to GPX.

    Perhaps an option (also compile-time, and not included for small device targets) could be added to automatically convert the recordstore track to an exported GPX file, either at end of recording, or perhaps even while recording. In effect this would add direct GPX logging, while still keeping the recordstore option for small devices. But this gets kind of complicated (the code gets more complex).

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-28

    To conclude; considering that storage is cheap nowadays, a lost track is something we don't want, and the GPX export function needs to be there anway, I think logging as live GPX _AND_ to the recordstore would be the way to go for most cases, e.g. your use case. If something goes wrong with the recordstore (as has happened often for some Android GpsMid users, see the bug report, and also to me on non-Android devices), hopefully all of the track or most of it could be recovered from the direct GPX log.

     
  • Billi25
    Billi25
    2012-03-30

    Short Info: new Android Location provider works well on Samsung SG2. I get direction by compass, satellites number, HDOP and PDOP. Thank you. You are great!

     
  • Mayeul
    Mayeul
    2012-03-30

    Hi,
    Thanks a lot for the feedback! Is this the Samsung galaxy S II with code name = I9100 ?
    Have you tried with the device held vertically to see if heading is still correct in all directions? Is heading already in exif (discussion above focused more on gpx)?
    Thanks!

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-03-30

    At least on the Galaxy Note, which is close to Galaxy S II, taking of pictures with GpsMid doesn't work.

    Heading (direction variable in Trace.java) is not stored in exif, GuiCamera.java would need to be changed to store heading.

     
1 2 > >> (Page 1 of 2)