Hmm.. I have tried this many times and cannot get it to load correctly. (Or at all for that matter)

-Greg

Was the player fully exited at that time? I am having serial problems but only when the player is mucking with the port.

Curious as to what the player is doing with the serial port, at least once it is up and running.

Since i went to the trouble of building the armtools setup and setting a bunch of symlinks to the tools, I decided to try to cross-compile the gps3d/gps that I have running on Redhat/Windows -- see if gpsd would run alongside the player. Unfortunately, I got some assembler "invalid option -Qy" error from two object files that I can't seem to track down. I might try again tomorrow. FWIW, the source for that is about 300 lines, not bad, I think, for what it does.

Once you do let your source out, I'd like to look at it WRT creating a very simple time set and time display extension (a full-screen HH:MM:SS display).

Thanks,

The player will be listening to the serial console waiting to be sent serial commands.

It might be worthwhile asking the empeg guys to add a config.ini option to their next release to disable the player listening to the serial port after it starts. Not sure whether they would be forthcoming... the other option is to start the player with the -s- flag (I think that is the correct flag)... but you would have to modify the /sbin/init to do that or make preinit start the player software itself.

Cheers

Kim

Rex,

After much experimentation and only reloading the player once I have gotten to where I get this on the boot message.

change_root: old root has d_count=1
Trying to unmount old root ... okay
: command not foundel memory: 4k init/etc/preinit.d/init_empgps.sh:
: command not found_empgps.sh:
: command not found_empgps.sh:
: command not found_empgps.sh:
': not a valid identifiers.sh: export: `
: command not found_empgps.sh:
mount: you must specify the filesystem type
mount: you must specify the filesystem type
Usage: mount [-hV]
mount -a [-nfFrsvw] [-t vfstypes]
mount [-nfrsvw] [-o options] special | node
mount [-nfrsvw] [-t vfstype] [-o options] special node
A special device can be indicated by -L label or -U uuid .
: command not found_empgps.sh:
'etc/preinit.d/init_empgps.sh: line 24: syntax error near unexpected token `
'etc/preinit.d/init_empgps.sh: line 24: `fi
empeg init 0.8
I see this is a developer image!

My script is just a copy of the content of your message. I have made empgps and the script executable and have removed all other scripts from /preinit.d. I am sure that there is some obvious Linux knowledge I am missing but don't know what it is yet! Any clues would be great.

Thanks,

Lynn

What does the content of the script look like?

Some common things:
Is the #! line at the very top of the file? Is it correct?
Do you give the full path to the empgps program in the script? I doubt a $PATH variable is populated at preinit time...
Is the location where empgps resides available at preinit time (ie mounted?).

/Michael

The script came from Rex's post back about 7 posts in flat mode(copied here).

#!/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

while :
do

#if grep -q '0 (AC Power)' /proc/empeg_power
#then
CUSTOM=`picker -t 3 1 "Player" "empgps"`
if [ "$CUSTOM" = "1" ]
then
/empeg/bin/player
else
empgps
fi
#else
# /empeg/bin/player
#fi

done

The syntax is not clear to me but perhaps the problem will be obvious.

Lynn

Looks OK on a quick glance, if empgps is in one of the directories listed in the PATH statement.

Did you save it in Unix format (linefeeds), if you work from a Windows machine? It could be a question of the #!/bin/bash line (and all others) having an extra "carriage return" character before the "line feed" character that Unix uses to separate lines...

/Michael

Michael,

Thanks for your insight. That was the problem. Once I removed the carriage returns it all works as expected. What would you recommend as an easy way to edit these files on a PC, that can be configured to save without the CR?

Thanks again, I am off to put it in the car!

Lynn

I like UltraEdit32 when I need to do this on a Windows machine (have both Windows and Linux machine at home), http://www.ultraedit.com It's a pretty good and complete text editor.

For a smaller utility to just convert an existing file, dos2unix (and unix2dos); can be found for instance at http://www.bastet.com/software/software.html

/Michael

I dont use Ultraedit buit JEdit.

Sweet. Thanks for putting this together. I've been hoping someone would for months now. Everything works great except for the Sats which shows that there is either 1 or 0 when I have at least 3+ showing on my gps (I have a yellow etrex with a data cable). Anyone know how kim's gps stuff is working out?

Thanks for your troubles,
Greg

Rex,

Thanks for your efforts. This is a great start and even seems to have knots to mph conversion. I have it working and installed and here is a one handed, one eyed (no passenger available to help) picture of the display while in motion



My GPS will allow setting of the NMEA output rate so I am anxious to try higher serial port rates when you get to it.

Thanks again,

Lynn

Very Nice. So is any one going to put together a documentation package with step by step instructions for us less capable??

How about TINI mentioned in this thread?

It will get a lot simpler soon. I am the first to admit that it's a PITA at the moment.

Cheers,

Rex.

That's great!

Yes, the speed is in MPH.

Cheers,

Rex.

I don't know what the player is up to but the jist is that I can't set the port speed without messing the port up completely. Might be a problem with two applications 'owning' the port at once but I don't get any errors.

Once I have a solution to the timezone problem I will add time setting support. I have an idea...

a full screen time display would be simple to add. All it needs is another 'page' handler added.

Cheers,

Rex.

Alas -s- didn't seem to work for me.

Now you have GPS code also, right Kim? Are you running with the player?

Cheers,

Rex.

What was the fix type? If it's 3D then the receiver is outputting a bad value.

The sats field shows how many are being used in calculating the solution, or at least what is being reported. This is an optional field and may need not be correct.

Cheers,

Rex.

sorry I never got around to playing with it with the player... and my empeg is in a sorry state at the moment until I fix the display problem I am having... (waiting for some fuses to be delivered)

Cheers
Kim

I use "Programmer's File Editor (PFE)" for editing Unix style text files on the PC. It's not too big, works well and is free It can be a bit hard to find these days as it isn't being developed anymore, but I can send you a copy if you want.

Again, vi. (Actually, try Vim.) Always vi.

Hmm, well I tried -s- again and it works! Might have been one of the other beta players I had running last time I tried.

Anyhow, I have put an updated picker script here that allows the player and empgps to be launched at the same time.

I was pleasantly surprised to find that the remotes still work when in empgps so I can change the volume or track from my steering wheel remote (Kenword KCA-RC700) while the GPS display was up.

Cheers,

Rex.

Cool works great. For some reason I can't get empgps to read my gps info in my car. At home I have my gps (etrex) plugged straight to my serial port from the etrex data cord. In my car I had to use a male to male gender changer to be able to plug the car adapter's female end and my etrex data cable's female end together. Is there something l need to set in my config.ini to make the empeg's serial a different rate?

-Greg

You will need a twisted (or null modem) male to male. Pins 2 and 3 are swapped on the sled's serial connector. (Also the handshake lines, but I doubt you care about those.)

The player's serial rate doesn't matter.

Cheers,

Rex.

Hi.

IIRC, the player completely ignores the handshake lines completely anyway.

cu,
sven

I'm working to get my GPS hardware working, and after that's OK, I'll be happy to help developing

Marius (Escort Cab + Mark II)

Looking good, Rex. Thanks again for getting this under way. I have found that I can run other applications (that don't need the serial port) by including them in the picker script. Viewer, for example, lets you look at the picker script!

Please keep us posted as if you get any additional functionality running or want any test feedback.

Lynn

a full screen time display would be simple to add. All it needs is another 'page' handler added.

A small footnote and a query of sorts. After some discussion with my co-driver about navigational mathematics, it's pretty clear that what we want is not an HH:MM:SS clock but actually an HH:MM.MM clock. Not sure if this is the correct expression, but I'm using it to signify a 6-digit clock that displays minutes to two decimal places.

Looking at the NMEA $PTNL,GGK sentence, it has decimal seconds (to two places), but the notion of somehow calculating decimal minutes off the ss.ss output as it come off the GPS seems like a ridiculous idea.

Absolute precision isn't essential, so even calculating a rough decimal minute (and HH:MM:SS of 12:31:14 becomes an HH.MM.MM of 12:31.23) in the display code would probably work.

I guess my question is whether there is any ability of the system clock to provide a more precise value that would help feed the display and smooth it out so that the decimal counter actually follows the more precise time in decimal minutes?? From what I see, basic Unix/Linux clock is simply HH:MM:SS. If there is any underlying facilty with more precise time, I don't see it. Any inspirations?

Thanks,

I believe that the NMEA sentence you have referenced is a proprietary, manufacturer specific message. In this case it is defined for Trimble navigation Ltd. (TNL) receivers, which happen to be what I have as well. However, I would caution against using this for any application that you want to have wider applicability, as most receivers available to the cost conscious user will be restricted to the common, generic NMEA messages. Some receivers can output time to 1/10 second in the generic messages, such as $GPGLL or $GPRMC (...,hhmmss.s,...) but you can't count on this for all receivers.

These time stamps are actually the time for which the position fix is calculated (in the past) and do not represent the time at which you actually receive the message on the serial port. You can make an adjustment to compensate for the typical time required to calculate the solution and communicate it to the receiving device but you will not achieve sub-second accuracy that way. The only way to get sub-second accuracy reliably would be to use the pulse-per-second output available from some receivers, but, as previously discussed above, that would reguire a discrete signal input and probably an interrupt on the Empeg, dedicated to achieving reasonable accuracy.

Lynn