Shop OBEX P1 Docs P2 Docs Learn Events
Balloon Project — Parallax Forums

Balloon Project

Earl FosterEarl Foster Posts: 185
edited 2007-01-22 18:51 in BASIC Stamp
I am starting a high altitude project with hopes of launching in the spring.· Now I know it has been done by lots of people but it hasn’t been done by me.· I figured I would start this project·thread under this section of the forum and continue to post any problems·I can’t resolve on my own in this thread as I progress through the project.
·
I have 6 objectives:
··········· Obtain photographs of the Earth’s curvature at > 90,000 feet
··········· Record external and internal (payload) temperatures every 5K feet
··········· Record GPS data: Lat, Long, Alt every 5K feet
··········· Record velocity during ascent and descent every 5K feet
··········· Track payload
··········· Recover payload
·
I have already worked through the first, second, and most of the third objectives.· I have run into 2 problems that I haven’t been able to solve.· The first is the hemisphere data and the second is variables in the GPS string.· I have read over and tried to understand Jon William’s Nuts & Volts articles #83 and #103 and apply them to my project but I can’t get altitude the same he did because my GPS does not generate PGRMZ.· In addition, the program takes up 76% of my code space.· So I also started modifying his Easy_GPS code which seems to work better for my needs.· And this is where my 2 problems popped up.
·
Problem 1: I expected to see latHemi displayed as N or S and lonHemi displayed as E or W from my GPS which it does generate (Attachment1.jpg).· Instead I am getting the number 44 for both which causes my subroutine to be invalid (Attachment2.jpg).
·
I have tried specifying the variables as different types but the results do not conform to the appropriate binary, decimal, or hex values for N, S, E, or W.· I figure it is the way I have the SERIN command setup. ·I would appreciate some ideas because I have run out of ideas.
·
Problem 2: Variable length fields.· Jon tackles this problem in article #83 and #103 where you read the sentence in as a string.· And while I liked this approach I ran into other problems because I have to extract all my information from one NMEA sentence.· So I am back to the Easy_GPS code.· HDOP (Horizontal Dilution of Precision – angle between the satellites) can be 4 characters long and sits right in front of altitude.· Right now I have compensated it by knowing the value of HDOP is 1.9 at my present location.· You can see from my code that I SKIP 10 to get to altitude.· The satellite field that I am skipping will transmit leading zeros and is a fixed length but HDOP values could change during the flight.· Therefore I have to be able to handle the variable length field. ·I was wondering how I can account for variable length fields using the Easy_GPS code approach.· Any thoughts or suggestion would be appreciated.
·
Final thought – it is not at all unlikely that I am going about this all wrong.· And that I am overcomplicating a simple task.· If that is the case then I would greatly appreciate a course correction.
623 x 258 - 34K
623 x 368 - 34K

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-01-09 00:44
    This project is being moved from the Projects Forum to the BASIC Stamps Forum, since it is not a completed project.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-10 04:58
    I figured out my 2 problems.· I wasn't skipping a comma separator and I forgot to use the STR variables with delimiters.· So it turns out it was the way I was reading in the sentence.· The attached code will now read in the GPGGA sentence with variable length fields and display Time, Altitude, Latitude, and Longitude.

    I cleaned up the code a little. I was using some variables and·subrountines for troubleshooting.· No point in taking up space if it isn't required.

    Post Edited (ebf306) : 1/10/2006 11:01:45 PM GMT
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-15 01:28
    Is it possible to store your program declarations on external memory using the BS2 or BS2p24?

    I will be using the 24LC32A for storing·my flight data and I was wondering if I could use it for declarations too.· If not then I will have to have my variables pull double duty.

    BTY - I uploaded my schematic for the project
    962 x 722 - 135K
  • GrendelTGrendelT Posts: 23
    edited 2006-01-15 02:20
    Awesome! Good luck with this. I, too, have aspirations for a High Altitude Balloon.
    My project -> neodux.com/forums/viewtopic.php?t=306

    *I started that post before I got a stamp for Christmas...

    Post Edited (GrendelT) : 1/15/2006 2:24:24 AM GMT
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-16 16:42
    It seems I haven't resolved my GPS issue.·My SERIN command of GPGGA is recording the fractional minutes incorrectly in the latitude field or my debug is showing it incorrectly on the screen.· Its the only·field that is displayed incorrectly.·

    The code I am using is this:

    · SERIN GPSpin, N4800, 3000, No_GPS,···················· ' Setup link to GPS
    ······· [noparse][[/noparse]WAIT("GPGGA,"), DEC2 hr, DEC2 mn, DEC2 sc,···' Get time
    ········ DEC2 latD, DEC2 latM, DEC4 latF,· SKIP 2,··' Get Lat minus Hemisphere
    ········ DEC3 lonD, DEC2 lonM, DEC4 lonF, SKIP 8,··' Get Long minus Hemisphere and skip SAT
    ········ STR HDOP\4\",", DEC5 alt, DEC falt]······' Get height
    The actual latitude here is 3255.6737 which I have varified via my other GPS's but what·is displayed by my·debug command is 3255.1826.

    If I display just latF I get 11826 which is just wrong.· All the other values are captured and displayed correctly (before and after latF).

    my baud rate is set to 16884 for the BS2p.· I have initiallized latF to 0.· I have tried breaking my SERIN command up into multiple parts.·

    The closest I have come to solving the problem is breaking up latF into 2 pieces.· Instead of DEC4 latF I used DEC2 latF, DEC 2 latG.· This shows the correct number until the GPS acquires, then my No_GPS subroutines activates.· Which completely doesn't make any sense to me why that is happening.

    I could really use some help here if anybody has a suggestion.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2006-01-16 17:10
    It's the way that you're retrieving·seconds -- seconds comes back as ss.sss in GGA (6 bytes: it's the whole number seconds, the decimal pt, followed by three fractionals/decimal places).· [noparse][[/noparse]UTC Time = hhmmss.sss]· So, I·figure you need to account for the ".sss" with a SKIP4·(assuming you don't "want" them) and then you can begin your LAT dd capture.·

    Make sense?·
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-16 17:40
    Garmins GPGGA only trasmits hhmmss for UTC. When I capture the data using the SPSTR command all the information is captured and displayed correctly

    173514,3255.6718,N,09635.9963,W,1,06,2.4,166.9,M,-24.9,M,,*7A

    I stop using captured data before the first "M" using the my method above and only the 6718 is incorrectly display or captured. All the other number are displayed correctly

    and here is my display commands

    hr = hr - CST ' Set time to Garland, TX
    DEBUG HOME, ' Show captured data to screen
    "Time: ", DEC2 hr, ":", DEC2 mn, ":", DEC2 sc, CR, ' Show Time
    "Altitude: ", DEC alt, ".", DEC falt, " Meters", ClrRt, CR, ' Show Altitude
    ' Show Latitude coordinates in degrees and decimal minutes
    "Latitude: ", "N ",DEC2 latD, DegSym, " ", DEC2 latM,".", DEC4 latF, MinSym, ClrRt, CR,
    ' Show Longitude coordinates in degrees and decimal minutes
    "Longitude: ", "W ",DEC2 lonD, DegSym, " ", DEC lonM, ".", DEC4 lonF, MinSym, ClrRt,CR
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2006-01-16 17:54
    Maybe this is one of those things where the decimal formatter can't keep up with the speed.· Does the Garmin use the NMEA (4800, 8N1, ASCII) or is it running 9600 or something?· If it's not 4800 and you can change the bps, then try 4800.



    Post Edited (PJ Allen) : 1/16/2006 6:12:56 PM GMT
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-16 18:11
    I tried adding the skip 1 statement and it it the same results. Instead of getting 6718 I get 1826 every time. It seems that when you are working with the DEC command it stops reading at the decimal. If I increase the to DEC5 then I 11826 as the number where I should still be getting 6718.
  • steve_bsteve_b Posts: 1,563
    edited 2006-01-16 20:19
    I ran in to some issues trying to grab the GPS stream as well (for a different project).
    JonW. can jump in....but they're not fixed fields. Although they are comma delimited.
    So you have to capture the entire string and then parse it out. Hard to do on the fly unless you have a scratchpad to work with (which is why a lot of JOns examples use the BS2p)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2006-01-16 21:10
    The data format = 173514,3255.6718,N,09635.9963,W,1,06,2.4,166.9,M,-24.9,M,,*7A

    The capture begins with:

    WAIT("GPGGA,")[noparse][[/noparse]DEC2 hr, DEC2 mn, DEC2 sc, ...

    So, I think that it's messing up by taking those three in row (hr, mn, sc) without there being a non-numeric character between, the first·non-numeric is the comma after "173514".· Everything else has a comma or a period/point to signal the end of the other DEC captures with.· But 173514 > 65535, so it can't be taken in as a WORD (can it?)·

    So -- how about taking the time in as ASCII STR VARiables (2 bytes each; hh, mm, ss), then SKIP1 (i.e. skip over that first comma) and take the rest in as DEC VARiables?· [noparse][[/noparse] Then Convert the STR variables to Decimal numbers, later. ]


    Post Edited (PJ Allen) : 1/16/2006 9:13:45 PM GMT
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-16 21:39
    Tried that and even skipped over them competely. Does the exact same thing. Its always the fractional minute field thats wrong in the middel of the string. Per JonW suggestion guess its time to contact tech support directly. Let you know what I find out.
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-17 23:47
    Tech Support sent me back to article #83.· The only thing I can conclude is that the stamp can't keep up with the larger NMEA 0183 strings if you are trying to process the string as it arrives.· You need to store the string first then process it.· Which is fine if that is what I have to do.· I just wanted to make sure I was using the SERIN command with parameters correctly.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-01-18 02:07
    If you're using the BS2p you can use the SPSTR modifier to stuff the incoming data into the ScratchPad RAM as long as you know how many bytes you have coming in.· Then you can jump to the apparopriate position and build your data from there.· Does the GPS output a fixed-length string?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-18 04:20
    I know the maximum size of the string. Not all parameters are transmitted with leading zeros so there is some variation. Not concern about that aspect of the string. I know the SPSTR method will work.

    The main reason why I wanted to process the string as it came in was to reduce code space. As I stated in the initial posting I liked the way JonW tackled the problem in article 83 and 103. I was concerned about the amount of program space that was used by a single program (76%). The stamp will be controlling 5 subsystems with GPS representing only 1 subsystem but it is the most important one and all other systems are triggered by the GPS information.

    I have plans to start recoding the GPS portion of my project tomorrow with the intensions of using both methods and minimize the amount of "after capture" parsing to reduce the code space. If I can reduce the GPS code to ~50% I should be fine. That will still leave me ~20% for the telemetry system.
  • steve_bsteve_b Posts: 1,563
    edited 2006-01-18 04:40
    Do you have an option to slow down the baud rate of the gps?

    2400baud is easy to work with...but if you have a lot of modifiers in your 'serin' statement, then you'll miss things at high speeds for sure.
    An SX could do the job alright....but in lieu of that, you'll have to be stodgy with your stamp.

    You said you could bring in the whole stream as a string. Well, try to do that and then parse it out. I'm at the same point as you with a different project.
    I think I'll have to bring it in to an array and then search for comma's and then count them out to define my string fields. Messy but I think it'll work!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-01-18 18:35
    ebf306 said...(trimmed)
    I know the maximum size of the string. Not all parameters are transmitted with leading zeros so there is some variation. Not concern about that aspect of the string. I know the SPSTR method will work.
    The main reason why I wanted to process the string as it came in was to reduce code space. As I stated in the initial posting I liked the way JonW tackled the problem in article 83 and 103. I was concerned about the amount of program space that was used by a single program (76%). The stamp will be controlling 5 subsystems with GPS
    Well, I'm not sure what else to offer you.· I would think there would be a code (And RAM) savings in using the SPSTR method.· Just because one example uses 76% doesn't mean your code will.· Let's not forget there are 7 more slots of EEPROM for program space, and they could be used to process your information.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-19 04:46
    I appreciated all the suggestions.· Stubbornness set in and I wanted to assign variables as I read the data in because it only used 14% of my program space, but it was giving me too much grief.· So I went to JonW article 83 way with a few changes.
    ·
    I managed to keep the code to 27% and leave 6 Words of RAM for my other subsystems.· I see 2 more bytes of RAM I can recapture if I need them.· I did have to break up the parsing procedure into 3 smaller procedures because I was reusing declared variables.· While that might have taken up more program space it saved me 3 words of RAM space.
    ·
    It took most of the day to rewrite the code but in the end it was worth it.· Drove around town a little and compared it with my Streetpilot GPS and it is working fine now.
    ·
    Now I just need to change my debug statements to·"save to external EEPROM" statements.·
    ·
    Thanks again for all the suggestions and assistance.· New GPS code is posted if you want to take a look.
  • steve_bsteve_b Posts: 1,563
    edited 2006-01-19 16:34
    Glad to hear it worked out!
    How about posting it as a finished project in the projects forum. Pictures are fun too! Maybe video (be careful if you're driving!).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • Earl FosterEarl Foster Posts: 185
    edited 2006-01-19 21:58
    steve_b - this is only one subsystem of the project. I am still a long way from completing the project. But the entire project will get posted in the projects forum when it is complete.
  • Earl FosterEarl Foster Posts: 185
    edited 2006-02-14 15:38
    I have a question about using multiple power supplies with a common ground.
    ·
    My HAPB project is now using 2 different stamps (schematic attached).· The BS2p24 handles the primary functions during flight.· The BS2-24 watches the primary computer, controls·tacking functions, and takes over supplying power for select components if the primary power fails.
    ·
    Each has been powered separately on different breadboards but now I want to bring the 2 together using the same ground on the same PCB.· I shouldn’t have any problems but I wanted to double check before going that route.
    ·
    Any thoughts?
  • n1iicn1iic Posts: 19
    edited 2006-02-15 14:19
    I am having a problem with having a common ground between the serial cable to the computer and a wall wart to power the board. I am fine if I use a battery instead of the wall wart, so I believe that your stuation will be fine if you are using two batteries.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Sick and tired of our media and the cheesy radio DJ's in the US? http://www.opieandanthony.com
  • steve_bsteve_b Posts: 1,563
    edited 2006-02-15 14:40
    EBF306,· is U1 and U7 the 2 supplies you want connected together?

    IF you are only transmitting data between the two, then you can just run the gnd/common wire with your TX/RX lines....but in effect you're doing teh same thing as connecting both commons together.

    The only thing you have to watch is if the ground is a +V ground.· I've seen some gear that does this in noisy environments to get rid of spikes/noise on the ground lines.

    I think if you're using LM regulators, you'll be fine.·



    n1iic, what kind of wal-wart are you using?· not all wall-warts come in the same flavour.· The really cheap ones don't quite regulate good enough (half-wave rectifiers)..these are the $5 ones.· The $15 ones will do the better job as they are typically full-wave rectifiers!

    You may also just need to stuff a capacitor across the power leads to smooth out those bumps.· 10uF is a nice number.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • steve_bsteve_b Posts: 1,563
    edited 2006-02-15 16:47
    n1iic....as per the private message:

    n1iic said: "since it will be getting off topic in there...
    I am using the wart that came with my Uniden BC-780 radio scanner. I believe it is a good supply and is noise free.
    My problem is the different ground potentials. I think it is feeding back through the circuit from the wart to the computer. I am going to take some power from the computers power supply to get around that.
    Jason"

    What computers' power supply are you talking about? The USB port?? -- I think it's rather limited in how much current it will source.
    Desktop PC power supplies are 'switching' power supplies and some electronics don't like running on them unless designed to do so.

    As far as your uniden wall-wart....what's the output? (voltage and current?)...what do you need for voltage/current.
    Do you have a volt-meter? How about an oscilloscope?
    With your circuit connected...measure the voltage coming from the output. What's its DC voltage value? What's its AC voltage value?
    If there's an AC voltage of more than 50mV then you might have an unregulated wal-wart!
    Your radio scanner may have additional circuitry inside to clean up this unregulated voltage....or, quite simply, it doesn't care!

    If your wal-wart outputs 12Vdc, and you only need 5 or 9Vdc....you can connect a regulator that will smooth things out for you quite handily.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • Earl FosterEarl Foster Posts: 185
    edited 2006-02-16 17:44
    U1 and U7 are the regulated power supplies that will share a common ground. The system is designed to provide power to the GPS and Opentracker via U1. If after ~6 hrs I haven't powered down the system (meaning I haven't located the capsule) then U7 will start providing power to the GPS and Opentracker. This will give me another ~12 hours of operation for tracking purposes. After ~18 hours the radio power will be dead and it will not matter anymore.
  • harrymharrym Posts: 2
    edited 2007-01-22 03:32
    Hi Earl,

    Just thought I'd give ya a quick howdy. I might wander on down your way and lend a hand if you can use the help. I'm looking at developing some BS apps for my project. I'm entry level at this time and am picking up tidbits here and there.

    Keep me posted on your flights.

    73 Harry

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·
    ·

    Oklahoma Research Balloons
    http://members.cox.net/hhm_74775/orb/
    http://groups.yahoo.com/group/oklahoma_research_balloons/join


    ·
    ·
  • Earl FosterEarl Foster Posts: 185
    edited 2007-01-22 18:35
    Harry,
    I keep my website updated on my launch status. www.photoesque.com/HAPB
    Currently working on HAPB-2 and running ideas around for HAPB-3 using the Propeller. I have the telemetry system and 3 solar panels in place. Still have to mount the camera, video recorder, and the remaining 3 solar panels. Hopefully, I will launch sometime next month, but will have to wait and see. The weather has been really strange this year.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - Harold Thruman Whitman
  • harrymharrym Posts: 2
    edited 2007-01-22 18:51
    Hi Earl,

    I agree the WX has been weird. I've been tring to get a flight off the ground since Aug when I got back from GPSL. There were 2 weekends that were favorable, but I had other commitments then. I looked at this coming weekend, but the predictions show over 100mi down range for landing.

    Do you have EchoLink so we can chat?

    73 Harry



Sign In or Register to comment.