GPS Project

[acg2010]

I have always been interested in the "near-space balloon" projects everyone seems to be doing now, even before it was well known. I mentioned the idea to members of the Dallas Makerspace and they have initiated a near-space balloon project of their own. One of the main components of this kind of project involves use of GPS to track the balloon trajectory, ascent and descent, altitude measurements, etc. So I was excited to see the Locosys USB GPS Mouse project and schematic in the Flowstone examples section under GPS located here: viewtopic.php?f=54&t=357

However, I only have an old Garmin eTrex Legend handheld GPS unit with serial connector cable. I tried modifying the LS20031 GPS Module V3 to work with my Garmin, but it did not seem to work. Upon doing some research I found that the NMEA format output may vary between GPS models. I set the GPS to output NMEA at 4800 baud, then used the COM Port Tester (here viewtopic.php?f=3&t=220#p555) to make sure the GPS was communicating. After communication was established, I then used Hyperterminal to connect to the GPS to capture a text file of the NMEA output. From there I was able to modify the COM Port Tester fsm with components from the LS20031 GPS Module V3.

The image below shows what I have so far. You can see the NMEA stream output once the GPS is connected and you can save the output as a text file. following the steps above, you should be able to configure it for any GPS capable to output NMEA.

I still need to set up an array/buffer and a counter to make sure and capture all of the NMEA output so one could customize information output.

[trogluddite]

Hi acg, nice to see another familiar face around here.
Sounds like an interesting project - do you have plans to aqcuire any other interesting data while your craft is up there?

Maybe worth looking into Ruby a little. You could easily parse and format the data, and then continuously append it to a 'log' file - you would then have access to almost unlimited storage space if the amount of data is very large. Ruby would also be very good for filtering the data, searching for patterns in it, or making comparisons with previous flights - even with my only two week old experience of Ruby, I can see that its handling of data structures far exceed those of the "green" arrays.

[acg2010]

Hi trog,
thanks for taking a look at my project, glad to see someone with your caliber and expertise here. Yes, the near space balloon project that the Dallas Makerspace (http://dallasmakerspace.org/wiki/Near_Space_Balloon) is working on will be transmitting and logging on SD card, GPS coordinates for trajectory, altitude, pressure, temperature, moisture, acceleration, humidity, and magnetic field strengths if I am not mistaken. They are using an Arduino with associated readily available modules, some are hand made. Transmission will be with aid of APRS radio. However, I think they lost the Ham radio person that was working on that part and therefore the project has kind of been at a stand still. I have some ideas on some other senors to collect data (wind speed, a spectrophometer, dust collector, photoionization detector, etc. However, these would have to be created from scratch.

This little project is more just research for now since there are probably better ways and equipment for GPS. If you google for near space balloon projects, a lot of the original ones used GPS units like a Garmin to track the balloon, hence my interest.

Your sugggestion to use Ruby is an excellent one, however I have yet to try and use it. Guess I got something new to learn and my work cut out for me. I will be posting updates as they are finished.

Take care,

-acg2010

[acg2010]

A new version of the GPS Tool. I realized that I had to add a "-" to the longitude for it to map correctly. Also added a new GUI that uses the tabbed window template from the SynthMaker wiki page and image of an actual Garmin GPS and I was able to save some GUI space while creating a pleasing and more realistic GUI. The "Menu" toggles between item 1 which is the parameters readout of the GPS and item 2 which is the NMEA readout. I could keep adding windows for other parameters as well. Things I still want to do: create a side momentary button like the actual ones on a Garmin GPS and add the array counter so that the entire NMEA sentence readout is captured.

[acg2010]

Here is where I am on this project: added a system configuration window to allow changing the COM Port setting and added satellite PRN number and signal to noise ratio (SNR) windows.

Things I am still working on:
1) an auto logging of the NMEA output - need to be able to determine the number of lines in the text box so that when it reaches a max number, it auto saves the output. However, I tried using the string array with the lines out but either I do not know how to use it properly or I am missing something, it only gives a number of "1" and nothing else when the Garmin GPS is connected and communicating.

2) a background such as rectangle behind the image of the Garmin front panel. Is it me or is the move forward/backward feature missing? I tried to find it everywhere by checking the Flowstone menues, right clicking on the modules, etc. Maybe I have to be more careful how the MGUI is layered in the fsm file. Guess I will keep working on it.

3) trying to make the SNR bars drawn go up not down. I used the draw bar module from the Step LFO but maybe I don't have it set up correctly. Also Tried to set up a string hold trigger so the SNR and PRN would stay present until updated, but did not work.

Other things that could be done - preset configurations and outputs for different models of GPS (Garmin, Magellan, etc.), windows for waypoints, etc.

[trogluddite]

Hi acg,
Coming along nicely - it's looking very smart now.
Here's a couple of suggestions for you...

Number of Lines.
As you already have the number of log entries available at the central string array, I'm guessing that what you really want to do is to find out when the amount of text overflows the view area for the "screen" - i.e. so that it takes into account the wrapping of long lines.
You should be able to do this using the "String Measure" primitive. The area that you feed into this primitive would be the actual screen area of the display (so that it knows the width of the view for wrapping). The output area is then the actual area occupied by the text - the 'screen' is full when this height matches or exceeds the height of the viewport. This should be more reliable that using a count of the array entries as it will account for the indeterminate length of each individual line.
You may need a second array to make this work though - without using Ruby, there is no way to append text to the end of a file, and the most recent "block" will overwrite the current file contents - so you'd need to save the contents of a separate array that holds the entire content for the session.
I'm doing a lot of Ruby fiddling about at the moment - if I get a nice "text file append" module working, I'll post it up for you. I think that this would be a more appropriate solution, as it would be able to simply append each line as it is received without requiring any kind of bulk storage within the schematic (other than for the display lines).

Screen Layers
The reason that you can't change the layer order is because those layers are hard-wired into the MGUI using solid links. When you do this, the order of making the links determines the order, and the GUI "back/front" options get disabled. So there are two possible fixes...
- Change the order of the links by removing them, and then rebuilding - the link that you make first ends up being the bottom layer; last link made is the top layer.
- Change the "daughter" GUI modules so that they communicate with the MGUI using wireless links. Wireless receivers that link to a common view transmitter have no pre-determined order ,so the layer ordering menus will become active again. This is probably the best way to do it, as it preserves the graphical layer editing in case you decide to add or remove anything later - and you have the necessary view transmitter there already.

[trogluddite]

Hi Again,
Here's my first attempt at the text file for data logging - a file is created automatically at startup in the .exe's directory (or on the Desktop when practicing in FS). All data entries, and the filename are tagged with the current system time - though maybe you won't need that, as your GPS likely has a more accurate time output.
Like your schematic, data is initially buffered inside the Ruby, and then everything in the buffer is flushed to the file either on demand, or automatically after a given number of lines. (there's more info inside the schematic).
EDIT: Attachment deleted - new version a couple of posts down.
I think the basic functions are pretty much there, but I'm a little undecided how it should be used in practice, so any thoughts you have would be most welcome.
Oh - and note that as soon as you open the schematic, it will automatically create a new log file called "Log_File <date><time>.log"- this will appear on your desktop, so that it is easy to seek and destroy!!

[acg2010]

trogluddite - What a great module you have created! For someone that says they just have started with Ruby, you coded this quickly. I added it to the GPS project and it works great. The desktop log file keeps appending. I think this would be a valuble module for any data logging scenario including the near space ballon project. But I see it might have wide spread applications.

I work for an environmental consulting company and we conduct data logging in the field for all sorts of purposes such as water levels in groundwater monitoring wells, temperature, dissolved oxygen, ORP, temperature, conductivity, pH, etc. I could see how connecting a YSI MPS meter to the laptop, then logging the data, then having it compare the data to a set of criteria, it could notify the field person when that criteria has been met, thus freeing them up to do other tasks (currently the parameters are monitored manually). It could be used for any data logging purpose.

After I complete some more tweaks on the GPS project, I'll post it and you can see how well it works.

Thanks,

-acg2010

[trogluddite]

I added it to the GPS project and it works great.

Thanks for the feedback - I'm really pleased that it has ported into your project easily.
I have a few uses for this in mind myself, so I'm going to keep working on it, as I keep finding lots of useful new features in the Ruby documentation/tutorials etc. - I think it could be developed into something very versatile that would make a nice little library module.
Re: fast coding - yes, Ruby really does seem to be living up to its reputation as an easy to learn language, and the quantity and quality of learning resources on the web really helps (the official Ruby.org website is a good starting point). My impression of it so far is that it is a very consistent and predictable language - it doesn't seem to have the over-fussy syntax and semantic rules that have always put me off learning e.g. C++.

[trogluddite]

Updated log file module...

...now uses the built-in Ruby "Time" class - as well as making the module a bit neater, this also allows much easier formatting, and reads the system time zone so that it can show the offset from UTC.
EDIT: Schematic removed - see next post for update/bugfix
Also added a couple of extra features-
- Enable switch, which generates a log file event when logging is paused or restarted. Pausing also causes the file to be updated and closed.
- Elapsed time and event count outputs
- File is only created when the first event is received or the Enable goes false->true - avoids dumping a file on the desktop every time the module is loaded/pasted. A new file is made if the the name input has been changed since the previous event.