As far as I know, it does whatever is normally built into that version of Linux. Empeg guys, do you have a definitive answer on this?

Isn't DST compensation handled by the OS?

Sorry if this has been covered before, but wouldn't the timezone screen in the empeg just provide a user method to change the timezone parameters to the OS - or has this not been built in.

PeterK

It certainly looks to have all the required stuff... (under /usr/share/zoneinfo)

/Michael

That's great. So now we can use GPS to make it accurate without requiring user intervention! Any takers?

Lynn

I have +12 on pin 4 of the DB-9 serial port connector on my car sled.

Weird. I just triple checked and I don't get anything on that pin. I have the rest of it wired OK (I get NMEA output into the empeg with TX, RX, ground from serial and power from the amp line). Thanks for the offer of help, but I think I will just leave it wired to the amp line.

-Mike

Any chance of someone posting a demo? ; ) I think i'd be fun even to just have minor gps info right now, especially since my gps hasn't been used for months and it begging to be used.

-Greg

That's great. So now we can use GPS to make it accurate without requiring user intervention! Any takers?

It would take an injection of, well, *something* to turn me back into any sort of programmer, but I may try to follow along with whoever does this. My inferior motive continues to be a big, plain HH:MM:SS clock that would update from a 1pps signal (for an in-dash rally clock -- no need to run with the player, could run off Hijack in place of the player).

On a quick and dirty basis, I even thought of a script that would pipe time stamp to "date" to keep clock synched on a settable, periodic basis (once every 10-30 minutes would work for me). I found an ARM date binary that worked, FWIW.

I know that over in some of the other GPS threads, yn0t_ and others mentioned the program gpsd. (Not sure who is maintaining this now. I found a "gps3d" at http://www.mgix.com/gps3d/ with sources. Not sure if it is branched from the original gpsd or what). Anyhow, not sure what the proc/memory footprint would be for one of these, but I wonder if it would be feasible to use? The advantage would seem to be that the daemon would already handle the serial interface, leaving you only to worry about fetching data from the daemon and displaying it (or updating clock or...). One other advantage, I think, would be that a gpsd/gps3d could handle requests from multiple clients, so if you wanted to run a nav screen along with a clock setting program along with....whatever, you could mix and match --- not have to stuff everything into one binary that has the serial port locked.

(Of course, the gpsd may, relatively-speaking, be a pig, so this tangentential thought may not be the right lean-and-mean approach)

Hi.

I would guess that you have a rather old MkII (not MkIIa). Some of the first empeg MkIIs had a problem with the serial port wiring on the car harness, which resulted in a missing power supply to pin 4 IIRC. Not too sure what the actual problem was, but it was surely either ground or +12V which was not connected.

cu,
sven

The moulded serial cable built into the harness didn't have enough pairs in it, so the +12V lines on the serial never got hooked up. I wrote to the BBS quite a long time ago saying what the differences were between the early and later Mk2 harnesses were. I'll try and look up the post for you.

Found it! It's here. The +12V wire on the serial cable just comes off the Amp remote line anyway, so there is no difference between how it is on the later empegs and how you are doing it really.

I started this thread with the hope that someone with programming skills (that I lack ) would help to get a demo going. There is a mockup of a screen view at the beginning of the thread along with a definition of the interface requirements attached to the second post.

I will do what I can, but I need help to get to the point where I can compile an application. Linux is new territory for me!

Lynn

Time setting from GPS is a great fringe benefit, but the original idea here was to develop a simple interface for a generic GPS receiver to display Position, Velocity and Time. This would form the basis of a diagnostic capability for an Empeg/GPS system in advance of having the software for a full blown navigation system available.

Once we have time available then using it to limit the drift of the Empeg's time keeping could follow. Not all receivers provide a discrete 1 pps signal and getting it into the empeg would involve "borrowing" another input, such as the Headlight Sense or Mute. By using the time stamps available from the serial data stream with a little bit of calibration we should be able to have time accurate to within a second.

Anything you would care to contribute to this cause would certainly be welcome.

Lynn

Time setting from GPS is a great fringe benefit, but the original idea here was to develop a simple interface for a generic GPS receiver to display Position, Velocity and Time. This would form the basis of a diagnostic capability for an Empeg/GPS system in advance of having the software for a full blown navigation system available.

I didn't mean to suggest a change in your focus. I was just thinking the underpinning of what you describe and that of my HH:MM:SS are very similar -- grab data, format, display. I saw it as an easy "come-along" opportunity. Also, I could see running a navigation GPS display like yours indefinitely -- it might be enough for me versus a full-blown nav system.

Once we have time available then using it to limit the drift of the Empeg's time keeping could follow. Not all receivers provide a discrete 1 pps signal and getting it into the empeg would involve "borrowing" another input, such as the Headlight Sense or Mute. By using the time stamps available from the serial data stream with a little bit of calibration we should be able to have time accurate to within a second.

You are right. Plus, once I think about it I'd guess there are other issues with 1pps like kernel/clock requirements.

Anything you would care to contribute to this cause would certainly be welcome.


My few achievements in life are due to, well, theft (of other folks documents, programs, whatever). I did poke around for developer info on RioCar.org before to see if I could grab a clue -- get a compile environment set up that would work. In this case I would tend to attack this from the app layer down. First thing I'd see if I could build something -- maybe stolen from viewer? -- that would throw dummy values up on the screen, then work out how to fetch those values (adding something like a heading "hold" makes that a bit more complex) , and consider the best way to get them (I'd still look at the feasibility of using something like gpsd -- I'm lazy!!)

I am setting up another Linux laptop that I hope to be able to use for stuff like this while travelling. I'm not sure how far I'll get and how fast (I can't explain it but my work is actually starting to get busy), but I am motivated to learn enough to produce something for my own amusement. The last programming I did was ~1995 in Clipper 5.3!

Not to discourage further discussion in this thread, but at some point if some of us are able to take the appropriate baby steps I suppose we could communicate off-line in e-mail?

In reply to:

---

The last programming I did was ~1995 in Clipper 5.3!

---

Well, you're way more current than I am. I was pretty good at CDC 6400/6600 assembler in the distant past! Hardly helpful here.

I agree that "Viewer" would be a reasonable starting point. I am stuck at trying to figure out how to structure a Cygwin compile environment. A model of how to do this would be a great help to getting started for me. Does anyone have a sample/model/tutorial for how to get C source compiled to run on the Empeg using Cygwin, in language that is understandable to a non-Linux/Unix experienced non-programmer? I need paint-by-numbers or connect-the-dots

Lynn

Unfortunately, I found it easier to install a Red Hat based distro on a spare computer and install Mark's precompiled toolchain.. Didn't succeed totally, as I couldn't even compile the empeg kernel, so I guess I'll, try my hand at application code instead.. If you do find anything that helps out let me know.. I'm interested in getting a cygwin setup working as well..

Here's the files I've gotten so far:

Roll-your-own toolchain:
armtools-empeg-skeleton.tar.gz
Requires:
binutils-2.10.1.tar.gz
gcc-2.95.3.tar.gz
glibc-2.1.3.tar.gz
glibc-crypt-2.1.tar.gz
glibc-linuxthreads-2.1.3.tar.gz
linux-2.4.3.tar.gz

And they don't work.. following the instructions in the skeleton sorta works, but the binutils code doesn't even compile.. Was fun trying though..

but the binutils code doesn't even compile.. Was fun trying though..

Well, I started the make on this, and it looks to be running, but I'm not going to stay up to see if it finishes.

Lynn, FYI, I loaded that gps3d on my file server that has a GPS attached. Then I ran the Win32 client "gps" on my laptop (pointed to file server IP) you can set it to raw NMEA output and it looks just like I'm listening to NMEA off a serial port. If this toolchain make works, I'll grab the source for gps3d/gps and see if I can compile for Empeg. If that works what I'm thinking that there is at least some serial-reading and NMEA-spewing code in there that could be appropriated even if you don't use the whole daemon.

Nap time.

Is this the kind of thing you are looking for? It's not ready for prime time but since this keeps coming up, here it is!

It does not currently try to set (or use) the system (empeg) clock but will once I figure out the timezone stuff.

I've got some other GPS code from another project I'll be moving in there as time permits.

Cheers,

Rex.

Rex,

Thanks for getting this going. I think it will be just what I was looking for, once I can get it to run. I have been unsuccessful so far.

I am using rev2beta11 and have tried with both Hijack v220 and v246.

I have tried it in the /bin and in the empeg/bin directories. I have made empgps executable (chmod 755 empgps) and the result of running the application is a blank screen. I have tried reconnecting at 4800 baud and still no response from or to the serial port. I can reboot via HTTP/Hijack and do not see any new entry in the Hijack menu.

I also tried using "Picker" to execute "empgps" but to no avail. Is the script required and if so where should it be placed in the directory structure? I tried using picker to start up "Viewer" and that doesn't seem to be working either so I guess I am missing something basic.

If you could point out where I am going astray I would appreciate it.

New input!!! I have empgps running but with no input from the serial port showing up on the display.

Thanks,

Lynn

Try this:

From a command prompt run empgps.

Press and hold the knob until the hijack menu appears. empgps should be in there. Select it. The serial port should then switch to 4800bps and display the first status page. This will show all zeros initially. Hook up the GPS.

empgps will only appear in the hijack menu while it is running. Rebooting will remove it.

I will put a picker script together to help use this. However, once I have the serial interaction with the player solved it can simply be started at boot (via preinit) and left there.

empgps will only output on the serial port in response to the ASTRAL power up prompt from a Tripmate receiver. Otherwise the data is strictly input.

Cheers,

Rex.

Thanks Rex,

I figured out how to get empgps started and I have the display showing with all zeros. I have GPS $GPGSA and $GPRMC data at 4800 8-n-1 visible on a terminal but no sign of it on the Empeg. Is there something else Tripmate specific going on? I am using a Trimble receiver that has always put out clean NMEA data in the past.

Once this is working I guess we need a way to get it started in the car without going to the shell, preinit should do it.

Lynn

Great. $GPRMC is all it *needs*, the tripmate init is purely optional.

Try feeding a RMC sentence directly from your terminal program. Here's one I have handy:

$GPRMC,135356,A,4203.6470,N,07123.4961,W,61.308,294.3,180302,15.8,W*78

This is from a tripmate but a Trimble should be similar. (Perhaps my error detection code is too strict though. If this sentence works and yours doesn't, please send me one.)

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

picker, along with preinit, would be the way to go for now to start it in the car. You can't simply run it at background at init time until I have the serial problems fixed.

I'll come up with something for picker.

Cheers,

Rex.

Rex,

My mistake. I had NMEA checksums turned off. It is running now.

If I put the picker script in the preinit "start at boot" directory, where will picker show up in the user interface in the car and how do I kill the player while it is running?

Lynn

Yep, a checksum is needed. That should be optional but currently isn't. I'll put it on the todo list.

picker gives a boot menu to allow, in this case, either empgps or the player to start. Once they can coexist preinit will put it in the hijack menu and it can stay there.

Cheers,

Rex.

Sorry if I seem clueless, but where should the picker binary be located and when and where will its boot menu show up? Also, for your to-dos, would it be possible to have 9600 and 19200 baud as an option. I am only seeing updates every 2-3 seconds at 4800. Is the Tripmate stuck at 4800?

Lynn

Hrm. For some reason I can't get into Hijack when the player isn't running. Im running Hijack v246. Any ideas?

-Greg

I have found that if I run Rex's "Disp" first then "empgps" from the shell and then hold the knob down, Hijack will start without the player and show empgps at the end (or beginning) of the Hijack menu. I can't seem to get the format right for the "picker" script yet to be able to strart it without the shell.

This is also with 246

Lynn

It seems with OBD2 it is possible to acquire vehicle speed easily, however, both OBD2 and GPS require use of the serial port. A shame there is not two serial ports in car. :-(

Calvin

Here's how to get picker set up to launch this version:

1) Install hijack and preinit.
2) Copy the script at the end of this message to /etc/preinit.d/init_empgps.sh. Make the script executable with:
chmod +x /etc/preinit.d/init_empgps.sh

NOTE: This script will need another mount if you have two drives. I don't know which partition gets mounted in this case so haven't included it.

3) Make a directory /drive0/bin.
4) Put empgps and picker in that directory. Make them executable.
5) Make sure the binaries and script are executable!
6) Reboot.

If something goes wrong you will need to reinstall the player software from an upgrade package.

Note that the script does not allow other preinit scripts to run once it has.

Upon rebooting you should be presented with a menu for 3 seconds. Hit the top button to launch the player (or just wait) or the left button to launch empgps. Once empgps is loaded, press and hold the knob to bring up the hijack menu and select empgps from there.

Hope that helps!

I will add a baud rate selector. It may not help with the update rate though, on the units I have used that was fixed.

Cheers,

Rex.


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

I have seen that. Try exiting the player with the screen on, or if you already tried that, off.

Alsp try launching it at boot time. Take a look at the picker script I just posted.

Cheers,

Rex.