Electronic Flight Cards?

The Rocketry Forum

Help Support The Rocketry Forum:

cwbullet

Obsessed with Rocketry
Staff member
Administrator
TRF Lifetime Supporter
Global Mod
Joined
Jan 24, 2009
Messages
24,710
Reaction score
2,872
Location
Glennville, GA
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.
 

John Kemker

Well-Known Member
TRF Supporter
Joined
Aug 25, 2019
Messages
1,222
Reaction score
495
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.
 

boatgeek

Well-Known Member
Joined
Dec 27, 2014
Messages
2,566
Reaction score
995
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. :)
 
  • Like
Reactions: BDB

cwbullet

Obsessed with Rocketry
Staff member
Administrator
TRF Lifetime Supporter
Global Mod
Joined
Jan 24, 2009
Messages
24,710
Reaction score
2,872
Location
Glennville, GA
I prefer grams and Kgs now. I understand people not using them,
 

Kelly

Usually remembers to get the pointy end up
Joined
Apr 26, 2010
Messages
199
Reaction score
102
Location
Oregon
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.
 

BDB

Absent Minded Professor
Joined
Aug 22, 2015
Messages
2,053
Reaction score
345
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!
 

swatkat

Down these mean skies, a kat must fly!
Joined
Jun 25, 2014
Messages
1,602
Reaction score
242
Location
Sactown, CA
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...
 

cwbullet

Obsessed with Rocketry
Staff member
Administrator
TRF Lifetime Supporter
Global Mod
Joined
Jan 24, 2009
Messages
24,710
Reaction score
2,872
Location
Glennville, GA
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.
 

H_Rocket

Death by Powerpoint
Joined
Jan 18, 2009
Messages
3,785
Reaction score
206
Location
North Central Texas
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:

Kelly

Usually remembers to get the pointy end up
Joined
Apr 26, 2010
Messages
199
Reaction score
102
Location
Oregon
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.
 

Scott Hala

Well-Known Member
TRF Supporter
Joined
May 6, 2019
Messages
170
Reaction score
68
Location
Huber Heights, Ohio
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
 

cerving

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
3,589
Reaction score
831
I still favor e-cards, but how about we stop being afraid of a piece of paper??? Recently from the CDC:

^^^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.
 

DAllen

Well-Known Member
Joined
Jan 18, 2009
Messages
4,744
Reaction score
686

(Waits for the inevitable “OMG ITS FOX NEWS THAT CANT POSSIBLY BE RELIABLE” nonsense.)
 

cwbullet

Obsessed with Rocketry
Staff member
Administrator
TRF Lifetime Supporter
Global Mod
Joined
Jan 24, 2009
Messages
24,710
Reaction score
2,872
Location
Glennville, GA
I still favor e-cards, but how about we stop being afraid of a piece of paper??? Recently from the CDC:

I have been saying this for weeks, but I think you are misreading the actual data behind this news article. Less likely is not does not spread via surfaces.

Let's focus on the topic which is ELECTRONIC FLIGHT CARDS.
 

John Kemker

Well-Known Member
TRF Supporter
Joined
Aug 25, 2019
Messages
1,222
Reaction score
495
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

John Kemker

Well-Known Member
TRF Supporter
Joined
Aug 25, 2019
Messages
1,222
Reaction score
495
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.
 

msjohnso

Active Member
Joined
Apr 6, 2009
Messages
33
Reaction score
7
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!
 

John Kemker

Well-Known Member
TRF Supporter
Joined
Aug 25, 2019
Messages
1,222
Reaction score
495
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".
 

cwbullet

Obsessed with Rocketry
Staff member
Administrator
TRF Lifetime Supporter
Global Mod
Joined
Jan 24, 2009
Messages
24,710
Reaction score
2,872
Location
Glennville, GA
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.
 

Greg Furtman

Well-Known Member
TRF Supporter
Joined
Nov 10, 2018
Messages
1,035
Reaction score
486
Location
Webster, Wisconsin
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?
 
2
Top