GPSsim is a project to create a drop in replacement for a physical GPS unit in a HAB payload. It's primary roll is to allow for Hardware-in-the-loop testing of payloads during the development and testing poccess. By replacing the flight hardware GPS module of your payload with a connection to GPSsim you can allow your payload to 'dream' that it's flying. While on the workbench (or freezer!) you can test any number of in flight logic processes, such as altitude (or GPS boundary) Cutdown triggers, Camera control, or telemetry testing.
The Arduino running the GPSsim firmware is connected to the payload's flight computer in the same way that physical GPS device connects. Connect the RX/TX ((usually) pins 0 and 1) on the GPSsim Arduino to the GPS input to your flight computer (so that the GPS TX pin is connected to the flight computer's GPS RX line, an the RX to TX). In addition to this you need to (probably should) connect the a ground line between the GPSsim Arduino to a ground line on your Flight computer, to ensure good RS232 TTL communication.
Just like a physical GPS unit, once powered up, GPSsim will start spewing forth NMEA sentences. Currently, the flight simulation also starts on power up, but this could be delayed.
Yes, there are lots of #define calls at the top of the code that can be edited to change parameters such as:
- Lat/Lon/Alt/kPa of launch site
- Targeted Ascent and Descent rate
- Terminal Velocity of payload
- GPS HZ
- Burst kPa (Outside pressure at which balloon will burst)
GPSsim, is not a fantastically accurate simulation of the dynamics of a balloon in flight, but it should be fit for purpose as it's described above. If you take the output of a GPSsim run and push it into Google Earth as raw NEMA sentences, it looks pretty similar to to paths of many of the balloon flight data tracks on the UKHAS wiki. There are few different processes going on in the code, and it's worth briefly discussing each one independently. (It has already been pointed out to me on IRC that the accuracy of simulation is severely compromised due to the absence algorithms during descent that describe the immense magnetic influence of Trees/Powerlines/North Sea/Heathrow/Girls???)
The Vertical simulation (the balloon's ascent and descent) are possibly the most accurate elements of the whole simulation (although that's not saying much!). The maths for this is all contained with the update_alt() function. The specific part of this which is relatively accurate is the implementation of the International Standard Atmosphere Model which is used in this context to determine when the balloon will burst. Once burst, and descending the payload drops at it's terminal velocity while drag increases to slow it, again as a function of the pressure verses altitude (this time working on the parachute). The drag calculation is not at all accurate, but serves our purpose of realistically slowing the payload. Two other inaccuracies in the Vertical simulation are the instant acceleration to terminal velocity (minus drag) rather than an acceleration of (9.8m/s^2 - drag), and the rather rude clamping of the descent speed so that it can never fall below the targeted descent speed. Neither of these are believed to have a major impact on the usefulness of the simulation as implemented (and saved me a lot of time and headaches!)
The Horizontal simulation deals with the movement of the balloon due to the effects of wind. It is almost completely powered by nonsense and has very little baring on reality, other than producing and end result that looks slightly plausible. The function update_wind() takes in as it's parameters, the current Lat and Lon of the balloon, the direction the wind is blowing, and how far the wind has blown the balloon in this 'step' of the simulation. This is then fed into an implementation of the Vincenty Direct equation which updates CurLat and CurLon with the new co-ordinates after this step of the simulation. The direction the wind blows in based on a simple random walk algorithm, changing slightly throughout the flight. It is intended that the balloon will undergo a major change of direction and speed when it transitions the tropopause, but this isn't implemented yet.
The GPSsim outputs NMEA sentences on the serial port in an exact simulation (on of the more accurate parts of the simulation) of a real GPS unit running in NMEA mode. The main reason I can be confident of the accuracy of the simulation here, is that I didn't write it myself, it's a Arduino port of the existing GPSGen emulator (specifically the emulate.c file) on the UKHAS wiki. Full credit goes to the author (rocketboy?) of this code for a job well done. Currently the NMEA output renderer runs independently from the simulation, so that you can simulate a 1Hz GPS unit while the simulator ticks over at about 50Hz. However, due to a bug I've found in the Vincenty Direct equation, when presented with changing values for windspeed (or more specifically distance per simulator step) I may have to lockstep the simulator and NMEA renderer to the desired GPS output Hz.
GPSsim supports and makes use of the common two line LCD shields that are common in Arduino world. I've developed it using this model, but there are many clones on ebay that are built to exactly the the same plan. They should all work. The LCD gives you output on the current Lat/Lon, altitude, outside pressure, and ascent/descent rate. It also has a glyph for the balloon state (Ascent/descent/landed) and an altitude graph. It's quite a busy little screen. The sheild also has buttons, and using the 'select' button you can toggle acceleration of the simulation by about x100.
I come from a background (i.e. my other hobby is...) UAV's (of the Ardupilot kind). In the UAV world we are taught at an early age that hardware-in-the-loop testing is the most important phase of development. By fooling the flight computer into thinking it's really flying (dreaming) you can discover and nail many bugs before they surprise you in the air. (Surprise situations in the UAV world (as in HAB), tend not to be recoverable). You can use a laptop/desktop PC/Mac to emulate the GPS and build your HIL testing rig, but when HAB flight times last at least a couple of hours, do you want to tie up your PC for that long? The Arduino is more than capable of performing this simulation anyway, it seems well suited. There may even be applications for this in the field as part of a flight readiness test, when a laptop isn't available, but having flown yet myself, I wouldn't know .. sigh..
I offer this code out to the HAB community, please fork if you wish, or mail me to be added as a developer to the project if you are able to contribute directly. It's going to be a useful tool for me in the development of my HAB flight hardware, and if anyone else finds it at all useful then that's a win for us all. I'm happy to help support the use of this as far as my time allows, both in terms of advise on setting it up, and with code bugs/feature requests (just add them to GitHub)
You can mail me jim at jimblackhurst dot c o m, or catch me in the UKHAS irc channel as Jimthree or Jim3