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