Sending again since the first time it didn't go the list. This seems to be one of those lists where hitting "reply" doesn't send the reply to the list.
On 3/15/19 10:11 PM, Bdale Garbee wrote: > "David W. Schultz" <[email protected]> writes: > >> Both NFPA 1122 and 1127 require that launch systems include a removable >> safety interlock in series with the launch switch. TRA uses NFPA 1127 as >> their safety code and NAR requires following the NFPA codes at all NAR >> launches. So this is a problem. > > I wasn't aware that a removable interlock was an explicit requirement. > I just looked and couldn't find the current NFPA text anywhere online. > I'd like to read the actual text... any idea where I can find it? > I see that directions have already been supplied. It still amazes me how many haven't read these. In addition, NFPA 1122 requires removing the safety interlock before approaching the pad after a misfire. Obviously written with the Estes controller in mind. 1127 just requires that the interlock be engaged. The off board drawings do not show how the off board components are wired up. > Sigh... all part of the reason I personally detest key switches. My > observation is that key switches get turned, but the key rarely gets > pulled out in practice. But .. [sigh] .. rules are rules. I like key switches. Perhaps colored by my experience at WSMR. The M270 launcher was modified with a launch inhibit system to prevent the crew from launching. This was controlled by a box with a key switch. During most of the countdown to an ATACMS launch, the cable to the missile igniter wasn't connected to the missile. Before that connection was made the launch inhibit key was sent to the pad. It wasn't returned until the pad was cleared. I bit much for an H powered rocket but there is some threshold where it makes sense. M? And not very compatible with a one controller to rule them all setup. >> Oh, I thought that the FCC prohibited encryption for amateur radio: >> 47 CFR 97.309(b) Has that changed? > > 97.309(b) does not apply because we're not encrypting the content, thus > we are in no way "obscuring the meaning of any communication". What > we're doing is appending a crypto checksum to each packet to > authenticate the link. That's been a common mechanism on amateur radio > control links for a long time. That is some additional detail that I hadn't seen. All I saw was that it used AES encryption. I had never heard of it being used for control links but Google turns up an old Phil Karn paper on the topic. I wonder how I never saw that? But in block chain mode the current checksum will depend on all previous checksums. What happens when a packet gets dropped? How do you prevent someone from recording a valid data packet and resending it? The answers are probably in the code but I see multiple versions of telelco with no idea which to look at. Not that I am fond of reading thinly documented code. -- http://home.earthlink.net/~david.schultz The cheaper the crook, the gaudier the patter. - Sam Spade _______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
