I just synced the CVS archive, give me 10 seconds...

Ok, v0.14 is up.

Does 14 also contain that clock patch posted earlier in this thread?

Route reversal... Just plan the reverse route offline and upload that as well. It just seems like a bit to much work for no real gains. i.e. there already is a perfectly working way to do it that actually handles one-ways etc, and doesn't complicate the code. And I would rather start playing with actual vector map data.


Fair play...it was just a thought, but I wouldn't want to distract you away from something that will be far more valuable. And of course, you're right, my need for reverse routes would only be based upon my laziness

wrt track points. I wonder if now is the time to consider what we might eventually want to see gpsapp write out to disk. Considering that it has to run 'root' anyway, getting gpsapp to remount /programs0 (or /programs1 if it exists) should be trivial.

No, I thought you said it didn't make any difference.

No, I thought you said it didn't make any difference.

Didn't SEEM to, but the timing of that thing is always variable.

wrt track points. I wonder if now is the time to consider what we might eventually want to see gpsapp write out to disk. Considering that it has to run 'root' anyway, getting gpsapp to remount /programs0 (or /programs1 if it exists) should be trivial.

Although track points are the last thing I'd want written out to disk, I could envision some other things it might write out to disk that would be useful...

Is it possible to write out the almanac data to the disk (only when I say so from a menu item) and then feed it back into the GPS at boot up? Does the GPSapp even get the almanac data or is that only internal to the GPS?

DBrashear, here's a photo of my StreetFinder opened up and wired for serial. You can see which pins are which pretty easily.

In this configuration, I was able to close up the case and just stick those pins into a female serial cable.

But later, I completely got rid of the plastic casing so that I could stealth mount it and position the antenna wherever I wanted. I wrapped the whole thing in electrical tape and soldered a proper serial cable to the PCB instead of the loose pins.

You don't have to go this far if you still want to use it with the palm3.

In reply to:

---

Although track points are the last thing I'd want written out to disk, I could envision some other things it might write out to disk that would be useful...

---

I have a suggestion that it should be possible to build a route up from scratch simply by driving it & marking key places/waypoints as you drive (gpsapp could even do this automatically as well using each turn you do more than X degrees from the last heading as a "waypoint").

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Doing this requires that we be able to save these waypoints somewhere - now I don't like the idea of running my Empeg with rw mounted disks anymore than anyone else, so maybe we could look at creating a small ext3 filesystem somewhere that can be left rw mounted permanently for apps like the GPs one to save stuff to as and when required.

Either that or we dust off the old talk from some time ago about a special "raw" disk driver that reads and writes disk blocks itself directly [no need for mounting the special filesystem then.

Given that The latest hijack now includes ext3 support, maybe this is the time to make use of it?

Can't think of any other way to get permanent storage on the Empeg can you?

AFAIK, most receivers will output and allow input of almanac data, but generally only in their own binary protocol. How long the almanac remains valid for is another matter that I'm sure that Derrick could answer.

Writing track points out to disk could have uses:
Survey - although the receivers/antennas we are typically using aren't up to the accuracy of proper survery units, it still might be useful/fun.
Map making/calibration.
Road Trip Logging.
If live routing ever becomes a possibility (the map data issue obviously needs to be resolved first), then track logs may be useful for retroactive routing validation.
It'd be cool to be able to 'mark' a place for attention, much like you'd mark a track for attention. How many times do you see an unusual place or shop and think "Must remember that's there...", only to forget exactly where it was? Or stop on vacation and take a photo of a wonderful vista, only to forget exactly where. If JEmplode could check a known directory, and find a date/time/position log, and the route taken to it, then you could process that information, give it a name and reupload it as a normal route, or use it to help label your photos.
Custom route creation - if you know a better route from Exit X of I95 to your house/church/whatever, than mapquest/mapsonus/whatever can find, then you could drive that route, and then retroactively use it to create driving directions for friends/relatives/whoever - including typical timings.

So many possibilities.

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Well you could use google and find in a couple of seconds programs like
www.gartrip.de and http://home.t-online.de/home/gpsinfo/ which allow you to create tracks and routes based on digitized topographic maps by tracing the track you want to follow.

If you're from england and rather not use those german programs, www.gpsu.co.uk does similar stuff.

Either that or we dust off the old talk from some time ago about a special "raw" disk driver that reads and writes disk blocks itself directly [no need for mounting the special filesystem then.

Writing to the disk is writing to the disk, whether you use a filesystem or write the blocks yourself. i.e. you could create a single large file without holes in any given filesystem and as long as it doesn't change it size the access is equivalent to writing to a raw device.

However, it is simply the actual process of writing bits to the disk that is dangerous. I believe some recent IBM 3.5" IDE drive was renowned for writing even when the power was cut so it would scribble over low level data between the tracks. This basically turned the disks into a brick that could be shipped back to the factory.

How long the almanac remains valid for is another matter that I'm sure that Derrick could answer.

Well, the almanac data is rough anyway, it's an idea of where in the sky to look for what, so basically, you can use it for months, with decreasing accuracy, but that's ok.

Ephemeris data is what's interesting, but I don't know what receivers cache it.

Actually,. I bet one of
Joe Mehaffey, or [url=http://www.edu-observatory.org/gps/gps.html]Sam Wormley[/url[ have a good explanation. I'm merely a somewhat enlightened amateur (though before selective availability was turned off, the quest for accuracy meant I learned a lot more than I would probably bother to today; for that matter, I also learned about datum shift bother using Molodensky and a shift table, and why for NAD27 to NAD83 you want a table, for instance, because I have maps calibrated in both, and wanted to use them all together, usefully)

Writing out track info to disk could be very useful, and at the same time, it opens the "read/write disk" can of worms. The thing that I want, probably, is a network attached disk external to the player, possibly CF based. The problem is, network attached disk (it doesn't need to be secure in my car unless I'm dumb enough to use wireless, can anyone say reverse wardriving?) isn't really cheap enough that you'd throw CF in a device and use it for this sort of thing... yet.

But basically I want it external to my empeg, so it doesn't use up either IDE channel that I could use for real data, and slow access is ok. Serial would probably be ok, except for that "out of ports" bit.

Writing out track info to disk could be very useful, and at the same time, it opens the "read/write disk" can of worms.


Maybe it's me, but sometimes I think that we all get a bit carried away about this. Yes, the empeg guys did a fantastic job of protecting our drives in their daily use - both in HW (choosing laptop drives, shock mounting) and in SW (keeping the disks spun down as much as possible, only mounting read-only), and I am both impressed with and grateful for their design ingenuity.

But the fact remains - these are laptop drives, and they are shock mounted. Millions of people use laptops with RW disks spinning in cars, on aeroplanes etc, carrying them around and plonking them down on hard desks without regard to whether they are going to crash their heads. I suppose one might argue that when being used on a lap in a car, that the person provides some shock mounting for the laptop as a whole, but that isn't the only modus operandi.

I'm not saying that we should mount all the paritions RW, and leave the disks spinning all the time. But I do wonder whether our collective paranoia is un-necessary. I'm tempted to interface an accelerometer to my empeg, and attach it to the drive caddy. The only problem is that I'd need the disks RW to log the results

I don't think that we should write data constantly either - but we could cache data to be written, thus minimizing risks as far as possible.

Mark Lord has talked about making a disk writing feature available in Hijack. As mentioned, it would operate on a few sectors in-place, and could be done while the drives are mounted r/o. The kind of features you guys are talking about are definitely good uses for this kind of thing, at least, better uses than high scores for empacman or favorite trivia categories for emptriv.

Hopefully as the weather gets colder we'll see Mark around here more, and he'll make this happen. I agree, the "thou shalt not write while in the car" thing is a bit overboard, and we should allow for at least a limited write-while-driving API in Hijack.

In reply to:

---

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Well you could use google and find in a couple of seconds programs like
www.gartrip.de and http://home.t-online.de/home/gpsinfo/ which allow you to create tracks and routes based on digitized topographic maps by tracing the track you want to follow.

If you're from england and rather not use those german programs, www.gpsu.co.uk does similar stuff.

---

Yes, I realise all this, but my point is that not everyone has the same common "solution" for all countries, so there will be a lot of "home-brew" type setups out there, therefore allowing the building of routes by "driving them" is always useful.

Personally, I'm using TUMONZ (The Ultimate Map of New Zealand) which is all 100% vector based maps with route information & planning and it only costs $100 (about $USD50) and allows uploading/downloading routes/waypoints to Garmin & Magellan GPS units.
It also comes with "aerial photographs which you can "drape" over your map to allow you to merge actual aerial photos the landscape with the topography - see the opening screenshot on the TUMONZ website for an example.

Considering the price this is pretty amazing stuff.

But, you need a Windows PC to run it, and its not much use to anyone outside of New Zealand (unless you're Mark Lord and want to plan your next mountain expedition).

In reply to:

---

Writing to the disk is writing to the disk, whether you use a filesystem or write the blocks yourself. i.e. you could create a single large file without holes in any given filesystem and as long as it doesn't change it size the access is equivalent to writing to a raw device.

However, it is simply the actual process of writing bits to the disk that is dangerous. I believe some recent IBM 3.5" IDE drive was renowned for writing even when the power was cut so it would scribble over low level data between the tracks. This basically turned the disks into a brick that could be shipped back to the factory

---

I agree, but my idea is only bringing up something that Mark Lord mentioned a long time ago when some form of permanent rw storage was mentioned.

While Network Attached storage sounds really useful, I am not sure of the life span of any hard disks in a mobile environment when kept powered up all the time.

Ideally we need a solution that uses solid state [flash] RAM - something like one of those USB Flash based "disk drives" would be exactly right -
but you would need a USB **master** device between that and the Empeg (This is required [to act as a master device and go-between between the USB slavees to "route/mirror" all copy data requests from empeg (on USB Slave Port A) to USB data device (on USB Slave port B) and/or "route" read requests from Empeg on Slave USB A to data device on USB slave B.)

In addition we'd need a way to get the USB ports to dock/undock reliably/easily in the car - something which could be done if there was a USB master device in a small portable chip - and thats a bit of a tall order right now.

Either that or we come up with a simple solution that can "clip" onto the rear of the Empeg and plugs into the USB port on the back and "fills up"/uses the space between the rear of the Empeg and the rear of the sled - preferably something that could take a USB flash device.
I'm thinking something sized and designed like the Nomad Muvo here [but again thats only a USB slave device].

There are multiple problems that affect reliability of drives. One is vibration, the heads are floating close to the platters too much vibration could disrupt the airflow causing the heads to hit the platters. The airflow also disappears when the drive spins down, so it is very important to move the head away. Another factor is that te spinning platter works like a gyroscope, moving sideways or rotating it in the horizontal plane is pretty much ok. Moving it vertically is a bit worse, but twisting is rough on the bearings. Laptops typically spin their disks down quite often. This is not to save power, as it costs more energy to spin a drive back up and seek to the correct track than just leaving the disk spinning at a constant rotation. So this is to avoid the possibility of head crashes and perhaps even wear to the bearings.

A big factor however is power loss. Laptops only predictably lose power, their battery runs low and the system suspends/hibernates itself before we completely run out. However in a car we have possible power dips and loss due to starting the engine, pulling the player out of the sled, a bad alternator/battery, etc. And when the power cuts out, the platter slows down and and the heads have to be moved off the platter as soon as possible. With the drives I mentioned before, when a write was in progress at this time, it wasn't aborted during the 'emergency head park' and so the bits got written in a sweeping arc across the disk.

Laptop drives are typically better protected for the mechanical wear and tear of mobile devices, but are definitely not designed for sudden power failure. They'll probably be able to handle it to a point, but where that point is exactly...

It's not the shock mount, it's the fscking, that concerns me. I trust the hardware.

It's not the shock mount, it's the fscking, that concerns me. I trust the hardware.

I trust neither, and I especially don't trust that the power will be there from the beginning of the write to the end of the write.

But if we're talking about just unlocking /programs0 to write one file and the locking it again, I don't see a problem with doing that as long as it's user-triggered.

I would be perfectly happy if there were a menu option in GPSapp that says "Write data to disk now", and when I hit it, it saves everything all at once: Track history data, almanac/ephemeris data, whatever. It would then indicate when it was done on the screen somehow.

That way, if the data was important to me, I could make sure to do it and be sure it was done with the write before I turn off the ignition and pull the player out of the dash. And only when the car wasn't going over bumpy roads.

I wouldn't care about mounting anything read/write, or adding hijack hacks to update ext2 even when the filesystem is mounted readonly.

Just open("/dev/hda6", O_RDWR) (yes the swap partition), and you can just write blocks directly, add a checksum so that we can later tell whether the block was completely written or not. The player won't be using the swap in the car, and because the swap partition is as far as I can see on the outer tracks of the drive, I'm assuming it requires a smaller seek to park the head and in the worst case you'd only be trashing across the unused swap partition. Maybe even open it O_SYNC to keep actual writes as short as possible. There wouldn't be any metadata that could become inconsistent. I guess this is similar to how the player uses it's raw partition.

As long as we don't damage the first sector which contains the signature for the swap partition and recover the data when we're back on AC somewhere before the player starts an fsck.

Not all receivers support giving the user the almanac. The rockwell in the Palm 3 unit might; The SVee6 doesn't.

I still think parsing Tiger data is far more exciting than this. Other free apps do this; If Jan gets autorouting working he'll be the first open source author to do so

Just open("/dev/hda6", O_RDWR) (yes the swap partition)

Ew.

I guess I should bother to see if it adds the swap partition from the second disk. If not, and you have 2 disks, that's less worrisome.

Actually, no almanac from the Rockwell, either. However, looking at the Zodiac doc reminded me... are your slow starts in weak coverage areas?

are your slow starts in weak coverage areas?

No, I live on a mountaintop with wide open skies in all directions. And once the satellites lock, I get pretty consistent solid coverage from several sats.

Everything I've read says that with these particular devices (StreetFinders), it's normal for it to take a long time to get a lock like that because the units don't have any local storage. I'm just curious what we can do in empeg software support to speed it up since we've got the storage if we really need it.

Actually the SV6 does support almanac and ephemeris exchange with the attached device but not via NMEA. The SV6 from BGMicro was an OEM product that has a limited subset of NMEA implemented with lots of fail-safe provisions, probably used for vehicle tracking or ?? The NMEA mode in these SV6s doesn't allow much, if any configuration.

If you reflash it to TSIP you get a much richer interface that allows upload and downlod of ephemeris, almanac, initial position and time along with customizing many other of its modes of operation. For example, you can set it to provide an overdetermined solution where it will use more than 4 SV to improve the precision of the nav solution. You can also set it to track the highest 8 SV or the highest 6, change the mask parameters, dynamics filters, operate in MSL or geoidal height modes, etc. It is a real luxury for Trimble GPS users that Jan has included the TSIP parser in GPSapp.

NMEA, per se, doesn't allow almanac or ephemeris interchange. Individual manufacturers have defined proprietary NMEA-like sentences that are then useable for expanded functions. Unfortunately, these are different for each manufacturer's GPS so the interface to use them gets almost as complex as providing for the various binary protocols.

NMEA was originally intended to interconnect marine electronics such as speed logs, compasses, auto pilots, LORAN etc. GPS came later and was added as the $GPxxx series along with a provision for manufacturers proprietary messages in the $Pyyyx series, where YYY denotes the manufacturer (such as GRM for Garmin).

When all is said and done the almanac/ephemeris functions really belong in the GPS. If a GPS receiver (designed for navigation use) doesn't store these then it is most likely a hardware fault (bad battery or "Gold Cap" or BBRAM). I don't know of any decent nav receiver that doesn't store this data by design. Dependency on an external device is devistating to performance.

If a GPS receiver (designed for navigation use) doesn't store these then it is most likely a hardware fault (bad battery or "Gold Cap" or BBRAM). I don't know of any nav receiver that doesn't store this data by design.

The StreetFinder, I'm told, doesn't store this data permanently after it's been shut off. It only keeps it as long as it's on.

After a good bit of searching I did find a little bit of info on the StreetFinder's receiver. Link follows:

http://www.gpsnuts.com/myGPS/GPS/Hardware%20reviews/RandMcNally/rand_mcnally_gps.htm

If this is the same receiver you have, it would appear that the RTC is not loaded. Probably a cost saving measure that relied on the Palm for initialization. Too bad they cut this corner as it is probably an otherwise ok receiver.

This guy seems to think you can upload initial position and time but implicitly NOT ephemeris data. Your Time To First Fix will probably never get better than 90 seconds or so as the receiver would not output any solution until it collects a valid ephemeris from each satellite it is going to use. Add some overhead and latancy to the 30 second long data message and allow for an occasional satellite selection challenge and...

Looking further for info onthe Rockwell Zodiac receiver I found a spec for a related version here:

www.navchina.com/right/product/pdf/zodiac_dg_gps_33.pdf

This seems to imply that almanac and last known position data (and more) are stored in EEPROM, not requiring a battery (see page 6-12, 13). If this applies to your receiver then all that is needed is time initialization.

Receivers that store recent ephemeris have an advantage in reaquisition (only after short losses of power) as the validity of the ephemeris is relatively short, it changes at least once per hour. Some receivers may use an old ephemeris for a short time while collecting a new one but that is risky in terms of accuracy and detecting faults in the satellites.

Lynn

I did find a little bit of info on the StreetFinder's receiver. Link follows:

The review you linked was for a laptop-connected "mouse shaped" model. I do not know if its guts are in any way related to the Palm3 model I got.

Probably a cost saving measure that relied on the Palm for initialization.

Even when I used the Palm software, this thing had long acqusition times. It's even in the manual for the Palm software as being "normal".

Your Time To First Fix will probably never get better than 90 seconds or so as the receiver would not output any solution until it collects a valid ephemeris from each satellite it is going to use.

90 seconds would be a dream.

This seems to imply that almanac and last known position data (and more) are stored in EEPROM, not requiring a battery (see page 6-12, 13).

Well, I know that the receiver instantly spits back its last known position as soon as it starts talking to the serial port. So that part is true for sure. Dunno about the almanac/ephemeris data.

If this applies to your receiver then all that is needed is time initialization.

If true, then why didn't that timecode patch improve my acquisition times? Was it because of some kind of a timezone-off error? For example, my player's timezone is set to GMT-8 which is PDT. Should I have set my player's timezone to GMT before trying that patch? I would have figured the patch was smart enough to convert my timezone to GMT before sending the time.

Interesting. I just peeked at the navman web site (the StreetFinder for Palm3 is a Navman product) and saw this. Note the highlighted text, I didn't realize this...

Question/Symptom:
What can I do to improve my Time To First Fix (TTFF)? The unit takes to long to acquire a fix when first turned on.

Answer/Solution:
There are several issues that can effect GPS acquisition. The receiver will often be blamed for poor reception or greater than average Time To First Fix (TTFF) in cases where user education can fix the problem. Realizing the limitations of the GPS system and utilizing your device for maximum performance will solve any problems you might be having.

1. View of the Sky- A GPS will typically take several minutes to acquire its initial position fix if it has not had a fix in your location on the planet previously. This is called a cold start. To obtain a cold start the GPS must have a view of the sky sufficient to 'see' four to five satellites continuously for about 45 seconds. It takes this long for the GPS receiver to download a data set from the satellites which is used to acquire a fix more rapidly on a future start (warm start). You must be located in an area with a clear view of the horizon around you. Buildings, houses, trees and other object will all affect this process. For Navman systems used in vehicles, they will typically be able to get a 'cold start' fix from inside the vehicle, but the vehicle can NOT be moving for the initial cold start. If the vehicle is moving it constantly changes the view of the sky and prevents the GPS from having a view of those same 4-5 satellites for 45 seconds.

2. Keep the GPS off- The GPS will acquire a fix more rapidly if it has an estimated position to work with. The GPS remembers where it was turned off and uses that position as a starting point. This is called a warm start or a hot start. The Navman GPS3420 has an integrated GPS expansion pack that is on (using power from the iPAQ) whenever a piece of software is looking at data from the allocated COM port. That is, when the SmartST Professional application is open then the GPS is on. If you leave the GPS on indoors for more than three minutes then it will go into a cold start mode. If it is left on then it thinks it can not 'see' the satellites it thinks it should. The GPS then believes it has been transplanted to a different part of the world and will try and start over doing a 'cold start'. This will cause it to have a longer time to first fix (TTFF) as if it has just been taken out of the box.
To Do:
-Make sure that you are stationary when initially turning on the GPS. You must have a clear view of the sky. The fix should not take long and you should see some progress from the GPS Status or GPS info screens.
- make sure that the SmartST Professional application is minimized or closed when the GPS is indoors or is not in a position to acquire.
-On the iPAQ, make sure all other applications have been shut down. The design of the Pocket PC is such that just clicking on the X in the corner doesn't really shutdown most applications. Many may still be running in the background. In some cases you might even want this, such as when listening to music while doing something else but for gps use shut everything down. Shutting down everything is not easy on a pocket pc. Method one is to use the Start menu and traverse to the shutdown command with 'start menu -> Settings -> System -> memory -> Running Program -> Stop All'. The second method is to use the iTask hardware key on the bottom right. This will list running programs and you can tap and hold to choose 'close all tasks'. Of course a soft reset also works.

How much power does the receiver really pull? Maybe you could just tie it to your always-on lead and never let it turn off. You could put a switch somewhere for those times when you know you'll not be in the car for a loooong time. Or maybe even figure out a way to build a timer that will turn it off after two or three days.

You're right. I'm seriously considering trying this.

How would I measure its load on my car's charging system?