GPS and Compass
AIman
Posts: 531
Has anyone used the GPS and Compass that Parallax sells?
If so was it a good or bad experience?
If so was it a good or bad experience?
Comments
window. The sensitivity appears to fairly good and accuracy
appears to match that of my Garmin.
<nit mode="picking">
I will say that I'm not completely happy with the software on the
SX that acts as a go-between (my BS2 and the actually GPS rcvr)
but I s'pose I could re-write it. Then again, what the software is
doing may be the best it can do as a result of an SX limitation (like
amount of RAM). I don't know much about the SX but while I can
appreciate what's going on doesn't mean I have to be happy about
it. Sorry... I'm not trying to act mean -- just a little disappointed.
</nit>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
I too wasn't very impressed with the SX code on the GPS module.
I have one and I plan to completely re-write it.
I love to hear any suggestions you have. How do YOU want it work.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·
If you're ready to learn I'll send you the SX Blitz. You aren't mean. Neither is Bean. Well, Bean . . . he only eats pizza and cheeseburgers. Still a nice guy, but if he handled the variety of food we eat at Parallax he'd be visiting us more often!
If you're ready to contribute to the quality of the product's firmware please let me know. Customer contributions are welcome for evaluation.
Ken Gracey
Parallax, Inc.
Sure, I'm ready to learn. 'preciate the offer!
And Bean needs to learn about Chili Dogs (Mexican-style) and Philly
Cheesesteak Subs for some variety.
Seriously now, y'all need to keep in mind that I have absolutely no knowledge
about the SX chips and their architecture so maybe I'm expecting too much.
So, with that in mind, allow me to suggest:
1) The way the software is currently written, each piece of data requested
will come from the next appropriate NMEA sentence coming off the GPS chip.
Thusly, requesting the current LATITUDE is fine but to get the LONGITUDE
the SX chips waits for the next GPMRC sentence (and position calculation)
coming off the GPS for that info. Consequently, each piece of data is not
"in sync" with a subsequent piece. True, this is not such a big deal when
the GPS is sitting on my window sill
be a little different story especially if it's moving kind fast. Oh, and it kinda
gives me "a wee bit of the willies". Maybe Parallax's intention for this product
was not to be in fast moving objects -- that's fine by me.
Possible solution: issue a command to the SX to "sample" the current GPS data.
The SX would store all the data from the next appropriate NMEA sentences read
off the GPS chip and reply with a good status or an error in the case of a timeout
or parsing error. Now, the BS can query the individual data pieces and they'd all
come from the same position calculation in the GPS.
Want the latest data? Issue another "sample" command. This would keep all the
GPS data "associated" and yet permit small processors like the BS, with small
amounts of RAM, to pull out bits and pieces and deal with it when it can handle them.
See, as I said, I was picking nits.
store the data (maybe in binary form) from the two(?) NMEA sentences it currently
parses?
2) Access to HDOP -- Horizontal Dilution of Precision -- this tells how good the GPS
thinks the satellites' geometry is affecting accuracy of its position calculations.
3) Access to LAT/LON in one command. Just sorta off the cuff -- it would be nice to
get these at the same time.
Again, I show my ignorance when I ask "Does the SX chip on the GPS module. with
the current application, have much memory remaining for expansion?"
I haven't done any calculations but I think my 'sample and get data' idea may result
in some savings in program memory 'cause each NMEA sentences are parsed only once,
in their entirety. The 'get data' portions would be simpler still.
Just my thoughts, for what they're worth.
Happy GPS'ing! (sorry JonW)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
Post Edited (Fe2o3Fish) : 9/28/2006 11:33:33 PM GMT
Seeing this code did however 'get me off my butt' and I started a SX project that will include a 'smart clock'. This code takes the time and date from the RMC sentence and converts it to local time. Still need to add the 'new' day light savings routine to it, maybe this weekend. Right now this code outputs mostly debug information so I can check it for being correct. A sample output is:
A 09/29/06 00:26:13 Friday 19:26:13 09/28/06 Thursday 04
Status, UTC Date, UTC Time, UTC Day of the week, Local Time, Local Date, Local Day of the Week, Local day of the week occurrence in the month
All time date calculations should be correct for years 2000 to 2099, for West of Greenwich. I've spot checked with a VB program outputting a manufactured $GPRMC sentence for various dates (leap years, day roll from 3/01 to 02/29, month rolls back, and year rolls back).
Posted for anyone that wants to use parts of it, feed back is welcome.
P.S. Rusty your just a few miles North of me! (kd5dhu)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
Post Edited (Mike Cook) : 9/29/2006 12:46:35 AM GMT
·
·· Your point is valid to a degree…If you were dealing with this data from a fast microcontroller such as another SX or the Propeller I could see where it could be an issue, especially if the unit was in high-speed motion.· The thing is that the daughter card on the GPS Module is mainly there to benefit slower microcontrollers with fewer resources.
·
·· In such a situation regardless of whether or not the GPS board gets all the data at the same time or not, the controller requesting the data is still only going to get it one value at a time and the data would most likely change anyway between reads.· Any controller sufficiently fast enough to handle the entire packet of data at once could use RAW Mode anyway, BS2p or higher for example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
And what's great is that it CAN be reprogrammed to be whatever you want.
Raise your hand if you have already soldered header pins on the programming pads. Yeah, me too.
P.S. Chili dogs and philly cheesesteak subs sound good to me. As long as there are no onions... And the chili is not too spicy... And the hotdogs are all beef... And the. . .
Okay, so I'm a picky eater. I think I told Ken this, but last time I let him take me out to eat, I just about threw-up. I had to stop eating the lemon chicken (ooh really adventurous). Then everyone made fun because I put sugar on my rice. Oh, well it was free...·A thousand "thank you"s to Chris Savage for choosing a pizza joint the next day (It's good to have a fellow·east-coaster there).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
Post Edited (Bean (Hitt Consulting)) : 9/29/2006 11:48:24 AM GMT
·
·· No problem!· I’m with you!· And if you ever come back my wife says she will make you her “East Coast” chili dogs and we’ll have onion free steak sandwiches!· Let’s not forget the cheeseburgers and Pizza!· Back to the subject at hand…I too am interested in hearing how everyone thinks the on-board SX/B code should function.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Steak sandwiches are good with just a little onion -- for just a touch of flavor.
If y'all come out to Dallas lemme know and I'll MAKE ya some of my good, award-winning
chili! And put 'em on some Texas-sized hotdogs if ya want. (Mexistyle is wrapping
the dog, chili, & cheese in a tortilla. That's what they told me in a little Mexican
restaurant in a mall in Maryland... run by a Vietnamese family! And there's less spillage!
Yes, I'm another East-coaster, originally.
Anyhoot, back to the obligatory Parallax-related topic...
Chris, I think you may have missed my point. It's not the speed of the attached
processor (BS2, PC, whatever) or getting one value at a time that's at issue. It's
that related data is coming from entirely different position calculations (with different
timestamps) within the GPS. I'm sure it probably doesn't matter to many folks but to
me and my fellow Texas Ham. Letting the SX chip buffer the data so a slow processor
can get it all is exactly what I'm suggesting.
Using something like my sample command to collect all the appropriate data before
making it available is still usable by even the most utterly and pathetically slow
processors but related data still stays together.
And data that stays together, calculates together! <whatever -- it's late>
This uses the SX like it's s'pose to be, even more so, for computron-challenged 'puters.
If I was using a fast attached-processor I'd go for the RAW and my point would be moot.
To exasperate and exaggerate the subject even more -- it would be like collecting data
from a cyclist as to his speed and cadence during a race. The code for the SX is taking
the speed at one point in time (say going uphill) but taking the cadence reading on the
downside of the hill and calling these data related.
Still, the fact that the SX processor can be reprogrammed is one of the greatest things
I like about this product!!! And I do like this product, make no mistake about that.
If Ken sends me that SX Blitz I can make my suggestions reality in short order, I hope.
Now, where's that soldering iron?? And who else is hungry? :-D
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
hmm...maybe it's time to start learning the SX...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
·
·· I see the point you’re both trying to make, but I think the one point that is being missed is that unless you are able to get all the data at once onto the host controller there is no possible way to have all the values be in sync while at the same time being up to date.·
·
·· Think of it this way, if you were to parse the whole string on the SX/GPS side of things, the host computer can only request one value at a time and at 4800 bps.· Traveling at a high rate of speed (as suggested) by the time the next value was gotten the positional coordinates buffered would be inaccurate since the GPS is in motion.
·
·· Now, on the other hand, if you had kept reading the entire string repeatedly, it still wouldn’t matter because, again, by the time the next read occurred by the host controller the data (string) would have changed.· I know this is undesirable to some but the only way to not have this occur is to read all data onto the host controller at once.· The problem here is that some microcontrollers (such as the BS2) cannot do this easily or not at all.· This is why the “smart” mode (SX controller) is there on the GPS.
·
·· On host controllers fast enough to get the entire GPS string the SX co-processor isn’t needed and therefore the issue becomes moot since these controllers can simply read the entire string and grab the relevant data fast enough to use before the next read.· About the only thing I could suggest is that you could modify the SX/B code to read the entire string on command and not re-read it until you sent a command to do so.· But then the possibility exists that, at high-speed the data will be inaccurate by the time the second or third value were read.· I would certainly be interested in hearing anyone’s thoughts on this.· Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
I would have to disagree, at least,in part, with your initial statement. The validity of the data as it relates to the speed of the device is not in question. It is the validity of the data-packet taken as a whole. If you are having to get your latitiude and longitude from two different reads of the GPS, the overall picture is of a "place that the device never was". If the data all comes from one read, then either the software can make allowances knowing that the data refers to a "real" situation and the device is in motion or, at least, can accurately report and work with the "real" positions that it passed through (taking into account the nature of GPS, of course).
...or have I misunderstood you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
·
·· I think you misunderstood me.· If you read two different values from the GPS Module at 4800 bps, it doesn’t matter whether they are from the same packet of data or not.· The device is still in motion and by the time the second read occurs the data second part of the data (perhaps even the first) may no longer be accurate for the new position of the GPS Module.· It’s really the same effect in the end as reading two different packets.· I guess you could say the argument works both ways.· Let’s not forget the most important aspect of high-speed travel…The GPS isn’t sending the data in real-time anyway.· At 4800 bps it takes a finite amount of time to send all of the strings (there are several) and in that time the coordinates will change when the device is in motion.· I hope this clarifies what I was trying to say.
·
· ·In any event you can always reprogram the SX chip to your own specifications and possibly include some code in there to compensate for the motion.· It seems in the sense of what you were trying to say it would be better for you to read the latitude and longitude at the same time.· This would provide the greatest accuracy for that particular reading taking into account the amount of time to retrieve the data at 4800 bps and process it.· I hope this helps.· Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
·Just because I haven't had this kind of discussion for a very long time [noparse];)[/noparse]· Perhaps my quick Paint graphic will illustrate what I'm trying to convey.
Let's assume the following conditions:
· The·GPS starts out at the origin (0,0) moving on a heading of 45 degrees (black dot).· It is moving at such a speed that it travels from one corner of a grid square to the opposite corner of that grid square in the same amount of time that it takes to take 2 successive readings from the GPS.
·So, at time period 1, we request a position.· The GPS instantly reports the latitude as 1 (purple dot), and then 1 time period later, reports the longitude as 2 (since by time period 2 the GPS is at the blue dot).· So our processor is convinced that we were at 1,2 (red dot)...a place we have never been.
·Admittedly, this is a somewhat fabricated set of circumstances, but I think that it illustrates that the reported positions would only loosely be tied to reality, severely compounded by the fact that course changes would only·magnify the difference between report and reality.· Pulling both latitude and longitude from the same GPMRS string should at least give a valid correlation between the two values since the GPS·builds the whole string at once before sending it out.· Any error would be in the GPS, itself.
Thanks for the stimulation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
·
·· I understood what you meant.· And it is a valid point if you plan on moving at such a speed where this would crop up.· At the same time I must admit that if I were designing something to move at such a speed I would not be using the “smart mode” in the first place as it would take too long to get all the data.· In such a case the on-board module is bypassed by grounding the /RAW pin.
·
·· I hope others watching this thread fully understand and appreciate the subject and concepts being shared here.· This is truly an expanded topic on GPS usability, however in the whole scheme of things there may be something pertinent to this discussion which may or may not also negate the potential error of getting the readings at a different time.· That is the inherent error that is part of most GPS systems anyway.· The accuracy is not down to the inch or even foot, and for many systems can be several yards.
·
·· To truly appreciate compensation of error in the X,Y readings you would also have to account for the travel speed and lag time.· That is, referring to you diagram…It would seem in the scenario you mentioned that if you take a reading at point 1,1 that your could actually be at 2,2 by the time the reading was parsed and computed.· Again, this introduces another inaccuracy.· These are all things to keep in mind for high-speed use of the GPS, though I suspect most will be using this on Robots such as those used for Robo-Magellan contests.· Bikes, Cars and even R/C Planes are sure to be part of the mix.· If everyone shares their experiences and code modifications I’m sure in the end everyone will have what they want.· Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·
The whole situation is definitely contrived...the only point I was trying to make was that if you took data from two different sentences, then the data itself was unreliable and didn't represent any reality...since you got your horizontal from one point in time and your vertical from another.
In short, no more than the type of theoretical discussion that doesn't generelly interest many but that hit one of my buttons.
Thanks for the repartee.
We now return you to your regularly scheduled technical Q and A...[noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
I currently have several types of microcontrollers (BS2, Propeller and SX), My intent was to run the GPS either straight into the SX or Prop, but with the discussion going on will these need·to link the a laptop or computer?
The compass was to cross check the GPS heading to maintain accuracy. I want to be as accurate as possible and if memory serves the GPS only updates once a second. If I use more then one - say start one every quater second - will I be able to get more frequent readings?
So here is my next question. If I take the GPS·and pull velocity and heading and compare the heading against the compass to get a correct heading; then by calculating out my speed, adjusting the Lat/Long accordingly will the measurement be accurate?
More to the point do I even need·to if the Computer/Prop/SX is fast enough?
And what about loading in GPS points? Can I do that via USB? It would be nice to be able to plot out my route and follow the points, not just collect data.
I get bored driving, can you tell?
Post Edited (AIman) : 10/2/2006 4:19:18 PM GMT
At crusing speed the GPS will typically provide a better heading than a compass. This is because of magnetic declination and magnetic deviation, the first is due to the fact that magnetic north is different than true north, and it's position shifts every year making a NNW trek of 81 km per year on average. This results in a -20 degree variation in Seattle WA and·19 degree variation in·in Portland ME. Heres a map of the declination for the US in 1990, this map changes a little every year (in the late 70s-early 80s·the 0 degree line passed through the Florida peninsula, in 1990 it passed through Fort Walton, FL which is in the furthest west portion of the panhandle):
Deviation is caused by local disturbances in the field such as nearby metal objects (your car), iron ore deposits and mountains. The sattelites used in GPS do not suffer from either of these errors. The error for the GPS heading is based on which sattelites·are used (one on the horizon produces more error than one directly above), the number of sattelites used, location error (approximately 3m, but this fluctuates), and vector error (the distance between samples). At highway speeds, the GPS will provide a much more accurate bearing than a compass unless you are within a 100 miles·of 0 declination line. Fortunately GPSs provide a string to indicate the degree of position error (DOP) to give you an idea of the degree of error for the data provided.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
http://www.ngdc.noaa.gov/seg/geomag/img/us_dec_8x11.pdf
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
for the receiver. I could be wrong but the electronic compass may need to be re-calibrated
(if it can be) to be usefully accurate around all that ferrous metal in the car.
If all you want are position, velocity, and bearing readings, a BasicStamp2 should be sufficient.
Depends on how accurate you want to be.
commercial GPS handheld unit then yes, you'll probably want something with a little bit
more computational UMPH! than an SX or Prop. Well, maybe you can get by with a Prop
depending on what you want to do. If you're wanting to use GPS points (navigators call
them 'waypoints') a little spherical geometry and floating point routines will make things
easier for you, the programmer. Yes, you can probably get by with integer approximations
but the accuracy may not be as good and will be a bit more difficult to code.
You have to ask yourself this question: How much accuracy do I really NEED?
Oh yeah, another good question would be: How much accuracy can I obtain?
Alas, you can't tell the GPS when to start sending you data and you can't "sync" the
GPS modules together. Each will be spitting out valid data after each locks onto the
proper number of satellites. Trust me -- you can not put X number of GPS's together
and get them sync'd nor spitting out THE EXACT SAME POSITION because they will have
started their calculations, at best, milliseconds apart. I don't care if you do feed the
power to each through the same switch! A satellite at 12,500-miles travels a noticable
distance and a computer can calculate a fair bit in a millisecond!
I don't believe that the compass, in a metal vehicle, will be as accurate as a GPS.
Frankly, have you looked at the spec for the Hitachi compass module? Compass
direction is limited to 64 directions AFTER calibration. 360-degrees/64 is just under
6-degrees. Look at the NMEA sentences that the GPS module puts out -- your
heading accurate to about 1/10-degree (give or take a tad). So long as you're
moving, the GPS will give you an accurate heading.
To reinforce my previous answer, No.
I can tell but how 'bout keeping yer eyes on the road???!!!???
Some laws have states, er.... some states have laws with regards to the driver
being able to see a computer screen while he/she is driving! Some don't allow it
at all!
If you want to plot yer route and what not, yer best bet would be to provide
RS-232 conversion from the GPS module's output to the PC's serial port, and
go with a commercial mapping program, say Microsoft MapPoint or Rand-McNally's
software (can't recommend DeLorme for accuracy). Still, an inexpensive GPS
and mapping software combo deal would be easiest and more than accurate for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
neither at the horizon NOR directly above. The only good a sat directly above you helps
at all is in your altitude calculations. The best positions for your sat's will be evenly
distributed throughout the sky midway 'tween your zenith and the horizon. Kinda like 2D
triangulation -- you don't want your reference points close together otherwise your position
error goes up! GPS is like this but in 3D, well 4D actually.
L1/L2 GPS units (like what our military uses) can compensate a fair bit for ionospheric diffraction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
·
·· I would have to say that an SX and/or a Propeller would be overkill for processing the data from a GPS Module and providing whatever accuracy is needed.· For the most part all of the data is provided within the NMEA strings, you need only present it to the user.· For this purpose even a BS2p is capable of that for the most part.
Edit: In retrospect I guess my wording should have been, "More than capable" rather than, "overkill".· As a co-worker pointed out to me, the Propeller could also be displaying way-points and mapping information on a monitor or NTSC Display and doing any number of other tasks, all without taking anything away from the GPS processing time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Post Edited (Chris Savage (Parallax)) : 10/3/2006 4:02:45 PM GMT
Sorry, I s'pose I probably shouldn't be saying anything about the Prop. Sure, pulling
numbers from a data stream and putting them on a display is child's play. That's not a
big, hairy deal. I was figuring more from the programming side as opposed to that of a
pure controller and I should have said that. I've done the floating point calc's for the
spherical geometry needed when a UI has to deal with waypoints and courses and bearings.
Not real nasty but not something for the average Stamp programmer. If the Prop can do
floating point without the hassle of fixed point estimation like the BS2 then clearly I'm
wrong and for that I humbly apologize to the Prop crew.
On the other hand, if floating point is not an integral part of the Prop then, while the Prop
may be able to do the job, the calculations will be a major pain in the Smile to write especially
while being watchful of how well accuracy is maintained through those calculations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
·
·· The Propeller can do Floating Point through an object created for it.· I guess I can just see someone going and making a hand-held GPS unit from a Propeller, small LCD Display from a cell phone and the GPS module itself…Probably have a flash card with local maps on it…Yeah, this could happen.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
·
·· You can find that at the bottom of the following thread.· Take care.
·
http://forums.parallax.com/showthread.php?p=605561
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Post Edited (Chris Savage (Parallax)) : 10/5/2006 4:23:23 AM GMT
How does the GPS from Parallax compare to others? My main concern is accuracy of location, direction, speed and uploading of LOTS of waypoints.
How easily can this be done?
The Garmin GPS18 is a simple GPS sensor with ability to plug in, that to would require a screen of some sort, but this would end up going into my computer to track the progress of the route taken.
In short, I am still confused about the specs espically the ones just mentioned.
Heck, go through the .PDF manual for it too. Guess what? You will not find ANY mention
of uploading waypoints to this GPS module. In this world, 99 times out of 100, if a feature isn't
mentioned on the box or in the documentation then the unit doesn't have that feature.
Supply a processor, memory for your waypoints, and programming for downloading your waypoints
amongst other needs for collecting data from the GPS.
Basically the Parallax GPS module is similar to the GPS18 but without the RS-232 level converters
for communications with your PC's serial port.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Rusty-
--
Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking