I'm still a bit miffed about the fact that you guys seem to have hoarded all the trimble GPS's before I had a chance to order one.

But, I've been working on a GPS routing application, and I'm releasing it with source and all, hoping to get some more ideas and feedback.

The documentation is probably a bit sparse, but you can find it here.

Jan

I'll have to give this a gander! You may want to build a sourceforge project for this. Thanks for being the first to release sources to a GPS app on the empeg!!!

I've really enjoyed my Garmin GPS 16 sensor ... pricey but well worth it.

Greg

But, I've been working on a GPS routing application, and I'm releasing it with source and all, hoping to get some more ideas and feedback.

Yes, hat's off for putting this out there. I looked at a few modules like serial and nmea and they made sense to me (and that is saying something given that I am fairly C illiterate).

Once we're pass out of Daylight Savings Time, I may have some extra evening hours (maybe some daytime hours, too, if I join the ranks of the unemployed in November!!) and would like to get working on my long-jawed-about "big digital clock" app. I'd use your work as a base if that's OK and give you anything I come up with.

[edit: I may have missed it, but has there been any progress/resolution on the serial port sharing issue?]

Thanks again,

I'd use your work as a base if that's OK and give you anything I come up with.

If it wasn't ok, I wouldn't have released the source. Ofcourse it is. Something that others might find useful. The 'empeg_ui.[ch]' files basically contain wrappers around the hijack ioctls when compiling for __arm__, but which wrap around Xlib calls otherwise. So you can do most of the development and debugging on your X desktop (cygwin for WinXX users?)

I used things like valgrind to make sure there were no memory leaks, or bad memory references, gdb to do single step debugging, and gprof to shave off a few cpu cycles in the really bad parts.

I may have missed it, but has there been any progress/resolution on the serial port sharing issue?

Sharing with the player? That's what hack_init is for. It copies itself to /empeg/bin/play-s, then copies /bin/init to /bin/init.new, modifies it to start play-s instead of the real player, makes a backup of the original init, and moves the modified init.new over /bin/init.

When it is started as play-s, it checks /proc/empeg_power and when we're on battery (in the car) it execs the player with the -s- flag. If we're on AC it simply execs the player without the extra flag.

The only problem I've seen is than when I'm running on AC, have a gps connected and start gpsapp from the hijack menu. It manages to set the serial port speed so that the player suddenly sees the gps data and the player application invariably crashes/restarts.

Sharing with the player? That's what hack_init is for.

Awesome. (I hadn't looked at all the modules yet). For a while I was thinking we'd never run the player during those times (in rallies) where we really wanted the clock, but for some long events, we're thinking otherwise. Also, being able to run the player would let us do stuff like pipe the output of something like a ham rig to the speakers through AUX.

I don't think I have the talents to contribute much, but maybe something that someone, somewhere might use. You've done so much. I'm going to home in on how to display big numerals...

(actually, other than the clock HH:MM:SS display, I'm thinking it would be good to display something like a "quality meter" -- say a 1-5 bar graph on the right hand side of the display that gives some indication of when the time was last successfully set from a GPS signal....basically, how much can you trust the clock?)

I'm going to home in on how to display big numerals...

Thanks to the wonderful vfdlib this is almost trivial

Hmm, just had a thought. I can create some snapshots from the X window.
[this is the screen grab of the previous bignum.c]

And here are some from gpsapp.



I'm really just trying to get a better 'status' than stranger here

Wow, so you are actually doing live routing (looks like it from the screenshot)? What are you using for map data?

-Mike

No, this is offline routing. The route information from mapsonus.switchboard.com is converted into a representation in the correct datum and already projected into rectangular coordinates. These pre-planned routes can then be uploaded to /programs0/routes/ on the empeg and it only has to figure out where in the route we are and draw the thing.

Looks like fun, I can't wait to get my GPS hooked up so I can play with it... I'm a compulsive mapblast user whenever I'm going somewhere I havn't been before, so this would save a lot of trees...

Is there any way for it to overlay sound on top of the music? Verbal directions would be a nice addion if it doesn't have them already. I'm glad someone's actually coding this and leaving it as open source.

Thanks,
Matthew

In reply to:

---

No, this is offline routing.

---

Interesting. Your website seems to be down at the moment or I would download it and check it out. How do you get mapsonus to output the data? I don't see them giving long/lat info anywhere. What happens if you get off route? Anyway, it looks like you have a pretty good start and I am glad to see someone working on this again and actually releasing source.

-Mike

Yes, something is wrong with the wired network in my office. I'm currently on-line using my laptop on the wireless. Because the tarball is still smaller than 200KB, I'll just attach the latest version.

I'm now averaging the reported gps speed so that the ETA/ETE numbers make a little more sense.

How do you get mapsonus to output the data? I don't see them giving long/lat info anywhere.

Use general options and toggle the Show Latitude & Longitude checkbox. You then get a raw route description link at the bottom of the page which contains both the route and the detailed shape information.

Yeah, I'd also like to say thanks alot for posting this source. Maybe it's the much needed kick up the backside I needed to get my OBD project underway - especially that serial bit!

Cheers again!

Don't thank me, thank kirkis. His vfdlib is about 1500 lines of code out of the total of 3700, and I wouldn't have gotten this far without that. And after you're done thanking him, thank mlord for hijack, which gives a really neat and simple way to hook into the display.

And then start thanking the empeg developers for making such a wonderful platform and releasing all the information that makes all of these things possible in the first place. Or no, thank them first.

I've been reading the source code the GPS app.

I must say, very readable code.

Now, I have a question on non-NAD datums and a question on hijack and a suggestion/improvement for the app itself.

1. For folks who are not in the USA we tendnot to use NAD co-ordinates on our GPS - is there much conversion/tweaking of your conversion routines to allow for this in the route files [e.g. for those of us who use WGS84]?

2. My understanding of how the current application works is that once launched from the Hijack menu it takes over your screen [and some key functions] until the program is exited.
Am I correct here in this behaviour - it would look to be consistent with how other apps like Empacman work?

If so, then how much work would be involved to add a "hide" Application menu option to the main "in app" GPS menu, that lets me "un-hook" all those bound/captured keycodes and also relinquish the screen back to the [presumably] Application that is updating the screen before GPS hijacked it [the main Player App?]. While still leaving the GPS app running in background - changing the GPS menu back to just "GPS" when I hide it will let me get to it again while its still running?

This suggestion would let the GPS app continue to record its track, mark off waypoints and do stuff it normally would, and it can still update its "local" copy of the screen in local memory, ready when you activate it again to update the display.

What I'm thinking/would like, is always having the GPS app running, and attached to the Hijack menu ready to be "woken".

Then when I need to do some GPS stuff, I can activate this app in terms of "bringing it to foreground" ala [X]Windows apps.

When I have finished with the App I select the "Hide" Menu option, which now unbinds its main menu from Hijack and replaces it again with the "GPS" only menu.
Then unbinds/releases all those keys it has captured, until I reactivate it next time?

You could even possibly allocate a couple of [hard coded for now] "hot" keys to let you hide and unhide the GPS app quickly from either the IR remote or from say the Sony stalk [there are a few [shifted] buttons e.g. all 10 on the Stalk you could use for this purpose.

[I don't think there are any buttons on the front panel you could hijack for this purpose of acting as application "hotkeys"].

That way you could "hot key" in and out of the GPS app at will. Kind of like those TSR add ins for IBM PCS in the mid-80s [like Borlands Sidekick].

You could even have the GPS app be able to play sounds for certain [user selectable] events [like reaching a waypoint or end of Route] - but thats a future feature I think.

Or even different sounds for directions e.g. One sound for turn left, another sound for Turn Right etc, that way you would not even need to take your eyes off the road to navigate. Simple "WAV file" sounds can be quite effective for this sort of thing.

The current "Quit" program option would still be there to really exit the program.

Any comments on this - when I get some time next month I hope to get this app up and running on my Empeg so I can do some serious hacking. I can see some real useful [user] extensions coming for the GPS app real soon now.

1. For folks who are not in the USA we tendnot to use NAD co-ordinates on our GPS - is there much conversion/tweaking of your conversion routines to allow for this in the route files [e.g. for those of us who use WGS84]?

Once you're in 'empeg space', everything is WGS84. Only the python script that massages the route does datum conversion.

It is trivial to add any other datum, you just need to add the right values of 'a, inv, dx, dy, dz' corresponding to that datum. Typically a google search or a quick look at programs like gpsman and gpstrans will turn up the ones you need. And it shouldn't be too hard to understand how to add it to convert.py (look for Ellipse_Clarke1866 which is where the datums are defined).

However, as far as I know, mapsonus can only route in the US, and somewhere in their site it said that all coordinates are in the NAD27 datum. So for that particular conversion it isn't necessary.

Am I correct here in this behaviour - it would look to be consistent with how other apps like Empacman work?

Yes, pressing the top button 'exits', however this isn't a real application exit, so all the state will still be there. i.e. we still has the same route loaded and preferences set and will immediately try to find our new location in the route when we 'start' the application again.

I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl. I did figure out that setting an alarm provides a nice way to get unstuck from the WAITMENU ioctl, so I could have the app do something even when it isn't visibly running (popups/beeps/voiceprompts?). I can re-add that code in 5 seconds flat if you think it would be useful.

I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl

Correct, you can't. But what you *can* do is run in overlay mode using the setgeom ioctl and reserve a little window for any output you want to do. Unfortunately this means you interfere with operation of the player depending on what buttons you're trapping, because apps that run in overlay mode still get input focus, there's no way to run multiple overlay apps.

I think once Mark's climbing season comes to an end, we'll have a very good chance of getting improvements made to the userland interface.

For folks who are not in the USA we tendnot to use NAD co-ordinates on our GPS - is there much conversion/tweaking of your conversion routines to allow for this in the route files [e.g. for those of us who use WGS84]?

If you can tell the difference between NAD83 and WGS84, more power to you. The typical GPS receiver you're going to use isn't going to give you that kind of accuracy, unless you drop a lot on one. The "proj.4" library includes everything needed to convert, but you again, you're probably going to not care.

For what it's worth, I use Xastir with NAD83 calibrated data and a GPS receiver set to WGS84. The errors are always either "compromises have to be made when drawing a map" or "GPS receiver can't see enough satellites"

Using aerial photos when doing GPS tracking is way cool, but they're big, data-wise.

In reply to:

---

Once you're in 'empeg space', everything is WGS84.
Only the python script that massages the route does datum conversion.

---

You are only in WGS84 in the Empeg, if your routes are in WGS84 co-ordinates AND your GPS is outputting NMEA data to the WGS84 datum.

But I understand your point, and the conversion in the Python scripts was what I was asking about.

In reply to:

---

Yes, pressing the top button 'exits', however this isn't a real application exit, so all the state will still be there. i.e. we still has the same route loaded and preferences set and will immediately try to find our new location in the route when we 'start' the application again.

---

When you say this, do you mean that the App is still running [in memory], just not actively updating the display or doing anything in particular?

If so, then how much work to have it continue to "navigate" behind the scene, e.g. accepting NMEA sentences, parsing them and updating your co-ordinates - is that just replacing your "Wait buttons" call with a Poll keys? and then continue if none of the keys are actually pressed?

And as mentioned before, when a waypoint is reached possibly make a beep noise or some audible indicator to let you know that the waypoint has been passed?

But If the app exits, then how does it know which route was active when it restarts?
[save its info to disk - but then how does it store this saved route info by mounted the disk rw and then saving - I haven't dug into this code?].

In reply to:

---

I did figure out that setting an alarm provides a nice way to get unstuck from the WAITMENU ioctl, so I could have the app do something even when it isn't visibly running (popups/beeps/voiceprompts?). I can re-add that code in 5 seconds flat if you think it would be useful.

---

Yes, please put it back.

In reply to:

---

_yn0t's post:

In reply to:

---

(Original comment from jaharkes)
I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl

---

Correct, you can't. But what you *can* do is run in overlay mode using the setgeom ioctl and reserve a little window for any output you want to do.

Unfortunately this means you interfere with operation of the player depending on what buttons you're trapping, because apps that run in overlay mode still get input focus, there's no way to run multiple overlay apps.

I think once Mark's climbing season comes to an end, we'll have a very good chance of getting improvements made to the userland interface.

---

This all raises some interesting points/possibilities.

1. Can a Userland App have mutilple screen geometries active at once?
[if so, how does the kernel which geometry is to be used - by the file handle passed to the hijack routines by the app (the file handle returned from the open of /dev/display)]

and/or can a Userland app reliquish the current geometriy and request a new one?

[e.g. to switch from full sreen to windowed mode and v.v.].

2. Whats to stop a Userland app, requesting a tiny 1 pixel wide by high window and then using that as a way to "hook" the input focus?, this would result in net zero effect on the resulting display - while getting control of the input focus, then it can use either multiple open "geometries" to select how much of the screen it wants to write over.

3. For keys/buttons that are not hijacked, does the player app still receive them normally?
[this would make sense], or are they simply 'thrown away' by the kernel?

In the former case, what if we dedicated a particular key code sequence as a sort of "attention" button, so that when we press it, we reactivate the userland app [as it is waiting in background for this keycode to appear having done told the kernel it wants this keycode (and this one only)], while the others go to the player app in the meantime. Once this keycode appears, the pap now extends the list of hooked keys to include all those it wants when it has the focus [e.g. all the numeric keys etc, along with say arrows and menu/cancel etc buttons].
Pressing the hotkey again while the app is active, will tell the app to "hide" itself, i.e. unhook all those keys except for the hotkey and stop updating the real display, and carry on doing what you do.

Note: This same hot key, with a little assistance from the kernel in future, could be used to allow multiple background apps to sit there ready to hijack the display window [or their bit of it], and the user can activate them/give them input focus by pressing the hotkey sequence followed by say a numeric code e.g. 1-9, to select app 1, 2 , 3 etc up to 9.
[obviously if that userland app is not running, then it doesn't appear/cannot be "activated" this way, so Hijack simply eats that key sequence].

This selected App is then "given" input focus in Hijack [and possibly woken up somehow - e.g. the kernel sends it a special "wake up" response to the WAITMENU IOCTL].

What I'm thinking of here is a bit like Alt-Tab in Windows, whereby you can "select" a particular app [i.e. there could be more than one app in background], which becomes the "foreground" app [as regards to input focus], while the rest execute in background mode [e.g. they continue to monitor your progress along a route if its a GPS app etc].

And you could consider the Player app to be the "desktop" i.e. its what you see and interact with when no other apps are running/active.

When you say this, do you mean that the App is still running [in memory], just not actively updating the display or doing anything in particular?

Right, it just jumps out of the internal loop where it waits for keypresses and serial input and blocks on the WAITMENU ioctl until we are 'woken up'.

If so, then how much work to have it continue to "navigate" behind the scene, e.g. accepting NMEA sentences, parsing them and updating your co-ordinates - is that just replacing your "Wait buttons" call with a Poll keys? and then continue if none of the keys are actually pressed?

I'm not sure how much hijack likes it, but I can either set an alarm before blocking on WAITMENU, and when the ioctl returns with -1/EINTR we know that we haven't really hijacked the display, in which case we can just drain queued data from the serial point, recalculate position/distance to next waypoint and go back waiting.

If this doesn't work, I'll probably just fork off a thread that handles serial input and deals with location updates, while the main thread waits for hijack and handles the screen updates.

Does anyone have exact instructions on how to install it?
What kind of map data, if any, can we use? If so, how do we get the prog to recognize it?

How do you compile it to run under X windows?

Without having tried, but only looking at the makefile, I'd guess by:

make gpsapp_host

And after building, the "all" target should build that, and it runs for me...

Just type make.

But to see text and such when you run it, you need to copy
the fonts from the empeg to empeg/lib/fonts/

Most of it is documented in the README file in the tarball. Yeah, should have been INSTALL, nobody reads a readme

I put a new version up here.

It has the code to deal with gpsd, but the empeg doesn't have the loopback network interface so it is not active. Also changed serial port handling a bit to allow for other GPS protocols besides NMEA.

Immense thanks to dbrashear for putting a real Trimble on my desk, as soon as I get that serial interface built I can test TSIP and TAIP, the Garmin protocol has been tested already with an Etrex Venture.

First, I want to thank you for making so much progress here! But, of course, I am having a few problems.

I have two Trimble GPS receivers here and your application works with one, just fine (an old ScoutMaster) but the other(SV6 core module a la BGMicro) doesn't seem to put out a compatible form of NMEA.

The ScoutMaster puts out GGA sentances that look like this:

$GPGGA,190423,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M,*78
$GPGGA,190426,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M,*7D
$GPGGA,190429,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M,*72
$GPGGA,190431,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M, *7B

The SV6 output looks like this:

$GPGGA,190441.0,3716.915,N,12202.080,W,1, 6,001.3,124,M,-026,M,,*68
$GPVTG,000,T,344,M,00.0,N,00.0,K*4D
$GPGGA,190442.0,3716.915,N,12202.079,W,1,6,001.3,125,M,-026,M,,*6C
$GPVTG,000,T,344,M,00.0,N,00.0,K*4D
$GPGGA,190443.0,3716.915,N,12202.079,W,1,6,001.3,125,M,-026,M,,*6D


As far as I can tell the NMEA output is hard coded and the VTG is included. Also, note the decimal content of the time stamp and other differences. It seems the SV6 has added some fields for DGPS status at the end and uses different formats for Time of Fix, HDOP and a sign difference for the Geoid offset.

I am looking forward to trying the TSIP binary protocol as it is far more flexible and useful for troubleshooting.

On another subject, could you give a little more detail on running the Python script. I have not succeeded in getting it to find the raw route file or perhaps I didn't save it in the coorrect format. See attached "raw route" (html).

Thanks,

Lynn

One more request , Jan.

Any chance of adding some diagnostic capability. Things like number of satellites tracked/used and 2d/3d would be very helpful. Much more is available when you get away from NMEA.

Thanks,

Lynn

as soon as I get that serial interface built I can test TSIP and TAIP

I wonder if it makes sense to teach gpsd TAIP and TSIP, as well as the Oncore binary protocol. The Oncore thing was on my list, maybe I'll have some time again and...

My Earthmate is sad. One of these days I should fix it.

thiogs like number of satellites tracked/used and 2d/3d would be very helpful. Much more is available when you get away from NMEA.

Well, isn't 2d/3d what the "mode" in the GSA sentence means?

And of course in many cases you can have lots of stuff if you're willing to deal with proprietary sentences. The Rockwell Zodiac has goodies that you can have if you're willing to deal with PRWIZCH for instance (and for Earthmates, gpsd spoofs NMEA from the binary data)

I am looking forward to trying the TSIP binary protocol as it is far more flexible and useful for troubleshooting.

can you attach to it with minicom/hyperterminal and parse it? I can't.

I always hated trying to debug Rockwell binary protocol, I don't see why this would be easier, though if you parse it all you get more information, probably.

NMEA parsers are "hard" because what can be spewed at you isn't tightly controlled enough, but with fine-tuning NMEA is easily more friendly to a person trying to figure out what's going on than a binary protocol you have to pray you wrote the correct reader for.

There is more data in the NMEA sentences but each has a different mix (GGA, GLL, RMC etc.) but #satellites used, 2d/3d, time of fix etc. are handy to display. Unfortunately the SV6 module from BGMicro only ouputs GGA and VTG. TSIP (and probably the binary protocols from other manufacturers) is much richer. You can get signal levels, elev/AZM of satellites, time parameters such as GPS/UTC offset and so on. Also, the binary protocol is the path to configuring the receiver operating parameters.

I don't think that a terminal emulator is the right tool for monitoring the binary protool on a PC. Trimble makes available tools for their receivers and also provides source code as an example for users writing their own interfaces. Look at the Trimble FTP site fot "TK...exe"

The relavent URL for Trimble is:

ftp://ftp.trimble.com/pub/sct/embedded/

I don't think that a terminal emulator is the right tool for monitoring the binary protool on a PC.

Well, no, but if I go use someone else's computer, they'll have one. They may not have the Trimble software or whatever I wrote.

I have the Trimble software, the URL was included in the doc that came with the SV6 and I already applied the tk510 "update" to convert one of them. I also have TSIP and TAIP documentation in PDF form, for one of these years when I have a few minutes to care

Hey folks,
I'm just jumping onto this thead. This looks very exciting, and I was wondering:

#1: which GPS receivers are supported? Trimble only? Where does one buy them?

#2: is there a street/map database that comes along with this so you get more than just latitude/longitude info?

Thankx
-Ted

which GPS receivers are supported? Trimble only?
It looks like any receiver which puts out GGA, GLL, RMC and/or VTG sentences can be used. I think Sam Wormley has a list somewhere of which receivers send what sentences.

is there a street/map database that comes along with this

It's not my project, but i would like to point out that that's a rather ambitious goal for a project currently at version 0.4 and not particularly old.

$GPVTG,000,T,344,M,00.0,N,00.0,K*4D

Probably my bad. A lot of the code is based on whatever I could figure out from other applications like gpstrans and gpsman (a TCL/TK app). I'm guessing I misinterpreted my sources on that VTG sentence. It should be fixable by adding a couple of 'skip(&p);' entries in the right places. Doing that now...
And I'm sure that the GGA parsing works fine if I change the strtol to strtod in nmea_time.

I implemented both TSIP and TAIP based on reasonably official looking PDF documentation that I found with Google. But as I never ran the code it most likely doesn't work yet. (For Garmin I worked from their official specs and it turned out that I had the whole checksumming stuff wrong)

Python script, ehh, python parse_mapsonus.py route.html, just did that on the file you attached and the route file it spat out is attached... (It's binary, so I hope it doesn't get corrupted by attaching it)

Any chance of adding some diagnostic capability. Things like number of satellites tracked/used and 2d/3d would be very helpful. Much more is available when you get away from NMEA.

Hmm, but where to show that on the screen. I'm not even using altitude anywhere, so the 2d/3d difference shouldn't be that big of a deal (except for precision). Right now, if there is no fix, the bearing pointer becomes a little diamond shape, whenever we have a fix it should look like a pointer.

Do you mean that your earthmate doesn't work with gpsd anymore?

Gpsd is an option (the code is there), but we can't open a tcp connection to localhost because there is no loopback network device, and because the disks are not writable a named pipe or unix domain socket is probably hard to do as well.

But plugging the earthmate protocol from gpsd into gpsapp should be pretty simple, it might even be easier than it was to add it to gpsd in the first place

You probably already have this info but if not perhaps it would help a little.

This is a nice summary of NMEA protocol:

http://www.kh-gps.de/nmea.faq

And the Trimble Lassen documentation has a nice description of TSIP and TAIP:

http://trl.trimble.com/dscgi/ds.py/Get/File-9998/lassensk2man.pdf

On the diagnostics, if not on a separate screen then even some corner pixels coded or character variations could be made to work for # satellites etc.

I originally started this thread a while back toward this end:

http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=77301&page=1&view=collapsed&sb=5&o=0&fpart=1

Still struggling with Python. Does it actually find the route.html file or what? Perhaps my Python installation is kaput. I just get:

NameError: parse....

My autoHijack Python script seems to run ok, however.

Thanks,

Lynn

Do you mean that your earthmate doesn't work with gpsd anymore?

The serial cable went bad.

Gpsd is an option (the code is there), but we can't open a tcp connection to localhost ... because the disks are not writable a named pipe or unix domain socket is probably hard

That's worth investigating. If it can be done I'll add it. Russ promised to release the patch I sent him in a gpsd 1.07 soon so maybe if I get my butt in gear...

I haven't checked the latest release, but in plagerising (sp?) some of your code in hte first release, I've noticed the following in empeg_ui.c:

1) You only bind IR_TOP_BUTTON_PRESSED, and not IR_TOP_BUTTON_RELEASED. This has caused me a mild headache. I've been writing an app and want to remain consiste
nt with Hijack's button code, where the top button is usually used for escape. It appears as though the first button returned is always IR_TOP_BUTTON_PRESSED, so setting up the application to exit on this causes the app to exit immediately on invocation.

2) It appears as though the last button in your list (IR_KNOB_LEFT) isn't bound either - I can't understand why because your code looks good. I think that hijack is subracting one from the number of buttons that you tell it to register. So in this case, telling it to register 9 buttons works, even though only 8 are listed.

So I've modified my local copy of empeg_ui.c to reflect these 2 changes:

const unsigned long buttons[] = { 10, /* front panel buttons (8) */ IR_TOP_BUTTON_PRESSED, IR_TOP_BUTTON_RELEASED, IR_RIGHT_BUTTON_PRESSED, IR_LEFT_BUTTON_PRESSED, IR_BOTTOM_BUTTON_PRESSED, IR_BOTTOM_BUTTON_RELEASED, IR_KNOB_PRESSED, IR_KNOB_RIGHT, IR_KNOB_LEFT };

So you'd be quite at liberty to wonder why I'm posting this, since I'm using it in an app completely unrelated to it's original purpose. The reason is that it's a bloody good bit of code, which IMO could form the basis for an empeg Application Template. Being able to test on an x86 architecture is a wonderful thing. Thanks. BTW, thanks also for the great Makefile. I've just learnt a lot about Makefiles and using them to dual-compile!

Still struggling with Python. Does it actually find the route.html file or what? Perhaps my Python installation is kaput.

Actually, I just checked, it runs fine with python2.1, but gets a zerodivision error with python1.5. I'm trying to figure out why. It looks like 1.5 goes off into the woods in the distance calculation. The workaround fix is to only use the 'simple' distance calculation, change
Distance to Quick_Distance at line 110 in parse_mapsonus.py.

Ah that explains a lot of the strange things I noticed, I guess the player in some screens is actually sensitive to the release codes and since I wasn't hijacking those...
It is probably wise to add release for all other buttons as well. And looking at the hijack source yup, hijack expects to see number of buttons + 1 as the first entry (maybe because 0 means no buttons and 1 indicates all buttons?)

empeg_ui.c/h should probably be distributed along with vfdlib. Kirkis, interested in adopting them?

I finally found the short between the headphones regarding Python. All my (un)doing!

I've been around the block a few times and have some observations as follows:

The SV6 interface seems to be fine now and the receiver works well.

I have created two routes. One is the same as the one I attached earlier and the other has two intermediate waypoints along the way. The second crashes every time I try to load it (causes the Player to stutter as well) but the first loads OK.

The direct route has some extraneous tracks showing at the larger scales (greater than 2-4 km) and shows tracks crossing the screen in all directions at the largest scale. When I get out to the largest scale the UI seems to lock up and I have to cycle power to recover.

The text to the right of ther screen shows 3781 km or 23495 mi both above and below the direction arrow. The endpoint is actually about 10 miles away as the crow flies.

Hope this helps track down some of the gremlins. I am glad to test at any time!

Lynn

The SV6 interface seems to be fine now and the receiver works well.

Nice, I just put up a new version 0.5 which has the NMEA parsing changes and also hijacks all the right buttons.

Could you send me both of those routes. I wonder whether there still is some python problem that created a badly formatted track file... Oh, you're probably using Windows which does 'automatical CR/LF' translations if you don't open files in binary mode.

Small change, I just included it in v0.5, but basically it is open("route", "wb"), that 'b' is significant here.

The routes are attached. Final v0.5 behaves similarly. Yes I am using Windows but have only renamed the route files post Python.

Lynn

and here is the route with intermediate waypoints.

Sorry for being a moron guys, but I can get this thing to work.
Can someone please detail the steps out for me on how to install this? If I use the preinit.d install instructions on its site, is that all I need to do on the preinit.d end (except for placing the M50gpsapp file in that dir)?
Thanks in advance guys, I am really looking forward to this program for trips and such.
Justin

Ok, windows is doing something funny with your files.
Here is where it goes completely wrong,

'\xd4\xf9\xff\xffz\xe8\xff\xffgP\x00\x00'

 41: x -1580 y -6022 dist 20583

',\xfa\xff\xff`\xe8\xff\xff\r\nP\x00'

                           ^^^^

 42: x -1492 y -6048 dist 5245453

Interestingly enough it looks like this is inserted at position 512. So it looks like something inserted a nice 'linebreak' for you. Probably the program you used to rename/copy the file. I guess I'll switch to some ascii based format, which will also make it easier to distribute these route files.

Jan,

I never did get the route file you converted. Could you send it again and I will not rename it, just to confirm that this is the problem?

Lynn

Cancel that request! I did it myself and confirmed your theory. Works fine if I don't rename. I'll try it under way in the morning.

Thanks

I have a preinit script that mounts /programs0, i.e. I followed instructions from the BBS from genixia. From your descriptions I can't really tell what you are stuck on.

Indeed, I just followed these same instructions, applying this patch to the preinit v4 source and building, with the gcc from mlord's cross compile package. I then installed launcher, but that's only really because I also wanted to play with some of the games.

Incidentally, Russ Nelson just released GPSd 1.07 with a patch that makes the Earthmate support work better. Were it not for a trip west, I probably wouldn't have noticed, but Hugo or Xastir or whatever I was using that week wasn't getting a fix, and...

GPSd 1.07 is actually somewhere different than 1.06 was.

Gpsd is an option (the code is there), but we can't open a tcp connection to localhost because there is no loopback network device, and because the disks are not writable a named pipe or unix domain socket is probably hard to do as well.

(Wow! I have to say that I am feeling "Hijacked!" by this thread. Another evolving project where Jim just can't keep up!! Seriously, it is exciting to see all the activity. Less talk, more action, indeed.)

No loopback interface. Interesting! Never gave that a thought. I'm thinking that was left out to help reduce the image. Is there any way to work a Hijack-style workaround? I'm just feeling that there could be other reasons down the road to use loopback.

On the clock front, I looked in the Readme (finally!) and elsewhere and didn't see any reference to setting the Empeg's clock. I didn't necessarily expect this, but I began to think about what would be the most desirable way to derive time for a clock display in the case that satellites were not in view.

I don't want to overestimate the risk of having no GPS time available. While most commercial units seem to refuse to display much of anything unless an initial fix has been achieved, is there any reason a custom application could not display time from as few as 1 satellite? I mean, they are all UTC, and I wasn't thinking delay would be a huge factor (or that GPSs did much to adjust time from traingulating satellites. I could certainly have a lot of this stuff all wrong.)

If you could display time from a 1-2 satellites independent of quality of fix, then going through the loop of having clock display read from Empeg's local clock would seem less necessary. OTOH, it would be a nice feature....and might be another reason to lust after loopback access to gpsd -- another modular process could set the local clock from gpsd rather than having the main gps app do it.

For a big-digit clock, was thinking of some kind of quality meter on the right hand of the display with 4 or 5 bars. Something like:
0-Local clock not set in past 3 hours
1-local clock set in past 3 hours, but GPS time not now available.
2-local clock set in past 3 hours, and GPS stream now available.
3-local clock set in past 30 minutes, but GPS time not presently available.
4-local clock set in past 30 minutes and GPS time available.
5-local clock set in past 10 minutes from GPS time

I probably haven't thought this through very completely yet, but will give it some more thought and welcome any comments. The goal is to have a clock that is always available and is as accurate as possible, but with some indication of trustworthiness. If I missed any clock related stuff in the work to date. my apologies.

Again, this is very exciting. I need to get that serial interface built!

I'm thinking that was left out to help reduce the image. Is there any way to work a Hijack-style workaround? I'm just feeling that there could be other reasons down the road to use loopback.

Oh it's there, no need to hijack anything. It just needs to be brought up with ifconfig. And it isn't needed at all for the normal operation of the player because the player never has to talk to some other process on the same machine.

On the clock front, I looked in the Readme (finally!) and elsewhere and didn't see any reference to setting the Empeg's clock.

I don't think you'd really want a purely GPS based clock anyways. Just look at all the delays, gpsapp is (or should be) running at a lower priority compared to the player. I'd rather have my location lag by a second or two than skipping music. Gpsapp wakes up 10 times per second and handles whatever was in the serial buffers at that time. So any measurement we get is on average 50ms delayed. And then the timestamp we receive isn't even the UTC time that the message was sent/received, but rather the UTC time of the last time we calculated a fix, it might just as well be several seconds old. If we want to get a better time estimate we'd have to busy loop and grab stuff from the serial as soon as it is received.

It sounds more like you really want to use the local clock, but have it 'disciplined' by the PPS signal from the GPS receiver. I'm not sure the empeg really has the oomph left over to do that kind of stuff, it probably does if you don't care much about playing music. (and adding an intermediate gpsd will add even more unpredictable latency in the tcp socket buffers).

As a side note, v0.6 is out. The main change is that the the route description files are now an ascii format.

What about just durning the preinit, check the time via GPS, if empeg time is off, adjust time.

Is this possible?

What about just durning the preinit, check the time via GPS

You really expect to already have a fix?

Oh it's there, no need to hijack anything. It just needs to be brought up with ifconfig.....

Great, I misunderstood and thought it hadn't been compiled in. If I can finish soldering this weekend, I'll try bringing it up along with gpsd

I don't think you'd really want a purely GPS based clock anyways. Just look at all the delays, gpsapp is (or should be) running at a lower priority compared to the player. I'd rather have my location lag by a second or two than skipping music.

Agreed. Hmmm. For hard-core positionists, could you have an adjustable priority tied to a Wendy filter or genre or something??

Gpsapp wakes up 10 times per second and handles whatever was in the serial buffers at that time. So any measurement we get is on average 50ms delayed. And then the timestamp we receive isn't even the UTC time that the message was sent/received, but rather the UTC time of the last time we calculated a fix, it might just as well be several seconds old. If we want to get a better time estimate we'd have to busy loop and grab stuff from the serial as soon as it is received.

For our skill level in TSD rallying, *reliability* is important, but precision would be acceptable at +/- 1 second. I wish we could begin to care about milliseconds!!

It sounds more like you really want to use the local clock, but have it 'disciplined' by the PPS signal from the GPS receiver. I'm not sure the empeg really has the oomph left over to do that kind of stuff, it probably does if you don't care much about playing music. (and adding an intermediate gpsd will add even more unpredictable latency in the tcp socket buffers).

Yes, a GPS-disciplined clock. And if it ever managed to be more accurate than strictly required for our rallying purpose, somebody else might find a use for that precision. Way back when I remember elleweber disabusing me of tapping 1PPS with the Empeg's existing serial interface. My memory is that much more work would have to be done to accept 1PPS into a clock process -- probably not something with the reach of my meagre talents. Given that it looks like you are including some degree of support for gpsd, my leaning would be try my hand at something that fetches time from that.

Yes, when first I conceived of a big clock, I wasn't thinking we'd use the player concurrently, but I've changed my mind on that so resources would be a concern...

As a side note, v0.6 is out. The main change is that the the route description files are now an ascii format.

More action!

Geez, disabusing sounds awfully harsh I 'm just very cautious of using a serial port for any kind of precise timing.

The PPS signal from the GPS receiver is going to be good to ~1microsecond when you have a navigation solution with good geometry or when you are stationary at a known position with one or more satellites tracked and the receiver in the time-keeping mode. The delays through the serial port will be on the order of 1/baud seconds, plus some unknown and probably variable processing delays. All of this may well be good enough for your rally application as it could be well under 100 milliseconds.

I suspect that you can do well enough for your needs by using the NMEA data along with a calibration factor for all of the delays to set the Empeg clock periodically. I doubt you would need to set it more often than once a day at the first good fix after turn on. I suspect that we can come up with a proceedure for determining the calibration factor though it would be tricky to take into account various receivers and their different processing contributions along with their variations in NMEA sentence outputs.

Lynn

jaharkes, I've found the following:
Start gpsapp, wait for the location. return to player software (using top button), return (or is it restart?) gpsapp. The player shows the screen it was left with for half a second or so, and then the player skips to auxiliary periodicaly. Any ideas?

Ok, which is the player that shows the screen it was left with? the empeg, or the player software?
In any case, gpsapp isn't reading the serial port while you're back in the player software, so when we get back it should still be at the location where we 'exited'.
It should reopen the serial port, and drain the buffers, and then start showing the location again.
What is auxiliary? If it is the player software doing something strange, perhaps that is because before v0.5 all the button release codes were not hijacked, so they would still get to the player software.

I'm using version 0.5.
After returning to the gpsapp via the hijack menu, the empeg screen shows the state gpsapp was left with for a short time. Then the player's source chnges to auxiliary input periodicaly.

The only way I can change to aux is by pressing a button on my remote. The remote even works when gpsapp is running because none of the IR codes are hijacked. Are you sure nobody happens to be sitting on a remote?

I'm pretty sure, yes ;-)
Do I have to run hack_init only once or every time I upload a new version? I did it only once until now.
The bug or whatever is btw. 100% reproducible.

Do I have to run hack_init only once or every time
Only once, until you install 2.0b14. If you run it again it won't find the /empeg/bin/player string and will exit with a message similar to 'didn't find player string is /bin/init already hacked?' and won't do anything.

Interesting that the bug is so reproducible, and it only happens when you start gpsapp, go back to the player and return to gpsapp? Did you do anything in gpsapp besides waiting for a location update?

Does anyone else see this? I've just tried this about a million times and the player never even skips a beat, let alone switch to aux.

I'm going on a longer drive this evening. I will do some further testing.

I've just tried this about a million times and the player never even skips a beat, let alone switch to aux.

I need to visit a store but when I get back I should have what I need to attempt to connect my Trimble SVee6 to the Empeg in the car and I will try then.

The player shows the screen it was left with for half a second or so, and then the player skips to auxiliary periodicaly.

I used 0.6, but it shouldn't matter. I can't reproduce either.

Incidentally, here's my temporary setup with the SVee6 attached to the player in the van. This is just after I got a fix in the car, right after plugging it in for the first time.

And here's the modified SVee6 enclosure (the metalwork and the extra board you can't see with a 7805 and MAX233 were done by someone I work with named Jeff Hutzelman for his car, and I stole it to take it with me to the empeg meet; He then built another and installed it in his own car (he's doing APRS with it) so I guess that makes this one mine.

I did get a "strange behavior" myself, but no network in the car yet. I put the car in "run" (without starting) and let the player start. It came up, I started gpsapp and it got a fix. I started the car, and gpsapp was gone from the hijack menu. I pulled out and reinserted the player and it was all good. I should really get network in the car so I can debug...

As an aside, the icon seems to be about 75 degrees counterclockwise of where i'd expect it to point, but maybe I misunderstand what it is.

I started gpsapp and it got a fix. I started the car, and gpsapp was gone from the hijack menu.

Yeah, that could very well be a hijack bug, I noticed it myself. The menu entry is only shown when the application is blocking in WAITMENU.
Sometimes, like when the car is started, hijack seems to 'forget' that there was a overlay active. The display and button redirections are removed, so the player becomes visible again, but the application is still in it's main loop polling for keypresses which ofcourse never arrive.

The little pointer in the map area should always be 'true north' up, the other pointer points to the direction of the next waypoint, but is relative to the current direction. So if it points up, you should be driving straight to the next waypoint, and it points down when driving away from it.

What version of HJ are you running, and do you have any other applications (empacman, viewer, emptriv etc) running?

Might work better with the antenna right-side-up

I have a question for you, I looked at your photo of your BG Micro Trimble GPS in your car.
You appear to have the Black side of the external antenna facing towards the windshield [and the GPS sats].

Is this the correct oritentation - the documentation didn't specify this that I read, so I figured the "black" bit was for mounting underneath the antenna, this the shiny side should face up, or does it not matter?

Does the GPS even work with the antenna upside down - or does it work, but "backwards" in direction mode, e.g. it reports lat/long correctly, but some directions are reversed left to right?

As far as I know a gps derives direction from difference between the current position measurement and the previous measurement. So it shouldn't matter at all whether the antenna is upside down or turned sideways.

The only effect of holding it upside down is that the metal of the mounting bracket might shield some of the satellite signals. The ceramic piece on one side is the actual antenna, so I guess it would work best when that is facing upwards.

Actually, the velocity vector and hence vehicle direction is the residual of the satelllite signal doppler solution. The doppler component for each satellite signal can be calculated knowing the satellite location at the time the signal was transmitted (calculated from the ephemiris for each satellite) and the user equipment's current position. What is left over is attributable to the users velocity. This is far more accurate and less noisy that differentiating position, as was done with previous radio navigation systems such as Loran or Omega.

One place that would help in gpsapp would be to retain the last heading from the GPS as it is slowing down, as the heading becomes quite noisy at rest. Typically if you lock the direction pointer as you drop below 1-2 km/hr and restore as you speed up again it provides a cleaner display for the user.

The active copmponent of the microstrip antenna (sometimes called a patch antenna) supplied with the SV6 from BG Micro is the plating on the exposed surface of the square piece of ceramic. Mine is under a piece of foam tape. The other side is actually a preamp in a shielded enclosure with about 25-30 db of gain, powered by 5 vdc on the feedline. If you are getting anything with the antenna upside down then it is just good fortune and reflections. The "T" section of extruded black plastic is just for mounting.

Lynn

Yeah, that could very well be a hijack bug

Well, every other time I thought I observed such a thing, I was wrong

The little pointer in the map area should always be 'true north' up, the other pointer points to the direction of the next waypoint, but is relative to the current direction. So if it points up, you should be driving straight to the next waypoint, and it points down when driving away from it.

I don't have any waypoints on the player, I was just using it with the GPS and looking at the map area. Indeed, I figured out the bit about true north; It became obvious when I was heading toward Kittanning on route 28 (I took a ride to play with it) and it was pointed consistently toward what would be northeast if up was north.

Tried again and failed to reproduce. I should point out:
-I'm running launcher and telnetd, and i didn't start any of empacman, empsoko, emptris or emptriv from launcher but they are all there
-no waypoints (shouldn't matter)
-hijack has been 295, 296 and now 297

Actually with no waypoints, the map 'center' is 0.0,0.0 and I'm projecting to a rectangular grid relative to that point. So I would assume everywhere but the couple of hunderd miles around greenwich would see significant distortion.

I'll add something that initialized the center coordinate based on the first fix if we don't have any route or waypoints loaded.

Aha, that makes sense.

I meant to look at the code, but I ended up going out to look for more GPS receivers.

I got something close to this to happen, *one* time. The one time it happened I popped up the HiJack menu by holding in the rotary selector. All other times I either held in the selector or held "OK" on the remote and it didn't happen. What happened was I got a blank screen for a second, then the unit rapidly began switching between aux, tuner and player. The remote wasn't active during this time. Perhaps significant was that I "recovered" the player by holding in the rotary selector, and the HiJack menu came back up, but sans the GPS item.

I tried to recreate, without success.

I definitely need to get in-car network so I have some way of figuring out what's going on.

Ok, I'm running HJ v297, software 2.00 b13 developer image. I have nothing in my preinit.d except M50gpsapp.
I always use the rotary knob to access HJ, using the remote doesn't fix it though.
I found out that I don't need to have a gps receiver connected. I even don't need to leave the HJ menu! I just do the following:

1. I enter HJ, starting GPS
2. The screen show 'waiting for gps location'
3. I push the top button to return to the HJ menu
4. I select GPS again.

The sound output pauses for a short moment, and then the empeg changes the sources rapidly between aux and player.
Again: No gps receiver connected, no one sitting on the remote ;-)
I've noticed that this happens quite randomly. It's not 100% reproducible as I first stated. Maybe it is related to 'restore visuals: enabled' in HJ?
I've also noticed that I can return to the HJ menu while the player is switching by pressing the rotary control. As dbrashear already told, the GPS menu item has gone then.

Can you see whether it makes a difference when you hold the knob down for less than 2 seconds, or longer than 2 seconds when selecting gpsapp. I think I might have an idea what could be going on. Hijack has this 'cycle to the nextsrc code when the knob is held down for more than 2 seconds'. Maybe it doesn't see the knob release.

I took a look at the output coming over the serial port: Everytime I start GPS in the HJ menu, HJ gives out the following message:
'hijack: removed menu entry: "GPS"'

If I hold down the knob longer than two seconds to start GPS, then first the screen appears with 'waiting for GPS location' and then (after ca. two seconds) the player's source changes to aux. but remains there. If I just click the knob to start GPS, then sometimes it works, sometimes the player goes into 'rapid source switching' ;-)

Hmm...so why is Hijack removing the menu entry immediately?

Can you ensure that you have the following in your config.ini:

[Startup]
reservecache=2


This tells the player to leave 2MB of memory unused. (By default it grabs all available memory - so if an app wanted to allocate some memory after the player has started, it could hit problems.)

I've put that in my config.ini - no difference.
Interesting thing is that the GPS menu entry is still there *although* HJ says 'removed menu entry: "GPS"'.
Only if that problem with source switching appears and I re-enter HJ, the GPS entry has really gone.

Hijack always 'removes' any application that is not waiting in the WAITMENU ioctl from the menu. So as long as gpsapp is 'running' it won't be in the menu, as soon as you put it back to sleep on the ioctl you can see the entry again.

You don't see the gps menu entry because gpsapp is still running in it's main loop and hasn't returned to waiting. Hijack forgot about the active overlay and removed/overwrite the button and screen redirections.

I figured it would be something like this.Well, when I go out again I guess I'll play around some more. Right now I'm in the middle of 60gb->80gb my player

Short explanation:

I don't know anything about your bug, but i'm pretty sure the thing about hijack removing a menu entry is nothing to worry about. It is hijack functioning "normally".

Long explaination:

ISTR that the text's main purpose was actually as debug code for something Mark implemented so that a program could change the menu entries during the course of the program. This was implemented in vertions 268-271 of hijack. Before then, any call to WAITMENU would insert the entry into the menu for the entire life of the program, such that if one program wanted to insert a new menu title after inserting an old one, a phantom entry remained. Now the menus only exist for the life of the WAITMENU call, a much better solution.

In other words ignore that. For those not familiar with the programming aspect, it just means the entry has been selected and it's the programs turn to do stuff. (That is, until another WAITMENU call.) I'm sure mark could explain the technical aspects much more clearly.

John

P.S. I recall there was still one minor bug with the dynamic menus in hijack feature, but i forgot what it was. I was writing a program that needed to dynamically change the menus but then I got a full time job and forgot what it was.

wow, i type slowly.

BG Micro has a Motorla 8-channel GPS unit for sale now for $14.95, it's got NMEA output so it's just what we need for GPS on empeg. (he says after he's ordered his 10 units)

Except for the bit where you need to find an antenna for it. I posted about it when they became available.

hmm wonder if you could use your car antenna as an antenna... probably not but I've got an antenna I can steal out of my rand mcnally gps for the palm anyways.

No, the Motorola wants an active antenna.

Dude, if you have a Rand McNally, it's got a 12 channel receiver in it. Why bother with the Oncores at all?

I could never get the module in the rand mcnally to work because it doesn't output rs232-level signal I think was the problem.. it was CMOS or TTL or whatever signal is incompatbile with rs232.. any idea where to get an active antenna?

I could never get the module in the rand mcnally to work because it doesn't output rs232-level signal I think was the problem

It would surprise me if the Oncore weren't the same. Build a circuit with a Maxim IC to deal and be done.

I thought we were just talking about how the Palm units we just bought were RS-232 since it just used the Palm connector (which is RS-232). Was that incorrect?

jaharkes, anything new about the source cycling issue? could you verify your idea about the HJ 'cycle to the nextsrc code when the knob is held down for more than 2 seconds'?
Here's another thread where someone describes similar problems but with pacman.

Edit: Oops, I've noticed that you already knew about the thread - you did a post there... Anyway!

Well, note that in v299, if it does nuts it should start fast forwarding through your songs instead

I'll give v299 a try tomorrow.
But are you sure the changes mark has made will result in that behaviour? AFAIK, he changed the function of knob rotation, not of holding it down?

Man, at those times it's hard to keep up with the HJ releases!

Not in the slightest; I just updated my player and haven't tried it yet.

I looked through the hijack diffs, only saw some suspicious things, but haven't been able to put my finger on any specific problem yet. Considering the other report it is either a hijack bug, or something that is easy to get wrong. Maybe there is some race (f.i. between being taken out of the menu and registering the buttons).

On the bright side, I've added initialization of the map center when no route is loaded so that the map isn't as distorted, and used ellweber's suggestion to basically ignore bearings when our speed is below some threshold.

Right now I'm experimenting with routing and map drawing based on tiger/line files. Pretty tough to get right while avoiding using up too much CPU or memory. And to actually get the planned route to end up where you're going

It is great to see so much progress, so quickly. I am now motivated to see if I can get to where I can compile!

I have a couple of questions about the UI. Could you briefly explain what the "Toggle Absolue/Relative" function is doing. I have been unable to figure this out.

It would be nice to be able to save the configuration from one session to the next so that all of the set up doesn't have to be re-entered each time. I 'm guessing this is a significant undertaking that would involve writing to a disk file. Is this perhaps on your todo list anywhere. I think it is way over my head!

Lynn

Toggle Absolue/Relative
Ehh, when we're displaying time, relative is ETE, while absolute tries to give ETA, but I haven't been able to get the right local timezone offset on the empeg. It looks like it picks UTC + double the actual timezone offset as localtime, not sure why.

When displaying distances to waypoints, it doesn't make any difference for the next waypoint or the final destination, but it matters for the ones after the next, it should be obvious when you have a route loaded and are in the text display.

For a lot of these options I'm assuming that they'll just at some point get obsoleted or fixed to some default value. Possibly read from config.ini. I really don't want to add anything that writes to the disk unless absolutely 100% necessary. Another advantage of that is that it should be virtually impossible to get into a wedged state that isn't recoverable by simply pulling the plug and rebooting.

Good point regarding robustness. Perhaps parameters in the preinit.d script or a section in config.ini could be used for English/Metric, rubberband on/off and things that don't change for an individual user. Resuming the same route after a gas stop (power cycle) and retaining some of the recent track data could be helpful, however. I know this is a tradeoff!

No help on the local time offset in the Empeg. I do now realize that it has a thorough database of timezones and DST rules but that is no help here. I haven't used the text display enough to see this yet. I tend to focus on the map graphic. In the traffic we have around here the time predictions are not very meaningful

Lynn

Right now I'm experimenting with routing and map drawing based on tiger/line files.

Suspend the player while computing routes? As long as you compute a whole route one time, this doesn't seem like a huge or unjustified sacrifice.

Hmm, possibly, right now I'm routing from the destination back to our current position, considering extending the best 8 routes out of a set of 32. Ofcourse here it depends on what the scoring criteria are. But it is doing a pretty exhaustive search

It sometimes has a problem converging, especially when several routes 'bump' into each other, and looking at the speed, my guess is that most routing application probably use a more heuristical approach. Something more similar to find the quickest way between these two point over interstates, then from the found exits, do the same over highways, etc. and finish up by finding 'shortcuts'.

The current code will give at least entertaining route that although not obvious will eventually get you to where you're going Right now everything is still python based mockups, so don't expect anything soon.

(Attached is a gnuplot dump of a routing 'attempt' in progress)

It's RS232 but it may not output the voltage required for a communication over a PC serial Port. You may have to make a circuit with a MAX233 to convert the voltages. I don't remeber the acronyms for the voltages but I think a PC runs off 12V signals and most gps units run off 5V.

This GPS runs off of 12 volts. Dunno if that's what's present on the serial line, but this thing takes direct 12 volt power in its AC adapter jack.

the 5v is "TTL level" and the 12v is 'RS232 level"

I've just finished interfacing my new Oncore board to my empeg - and Wow. This rocks.

I have a couple of comments/requests;

1) Can we get the satellite signal strengths available in a display? Bargraphs would be nice - but I'd settle for textual.

2) The waypoint logic gets confused. An example - X is the start point. w are other waypoints, z is a point of confusion.

                                  X-----------w

                                                        \ 

                                                         \

                                                          \

     w---------------z---------------w

At point z, gpsapp determines that X is the nearest waypoint and starts to give me directions for the first waypoint again.

3) Can you provide a way to manually switch between waypoints?

4) I'd really like a way to toggle the textual instruction overlay. Given the limited resolution of the screen and the fact that the instructions from maponsys (by their own admission) are sometimes funky, relying on the line representation is sometimes more useful - but the instruction obliterates the bottom 20% of the screen.

5) Can you move the scale marker? - it gets hidden by the fascia bug. I figure that I'm more likely to want to glance at the scale than the co-ordinate, so may swap their positions?

6) I don't know how technically feasible this is, but would it be possible to (optionally) rotate the map so that the perceived direction of travel is up. We'd probably need a bearing indicator too, so that we keep our sanity, and somehow indicate clearly when this mode is selected (for the same reason). I figure that when driving 'by-wire' as opposed to following the text instructions, that this rotated mode may be easier to follow.

7) Is it possible to rebroadcast the NMEA messages over IRDA ?

8) Can we somehow use GPS time to set the empegs clock?


Hmmm..ok, so maybe more than a couple. Anyway...thanks!


Edit: Oh yuck. I've just notice that my lovely ascii art got screwed by the bbs software. Anyway, those lines are supposed to be linked.

satellite signal strengths
Yeah, I'm just about ready to connect a trimble sv6 (thanks again dbrashear), and noticed that without a signal strength display it is kind of hard to figure out where a good place to mount the the antenna would be.

waypoint logic gets confused
Noticed it as well, it screws up on just about any route that 'backtracks' or has an interesting twist. I guess part of the problem is how I pick the next waypoint, it suffers from things like locking on to a local minimum. I could change it to something that tries to keep track of exactly where we are and refuses to jump to a completely different point in the route. Adding something to select to the prev/next waypoints should work nicely with that.

toggle the textual instruction
Long press the down button (something like 2-3 seconds), or do you mean disabling the popup route description?

scale marker
Interesting, I just added that for debugging, hadn't even though about whether it would actually be useful. I can move it over to the other side, that's not a problem at all.

rotate the map
Guess I am too much of a boyscout. I like maps, always have, and probably always will. So I typically have a pretty good perception of where north is, and I can easily look at the small route on the empeg screen and match it up with an actual paper map.

There are a couple of problems with rotating. First of all we need to do a transformation, involving sines and cosines for the rotation. These floating point operations are impressively slow on an empeg, and I was trying to keep CPU usage low enough so that the main application (player/visual) doesn't really notice anything else running at the same time
Then the screen is only 32 pixels high, we can move the 'center' down a bit, but what we just drove might be useful in figuring out what kind of a turn we're in and such. So there isn't much we can really see in the remaining ~24 pixels worth of screen. And then we also get largely useless 48 pixels on each side, since most routes will hopefully approximate a straight line between point A and B. But still, it might be worth a try.
And last, but probably not least, as ellweber remarked earlier as soon as the speed drops below something like 1-2km/h the direction reading is useless. The next version will jsut lock the bearing to the last measurement before we dropped below some speed value. I guess it will be ok most of the time, but when making a slow turn the map might not follow in that case.

NMEA over IRDA
Shoudn't be too hard at all, depending on whether the kernel was prebuilt with irda/ircomm it is just opening /dev/ircomm0 and spitting out NMEA sentences (empeg as gpsd?).

Setting the clock
That's an area I really would like to avoid, at least for now. First of all, I managed to figure out that even when linking /etc/localtime to the right timezone file, mktime and friends are not able to give me the right local time from UTC time (it seems to be off by about 2x the timezone offset). I haven't used 'date' on the empeg yet, but I'm assuming it's not ticking UTC, but rather local time, and because it isn't using the timezone files it is a real pain to get the mapping from UTC to whatever we need right (along with the various daylight saving time rules etc.)

And then the quality of the received time. Ofcourse GPS time is almost perfect, but a lot of error is introduced after that point, the fact that I only read buffered serial data 10 times per second. The fact that the timestamp we get is from the last fix, and not when the message was sent over serial. So 'time' as gpsapp sees it is probably going to be off by at least a second. I can just as well set the time with about the same accuracy once a week by hand.

First of all, I managed to figure out that even when linking /etc/localtime to the right timezone file, mktime and friends are not able to give me the right local time from UTC time (it seems to be off by about 2x the timezone offset).

The glibc on mine at the time (which was 2.0b11, I think) was doing something weird, like opening files in the wrong place or something.

I wish I remembered what I eventually discovered, but my laptop is at home and just fell over (thank you Dell for the crappy power cable) so even if I have notes, I can't look now.

As to NMEA over IRDA, I think Kim Salo was doing something like that at the beginning of his project, actually.

toggle the textual instruction
Long press the down button (something like 2-3 seconds), or do you mean disabling the popup route description?


Disabling the popup. But like the long down mode-switch, this is something that would need to be easily toggled. Perhaps a knob-press? I like the popups on the whole, and with well-spaced waypoints (such as interstate driving) they are great. But for city-driving with dense waypoints the popups are pretty much always there, and if you're driving south...


rotate the map
Guess I am too much of a boyscout. I like maps, always have, and probably always will. So I typically have a pretty good perception of where north is, and I can easily look at the small route on the empeg screen and match it up with an actual paper map.


Me too. As a scout leader, one of the first map skills that I used to teach my scouts was how to set a map, ie align map north with magnetic north (taking the magnetic deviation into account of course ) - so that they looked 'across' the map in the sme direction that were travelling in. But I digress.

I wonder if it is possible to integerise some of the math?


I can live without clock support - it's not often that my empeg goes un-powered long enough to lose it's time. I just figured that it's a pain to set it manually when it does, and since GPS can provide it.
(1 second accuracy would be fine - we're not going to get more accurate by hand. But I can use ntpdate when I sync/load routes instead. )

I thought of one other request; Can we get the elevation reported when co-ordinates are displayed?

Well, disabling the popups was trivial, the option was already there, I just didn't have a menu entry to toggle it yet. Same deal for swapping the scale and coordinate locations. And I dumbed down the 'where are we in the route' code significantly, and added knob rotation to skip to the next/previous waypoint in the route.

Also added ellwebers suggestion to drop bearing updates below 1-2km/h, and reinitialize the map center when we get the first location update.

That was all the really simple stuff, so I've put up version 0.7 of gpsapp. btw. There is also a modified hijack-v299 which for me has fixed the "switch back to the player in aux mode" when restarting a userland application.

Now I'll finish up some soldering, and then I can start debugging TSIP and maybe add a satellite info page.

Wow man, that's great news. I'll give the modified HJ a try tomorrow.

As usual, I've got something I was wondering about: My GPS receiver (a simple GPS mouse) stopped working a few days ago (I've already gotten a replacement). It was permanently connected to the empeg's serial port. So maybe it quit working because the empeg was sending some 'weird' data to the GPS-Receiver (at least from the point of view of the receiver ;-). Is it a problem that the receiver always sends data simultaneously while the empeg sends data? Or could it be that the output from the player re-programmed the GPS-receiver's bios (or whatever)? Should I only connect the GPS-receiver if I have gpsapp running?

The kernel does send out some messages during bootup, if you don't have car_serial_rate and notify, the player shouldn't be sending anything. However I don't think either of these would 'reprogram' a receiver.
The used protocols typically use non-ascii characters and checksums to avoid such things from happening. How is that receiver powered? I might be a power spike, 12V in a car isn't really regulated, so it can be anywhere between 9 and 16, (or even worse? maybe I should add a diode to protect my gps from negative voltages).

The receiver runs at 5 Volts. I'm using a simple fixed voltage regulator. It's buffered with a high capacity cap and sufficiently cooled. I don't think that's the problem, do you?

Incidentally, the python script gets really pissy if your web browser plays with the web page at all when writing it out. Both saving page as .txt and .html in Mozilla write out something useless; When I use wget, it's fine.

I use mozilla myself and use 'save link target as html'. But yeah, the python parser isn't that pretty and easily gives up when the input doesn't really match the couple of routes I tried. There are 2 html options, for one of them mozilla also grabs the images and rewrites the html output, my guess is that the rewrite breaks the parsing.
In a way the mapsonus routes should be a temporary solution as I want to get on-line routing in gpsapp at some point.
btw. fixed the Trimble TSIP protocol, turned out to be that the ARM uses a slightly different layout for double precision floating point numbers. v0.8 has just that one little change.

With a regulator in between, receiver damage due to power spikes is unlikely. I do find it hard to believe that ascii text written to the serial port could cause permanent damage to your receiver. Perhaps the company provides a flash upgrade or windows drivers so that if something like this happens again you can simply reflash it.

In a way the mapsonus routes should be a temporary solution as I want to get on-line routing in gpsapp at some point.

Agree. I contemplated writing it in perl for about 30 seconds, then figured there were more permanent improvements that could be done (not that any of them are now done.)

What about empeg's serial port? Maybe there are power spikes or even negative voltages at the moment I power on the empeg?

The serial port is supposed to use -12v and 12v signal levels and the inputs typically have pretty high impedance, I don't think you can kill a serial input line, except when you go crazy with the voltages (25V and over..) Haven't looked it up or anything, I guess a max233 datasheet could give a 'reasonable ballpark figure'.