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


Page 3 of 3 FirstFirst 1 2 3
Results 61 to 68 of 68
  1. #61
    Join Date
    10th July 2007
    Location
    Melbourne, Australia
    Posts
    1,468
    Another possibility other than cranking up to a bigger processor is to split your processing using more than one arduino and allocate specific tasks to other "intelligent" modules. A simple command and communications interface (serial) between the two can have them cooperating nicely. That's how I design my spectrometers. Interestingly they use ATMega328P devices too ☺.

    TRA 13430, Level 3

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

  2. #62
    Join Date
    31st July 2014
    Location
    Idaho
    Posts
    191
    I don't know how much free RAM you have left but I'd try to make a 3 second circular buffer. When a launch is detected start saving the data at the top of the buffer. That way you don't waste any EEPROM but have all the data from prior to launch. Just remember to wait 4 or 5 seconds after landing to stop recording so all the buffered data is saved. Of course this assumes that you can write to EEPROM faster than new data is coming in. Just a thought.

    Quote Originally Posted by AllDigital View Post
    Thanks all for the feedback. It sounds like my launch detect threshold is too low, but unlike a basic DD altimeter, I am trying to capture as much data and telemetry as possible, so I don't want to miss logging the first few seconds of the launch. When the rocket is sitting on the pad for 45 minutes waiting I don't want to be logging data to an SD card at the same resolution as logging during launch (<100ms). I think a hybrid option would be to activate high resolution data logging at the lower accelerometer or "10 foot" trigger threshold, but abort logging if I don't get a real confirmation (much higher accelerometer and barometer readings) within a few seconds. I'll need to play with that logic to get the benefit of early logging without the false positive for launch detect. For now, I'll use both sensors at the bottom and top, until I can characterize some real life data.


  3. #63
    Join Date
    3rd February 2012
    Location
    So Cal (ROC, TRASD, SCRA)
    Posts
    2,672
    Quote Originally Posted by W7AMI View Post
    I don't know how much free RAM you have left but I'd try to make a 3 second circular buffer. When a launch is detected start saving the data at the top of the buffer. That way you don't waste any EEPROM but have all the data from prior to launch. Just remember to wait 4 or 5 seconds after landing to stop recording so all the buffered data is saved. Of course this assumes that you can write to EEPROM faster than new data is coming in. Just a thought.
    The Eggtimer altimeters do that, the newer ones use the whole amount of allotted EEPROM in a circular buffer so they can go back arbitrarily from the launch detect to a few seconds prior to launch. Since EEPROM's have a finite number of write cycles, you want to minimize writes if you can, and using a larger EEPROM footprint does that. As far as speed of EEPROM, when you're done with the write you have to wait about 3-5 ms. At 100 samples/sec that can be significant... if you're concerned about write speed then you should think about using a buffer SRAM or FRAM ahead of your EEPROM. Ditto for flash memory... but even more so.

  4. #64
    Join Date
    14th June 2013
    Location
    SoCal
    Posts
    96
    Quote Originally Posted by OverTheTop View Post
    Another possibility other than cranking up to a bigger processor is to split your processing using more than one arduino and allocate specific tasks to other "intelligent" modules. A simple command and communications interface (serial) between the two can have them cooperating nicely. That's how I design my spectrometers. Interestingly they use ATMega328P devices too ☺.
    I had planned to do this on the rocket side, but so far I'm not processor constrained. On the base station I am doing this for the "talking telemetry" capability, so that verbal speaking of telemetry doesn't pause radio reception or incoming data. For the talking telemetry I am using a small Arduino nano with a SD/MP3 module and I'm passing commands/telemetry to it using a serial connection. I can pass serial commands and be done in about 2ms. On the rocket, most of my modules (GPS, Radio, MPU, SD Card, etc) have strong processing and buffering capability, so very little CPU gets tied up.

    The 3-4 second looping buffer before launch makes a lot of sense. I can probably fit it in memory (RAM), as my samples will probably be less than 20 times a second. My design has all the telemetry data streaming to an SD card and not to an EPROM, giving me almost unlimited capacity, so I would need to figure out how to dump the 3-4 seconds onto the card at launch and/or maybe wait for descent to spend time writing it out, so I don't miss the "good stuff" immediately following launch. Another option would be to use the EPROM or RAM on the way up and then write to SD on the way down. If I keep a file open on the SD Card I can write a line of data at a rate of 1ms - that is pretty fast, but 3-4 seconds will give me 60-80 lines to write. I am also not sure how the SD card is going to perform under very high G forces -- another reason to use EPROMs on the way up.
    Mike
    NAR L3 #96060
    Tripoli L3 #17739

  5. #65
    Join Date
    14th June 2013
    Location
    SoCal
    Posts
    96

    Sledding in the Spring

    A quick progress report. I designed a custom 3D printed sled to get all the hardware to fit in a 3" rocket for testing. I was about 4mm shy of getting it to all stack in a 4" x 3" round package, but I ultimately had to stack the radio below the CPU and battery, resulting in a 6.5" sled package. With more work and a different battery I'm sure I could get it down to 4".

    In the rocket sled I've got the high power serial radio, a 1200mah 7.2 Lipo battery, an Arduino Mega, a voltage buck converter (to step down voltage to radio and filter radio noise), a barometer, an MPU9250 Accelerometer, Gyro, Magnetometer, a piezo siren, voltage sensor, fore/aft separation sensors, SD card, and a Ublox NEO M8 GPS.

    That is a lot of component hardware. It weighs in at 10.4 oz. The only thing missing is the antenna (going external).

    I've got all the basic code loaded on the package and the logic laid out. Now I need to refine the code, integrate with the base station, and do some more ground testing.

    Click image for larger version. 

Name:	IMG_6701.jpg 
Views:	30 
Size:	233.7 KB 
ID:	344123 Click image for larger version. 

Name:	IMG_6700.jpg 
Views:	28 
Size:	96.1 KB 
ID:	344124 Click image for larger version. 

Name:	IMG_6699.jpg 
Views:	32 
Size:	109.8 KB 
ID:	344125


    Click image for larger version. 

Name:	IMG_6697.jpg 
Views:	25 
Size:	106.1 KB 
ID:	344126 Click image for larger version. 

Name:	IMG_6696.jpg 
Views:	26 
Size:	149.9 KB 
ID:	344127
    Mike
    NAR L3 #96060
    Tripoli L3 #17739

  6. #66
    Join Date
    8th February 2009
    Location
    O'Fallon, IL
    Posts
    112
    Quote Originally Posted by AllDigital View Post
    I am also not sure how the SD card is going to perform under very high G forces...
    The SD card should be fine. I've tested mine at 30G's without any issues, logging data at 800 samples per second from multiples sensors.

    I was reading through this thread again and am definitely concerned with your apogee detection logic. Nearly all of my rockets rotate well past 20 degrees before apogee. Some combination of barometric and integrated vertical velocity would be a better choice.

    As for the preflight data logging issue, I simply start logging to the SD card when the accelerometer reads more than 2.5Gs. Sure, I miss a few samples, but its only 0.02 seconds of data, probably less. If the 2.5Gs isn't sustained for more than 0.3 seconds (user configurable), then the flight computer resets itself, ensuring that an accidental bump or drop at the pad doesn't set everything off.

    Your avionics sled and setup are impressive. I'm definitely jealous. Mine look like a tangled mess of connection wires and breakout boards.

    Good luck!
    Last edited by SparkyVTFlyer; 14th May 2018 at 04:22 PM. Reason: correction
    Sparky

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

  7. #67
    Join Date
    14th June 2013
    Location
    SoCal
    Posts
    96
    Thanks Sparky. For now, I'm keeping it simple and will use similar logic for detecting and logging the launch. I get 4 samples of >2g about 30ms apart, but it is all configurable. Since I am not using this for ejection right now, I am doing a bunch of logging around tilt, speed, 3-way acceleration, and pressure (altitude), once I get a number of launches under my belt I'll try and fine tune the best combination to detect apogee. As a simple starting logic I'm using tilt > 70 degrees -or- 3 consecutive altitude drops of 10'.

    I am going to do a bunch of backyard "drone launches" with the rig lifted 400' up and down with a drone. Like a super slow motion launch, just to shake out any final bugs in the logging or radio telemetry. I was set to do this on Saturday, but I started to get a lot of odd false launch positives from my MPU while bench testing for long periods of time. When waiting still for launch, I would get a random value of >16g or some burst of random values up or down. I am using the Digital Motion Processor from my MPU6050 (MPU9250), so it was odd to see crazy values from out of nowhere. After 3-4 hours of troubleshooting the MPU, calibrating, and double-checking the quaternion functions I realized my issues were not code related. At first I suspected a memory leak (Arduino freak out when they run out of memory), but then I figured out it was time and heat related. I think I solved the source/cause of the overheating Arduino, so now I am back to constructing some tests.

    Mike
    Mike
    NAR L3 #96060
    Tripoli L3 #17739

  8. #68
    Join Date
    14th June 2013
    Location
    SoCal
    Posts
    96
    This week I continued to get a lot of odd readings on the accelerometer / gyro (MPU9250). I originally suspected overheating, since I was really taxing my Arduino regulator, but moving components to other power sources didn't completely solve the issue. I got a good lesson in level shifting this week. Anyone doing serious Arduino work should make sure they understand which components communicate on what voltage level. Each Arduino uses different pin/communication voltages. The Mega2560 is generally using 5V for communicating, but most I2C (SDA/SCL) components are 3.3V chips. I have a I2C Barometer, but it has a level shifter built in, so it is 100% compatible. The same goes for my SD Card. My MPU9250 is 3.3V with no shifter, so driving it with 5V is problematic. I needed a level shifter on the communication lines. I also did a full review of the components and realized my GPS and Radio both needed level shifters on the TX/RX lines, since they are 3.3V and the Arduino is 5V. Both of those seemed to work OK, but I suspect the 5V would eventually wear them out and/or the lower incoming voltage could result in dropped serial packets. Now things seem to be rock solid...at least, on the bench.

    Mike
    NAR L3 #96060
    Tripoli L3 #17739

Similar Threads

  1. Arduino-based altimeter, GPS, telemetry, and possibly guidance
    By zortness in forum Rocketry Electronics and Software
    Replies: 45
    Last Post: 1st December 2015, 07:49 PM
  2. AltiRocket - Arduino based rocket telemetry unit
    By Winston in forum Rocketry Electronics and Software
    Replies: 3
    Last Post: 11th May 2015, 01:01 PM
  3. Motor test stand Arduino based
    By bdureau in forum Rocketry Electronics and Software
    Replies: 9
    Last Post: 10th June 2014, 10:02 PM
  4. Parts for Arduino based Oven
    By blackbrandt in forum The Watering Hole
    Replies: 20
    Last Post: 27th February 2014, 04:32 PM
  5. Radio Talk Show and Model Rocketry
    By tquigg in forum The Watering Hole
    Replies: 2
    Last Post: 4th April 2007, 09:36 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
  •