LithosphereRocketry
Pining for the Fjords
- Joined
- Feb 19, 2017
- Messages
- 882
- Reaction score
- 93
Aaaand PCBs and parts ordered. Should be here in a few weeks.
The EEPROM thing combined with my current setup was kinda what I was thinking, and I'd love to be able to use the built-in brownout detection. However, I have two questions/concerns-
- It seems I have to modify the Arduino bootloader to enable brownout detection. This isn't something I've done before, and I'd like to avoid it if at all possible. However, if I can make minor modifications and end up with a more reliable altimeter, that would be fine.
- How is a brownout any different from simply disconnecting the power and reconnecting for the next flight? If you have to hit the reset button every time that's really no better than having a separate key.
About electronic deployment- I was under the impression that those under 18 can't do electronic deployment, going by this bit of text from the NAR Jr certification page:
If electronic deployment is allowed but the BP has to be purchased by an adult, then I'd love to set up an electronic deployment system to test the ArdIU. However, I would have thought that the NAR would include something about that possibility if it were the case.
Dont read more into the certification requirements than what is written.
Until youre 18 your HPR motors and your BP must be purchased and handled by an adult, but that doesnt mean you cant fly dual deployment.
Tripoli and NAR handle this a bit differently. Tripoli allows mentored flights within the certification and competence level of the mentor. The TRA mentor is charged to 'ensure that every rocket used in a mentored flight is built with the level of skill necessary for the project'. If you can build it and demonstrate to your competent & qualified mentor (who should be monitoring the build, much like a TAP monitors a level 3 project), your mentor can allow you to fly it.
NAR's web page states as of their 2009 rules revision:
- "Qualifying junior members at this level permits them to fly single or multiple motor rocket flights with motors having a maximum total impulse of 640.00 Newton seconds.
The qualification flight and all future flights must be single deployment only. This is due to regulatory requirements of ejection charges used in dual deployment systems. On board electronic devices are permitted as long as they are not used for deployment.
As models with hybrid motors require regulated ejection methods, they are not permitted to be used by the Junior HPR Level 1 Participant at this time"
Please correct me if there is a more recent revision to the NAR program.
You are correct. The NAR Jr. L1 program specifically prohibits a Jr. L1 flyer from flying dual deployment during or after certification, until their 18th birthday. I was wrong. [emoji17]
And yes, the Tripoli mentoring program would allow him to fly dual deployment, but he would still have to have an adult prepare the motor and handle the BP.
However, what I can do is have some kind of visual "charge" that doesn't actually do anything functionally- anybody know if a Christmas light is visible at 1000ft?
I sincerely doubt it, especially in daylight, they're often barely visible from tens of feet during the day. But is the rule strictly against BP? I'd wonder if you could set off e-matches even if they didn't have any BP, then you could at least see if the matches fired. But I haven't read any of the rules, just asking questions.
Question: Do the rules regarding BP for Jr. fliers also include BP alternatives like Mr. Nakka's Crimson Powder?
That's an interesting thought- I'd have to read up on that. I do have some nichrome wire somewhere...You could do motor deploy and a hot wire cutter chute release.
For datalogging, which would be more useful by default- CSV or TSV? I can make it configurable, I'd just be interested to know what people prefer.
Binary. You can always mangle it into CSV later if you want.
It is easier and faster for the micro-controller to deal with. One big problem with using an SD card is that there can be long delays while writing a sector. (The SD card specification says up to 750ms!) If you don't want to lose data you must be able to buffer that much data. Since RAM is at a premium in most micro-controllers, using an ASCII format is going to make this problem worse. You have 2K of RAM so at best you have space for three 512B buffers. Which limits you to 1.5KB/750ms = 2KB/sec. I figure that gives you about 32SPS with an ASCII format while binary would be around 4 times that.
This assumes that you know how to write code for the Arduino that can gather/process data while the data write to the SD card is in progress. If you don't, then you are going to lose data no matter how much buffer space you use.
Even skipping a file system like I do doesn't completely eliminate the delays although it does reduce them.
I might be interested in a Beta board. What kind of time frame for feedback are you considering? And how often?
Floats are 4 bytes.
A long int (4 bytes) has more than enough precision for most of your data.
C data widths are adjustable based on the device and OS. On Arduino "standard precision" is only 2 bytes, "long" is 4. On most "normal" devices standard is 4 bytes, long is 8- Arduino uses less because of the low specs of the chip.
I think floats make the most sense in terms of accuracy- the accuracy drops at high altitudes, where you don't care as much anyway. An (unsigned) int would wrap at 65km, a reasonable range for some extreme projects, but nobody's gonna break the upper bound for a float- 4 billion meters, well into interplanetary space.
"int" defaults to 16 bits, "long" to 32. I agree. (if portability is a concern and type widths matter, I like to use the types in stdint.h: int16_t, int32_t, etc.) "float" is 32 bits. You're right, now that I look... I assumed everything would follow the same width standards... Apparently not. Depending on write speed constraints I can either widen the sample size or use a short float. Double is usually 64 bits but I haven't seen an Arduino implementation that supports that. (MAXFLOAT (see math.h) is much greater than 4E9, more like 3.4E38). I was going by the 5 bit exponent for a "short" float. Now that I actually read the **** manual (i.e. Arduino reference) I see that a float is the same length as a long...
And there is not much reason to record anything other than the raw sensor data. Let your fancy Intel/AMD processor do the conversion to engineering units later.
Even if the altimeter is controlling deployment there is rarely any reason to convert from the raw sensor value. They only one I can think of is when using a Kalman filter and you must have altitude and acceleration in compatible units.
Fair point- however, I'd be concerned about loss of precision across various widths, especially with things that integrate and therefore are subject to huge errors from tiny imperfections. Additionally, the MPU-6050 has support for on-chip data processing, which runs MUCH faster and more accurately than any other option.
C data widths are adjustable based on the device and OS. On Arduino "standard precision" is only 2 bytes, "long" is 4. On most "normal" devices standard is 4 bytes, long is 8- Arduino uses less because of the low specs of the chip..
However, UhClem is right, you do not need to use floating point in an altimeter, especially one that is using an 8-bit processor. You can do everything you need with fixed point integer math. It will run alot faster too and use much less program memory.
Personally I would stick with the floats if you have the processing power during flight.
Yes, my processor is slow as ****- and I had to drop to 8MHz to run at 3.3V, so it's even slower- but all the integrating is being done onboard by the IMU itself. It's not a well documented feature but the library I use supports it. (Thx Jeff Rowberg!)I would agree that if you have an ARM or similar you can trade off bloated code and clock cycles for an easier program.
But the OP is using an AT328P which is an 8 bit processor and 32kb of code space. I am guessing that the quaternion multiplies and normalization for the IMU functions is going to use ALOT of clock cycles and code space using the GNU floating point library on an 8-bit machine. It may be hard to fit all the other desired altimeter functions in there. Also he programming in the Arduino library not native, there is some extra overhead there.
Yes, my processor is slow as ****- and I had to drop to 8MHz to run at 3.3V, so it's even slower- but all the integrating is being done onboard by the IMU itself. It's not a well documented feature but the library I use supports it. (Thx Jeff Rowberg!)
Sent from my LGL44VL using Tapatalk
Enter your email address to join: