Help Support RocketryForum by donating using the link above or becoming a Supporting Member.


Page 3 of 6 FirstFirst 1 2 3 4 5 6 LastLast
Results 61 to 90 of 151
  1. #61
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Aaaand PCBs and parts ordered. Should be here in a few weeks.

    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  2. #62
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Never mind about a few weeks, OSH Park upgraded me to the fast panel for free because they had a few square inches of space free... That panel ships within 5 business days.

    However, I won't be able to do much assembling as of yet, as the electronic parts are still on the way from China... So I'll have something in a week or 2 but no assembling will happen for a bit after that.

    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  3. #63
    Join Date
    23rd July 2011
    Location
    Butte, MT
    Posts
    2,720

    ArdIU - Open source flight computer w/ ATMega328

    Quote Originally Posted by LithosphereRocketry View Post
    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.
    Donít read more into the certification requirements than what is written.
    Until youíre 18 your HPR motors and your BP must be purchased and handled by an adult, but that doesnít mean you canít fly dual deployment.
    Steve Shannon
    L3CC, TAP, Director, Tripoli Rocketry Association

  4. #64
    Join Date
    29th December 2013
    Location
    Bayport MN
    Posts
    169
    Quote Originally Posted by Steve Shannon View Post
    Donít read more into the certification requirements than what is written.
    Until youíre 18 your HPR motors and your BP must be purchased and handled by an adult, but that doesnít mean you canít 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.
    L1 - Madcow 4" Phoenix I180 Skidmark 1651 feet
    L2 - Darkstar 2.6" J145 Skidmark longburn 4787 feet
    L3 - Terminator 5" M1297 White Lightning 8602 feet

    TRA 15743
    NAR 30949
    http://www.rocketreviews.com/karl-tyrrells-page.html

  5. #65
    Join Date
    23rd July 2011
    Location
    Butte, MT
    Posts
    2,720
    Quote Originally Posted by Thorfire View Post
    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.
    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.
    Steve Shannon
    L3CC, TAP, Director, Tripoli Rocketry Association

  6. #66
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by Steve Shannon View Post
    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.
    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.
    OK, that's what I thought. Guess I won't be testing DD capabilities after all.

    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?

    This also brings up an interesting point. I'm planning on testing with staging to get around the "no BP" rule, and many clubs require a tilt lockout when possible (not mine AFAIK, so this is just a thought experiment.) The ArdIU can do tilt lockout with its MPU6050 IMU, however, if the motor locks out, I don't get an ejection charge. So which is preferable- the upper stage igniting off center and traveling for miles, or not igniting at all and lawn darting? I would assume any parachute is better than none, but I'd be interested to see what people think.
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  7. #67
    Join Date
    9th October 2013
    Location
    San Jose, CA
    Posts
    697
    Quote Originally Posted by LithosphereRocketry View Post
    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.
    Will Ferry (Launches & Videos) NAR #96512 (L2) / TRA #15328 (L2) / LUNAR #2759
    L1: 9/2013 @ XPRS, GLR T-Bolt "Thunderbolt" (R.I.P.), H148R
    L2: 4/2016 @ TCC Helm, Binder Design Excel w/DD "dd2.xls", J315R
    Impulse flown (flights): 2013: 767Ns (2), 2014: 4298Ns (8), 2015: 7486Ns (16), 2016: 11693Ns (18), 2017: 11138Ns (16), 2018: 3879Ns (5)

  8. #68
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by woferry View Post
    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.
    I think the regulation is because BP has to be handled by adults, so an ematch taped to the side or something would be OK- not sure though. Here's an interesting idea- many reload manufacturers are OK with people putting foreign objects in their BP wells. So can I legally use the BP well on a reload as a charge well as a backup- similar to what I've seen people do with 2 matches per charge? The idea would be to drill a hole in the little red cap (or poke a hole in the paper with CTI) and stick an ematch in that, with some kind of breakaway connector to the ArdIU.

    The first step of course would be to just fly it "dry" and record on the SD card when charges "fire".
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  9. #69
    Join Date
    23rd July 2011
    Location
    Butte, MT
    Posts
    2,720
    Just have an adult fly it.


    Steve Shannon
    Steve Shannon
    L3CC, TAP, Director, Tripoli Rocketry Association

  10. #70
    Join Date
    8th October 2016
    Location
    Midwest
    Posts
    319
    Question: Do the rules regarding BP for Jr. fliers also include BP alternatives like Mr. Nakka's Crimson Powder?

  11. #71
    Join Date
    12th September 2013
    Location
    SE Wisconsin
    Posts
    1,178
    You could do motor deploy and a hot wire cutter chute release.
    Charles McGonegal
    Ciderwright at AeppelTreow Winery & Distillery
    www.appletrue.com
    NAR #103560 L1 6/25/17 Estes Leviathan CTI H175-SS
    Ad Astra Tabernamque!

  12. #72
    Join Date
    23rd July 2011
    Location
    Butte, MT
    Posts
    2,720
    Quote Originally Posted by Tobor View Post
    Question: Do the rules regarding BP for Jr. fliers also include BP alternatives like Mr. Nakka's Crimson Powder?
    Not the way they are written. See post 64.
    Steve Shannon
    L3CC, TAP, Director, Tripoli Rocketry Association

  13. #73
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by Charles_McG View Post
    You could do motor deploy and a hot wire cutter chute release.
    That's an interesting thought- I'd have to read up on that. I do have some nichrome wire somewhere...

    Sent from my LGL44VL using Tapatalk
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  14. #74
    Join Date
    12th September 2013
    Location
    SE Wisconsin
    Posts
    1,178
    Here's mine :
    Eggtimer Quark based chute tender

    http://www.rocketryforum.com/showthread.php?t=129976
    Charles McGonegal
    Ciderwright at AeppelTreow Winery & Distillery
    www.appletrue.com
    NAR #103560 L1 6/25/17 Estes Leviathan CTI H175-SS
    Ad Astra Tabernamque!

  15. #75
    Join Date
    12th September 2013
    Location
    SE Wisconsin
    Posts
    1,178
    And another based on a Quantum
    Quantum based hotwire chute release

    http://www.rocketryforum.com/showthread.php?t=141642
    Charles McGonegal
    Ciderwright at AeppelTreow Winery & Distillery
    www.appletrue.com
    NAR #103560 L1 6/25/17 Estes Leviathan CTI H175-SS
    Ad Astra Tabernamque!

  16. #76
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Before I get into deployment of any kind, I need to build an altimeter. Speaking of which, my PCBs came in the mail today. Very nice quality, I'll post pics soon.

    Now to wait another week or two for the rest of the parts...

    Sent from my LGL44VL using Tapatalk
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  17. #77
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    So I got the prototype altimeter assembled over the last few days. Came out pretty nice:
    Click image for larger version. 

Name:	0121181347.jpg 
Views:	151 
Size:	114.5 KB 
ID:	336702Click image for larger version. 

Name:	0121181404.jpg 
Views:	150 
Size:	126.7 KB 
ID:	336703

    I first built it without breakout boards and tested it, then added the boards afterward, just in case I needed to fix something.

    My comments:
    - Several footprints were mis-sized, most significantly the SD breakout. I can work around it but it's annoying enough that I'm going to want new footprints for the first beta run.
    - The polarity on the LEDs was very hard to see. I was using Sparkfun's library for these- I'll switch to the Adafruit footprint, which is much clearer, in the future.
    - Most of the info text on the back was practically invisible. Easy fix.
    - The programming header was set up backwards. I can work around it by just flipping the programmer, it's just not ideal.
    - I'm planning on running the entire board at 3.3V with internal clock on the next iteration. I found a high-efficiency version of the 1117 that can run 3.3V off of as little as a 2.5V input, so I can run 1S LiPos- I have quite a few lying around.
    - I'm also planning on moving the SD card from a breakout board to a standalone holder. I just need to find one that's reasonable to solder...
    - Several bugs in the Arduino library have been worked out- mostly related to the annoying way C handles floats- float x = 1/2 will give zero because the 1/2 part is reading as an int. float x = 1.0/2 fixes it. Still have a lot more to go there.

    Two quick polls-

    How much interest is there in a beta run once all of these issues are taken care of? OSH Park sells boards by 3's so I'm planning on getting 6- one for myself and if that goes well 5 beta kits. Beta kit price would probably be around $30-40, and gain you my undying gratitude, your name/handle on the production board, and first pick at debugging help and/or code customization, plus maybe more stuff.

    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.

    Thanks for all the interest!
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  18. #78
    Join Date
    6th February 2010
    Location
    Camarillo, CA
    Posts
    2,258

    ArdIU - Open source flight computer w/ ATMega328

    Congrats on such a cool project! For my arduino data logging payloads, I always use CSV format. Doesnít make a bunch of difference, I use Excel and MatLab for data analysis and both probably wouldnít care TSV vs CSV. I notice to that most other altimeter manufacturers use CSV also.

    You could count me in for getting more info on a beta-run.


    Sent from my iPhone using Rocketry Forum

    Bryce Chanes
    Previous ROC Board Member
    NAR 89467, TRA 13928 L3
    KR0CKT General
    Follow me on: YouTube, Twitter, Google+, Facebook

    2011: 14,773Ns (44% N)
    2012: 38,670Ns (89% O)
    2013: 26,936Ns (32%O)
    2014: 7,392Ns (45%M)

    www.BryceChanes.com

  19. #79
    Join Date
    7th February 2009
    Location
    Arlington, TX
    Posts
    1,272
    Quote Originally Posted by LithosphereRocketry View Post
    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.

  20. #80
    Join Date
    8th October 2016
    Location
    Midwest
    Posts
    319
    I might be interested in a Beta board. What kind of time frame for feedback are you considering? And how often?

  21. #81
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by UhClem View Post
    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.
    Hmm, now that's a thought... What I could do is have it write to a binary file during boost, and then revert to CSV as well during descent, when it doesn't have to sample nearly as often. I'd be planning around a 32B per frame sample width:
    -4B timestamp (unsigned long)
    -2B altitude (unsigned float)
    -6B axial acceleration (3 floats)
    -8B orientation (calculated by the IMU; quaternion- 4 floats)
    -12B spare for other things- e.g. pin states, raw readings, etc.

    I can also change the sizes of the floats for more or less precision as I see fit- for example, the current scheme maintains 1m stored accuracy up to 2km and 32m accuracy well past the Karman line, but switching to double precision would vastly improve that.

    I do want to keep the card in a file-formatted state though for ease of debugging- also, then if you crash and damage your altimeter, you can still recover data relatively easily. I'll have to run some performance tests to see what the delays will look like.

    Quote Originally Posted by Tobor View Post
    I might be interested in a Beta board. What kind of time frame for feedback are you considering? And how often?
    I don't really have any formal plan for feedback at the moment- basically, I want to know how well it works and any improvements you'd suggest. Any feedback is welcome!

    Glad to see there's interest! I'll get working on the beta PCB & library when I have a bit more time.
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  22. #82
    Join Date
    23rd January 2009
    Location
    NE Ohio
    Posts
    2,545
    Floats are 4 bytes.

    A long int (4 bytes) has more than enough precision for most of your data.
    John Derimiggio NAR/TRA L3
    MarsaSystems

  23. #83
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by jderimig View Post
    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.
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  24. #84
    Join Date
    7th February 2009
    Location
    Arlington, TX
    Posts
    1,272
    Quote Originally Posted by LithosphereRocketry View Post
    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. (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. 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).

    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.

  25. #85
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by UhClem View Post
    "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.
    Again, thanks for the help, everyone! I really appreciate all the ideas!

    I will get the beta boards sent to the fab as soon as I can... While they're processing I'll chew away at the Arduino library. So much to do! bandman444, Tobor, I'll try not to keep you waiting too long... It'll be a month or so at minimum though- just printing the PCBs takes around 3 weeks.
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  26. #86
    Join Date
    23rd January 2009
    Location
    NE Ohio
    Posts
    2,545
    Quote Originally Posted by LithosphereRocketry View Post
    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 was just correcting you on the size of floats in the standard Arduino library. Floats are 4 bytes, so are doubles, no difference in precision.

    https://playground.arduino.cc/Code/DatatypePractices

    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.
    John Derimiggio NAR/TRA L3
    MarsaSystems

  27. #87
    Join Date
    10th July 2007
    Location
    Melbourne, Australia
    Posts
    1,468
    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. I have seen people stuff up integer and fixed point integer maths, just because they are not used to it. You can be clever writing code, but if it is not understandable or maintainable then you should probably consider doing it differently. YMMV.

    BTW, I used integer maths to calculate Pi to 10,000 decimal places back in the late 70's, just for fun, when I was a teenager
    TRA 13430, Level 3

    "Everybody's simulation model is guilty until proven innocent" (Thomas H. Lawrence 1994)

  28. #88
    Join Date
    23rd January 2009
    Location
    NE Ohio
    Posts
    2,545
    Quote Originally Posted by OverTheTop View Post
    Personally I would stick with the floats if you have the processing power during flight.
    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.
    John Derimiggio NAR/TRA L3
    MarsaSystems

  29. #89
    Join Date
    19th February 2017
    Location
    The world, probably
    Posts
    711
    Quote Originally Posted by jderimig View Post
    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
    NAR #104043, Jr L1 - 3/18/18
    www.crmrc.org

    Director of Impressive Titles, ArdIU Flight Computer Project:
    lithosphererocketry at gmail dot com

  30. #90
    Join Date
    8th February 2009
    Location
    O'Fallon, IL
    Posts
    112
    Quote Originally Posted by LithosphereRocketry View Post
    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
    Even if you had to do the integration on the AT328P its not impossible. I use the Arduino IDE and can get SD card data logging of gyro/accel/baro, dual-deploy, 2-stage functions, and quaternion tilt-lockout all on the AT328P. That said, I'm using 75% of RAM and 99% of Flash, so it BARELY fits, but it fits.

    Sparky

    NAR #85720, L3
    Tripoli #12111, L3
    2017 Impulse: 86,532 N-s
    2017 Flights: 26

Similar Threads

  1. Open Hardware Flight Computer for sounding rockets
    By mitokondri in forum Rocketry Electronics and Software
    Replies: 0
    Last Post: 4th February 2016, 12:20 AM
  2. [SOLD!] Open source GPS tracker pcb
    By thobin in forum Yard Sale / Wanted
    Replies: 4
    Last Post: 2nd June 2014, 08:50 PM
  3. [For Sale] Open source TX PCB
    By conman13 in forum Yard Sale / Wanted
    Replies: 0
    Last Post: 8th May 2014, 02:30 AM
  4. Help! My computer will not run Open Rocket
    By goose_in_co in forum Rocketry Electronics and Software
    Replies: 18
    Last Post: 20th July 2011, 11:01 PM
  5. Open Source Flight Controller/Altimeter
    By konkers in forum Recovery
    Replies: 37
    Last Post: 12th June 2007, 06:13 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •