Electronic Flight Cards?

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Thanks for the feedback!

Kit/Scratch field I see as a safety issue. If it's a kit, it's usually a proven design. If scratch, may be a heads-up. Of course, nothing stops a kit from being a heads-up and an established flyer is usually fine with a scratch.

Agree on boolean/checkbox. Also like the color fields being added.

Plus: out is nice to tell folks which kit because it drives sales.
 
Loaded weight/mass also needs to be flexible enough to handle grams, kg, and pounds/ounces. It might be worth having two fields, one labeled grams and one lbs/ounces. We can probably trust people to do the conversion from kg to grams themselves. Hopefully nobody shows up with decimal pounds.
Okay, so what I'm doing is putting together a data interchange format specification. Whether or not the application's presentation layer (read: user interface) asks for weight (in pounds, ounces, carats, etc) or asks for mass (SI units, natch) is irrelevant. When placed into the format for transfer between two systems, standardize on ONE unit. The applications can convert to the users' preferred unit before display. Since we've already standardized on Newtons (SI) for thrust, I believe it's probably best to standardize on mass in grams (SI) for that field.

Again, *your* program/application can display it however it wishes. Between two computers, which you don't see, it stays in SI.
 
Okay, so what I'm doing is putting together a data interchange format specification. Whether or not the application's presentation layer (read: user interface) asks for weight (in pounds, ounces, carats, etc) or asks for mass (SI units, natch) is irrelevant. When placed into the format for transfer between two systems, standardize on ONE unit. The applications can convert to the users' preferred unit before display. Since we've already standardized on Newtons (SI) for thrust, I believe it's probably best to standardize on mass in grams (SI) for that field.

Again, *your* program/application can display it however it wishes. Between two computers, which you don't see, it stays in SI.

OK, that makes sense. I always use grams, so I'm content to bend everyone to my will. I just want to make sure that somewhere along the line there's a way for people to enter pounds and ounces so that those who are more comfortable in Freedom Units have an opportunity to do so. This transition is going to be hard enough without forcing unit changes too. :)
 
It would be nice, since you have weight and thrust, to do the simple calculation and populate a "thrust:weight ratio" field automatically, for quick check by the RSO. I know as an RSO I've made mistakes trying to calculate this in my head when the thrust is in N and the weight is in, say, ounces.
 
It would be nice, since you have weight and thrust, to do the simple calculation and populate a "thrust:weight ratio" field automatically, for quick check by the RSO. I know as an RSO I've made mistakes trying to calculate this in my head when the thrust is in N and the weight is in, say, ounces.

This is a great idea!
 
Google docs looks like a good realtime solution. we have a battery operated UV-C sterilizer for regular paper cards, but can only do 4 at a time (5 min. cycle) so it's pretty slow going that route...
 
Google docs looks like a good realtime solution. we have a battery operated UV-C sterilizer for regular paper cards, but can only do 4 at a time (5 min. cycle) so it's pretty slow going that route...

It is a good idea, but how long do you expose them? Not great research on COVID.
 
I always felt that a ton of the fields that existed on flight cards were just for personal interest, to be announced during the flight and in launch reports afterward. No real functional importance, but interesting to some.

I just see some cards that are like a pre-flight checklist and then the actual announcement is something like "Here is Steve's <rocket name> on a <motor> with <recovery info>" There might possibly be a bit of mocking abuse as well, however that is almost always ad-hoc. . The rest is just of interest to someone. The issue to me is either the card gets unwieldly or the fields are too small to fill out legibly.

If this electronic flight card does not fit in one screen, it just becomes another chore. Plus if you can't see the screen due to glare, you are stuck. One other thing. If the author leaves the club, how do you make sure you have someone to maintain it?


I love technological innovation however this one, to me, is a solution in search of a problem. Of course that is my $0.02 and YMMV.
 
Last edited:
Google docs looks like a good realtime solution.

The problem with Google Docs is that it requires connectivity to the internet. This is difficult if not impossible at many launch sites. Sending data back and forth from one device to another doesn't need to involve internet, it can be done with a local wifi connection, which is easy to set up, even at the most remote of spots. A google doc/sheet seems overkill, when you're just using it to hold a set of data and pass it back and forth. Just my 0.02, I'm not 100% sold on the e-card idea, but I hate to see it get started with an infrastructure that makes it 100% unusable for many sites.
 
WSR's Flight Cards are pretty simple (or so I think). Flyer Name and NAR# (we're an NAR Section after all).
Rocket Name,
Type (Kit, Plans, Kitbash, Original),
Scale (Original, Upscale, Downscale),
Deployment Type (Ejection/Dual Deploy/Ejection+JLCR),
Recovery (Parachute, Streamer, Tumble),
Launcher (1/8, 3/16, 1/4, 1010, 1515)
Motors (Stages, Clusters, sizes)
First Flight (yes/no)
Cert Flight (yes/no)
RSO Initials
Pad Assignment
Comments
 
I still favor e-cards, but how about we stop being afraid of a piece of paper??? Recently from the CDC:

https://www.cdc.gov/coronavirus/2019-ncov/prevent-getting-sick/how-covid-spreads.html
^^^This... unless the "piece of paper" is a tissue.

I get that we need to take precautions, but let common sense prevail. Wear a mask, do the social distancing thing, stay home if you're not well, and wash your hands occasionally. The average launch isn't like a concert or a sporting event, you're not crammed into a confined space. It would not be hard for the RSO/PM/LCO personnel to do their jobs with no-touch procedures. The chance of you getting anything from a launch is extremely small compared to going to places like the market or take-out food places, which ARE open.
 
Changed my mind from XML to JSON. (Easier to write, easier to document, easier for most folks to read, among other reasons.)

I've attached a copy of the flightcard.json definition. (Had to rename it with a .txt extension to make the forum software happy.)

Comments encouraged.
 

Attachments

  • flightcard.json.txt
    2.3 KB · Views: 4
That’s very good of you! The best of our organizations is represented by volunteers like you and others like you!
My pleasure, Steve. Something like this shouldn't have my name on it, as others from both orgs contributed by giving ideas. Just keep the GPLv3 or later on it. It's an open-source definition.

For those of you who want a higher degree of communication between the flyer app and the launch app, then add data structures tied to this set of minimums. If you modify the base data structures, you'll break app interoperability. If you add your fields to new data structures, then an app that doesn't use your extensions can safely ignore those fields and not break. I can see a vendor developing a suite of software that includes flyer apps (for use on Kindles, phones, tablets, laptops) and launch apps (for use by clubs @ launches) that integrate tightly. Go for it! This spec just makes sure that if I want to use my homebrew Python based flyer app, your app can read my flight card. And if someone has your flyer app, they can talk to my launch app, even if it's not yours. Yes, they'll miss some functionality in both cases, but the basics will be covered.
 
Changed my mind from XML to JSON. (Easier to write, easier to document, easier for most folks to read, among other reasons.)

I've attached a copy of the flightcard.json definition. (Had to rename it with a .txt extension to make the forum software happy.)

Comments encouraged.

May the great bird of the galaxy bless your planet for NOT using XML. I avoid it whenever possible as I think it has crossed the line between extensibility and usability. I am stuck with it for things like Web.config files but that doesn't mean I have to like it!
 
It's a text file. Try to find something that allows you to edit text. I just downloaded DroidVim, but I learned to edit on vi under UNIX a very long time ago, so you might want to try something else. There's lots of text editors on the Play Store. Just search "text editor".
 
Today, I am programming a requirement for Octoprint. Our next launch is in June - pending ability to hold it. The goal is to have a meeting from 6 feet distance to discuss this requirement.
 
It's a text file. Try to find something that allows you to edit text. I just downloaded DroidVim, but I learned to edit on vi under UNIX a very long time ago, so you might want to try something else. There's lots of text editors on the Play Store. Just search "text editor".
I looked at it in NotePad. Is there anyway to see how it would look like on a phone or tablet as a fillable form?
 
Back
Top