- Joined
- Feb 3, 2012
- Messages
- 6,339
- Reaction score
- 5,537
Nope, just one Quantum and Project X in the BT50... running off the same compact 350 mAH 2S LiPo. Probably about 2-3 oz, which is a lot for an Estes Mongoose.
Nope, just one Quantum and Project X in the BT50... running off the same compact 350 mAH 2S LiPo. Probably about 2-3 oz, which is a lot for an Estes Mongoose.
Nope, just one Quantum and Project X in the BT50... running off the same compact 350 mAH 2S LiPo. Probably about 2-3 oz, which is a lot for an Estes Mongoose.
Back in post #109, you mentioned 2 Quantums. That must have been the other flight.
On the subject of two quantums, I'm going to be using two of them in my forthcoming frenzy xl and I'm wondering if any of the following things are currently or might in the future be possible:Yes, that was the G-F flight, on a rocket based on an Estes STM012. $7 each from Estes' web site right now... added basswood fins and 29mm mount for the bottom stage.
On the subject of two quantums, I'm going to be using two of them in my forthcoming frenzy xl and I'm wondering if any of the following things are currently or might in the future be possible:
1) Change the name of the wifi network. It'd be great if I could name one "rocketsam2016 frenzy primary" and the other "rocketsam2016 frenzy secondary" such that the wifi network name would be that and/or that would be displayed prominently at the top of the status pages.
2) I need physical switches if I ever want to fly this L3 under NAR (tell me if I'm wrong!), so once I'm doing that it might be fun as well to wire in some status LEDs that would indicate Off/On/Armed. Is there any easy way to hook that up to the current board? This would just be for fun - the beeping is enough to tell me they are armed and I'm assuming I'll be able to easily tell that both are beeping.
Yup I know they have unique identifiers and I'll have them written on my checklist, but nonetheless it'd be a very convenient ability and would reduce the risk of mistakes when using two in a single rocket (for example if the secondary charges are larger, it would be sub optimal to get the quantums mixed up and accidentally have the secondary charge fire first).Each WiFi unit has its own unique identifier when you get it. You don't have to do a thing except bench test so you are assured which one is which. Here is where a checklist is helpful with the ID numbers written down so one can keep track. You'll be able to pull this off easily. If your device allows you to "rename" network wifi links, you'll have that option but frankly, I don't bother.
Agreed that no switches would be nice, but AFAIK they are required for an L3 flight for NAR. You're right that the other benefit is battery life - in my case I've decided I just want to use a single battery size across my rockets so I'm using a 2s 460mah lipo since one of my rockets is space constrained. That way my batteries are all interchangeable which is pretty convenient, but the downside is it won't last for hours and hours with a quantum.Personally based on the design that Cris Cerving espouses, switches are unneeded and superfluous. I hope he can convince the "Ivory Tower Boys" or the
"Powers that Be" they are absolutely not necessary for safety's sake. The "only" reason to use them would be if one is pressed on space and hence battery capacity.
In that situation, a long wait after prepping or sitting on the pad could compromise the flight. If faced with that prospect, a physical switch would allow one to activate their electronics at the "last minute" to conserve the batteries for flight. A switch is another point of failure
in an electrical circuit
Me? I always look at extra battery capacity as "useful" weight especially if needed for CG purposes or if one is trying to fly a "big" motor and keep under a waiver
limitation. It's nice to have if one has the room.
I flew an EggTimer TRS and the rocket had like a 45 minute wait on the pad. I used a single 2s Lithium to run the cpu, the pyro circuits and it was 1300mah
capacity. Had plenty of juice for the flight by the time it was launched so I was unfazed and the flight was successful.
Kurt
On the subject of two quantums, I'm going to be using two of them in my forthcoming frenzy xl and I'm wondering if any of the following things are currently or might in the future be possible:
1) Change the name of the wifi network. It'd be great if I could name one "rocketsam2016 frenzy primary" and the other "rocketsam2016 frenzy secondary" such that the wifi network name would be that and/or that would be displayed prominently at the top of the status pages.
2) I need physical switches if I ever want to fly this L3 under NAR (tell me if I'm wrong!), so once I'm doing that it might be fun as well to wire in some status LEDs that would indicate Off/On/Armed. Is there any easy way to hook that up to the current board? This would just be for fun - the beeping is enough to tell me they are armed and I'm assuming I'll be able to easily tell that both are beeping.
Good to know! Sounds like this should be a pretty safe mod then on the new boards? I may or may not do it we'll see. If I wanted to show that the quantum was on/off, would the best thing to do be to have a resistor + LED across the battery inputs and would that be pretty safe given a large enough resistor?I looked at customizing the SSID early on (actually, when I did the WiFi Switch...), the problem is that 1) you can only have 15 characters (not a terrible limitation) and 2) They have to be unique somehow. The uniqueness is a kicker... how do you guarantee that two people won't set "my rocket" as their SSID? The current firmware does it by adding the non-OUI part of the MAC address to a shorter name ("Quantum_"). Of course, that's no different than your home WiFi... if your neighbor has their router set to the default and it's something like "charter wifi" you might find that there are 10 of them just like that in an apartment complex. The only differentiator is the signal strength (which is hopefully strongest in your unit), and the passkey (which is hopefully unique somehow).
Since the passkey on a Quantum (or WiFi Switch) is fixed and derived from the MAC, this may not be a real problem... you would be able to see the "other" device with the same SSID, but you wouldn't be able to connect to it. That should prevent them from arming your Quantum, and vice versa. I'll look at adding this feature in a future build, but it's not likely to be in the initial airstart version.
Yes, NAR wants a physical switch on the deployment igniters on a L3 project. TRA is a bit more lenient, they only require that it's disabled. For an "armed" indicator, you could wire a LED with an appropriate dropping resistor in parallel with the buzzer, when it goes into the "ready for flight" mode you'll see it blink once per second. I recommend that you only do this with the newer A12f boards; the older one has the buzzer driven directly from the WiFi processor, and there isn't enough current to drive both the buzzer and a LED. The A12f board has an additional FET to drive the buzzer, there's plenty of extra current capacity.
Yup I know they have unique identifiers and I'll have them written on my checklist, but nonetheless it'd be a very convenient ability and would reduce the risk of mistakes when using two in a single rocket (for example if the secondary charges are larger, it would be sub optimal to get the quantums mixed up and accidentally have the secondary charge fire first).
Agreed that no switches would be nice, but AFAIK they are required for an L3 flight for NAR. You're right that the other benefit is battery life - in my case I've decided I just want to use a single battery size across my rockets so I'm using a 2s 460mah lipo since one of my rockets is space constrained. That way my batteries are all interchangeable which is pretty convenient, but the downside is it won't last for hours and hours with a quantum.
But my question remains: is there an easy way to hook up leds for off/on/armed for fun?
I looked at customizing the SSID early on (actually, when I did the WiFi Switch...), the problem is that 1) you can only have 15 characters (not a terrible limitation) and 2) They have to be unique somehow. The uniqueness is a kicker... how do you guarantee that two people won't set "my rocket" as their SSID? The current firmware does it by adding the non-OUI part of the MAC address to a shorter name ("Quantum_"). Of course, that's no different than your home WiFi... if your neighbor has their router set to the default and it's something like "charter wifi" you might find that there are 10 of them just like that in an apartment complex. The only differentiator is the signal strength (which is hopefully strongest in your unit), and the passkey (which is hopefully unique somehow).
Since the passkey on a Quantum (or WiFi Switch) is fixed and derived from the MAC, this may not be a real problem... you would be able to see the "other" device with the same SSID, but you wouldn't be able to connect to it. That should prevent them from arming your Quantum, and vice versa. I'll look at adding this feature in a future build, but it's not likely to be in the initial airstart version.
Yes, NAR wants a physical switch on the deployment igniters on a L3 project. TRA is a bit more lenient, they only require that it's disabled. For an "armed" indicator, you could wire a LED with an appropriate dropping resistor in parallel with the buzzer, when it goes into the "ready for flight" mode you'll see it blink once per second. I recommend that you only do this with the newer A12f boards; the older one has the buzzer driven directly from the WiFi processor, and there isn't enough current to drive both the buzzer and a LED. The A12f board has an additional FET to drive the buzzer, there's plenty of extra current capacity.
NAR requires that ematches are disconnected physically, or that the controller is powered off (i.e. disconnected from the battery).
The problem that I see is that if you have some kind of device (timer or altimeter) using a FET and the FET gets blown, it's going to fire as soon as you apply power, presumably with some kind of switch mounted on the side of the rocket, so your face and/or hands are right next to the rocket. That's not true with the Quantum, even if you blow the FET; the BJT transistor would have to turn on too, and that's not gonna happen until something tells it to. The "something" would be the processor, after you're armed and in the air.
I don't know how often this kind of thing happens, I personally haven't see it but I've heard anecdotal tales of it.
Now I'm confused. Cris - I interpreted your response as saying that it is sufficient to have the altimeter physically disconnected from the battery by a switch. If so, the Quantum is still safe when you throw the switch since it has the BJT transistor.O.k., that means an on/off switch for each "conventional" deployment device is necessary with NAR then to shut off the controllers. Like I said in the past, they required switches on the ematches themselves. Take a look in some of the older magazines of
cert attempts and you can see stuff like six switches or 6 jack and plug arrangements. Fortunately when getting into the L3 range, the rockets are large enough to accommodate whatever hardware one has to throw at them. Kurt
The problem that I see is that if you have some kind of device (timer or altimeter) using a FET and the FET gets blown,
I recommend doing the continuity tests at work worktable BEFORE you put the powder in the charge wells. If you're going to have a problem, it's going to show up then. I have yet to see a scenario (short of a soldering problem that would show up before you ever got to that point) that would cause a Quantum to fire a channel without arming.
If you disconnect the battery, it's 100% safe... no juice to fire the igniter. That's the way the NAR thinks, and it's hard to argue with.
The Quantum is different than other altimeters because there are two electrical paths required to activate a deployment device... the FET and the BJT. The FET is basically an electronic switch on the deployment power, the BJT's (one for each channel) controls the firing. There is much less chance of having any kind of accidental firing than you would have with a device with only a single path. If for some reason you fry something, the other path is there to prevent it from triggering accidentally.
FET's have a habit of failing short-circuited when overloaded. If a FET switch fails that way, it's essentially always on. BJT's fail open when blown... they're always off. From a pad safety point of view, it's safer to have an open-circuit failure than a closed-circuit failure. All Eggtimer Rocketry altimeters use BJT's in their deployment circuitry, for that reason. Most other altimeters use FET's. FET's for a given size will handle more current and don't create as much heat, because they're a near-zero resistance device, whereas BJT's are basically a variable resistor as far as the load is concerned. Everything in electronics design is a trade-off... in this case, I chose a "safer" route vs the more established convention.
There are advantages to a physical switch with the quantum:
1) it let's you set things up ahead of time without the battery draining. You prepare the avbay the night before, flip the switch(es) at the launch site sometime before the launch, and then arm as usual on the pad. Depending on the rocket, this can be a nice time savings when you have an AVBay that is prepared ahead of time (except for charges) and doesn't need to be opened on site.
2) It let's you cut power without opening the av bay after the flight to save the batteries, stop the post-flight beeping and/or reset for a new flight
3) If using a pair of quantums for redundancy, an external pair of switches makes it easy to be sure you are connected to the right one with configuring flight settings.
You still get most of the benefits of the quantum - a visual and outside-the-rocket view of the settings, continuity and arming status, as well as the ability to arm the electronics while stepped back a few feet or more and do safe remote ground testing. I'm building my current rocket with switches so that it can be used for an L3 NAR cert, but these benefits mean I'll probably still use physical switches with quantums in future builds as well.
If you disconnect the battery, it's 100% safe... no juice to fire the igniter. That's the way the NAR thinks, and it's hard to argue with.
The Quantum is different than other altimeters because there are two electrical paths required to activate a deployment device... the FET and the BJT. The FET is basically an electronic switch on the deployment power, the BJT's (one for each channel) controls the firing. There is much less chance of having any kind of accidental firing than you would have with a device with only a single path. If for some reason you fry something, the other path is there to prevent it from triggering accidentally.
FET's have a habit of failing short-circuited when overloaded. If a FET switch fails that way, it's essentially always on. BJT's fail open when blown... they're always off. From a pad safety point of view, it's safer to have an open-circuit failure than a closed-circuit failure. All Eggtimer Rocketry altimeters use BJT's in their deployment circuitry, for that reason. Most other altimeters use FET's. FET's for a given size will handle more current and don't create as much heat, because they're a near-zero resistance device, whereas BJT's are basically a variable resistor as far as the load is concerned. Everything in electronics design is a trade-off... in this case, I chose a "safer" route vs the more established convention.
You can easily put a switch on the deployment channel power, if you're using the single-battery configuration you just run it between the two "jumper" pads. That way you can check it on your table without the powder, turn it off, put in your powder, and you don't have to touch it until you get to the pad. This also applies to the TRS, too.
Enter your email address to join: