I recently discovered the excellent “console” wrapper for cmd.exe (or the shell of your choice) in Windows.
I had a lot of trouble figuring out how to setup a right-click command to “Open console here” similar to the “Open Command Prompt Here” offered by Microsoft’s “TweakUI” in WinXP (and similar).
I figured it out, tho. Here’s the trick:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Folder\shell\Open console here\command]
@="u:\\users\\dave\\data\\bin\\Console2\\Console.exe cmd -r \"/k pushd %L\""
That’s it – easy enough. Replace the path to wherever you installed console.exe, of course.
It even works on network volumes (it automatically creates a drive letter mount, the same as does Microsoft’s own Open Command Prompt Here).
I’ve only tested it on Win7, but in principle it ought to work on any recent version of Windows.
As mentioned a couple of posts back, I recently got a new PC and decided to try using Linux on it as my main operating system. I tried – really tried – for 3 weeks, spending a large fraction of my working hours googling for solutions to get things running smoothly.
I used (real) Unix back in the early 1980s (as a user, not an admin), and liked it pretty well back then, so I wasn’t totally new to common Unix commands.
I tried Linux Mint 11 x64, then Xubuntu 11.10 x64, and finally Kubuntu 11.10 x64.
Linux works great as a server or command-line driven operating system. For that, it’s mature, powerful, and effective. But as far as I can tell all the GUI desktops are still suitable only for:
Users who only surf the web, edit office documents, and do email
Single-function applications (basically, running one app)
It’s a shame. I really prefer the Unix command-line environment to Windows. But so far as I can tell, the only Unix-based operating system with a mature GUI is Mac OS X. (And that I’m taking on faith, not having tried it…yet.)
But I give up; I’m installing Windows 7, which works smoothly despite its inferior architecture. For those whose main use of their computers is configuring and tweaking the computer itself, Linux may be great. But I have stuff that I want to get done – every time I tried, I ran into little niggling problems that required hours of web searching and learning to get over. I think the rest of this site demonstrates that I’m not technically inept or unwilling to learn. But Linux isn’t ready.
I did learn a lot in the process. For those who want to try it for themselves, my notes follow; at least you can benefit from my experience.
As well as the problems mentioned below, in all three attempts I found a strange problem with the Chrome browser on Linux – after the first hour or two of use, it became incredibly slow. At first I thought it was my ISP or home network, but Firefox worked fine, as did Chrome on my Win7 boxes. There is something about Linux that Chrome doesn’t like. One (unconfirmed) idea is that it wants to see an IPv6 stack – Win7 has this but none of the Linuxes turn it on by default.
The rest of this post consists of my notes on Linux in general, then notes on each of the three attempts I made (Linux Mint 11 x64, then Xubuntu 11.10 x64, and Kubuntu 11.10 x64).
GENERAL LINUX NOTES (some come from previous attempts with Ubuntu…)
sudo fdisk -l List all mounted partitions
sudo fdisk -l /dev/sda List partitions on /dev/sda
./configure Something to do after downloading source code
sudo make install Ditto?
uname -r Report kernel version
sh FILENAME.sh Run script FILENAME.sh
~ Macro for home folder ( ~ == /home/dave )
Terminal colors Dark blue - directory
Green - executable
Yellow - device
Magenta - image
Red - archive
/media Folder where USB drives get mounted
/dev/ttyUSB0 0th USB serial port
Alt+middleClick Resize window (GNOME); no easier way than choosing 1-pixel border
lspci List machine hardware (try -v for verbose, or -vv for very verbose)
Drag MIDDLE button to choose move vs. copy (Gnome)
uname -sr Reports kernel version name & number
cat /etc/*-release Returns distribution version
Shift-Ctrl-C and -V work in Gnome terminal (cut/paste)
Random app icons are in /usr/share/pixmaps/
Multiple commands can be on the same line - delimit with ';'
CLASSICAL SHARES vs USERSHARES
Classical shares are created in /etc/samba/smb.conf
They must be created by root.
Usershares are created by the user (without needing
root privs) in folder /var/lib/samba/usershares.
Nautilus's "Create share" makes a usershare. These
are 'less secure' (not sure exactly how).
du -sh folder Lists disk usage of folder (summarized)
KERNEL ISSUES
TRIM needs kernel 2.6.33.x or later; 10.04 LTS has 2.6.32-31-generic
I tried updating to a newer kernel; got driver problems as with contempoary versions of Ubuntu (10.10 and 11.04).
Here follows my notes from each attempt – may they be useful to somebody out there.
Gnome 2 on Linux Mint 11 x64:
I chose Linux Mint because it was advertized (accurately) as being more complete out-of-the-box than Ubuntu, with commonly needed things like codecs and Samba (Windows-compatible file sharing; I have to administer lots of Windows boxes) pre-installed. And it was based on Ubuntu (widely supported, stable), and rising in popularity, which I figured would help iron out bugs.
It worked pretty well up until I got frustrated with the horrible vertical grid for desktop icons. It does have a grid, but the grid is much too fine in the vertical dimension, so you end up with icons in neat columns but messy rows. And there’s no way to change the grid short of hacking Gnome 2 (believe me, I looked into this hard).
So I attempted to install XFCE in parallel. That borked the whole system and I had to reinstall the os.
I got as far as you see below; this took a couple of weeks. I was still running 90% of my apps on a Win7 box via rdesktop, but I was able to use EaglePCB on the Mint machine.
SETUP NOTES FOR LINUX MINT 11 x64
Setup notes for ENOUGH - Intel i750-2600, 8 GB, Linux Mint 11 x64
Started 8 November 2011, gave up 26 November 2011 (Chrome got corrupted, conflicts between Gnome2 & XFCE)
>>> Marks unresolved problem
[u] Marks removed program (thought better of it later)
1 - Updated everything
2 - Google Chrome
3[u] - RDPfree (because of black cursor problem with rdekstop) [UNINSTALLED LATER; rdesktop 1.7 is better]
4 - Added Chrome and Terminal to Panel
Right click then unlock, rt-click then Move to move
5 - Turboprint for Canon ix7000 printer (works well so far)
Set CtrlCntr>Printing>Properties>JobOptions>ScaleToFit to avoid cropping at margins
Couldn't get applet to appear in applet list for panel (posted 2011-11-12) - fixed after rebooting
6 - PuTTY
Note middle-click does paste. Enter sends CR, ^J sends LF.
Ctrl-RtClick brings up menu to change settings.
7 - Eagle PCB
Setup folders to search separated by ':' in Options>Directories
8 - Meld & BeyondCompare (not sure which to keep yet)
9 - XRDP (>>> probably ought to configure, also set fixed IP and port)
10 - Installed rdesktop 1.7 (to fix black cursor problem in 1.6):
download source from website
tar -zxvf rdesktop-1.7.0.tar.gz Un-gZip, Xtract, Verbose, from File
cd rdesktop-1.7.0
./configure Gives error, so then...
sudo apt-get install libssl-dev
./configure Seems happier now...
make
sudo make install
Works!
To get 32-bit color and anti-aliasing, use:
padsp rdesktop -a 32 -g 95% -r clipboard:PRIMARYCLIPBOARD -x 0x80 <ip>[<:port>]&
Right now, QUIET is .117 and NIGHT is .111
>>> Cut/Paste works toward client, but not toward server
11 - Fixed PDF printing as follows:
sudo apt-get purge cups-pdf
sudo apt-get install cups-pdf
That installs printer "PDF" that prints to ~/PDF
Change output folder to desktop:
gksu gedit /etc/cups/cups-pdf.conf
Change this line:
Out ${HOME}/PDF
sudo /etc/init.d/cups restart
12 - Plugged in Canon MP830 printer/scanner/fax, let it install printer driver for it. Works.
13 - XSANE (scanner driver for MP830)
Works, but very clunky to make multi-page PDFs from ADF.
For now using Win7 stuff; consider VuePrint or Wine/VM instead.
14 - Picasa
>>> Picasa viewer isn't associated with .JPGs, etc.
15 - Setup (wrote) "startRDP.sh" in ~/scripts. Now I can make links to machines on the desktop.
16 - Wine 1.2.2
16a - MS Office 2003, SP3 update
Works fine if launched from command line or from 1st of 2 right-click menu options.
Doesn't work if launched from mintMenu or 2nd of 2 right-click options.
Seems to be because of:
http://forums.linuxmint.com/viewtopic.php?f=76&t=60130
http://ubuntuforums.org/showthread.php?t=586846&page=2
17 - Google Earth
>>> Copy over placemarks
>>> Get SpaceNavigator working
18 - Menu>Control Center>CompizConfig Settings Manager>WindowDecoration
Change command to "/usr/bin/compiz-decorator" (fixes loss of min/max/close buttons in Mint 11)
See http://forums.linuxmint.com/viewtopic.php?f=55&t=74327#p444922
19 - Tweak destkop appearance and fonts:
Nautilus>Edit>Preferences>FileMgmt>IconViewDefaults>66%
>ListViewDefaults>66%
>CompactViewDefaults>66%
>ViewNewFolders: List View
Menu>Prefs>Appearance>Fonts
Application: "Sans 10" to "Libration Sans 9"
Document: "Sans 10" to "Libration Sans 9"
Desktop: "Sans 10" to "Libration Sans 9"
Window Title: "Sans Bold 10" to "Libration Sans Bold 9"
Fixed: "Monospace 10" to "Droid Sans Mono 9"
CompizSettings>Grid>Uncheck (turn off windows "aero snap")
20 - Get NETBIOS working:
sudo gedit /etc/nsswitch.conf
add "wins" before "dns". Result should look something like:
hosts: files wins dns
Then:
sudo apt-get install winbind
Works. Now can ping QUIET and NIGHT (others worked OK before)
21 - Setup "classical share" for /home/dave:
sudo smbpasswd -a dave Setup SMB password for "dave"
gksu gedit /etc/samba/smb.conf
Then add at end:
[SHARENAME GOES HERE] used 'dave'
path = /home/dave
available = yes
valid users = dave
read only = no
browsable = yes
public = yes
writable = yes
Then
sudo restart smbd
22 - Added "Force Quit" to panel
23 - Remove mounted volumes from showing on Gnome desktop
gconf-editor
Apps>Nautilus>Desktop>Uncheck "volumes visible"
24 - XFCE 4 metapackage (try to get rid of ugly icons, desktop grid problems...)
TODO
* Write scripts to:
Follow Windows .LNK files (when double-clicked; open Nautilus)
Arrange icons
Create launcher to open Nautilus at SMB share folder
* Programmers' editor
KATE
TextPad via Wine
NetBeans (use also for MPLAB X)
UNRESOLVED ISSUES
* No drag-n-drop when using XRDP. Fix, per https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/587856 is:
apt-get install libgtk2.0-0=2.20.0-0ubuntu4 libgtk2.0-bin=2.20.0-0ubuntu4 libgail18=2.20.0-0ubuntu4 libgail-common=2.20.0-0ubuntu4 gtk2-engines-pixbuf=2.20.0-0ubuntu4apt-get install libgtk2.0-0=2.20.0-0ubuntu4 libgtk2.0-bin=2.20.0-0ubuntu4 libgail18=2.20.0-0ubuntu4 libgail-common=2.20.0-0ubuntu4 gtk2-engines-pixbuf=2.20.0-0ubuntu4
* How to make SAMBA/NETBIOS work before local login?
* Widen mouse target for dragging the window sizes
Use Alt-MiddleClick for now; may not be any better way
NOTES FOR FUTURE
* Re TRIM
Stick to 10.04 LTS and it's kernel.
Instead, find out how to use hdparm and "wiper.sh" to clear out the drive once in a while (daily?)
* For future reference, some of the RTL8192 prolbems in LATER kernels seem to be a conflict between
the RTL8192E and SE drivers; the BLACKLIST of the SE seems to fix it for some people.
* apt-get install gedit-plugins
For multi edit, which allows column editing. Supposedly.
CONCLUSIONS
* Neither LibreOffice nor Google Docs is (nearly) compatible enough with MS Office 2003 to transition. (as of 2011-11 anyway)
XFCE on Xubuntu 11.10 x64:
As I said, the Mint install got borked by the parallel install of XFCE.
Since I wanted to try XFCE, I decided to next try a clean install of Xubuntu 11.10 x64.
I found it very nice, simple and clean. Less tweaking was needed than Gnome 2. But Thunar (XFCE’s file manager) is completely incapable of handling Samba (smb:) shares on other machines. I tried some complex instructions to work around this and borked the whole machine.
SETUP NOTES FOR XUBUNTU 11.10 x64
Setup notes for ENOUGH - Intel i750-2600, 8 GB, Xubuntu 11.10 x64
Started 27 November 2011
>>> Marks unresolved problem
[u] Marks removed program (thought better of it later)
1 - Updated everything
2 - Copy data into ~/.
3 - cd scripts; chmod +x * (rdesktop scripts now work)
4 - Google Chrome (direct from Google via Firefox)
5 - Get NETBIOS working:
sudo gedit /etc/nsswitch.conf
add "wins" before "dns". Result should look something like:
hosts: files wins dns
Then:
sudo apt-get install winbind
6 - Moved main taskbar to bottom.
To move the panels just right click the panel and go to panel>panel preferences and uncheck lock panel
then you will see a handle on the left side of the panel and you can move it around. The re check lock panel.
7 - Moved launcher panel (panel 2) to left edge, vertical
8 - Samba per TINY notes
9 - Workaround for Thunar's inability to handle Samba:
a) Install fusesmb in Synaptic (from Universe repository)
b) Edit /etc/modules and add the word 'fuse' to the modules list to be loaded (without quotes), and save the file.
c) Reboot, so the fuse module loads, and the proper workgroup is read for samba.
d) In XFCE Applications -> System -> Users and Groups... Properties of your username... User Priveleges Tab... check
"Allow use of fuse file systems..."
e) Create a directory that you are going to mount your network browse to... I used /media/network. [~/network]
Change permissions to read / write for group and others (777). [skipped]
f) In a terminal, type: sudo chown <username>:fuse /media/network [sudo chown dave:fuse ~/network]
g) Double check that the permission to use fuse took. Applications>System>Users and Groups... Manage Groups...
find fuse and choose properties. Make sure your user name account is in that group and check-marked.
h) Reboot the system and triple check with step (g)
i) In >Settings>SettingsManager>SessionAndStartup>Application Autostart... Add an application... name and describe as you wish...
for command line, put: fusesmb /media/network (Or whatever mountoint you created).
j) Open Thunar, and navigate to the parent folder of your mountpoint... then drag the 'mounpoint folder' to the places
(shortcut) pane of thunar.
k) Logout and log back in (So the user privilege and fusesmb autostart will take affect)
TODO
* Icon & font size/grid (closer to Win7 compact)
* Better default edtior (textpad-like: regexp, column/block select)
Kate, "Programmers Notepad 2"
* BC or similar (GUI diff)
* ix7000 printer
* Setup screensaver/power mgmt for screen
* Fonts
* Wallpaper
* Enable IPv6
* Move taskbar to bottom
UNFIXABLE, WITH WORKAROUNDS
* Mouse wheel scroll in vim (man, etc.):
Known bug. Live without it.
* DragDrop icons at drop location instead of next open spot
* Move multiple icons at once (group select & drag)
Works fine in Thunar, not on desktop - live with it
* GUI move vs. copy vs. link [The following applies to Thunar ONLY, not XFCE desktop]
Shift+Drag: Move
Ctrl+Drag: Copy
Ctr+Shift+Drag: Link
(Note how the mouse pointer changes)
That last step messed up the machine so badly that I had to, again, wipe the machine and reinstall the OS. I probably could have un-done the changes, but without convenient access to Windows shares, there wasn’t much point.
KDE4 on Kubuntu 11.10 x64:
Last, I tried KDE on Kubuntu.
KDE4 (4.8) is very powerful. Lots of eye candy – in fact way too much; it was on my list to turn a great deal of it off, but I never got that far. Kate is a powerful editor; I like it a lot. Dolphin is a very capable file browser, it can easily handle not only Samba, but also FTP folders, and (unlike Nautilus on Gnome2) it handled softlinks to Samba shares in a smooth and seamless way. It’s better than Windows Explorer.
I found the Plasma desktop very complicated and unfamiliar. One I found the “folder view” things got better, but I never did figure out how to get shortcuts/links/launchers for apps onto the desktop (or even the panel, which was easy on Gnome 2 and XFCE), or how to copy/move files on the desktop (worked fine in Dolphin tho). The default theme needed a lot of tweaking that I never got to (the text on the taskbar had such low contrast that it was mostly unreadable, etc.). And I mentioned the crazy busy eye candy that needed to be turned down.
But I still had major problems with Chrome/Chromium being incredibly slow (Firefox was OK). In the process of working on that I seem to have borked the system.
At this point I’d spent 3 weeks trying different flavors and versions of Linux, and again had a borked system (Win7 is far more stable than any of these Linuxes – never thought I’d say that, but it’s so). With a little luck my new SSD will show up tomorrow and I’ll install it and then Win7Pro on that and be able to get back to work.
I’d seriously consider Mac OS (OS X, currently Lion) as something else to try. It may be the only Unix varient OS with a really mature and stable GUI (all the Linux versions are fine at the command line…). The Mac Mini is not what I want, but is the only thing close to reasonably priced (if you order the base hardware and upgrade it yourself). So that might work, but I’d wasted enough time fiddling with computers this cycle. Maybe in 2 or 3 years I’ll try that, but before dropping the $1200 or so on it, I’ll download a VM with Mac OS and try it in a virtual box on Windows and see how I like it.
SETUP NOTES FOR KUBUNTU 11.10 x64
Install notes for ENOUGH with Kubuntu 11.10 x64
Started 2011-11-26 (gave up 2011-11-27)
>>> Marks unresolved problem
1. Update everything, reboot
2. Firefox (had trouble downloading avast with default browser)
3. Downloaded Avast .deb file; to install: [I was thinking the Chrome problems might have been due to a virus...]
cd /Downloads
chmod +x *
sudo apt-get install ia32-libs
sudo dpkg --force-architecture -i avast4workstation_1.3.0-2_i386.deb
avastgui
Enter key
Update database
Initial full scan of whole machine, thuro
crashes
Add "kernel.shmmax = 128000000" to end of /etc/sysctl.conf, reboot
Initial full scan of whole machine, thuro
4. sudo apt-get install rdesktop
5. Kate leaves backup files strewn about the desktop
Settings>Configure Kate>Open/Save>Advanced> add "." (dot) to "Prefix" under "Backup on Save".
Also enable for remote files
6. Right-click on K and set "Classic Menu Style" (so much faster!)
7. Uninstall:
KAddressBook (generates annoying warnings; useless)
KMail
Kontact
KOrganizer
KVkbd
kPPP
rekonq (using Firefox/Chrome)
LibreOffice (mostly; kept Math & Draw)
8. Rt-click on tray, then Akonadi, then Quit (remove it from tray permanently)
9. Set "folder view" on desktop (forgot how; something to do with the cashew)
This lets you see the files in ~/Desktop on the desktop
10. Rt-click destkop>Icons>Align to grid (yay!)
11. Somewhere along the line I did:
Copy data into ~/.
cd scripts; chmod +x * (rdesktop scripts now work)
12. Installed 7zip (p7zip) from Muon Sw Center.
13. Get NETBIOS working:
sudo kate /etc/nsswitch.conf
add "wins" before "dns". Result should look something like:
hosts: files wins dns
Then:
sudo apt-get install winbind
14. Samba - sudo apt-get install samba smbfs
15. Setup "classical share" for /home/dave:
sudo smbpasswd -a dave Setup SMB password for "dave"
sudo kate /etc/samba/smb.conf
Then add at end:
[dave] This is the share name
path = /home/dave
available = yes
valid users = dave
read only = no
browsable = yes
public = yes
writable = yes
Then
sudo restart smbd
16. Tweak Dolphin to taste:
Folders, Places, Main Toolbar
Add Seperator, Compare Files, New Tab, New Window, What's this to toolbar
Small icons
Remove menubar
17. Tweak kate to taste:
Small icons, text below
Settings>Configure kate>Spaces and Tabs, 4 and 8 places
Toolbar to taste
Documents to List Mode
18. Chromium (not Chrome), via Muon
19. Settings>System
Desktop Effects>all>translucency off
Default apps>Web browers>Firefox
(Note: "snapping" can be managed in Workspace>Screen Edges)
Printer>New Printer> (didn't find MP830)
19. Turboprint, rt-click in Downloads, "open with QApt".
Can't figure out how to add applet. Added to desktop (appears), tried to move>KDE4 crashed.
Added ix7000 printer, print test page.
Reboot.
Still problems with Chrome/Chromium being extremely slow. I enabled logging and tried to capture
a log (and strace) for posting, but when I ran strace the whole machine crashed.
On reboot, kate doesn't work anymore. Sometimes it shows up in the taskbar, but I can't find a way to get
at the window. I installed gedit to finish up these notes.
KDE was working pretty well for me up to this point - better than anything else, but I never did figure out
how to move/copy things on the desktop (in Dolphin it worked great). Dolphin and kate are both very good
when they work.
TODO
* Customize clock
* Remove mounted HDDs and "New Volume" from Dolphin Places
* Change theme to make stuff on taskbar more visible, less busy eye candy
* Change desktop icons
* Add launcher panel on left (hidden), or launchers to panel on bottom
* Add "7z" on right-click compress options (already installed p7zip)
* Icon & font size/grid (closer to Win7 compact)
* BC or similar (GUI diff)
* Setup screensaver/power mgmt for screen
* Fonts
* Wallpaper
* Enable IPv6
* Latest NVidia driver
* Start moving files over
* 3DConnexion SpaceNavigator & driver for Google Earth
* Move Google Earth database (placemarks)
* PDF reader in Chrome that will handle TI document and print-to-file OK
* Links to folders on other machines
* Turn off auto-snap to borders
* MPLAB X and C32
* Wine/Virtualbox vs VMWare
MS Office 2003
Photoshop
Sony Vegas
* Write scripts to:
Follow Windows .LNK files (when double-clicked; open Nautilus)
Create launcher to open Nautilus at SMB share folders
Look at:
http://hanschen.org/2010/03/04/10-things-you-might-want-to-do-in-kde-sc-4-4/
http://hanschen.org/2011/05/15/7-ways-to-switch-activities/
http://userbase.kde.org/Plasma/HowTo
http://userbase.kde.org/Plasma
http://userbase.kde.org/Glossary
>>> After downloading from Firefox, rt-click on file offers "Open containing folder", but if you pick it it doesn't know what program to open it with (should be Dolphin). Where is Dolphin?
KDE TERMINOLOGY
Activity A screenfull of Widgets (dedicated to a task)
Cashew/Toolbox A tool usually in upper right corner for managing Activities
Act. Mgr Three dots (red/blue/yellow) for managing Actvities
Two boxes on left These select windows (workspaces)
K Start menu
Panel A thing that holds icons or widgets
UNRESOLVED ISSUES
* No drag-n-drop when using XRDP. Fix, per https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/587856 is:
apt-get install libgtk2.0-0=2.20.0-0ubuntu4 libgtk2.0-bin=2.20.0-0ubuntu4 libgail18=2.20.0-0ubuntu4 libgail-common=2.20.0-0ubuntu4 gtk2-engines-pixbuf=2.20.0-0ubuntu4apt-get install libgtk2.0-0=2.20.0-0ubuntu4 libgtk2.0-bin=2.20.0-0ubuntu4 libgail18=2.20.0-0ubuntu4 libgail-common=2.20.0-0ubuntu4 gtk2-engines-pixbuf=2.20.0-0ubuntu4
* How to make SAMBA/NETBIOS work before local login?
* Widen mouse target for dragging the window sizes
Use Alt-MiddleClick for now; may not be any better way
CONCLUSIONS
* Neither LibreOffice nor Google Docs is (nearly) compatible enough with
MS Office 2003 to transition. (as of 2011-11 anyway)
* kate is pretty good (see "Programmers Notepad 2" for a possible free alternative)
Back on 28 October I covered the first 3 flights of the “Autonomy” (now “Autonomy 1”) rocket glider.
We flew it six more times, four times on 5 November 2011, and twice more on 19 November. On the last flight I forgot to arm the electronics (sigh)1, so this winter we’re planning to build “Autonomy 2”.
At the moment, the main problem we’ve been having is that the GPS loses lock on the satellites a few seconds into boost, and never regains it during the glide. Without valid GPS fixes navigation is impossible, so this is a major problem.
By way of background – the glider is meant as a way to prove out the navigation and control software for autonomous steered-parachute recovery of rockets; see this post for more details. Fellow CMASS member Boris K. built the glider airframe; I did the electronics.
From the logged data in flash, on flights 1 and 3 (the bad ones), the parachute ejection was triggered by the failsafe “TimeToImpact” calculation, well above the 200 foot (60 m) deployment altitude. The rocket decided it was less than 4 seconds from impact while descending at > 30 MPH (13 m/s actually) so it popped the chute, despite still being well above the deployment altitude.
Only on flight 2 (the good one) did the 200′ altitude trigger a flare and then deployment.
Unfortunately, on flight 2 it looks like the GPS signal dropped out partway thru the glide. At first I thought this was because the camera (wrapped in foil) shadowed the GPS antenna, but looking at it again I don’t think that’s it. I don’t know what it is – I haven’t seen this on prior flights (under a parachute).
Also the altimeter data was really noisy – it makes it very difficult to figure out the sink rate while gliding. (See graphs at the end of this post.)
After fiddling on the bench a lot, I concluded that the source of the noise (most of it anyway) is small variations in the power supply voltage (3.3v) caused by load from the servos and radio (which draw on the same battery, but prior to the 3.3v regulator). I could see the altitude readings jump around each time a servo draws current.
Prep for 2011-11-05 flights
In preparation for the 11/5 flights, I made the following adjustments to the glider:
Reduced parachute deployment altitude from 60 m (200′ AGL) to 45 m (150’ AGL) to get more glide time.
Reduced YAW_FACTOR from 1.0 to 0.1 (100 to 10) to make it less sensitive. This makes the servo response less sensitive by a factor of 10 in yaw – this is the most I think it can be reduced and still have positive control in yaw.
Tweaked the port elevon 3 half-turns down to try to trim out gentle left-turning tendency seen on flight 2 of 2011-10-22.
Adjusted YAW_STOWED_POSITION from 0 to -1 (50 to 0) to induce a slow roll during boost to counteract any pitch tendency during boost.
Adjusted PITCH_STOWED_POSITION from -0.4 to -0.54 (30 to 23) to counteract pitch-up tendency during boost seen in 2011-10-22 flights. I think AstronMike was correct in his suggestion on TRF – this is caused by differential drag on the rudder (hadn’t thought of that – thanks for pointing it out!).
Lengthened the flare period from 3.0 to 4.0 seconds.
Most of these parameters can be tweaked on the pad with telemetry commands.
Second set of flights
On 11/5 we flew four more times. All four flights resulted in nice glides; the software tweaks seemed to help a lot. Ascent was nice and vertical, the yaw over-control problem got solved.
Unfortunately, the logged data shows that the GPS signal dropped out – again – after a few seconds on each and every flight.
On flight 1, Boris steered in the “yaw” mode, where he directly controls the yaw input to the servos. We used a “YawFactor” value of 10 (out of 100), so it was 1/10th as sensitive as on the previous flights.
Here is the video (first from the ground, then from the onboard camera):
On flight 2 we enabled autonomous navigation. As you’ll see, it overcontrolled a little bit (and because of the GPS dropout, navigation was impossible).
Flight 2:
After flight 2, we reduced YawFactor from 10 to 5, making it half as sensitive in yaw. This reduced the overcontrolling in yaw.
One flight 3, Boris steered it in the “forced navigation” mode. Here his knob inputs were used to force the navigation system to choose a steering command – this results in steering updates that are coarser and less frequent than in the “yaw” mode, but it allows the navigation system to learn from the response of the glider. Again, since the GPS didn’t work, the nav system had nothing to work from.
Flight 3:
For the last flight of the day we tried a larger motor, hoping for more glide time and more data. We got lots more glide time (a great flight), but again the GPS failure meant no useful data. This altitude (1300+ feet AGL) is about as high as I’d want to go with manual steering – any higher and it becomes hard to see which way the glider is pointed.
Flight 4:
The loss of GPS sync was again frustrating.
One possibility was a bad GPS unit – this was a new unit that had only flown on the glider. But it performed fine on the ground.
Another possibility was something about the glider flight dynamics that the GPS firmware can’t handle. The glider flies much faster than a parachute glides, while descending at a faster rate than an automobile normally would. Maybe this confuses GPS firmware that’s tweaked for use in cars.
The last idea I thought of was possible RFI from the camera, despite the foil shielding.
Prep for 11/19 flights
I corresponded with the GlobalTop (GPS maker) people – they said there is a dynamics setting in the GPS chipset I didn’t know about:
Regarding the dynamic conditions, you can execute PMTK command for setting. Our output speed is horizontal speed not vertical speed. Also, we don’t have higher accelerations.
PMTK command:
$PMTK302, MODE
Mode: Dynamics mode.
0 : Default ( fixed status)
3 : Slow Ground Vehicle (tractor, boat etc)
4 : Fast Ground Vehicle (car, train etc)
5 : Airbourne Low dynamics (<1g)
$PMTK302,3*2C<CR><LF>
//
Query Dynamics type
$PMTK402*34<CR><LF>：API_Query_Dynamics
Sure enough, the GPS was set to $PTMK302,0 (default) when I checked, so I changed it to $PTMK302,5 (Airbourne Low dynamics). I also ordered some of their new “PA6C” GPS units (successor to the PA6B I’m using now) – they said it has some features that make it (a bit) more immune to noise (a lot lower power, too).
Separately – I finally found the source of the altimeter noise. I was using the internal AVdd as the ADC reference voltage instead of the external pin. You wouldn’t think it would matter, since they’re both supposed be at Vdd – but it makes a huge difference.
Here are the results from my testing – the numbers are the standard deviation of the altimeter noise, in meters AGL:
The radio draws lots of current (> 100 mA) each time it sends a packet; so I used that as a way to test what happens when something draws lots of current.
(I used the battery – 2 alkaline ‘C’ cells in series – as a reference “clean” power source.)
So, as Adrian A. (of http://www.featherweightaltimeters.com/) said on the TRF forum, the LDO supply is cleaner, but only by a little – almost all of the difference comes from using the external VRef+ pin. I think the DCDC supply is clean “enough” once I use the VRef+ pin.
I also swapped out the GPS for another one, that I flew in rockets before (under a parachute) and had worked well there.
Final two flights – 2011-11-19
On the first flight I was optimistic that navigation would work. We flew it first on a ProX G125 because the day was extremely windy and we didn’t really know how that would affect things (we only flew it on calm days previously).
Here’s the flight as seen from the ground:
You can see the parachute ejected but didn’t inflate – it remained stuck in the nose cone. Luckily there wasn’t any damage on landing, but we’ll try to avoid this problem on the next glider.
It did about 400 feet AGL (as expected with that motor), but after apogee it just spun around, because the GPS lost satellite lock about 1.6 seconds into the boost (as expected) but never regained it after apogee (not as expected).
This is extremely frustrating. I don’t know why the GPS loses lock in the glider, but works fine under the parachute. I set the high-dynamics mode (as mentioned earlier) but it seems this didn’t make any difference.
I suppose it’s possible there is some interference from the camera electronics. We didn’t unplug the camera for this flight because I thought it would likely work OK with the dynamics setting. However the GPS works fine with the camera running on the ground.
I just got 5 new “PA6C” GPS units from GlobalTop. I won’t have a chance to fly them before spring, but they say they’re less sensitive to interference than the PA6B I’ve been flying. I hope that fixes it.
We have no video from the on-board camera because we haven’t recovered the glider (and camera) yet – the video is still in there.
This flight did serve as a test of the modified altimeter. The results are mixed. The altimeter readings seem to have much less noise on the ground and during boost, but just as bad as ever during glide.
The graph below shows time (seconds, X-axis) vs altitude (feet AGL, Y-axis) for 3 flights – dark blue is this flight, magenta is the very first flight of the glider (in October, similar motor) and yellow is the 2nd flight of the glider (also in October, obviously on a larger motor):
The rocket collects an altitude reading 25 times/second (every 40 milliseconds); that’s what’s plotted here.
You can see that post-modification (dark blue) there’s a lot less noise in the altimeter up until apogee. But after that there’s still very strong noise – the altitude jumps up/down by as much as 40 feet.
I think that perhaps what I’m seeing here is a ‘whistle’ effect of air blowing and vibrating across the vent hole on the bottom of the glider. If so, it only happens in the glide configuration (which is imaginable). There’s just the single vent hole, but the electronics bay hatch (opposite from the hole) is not airtight. Suggestions for how to rearrange things to avoid this (if indeed this is the cause) will be greatly appreciated.
At the top of the graph is the battery voltage (2 x LiIon) * 100 (in cyan). There are 4 distinct dips – these correspond to current drain from (1) servos driving the elevons to boost position upon launch detect, (2) servos going to glide position at apogee detect, (3) servos going to flare position at 150′ AGL, and (4) parachute ejection current.
For the second (and it turned out, last) flight, we went to a bigger Cesaroni 296H110 motor for more altitude. Here’s the video:
I realized about 5 seconds after the crash that I’d forgotten to arm the electronics before launch. That’s a bad feeling.
With the electronics disarmed, the elevons stayed in the boost position (streamlined) for the whole flight, and the parachute didn’t deploy. It crashed across the Pow Wow river in the swamp. I didn’t see where it ended up, but I know where it is within 30 feet or so. It didn’t seem worth risking pneumonia to wade across the near-freezing river to recover the wreckage, so it’s still there. (Boris thinks it might have landed in the river itself and gotten washed downstream.) Maybe once the river freezes solid this winter I’ll try to recover it.
Here is Curtis Heisey’s photo of Autonomy 1 on it’s last flight:
It looks like I have a busy winter ahead.
This is the 2nd rocket I’ve lost in my rocketry career due to forgetting to arm the electronics. Like everyone, I’ve seen it happen to others too.
So one of my winter projects is to build a box that will sit next to the launch pad. This will connect to the ignition leads from the LCO, and have a relay inside, with the motor igniter connected to the relay. The relay will not close unless the box gets a radio message from the rocket saying that it’s armed. I should have done it long ago. ↩
I’ve been collecting a summary of the proprietary extension commands for NMEA GPS modules based on the MediaTek (MTK) chipsets.
Here (click to download Excel file) is the summary of all the $PMTK commands I’ve found so far. The source documents (which you’ll need for details of the parameters) are on the Web – ask Google for them.
Not every command will work on every module. You can find out if yours supports a given command by sending it and watching for the response. $PMTK001,code,3 means it worked.
Many of the commands have three variants – a code that sets a parameter, another you can use to query the current setting, and a 3rd that the GPS uses to reply to the query.
If you know of others not in the list, please contact me (as much detail as possible please) and I’ll add it.
On Thursday I got a new PC and decided to really try to use Linux as my main operating system.
I’ve made abortive attempts before, but always ended up going back to Windows. I’m no Linux expert (I did use Unix a little as a user back in the 1980s, but never did any scripting or programming in it.)
So far it’s going reasonably well; I decided to try Linux Mint (11, x64) this time instead of Ubuntu – it has a lot of the necessary stuff (like Samba) needed to talk to Windows networks already installed.
One problem I had was I was unable to launch rdesktop (a RDP client) from a Gnome launcher. Nothing happens when I try – I still don’t know why.
I found a workaround – start it from a script launched from the Gnome desktop.
Here’s how. From a terminal window do:
cd ~
mkdir scripts
cd scripts
gedit startRDP.sh
Then paste the following into the file:
#!/bin/sh
# Usage: startRDP ipAddress[:port] [[username [password]]
# Free software by nerdfever.com. Public Domain. 2011-11-13.
if [ “$1” = “” ]; then
echo Usage: startRDP ipAddress[:port] [[username [password]]
return 1
fi
if [ “$2” = “” ]; then
padsp rdesktop -a 32 -g 95% -r clipboard:PRIMARYCLIPBOARD -r sound:local -x 0x80 $1
return 0
fi
if [ “$3” = “” ]; then
padsp rdesktop -a 32 -g 95% -r clipboard:PRIMARYCLIPBOARD -r sound:local -x 0x80 $1 -u $2
return 0
fi
Substitute the client machine’s IP address (and optionally :port) for 192.168.1.111.
Substitute your username/password for username and password. You can leave off password, or both username and password if you want to get prompted for these manually.
Since then I’ve tweaked the board a bit, to the point where the hardware design is clean and bug-free (as far as I know).
So here is the current version of the board schematic and layout, including the original Eagle PCB files as well as a PDF version of the schematic. It runs nice and stably, and could be the basis for a lot of other PIC32-based projects.
Compared to earlier versions, this one uses a DC-DC step-down for much more efficient use of the battery, and includes the reed-switch driven power on/off system I described earlier.
You are welcome to do with this as you like (modify, republish, whatever). To make it official:
Hardware rights: I hereby grant everyone and everything in the universe permission to use and modify this hardware design for any purpose whatsoever. In exchange, you agree not to sue me about it. I make no promises. By using the design you agree that if you’re unhappy the most I owe you is what you paid me (zip, zero, nothing, nada). That seems fair.
I do ask that you credit this site (https://nerdfever.com) and post as the source, just as a courtesy; but you don’t have to.
Eventually (maybe this winter), I hope to do a new spin that will run off a single LiIon cell (instead of 2 in series, as now), and that will provide a cleaner power supply to the pressure sensor and ADC; noise on the power supply is the main source of noise in the pressure sensor readings (as far as I can tell so far). But this version works quite well as it is.
For more info about the board, leave a comment and/or see my earlier posts:
Saturday 2011-10-22 saw the first three flights of the rocket glider.
(Most of this post is adapted from this thread where there are more details.)
Only one of the flights was really good, but we learned a lot from all 3; and the glider is in good shape.
Boris and I decided to name it the “Autonomy”. Our goal for the day was to get some flight information about the proper pitch setting for a nice stable glide.
There is still a lot of data analysis to be done, but you can look at the videos below. The whistling noise on the audio track is a good indication of relative airspeed, I think.
Flight 1 – Roadrunner G80 (115 N·s)
Video from the ground:
Video from the on-board camera (looking out the bottom of the glider):
Immediately after apogee the glider went into a sharp roll to the left. This was because I forgot to turn off the navigation system, which hasn’t yet been calibrated for the roll sensitivity of the glider. It commanded left yaw and put it into the roll. While spinning it lost lift and dived toward the ground.
The parachute deployed at 200 feet AGL as planned. No damage other than a very tiny zipper (similar to the one on Friday).
Flight 2 – CTI/AMW H54 White Longburn (168 N·s)
This was our best flight of the day. I remembered to turn off the navigation system.
Video from the ground:
And from the on-board camera:
The glider arcs over a little prematurely. Looking at the video, I think this is because the “straight” boost position for the elevons actually is slightly pitch-up, so the glider tends to arc up (toward the rudder) during boost.
I think we can reduce this in future flights by (a) adjusting the boost position a little bit pitch-down, and (b) adding a little bit of yaw command to the boost position to induce a slow roll during boost to even out any pitch-up/pitch-down tendency.
By chance the glider was right-side-up at apogee, and the transition of the elevon position from straight (for boost) to the glide position is very clear in the video. When the elevons go to glide position the glider does an Immelmann turn (due to the high airspeed at apogee – this was a pure accident) and then settles into a steady glide.
The really good news here is the glider does seem to be self-stabilizing due to the dihedral; regardless of what attitude it was in at apogee, if left alone it seems to settle into a stable glide.
During the glide, Boris was manually adjusting the pitch setting via the telemetry system. The effects of this aren’t too obvious in the video, but I’m hoping to learn more when I look at the logged data (servo position vs. climb rate, airspeed, etc.).
Three seconds prior to parachute ejection, as planned the elevons go full-up to induce a flare for airspeed reduction. This is hard to see from the ground video, but the pitch change is pretty clear from the on-board video.
I plan to look carefully at the GPS data from this flight (also correlating that with the two video streams). I hope to get a sense of the forward airspeed of the glider (at various pitch settings), whether or not we have enough control authority to do a full-stall flare (and how long it takes to do that), sink rate, etc.
Flight 3 – CTI/AMW H100 Imax (286 N·s)
On the last flight of the day we tried a somewhat larger motor, aiming to get more glide time and a chance to try manual yaw control.
This time I worked the radio controls (probably a mistake) and Boris ran the camera.
Ground video:
On-board video:
Again you can see the glider pitching up during boost, causing a premature arc-over and too high an airspeed at apogee. It’s more pronounced here than in the prior 2 flights.
It’s hard to tell from the ground video (Boris, you need to zoom in more!), but you can see that at about 0:13 on the on-board video, as soon as I switched on the manual yaw control, I massively over-controlled it and the glider went into a sharp left roll, and dived that way toward the ground, much like in flight 1.
Clearly the glider is VERY sensitive in roll (as predicted by some posters here).
On flights 1 and 3 (the bad ones), the parachute ejection was triggered by the failsafe “TimeToImpact” calculation, well above the 200 foot (60 m) deployment altitude. The rocket decided it was less than 4 seconds from impact while descending at > 30 MPH (13 m/s actually) so it popped the chute, despite still being well above the deployment altitude.
Only on flight 2 (the good one) did the 200′ altitude trigger a flare and then deployment.
Unfortunately, on flight 2 it looks like the GPS signal dropped out partway thru the glide. At first I thought this was because the camera (wrapped in foil) shadowed the GPS antenna, but looking at it again I don’t think that’s it. I’m not sure what it is – I haven’t seen this on prior flights (under a parachute).
For our next flights (November 5 is the schedule), I’ve made the following changes:
Reduced parachute deployment altitude from 60 m (200′ AGL) to 45 m (150’ AGL) to get more glide time.
Reduced YAW_FACTOR from 1.0 to 0.1 (100 to 10) to make it less sensitive. This makes the servo response less sensitive by a factor of 10 in yaw – this is the most I think it can be reduced and still have positive control in yaw.
Tweaked the port elevon 3 half-turns down to try to trim out gentle left-turning tendency seen on flight 2 of 2011-10-22.
Adjusted YAW_STOWED_POSITION from 0 to -1 (50 to 0) to induce a slow roll during boost to counteract any pitch tendency during boost.
Adjusted PITCH_STOWED_POSITION from -0.4 to -0.54 (30 to 23) to counteract pitch-up tendency during boost seen in 2011-10-22 flights. I think AstronMike is correct – this is caused by differential drag on the rudder (hadn’t thought of that – thanks for pointing it out!).
Lengthened the flare period from 3.0 to 4.0 seconds.
Maybe other things once I’ve looked more carefully at the logged data. We’ll see.
As I mentioned a couple of posts back, my last flight, on 24 July 2011, crashed after reaching about 7300 feet AGL.
Another flyer – Stan Speegle of OROC – eventually found the crash site, and was nice enough to collect the wreckage and send it to me for analysis. Here’s what I found when I unpacked his box:
That rocket won’t be flying again. Interesting how high-speed crashes create “accordion”-like wreckage; very different from the result of low-speed crashes.
Despite the 280+ MPH impact, a lot of parts were still usable – the nosecone was undamaged (because it was ejected milliseconds before impact) and the G10 fiberglass fins can be used again, as can lots of little bits of hardware.
The only real surprise was that the apogee ejection charge hadn’t gone off at all:
The charge holder on the left was the backup; that fired a few hundred milliseconds before impact.
The holder on the right fired 240 milliseconds after (detected) launch; but the charge didn’t go off. Unwrapping the flashbulb revealed that the bulb had fired, but not ignited the ejection charge:
This is the first time I’ve been able to confirm that AG1 flashbulbs don’t always ignite the ejection charge (I suspect, but can’t prove, that it happened once before). Overall AG1 bulbs are still a pretty reliable ejection trigger, but clearly not 100%; from now on I’ll be using some kind of backup ignition with them.
The electronics PCB was banged up, but I was able to get it running again with some unbending and resoldering of pins. I downloaded and analyzed the data stored in flash memory; it just confirmed what I’d already figured out from the telemetry.
At this moment (September 2011), it seems that the main problem I’ve been having with getting the parachute to steer properly is twisting of the control lines (see previous posts). I probably should have figured it out earlier, but the problem didn’t become totally clear until I could see it happening with the on-board 808 keychain camera. I’d been misled by the results of flight #28 way back in July 2010, which seemed to work OK with a tiny 2.5″ baseline – but it seems that was just luck.
Before my next flight, I plan to redesign and rebuild the steering system so that it has a much larger baseline. The comment by Tom Hannan posted July 29 on the project page hits the nail on the head, I think – the GPS and steering mechanism needs to be mounted right at the pivot point of the parachute, not any further down. This should cut way down on the swinging. I’ll try to make the parachute lines much harder to tangle while I’m at it. I also need to implement a apogee-detect lockout for a few seconds after launch (to avoid the problems in my last flight, on July 24). I’m not sure when that will be ready – probably October/November.
At the same time, I’ve been working with fellow CMASS rocketeer Boris Katan on a closely-related project – a rocket glider with GPS-steered recovery, based on the same electronics and software. We started back in June or so. At that time I thought the main problem with the system was swinging of the GPS under the long parachute lines – the GPS could conceivably be swinging in one direction while the parachute flew in another, which would certainly confuse my navigation algorithm. Also, I knew then that I had lots of problems with line tangling preventing reliable parachute deployment. Boris suggested that a rocket glider might be a way to test the navigation system without the complexities of the parachute – no long lines and swinging, and no tangling.
I thought it was a great idea, and we agreed to work on it together – Boris is building the airframe of the rocket glider, and I’ll be installing my electronics and servos into it to steer it. Boris started a thread on The Rocketry Forum about the project – there’s lots of info there.
Boris first built a 1/3 scale model of the final glider – here it is before flight:
This flew twice on August 11 – both times fine, proving the stability of the design (see the TRF thread for more details). Now he is building the full-scale glider – here’s a recent picture from Boris – you can see the hole in the 3″ body tube for the electronics bay:
The delta-wing glider will steer with two elevons, using two servos to drive it. This will give us both yaw and pitch control, so we can flare the glider as well as steer it left/right. The elevons will be set flat (minimum drag) for the rocket boost. Then after apogee the nav system will try to steer it back to the pad. When the glider gets close to the ground (100 feet AGL or so), it will flare (to minimize airspeed) and deploy a parachute for a soft landing. I’ll be building up a new set of electronics to go in the glider, and working on some minor changes to the way the servos are driven in software, to allow both pitch and yaw control. We’re aiming for a first test flight on October 22 – but no promises.
The other day I got an email from Mike Passaretti way down in Western Australia, who saw my project here, and is working on a similar one of his own. His very first test flight was last weekend. Mike seems like a very experienced engineer, and I think has a good approach. There’s a very interesting thread on his project on the Australian Rocketry Forum. Maybe we’ll have a chance to collaborate – that would be fun.
Now that I’ve caught up the blog, I can go back to work. Watch this space.
After the July 16 launch (see previous posts) I only had a couple of days to fix things before it was time to drive out from Boston to metropolitan Brothers, OR for the OROC Desert Heat launch.
I repaired my 3″ “Thrud” rocket, changed the apogee detection algorithm, fixed the servo pulse problem, did some quick testing, and then packed up the motorhome for the trip.
On July 23, I flew my 4″ SuperHorizon rocket with the new software on a Skyripper J144 in the spacious Oregon desert:
Apogee detection was a little late, but not as much so as before. Looking at the logged data afterward, I suspect the algorithm is working fine, but the vent holes for the altimeter are too small.
As you saw on the video, the parachute deployed but didn’t fully inflate at first – after about 8 seconds it untangles enough to fully inflate. Here is the graph of altitude (feet AGL) vs. time – you can clearly see the high descent rate slow down when the parachute fully inflates:
Once the chute inflated, I had a very nice descent with a good chance to steer manually. Unfortunately, the steering didn’t work at all – the parachute just descended doing another slow counterclockwise turn.
But I got a strong hint as to why – have a look at the onboard camera video:
I think this is a really cool video because you can see the packed parachute and hear the wind whistling just before ejection.
I should have figured it out before, but it is completely clear from this video that the parachute lines are badly twisted together right from the moment of inflation. With the lines twisted like that, when the servo pulls on one line, the other inevitably gets dragged along, so no real steering happens.
The lines untwist gradually, becoming straight just a few seconds before landing.
I wasn’t able to redesign things out in the field, so the the next day (July 24) I packed the parachute even more-er carefully-er and flew the 4″ rocket again, this time on a Cesaroni I195:
I had some ability to steer the parachute manually at the very start of the descent, but then lost it as the descent continued. And here is why:
My careful packing paid off – the parachute deployed untangled. Mostly, anyway – the line going to the nose cone can be seen draped over the two parachute control lines. This isn’t good, but it wasn’t so bad that it prevented steering altogether.
But as the descent continues you can see the lines twisting together. And that’s when I lost steering control.
After looking at this video, it became completely clear that the reason I’ve been having so much problems getting the parachute to steer for the last year is that my steering baseline (distance between the origin of the left and right control lines) is far too small – this allows the control lines to twist together under the parachute. I need to redesign the steering system to provide a much larger baseline.
The afternoon was the end of the launch, so I decided to get as much data as possible from my last flight, taking advantage of the rare chance (for me) to fly in a really big desert field. I put my biggest motor, a Cesaroni J395, into my smallest rocket, the 3″ Thrud.
The result was not good:
I lost sight of the rocket on ascent, and never found it again. But the telemetry worked. As you can hear on the video, the telemetry reported the rocket coming down very, very fast. And some observers on the ground thought they saw pieces coming off it near apogee.
I analyzed some of the telemetry data after the flight, and got the following graph:
The maximum climb rate on the way up was reported (by telemetry) as 302 m/s (676 MPH, about Mach 1). The descent rate reached 126.8 m/s (284 MPH) just before loss of signal.
A lawn dart.
Unfortunately, the telemetry didn’t have any valid GPS data, because the high vertical speeds seemed to prevent the GPS from holding lock on the satellites. My son and I searched for the rocket for over an hour, but never found any of it.
After the flight, I tried to analyze what went wrong. The telemetry gave an apogee of 7316 feet AGL (a personal record). But the telemetry also showed that the rocket detected launch at 93 feet AGL, then just 40 milliseconds (one cycle) later, falsely detected apogee and fired the ejection charge at a reported (but highly unlikely) altitude of 8 feet AGL. This immediate (and unreal) dip in measured altitude almost certainly caused the false apogee detection.
It’s clear from both video and telemetry that the parachute didn’t deploy just after launch. Launch mass was about 2.2 kg. Based on the published thrust curve of this motor, the rocket should have left the pad at about 22 Gs of acceleration; my best guess is that the 22 x normal weight of the nosecone just after launch was enough to keep it on the rocket despite the ejection charge.
My theory at this time is that the false apogee detection was caused by the high G forces at launch. Most of my rockets leave the pad at 4 to 6 G; this one left at 22 G. The Freescale MP3H6115A pressure sensor is known to be sensitive to physical flexing – probably the G forces flexed the sensor, leading to the false reading. I’ll have to implement a software “lockout” to prevent this from happening again.
The flight was a useful radio range check; the graph above plots time against AGL altitude, RSSI, and LQI, both scaled to 10,000 as the max reading (all from telemetry); as you can see the radio still worked well at a distance of about 1.5 miles, although the signal strength was starting to get low.
I did have a backup ejection charge setup. And it worked exactly as (poorly) designed. At 200 feet above the pad elevation, the rocket was descending too fast, so the rocket fired the backup charge. You can see the overpressure from the backup charge in the altitude graph (above). Unfortunately, 200 feet at 280 MPH is less than half a second. The backup ejection happened just 200 milliseconds before the last telemetry record was sent (when the rocket either impacted or went behind a hill shortly before impact); nowhere near enough time for the parachute to deploy. In retrospect, I should have made the backup system depend on the time to impact (based on descent rate) instead of simply altitude. Oops.
About a month later, the debris was found by Stan Speegle of OROC, who was nice enough to call and tell me about it. Sure enough, he found the parachute partly deployed, and the rest of the rocket smashed into tiny pieces. He’s promised to mail the wreckage back but I don’t have it yet – maybe I can still extract some data or video from it when I get it.
