Problems with gpsapp

With gpsapp I have 2 problems:

1. When gpsapp is running I do no longer receive traffic alerts from the tuner

2. when a route is loaded gpsapp seems to have problems synchronizing with my actual position. When my position is exactly at the starting point of the route I can see the stored route on the empeg display about 5-10m away from my current position, during my travel the current position remains about 5m away from the calculated route but gpsapp does not "close the gap" and sync on the route; the same problem occurs while following a route, gpsapp seems to get easily out of sync between current position and original route (e.g. when a turn is slightly miscalculated) and then goes strictly to the end of the route and does not resync again with my current position, even not if I load the entire route again.

Any idea on this?

Juergen

For the second one, I often find I need to twiddle the knob a few times during the course of the trip to get it to re-acquire my route.

Okay, that avatar is just riduclous!

When gpsapp is running I do no longer receive traffic alerts from the tuner

Nothing does traffic alert on this side of the pond that I know of, so I can't suggest anything for this.

when a route is loaded gpsapp seems to have problems synchronizing with my actual position.

Do you have any way of capturing a GPS log of the route, or just staying around the start of it, then sending me that and the route file?

Okay, that avatar is just riduclous!

Wise man say: When living in house of glass, do not hurl stone.

Okay well if you're gonna carry on with that avatar, you need to change your title to "FAQ Mastah" or "FAQ Sensei" or something.

"FAQ Sensei"

I believe that would be ``FAQ Sifu''.

Okay well if you're gonna carry on with that avatar, you need to change your title to "FAQ Mastah" or "FAQ Sensei" or something.

FAQ Mahshi'n ?

O.K., thanks for your response.

Problem 1 (traffic alerts) seems to be on my side, after some other configuration the problem has gone ... so sorry for that.

Problem 2:
I'll try mz best to capture some data, but it will be a tricky job while driving.
Some more findings on my side:
Turns are most of the time not exactly calculated, about 100-200m away from the original turn. This could be a problem of Greenflag map data - I will check for this.

While following a route and being in sync with gpsapp I can see that when driving on a longer part of the route (10km) through curvy areas then gpsapp looses contact to the directy calculated line between the last and the next turn. This happens if I leave the direct line for more than 100-200 meters. In this case also the compass function of gpsapp stops working. When touching the route again, even crossing the route gpsapp gets not back in sync.

Try to fing more data on that.

Juergen

Hmm, 100-200m away from the actual turn. That sounds like greenflag is using a different datum. Most mapdata in the US seems to be NAD27, which is about 200m skewed wrt. to WGS84 which is what the gps is reporting. Now NAD27 stands for 'north american datum 1927', so it is highly unlikely that the european map data uses the same reference grid.

Every calculation in gpsapp is based on the WGS84 datum, because that is what the gps is reporting. The datum conversion of the mapsonus route data is performed by parse_mapsonus.py. You'll notice in a couple of places I'm using NAD27toWGS84(Coord(lat, long)). Just replace those with Coord(lat, long) and thel coordinates that you feed into the parser will not get the datum conversion applied.

Perfectly True!

I removed the NAD27toWGS84 conversion from the script and now the truns match quite good to my real position.

Many thanks for your advise!

Still present are the following problems:

1. gpsapp "looses" contact between actual position and calculated route, the route description goes (without moving my car) step-by-step directly to the end, display says "No route loaded", loading route again is not possible, map of the route is still present - with the new coordinate system its better (occurs not so often) but not solved

Today I tried hard (while driving) to log some data while following the route. My description of the route with empeg display messages is on
http://www.bndlg.de/~fossi/gpslog.htm

An interesting finding was that the reverse route works quite good.

2. Somtimes (as today) gpsapp suddenly hangs up while travelling without any user interaction (just display and moving map), front-keys are blocked, mp3 is still playing, remote works, tuner does not work - after rebooting everything is fine again

Any idea?

Juergen

Can you take a laptop to the car (at the start of the route), attach a GPS receiver, run a comm program and capture NMEA data for 2 or 3 minutes?

Quite hard for me, as I have no laptop and the gps-mouse installed and wired through the whole car.

But which info do you need, probably there is another way to get it.

Somtimes (as today) gpsapp suddenly hangs up while travelling without any user interaction (just display and moving map), front-keys are blocked, mp3 is still playing, remote works, tuner does not work - after rebooting everything is fine again

Yeah, I reported this bug a couple months ago. I wonder if it's related to the keystrokes-getting-through-to-player bug (the one where it fast forwards the song when you try to zoom in the map).

Oh, and on that last bug, I thought of something. Since it begins fast forwarding the song, that means only the key DOWN event gets through to the player software, not the key UP event. Maybe that'll help locate the bug?

Well, having complete NMEA sentences from the GPS receiver would be nice.

It's hard for me to connect the gps-mouse to another device as I would have to dewire half of my car.

But I have WLAN access to the empeg build in the car. Is there any way to capture data from the serial port within the empeg software?

Juergen

if you have wavelan, i assume you can get telnetd, and at that point it's a trivial matter to capture data by telnetting in and reading the serial port.

I posted a gpsd binary a while back. Install them, but do not hijack exec them.

telnet in. run gpsd -p /dev/ttyS1

at that point you should be able to telnet to port 2947 on the empeg.
type "R" at it and it will start streaming NMEA sentences at you. Capture them.

Did not suceed running gpsd.

Run it on the empeg with the command:
[ -x /programs0/gpsd ] && /programs0/gpsd -p /dev/ttyS1

Am I totally wrong ? (I'm not an expert on Linux)

ls -l /programs0/gpsd
gives you?

ls -l gives me:

-rwxr-xr-x 1 0 0 26192 Mar 2 17:01 gpsd

So gpsd is in fact executable, it evens runs without error, after a few seconds the cursor is back. I have at no time access to port 2947 with telnet, connections are refused. The number of network connections is not limited in config.ini.

What else could I try out ?

Juergen

get mini_ifconfig and run it, then you can telnet to it directly on the empeg, but i have no telnet client to offer you and no handy way to compile it just now. Nor is my empeg handy for me to make sure it works.

From the empeg, you'd
telnet 127.0.0.1 2947
and type R as before.

Puuh ...
quite a little piece of work.

But finally ... here is a log file of received data at the starting point of the logged route:
http://www.bndlg.de/~fossi/gps.txt

Usefull?

Juergen

Another problem occured while using gpsapp, which could have something to do with the previously reported problem:

Some routes work quite well, but when loading the route

http://www.bndlg.de/~fossi/route_error

gpsapp instantly reports "No route loaded", there is no route plan scrolling, there is simply nothing displayed, even not in map mode.

When trying to load the route a second time, gpsapp and the entire empeg hang up (only unplugging power helps).

Juergen

It isn't something silly like it's choking on the Ä character, is it?

Try editing the file so that it's got English-language-only characters and see if it still crashes.

Characters were not the problem (even if not displayed correctly on the empeg) but the file was simply a little bit corrupted during transmission to the empeg (no idea why). So this particular problem is solved.

Juergen

I don't suppose you save a corrupted copy?