All right. GPSapp is installed and I'm ready to interface my RandMcnally StreetFinder to the player. I need help.

I realize this is not strictly a "programming" thing and it's being posted in the wrong forum. But I wanted it grouped next to the GPSapp threads so that Jaharkes could see it.

I have soldered wires to the Ground, RX, and TX pins on the StreetFinder's serial port. These correspond with pins 5, 2, and 3 on a standard serial port (2 and 3 will swap depending on if the cable is straight thru or crossover).

Okay, how, in "home" mode do I get GPSapp to properly talk to the GPS?

I have plugged the pins into the serial port, and it looks like the GPS is sending serial data to the player because when I select "GPS" from the hijack menu, the player software goes crazy like I was pressing a bunch of keys and letters on the serial port. Turning shuffle on and off, pausing and unpausing, etc.

I'm guessing that the NMEA sentences are being heard by the player software. But I did hack_init so the player should have been started without grabbing the serial port. What's going on? Any help?

But I did hack_init so the player should have been started without grabbing the serial port. What's going on?

Answering my own question: The removal of -s- thing doesn't happen unless we're actually in the car. So I have to force DC car mode if I've got the GPS plugged in, otherwise the NMEA sentences flow to the player and it acts goofy.

Follow up question: If I'm indoors and the GPS receiver can't see any satellites, what can I use to check and be sure it's even working? How can I see if the software is correctly communicating with the GPS unit and it just hasn't gotten a satellite fix yet?

Okay, I like how holding the bottom button toggles between the three screens, very much like I toggle between visuals and track info in the player software. Nice touch.

Okay, if the sat info screen says "No satellite data" does that mean...

a) The GPS is not communicating with the player on the serial port properly, or
b) The GPS is working fine but it just doesn't see any satellites yet because it's indoors?

Also, when I first start the GPS app, it says something like "invalid protocol, reverting to NMEA". But I thought the M50gpsapp script that I put into preinit.d already specified NMEA.

Sometimes the keystrokes I press while inside the GPSapp will ghost through to the player software itself. Is this a known problem?

Jesus, man, the "Edit Post" function is your friend!

Ok, let's see whether I can add anything to this discussion

Okay, how, in "home" mode do I get GPSapp to properly talk to the GPS?

I didn't want to interfere with the emplode/player communication over the serial port when we're on AC. So the player is only started with -s- when it is on DC. That's what the 'incar' test program does. If it works it should stop gpsapp from starting whenever we're used on AC.

Use hijack to force DC to run the player with -s- and start gpsapp.

If I'm indoors and the GPS receiver can't see any satellites, what can I use to check and be sure it's even working?

Not sure, in a way it depends a lot on the gps, and I probably am not really displaying enough information to make it totally clear whether we're actually seeing anything coming in from the GPS. One thing is to go to the map display (the second screen) and from the menu toggle the coordinate display on. It should show the last received coordinates in the top-left corner of the screen (some gps's will remember this across reboots).

No satellite data

We haven't seen any packets from the GPS that contain satellite fix information. I've notices with the garmin that this info is only sent once the receiver has locked onto satellites. For trimbles the code tries to prod the receiver into sending it at least once every 30 seconds while it is looking for satellites. Once there is a fix it should update about once a second.

Also, when I first start the GPS app, it says something like "invalid protocol, reverting to NMEA". But I thought the M50gpsapp script that I put into preinit.d already specified NMEA.

Hmm, perhaps CR/LF confusion. This would indicate that gpsapp is started without any arguments, but M50gpsapp should pass whatever is in the variable $PROTOCOL, which is set 2 lines up. Maybe this is related to all the other error messages? I'll have a look at it either way.

Sometimes the keystrokes I press while inside the GPSapp will ghost through to the player software itself. Is this a known problem?

Never seen it myself, and if it happens it must be a hijack bug. All the buttons should be intercepted by hijack. Only the remote control codes should reach the player. Maybe hijack is still passing translated/reprogrammed buttons straight through to the player?

Not sure, in a way it depends a lot on the gps, and I probably am not really displaying enough information to make it totally clear whether we're actually seeing anything coming in from the GPS.

What I have noticed so far is that if I don't plug the GPS into the serial port, it says "Waiting for GPS location" and sits there doing nothing.

But if I do have the GPS plugged into the serial port, it says "Wating for GPS location" briefly and THEN it goes to "No satellite data".

For trimbles the code tries to prod the receiver into sending it at least once every 30 seconds while it is looking for satellites. Once there is a fix it should update about once a second.

The Rand McNally unit is notorious for sometimes not getting a proper fix for like 5 minutes or something. I've noticed this with the Palm software, it sometimes doesn't start working until the thing's been on for 5 minutes or so. Does your software handle that OK?

Hmm, perhaps CR/LF confusion.

ARRRGH I hate Winzip. Curse its "TAR File smart CR/LF conversion" feature!

Which files should I worry about in this case, just the preinit.d script?


Never seen it myself, and if it happens it must be a hijack bug. All the buttons should be intercepted by hijack.

Only seems to happen the second time I enter the GPSapp from the Hijack menu (in/out/in), if that's any help. Might be imagining that, though.


Okay next question. When I put the GPS antenna by the window, I got this:



Is this normal?

ARRRGH I hate Winzip. Curse its "TAR File smart CR/LF conversion" feature!

Yup, that was it. It trashed the preinit script, and it trashed your example "CMU" route. The latter seemed to still work OK even with the extra CRs in there.

Time to mess around with it some more...

Ok it should say 'waiting for gps location' until it get any input (either serial port or keypress). So as soon as it receives something from your GPS it switches to No satellite data.

The Rand McNally unit is notorious for sometimes not getting a proper fix for like 5 minutes or something. I've noticed this with the Palm software, it sometimes doesn't start working until the thing's been on for 5 minutes or so. Does your software handle that OK?

Well, when the GPS isn't giving me anything there isn't much I can do about it. I do want to have that satellite strength screen continuously updating while it is trying to get a fix.

My guess is that I have to do a bit more work on parsing the satellite tracking information messages. The data is probably there, but that my code is still a bit too picky about what it does with it.

Are you getting that insane switching between 'no satellite data' and the signal strengths and locations? Hmm, I can probably fix that, had that with the Trimble protocol as well but managed to get rid of it without too much trouble.

Are you getting that insane switching between 'no satellite data' and the signal strengths and locations?

Yes. That's why I went to the trouble to make the animated GIF of the two photos, so you could see exactly what it looked like.

So I guess my interface is WORKING (woooo!) because that's the satellite strengths screen, it switches to "no satellite data" almost immediately, and I also DO see coordinates when I toggle them on.

So if you hadn't gotten proper coordinates from the GPS unit, there would be "nothing" when I toggle coordinates on?

Do these look like they would be accurate if they were last coordinates the receiver might have gotten?:

39.215278
-121.175017

Should have been somewhere in California.

Okay, now to go install ActivePython and mess with loading some routes.

So if you hadn't gotten proper coordinates from the GPS unit, there would be "nothing" when I toggle coordinates on?

Well they would be 0.000 and 0.000, so they should only be confusing for a couple of people somewhere in the middle of Africa.

Do these look like they would be accurate if they were last coordinates the receiver might have gotten?

Does Penn Valley ring a bell? It should be about a mile away.

Does Penn Valley ring a bell? It should be about a mile away.

Yup, that's accurate. That's exactly where I expected it to show (my house is about a mile from Penn Valley, and the last time I had it working, I was in my driveway).

ROCK, the serial interface works. Now for the car mount and to try out some routes from Mapsonus.

ROCK ROCK ROCK.

Thank you for your help. And thanks, Bitt and Genixia for helping me get preinit and the programs0 partition working.

hmm. i'm expecting a gps howto writeup in the faq very soon =)

i'm expecting a gps howto writeup in the faq very soon

No way. As these threads demonstrate, the install procedure needs to be improved to near-point-and-click status and I'm not going to FAQ things that will be changing any time soon.

Bitt's preinit is very very close to point-and-click because of the FTP script he includes. High marks for that. If he could get the automatic creation and mounting of /Programs0 and /Programs1 built into preinit, then it would be completely painless and point-and-click.

The GPSapp would be almost point-and-click if:

- There was a "layman's version", a distribution that's just the needed binaries, in ZIP form so that you don't run into the CR/LF problem in WinZip.

- The instructions were cleaned up a bit and made clearer for laymen, including things such as how to chmod 755 the files. If it included an FTP script like Bitt's preinit did, even better.

Bitt's preinit is very very close to point-and-click because of the FTP script he includes. High marks for that.

Woo-hoo!

Too bad I can't automagically find your empeg's IP address and embed it in a .bat file or something.

Or did someone release something that would probe the network for it? Maybe in relation to adding it to .../etc/hosts?

Or did someone release something that would probe the network for it? Maybe in relation to adding it to .../etc/hosts?

Yes, that was FindEmpeg. I use it myself to always call my empeg "empeg" in the hosts file. I wouldn't bother with that part if I were you, though. Because the user would still have to input the name or serial number of their empeg if they had more than one on the network.

There was a "layman's version", a distribution that's just the needed binaries, in ZIP form so that you don't run into the CR/LF problem in WinZip.

Not my fault that winzip is messing up the files. Zip has it's own problems like not preserving directory layout and requiring nagware/shareware/limited time demo programs to unpack the archive.

The instructions were cleaned up a bit and made clearer for laymen, including things such as how to chmod 755 the files.

Actually I just went to update the readme file and it says quite explicitly 'upload gpsapp and hack_init to /programs0 and make sure they are executable (chmod 755).' I guess I'm not a layman, should I have included the manual page for chmod?

Ok, it missed out on the incar program, but if that isn't installed or not executable everything will still work. incar is just to avoid starting gpsapp when the player is not running with -s- (i.e. when we're on AC), and that functionality probably should end up in preinit somehow.

If it included an FTP script like Bitt's preinit did, even better.

You can't run an executable like hack_init from an ftp script. However now that preinit v6 has the blocking functionality, it should be possible to get rid of hack_init completely. At some point the installation will be something like 'dump gpsapp in /programs0, and M50gpsapp/B00init in /programs0/preinit.d and we're done. If I move the protocol selection to config.ini and preinit can run executables the instructions could even become, upload gpsapp to /programs0/preinit.d/M50gpsapp

Sorry, I'd missed the line about chmod. Perhaps rewording it to a step-by-step list instead of prose would make it more layman-friendly.

I'm working on a DOS batch file that will hopefully allow me to drag-and-drop HTM files onto it for Python conversion...

Lucky b**tard. My script doesn't rate. ( )

Bitt, if you want to steal my script and roll it into a preinit tarball, then please go ahead. Then it would be possible to also install N00firsttime into /etc/preinit.d:

#!/bin/sh
/mkprgpt
rm mkprgpt
rm /programs0/N00firsttime

(mkprgpt in it's current incarnation migrates /etc/preinit.d entries to /programs0/preinit.d)

It's still got preinit.d entry creations in it which should probably be stripped out. Let's encourage app developers to create them..

My script doesn't rate.

Your script didn't work.

Yeah it did. Just not well enough. Given that it had just been updated for preinit changes, and that I had no desire to unformat my /dev/hda2, /dev/hdc2 partitions just for testing purposes, I think it worked incredibly well....but you should have just ran it twice to be sure....

Anyway, I'm hoping that someone else with a pristine player will try it and give me some feedback. That bug has been squashed.

Heh, don't take it personally, your after-sales-support was superb.

Heh, don't take it personally, your after-sales-support was superb


You haven't seen the invoice yet..

Hi. I have a RandMcnally Streetfinder for Palm V and want to try interfacing it with my empeg. However, I can't find any documentation as to which pin is ground, rx, or tx. How exactly did you interface your Streetfinder?

In the thread about the original Palm3 GPS unit being on sale at Staples, there was a link to a picture of the Palm docking connector pinouts. That's what I used.

And when I opened the GPS to do the soldering, my only question was orientation... which pin was pin 1? I mean, I knew from the connector docs, but I wanted to be certain. Turns out that once I had the GPS open it was dead obvious which end was the ground pin (you know how on PC boards the big flat areas around the outside edge are ground), so that was a no-brainer once I had it open.

Hmm. It seems I'm not too good with this hardware stuff I cut an old serial cable in half and used a multimeter to figure out which pin goes to which wire (pin numbers were printed on the cable). Then according to that diagram I soldered the wire connected to pin 5 of the serial cable to pin 10 of the streetfinder, pin 2 of the cable to pin 5 of the streetfinder, and pin 3 of the cable to pin 3 of the streetfinder. Is that all I need to solder and are those the correct pins? I thought that pin 1 of the streetfinder was the leftmost pin if you are holding it with the antenna pointed up and pins facing you, is this correct? I haven't actually loaded gpsapp to test this on my empeg, I have just been trying to get it to spit out something to my pc in hyperterminal with the settings 4800-8-n-1-no flow control. Is this a good way to test it? There are so many things I could have done wrong, what do you think it is? Thanks for your help.

Try swapping pins 2 and 3.

And I'm not sure, but I think the PC is wired backwards of the empeg, in other words, you might have to swap 2 and 3 back when hooking to the empeg.

And honestly, I never got any output on the PC, I just plugged straight into the empeg and ran GPSapp.

Also, verify that pin 10 really is ground by opening the streetfinder and looking at it. You could theoretically have them the wrong way 'round.

Has anyone on this board with a Garmin GPS V tried to interface with the GPS app on the empeg? I'm interested in learning more about how to do this...

- Jon