Staging Logic Gates

[UhClem]

In the US, angle lockouts are required by both NAR & TRA for multi-stage flights.

I have never heard of the NAR imposing this requirement. Is this documented anywhere?

 

[UhClem]

I figured out it was the sensor and not the traces when I didn't see the same effect in the IMU. For whatever reason it seems to affect some ADCs and not others. I get the same interference problem when I sample the MCU ADC for the Teensy3.5.

Long ago I read the data sheet for the AD623 instrumentation amplifier which has a nice section on EMI. RF gets into the input and causes trouble. The solution is to keep RF out via some RC input filters.

Impossible to do on a sensor with an integrated ADC of course. All you can do there is enclose the offending part in an EMI shield.

 

[heada]

The Teensy 4.0 is slightly shorter board but with the uSD as pads and not the slider. You could solder the uSD card directly to the board and the vibration becomes much less of a worry.

Since the Teensy 4.1 has multiple I2C buses, could you put a sensor on each bus to eliminate the worry of EMI on a specific I2C bus?

 

[Johnly]

I have never heard of the NAR imposing this requirement. Is this documented anywhere?

The statement I made was incorrect. When this was being considered, there wasn't sufficient technology available to HPR fliers to make it a requirement.
It is currently only a recommendation with the local clubs and launch RSO having the decision to mandate it.

 

[AllDigital]

We flew the staging logic on the booster (without sustainer) yesterday, to 14K feet, to simulate a staging flight. All of the logic worked perfectly, except we did not get the call to fire sustainer ignition. Our launch detect, burnout detect, mach delay, staging armed, stage separation pyro, apogee, drogue pyro, main pyro, and landed detect were exactly as planned. On review of the data and the code, I had a single typo in the conditional for sustainer ignition that the compiler did not catch (ugh!). That is why we test. Other than the typo inhibiting one condition, all the other conditions went true at the right times. So, we'll repeat the same booster-only test in a few weeks.

As a side note, on this flight the motor should have hit burnout around 3.6 seconds. We got notified that it hit burnout in 1.5 seconds on the ground and thought the logic had failed. As it turns out, the motor ran at least 2X hotter (gee's, burn time) than normal due to a bad batch of sugar (investigating) -- luckily the case, components, and airframe could handle the extra pressure, so it was an otherwise normal flight.

 

[profmason]

Nice to see the new version of your board. Good flight yesterday.
0. Thanks for putting this up, this was just what I was asking you in the field.
1. It looks like you have a row of optos on your board. Are you using those for deployment or are there a set of transistors I don't see?
2. I have definitely had SD cards eject/ detach / fail etc. The board I recovered yesterday that did a tumble recovery after skywriting on the N motor had all data on Flash which downloaded without issue. I think there is little cost to run SPIFFS and use your micro to log redundantly to internal flash.
3. Off axis detection / lockout. I have done this by comparing barometric altitude with the integrated accelerometer values with the thought that some large difference means that the rocket is not moving in line with vertical. (at least during boost) and setting a max deviation. I am terrible at getting the second stage to light even if all the signals are good.... Other lockouts are: 1. timer since launch detect, 2. minimum barometric altitude and 3. minimum filtered barometric velocity.
4. I still maintain that there is a 10db advantage of LORA over the standard GFSK modulation schemes. 10db at the expense of 1/10th the bandwidth... 10dB lets me run terrible antennas. I really need to do some of the same tests you did on range, but I know that going to LORA modules vs FSK modules let me run much terrible antennas with better results. https://www.frugalprototype.com/wp-content/uploads/2016/08/an1200.22.pdf

I can't wait to see what you come up with in 2 weeks!

 

[SparkyVT]

For my 32KSPS Teensy 3.6 logger I found that I had just enough time to handle the SPI transfer in an assembly language interrupt service routine.

Thats a LOT of data! I looked at your site and the work you did is pretty great. I'm not at that level, but so far I haven't needed it. I've thought about programming MCUs outside the Arduino environment, but haven't taken that leap. What I have is good enough and anything more gets me diminishing returns for my project.

I really should have used DMA but that looked like a big can of worms best left unopened.

I did a quick search on Teensy DMA, and it seems there is a library for it: https://github.com/crteensy/DmaSpi

If I can get the sensors on my next board to use the SPI bus, then I may try this library out. That would dramatically free up processing time.

 

[UhClem]

If I can get the sensors on my next board to use the SPI bus, then I may try this library out. That would dramatically free up processing time.

One of the little details of the MPU9250 is that you can use a higher SPI clock frequency when accessing the data registers. 20MHz vs. 1MHz. Which really speeds things up.

 

[profmason]

Mike, I saw the graphs your put up of your integrated accelerometer data. Can you put up graphs of your integrated accelerometer altitude, barometric altitude and GPS altitude from the flight you just did, so I can get a sense of how these match up for you? I am seeing excellent agreement between barometric and GPS, but my accelerometer is leading. I am also missing a 5 second chunk when the two fins came off (and am hitting the 16g limit on the accelerometer.

 

[AllDigital]

1. It looks like you have a row of optos on your board. Are you using those for deployment or are there a set of transistors I don't see?

Yes. The optical relays are for the pyros (Omron G3VM-31AR). I've got one for arming/safety, four pyros, and the last one is to switch my camera on/off (overkill for that purpose). These are beefy 4 amp relays. I prefer the optical relays for the extra layer of isolation (vs transistor or mosfet), but I am no electrical engineer (but I did stay in a Holiday Inn last night). I also have a 3.5 amp auto-resetting fuse in-line. My tests of e-matches show MJG's consistently fire under about 1/2 an amp, while the cheap "orangies" take up to 2.5 amps or more. My fear is firing a pyro with a hard short, so I designed and tested to make sure an accidental short on a pyro didn't screw anything else up on the board when it fired.

3. Off axis detection / lockout. I have done this by comparing barometric altitude with the integrated accelerometer values with the thought that some large difference means that the rocket is not moving in line with vertical.

That is a novel idea, but I'm not sure if it would be accurate under different flight profiles. I'd have to do the math or run scenarios. Yesterday, our new quaternion tilt routine worked perfect. We took off the pad at 2 degrees and twenty seconds in we were only at 5 degrees. At apogee we could see the turn over and subsequent tumbles. We could also see perfect spin/roll data on the way up. So, I'm pretty happy with using it as our tilt lock-out.

4. I still maintain that there is a 10db advantage of LORA over the standard GFSK modulation schemes.

Yep. I need to order some Lora radios and run the same tests. I see a lot of advantages.

On the topic of SD data logging... Using the teensy 4.1 (built in SPI SD card) I can log a 64 byte string at 7,751hz with the files kept open and 330 hz if I issue an open/close for each write. That's using a cheap, but "ultra fast" micro SD card. The open/close creates a hard commit, so if things cato there is zero data loss (well... assuming you can recover the card). With files open, you don't have the data committed until you close the file. You can keep them open and close every xx seconds. You can also keep files open and issue a flush() after each write and it is slightly faster than open/close (writes about 400hz). For my needs on rocket telemetry, I never need to log faster than 100hz -- that is still a crazy amount of data to sift through after each flight. My sensors are sampling at 400hz, but I really don't need to log every sample. So, on the Teensy 4.1 I use standard libraries and have no problems logging at 100hz and then doing a dozen other things in parallel. The Teensy 4.1 has an insane amount of CPU power (ARM Cortex-M7). I break my program into three threads (loops) and have sensor sampling on one loop, logging to SD on another, and the radio/GPS/housekeeping on the third and I am still swimming in extra CPU cycles. The real constraint is I/O with that board. I run my sensors on I2C at 400K, SD on the built-in SPI, and GPS and Radio on serial.

On the flight yesterday, the rocket hit 40 gees (not intentionally) and the SD card didn't miss a byte.

@UhClem what were you logging at 32K? motor burns? That is like watching atoms split.

 

[AllDigital]

Mike, I saw the graphs your put up of your integrated accelerometer data. Can you put up graphs of your integrated accelerometer altitude, barometric altitude and GPS altitude from the flight you just did, so I can get a sense of how these match up for you?

The flight yesterday is not the best dataset, as we switched velocity/altitude integration over to the 32G accelerometer and it maxed out in the first 1.5 seconds. Also, due to the very high G's the GPS did not come back online until it dropped 3-4K feet from apogee. that said, below is data from the previous flight. My accelerometer altitude also runs ahead or "hot" from the barometer. Intuitively that makes sense, as the barometer takes longer to sense/adjust, but even with that consideration it does seem like the accelerometer is always "more generous" with altitude. After apogee, the accelerometer data is useless. The GPS and the barometer tend to track very close, but the GPS is only working in "low speed" situations, so the barometer has less lag. I only log the GPS every 5 seconds on the way up and often get an anomalous 2D reading when it regains lock, as in the graph below. You can also see in the graph the "mach dip" in the first few seconds and more lagging and sagging of the barometer during the fastest phase of flight.

 

[profmason]

Thanks for this! The bottom axis of your graph is in ms. That would be consistent with logging gps every 5 seconds. I am going to have to do more work on my integrated altitude and up my logging rates. Thanks for the link to those omron parts, I had been using two components..

 

[SparkyVT]

I prefer the optical relays for the extra layer of isolation (vs transistor or mosfet)

I feared the same thing, especially when I discovered EMI on the barometers, but I haven't had any issues when grounding the MOSFET with a 1K ohm resistor. I wanted to be able to use First-Fire igniters in my upper stages and have had no issues.

I am going to have to do more work on my integrated altitude and up my logging rates.

I'm not sure what unit you use, but the UBLOX chips are nice. They are easily programmable over serial and maintain accuracy even at 4-8 Gs. Above that, and it will take a few seconds to recover, but I almost always get it back before apogee. The M8Q can do 20 updates per second using 3 GNSS systems. The new M9N I think can do 100 updates per second with 4 GNSS systems. Holy Smokes!

Here's a flight from 10 days ago. Plots at the end.

 

[cerving]

The flight yesterday is not the best dataset, as we switched velocity/altitude integration over to the 32G accelerometer and it maxed out in the first 1.5 seconds. Also, due to the very high G's the GPS did not come back online until it dropped 3-4K feet from apogee. that said, below is data from the previous flight. My accelerometer altitude also runs ahead or "hot" from the barometer. Intuitively that makes sense, as the barometer takes longer to sense/adjust, but even with that consideration it does seem like the accelerometer is always "more generous" with altitude. After apogee, the accelerometer data is useless. The GPS and the barometer tend to track very close, but the GPS is only working in "low speed" situations, so the barometer has less lag. I only log the GPS every 5 seconds on the way up and often get an anomalous 2D reading when it regains lock, as in the graph below. You can also see in the graph the "mach dip" in the first few seconds and more lagging and sagging of the barometer during the fastest phase of flight.

View attachment 449823

That graph is very typical of flilghts that are close to mach transition. You can see the baro do a dip and then come back. With a high-G single-axis accelerometer (such as the one in the Eggtimer Proton) you can do decent off-axis check by comparing the two computed altitudes, and if they are sufficiently close then you're probably pointing "up". This works best a few seconds after burnout and in the early coast phase... which is when you generally are going to be lighting a sustainer.

 

[UhClem]

what were you logging at 32K? motor burns? That is like watching atoms split.

My particular interest is launcher interactions. That happens pretty fast and I want as much data as possible during that time. The MPU9250 had the highest data rate on gyros that I could find so that determined the sample rate.

I need to finish up the test vehicle which has photo-transistors at the button locations. Once flying gets back to normal my motivation for that will improve.