One more request , Jan.

Any chance of adding some diagnostic capability. Things like number of satellites tracked/used and 2d/3d would be very helpful. Much more is available when you get away from NMEA.

Thanks,

Lynn

as soon as I get that serial interface built I can test TSIP and TAIP

I wonder if it makes sense to teach gpsd TAIP and TSIP, as well as the Oncore binary protocol. The Oncore thing was on my list, maybe I'll have some time again and...

My Earthmate is sad. One of these days I should fix it.

thiogs like number of satellites tracked/used and 2d/3d would be very helpful. Much more is available when you get away from NMEA.

Well, isn't 2d/3d what the "mode" in the GSA sentence means?

And of course in many cases you can have lots of stuff if you're willing to deal with proprietary sentences. The Rockwell Zodiac has goodies that you can have if you're willing to deal with PRWIZCH for instance (and for Earthmates, gpsd spoofs NMEA from the binary data)

I am looking forward to trying the TSIP binary protocol as it is far more flexible and useful for troubleshooting.

can you attach to it with minicom/hyperterminal and parse it? I can't.

I always hated trying to debug Rockwell binary protocol, I don't see why this would be easier, though if you parse it all you get more information, probably.

NMEA parsers are "hard" because what can be spewed at you isn't tightly controlled enough, but with fine-tuning NMEA is easily more friendly to a person trying to figure out what's going on than a binary protocol you have to pray you wrote the correct reader for.

There is more data in the NMEA sentences but each has a different mix (GGA, GLL, RMC etc.) but #satellites used, 2d/3d, time of fix etc. are handy to display. Unfortunately the SV6 module from BGMicro only ouputs GGA and VTG. TSIP (and probably the binary protocols from other manufacturers) is much richer. You can get signal levels, elev/AZM of satellites, time parameters such as GPS/UTC offset and so on. Also, the binary protocol is the path to configuring the receiver operating parameters.

I don't think that a terminal emulator is the right tool for monitoring the binary protool on a PC. Trimble makes available tools for their receivers and also provides source code as an example for users writing their own interfaces. Look at the Trimble FTP site fot "TK...exe"

The relavent URL for Trimble is:

ftp://ftp.trimble.com/pub/sct/embedded/

I don't think that a terminal emulator is the right tool for monitoring the binary protool on a PC.

Well, no, but if I go use someone else's computer, they'll have one. They may not have the Trimble software or whatever I wrote.

I have the Trimble software, the URL was included in the doc that came with the SV6 and I already applied the tk510 "update" to convert one of them. I also have TSIP and TAIP documentation in PDF form, for one of these years when I have a few minutes to care

Hey folks,
I'm just jumping onto this thead. This looks very exciting, and I was wondering:

#1: which GPS receivers are supported? Trimble only? Where does one buy them?

#2: is there a street/map database that comes along with this so you get more than just latitude/longitude info?

Thankx
-Ted

which GPS receivers are supported? Trimble only?
It looks like any receiver which puts out GGA, GLL, RMC and/or VTG sentences can be used. I think Sam Wormley has a list somewhere of which receivers send what sentences.

is there a street/map database that comes along with this

It's not my project, but i would like to point out that that's a rather ambitious goal for a project currently at version 0.4 and not particularly old.

$GPVTG,000,T,344,M,00.0,N,00.0,K*4D

Probably my bad. A lot of the code is based on whatever I could figure out from other applications like gpstrans and gpsman (a TCL/TK app). I'm guessing I misinterpreted my sources on that VTG sentence. It should be fixable by adding a couple of 'skip(&p);' entries in the right places. Doing that now...
And I'm sure that the GGA parsing works fine if I change the strtol to strtod in nmea_time.

I implemented both TSIP and TAIP based on reasonably official looking PDF documentation that I found with Google. But as I never ran the code it most likely doesn't work yet. (For Garmin I worked from their official specs and it turned out that I had the whole checksumming stuff wrong)

Python script, ehh, python parse_mapsonus.py route.html, just did that on the file you attached and the route file it spat out is attached... (It's binary, so I hope it doesn't get corrupted by attaching it)

Any chance of adding some diagnostic capability. Things like number of satellites tracked/used and 2d/3d would be very helpful. Much more is available when you get away from NMEA.

Hmm, but where to show that on the screen. I'm not even using altitude anywhere, so the 2d/3d difference shouldn't be that big of a deal (except for precision). Right now, if there is no fix, the bearing pointer becomes a little diamond shape, whenever we have a fix it should look like a pointer.

Do you mean that your earthmate doesn't work with gpsd anymore?

Gpsd is an option (the code is there), but we can't open a tcp connection to localhost because there is no loopback network device, and because the disks are not writable a named pipe or unix domain socket is probably hard to do as well.

But plugging the earthmate protocol from gpsd into gpsapp should be pretty simple, it might even be easier than it was to add it to gpsd in the first place

You probably already have this info but if not perhaps it would help a little.

This is a nice summary of NMEA protocol:

http://www.kh-gps.de/nmea.faq

And the Trimble Lassen documentation has a nice description of TSIP and TAIP:

http://trl.trimble.com/dscgi/ds.py/Get/File-9998/lassensk2man.pdf

On the diagnostics, if not on a separate screen then even some corner pixels coded or character variations could be made to work for # satellites etc.

I originally started this thread a while back toward this end:

http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=77301&page=1&view=collapsed&sb=5&o=0&fpart=1

Still struggling with Python. Does it actually find the route.html file or what? Perhaps my Python installation is kaput. I just get:

NameError: parse....

My autoHijack Python script seems to run ok, however.

Thanks,

Lynn

Do you mean that your earthmate doesn't work with gpsd anymore?

The serial cable went bad.

Gpsd is an option (the code is there), but we can't open a tcp connection to localhost ... because the disks are not writable a named pipe or unix domain socket is probably hard

That's worth investigating. If it can be done I'll add it. Russ promised to release the patch I sent him in a gpsd 1.07 soon so maybe if I get my butt in gear...

I haven't checked the latest release, but in plagerising (sp?) some of your code in hte first release, I've noticed the following in empeg_ui.c:

1) You only bind IR_TOP_BUTTON_PRESSED, and not IR_TOP_BUTTON_RELEASED. This has caused me a mild headache. I've been writing an app and want to remain consiste
nt with Hijack's button code, where the top button is usually used for escape. It appears as though the first button returned is always IR_TOP_BUTTON_PRESSED, so setting up the application to exit on this causes the app to exit immediately on invocation.

2) It appears as though the last button in your list (IR_KNOB_LEFT) isn't bound either - I can't understand why because your code looks good. I think that hijack is subracting one from the number of buttons that you tell it to register. So in this case, telling it to register 9 buttons works, even though only 8 are listed.

So I've modified my local copy of empeg_ui.c to reflect these 2 changes:

const unsigned long buttons[] = { 10, /* front panel buttons (8) */ IR_TOP_BUTTON_PRESSED, IR_TOP_BUTTON_RELEASED, IR_RIGHT_BUTTON_PRESSED, IR_LEFT_BUTTON_PRESSED, IR_BOTTOM_BUTTON_PRESSED, IR_BOTTOM_BUTTON_RELEASED, IR_KNOB_PRESSED, IR_KNOB_RIGHT, IR_KNOB_LEFT };

So you'd be quite at liberty to wonder why I'm posting this, since I'm using it in an app completely unrelated to it's original purpose. The reason is that it's a bloody good bit of code, which IMO could form the basis for an empeg Application Template. Being able to test on an x86 architecture is a wonderful thing. Thanks. BTW, thanks also for the great Makefile. I've just learnt a lot about Makefiles and using them to dual-compile!

Still struggling with Python. Does it actually find the route.html file or what? Perhaps my Python installation is kaput.

Actually, I just checked, it runs fine with python2.1, but gets a zerodivision error with python1.5. I'm trying to figure out why. It looks like 1.5 goes off into the woods in the distance calculation. The workaround fix is to only use the 'simple' distance calculation, change
Distance to Quick_Distance at line 110 in parse_mapsonus.py.

Ah that explains a lot of the strange things I noticed, I guess the player in some screens is actually sensitive to the release codes and since I wasn't hijacking those...
It is probably wise to add release for all other buttons as well. And looking at the hijack source yup, hijack expects to see number of buttons + 1 as the first entry (maybe because 0 means no buttons and 1 indicates all buttons?)

empeg_ui.c/h should probably be distributed along with vfdlib. Kirkis, interested in adopting them?

I finally found the short between the headphones regarding Python. All my (un)doing!

I've been around the block a few times and have some observations as follows:

The SV6 interface seems to be fine now and the receiver works well.

I have created two routes. One is the same as the one I attached earlier and the other has two intermediate waypoints along the way. The second crashes every time I try to load it (causes the Player to stutter as well) but the first loads OK.

The direct route has some extraneous tracks showing at the larger scales (greater than 2-4 km) and shows tracks crossing the screen in all directions at the largest scale. When I get out to the largest scale the UI seems to lock up and I have to cycle power to recover.

The text to the right of ther screen shows 3781 km or 23495 mi both above and below the direction arrow. The endpoint is actually about 10 miles away as the crow flies.

Hope this helps track down some of the gremlins. I am glad to test at any time!

Lynn

The SV6 interface seems to be fine now and the receiver works well.

Nice, I just put up a new version 0.5 which has the NMEA parsing changes and also hijacks all the right buttons.

Could you send me both of those routes. I wonder whether there still is some python problem that created a badly formatted track file... Oh, you're probably using Windows which does 'automatical CR/LF' translations if you don't open files in binary mode.

Small change, I just included it in v0.5, but basically it is open("route", "wb"), that 'b' is significant here.

The routes are attached. Final v0.5 behaves similarly. Yes I am using Windows but have only renamed the route files post Python.

Lynn

and here is the route with intermediate waypoints.

Sorry for being a moron guys, but I can get this thing to work.
Can someone please detail the steps out for me on how to install this? If I use the preinit.d install instructions on its site, is that all I need to do on the preinit.d end (except for placing the M50gpsapp file in that dir)?
Thanks in advance guys, I am really looking forward to this program for trips and such.
Justin

Ok, windows is doing something funny with your files.
Here is where it goes completely wrong,

'\xd4\xf9\xff\xffz\xe8\xff\xffgP\x00\x00'

 41: x -1580 y -6022 dist 20583

',\xfa\xff\xff`\xe8\xff\xff\r\nP\x00'

                           ^^^^

 42: x -1492 y -6048 dist 5245453

Interestingly enough it looks like this is inserted at position 512. So it looks like something inserted a nice 'linebreak' for you. Probably the program you used to rename/copy the file. I guess I'll switch to some ascii based format, which will also make it easier to distribute these route files.

Jan,

I never did get the route file you converted. Could you send it again and I will not rename it, just to confirm that this is the problem?

Lynn

Cancel that request! I did it myself and confirmed your theory. Works fine if I don't rename. I'll try it under way in the morning.

Thanks

I have a preinit script that mounts /programs0, i.e. I followed instructions from the BBS from genixia. From your descriptions I can't really tell what you are stuck on.

Indeed, I just followed these same instructions, applying this patch to the preinit v4 source and building, with the gcc from mlord's cross compile package. I then installed launcher, but that's only really because I also wanted to play with some of the games.

Incidentally, Russ Nelson just released GPSd 1.07 with a patch that makes the Earthmate support work better. Were it not for a trip west, I probably wouldn't have noticed, but Hugo or Xastir or whatever I was using that week wasn't getting a fix, and...

GPSd 1.07 is actually somewhere different than 1.06 was.

Gpsd is an option (the code is there), but we can't open a tcp connection to localhost because there is no loopback network device, and because the disks are not writable a named pipe or unix domain socket is probably hard to do as well.

(Wow! I have to say that I am feeling "Hijacked!" by this thread. Another evolving project where Jim just can't keep up!! Seriously, it is exciting to see all the activity. Less talk, more action, indeed.)

No loopback interface. Interesting! Never gave that a thought. I'm thinking that was left out to help reduce the image. Is there any way to work a Hijack-style workaround? I'm just feeling that there could be other reasons down the road to use loopback.

On the clock front, I looked in the Readme (finally!) and elsewhere and didn't see any reference to setting the Empeg's clock. I didn't necessarily expect this, but I began to think about what would be the most desirable way to derive time for a clock display in the case that satellites were not in view.

I don't want to overestimate the risk of having no GPS time available. While most commercial units seem to refuse to display much of anything unless an initial fix has been achieved, is there any reason a custom application could not display time from as few as 1 satellite? I mean, they are all UTC, and I wasn't thinking delay would be a huge factor (or that GPSs did much to adjust time from traingulating satellites. I could certainly have a lot of this stuff all wrong.)

If you could display time from a 1-2 satellites independent of quality of fix, then going through the loop of having clock display read from Empeg's local clock would seem less necessary. OTOH, it would be a nice feature....and might be another reason to lust after loopback access to gpsd -- another modular process could set the local clock from gpsd rather than having the main gps app do it.

For a big-digit clock, was thinking of some kind of quality meter on the right hand of the display with 4 or 5 bars. Something like:
0-Local clock not set in past 3 hours
1-local clock set in past 3 hours, but GPS time not now available.
2-local clock set in past 3 hours, and GPS stream now available.
3-local clock set in past 30 minutes, but GPS time not presently available.
4-local clock set in past 30 minutes and GPS time available.
5-local clock set in past 10 minutes from GPS time

I probably haven't thought this through very completely yet, but will give it some more thought and welcome any comments. The goal is to have a clock that is always available and is as accurate as possible, but with some indication of trustworthiness. If I missed any clock related stuff in the work to date. my apologies.

Again, this is very exciting. I need to get that serial interface built!

I'm thinking that was left out to help reduce the image. Is there any way to work a Hijack-style workaround? I'm just feeling that there could be other reasons down the road to use loopback.

Oh it's there, no need to hijack anything. It just needs to be brought up with ifconfig. And it isn't needed at all for the normal operation of the player because the player never has to talk to some other process on the same machine.

On the clock front, I looked in the Readme (finally!) and elsewhere and didn't see any reference to setting the Empeg's clock.

I don't think you'd really want a purely GPS based clock anyways. Just look at all the delays, gpsapp is (or should be) running at a lower priority compared to the player. I'd rather have my location lag by a second or two than skipping music. Gpsapp wakes up 10 times per second and handles whatever was in the serial buffers at that time. So any measurement we get is on average 50ms delayed. And then the timestamp we receive isn't even the UTC time that the message was sent/received, but rather the UTC time of the last time we calculated a fix, it might just as well be several seconds old. If we want to get a better time estimate we'd have to busy loop and grab stuff from the serial as soon as it is received.

It sounds more like you really want to use the local clock, but have it 'disciplined' by the PPS signal from the GPS receiver. I'm not sure the empeg really has the oomph left over to do that kind of stuff, it probably does if you don't care much about playing music. (and adding an intermediate gpsd will add even more unpredictable latency in the tcp socket buffers).

As a side note, v0.6 is out. The main change is that the the route description files are now an ascii format.

What about just durning the preinit, check the time via GPS, if empeg time is off, adjust time.

Is this possible?

What about just durning the preinit, check the time via GPS

You really expect to already have a fix?