Tempel said:
As for GPS receivers, I'm fairly certain that they have a standard method of communicating location to a computer (edit: looked it up, its the
NMEA standard). So, except for the aforementioned USB 1.1 vs. 2.0 issues, I think any receiver that supports the standard should work (but maybe wait until some have been tested with the Pandora first; I'm no expert on this).
Son of a... I just wrote a huge reply and it got swallowed by Firefox refreshing the page for whatever reason. I really hate when that happens, especially because I don't know why it did it. I don't mind losing data when it was my own fault, but when it just happens for reasons unknown, it's a little disconcerting.
To summarize (because I want to get to bed) - NMEA is not a well-defined standard. NMEA is not the standard for communicating with the computer, it's just the protocol for packaging up the information itself. What you said wasn't incorrect, it just might be misinterpreted, so I thought I'd pipe in and clarify. The way a bluetooth GPS communicates with Linux is as a HID device, over a virtual COM port. Almost all bluetooth GPSes work this way. If you have one that works this way (basically it would be strange if you didn't) then you will just have to pair with the device and it will work. (it's actually not quite that simple, you have to do some configuration with RFCOMM and a couple of painful hoops, but you only have to do that once.)
The way the data itself is sent is typically NMEA but there are also binary formats that actually work better than NMEA (in that they're more rigidly standardized and are more logical than NMEA - NEMA has an insane amount of cruft from years of poorly-planned revisions - and it's also used for a lot of other communications methods (not just GPS) on ships so it has a lot of unnecessary functionality that just convolute the standard.) Most / all software written for Linux using GPSes will use GPSD, not directly process the NMEA sentences a GPS spits out (this is doable but the way NMEA is implemented differs with different chipsets, and as I said before, it's preferable to use the binary protocols in a lot of instances.) SO just make sure that the device you're buying uses a chipset supported by GPSD (preferably one with a binary mode supported by GPSD - you'll get more accurate data and faster updates that way, in most cases.)
I just bought a $25 gps adapter on ebay that I knew had binary mode support in GPSD and it works perfectly in Linux. Acquires satellites really fast and updates fast as well.
As far as nav software, I don't particularly like Navit. It has a lot of faults and all around feels very unpolished to me. I appreciate the effort the guys put into it and I know it's still alpha, but personally I don't think I'll be satisfied using it, and it's looking like it will be alpha for quite a while. I guess we'll see, I'm pretty early in the first batch (around 7-800) and I live in Texas (only about 3 hours from manufacturing facility), so I may be one of the first people to get a MP pandora (if they really can make/ship a few hundred a day), and I'll make a Youtube video with an evaluation of all the GPS options (as this is one of the many uses my Pandora will hopefully serve) probably on the first day I have it. I'll also write up a guide on how to set up GPS under Angstrom and with the software and all and post it on my website. I'm planning on writing a lot of Pandora guides actually.
Getting back to navit, I don't think they do turn-by-turn navigation or even have searchable addresses, so it's unlikely that will work unless you can look up the addresses beforehand and type in the coordinates, but in that case why not just print out Google Maps directions to the place you're going?
This isn't specifically directed at navit, but one of my main pet peeves with all GPS software I've used is UI design. They've all got pretty fast updating chips now as far as actual GPS coordinates go, but I have not to this day used any GPS software that I felt had even a passable UI. (Google Navigation is probably pretty good (Google and I generally have similar ideas regarding UI design) but I haven't had a chance to use it yet.) They almost all do stupid stuff that just makes me shake my head in frustration.
For example, suppose I want to go to to my friend's house. Now I live in a city (as most people do) and I typically travel to places in the city. Sometimes I'll go on road trips, sure, but for the most part, I'm typically navigating to places in the same city as me. So I go to the GPS program, and most of them will say "please enter the city" or "search all cities" after I click "route me". So I've already had to click once (to search all cities) or clicked a whole lot of times (to type in the city name). The problem with the "search all cities" is that it is typically poorly implemented and makes the subsequent search really slow, so most people end up doing the "enter city" option and typing in their current city (or entering the zip code, but that's still at least 7 clicks.) Now, what I would do (were I to design a GPS app) is... well, duh, we already know what city the user is in. So don't even have that screen. Start on whichever screen we would put AFTER that screen, and at the bottom of THAT screen, have a button that says "( Searching in Austin, TX. Click here to change.)" It's just as clear what you are doing and saves the user a click (or possibly many clicks.) And even though we say we are searching only in their city that doesn't mean we actually have to. When we do the actual location search, we simply search their city first and if it's not in the city, we throw up a button that says: "No results found in the current city. Searching surrounding cities... click here to change cities." And just... GASP!... do shit for them that they probably wanted to do anyway!
Another annoying thing some GPS software does is to ask you for the street name before it asks you for the street number. This is nice because, for example, some streets only have addresses in the range 100-900 so they can then enforce some checks for you, or some streets may only have addresses starting with 12xxx so they can go ahead and auto-enter 12xxx. The problem though is that people don't remember addresses in this order, we think "232 lexington blvd., Austin, TX, 78777" not "Texas, Austin 78777, Lexington blvd. 232". It's jarring and unnecessary. I would much prefer to just have one window where I enter "232 lexington blvd." and it will just intuit "Austin, TX" because that's where I am at the time, and if I want to specify a different city, heck, I can type in a different city name! I know what city I'm in and I know my destination city, and it knows what city I'm in. therefore, if AB = AC and we both know what A is, then B = C. I know that the reason they ask for data in a specific order is to decrease the order of magnitude of the search space in their database, but it really hampers my ability to use the software, and with some cleverness, they can have the same reduction in search space without making it such a grating experience for me.
I'm sure some GPS software has this particular issue fixed, but there are just a huge amount of ideas that can be implemented to fix the user experience in other ways that just never come to fruitation. I could go on and on about this but I'll stop there for now.
I guess I'll go ahead and say this, but please no one take this out of context or blow it out of proportion please... it's really nothing major.
I'm a developer/programmer (I'm in my last semester getting a Master's in Computer Science) and I've been writing a GPS navigation application specifically for the Pandora. I don't know if it will ever get done enough to see the light of day, but I have already done some preliminary work on it. I'm just waiting for my Pandora so I can ramp up development on it. It's probably going to be the application that's my main development focus when the Pandora ships. It may take me a very long time to come out with this, if ever, so don't get too excited, but I have a huge list of grievances on navigation software and I think I know how to fix all of them to provide a much more seamless and pleasant user experience. The study of Human-Computer Interaction and User Interface Design are my passions and I'm really excited to start. When I have the Pandy in my hands and I've restarted development on the software, I will create a thread where we can discuss more in detail some progressive ideas to hopefully make some really great software, but right now it's mostly just an idea and a couple hundred lines of code. I really do hope I have the time to get it working, because it seems to me that really fantastic GPS software is basically nonexistent under Linux. And I think this community is really something great, and I think you guys probably have a ton of ideas as well on how to improve upon the state of the art (which is fairly immature as far as I can tell.) Heck, if you guys weren't easily dissatisfied with commercial efforts being lackluster you wouldn't be ordering an independently-developed handheld in the first place, would you?
Of course I'll see if I can just contribute to NavIT if/when I resume development, but I don't completely agree with some of their design decisions (anytime thousand-line XML files come up I sigh) so I may end up continuing with the project I've started from scratch.
Wow, that didn't end up being much of a summary, did it? Turned out to be longer than the previous post. Anyway, good night, everyone. Let's all cross our fingers that the February 13th deadline is reached and the first thousand Pandoras ship soon!
