Jon:
Thanks for doing this. Since I know all your work is first-rate in the end, I just placed an order for 3 units of the OEM GPS and antennas on ebay.
Some Suggestions:
Include solutions for feeding output to Sx (in addition to STAMP)
Your project spec talks about feeding to STAMP. Can we also work out any problems associated with feeding to SX? Ideally, your buffer board could fit onto the SX48 protoboard. That could be mounted to OEM GPS and antenna for a complete package the size of a pack of cigs.
Consider start-up of the whole system
I've found with GPS the whole start-up routine creates issues from STAMP's viewpoint if the whole operation is autonomous. For example, to get hourly readings timed by the STAMP, we have to wake the stamp, then wake the buffer board(?), start power to the GPS, wait for gps to retrieve almanac (a variable time since we don't know if in warm or hot read state), wait for GPS to get satellite lock, wait for GPS to get reading, (reiterate back if more satellites are locking?), request the data from GPS to buffer board to STAMP, then shut it all down. To make this easier (and preserve batteries) it would be good to be able to get the state of the GPS after giving it power. In short, when is the GPS ready to give me a reading so I can get the reading and power down?
Report number of satellites locked and accuracy
I find on my Garmin that as soon as I get a lock on a three satellites it gives me a report on accuracy and a reading. Then in a few seconds it locks more satellites and gives a better accuracy and reading. So I am thinking that at some early point in the boot a reading is available, but that is not the best reading we can get if we just let the satellite locking finish for a minute. (This is separate from the change in readings and accuracy over many minutes as satellites come in and out of view). It would be useful if the buffer board could tell my STAMP the current accuracy. Then I can make a decision whether or not to wait a few seconds for better accuracy. In other words, we may not want to just grab the very first location that the GPS produces. Alternatively (thinking of a bear-tracking collar) we would like to know the number of satellites locked. Then in my STAMP I can say “if I can’t get >=x number of locks, then try again in five minutes.”
Consider completely autonomous operation
When you think about applications, write up scenarios and test solutions, consider two scenarios. The first is attended, where an operator is around to power up, get data, etc. The second case is a GPS & STAMP recording data for a month on a bear-tracking collar. Everything has to be completely autonomous (or else we send Jon within range of the grizzly's teeth to flip the necessary switch).
Someone write a short discussion on data storage capacity
Although not strictly part of your project, I think it would be great to have some notes on how many locations could be saved with various STAMPS, and how to optimize that quantity. For example, I'd like to know before starting if I can save 10, 100 or 1000 locations on a BS2 before I have to retrieve my bear-tracking collar. How many locations do I give up by including minutes and seconds in the time data? Again, this is outside the scope, but I'm sure you or others have thought about it and a couple of paragraphs would be a big help (and would help sell the more expensive STAMP models).
Someone write similar discussion for power consumption & battery life.
How to minimize power consumption in an entire system? Bears hate it when I have to change their batteries. Perhaps references to discussion (or a customer application page) on what it takes for solar power of the whole unit.
Again, Jon I completely realize some of this is outside the scope of your buffer board, but they are the final touches that will actually make this a complete and desirable solution. Let me know if I can help with testing.
My first post in the forum, on a subject that deals with my first BS project.... cool....
I'm working towards using a BS2p to parse the NMEA output from my Garmin 60C GPS and flash some LEDs/sound a tone so that I can recreate the functionality of this GPS for autorouting while riding a motorcycle. (The GPS only has a Pizzo speaker for sound output so I can't hear it while at freeway speeds on the bike)
I'm using the $GBRMB string to calculate times to turn so that I can get a 2 minute warning (using current speed and distance to next waypoint), I'll use the arrived at waypoint flag to give me a "turn now" indication.. I may use bearing information to give me a turn direction and flash appropriate leds (with the option of using a voice chip in the future and actually piping words into my intercom)... depending on how reliably it works out in use (bearing to next turn may not have much in common with direction of turn at 2 minutes... besides, I have the GPS giving me this info)
I'll also want to use the $GPBOD string because here the name of the next waypoint is in full length format, and the above waypoint string is truncated a lot. I mean to display this on a serial LCD.
I'll also display the temperature, Distance to next waypoint, altitude, and perhaps the time (from GPS) if I have the resources available in the end...
Hope this helps you... It'd be awesome to not be stuck for timing by waiting for the next appropriate string to come in to grab these variables...
Jon:
Thanks for doing this. Since I know all your work is first-rate in the end, I just placed an order for 3 units of the OEM GPS and antennas on ebay. · ·
Some Suggestions: · Include solutions for feeding output to Sx (in addition to STAMP)
Your project spec talks about feeding to STAMP. Can you also work out any problems associated with feeding to SX? Ideally, your buffer board could fit onto the SX48 protoboard. That could be mounted to OEM GPS and antenna for a complete package the size of a pack of cigs. · Consider start-up of the whole system
I've found with GPS the whole start-up routine creates issues from STAMP's viewpoint if the whole operation is autonomous. For example, to get hourly readings timed by the STAMP, we have to wake the stamp, then wake the buffer board(?), start power to the GPS, wait for gps to retrieve almanac (a variable time since we don't know if in warm or hot read state), wait for GPS to get satellite lock, wait for GPS to get reading,· (reiterate back if more satellites are locking?), request the data from GPS to buffer board to STAMP, then shut it all down. To make this easier (and preserve batteries) it would be good to be able to get the state of the GPS as soon as possible afterSTMAP wakes. In short, when is the GPS ready to give me a reading so I can get the reading and power down? · Report number of satellites locked and accuracy
I find on my Garmin that as soon as I get a lock on a three satellites it gives me a report on accuracy and a reading. Then in a few seconds it locks more satellites and gives a better accuracy and reading. So I am thinking that at some early point in the boot a reading is available, but that is not the best reading we can get if we just let the satellite locking finish for a minute. (This is separate from the change in readings and accuracy over many minutes as satellites come in and out of view). It would be useful if the buffer board could tell my STAMP the current accuracy and/or number of satellites locked. Then I can make a decision whether or not to wait a few seconds for better accuracy. In other words, we may not want to just grab the very first location that the GPS produces. Alternatively (thinking of a bear-tracking collar) we would like to know the number of satellites locked. Then in my STAMP I can say “if I can’t get >=x number of locks, then try again in five minutes.” · Consider completely autonomous operation
When you think about applications, write up scenarios and test solutions, consider two scenarios. The first is attended, where an operator is around to power up, get data, etc. The second case is a GPS & STAMP recording data for a month on a bear-tracking collar. Everything has to be completely autonomous through cycles of power-up and power save modes (or else we send Jon within range of the grizzly's teeth to flip the necessary switch). · Someone write a short discussion on data storage capacity
Although not strictly part of your project, I think it would be great to have some notes on how many locations could be saved with various STAMPS, and how to optimize that quantity. For example, I'd like to know before starting if I can save 10, 100 or 1000 locations on a BS2 before I have to retrieve my bear-tracking collar. How many locations do I give up by including minutes and seconds in the time data? Again, this is outside the scope, but I'm sure you or others have thought about it and a couple of paragraphs would be a big help (and would help sell the STAMP models with higher capacities). · Someone write similar discussion for power consumption & battery life.
How to minimize power consumption in an entire system? Bears hate it when I have to change their batteries. Perhaps references to discussion (or a customer application page) on what it takes for solar power of the whole unit. ·
Again, Jon I completely realize some of this is outside the scope of your buffer board, but they are the final touches that will actually make this a complete and desirable solution. Let me know if I can help with testing.
Thanks for your confidence in my abilities, John.· As soon as I get settled in southern California (moving shortly!) I will get back to this project.· The code will be written in SX/B and open-sourced so that others can adapt and improve it where possible.· With the interest in GPS, this should be a fun community project.
Happy Holidays!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Jon Williams Applications Engineer, Parallax
Comments
Thanks for doing this. Since I know all your work is first-rate in the end, I just placed an order for 3 units of the OEM GPS and antennas on ebay.
Some Suggestions:
Include solutions for feeding output to Sx (in addition to STAMP)
Your project spec talks about feeding to STAMP. Can we also work out any problems associated with feeding to SX? Ideally, your buffer board could fit onto the SX48 protoboard. That could be mounted to OEM GPS and antenna for a complete package the size of a pack of cigs.
Consider start-up of the whole system
I've found with GPS the whole start-up routine creates issues from STAMP's viewpoint if the whole operation is autonomous. For example, to get hourly readings timed by the STAMP, we have to wake the stamp, then wake the buffer board(?), start power to the GPS, wait for gps to retrieve almanac (a variable time since we don't know if in warm or hot read state), wait for GPS to get satellite lock, wait for GPS to get reading, (reiterate back if more satellites are locking?), request the data from GPS to buffer board to STAMP, then shut it all down. To make this easier (and preserve batteries) it would be good to be able to get the state of the GPS after giving it power. In short, when is the GPS ready to give me a reading so I can get the reading and power down?
Report number of satellites locked and accuracy
I find on my Garmin that as soon as I get a lock on a three satellites it gives me a report on accuracy and a reading. Then in a few seconds it locks more satellites and gives a better accuracy and reading. So I am thinking that at some early point in the boot a reading is available, but that is not the best reading we can get if we just let the satellite locking finish for a minute. (This is separate from the change in readings and accuracy over many minutes as satellites come in and out of view). It would be useful if the buffer board could tell my STAMP the current accuracy. Then I can make a decision whether or not to wait a few seconds for better accuracy. In other words, we may not want to just grab the very first location that the GPS produces. Alternatively (thinking of a bear-tracking collar) we would like to know the number of satellites locked. Then in my STAMP I can say “if I can’t get >=x number of locks, then try again in five minutes.”
Consider completely autonomous operation
When you think about applications, write up scenarios and test solutions, consider two scenarios. The first is attended, where an operator is around to power up, get data, etc. The second case is a GPS & STAMP recording data for a month on a bear-tracking collar. Everything has to be completely autonomous (or else we send Jon within range of the grizzly's teeth to flip the necessary switch).
Someone write a short discussion on data storage capacity
Although not strictly part of your project, I think it would be great to have some notes on how many locations could be saved with various STAMPS, and how to optimize that quantity. For example, I'd like to know before starting if I can save 10, 100 or 1000 locations on a BS2 before I have to retrieve my bear-tracking collar. How many locations do I give up by including minutes and seconds in the time data? Again, this is outside the scope, but I'm sure you or others have thought about it and a couple of paragraphs would be a big help (and would help sell the more expensive STAMP models).
Someone write similar discussion for power consumption & battery life.
How to minimize power consumption in an entire system? Bears hate it when I have to change their batteries. Perhaps references to discussion (or a customer application page) on what it takes for solar power of the whole unit.
Again, Jon I completely realize some of this is outside the scope of your buffer board, but they are the final touches that will actually make this a complete and desirable solution. Let me know if I can help with testing.
I'm working towards using a BS2p to parse the NMEA output from my Garmin 60C GPS and flash some LEDs/sound a tone so that I can recreate the functionality of this GPS for autorouting while riding a motorcycle. (The GPS only has a Pizzo speaker for sound output so I can't hear it while at freeway speeds on the bike)
I'm using the $GBRMB string to calculate times to turn so that I can get a 2 minute warning (using current speed and distance to next waypoint), I'll use the arrived at waypoint flag to give me a "turn now" indication.. I may use bearing information to give me a turn direction and flash appropriate leds (with the option of using a voice chip in the future and actually piping words into my intercom)... depending on how reliably it works out in use (bearing to next turn may not have much in common with direction of turn at 2 minutes... besides, I have the GPS giving me this info)
I'll also want to use the $GPBOD string because here the name of the next waypoint is in full length format, and the above waypoint string is truncated a lot. I mean to display this on a serial LCD.
I'll also display the temperature, Distance to next waypoint, altitude, and perhaps the time (from GPS) if I have the resources available in the end...
Hope this helps you... It'd be awesome to not be stuck for timing by waiting for the next appropriate string to come in to grab these variables...
Any idea on a timeframe for you to be done?
Al...
Thanks for doing this. Since I know all your work is first-rate in the end, I just placed an order for 3 units of the OEM GPS and antennas on ebay.
·
·
Some Suggestions:
·
Include solutions for feeding output to Sx (in addition to STAMP)
Your project spec talks about feeding to STAMP. Can you also work out any problems associated with feeding to SX? Ideally, your buffer board could fit onto the SX48 protoboard. That could be mounted to OEM GPS and antenna for a complete package the size of a pack of cigs.
·
Consider start-up of the whole system
I've found with GPS the whole start-up routine creates issues from STAMP's viewpoint if the whole operation is autonomous. For example, to get hourly readings timed by the STAMP, we have to wake the stamp, then wake the buffer board(?), start power to the GPS, wait for gps to retrieve almanac (a variable time since we don't know if in warm or hot read state), wait for GPS to get satellite lock, wait for GPS to get reading,· (reiterate back if more satellites are locking?), request the data from GPS to buffer board to STAMP, then shut it all down. To make this easier (and preserve batteries) it would be good to be able to get the state of the GPS as soon as possible afterSTMAP wakes. In short, when is the GPS ready to give me a reading so I can get the reading and power down?
·
Report number of satellites locked and accuracy
I find on my Garmin that as soon as I get a lock on a three satellites it gives me a report on accuracy and a reading. Then in a few seconds it locks more satellites and gives a better accuracy and reading. So I am thinking that at some early point in the boot a reading is available, but that is not the best reading we can get if we just let the satellite locking finish for a minute. (This is separate from the change in readings and accuracy over many minutes as satellites come in and out of view). It would be useful if the buffer board could tell my STAMP the current accuracy and/or number of satellites locked. Then I can make a decision whether or not to wait a few seconds for better accuracy. In other words, we may not want to just grab the very first location that the GPS produces. Alternatively (thinking of a bear-tracking collar) we would like to know the number of satellites locked. Then in my STAMP I can say “if I can’t get >=x number of locks, then try again in five minutes.”
·
Consider completely autonomous operation
When you think about applications, write up scenarios and test solutions, consider two scenarios. The first is attended, where an operator is around to power up, get data, etc. The second case is a GPS & STAMP recording data for a month on a bear-tracking collar. Everything has to be completely autonomous through cycles of power-up and power save modes (or else we send Jon within range of the grizzly's teeth to flip the necessary switch).
·
Someone write a short discussion on data storage capacity
Although not strictly part of your project, I think it would be great to have some notes on how many locations could be saved with various STAMPS, and how to optimize that quantity. For example, I'd like to know before starting if I can save 10, 100 or 1000 locations on a BS2 before I have to retrieve my bear-tracking collar. How many locations do I give up by including minutes and seconds in the time data? Again, this is outside the scope, but I'm sure you or others have thought about it and a couple of paragraphs would be a big help (and would help sell the STAMP models with higher capacities).
·
Someone write similar discussion for power consumption & battery life.
How to minimize power consumption in an entire system? Bears hate it when I have to change their batteries. Perhaps references to discussion (or a customer application page) on what it takes for solar power of the whole unit.
·
Again, Jon I completely realize some of this is outside the scope of your buffer board, but they are the final touches that will actually make this a complete and desirable solution. Let me know if I can help with testing.
Happy Holidays!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax