What exactly do you need this for? :-) Do you need an accurate absolute time reference or would relative suffice? The empeg tied to a GPS receiver will be accurate within a few seconds of GPS time (or UTC, depending on the receiver.)

There are certainly ways of maintaining sub-second resolution but I do not know how to do it from user land on this platform.

I hadn't planned on implementing the $PTNL,GGK sentence. My GPS unit doesn't generate it, not sure it's even a standard sentence. By the time the sentence has been sent, read and interpreted that sub second resolution is of little use. RMC has the time to 1 second and I'm already handling that.

I will set the empeg clock once in a while, perhaps every 10 minutes while it has a good lock. Setting it too often introduces jitter which I imagine would be bad for your use.

Cheers,

Rex.

What exactly do you need this for? :-)

First, let me say that this "clock" would be a nice-to-have, not a must-have. Also, the notion that it would be GPS synched is not a matter of necessity. It's just that it would be cool to do, definitely appeals to my lazy side, and (by installing a GPS receiver) would provide the opportunity to run more general GPS-dependent apps (like yours).

Forget 1PPS and you and Laura can just ignore that particular proprietary string (I just went looking for examples of how time is formatted and found that string). For my purposes, I would be happy if this clock could be accurate +/- 2-3 seconds over the course of the day.

You are still asking: What is it for? Well, it would be a clock visible to both driver and navigator in local TSD rallies (most of the ones we run are late afternoon and evening, so the Empeg display would be great).

My co-driver (we trade off) and I agree that while we'll keep running TSDs, we are not likely to get so serious as to buy some $400-$600 in-car calculator/clock setup. We did decide, though, that we should do something on the clock front, and it finally occurred to us that trying to do math en route using MM:SS was a losing proposition; we need to make the leap to decimal minute/second format if we are to achieve less embarassing performance.

We are trying to become a slightly more well-oiled team as we have some thoughts about running the Winter Alcan Rally in 2004 (if we're both still employed, can afford some studded Nokians, et cetera). Since we may wind up slapping some low-grade sponsorship stickers on the WRX for that, I'm thinking we may be the only folks to run the Alcan with 2 blue Empeg stickers. A GPS-synched Empeg dash clock would make it even more of a conversation piece! It's not like we'll be using it to listen to music!

If we do Alcan, we probably would buy a low-end $200 rally clock with an electrical odo interface, but it would still be nice to have the Empeg as a reference clock.

Well, that's my sordid story. Don't lose any sleep over it. I'm just trying to think of ways to make it happen as a come-along -- a footnote. Also, FWIW, having gone to the trouble of setting up an arm compile config, I'm feeling some urge to figure some of this out myself, but don't want to reinvent anyone's wheel.

Ah, understand. The empeg, gps synched should do the job nicely.

Now, perhaps you would be interested in an empeg accelerometer? This one is way on the back burner but I have built prototype hardware. In theory this could give 0-60, 1/4 mile, peak HP, g-force type info. No idea how accurate it will be in practice and the math will take some work.

Cheers,

Rex.

The Unix clock is held internally as the number or seconds past midnight, January 1, 1970. It also keeps track of the time in segments as small as microseconds, but I believe that the microseconds are kept separately, and that that is implementation-specific. Solaris can keep track of nanoseconds, supposedly, for example.

Now that is what I call cool! Definitely a gadget I have no possible need for, but I kinda want one I voted for this way back when empeg held the poll for "what do you think the serial port should be used for"

Have you tested the prototype? Or is it purely at a hardware level at the moment?

It's tested to the point of generating apparently sensible g force values, though uncalibrated. It needs work on it's on board PIC software and there is nothing on the empeg for it yet so there's a way to go yet.

Cheers,

Rex.

I've got the latest pre-init, latest hijack, empgps, and this shell script running on my empeg now.

So far I can get the gps display to come up as planned, but I've run into some desasterous snags...

A) I no longer appear to have any playlists when running the player. I'm sure my music is still there, it just doesn't know it.
The playlists menu shows -none-.

B) I can't exit to shell ... as soon as I hit 'Q' to get to shell, pre-init starts up again and reloads the empgs init script ... now I'm screwed into reloading the kernel?

Greg

Re: preinit restart

That's very weird. Before I go anywhere else, make sure that you have a developer install on your empeg.

The only thing that should ever start the preinit process is the kernel itself, unless you've got an odd script that's calling it explicity (and then I can't think of how it would actually happen).

I've got hijack installed, so does that by default give me a developer image?

I'm currently rebuilding the database via emplode to see if this fixes the playlist issue, but unfortunately i forgot it was over serial ... looks like i'll be doing this till dawn.

Re: preinit restart
would it make a difference if my original 2.0b11 image was consumer, then upgraded to hijack? should I back pedal to developer, then go up to hijack? Not even sure what I started with at this point.

Greg

Update ... rebuilding the database brought back my playlists ... but starting empgps from the picker via preinit made the playlists go away again. ... rebuilding again now.

[note later]

rebuilding DB from jemplode produce blank playlist. now rebuilding from emplode...

If I can get this back in the next few minutes, I'll go through ftp and remove the empgps init script and see what happens.

I'm a little worried at this point.
Greg

Are you trying to start empgps AND the player using the stock init? That causes problems, though I haven't seen this one.

To run empgps the player must be started with the -s- switch (which you can't do from init.)

If the player is started though the normal init and empgps is started, the serial port is not correctly programmed and the player starts to interpret the garbled GPS data as commands. I have seen it do some weird things but never anything like this.

Please let us know your start sequence.

Cheers,

Rex.

I'm just using the script you provided ... other than that, I don't know what's happening ;-)

Here's what I did, and hopefully you can tell me if I'm misusing it.

1) install hijack over 2.0b11 developer
2) install preinit v3 as per bitt's instructions
3) install empgps and picker in /drive0/bin
4) install your preinit/empgps script in /etc/preinit.d as N30empgps
5) reboot the player.

At this point, I'm presented with the proper picker, I say empgps and I get the gps display. Later I reboot, pick player, and I get no playlists. I also can't get shell access, unending loop in the custom preinit script for empgps.

Greg

That looks fine.

By reboot, do you mean power cycle (or reboot from hijack) or 'quit' the player? If the latter then you may have empgps and the player in non -s- mode running at the same time.

If you are rebooting I can't see any potential for interaction between the apps. The disk is even mounted read-only.

Early versions of the empgps/picker script did not support the shell over serial. The current one does. (It's on the empgps page.) If you have an early one, use hijack's ftp to replace the picker script.

Cheers,

Rex.

I can't speak to the playlists problem, but it sounds to me like the empgps script is completely bypassing the empeg's init. (I've never seen it, as I don't have a GPS receiver. Can someone post the script real quick?)

As far as developer/consumer goes, the only difference, I believe, is outside the realm of the kernel, and, therefore, outside the realm of Hijack. You have to install a developer image in order to be able to get to a shell. (You might also try the telnetd -- it might work with a consumer image, but, then again, it might turn out to be impossible to create the devices it requires.) Also, installing a new image on your empeg will delete your entire root partition, which means that your /etc/preinit.d scripts will go away and you'll have to reupload them, so make a backup first.

Ok, I've gone over a few things and fixed a few problems. The last problem remaining is trying to quit to shell via serial with everything as it is ... currently I'm using telnetd to get around this.

Ok here's things I've fixed since last night:
1) Replaced bad drive cable, this was causing problems for months.

2) Altered the empgps-preinit script to also mount my second drive ... this is what was preventing the playlists from showing ... it only mounted drive0

3) Built null modem cable for gps to car sled.

Like I said, all that's left is quitting to shell. Here's my modified preinit script called N30empgps

#!/bin/bash
#

PATH=.:/usr/local/sbin:/drive0/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/root/bin:/usr/local/root/sbin
TERM=vt100
export PATH TERM

mount -n -o remount,ro /
/bin/mount -n -o nocheck,rw /proc
/bin/mount -n -o nocheck,ro /dev/hda4 /drive0
/bin/mount -n -o nocheck,ro /dev/hdc4 /drive1

while :
do

CUSTOM=`picker -t 3 1 "Player" "empgps"`
if [ "$CUSTOM" = "1" ]
then
/empeg/bin/player
else
empgps
fi

done

Okay. What's happening is that your script is never calling init (which is what the author intends). But the thing about the developer init is that it will call bash when the player exits. But you're not doing that here. What happens is that there's a loop starting at the ``while'' and continuing to the ``done''. There are a couple of things that you could do. The simplest thing would be to add a call to /bin/sh right after the call to player. That way, when the player exits, it will call /bin/sh, and when it exits, the loop will start over. No matter what, you'll need to have an explicit call to /bin/sh after player, since nothing else will take care of it. You might also want to change where the loop is, so that it will remain in the player/shell pattern every time until you reboot. Then again, you might like it the way it is.

Edit: You might also want to consider exiting the script instead of calling the player app directly. That would put the empeg in its normal loop instead of your custom one.

There was also something about a `-s' option to the player. I don't see that referenced anywhere in your script. What am I missing?

Don't know about the -s, this is just the script I got from Rex for empgps, with only the additional mount of the 2nd drive. Not sure what the -s option gives me, maybe i'll try it and see what happens.

Good idea about the shell. I'll eitherremove the big while loop and just have the script exit if they don't pick the gps option, or just put a /bin/sh after the player call...

Thanks for your help!
g

That script was a quick'n'dirty hack. There is a better one here. This allows the player and empgps to be launched together as well as exiting to a shell.

The -s- option prevents the player from mucking with the serial port.

(The current script does not mount the second driver either, BTW. I will add that.)

Cheers,

Rex.

Well, you could try moving the player binary to player.orig and making player be a script that execs ``player.orig -s-''. That would allow you to use the init script as usual.

I tried using that new script but when my empeg loads with the player and empgps the player gets screwed up by accepting the stuff my gps sends to it... it will do stuff like keep switching from random on and random off, etc... I also cannot get into shell by pressing Q in terminal. It just reboots the player. Another thing i also noticed is sometime the delay for the picker menu dissapears before i can press anything and somtimes it delays fine.

-Greg

When empgps is running it takes over the serial port and forces it to 4800 baud. Could this explain any of the shell response behavior you are seeing?

Lynn

Would you be willing to post the source to this? I'd like to tinker with it if I might, put an analog compass on it, maybe let you set a waypoint or something.

Greg

Noticed that with everything up and running, with a Garmin 16 (Hi Voltage) gps, it works for about three minutes then reboots, or just locks up the display.

It does this quickly if it loses gps signal for more than a couple of seconds. If it's constant, it'll stay working for two or three minutes. Any ideas?

Greg

What locks up/reboots, the empeg or the Garmin?

If it's the empeg, could you capture say five minutes of data, zip it up and email it to me? I'll try to reproduce it here.

You can also play the log back to the empeg and see if it causes the problem.

Cheers,

Rex.

I will release source once it is more mature. I want to build the structure some while I have control :-)

1) Random player actions shouldn't happen with the -s- switch. Are you using the script 100% as posted?

2) Shell access. You can't send a Q to the player when launched with the -s- switch (see 1!) Even if you could, Q would dump you back in the script and restart picker. This is why there is a shell option on the picker menu!

3) No delay in picker. I have seen this also and haven't fixed it yet.

Gee, I replied to this post before it isn't showing up.

This is essentially what I will try. I don't know if the stock init will launch a script. It may have to be an executable. Either way it's the only way to go forward.

Cheers,

Rex.

Well, if it won't (and I think I've observed instances where the empeg doesn't like scripts, too), you could always build a tiny executable that just exec()s the real player and adds on that one argument (or explicitly just sends it that one argument, if you feel comfortable in making the assumption that the call from init will never contain an argument).

Exactly. Trivial. Smaller memory footprint than a script too.

Scripts are still easier though :-)

Hi.

Yeah, and I know I once saw a compiler for bash scripts, or should I say bash2c translator? It was pretty cool, and the footprint was small too, as long as you didn't do any of the more fancy things in the script, like "for *.jpg; do <whatever>; done" which would require directory parsing and regexp matching. But things like just checking return values, adding more commandline parameters and stuff like that were really translated into pretty small C programs.
BUT I can't find that damn thing anymore.

cu,
sven