New threads and interesting conversations directly in your inbox. Sign up now and get a daily summary of the latest forum activities!
Discussion in 'Rocketry Electronics and Software' started by Worsaer, May 4, 2017.
It's going to be interesting when I convert with the logger. I'd like to see the differences with the onboard logger and the live tracking solution I've tried: http://www.rocketryforum.com/showthread.php?137555-Eggfinder-Map-tracks&highlight=EggFinder+tracks
I think the latency of the program(s) I use on the receive end misses plotting of valid data points so a comparison of a the live track with the data logger should prove enlightening.
That said, I have discovered a very small "true" Linux handheld: https://getchip.com/pages/pocketchip First thing is to ditch the shipped firmware and download and flash a standard "Jessie" distro that the maker has available. Extra "Chips" are
$10.00 so the thing can be tailored to a particular use and since it's so cheap, just get another pop in board for a different application.
Latest firmware makes use of 8Gb of memory so the Linux tracking app Xastir will run with it. Using a script gps2aprs.pl : http://www.ece.uah.edu/~jdw/rockets/gps2aprs.txt one can bond a B/T EggFinder receiver to the device, activate the script and
the rocket position will be directly injected onto the Xastir map as a rocket waypoint. The latency is pretty short so I'm hoping this will work better than the APRSIS32 app I've been using as far as a greater resolution of the rocket track.
These are some high zoomed scans of a test using the EggFinder. Now I just have to do some flights and I have 3 motor ejection "tracker dog" rockets I can use for testing. Stuff the the Pocket Chip inside a small flat black painted
box on the inside for glare protection, use an Rf mouse for control and have at it.
Any other Hams out there who are dabbling with Egg Finders might find YAAC might work: http://www.ka2ddo.org/ka2ddo/YAAC.html
With YAAC, one can use free Open Source Maps plus YAAC will allow one to attach one NMEA gps for base station location AND one can attach another NMEA port (ie. the EggFinder receiver) and track the rocket in real time.
Some test shots below. Only problem is last time I tried YAAC, Bluetooth support was crummy and it might have improved over time. If that is the case, since this is a Java driven app, WinBlows and Linux should work with it.
It's been a long time since I've worked with it but it might be that the author got the Bluetooth bugs out of it.
Technically, a non-Ham radio operator could use a "bogus" callsign and as long as they don't connect to the internet and "attempt" to use the APRSIS service or connect up Ham radios to their hardware they would be perfectly
legal as long as they stick with their EggFinder hardware. So much to try....... So little time. Kurt
Several of these shipped out over the past week, and more are still available. Also, thanks to those of you who volunteered for flight tests. So far the comments have been positive.
Got mine yesterday so on to putting they together. Looks pretty easy.
I take it the little dollop of solder it is going to take to attach to the terminals still allows enough
space for applying a shorting plug and being able to reprogram to a different frequency? Kurt
Kurt, the supplied solder is only needed to attach the supplied headers. It's intended to be a pluggable board rather than permanently soldered into place. As you say, there is sufficient room, but my suggestion is not to solder the board to the TX. To reprogram the TX simply remove the TXLog board by removing the mounting screw and slide it off the TX header pins.
Thanks! So before I asked another stupid question the assembly instructions are here: https://s3-us-west-2.amazonaws.com/12294/TXLog+Assembly+Instructions.pdf
In case anyone else missed the link. :wink::blush:
Making it removable is a prudent intention and I suspect the contact on the pins is sufficient as long as the forward screw mounting
is adequate. Nonetheless, if the log board has a power glitch during a flight only the logger is affected and not the ability of the
EggFinder to track and get the rocket back. No major concern here then. Nice! Kurt
Got one of Bill's boards assembled and not hard. Only problem is the pinned headers on the respective EggFinders. I assembled one board and the instructions are fine.
Bill suggests press fitting but..............I'd suggest if going with a screaming meeemeee flight to solder it down on the particular EggFinder used. That said, I didn't solder my one of two
loggers to the EggFinder and diddled with it like heck by tinning the pins on each EggFinder on the headers until I got good contact.
My first one, the "run" header had lousy contact so I messed with building up the pins on the Eggfinder with solder. I press fit the logger to the board and nada, nothing with the EggFinder.
I put the run jumper on over the logger board and there is a tiny blue LED on the logger board that lights up to indicate it's working. I kept building up and bending the two pins until I had contact and then success without that added "external" jumper!
I used this program on my computer to convert the NMEA text to .kml files: http://gnss-info.blogspot.com/p/download-eng.html I "ABSOLUTELY" hate internet dependency out in the field
and try to achieve independence. This program on a tablet will achieve that. After conversion, I got these screen saves after a little walk:
And then zoom down to this:
That little curly cue off the right is where I went over to a neighbor walking a dog who asked if I was, "playing Pokemon." I said, "No, testing a tracker for HPR where I fly at a location a long ways from here with FAA blessing so's not to disturb travelers." She was impressed to say the least. A lot of points are plotted at once/sec at walking speed. It's nice with Google Earth that
there are data points and the blue arrows on zoom-in is the direction of travel! I really like that.
Once the track is converted to .kml, go to Google Earth and load it in. That's the pics I got above.
I then pulled the logger off the first EF I had and plopped it on a second one. This time the shorting for RUN was connected fine with the holes in the logger board but the power and data 3 pinned header didn't have contact. Soooooooooooo............... Back to building up the header pins on the +, - and signal pin. Got it working fine and running.
I jiggled the board assembly and the contact was maintained on both EggFinders so I believe ready for flight. The nice thing about it is as long has the RUN header pins remain shorted
the EggFinder will continue to track. When I fly with the logger, I'm going to make certain that I tape a shorting block on the RUN pins that are projecting through the logger board assembly as added insurance that at least the EggFinder remains operational to track.
If the logger board loses power, no big deal as long as the EggFinder continues tracking. If the RUN header block loses continuity in the logger board assembly, one might end up with a lost rocket.
Again, if going with a "crazy flight", might want to consider soldering the logger to the prospective EggFinder to be certain of reliability of tracking/finding the rocket and recording the flight. I can tolerate losing a record of a flight if I can get by with getting the rocket back but if that RUN header opens during a completely out of sight flight, one is at risk of losing the rocket.
The only setback of soldering the RUN header together is the loss of ability to program different parameters into the EggFinder. Something to consider when weighing whether or not one
wants to go all the way to further improve reliability. Clipping a shorting block with tape on the pins or by whatever reversible means is added insurance the tracker will continue to run.
Me? I'm going to diddle and tweak the logger board and if I see good continuity, I'm not going to mess with a permanent solder solution. I'd like to be able to program my EFs in the future. Again, a temporary "shorting solution" on the RUN header pins will improve "recoverability" with logger failure. That should be one's priority if running this logger.
The record on Google Earth is nice at least with the slow speed test I did.
Thanks for the feedback Kurt. It's interesting that you're seeing somewhat different results with the Run pins. I agree, you want a good connection, which is why I added the horizontal Run jumper. If you place a jumper on the original Run pins, the one on the TXLog is not doing anything.
You're welcome Bill. The other thing to remember folks there is a blue led on the logger module that lights up
to show it's working. You see that at once/sec and it's up. Also need to see the red LED flashing on the HOPE
module to show the EF is transmitting. Kurt
You're correct Kurt. The red LED indicates data being transmitted, and the corresponding blue LED on the module indicates data being received. To your earlier point, if the red LED on the TX is not flashing, no data is being transmitted, which may mean it's not in Run mode.
Built my TX last night and assembled the logger tonight. Works flawlessly! (On the ground that is )
Interesting thing is if Google has a ground level picture of where you do a test, you can get an interesting view of the plotted points at eye level. Kurt
I'll have to check that out!
Have GE plot your points and then zoom as low as you can go. If the "Google Car" has driven through the area for street side shots you might get to see some funky dots overlayed on the picture
Where can I find the +3.3 (VCC) supply on a TRS?
I think I have the TRS A5 revision.
Kevin, here's a layout diagram of the Hope RF module that shows the pin positions that Cris was describing. Does this help?
Thank you Bill. That's perfect. I didn't read Chris' reply carefully.. and thought he was referring to the OpenLog's pinout.
I'm guessing even a small 1Gb microSD card will hold many hours of data.
Yes. In general, an entire flight is only a few Kb's of data. Perhaps some folks who have collected files could submit them as examples...
The actual flight is probably only a few KB, but if you count the pre-launch and recovery it's going to be a lot more. I flew an OpenLog/TX in my G3 to about 7,500' at DairyAire on a K1100X, the file was about 1.1 MB for about 90 minutes total time. That means that an 8 GB uSD card can "only" hold about 7,000 flights...
Sounds about right. I just reviewed a data file that spanned 2 flights in 100 minutes, and it was 1.4 MB.
I have had two test flights with the TXLog so far and must say that it is a lot of fun to see the track afterwards. The unit is easy to mount and use.
This screen grab is from a launch this weekend and anyone who wants can download the log file converted to KML here:
http://www.bratazor.com/kthomson/CRMC - Madcow Pike I366 - 6-17-2017.kml
Video from the flight is here: https://youtu.be/4KLnHjVrMVM
What's interesting about this track is that the rocket comes back under chute in the direction of the pad, I'm assuming that there was a fair amount of wind and it weathercocked a bit at launch. If it went out of sight and you didn't see coming down, and you didn't have a GPS, you'd be looking for it in the wrong place. That's the same thing that happened with my Double Shot a few months back... it ended up 5 miles away (main at apogee courtesy of loose shear pins) in a completely different direction than where I last saw it on the way up.
Maestro Wireless, the manufacturer of the EggFinder GPS module, provides a nice NMEA decoding tool called GPS Cockpit that allows you to play back your data in real time, or at an accelerated speed. It's a useful tool to dig into the data, and it also has an option to convert to KML file format.
The tool can be downloaded here: GPS Cockpit
Bill is going to be relocating soon and he's going to be very busy for a few months, so Bill and I have agreed to sell his excellent OpenLog adapter boards through Eggtimer Rocketry directly. This should save a lot of you on postage. The price will be $8 for the adapter board, and $12 for the OpenLog modules. We're not selling micro SD cards (at least not yet), but we anticipate that we will once we find a decent source. Those are pretty easy to come by...
Also, there is a new version of the TX board now shipping (RevC1) that has a space directly on the board for an OpenLog module. You don't need Bill's adapter board for the new release, but if you have a B6 or B7 version (and we've been shipping those for two years now) then you might want to pick up a couple of the adapter boards and OpenLog modules for your existing TX's the next time you order a transmitter. Believe me, it's really nice to have that GPS track recording... it really complements your altimeter's data log.
To add to Cris' post, and perhaps to state the obvious, these will be less expensive from Eggfinder than they were from me. Cris has been working to source the OpenLog components at a substantial savings, thus making them available for much less than I could. Thank you Cris.
Cris, I just looked at the updated assembly photos of the Rev C1 board on your website - nicely done. The new layout makes adding the on-board module really slick.
Nice flight on my 4" Nike Smoke today at Tripoli Central California.
I flew a K1440 to 7,655 AGL, and the Eggfinder mounted data logger performed as expected. Here's the Google Earth view.
That's very nice Bill. The logger does a great job of getting all the positions. Kurt
Slightly off subject, but I run one of the open loggers in my LCD RX as a backup. Now the kids had been fiddling with the switches which never helps, but when I went to look at the logs I found the data had been corrupted and was only able to recover a few seconds of the flight. Was wondering if anyone had seen something similar and also perhaps there are settings I should look at to force the unit to write to the file more often IE don't buffer much data. I'm also thinking of adding a super cap to keep the unit powered up once the log / Bluetooth switch is turned off so it has time to write out any buffered data.
Good question. It sounds like either the power 'bounced', or reception was interrupted, corrupting the data. According to the OpenLog data sheet (link below),
"OpenLog buffers 512 bytes at a time before recording to the SD card. Recording 512 bytes is very fast so the LED is on for very little."
Looking at the command set, I don't see any settings for setting a smaller buffer or flushing it manually. Perhaps someone else has more experience with it.
Separate names with a comma.