#150779 - 29/03/2003 16:17
Re: GPSapp-0.17
[Re: tfabris]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Do you mean stream the serial output from the GPS unit to a file?
Yes.
If that can be done with some kind of softare on the player, I'd be happy to do it.
Well, I could write something, but if you wait for that it will probably be a bit. Basically the simple way involves installing gpsd, making it get run by hijack, then installing "nc" (netcat) and a script which runs netcat, connects to gpsd, sends 'R' to enable raw mode, and writes output to a file... but you'll have to pick a partition on your player to mount read-write to do it.
Don't ask me to script it, at least not today.
|
|
Top
|
|
|
|
|
#150780 - 30/03/2003 02:08
Re: GPSapp-0.17
[Re: Daria]
|
pooh-bah
Registered: 31/08/1999
Posts: 1649
Loc: San Carlos, CA
|
Well, I could write something
Or if you have access to a laptop you can just drive the area and capture the nmea output from your gps via hyperterminal (or your preferred serial app). I did this a couple of times when I was testing stuff for Kim's gps software. You could do it with the empeg as well, but you would have to have the drives mounted read/write and it gets more complicated from there.
-Mike
|
|
Top
|
|
|
|
|
#150781 - 30/03/2003 11:05
Re: GPSapp-0.17
[Re: mcomb]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Yup, but he mounted his GPS in his dash I bet. I suppose if he had another that might work.
|
|
Top
|
|
|
|
|
#150782 - 30/03/2003 12:26
Re: GPSapp-0.17
[Re: Daria]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Yup, but he mounted his GPS in his dash I bet. I did. I'm not that adverse to digging in the dash, but it's just a question of getting the time to do that. It's a bit of a project.
The GPSD software solution sounds like one way to go about it, but I know just enough about Linux to make me dangerous, so without some really detailed instructions, I'm loath to attempt it on my own.
|
|
Top
|
|
|
|
|
#150783 - 30/03/2003 12:40
Re: GPSapp-0.17
[Re: tfabris]
|
carpal tunnel
Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
|
Well, we have broken stuff here, and I have a funeral to go to, and after that, probably Wednesday at earliest I might be able to script something and give you some binaries.
|
|
Top
|
|
|
|
|
#150784 - 30/03/2003 12:44
Re: GPSapp-0.17
[Re: genixia]
|
enthusiast
Registered: 20/08/2002
Posts: 340
Loc: Pittsburgh, PA
|
Ok, got to play with this today. The altitude bug isn't totally fixed. Apparantly I was at 4 billion feet altitude at some point. I know I live on a hill, but it's not that high
And I thought I was dealing with altitude as a signed integer all the way by now. I don't really have a way to test it because the lowest point around here is several hundred feet above sealevel.
Preloading the list of routes at startup would solve the pause when we go into the 'select a route' menu, but I don't see what the use would be when the current stat (actually opendir) is left in place. As soon as we call stat or opendir, the process is stalled until the disk is spun up, it doesn't matter if we use or discard the result.
_________________________
40GB - serial #40104051 gpsapp
|
|
Top
|
|
|
|
|
#150785 - 30/03/2003 12:56
Re: GPSapp-0.17
[Re: tfabris]
|
enthusiast
Registered: 20/08/2002
Posts: 340
Loc: Pittsburgh, PA
|
Was it stuck at some waypoint in the middle of the route? What we do is, first get the distance between 'closest point' and the end of the route. The distances for all points in the route are pre-computed whenever we load the route into memory. And then we add the distance between our current location and that closest point. The number in the top right corner is not an 'as the crow flies' distance to the destination, but the true sum assuming that we will have to pass all waypoints including the currently selected one.
_________________________
40GB - serial #40104051 gpsapp
|
|
Top
|
|
|
|
|
#150786 - 30/03/2003 13:07
Re: GPSapp-0.17
[Re: tfabris]
|
enthusiast
Registered: 20/08/2002
Posts: 340
Loc: Pittsburgh, PA
|
I've also noticed that it still has trouble snapping to the correct waypoint in certain "really close" situations. It's hard to describe, but I'll try.
Yeah, most car navigation systems seem to use a 'trick' for this. They 'snap' the gps reported location to the closest road which has the correct heading. People that go hiking or offroading have to explicitly disable this feature to get correct position reporting.
I don't want to do something like this until we have full street information available. The current routes really don't have that much information and if we snap the current position to a likely place in the route it would be a bit difficult to find the correct route back after a wrong turn.
_________________________
40GB - serial #40104051 gpsapp
|
|
Top
|
|
|
|
|
#150787 - 30/03/2003 13:08
Re: GPSapp-0.17
[Re: jaharkes]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Was it stuck at some waypoint in the middle of the route? No, it was tracking my path and correctly displaying the waypoints in the correct order when I observed this behavior.
The number in the top right corner is not an 'as the crow flies' distance to the destination, but the true sum assuming that we will have to pass all waypoints including the currently selected one. Which is the behavior I expected. Only it seemed to be counting upwards away from zero as I approached the destination, not downwards toward zero. The number kept getting higher as I traveled the (correctly tracked) route, not lower.
It really does seem to have gotten its start and end points mixed up for the calculation of that number. It really looked like it was showing me distance-from-start, not distance-to-end.
The other number, the one in the lower right, correctly calculates distance to next waypoint. It's on the upper-right number that I noticed this behavior.
|
|
Top
|
|
|
|
|
#150788 - 30/03/2003 13:12
Re: GPSapp-0.17
[Re: jaharkes]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
The current routes really don't have that much information and if we snap the current position to a likely place in the route it would be a bit difficult to find the correct route back after a wrong turn. I agree that it would be bad to snap your current position to the map data. Because as we all know, map data can suck pretty often.  I like the way it works currently: seeing how far off from reality the map data is.
But maybe, just for the purposes of deciding which waypoint to select and display, it could sort of "assume" a snap? Not for the actual screen display, not for the actual calculations of everything else... just for purpose of choosing when to display the next waypoint.
This would also solve the problem of it saying to turn left when you're clearly looking at a right turn (as we discussed before).
|
|
Top
|
|
|
|
|
#150789 - 30/03/2003 13:21
Re: GPSapp-0.17
[Re: jaharkes]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
Preloading the list of routes at startup would solve the pause when we go into the 'select a route' menu, but I don't see what the use would be when the current stat (actually opendir) is left in place. As soon as we call stat or opendir, the process is stalled until the disk is spun up, it doesn't matter if we use or discard the result
Good point. I wonder if there's any kernel ioctl that can force a spin up with an immediate return?
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#150790 - 30/03/2003 13:47
Re: GPSapp-0.17
[Re: genixia]
|
enthusiast
Registered: 20/08/2002
Posts: 340
Loc: Pittsburgh, PA
|
Would probably still not be that useful. There isn't much memory and the player mlocks most of it for it's own use. Any codepath that hasn't been executed in a while has a high probability that it was paged out, so it is equally likely that something as simple as a function call is blocking on the disk spinup.
It is fairly easyl to observe, simply run ps auxwww and notice that the RSS size of pretty much every process (except for the player) is significantly smaller than the VM size. When gpsapp is blocked in the hijack waitmenu ioctl, it is completely paged out after a while.
I view this as a good reason to avoid useless and duplicated code. Most problems are avoided when the binary and memory usage are as small as possible. There are limits, with a full streel level database we simply can't avoid disk accesses.
_________________________
40GB - serial #40104051 gpsapp
|
|
Top
|
|
|
|
|
#150791 - 30/03/2003 15:05
Re: GPSapp-0.17
[Re: jaharkes]
|
Carpal Tunnel
Registered: 08/02/2002
Posts: 3411
|
unless gpsapp mlock'd that function...
But at this point, I'd be inclined to agree that the effort wouldn't be justified for just this reason. I do wonder whether it might be worth mlocking just enough of the menu structure so that gpsapp always appears responsive to user input, even if everything else is paged out. But that's another story.
I still think it's worth stating the directory early though. From the usability aspect, people tend to accept delays in loading files more than they do when listing them, and it'd be more consistent with delays elsewhere on the empeg - eg Playlist loading, the delay happens at the load.
_________________________
Mk2a 60GB Blue. Serial 030102962
sig.mp3: File Format not Valid.
|
|
Top
|
|
|
|
|
#150792 - 30/03/2003 15:36
Re: GPSapp-0.17
[Re: tfabris]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
I'm not that adverse to digging in the dash averseI'm loath to attempt it on my own. You got this one right, though. I hate it when people confuse ``loath'' and ``loathe''. As much as when they confuse ``breath'' and ``breathe''.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#150793 - 30/03/2003 17:13
Re: GPSapp-0.17
[Re: tfabris]
|
addict
Registered: 14/01/2002
Posts: 443
Loc: Raleigh, NC
|
No, it was tracking my path and correctly displaying the waypoints in the correct order when I observed this behavior. Was this in conjunction with it not noticing that you passed a waypoint due to the GPS coordinates being off from the waypoint coordinates? If so, it will count upwards as it assumes you have to go through that "missed" waypoint. As you continue on down the path, you are getting further from that "missed" waypoint, so your total route distance would increase.
If not, then I'm out of ideas.. 
|
|
Top
|
|
|
|
|
#150794 - 30/03/2003 17:32
Re: GPSapp-0.17
[Re: Yang]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Was this in conjunction with it not noticing that you passed a waypoint due to the GPS coordinates being off from the waypoint coordinates? Negative. This was on a different occasion when it was correctly tracking my path.
However, there's a chance that I may have had to twiddle the knob during the start of the trip (i.e., I was already underway when I activated GPSapp, and I twiddled the knob to make it reach the current waypoint).
But when I noticed the "counting up" thing happening, it was tracking correctly and following waypoints correctly.
|
|
Top
|
|
|
|
|
#150797 - 30/03/2003 21:31
Re: GPSapp-0.17
[Re: tfabris]
|
addict
Registered: 14/01/2002
Posts: 443
Loc: Raleigh, NC
|
Correct.. However, if it assumed that you missed a turn, it would consider your forward movement to be going away from the next waypoint. I guess it depends on the difference between the route and your path, and how close to the route you have to be to be considered following the route.
|
|
Top
|
|
|
|
|
#150798 - 30/03/2003 22:11
Re: GPSapp-0.17
[Re: Yang]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Lemme clarify what I said... No matter what happened earlier in the trip, even if I got off-track, the software knows that I'm on track *now* and is tracking correctly and showing me that the next waypoint is the correct waypoint. It shows the higlighted section of road (the road ahead of me) correctly. It is correctly counting down the distance to the next correct waypoint.
So, at that point, even if I'd gone off track earlier, the software should be treating it as an "on track, on path" situation, and ignore the fact that I'd strayed earlier in the trip. And should still be counting down the correct distance to both the next waypoint (which it's doing properly) and the end of the route. Not counting up from some old missed waypoint. If that's genuinely what the software is doing, then that's a bug that really needs to be fixed.
|
|
Top
|
|
|
|
|
#150799 - 04/04/2003 12:08
Re: GPSapp-0.17
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Update...
When using the new map data set from StreetAtlas with Siberia's method, the distance countdown seems to be working correctly. Perhaps all along it was bad map data?
My only concern is... The map data I was using before, it came right from Jan's supplied Python script. So I don't see why it should be corrupted to the point of causing a program error. Perhaps inaccurate in terms of street information, but not completely corrupted.
And in all cases, when I look at the map data files in an ASCII editor, they all look fine to me.
Hmm...
|
|
Top
|
|
|
|
|
#150800 - 04/04/2003 12:13
Re: GPSapp-0.17
[Re: tfabris]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
What happens if you remove the new .V ir_translate lines? If it goes back to being flaky, what about removing all ir_translate lines? Does Jan have any ir_translate happening?
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
|
Previous Topic
Index