gpsapp-0.9

Well, that last thread definitely still generated a lot of talk, but at least there was some action

I just uploaded the fruits of last weekends labor, there is a satellite signal strenght view now, only works when your gps is generating the GPGSA and GPGSV nmea sentences, or when connecting with trimble's TSIP protocol.

Also added a simple 'incar' application whose return code indicates whether we're on DC or not. Useful to conditionally run applications from the preinit scripts. i.e. to only start an application when we're in the car add '[ -x /programs0/incar ] && /programs0/incar || exit' to the beginning of the preinit script. Replace the || with && when you want the reverse.

Oh, and I noticed that I had lost the links to my hijack kernel patch, which should fix the player/aux switching when running a userland application.

I really should just add this link to my .sig.

After deciding (last Friday) that even the promising TripPilot software for the Palm sucked, I'm now interested in interfacing my Rand McNally GPS unit with the empeg and trying out this software.

Does anyone has the following information?:

- An "idiot's guide" to installing GPSApp.

- An "idiot's guide" to getting maps and directions into GPSApp.

Something I'd like to do is link the GPSApp page from the FAQ, but I usually only like to do that kind of thing if the page has those kinds of instructions on it. Any chance of the page getting updated with that information?

Also- Does anyone have tips on connecting the Rand McNally GPS unit to the Empeg? Does anyone think it's as simple as wiring the correct pins on the StreetFinder's connector plug directly to the Empeg's serial port?

As with all third party applications, installing is still somewhat difficult. It looks like the latest preinit will make things a bit easier, but you still need to create a filesystem on /dev/hda2 so that empeg-preinit can mount it as /programs0. It's also still in it's infancy, considering that I started working on it less than a month ago. There are installation instruction in the README file in the tarball, I could merge those in the page.

Right now gpsapp doesn't do 'maps', it just shows a route and directions that are grabbed (off-line) from the mapsonus website. The parser that converts the raw route descriptions is a Python script and a bit picky. Once you get it going it isn't too hard to collect a couple of routes. But I consider this method a dead-end anyways, mapsonus could remove the raw route download functionality or change the format arbitrarily. So I would like to add on-line routing at some point, probably based off of the tiger/line datasets.

I've already looked at those a bit and they are quite amusing, no one-way street information and it doesn't know about bridges and such. So, combined with my knowledge about routing algorithms (i.e. none), it definitely gives some really interesting routes that can sometimes be challenging to drive Right now I feel like I'm reinventing a bunch of wheels, and the remaining parts of car, trying to figure out how to store and index the dataset in such a way that it is actually usable for mapping, routing and possibly geo-locatiing (i.e. give an address get a coordinate).

Not sure about the GPS, does it output NMEA? If so, then you just need to figure out the wiring. Otherwise I need to hunt down the parts of gpsd that deal with the earthmate/tripmate protocols.

Not sure about the GPS, does it output NMEA? If so, then you just need to figure out the wiring.

Yes, it's NMEA. My concern was only with wiring and voltages and such. There was some discussion in another thread about whether or not it was really RS-232 because it was meant to interface with a Palm, not a PC.

Right now gpsapp doesn't do 'maps', it just shows a route and directions that are grabbed (off-line) from the mapsonus website.

That's fine with me, that's all I'd ever want anyway.

So I would like to add on-line routing at some point, probably based off of the tiger/line datasets. I've already looked at those a bit and they are quite amusing, no one-way street information and it doesn't know about bridges and such.

Right, others have come to that same conclusion. I actually prefer your current method because it uses a web-based system which can (in theory) do much better route-finding using much more up-to-date maps than something built in to the player ever could.

The parser that converts the raw route descriptions is a Python script and a bit picky.

Ouch. Any solutions for us Windows users?

My concern was only with wiring and voltages and such. There was some discussion in another thread about whether or not it was really RS-232 because it was meant to interface with a Palm, not a PC.

I used to attach Palms directly to Unix machines serial prt to work as a portable console. I don't believe that the cable had any electronics in it, so I think that the Palm's serial port works at the same voltages as a standard serial port, and, by the transitive property, your GPS receiver should be the same.

But I could be wrong.

The parser that converts the raw route descriptions is a Python script and a bit picky.

Ouch. Any solutions for us Windows users?

How about using Python? There have been Windows ports forever. And those ActiveState guys have an ActivePython, too.

Yes, it's NMEA. My concern was only with wiring and voltages and such.
Well, looking at how this guy made his own serial cable without any max233 like components, I'm guessing it is using normal RS232 signal levels.

In any case, you could always leave the TX line from the empeg (i.e. RX on the gps) disconnected, the NMEA parser never sends anything to the GPS anyways and if the GPS is really using 5V outputs that won't harm the empeg either.

Python works on windows just fine, that's one of the reasons I used it instead of writing the parser in C.

More very useful progress, thanks. This is getting better much faster than my efforts to compile Empeg code.

Could you briefly sumarize the TSIP configuration best suited to interface with GPSapp? I can see that it polls for satellite data but there is a tremendous range of output data available using TSIP (and probably the Oncore and other binary protocols, as well) so it would be quite helpful to have a starting point for the config.

Thanks,

Lynn

So should I just download and use the ActiveStates version of Python? Is it a limited demo version or is it free?

...assuming that my /programs0 creation script has been used, and that preinit.d works etc. It also assumes that you have a machine capable of running python scripts.

ftp empeg
site rw
put hack_init
site chmod 770 hack_init
cd /programs0
put gpsapp
chmod 770 gpsapp
put incar
chmod 770 incar
mkdir routes
bye

Get a shell prompt (serial or telnet if installed)
rw
./hack_init
rm hack_init
ro
quit

Make sure your config.ini has car_rate=4800 in the appropriate place.

At this point, after a reboot, GPS should be selectable from the hijack menu, and it should start with the satellite strength meter - if you see lots of pretty bars then proceed.
If not, then you need to debug your hardware - ensure that your GPS receiver is in NMEA mode, that the RS232 connections are correct (the sled is wired as DCE with 12V on pin 4, the empeg itself as DTE without the 12V - wire accordingly. Actually this RS232 stuff should have been mentioned at the top...), and that the receiver has a current almanac etc. If your receiver doesn't support NMEA then check the other protocols that gpsapp supports, change the protocol variable as appropiate in M50gpsapp and re-upload. If you use a protocol other than NMEA then the satellite signal strength meter wont work anyway, and you'll just have to see if you can get a fix reported to the empeg. In gpsapp, press down to access the menu, and then press right until you get to toggle co-ordinates. Press down again, and you will hopefully see your current position - Proceed...

At this point go to mapsonus.switchboard.com.
Under general options ensure that "Show long/lat" is enabled.
Get your driving directions to wherever...at the bottom of the page should be "raw route description". Save this as wherever.html
Run parse_mapsonus.py wherever.html > wherever

ftp empeg
site rw
cd /programs0/routes
put wherever
site ro
bye

Now when you start gpsapp you should be able to load 'wherever' as a route. Enjoy.

Question:

Why is preinit required for GPSApp to run?

I'm trying to minimize the stuff I install on the empeg and would like to avoid doing preinit.

You can either get the python.org version, which would be the canonical version, or you could get the ActiveState version. The ActiveState one, I believe, has a nicer install and has a lot of Python modules bundeled with it. It's probably easier to deal with.

Both are free.

I totally understand not wanting to run extra stuff on your empeg, even in light of what I'm about to say, but I just want to make sure that you understand that preinit doesn't reside in memory. It just finds stuff to execute and then exits, calling the normal init process (unless you use the blocking feature, in which case it resides in memory until the blocking script has exited, or if you use the mounttime feature, in which case it resides in memory until the music partitions are mounted -- no more than a couple of seconds). So no more memory is used if you use it than if you didn't. It just adds a fraction of a section to startup time.

Hijack doesn't have any way of executing programs directly. For a program to show in the hijack menu, it must be started independantly - and preinit does this for us. Theoretically you could use hyperterminal at 4800 baud to start gpsapp, and then switch cables.

I just want to make sure that you understand that preinit doesn't reside in memory.

I understand that, but anything I do with preinit is lost as soon as I apply the next .upgrade file and I have to do it all over again. That's what I want to avoid. It's getting increasingly difficult to remember what changes I have to re-apply to the player every time a new version of the player software comes out.

Hijack doesn't have any way of executing programs directly.

That's the one thing I'd like to see changed the most. Hence the new thread I just started in this forum.

So store all the stuff you add to / in /programs1 with a .sh script that will recreate your changes.

I meant to automate this, but given that I've upgraded one time, it hasn't really been worth the effort. The 50 other things I have to do that have some bearing on my life at this moment sort of win

Do you get more frequent alphas to test, or are you just worried about when it does happen?

Right, others have come to that same conclusion. I actually prefer your current method because it uses a web-based system which can (in theory) do much better route-finding using much more up-to-date maps than something built in to the player ever could.

I'm in Rockhill Furnace, PA. My cell phone has no digital service, meaning no data service. I don't have my laptop. I want directions to, say, State College (I know how to get there, but ignore that).

The roads haven't changed in 40 years, or if they have, the old road which was bypassed is still there.

I can have no data, because I didn't anticipate I was going to do it, or I can have n (currently 2) year old Census data with some errors and some omissions.

I think I want exactly the opposite of you. I should find some time and be a sucker, I mean, volunteer to do some work for Jan...

You forgot /etc/preinit.d/M50gpsapp in the instructions, although you are mentioning it later on

Also car_rate=4800 is not necessary, as only the player pays attention to that option. And as there is only one serial port, the player should just keep it's hands off when gpsapp sets up everything for the gps. Which is why init has to be modified to start the player with -s-, and it is possibly advisable to have notify=0 in config.ini.

The M50gpsapp script uses 'incar' to check whether we're actually running in the car. This functionality could probably be moved into the next release of preinit (pretty please ). Or I could let gpsapp do the incar test and simply exit when we're on AC, but having a separate test is probably more flexible. Although the players reaction to various GPS messages when I accidently boot without using hijack to force car mode is definitely suprising and annoying.

The signal strength meter definitely works for TSIP. The other currently supported protocols (TAIP and Garmin) will never support it because I cannot find any reference to signal levels or satellite positions in the published protocol documentation. Considering the fact that trimbles can be reflashed to use TSIP, and Garmins have working NMEA output I guess those two protocols can be dropped at some point.

I just came up with a simple idea to test a whether a serial port is 0v/5v or -12v/12v. Hook up an led and a 1K ohm resistor so that it lights on the negative 12 volt of the tx line. If the led doesn't light, it's probably 0v/5v.

TX o---WWW----|<---o GND

Yeah, I've been thinking about what Tony said - and pretty much decided that my needs were orthogonal to his too.

Give me a map and tell me where I am, and I'm a happy boy. Thus routing isn't a major concern - if I have access to state maps showing major roads, and a few selected city maps with more detail, then I'd live with that. It'd be great if I could search a list of road names within a map, and then gpsapp would highlight that road, being able to narrow down to a given block would be fantastic. I'll drive around one ways streets when I have to

Given the limited resources on the empeg - limited memory for holding map data, limited display, limited processing power (wrt to floating point ops anyway), and limited input UI, we are (or should I say Jan is ) going to hit a limit as to what can be achieved. But we can dream..

I think I reinitialize almost everything on startup and whenever I detect that the receiver has lost power. Basically double precision LLA, ENU velocity, etc. I played a bit with the various messages, and finally came up with a 'state machine' that seems to work reasonably well.

Sometimes it still fails to get satellite signal and position updates during startup when the receiver is trying to find which satellites are visible. Not entirely sure why as I couldn't test any of this on my laptop. The USB serial dongle support broke in recent Linux kernels, so it was a bit hard to debug all of this.

Whenever it seems to happen I first try to exit back to the hijack menu and go back to gpsapp, this triggers the initialization sequence and it typically recovers. If that fails I pull the sled and wait for a minute or so until I actually start gpsapp, by that time the receiver already has a lock.

Give me a map and tell me where I am, and I'm a happy boy.

Truthfully I usually need neither. Maybe an idea of where the place that I'm going *is*. Autorouting will generally be more useful to my wife than to me. She won't preload routes, I know it...

Looking at the maps, or maybe panning to elsewhere, is probably the most I'll ever strictly need myself

No longer. preinitv6 now supports putting your startup scripts in /programs0/preinit.d. Then all you'd have to do is reapply hijack, reupload preinit (via FTP is fine), and recreate the /programs0 and /programs1 mount points (FTP is also fine for this) upon upgrade. It's not as nice as what you're looking for, but your scripts and programs won't get deleted.

reupload preinit (via FTP is fine), and recreate the /programs0 and /programs1 mount points

That's the steps I'm trying to avoid. There's too much to do every time I re-upgrade.

Are the mounting points created by simply running your "install.ftp" script? If not, how do I create them? I couldn't find information about this in your "To install from Windows" step by step guide at your homepage.

In reply to:

---

Right, others have come to that same conclusion. I actually prefer your current method because it uses a web-based system which can (in theory) do much better route-finding using much more up-to-date maps than something built in to the player ever could.

---

Since I live in germany, I couldn't use this feature. gpsapp would then be useless for me. That would be a pitty.

couldn't preinit do an "if not exists /programs0 do mkdir /programs0" and then attempt to mount? that then only leaves uploading preinit as the only step after an upgrade.

Are the mounting points created by simply running your "install.ftp" script?

No. I suppose I could add them, but you also have to run a ``mke2fs /dev/hda2'', to, in Windows terms, ``format'' the hard drive partition, which I can't do via FTP (or is there arbitrary execution via Hijack's FTP server?). But you just have to ``mkdir /programs0'' and ``mkdir /programs1''. Mount points are just directories, plain and simple.

couldn't preinit do an "if not exists /programs0 do mkdir /programs0"

I tried to do that and it failed. There's (soon to be) more information in the preinitv6 thread.

It would have to remount / as writable and such. I would really advise against doing anything like that in such an ad-hoc fashion, especially during bootup when you're not 100% sure the power is going to be stable. i.e. when I start my engine the voltage dips enough for the player to restart. And for various things like telnetd you'd still need to create devices in /dev etc.

It is far better to have a script on f.i. /drive0 that can be run which 'restores' all local hacks and run it from the serial console after upgrading.

Something trivial like
rw ; mkdir -p /programs0 ; mount -text2 /dev/hda /programs0 ; /programs0/setup.sh ; ro

And have all the customized things run from setup.sh.

On the other hand, allowing applications that don't really need to have a specific location to live in f.i. /drive0/usr/bin and have an /sbin/hijack (preinit) that can start executables without requiring a shell (requiring a developer image) will make installations somewhat easier.

There's too much to do every time I re-upgrade.

You've already got to sit through a serial upload of Hijack that takes a good few minutes and you can't also sit through a script that'll take about 2 seconds? (ftp empeg < install.ftp)

Okay.

It would have to remount / as writable and such. I would really advise against doing anything like that in such an ad-hoc fashion ...

fsck'ing / isn't a huge deal, and we're not really modifying any data other than dirents, so I wasn't too concerned about that.

and you can't also sit through a script that'll take about 2 seconds?

It's not the time, it's just the additional steps I have to remember. Each time I upgrade the player, I already have a bunch of stuff to do and I keep slipping farther and farther away from being able to remember all of it each time.

If we had that Hijack feature I talked about, I could put everything in drive0/var somewhere and would never have to do ANYTHING on a re-upgrade.

Hey Tony, we're talking the JEmplode wishlist thread about simplifying 3rd party app installs to a point and click thing which should at least ease this concern.

But what you are asking for here is a technical challenge - unix and linux systems usually only pass control to userland once - via init. init is then responsible for spawning whatever is needed in userland, and the userland/kernel interactions at that point are fairly limited to system calls from userland.

The problem here is that the empeg-supplied init is locked down to only do one thing - start the player. And always tells the player to hog the serial port. Even if hijack were able to start arbitrary userland applications, gpsapp would still need to start before the player in order to work (and then the player wouldn't) . Now this again could be solved in hijack - we could (optionally) remap the serial device (/dev/ttyS0) to a dummy device that does nothing but dump the data, and then tell gpsapp to use /dev/ttyS1 that would really point to the port. This potentially would allow hijack to remap the port at will from a menu item - allowing either gpsapp or player serial messages to be using the real port at will. If my serial port expansion plans come to any fruitition then it would use a scheme similar to this - but I digress.

What would pretty much solve the init issue is if the empeg guys included preinit in the distribution. Only hijack kernels would use it - so it would be transparent to non-HJ users. And whether the player uses the serial port should be a config.ini setting.

Once that is done it is comparatively easy to get JEmplode (or some other software) to deal with the rest of 3rd party app installs.

What would pretty much solve the init issue is if the empeg guys included preinit in the distribution.

But wouldn't they be loath to do that, because if preinit could execute arbitrary code from one of the drives that doesn't get wiped on a .upgrade, then you could theoretically render your player unbootable in a way that .upgrade wouldn't fix? A builder image would, but a regular .upgrade wouldn't.

Empeg guys, any of you listening here? Got any ideas?

if preinit could execute arbitrary code from one of the drives that doesn't get wiped on a .upgrade, then you could theoretically render your player unbootable in a way that .upgrade wouldn't fix?

No, because preinit will only be called by hijack kernels. It exists as the file /sbin/hijack, which hijack will try to execute in favor of /sbin/init. The default kernels won't do that. Hijack will fall back to /sbin/init if /sbin/hijack doesn't exist. Both kernels will then fall back to /sbin/sh if init doesn't exist; that's a standard feature of all(?) Unix kernels.

Interesting.

Hmm. Empeg guys... Listening?

It exists as the file /sbin/hijack, which hijack will try to execute in favor of /sbin/init.

Wait wait wait.

What if hijack were changed so that preinit could exist somewhere specific on Drive0 instead? Then one wouldn't have to re-install preinit on each upgrade, and the empeg guys wouldn't have to get involved.

Then if your mountpoint stuff could somehow be worked into a startup script, preinit could be a painless thing. Then all add-ons could go onto Drive0 and nothing would never have to be reinstalled after a .upgrade.

It's not the time, it's just the additional steps I have to remember. Each time I upgrade the player, I already have a bunch of stuff to do and I keep slipping farther and farther away from being able to remember all of it each time.

Why not just add the details to the FAQ and then refer yourself to it when you need to do an upgrade...



(I tried so hard to resist it)

/drive0 isn't mounted during boot, so you cannot have preinit on /drive0 and start it before /sbin/init mounts the drive.

Why not just add the details to the FAQ and then refer yourself to it when you need to do an upgrade...

Oof!

Only the root parition (flash) is mounted at that point, and the player app mounts /drive0. /programs0 is mounted through a preinit script.

the player app mounts /drive0

Yuck. How much time would it add to the boot process to have the kernel mount /drive0?

Theoretically speaking, not much. But, It's Not The Correct Thing To Do(tm). I don't know whether that might affect the player in any way (the players mount command would 'fail')

Is it me, or are we holding the same conversation in 3 different threads now?

How much time would it add to the boot process to have the kernel mount /drive0?

Have the kernel start mounting other filesystems before it passes control to init.

EVIL!