There seems to be a lot of effort going into a full-blown navigation system over in the “Projects” area. I would like to take an interim step that would allow us to interface a generic GPS receiver to the Empeg display. Fortunately, there is a nice generic ASCII serial protocol that is available on almost all GPS receivers with I/O.

This could provide several useful benefits.

1) Allow for debugging the hardware interface and GPS in-vehicle installation.
2) Provide a useful diagnostic screen for long term use with a navigation system.
3) Give us the best possible source of Position, Velocity and Time in-vehicle for setting your clock and calibrating your speedometer.

The attachment is a brief reference specification that describes what is required in MS Word format. The resulting display would look something like this.



I think this could be included in Hijack or written as a separate application, similar in complexity to “Viewer” (which is what I used to produce the above mock-up). Thanks to John for this handy contribution.

I would be willing to fumble through this but I will need a lot of hand-holding. I do have Cygwin installed but am lost about how to get Empeg code compiled, I am not skilled in this art! If any of you would be willing to help me get started or better yet produce a primitive shell for this job that I could then expand that would be very welcome. A reference to a tutorial would also be helpful, I am really a hardware guy and seem to be slow to pick up this new skill.

The attachment fell off!

Looks like a good idea, and would probably get me around to wiring my GPS up (once I fix my in car serial port )

Mark hinted at allowing Hijack to launch programs instead of needing every program running to be in the Hijack menu. Hopefully someone will help him to get this working, as this has been my biggest stumbling block so far with adding some simple things.

My current highest wish is a compass, reading from the GPS and displaying heading, small numbers towards the edge of the display and large letters that can be seen from a distance without focusing.

Marius (Escort cab + Mark II)

You can try my patch in the other thread... still not perfect... but it could do what you are after...

Cheers

Kim

Awesome, definitly a step in the right direction.

This made me realise 2 seperate things are needed as well. 1 section that loads a program on boot from hijack, and the second that simply puts items in the hijack menu, then calls the exec when the user selects it. Should be pretty simple since Mark said the only problem he had earlier was launching programs.

Hmm... I might work on that if I get stumped going much further with trying to get things executing from the kernel properly...

You are after something like...

[launcher]

Viewer=/drive0/bin/viewer

Nav System=/drive0/bin/gps-nav

Process List=/drive0/bin/blitps -aux

where the left of the = is the menu label and the right is the executable to call... (with parameters assuming they could be got working...)

I will try and get a little further with my launch from kernel code before I give up and take this path instead... I would like to work out what I am doing wrong that is stopping SITE EXEC from working properly... I have a feeling the kftpd thread that calls my exec code ends and takes the process it spawned with it...

Cheers

Kim

Once you have a GPS heading available then this is just a matter of providing an alternate display format. However, GPS heading data is only valid when you are moving, it becomes ambiguous when you are stationary. It can only provide a velocity vector that is not necessarily the orientation of the vehicle! Not quite a compass in the traditional sense.

Lynn

I know, but that's exactly what I want.

Marius (Escort Cab + Mark II)

A way round this problem would to set a velocity threshold below which the on-screen compass reading is not changed/updated - this would mean that if you set a low threshold like 5 mph or whatever, then when the car was stopped you would see the direction you were going when you were going above the threshold (i.e. just before you stopped), you could also have a little indicator to show that this is not a live reading (e.g. make it flash or have a * beside it to show its a last known direction not the current direction).

Note: as GPS has a slight inaccuracy to it, you may appear to be still moving even when stationary due to these errors, which are much reduced now that SA has been turned off. So the threshold can't be 'zero', but it may be able to be lower than say 5mph, for use in a car anything below about 5mph is a good as being stationary, and if the threshold was user adjustable from the front panel then so much the better.

Some (perhaps most?) GPS receivers have this kind of algorithm (hold last heading below 2-5 km/hr) implemented on-board. This works well because it tends to show the last meaningful direction, unless you are in a sharp turn as you come to a stop.

The nice thing about GPS velocity measurement is that is a direct computation from the doppler shift of the satellite signals, so it doesn't have the noise contribution you get from differentiating position, as was the case for older radio navigation systems. Three dimensional velocity error is, therefore, independent of vehicle speed for a GPS system, typically around 0.2 m/sec or better for commercial equipment.

Definitly appropriate for calibrating your speedometer!

Lynn

What's sort of interesting is that the people over in projects discussing GPS based navigation systems say that to do a navigation system you should use a real compass and the spedometer, and only use the GPS cordinates to correct where you think you are based on your heading and magnitude.

Matthew

Matthew,

It is common practice to use GPS data in conjunction with dead-reckoning data (compass and odometry) for a more robust navigation solution. GPS fails in tunnels, parking garages and deep urban canyons (think Manhatten or even San Francisco) where a line-of-sight view of the satellites is obstructed and dead-reckoning drifts over time (think KAL 007, an inertial navigation system is a very sophisticated form of dead-reckoning). Either sensor alone will leave something to be desired. Your needs will somewhat depend on the terrain where you will be navigating.

Lynn
[Go Bears ]

I thought SA was turned back on after 9/11.

Hi,

No, it wasn't.

Alberto

S/A is not on right now according to my receiver. I do not believe that there is any intention to turn it back on at this time. The DOD does have the option to do so should they believe that an "enemy" poses a threat that would be aided by having access to the full accuracy of the C/A (civilian) code signals.

The GPS system provides an accuracy figure of merit for each satellite, in the broadcast data message. This parameter is called the "URA" or User Range Accuracy. Currently all of the satellites have this parameter set to 2 or 4 meters which is consistant with a typical solution accuracy of ~20 meters. In the past, when S/A was enabled, these URAs were running 16-32 meters. It only provides a rough estimate as it does not take into account receiver performance or atmospheric delays.

Lynn

I agree with this idea of being able to launch (userland) apps from the Hijack menu.

The easiest way to do that would be to have a userland app (like init does now) which can communicate with the kernel (via IPC socket or /proc/something file) or something simple.

The launching of userland apps is undertaken by this userland application as requested by the user - the request comes either from kernel space via hijack or via inbuilt hijack menus built into this application.

I think Mark indicated that there was a problem getting userland apps launched cleanly from kernel space - hence the kftpd problem we had earlier.

If thats now fixed, then all Mark has to do is launch the (yet to be written) userland 'userapp' program once the system starts, and let it do the config.ini reading of its list of applications to run and the binding of itself and its menus into the Hijack menu tree etc.

What would be even more useful with this idea would be the ability to tag certain application entries as 'autostart', meaning start these programs as soon as the empeg does. And these programs would have to 'play nice' and not use the display until the user requests that they can do so via a menu selection from that apps bound in menu.

Of course, you have to use this sort of autostart option list sparingly otherwise you'll starve the player of vital memory for buffering mp3s.

All other apps that aren't autostarting could be launched as required from a Hijack menu (with the 'run this program' menu entry bound to the main hijack menu by the userapp autolaunch program).

Once each app starts its then its job to bind itself back into the Hijack menu tree at the right place, and of course each app should then have a 'Quit Program' menu option so you can shut it down again should you be finished with it for the meantime. And these apps would have to play nice and not assume they have exclusive access to the display and buttons all the time.

Heh, it could be useful if you could defer/stop the starting of the player software - that way if you need the memory for something else you can have it until you start the player, but thats a nice to have.

Hmm, this sounds more and more way too much like initab.

Somewhere, I posted a request for somebody (else) to take the time and effort and flash wear'n'tear to figure out how to launch an execve() thread and wait upon it's completion, all in kernelspace.

Solve that for me (I could, but am busy and don't need it personally), and we can revamp how the menus work.

Cheers

This sounds like a great project! Is there a specific low cost GPS that you'd recommend? Sounds like the wiring should be trivial (I gather you could help with this). I wish I had the software smarts to do the control and display for the Empeg. Seems like it should be pretty straightforward for someone who's familiar with the software innards of the Empeg.

Any idea if there's enough bandwidth in the CPU to manage this while playing music? I get the impression that the processor has a lot of available cycles.

I'm kind of surprised no one has done this yet. It would be a lot cheaper than adding a tuner (at current prices!) and, IMHO, a lot more useful than things like more visuals or most of the recent feature tweaks.

Almost any GPS receiver made for the consumer market in the last ten years would work with this interface, if the receiver has an I/O port at all. Current GPS receivers made by Magellan and Garmin will function, as will almost all Trimble receivers. For the cleanest installation in a car the Garmin 16 seems to be a good choice at around $150. This receiver is a “smart antenna” with a single data/power cable terminated in an RJ-45 (I found a nice RJ-45 to DB-9 adapter at one of the local surplus stores that would do the job without requiring any fabrication at all). Here is a link to info on this receiver, http://www.garmin.com/products/gps16/index.html ; it can be powered from the Empeg serial connector (pin 4) and even receives WAAS differential GPS corrections for improved accuracy when they are available.

The hardware should be a piece of cake.

I would not expect the processing demand to be significant. There is no need to send data to the GPS. The receiver can be preconfigured to set the mapping datum and select the output data strings and should not require any maintenance. On the receive side the data are low speed ASCII strings, typically received once per second, that need a little parsing and perhaps some units conversion before writing to the display. I would expect this to be simpler than many if the visuals, as a processor task. I really don’t know how much spare bandwidth the Empeg processor has but I see it doing lots of other tasks like serving files and VNC clients and running complex visuals without affecting the music playback.

So the electrical interface looks trivial, installation in the car sounds pretty simple, and the cost is reasonable. I guess it's "simply a matter of programming".

BTW, I'll bet a clever programmer could get the GPS time signal to set the Empeg clock (to keep it super accurrate). Even without the GPS time signal, it would be nice if the Empeg clock would automatically adjust for DST...one less clock to change twice a year.

it can be powered from the Empeg serial connector (pin 4)

Has anybody actually done that? I just picked up a GPS16 the other day and was hoping to power it from the serial connector, but I don't seem to have power on that pin on either my MK2 or MK2a. I don't have a proper voltage tester to check for any current, but it won't power the GPS or a 12volt auto tester.

-Mike

it would be nice if the Empeg clock would automatically adjust for DST...one less clock to change twice a year.

I thought it did? I don't recall adjusting the empegs time this fall (do remember that I did have to adjust the clock in the dash though)

/Michael

Maybe it does...the manual is a little thin on this kind of info
I haven't had mine long enough to see if does this adjustment(though I guess I could lie to it about the date)...or just wait until next month and see what it does. I don't remember a setting for selecting the DST function.

The answer may be in the FAQ's, but I couldn't find it.

I have +12 on pin 4 of the DB-9 serial port connector on my car sled. This is a female connector and pin one is the right-most position on the top row (five positions) facing the unmated connector. Txd is on pin 2 and Rxd is on pin 1 with pins 5 and 8 being ground. The male connector on the back of the Empeg itself does not seem to provide power on pin 4.

The Garmin spec claims 65 ma at +12 vdc for the 6-40 vdc version, so this should not present an excessive load to the Empeg +12 output.

If I can be of any help I would be glad to try if you are also in the Bay area!

Lynn

For this to work the Empeg would have to know what time zone you are currently located in as the DST rules vary (no DST in Indianna, Arizona or Hawaii for example). Right now I don't think the user interface is handleing time zones correctly, I can't get mine unstuck from US-Alaska!

Lynn

The US-alaska thing is a known bug that will be fixed in the next release. As far as I know, it's only the default menu selection that's the problem, not the actual set timezone. I think beta11 is correctly remembering and using the time zone.

None the less, for the Empeg to automate DST requires more detailed location info and an appropriate database of DST rules.

To cover the world wide case this includes places that have non-integer hour time offsets, such as Australia, India, Iran and Nepal (UTC +5:45!!!).

Still, using GPS to set the minutes to an accuracy of better than a second is possible even with serial port delays. GPS can totally eliminate clock drift.

Lynn

I thought the "advanced" option in the player's timezone menu had all that. Haven't looked closely.

Does it also have all of the algorithms? First weekend in April and last weekend in October only applies to 47 states in the US, as far as I know.

Lynn

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.

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

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

Yeah im using the script exactly from your source and installed it exactly how you instructions say... My empeg still starts randomly accepting codes from the gps and will do stuff like turn randomizing on and off once i exit out of the gps screen... which reminds me, could you make it so that when you hit one of the buttons it goes back to the player.. it seems the only way to get back is to bring up hijack and then exit it.

-Greg

Sounds like the -s- isn't working on the player software you are running. I have had this in the past too. Are you on the current beta?

Pressing the knob exits empgps.

Cheers,

Rex.

Rex,

I am having a new problem and I am wondering if it is anything you have seen. If I enter EmpGPS before I have clean $GPRMC messages and I have other applications running (Telnetd and the Player, for example) the display will lock up and the buttons and knob are no longer read. If I run EmpGPS by itself then it will tolerate this condition without any lock ups.

If I wait until I have a GPS solution and the corresponding $GPRMC messages then all is well, until I go under an obstruction or lose coverage for some reason. I don't remember seeing this earlier. I have updated preinit and do now try to run Telnetd so it may be related to one of those. Telnet is really nice to have when the serial port is recommitted to the GPS.

I have also seen many of the things that have been mentioned above but will not repeat them here. I do think that there is some risk to the problem that seems to clobber the flash because of the large number of write cycles.

Any clues?

Lynn

It's the empeg ... I'll store a log file for you, but i won't be able to do it until sunday evening or monday. But I was planning on doing this anyway for testing purposes ;-)

Greg

Did anybody try this with the earthmate ?

I'm about 2 days from ordering it,
but if it won't work in my car I won't get it...

I *think* that the earthmate is a binary interface, not standard NMEA. That will limit your choices of software.

empgps doesn't support any binary interface.

BTW, empgps isn't dead, I've got lots of new code but nothing is going to happen with it until summer is over.

Cheers,

Rex.

Will it support the binary interface in the future ?
I could build a binary to NMEA translator,
but this could be done in software...

The tripmate is nearly impossible to get in germany/europe,
but the earthmate is easily available....

Doesn't gpsd translate some kind of binary format into NMEA?

I had no plans to add earthmate support but it would be easy to do. I do have an embedded unit here that has a binary output, I might use that in the car and therefore support that.

Someone with an earthmate could add support easily once I get source out there.

In the mean time, here's an interesting hacker style GPS receiver for $25:

http://www.bgmicro.com/lmad.htm

(I haven't got one -- yet -- and haven't tested it.)

Cheers,

Rex.

Cheers,

Rex.

Heh, at BGMicro, look at item # ACS1034.

A 40" shoe string...? Well, I guess you could buy a bunch and tie them end to end to find your way home but the ACS1394 GPS receiver might be better suited :-)

Looks like they might be sold out already though :-(

Cheers,

Rex.

Rex

Do you remember any more info about them? Perhaps they could be found else where?

I like playing with that sort of cheap reject/surplus type stuff trying to get it to work.

Damn they were Trimble GPS modules . $25 is (well would have been) a bargain. We used them in products here at work and they worked well.

PDF Manual is here

The entire documentation can still be found herehttp://www.bgmicro.com/pdf/acs1394.pdf.

These kind of units do crop up on the surplus market once in a while but sell out fast. I have one here that was just $20 but that does have a binary interface only. (Easy to use all the same.) Came with a nice patch antena too that was worth more than the $20 alone.

Cheers,

Rex.

Any chance of getting another release of the empgps software? That last one was close but the whole crashing thing ... you mentioned that you'd probably fixed that part already ...

g

I have a lot of new code and some fixes but to be honest, nothing is going to get done in the summer. Too much to do. I am even only using the car (and therefore empeg) when the weather is bad.

Hopefully I start to get some time in the fall.

Cheers,

Rex.

Any particular reason not to support gpsd and let it do the earthmate work for you, as opposed to yet another version of the "convert earthmate to something sane" code?

The orginal code on which this is based both predate gpsd and ran on an embedded non-linux system. That's all. I'm sure it could easily be added, I just haven't :-)

Cheers,

Rex.

I wasn't pointing at you particularly, but rather wondering for the benefit of potential suckers^H^H^H^H^H^Hcontributors.

They are back in stock at BGMicro. Probably not many so don't wait!

Cheers,

Rex.

Well, I went ahead and ordered one. Now I've just got to figure out how to build the serial interface circuit that I thought would be more of a buy-a-converter-cable-at-rat-shack style. We'll see how it goes. Anyone else actualy get one of these?

Matthew

It's not quite that simple :-) You just need a 5v power source (regulated) and a max232 or similar level converter. Ratshack probably has all the parts.

I have ordered one of these too. It will allow me to have only a small patch esposed in the car rather than the tripmate, which although painted is still an eyesore.

Cheers,

Rex.

Lookin forward to a next run of empgps ;-)

g

Thanks for the heads up Rex. I have ordered a couple. I just hope I don't get screwed by the shipping costs...

Their shipping charges are very reasonable. Might even be actual UPS cost. I wish more etailers were so straight forward!

For RS232 level shifting to 'safe' empeg levels, I'd use a Dallas Semi (now Maxim) DS275 RS232 transceiver.

Its a small 8 pin device, which steals its TX line 'idle' voltage from the RX line from the device at the end of the RS232 link [i.e. the empeg], thus removing the need for voltage invertors - which the MAX23X series provides.

This makes for a small and simple RS232 level convertor, without the need for capacitors that some MAX23X chips need.

all it needs is +5Volts - already needed for the GPS.

Of course if you want to provide the RTCM input as well on the second serial port on the GPS unit, then you'll need a second DS275, which may make a MAX233 a better option as it has 5 transceiver circuits, enough for TX and RX for both serial ports on the GPS unit.

You could probably power one of these DS275s from the serial port pins on the EMPEG [the DTR line is +12V] with a 7805 low power regulator and a cap.

Heck you'd probably be able to power the GPS unit from the same circuit if the 7805 was properly heatsinked and the GPs board didn't need more than 400ma.

I'm also sure you could set things up so that the GPS was powered and only powered down when the Empeg itself went to "sleep" [i.e. led stops blinking], thus allowing you to keep your GPS "engine" running [and ready to reacquire its position much more quickly] than from a cold start like when the power has just been turned on again, useful when you make a short stop and don't want to lose your GPS "lock".

The DS275 will probably work in this case but keep in mind that it is greatly limited compared with the MAX23x. There is another part -- forget the number right now -- like the MAX232 but with internal caps. Easier to use but more expensive. Personally I use MAX232s a lot, easy to hook up, cheap and reliable. Never had a problem with them.

The DS275 has issues with a full duplex signal but this is rarely needed with GPS. However, setting up this unit by downloading new firmware could be a problem though.

The GPS receiver has provision for a battery backup which will keep it's clock running and help speed locking on power up. Not as good as keeping the 'engine running' but should lead to sub-minute locking all the same.

Cheers,

Rex.

There is another part -- forget the number right now -- like the MAX232 but with internal caps.

Unless I'm mistaken, it's the MAX233.

You are right that the DS275 is not a perfect replacement for a MAX23X chip.

I use them for two reasons.

1. Smaller package size - a 8 pin device is less of a problem to work with than a 18 pin MAX232 (or 20 for a MAX233). Its more expensive (and harder to get though).

2. Few serial circuits need 'full spec' RS232 signals (+/- 12 volt signals), the DS275 can only provide a 'positive voltage' as high as the voltage you give it, for most applications this is 5 volts, so the signal won't travel too far, however for most applications a 5 volts serial signal is quite robust enough - many laptops do the same and only generate +/- 5 volts on the serial port.

The DS275 only provides TX and RX not CTS,RTS etc - these signals are generally optional and not used for most Serial interfaces these days.

However, I gather the GPS BG micro are selling does output pulses for its PPS - using this would require a full MAX23X chip.

. I have ordered a couple. I just hope I don't get screwed by the shipping costs...

FYI, BG Micro now shows the Trimbles as sold out. I'll see if I get the ones I ordered last eve. FWIW, they show "8 channel Motorola GPS boards coming this week" Encores? With antennas?? Can't know, but maybe an equivalent deal to the 6-channel Trimbles...

(edit: also, in the event that this wasn't mentioned earlier here, BG also has a doc with an example 232 interface here .

FYI, BG Micro now shows the Trimbles as sold out. I'll see if I get the ones ordered last eve. FWIW, they show "8 channel Motorola GPS boards coming this week" Encores?

Encore GT. $15 per. ACS1397

The Motorola need a seperate Active GPS antenna do they not?
[antenna is not sold by BG Micro and ebay is your option I think].

Vendors still sell the Motorola antenna and other vendors' active GPS antennas may also be suitable.

So what all should I be buying? I'm looking through the digi-key web site and trying to decipher the circuit diagram in the PDF. Unfortunatly, I really earned my C in electrical-engineering-for-cs-majors and I'm not really up to speed on this stuff yet.

So far, my digi-key shopping cart consists of the following
(ugly snarf&barf from table warning)
1 1 LM7805CT-ND IC REG 1A 0-125DEG C TO-220 IC2 0 0.48000 $0.48
2 1 399-1447-ND CAPACITOR TANT 2.2UF 50V 10% RAD C2 0 0.93000 $0.93
3 1 P2067-ND .1UFD @ 50VDC TANTALUM CAP C1 0 0.43000 $0.43
4 1 MAX233CPP-ND IC 2DVR/2RCVR RS232 5V 20-DIP IC1 0 7.45000 $7.45
5 1 PT5101N-ND REG 5V/1A 3P-SIP INT SWIT VERT IC2 - SECCOND CHOICE 0 14.62000 $14.62

Questions:
1) In the BG Micro PDF, what is B1? A generic pull down resistor? Or some other component I'm not recognizing?

2) Is a PT5101 worth the extra $14 to have a switching power supply instead of linear? It's recomened in the PDF for the motorola, but really adds to the expense of all this.

3) Can I actually get these at radio shack? They're not showing up when i search their catalog online... But I'd love to avoid shipping&handling.

Has anyone gotten a shipping confirmation or anything? I'm assuming mine will arrive sometime here...

Thanks,
Matthew

I think B1 is the 3volt lithium backup cell for keeping your GPS receivers "memory" backed up when the main power is switched off.

The purpose of this battery backup is to make the "Time to First Fix" (TTFF) shorter as the GPS will have some of the data it needs remembered from last time it was used.
Time To First Fix is the time taken from when you power (the GPS) up, until it reports its location (lat/long etc).
It could take a minute or more without the battery backup to report its first fix.
You could run your unit without the battery backup - but TTFF will definately take longer that way.


I got shipping notice/email from BG Micro today that my order had shipped, as Its going Airmail, I won't expect it much before early next week.

You probably don't need to expensive Switching Power Supply - the 7805 type regulator will work, provided that the excess voltage above 5 volts can be easily removed as heat from your design.
If you need a cooler operating design - then the switching Power Supply may be cooler/generate less heat.

It may also tolerate a wider voltage range - I'm not sure on the difference from the 7805 type design..