Oh it's there, no need to hijack anything. It just needs to be brought up with ifconfig.....

Great, I misunderstood and thought it hadn't been compiled in. If I can finish soldering this weekend, I'll try bringing it up along with gpsd

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.

Agreed. Hmmm. For hard-core positionists, could you have an adjustable priority tied to a Wendy filter or genre or something??

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.

For our skill level in TSD rallying, *reliability* is important, but precision would be acceptable at +/- 1 second. I wish we could begin to care about milliseconds!!

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).

Yes, a GPS-disciplined clock. And if it ever managed to be more accurate than strictly required for our rallying purpose, somebody else might find a use for that precision. Way back when I remember elleweber disabusing me of tapping 1PPS with the Empeg's existing serial interface. My memory is that much more work would have to be done to accept 1PPS into a clock process -- probably not something with the reach of my meagre talents. Given that it looks like you are including some degree of support for gpsd, my leaning would be try my hand at something that fetches time from that.

Yes, when first I conceived of a big clock, I wasn't thinking we'd use the player concurrently, but I've changed my mind on that so resources would be a concern...

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

More action!

Geez, disabusing sounds awfully harsh I 'm just very cautious of using a serial port for any kind of precise timing.

The PPS signal from the GPS receiver is going to be good to ~1microsecond when you have a navigation solution with good geometry or when you are stationary at a known position with one or more satellites tracked and the receiver in the time-keeping mode. The delays through the serial port will be on the order of 1/baud seconds, plus some unknown and probably variable processing delays. All of this may well be good enough for your rally application as it could be well under 100 milliseconds.

I suspect that you can do well enough for your needs by using the NMEA data along with a calibration factor for all of the delays to set the Empeg clock periodically. I doubt you would need to set it more often than once a day at the first good fix after turn on. I suspect that we can come up with a proceedure for determining the calibration factor though it would be tricky to take into account various receivers and their different processing contributions along with their variations in NMEA sentence outputs.

Lynn

jaharkes, I've found the following:
Start gpsapp, wait for the location. return to player software (using top button), return (or is it restart?) gpsapp. The player shows the screen it was left with for half a second or so, and then the player skips to auxiliary periodicaly. Any ideas?

Ok, which is the player that shows the screen it was left with? the empeg, or the player software?
In any case, gpsapp isn't reading the serial port while you're back in the player software, so when we get back it should still be at the location where we 'exited'.
It should reopen the serial port, and drain the buffers, and then start showing the location again.
What is auxiliary? If it is the player software doing something strange, perhaps that is because before v0.5 all the button release codes were not hijacked, so they would still get to the player software.

I'm using version 0.5.
After returning to the gpsapp via the hijack menu, the empeg screen shows the state gpsapp was left with for a short time. Then the player's source chnges to auxiliary input periodicaly.

The only way I can change to aux is by pressing a button on my remote. The remote even works when gpsapp is running because none of the IR codes are hijacked. Are you sure nobody happens to be sitting on a remote?

I'm pretty sure, yes ;-)
Do I have to run hack_init only once or every time I upload a new version? I did it only once until now.
The bug or whatever is btw. 100% reproducible.

Do I have to run hack_init only once or every time
Only once, until you install 2.0b14. If you run it again it won't find the /empeg/bin/player string and will exit with a message similar to 'didn't find player string is /bin/init already hacked?' and won't do anything.

Interesting that the bug is so reproducible, and it only happens when you start gpsapp, go back to the player and return to gpsapp? Did you do anything in gpsapp besides waiting for a location update?

Does anyone else see this? I've just tried this about a million times and the player never even skips a beat, let alone switch to aux.

I'm going on a longer drive this evening. I will do some further testing.

I've just tried this about a million times and the player never even skips a beat, let alone switch to aux.

I need to visit a store but when I get back I should have what I need to attempt to connect my Trimble SVee6 to the Empeg in the car and I will try then.

The player shows the screen it was left with for half a second or so, and then the player skips to auxiliary periodicaly.

I used 0.6, but it shouldn't matter. I can't reproduce either.

Incidentally, here's my temporary setup with the SVee6 attached to the player in the van. This is just after I got a fix in the car, right after plugging it in for the first time.

And here's the modified SVee6 enclosure (the metalwork and the extra board you can't see with a 7805 and MAX233 were done by someone I work with named Jeff Hutzelman for his car, and I stole it to take it with me to the empeg meet; He then built another and installed it in his own car (he's doing APRS with it) so I guess that makes this one mine.

I did get a "strange behavior" myself, but no network in the car yet. I put the car in "run" (without starting) and let the player start. It came up, I started gpsapp and it got a fix. I started the car, and gpsapp was gone from the hijack menu. I pulled out and reinserted the player and it was all good. I should really get network in the car so I can debug...

As an aside, the icon seems to be about 75 degrees counterclockwise of where i'd expect it to point, but maybe I misunderstand what it is.

I started gpsapp and it got a fix. I started the car, and gpsapp was gone from the hijack menu.

Yeah, that could very well be a hijack bug, I noticed it myself. The menu entry is only shown when the application is blocking in WAITMENU.
Sometimes, like when the car is started, hijack seems to 'forget' that there was a overlay active. The display and button redirections are removed, so the player becomes visible again, but the application is still in it's main loop polling for keypresses which ofcourse never arrive.

The little pointer in the map area should always be 'true north' up, the other pointer points to the direction of the next waypoint, but is relative to the current direction. So if it points up, you should be driving straight to the next waypoint, and it points down when driving away from it.

What version of HJ are you running, and do you have any other applications (empacman, viewer, emptriv etc) running?

Might work better with the antenna right-side-up

I have a question for you, I looked at your photo of your BG Micro Trimble GPS in your car.
You appear to have the Black side of the external antenna facing towards the windshield [and the GPS sats].

Is this the correct oritentation - the documentation didn't specify this that I read, so I figured the "black" bit was for mounting underneath the antenna, this the shiny side should face up, or does it not matter?

Does the GPS even work with the antenna upside down - or does it work, but "backwards" in direction mode, e.g. it reports lat/long correctly, but some directions are reversed left to right?

As far as I know a gps derives direction from difference between the current position measurement and the previous measurement. So it shouldn't matter at all whether the antenna is upside down or turned sideways.

The only effect of holding it upside down is that the metal of the mounting bracket might shield some of the satellite signals. The ceramic piece on one side is the actual antenna, so I guess it would work best when that is facing upwards.

Actually, the velocity vector and hence vehicle direction is the residual of the satelllite signal doppler solution. The doppler component for each satellite signal can be calculated knowing the satellite location at the time the signal was transmitted (calculated from the ephemiris for each satellite) and the user equipment's current position. What is left over is attributable to the users velocity. This is far more accurate and less noisy that differentiating position, as was done with previous radio navigation systems such as Loran or Omega.

One place that would help in gpsapp would be to retain the last heading from the GPS as it is slowing down, as the heading becomes quite noisy at rest. Typically if you lock the direction pointer as you drop below 1-2 km/hr and restore as you speed up again it provides a cleaner display for the user.

The active copmponent of the microstrip antenna (sometimes called a patch antenna) supplied with the SV6 from BG Micro is the plating on the exposed surface of the square piece of ceramic. Mine is under a piece of foam tape. The other side is actually a preamp in a shielded enclosure with about 25-30 db of gain, powered by 5 vdc on the feedline. If you are getting anything with the antenna upside down then it is just good fortune and reflections. The "T" section of extruded black plastic is just for mounting.

Lynn

Yeah, that could very well be a hijack bug

Well, every other time I thought I observed such a thing, I was wrong

The little pointer in the map area should always be 'true north' up, the other pointer points to the direction of the next waypoint, but is relative to the current direction. So if it points up, you should be driving straight to the next waypoint, and it points down when driving away from it.

I don't have any waypoints on the player, I was just using it with the GPS and looking at the map area. Indeed, I figured out the bit about true north; It became obvious when I was heading toward Kittanning on route 28 (I took a ride to play with it) and it was pointed consistently toward what would be northeast if up was north.

Tried again and failed to reproduce. I should point out:
-I'm running launcher and telnetd, and i didn't start any of empacman, empsoko, emptris or emptriv from launcher but they are all there
-no waypoints (shouldn't matter)
-hijack has been 295, 296 and now 297

Actually with no waypoints, the map 'center' is 0.0,0.0 and I'm projecting to a rectangular grid relative to that point. So I would assume everywhere but the couple of hunderd miles around greenwich would see significant distortion.

I'll add something that initialized the center coordinate based on the first fix if we don't have any route or waypoints loaded.

Aha, that makes sense.

I meant to look at the code, but I ended up going out to look for more GPS receivers.

I got something close to this to happen, *one* time. The one time it happened I popped up the HiJack menu by holding in the rotary selector. All other times I either held in the selector or held "OK" on the remote and it didn't happen. What happened was I got a blank screen for a second, then the unit rapidly began switching between aux, tuner and player. The remote wasn't active during this time. Perhaps significant was that I "recovered" the player by holding in the rotary selector, and the HiJack menu came back up, but sans the GPS item.

I tried to recreate, without success.

I definitely need to get in-car network so I have some way of figuring out what's going on.

Ok, I'm running HJ v297, software 2.00 b13 developer image. I have nothing in my preinit.d except M50gpsapp.
I always use the rotary knob to access HJ, using the remote doesn't fix it though.
I found out that I don't need to have a gps receiver connected. I even don't need to leave the HJ menu! I just do the following:

1. I enter HJ, starting GPS
2. The screen show 'waiting for gps location'
3. I push the top button to return to the HJ menu
4. I select GPS again.

The sound output pauses for a short moment, and then the empeg changes the sources rapidly between aux and player.
Again: No gps receiver connected, no one sitting on the remote ;-)
I've noticed that this happens quite randomly. It's not 100% reproducible as I first stated. Maybe it is related to 'restore visuals: enabled' in HJ?
I've also noticed that I can return to the HJ menu while the player is switching by pressing the rotary control. As dbrashear already told, the GPS menu item has gone then.

Can you see whether it makes a difference when you hold the knob down for less than 2 seconds, or longer than 2 seconds when selecting gpsapp. I think I might have an idea what could be going on. Hijack has this 'cycle to the nextsrc code when the knob is held down for more than 2 seconds'. Maybe it doesn't see the knob release.

I took a look at the output coming over the serial port: Everytime I start GPS in the HJ menu, HJ gives out the following message:
'hijack: removed menu entry: "GPS"'

If I hold down the knob longer than two seconds to start GPS, then first the screen appears with 'waiting for GPS location' and then (after ca. two seconds) the player's source changes to aux. but remains there. If I just click the knob to start GPS, then sometimes it works, sometimes the player goes into 'rapid source switching' ;-)

Hmm...so why is Hijack removing the menu entry immediately?

Can you ensure that you have the following in your config.ini:

[Startup]
reservecache=2


This tells the player to leave 2MB of memory unused. (By default it grabs all available memory - so if an app wanted to allocate some memory after the player has started, it could hit problems.)