Teensy 4.1 Radio Interference Shielding?

Status
Not open for further replies.

TeensyDigital

Well-known member
I've got a T4.1 that I am using as the brains for a flight computer and radio telemetry in an amateur sounding rocket. I ported my project to the T4.1 from an ESP32 about six months ago and I love the extra CPU power and IO, but I am running into a lot of RF interference issues, as the ESP32 was shielded and the T4.1 is not. I haven't needed to do a lot of shielding before, but my past four flights have had a lot of RFI issues, so now I'm going to rebuild my PCB and sled. There is a lot going on in my setup and the package can often be crammed into a very small 3" diameter by 12" avionics bay.

Here is what I've got: A T4.1 logging to onboard SD (SPI) at 100hz. Three sensors on the I2C lines running at 400Hz (a barometer, a 200G accelerometer, and an IMU/gyro). I've got a GPS connected by serial pins and I'm using a 2 watt 433mhz radio for bi-directional radio transmission, using the second serial port (both at 19200 baud). I also have six gpio pins to opto-solid state relays for pyro events (and six more gpios to check pyro continuity) and 4-5 other gpio pins extended up and down the rocket 4-6 feet for hall sensors and other event sensors. (the CPU board sits central in the rocket and sensor/pyro leads go up and down the airframe). There is a LOT of i/o going on. I have 3-4 different antennas I swap out, but the antenna is always within inches of the T4.1. Some are dipole, inverted V, and whip. There really is no way to get the antenna further away, as the airframe hard separates during flight above and below the board for parachute deployment. The whole thing runs on a single 7.4v lipo battery that splits into a 5V line for the radio and the T4.1 and 3.3v line for the baro, accelerometer, IMU, and GPS. The radio TTY serial levels (and all sensors) are 3.3v. I have the T4.1, all the sensors, SSRs, etc. on a custom PCB that is about 4.5" x 2" with terminal screws or JST plugs connecting the PCB to all the sensors and pyros on the rocket.

The canary in the coal mine for my RFI woes is the SD card. It seems to glitch out first and stop writing. I can reproduce the SD issue reliably, by placing my setup with the antenna next to a metal table (causing RF reflection back into the package), but the other RFI issues are more intermittent. In addition to the SD, I get anomalous readings on the I2C bus, usually from the barometer first. During the flight this weekend, my issue was with GPS lock and/or GPS serial comms back to the Teensy. It refused to lock (and I was getting erroneous barometer readings), until I disconnected the radio. I know from my ESP32 days that poor antenna or feed design can cause lots of RFI issues. I always knew when I had a bad antenna design, based on RFI on the ESP. So, now I am using "known good" feed line and antenna setups that SWR < 2.0, but the T4.1 just seems a lot more sensitive. So, it is time to dig in and shield it and protect it with as many belts and suspenders as I can.

Here is my current thinking, based on light research (not my area of specialty):

1) I am going to attempt to design of a copper box/shield around the board in its 3D printed sled. I can likely cover the top, bottom, and three of four sides. I am also considering a small shield over the T4.1 on the PCB on top and bottom. Anyone else ever do this at the PCB level?
2) Use of ferrite beads on the power feeds and on all the active GPIO lines. Any suggestions on using ferrite beads on the I2C or serial lines? What size?
3) Small caps on the i/o lines (1 uf?)
4) Eliminate ground loops on the PCB -- use "ground star" layout. I do have ground loops, I also have long 4-6 foot ground wires running to separation sensors in the airframe.
5) Use a separate 5V regulator for the radio to isolate the power more (I really don't want to use a separate battery, due to space/weight).
6) Use stronger pull-up resistors in the I2C bus. Currently I am depending on the pull-ups on some of the sensor boards. Maybe add some 4K resistors on the board to ITC lines? I can't slow down the I2C without impacting my sampling and velocity integration.
7) I'm going to swap out my bosch BME280 for a different barometer. The Bosch is known to be more RF sensitive.
8) I am also researching a Lora based 1 watt radio to replace the 2 watt FSK serial radios. I need these to work > 100K feet, so I can't go much lower in wattage, but maybe different radios will give me the same range, but less RF (?)

If anyone has experience shielding a Teensy from external RFI I would really appreciate your advice. Thank you for any ideas or suggestions.

Mike
 
@brtaylor might have some real world flying Teensy experience?

The T_4.1 bottom QSPI pads can hold PSRAM'S - not static enough perhaps.
> how much space is needed?
> how many bytes/sec to write?

Asking because Teensy Duino Beta 7 of version 1.54 has LittleFS that would allow using a 16-256MB Flash chip soldered on if ~2MB/sec write speed is good enough - depending on the chip in use.
 
if you go with lora you can get 0.1 and 1 watt modules. your range may get better rather than suffer
because at 300 baud receiver sensitivity is an astounding 0.01 uv which is 20-24 db better than many
fsk radio rcvrs. as the baud rate goes up so will rcvr sens but is still a bit better at 19200 than many
fsk rcvrs. as far as the transmitter shooting down other equip, it may get better because lora is spread
spectrum spread over 500-1000 khz so there is far less energy/harmonics at any one narrow band.

0.1 and 1 watt lora modules are avail for 433 and 915

can you keep everything xcpt the radio/antenna at one end of the bay and the radio/antenna at the
other or is it full up?
 
Thanks. The SD card itself is not the issue and SD is only one symptom of the RF interference. I've flown the SD card (on the T4.1) at 44 gees logging at 100hz without a glitch on bigger rockets where I had more room to move the antenna. I suppose flash chips might be less susceptible to EMF (?) than SPI/SD, but the wouldn't solve the reliability issues on the rest of the I/O. I believe I really need to shield and protect the circuit, given the close proximity of high wattage RF.
 
can you keep everything xcpt the radio/antenna at one end of the bay and the radio/antenna at the
other or is it full up?
Thanks. I have some 1 watt 433mhz Lora radios I'm using for another project, so I just need to pull them over to this project and test them. The others I had tested up to 20 miles "peak to peak" in the local mountains. I'll just need to do that same level of testing with different antennas with the Lora modules. I am hopeful that the Lora 1w give me the same reliability as the 2w FSK. The Lora also have a mesh/repeater option, so I could also set up a bigger (stationary) base station potentially to relay to our hand-held receiver/tracker. My MCU to Radio is 19,200 baud, but the over-air it is 4800 baud radio-to-radio, so that is still a lot of bandwidth.

Unfortunately, the small avionics bay is full up and a decent antenna (dipole) is 12 inches long for that frequency, so it takes up the whole length and soaks everything in the avionics bay with RF (good times!). I've tried moving the antenna all the way down and even used an inverted V antenna sticking out -- that is the best for minimizing RF, but with that configuration this weekend I still had issues.
 
So far our Flight Control Systems have only used the Teensy 3.6. I do see noise on the BME280 if there is any sort of transmitter on the vehicle. Haven't had any issues with SD or any of the buses. We occasionally get drops on the I2C bus, but that is due to the connector, long I2C cable runs, and vibration. Or at least that's what I'm suspecting. We're typically using relatively low power 900 MHz SiK radios.

That being said, I have a prototype new flight control system using the Teensy 4.1. I'm getting 3 of those built and will be using it to flight test some research this summer. I also have some higher power radios from MicroHard (up to 1W, IIRC) in both the 2.4 GHz and 900 MHz bands. I'll share any interesting data I get, but it'll probably be a month before I start flying those.

Brian
 
Also, if you have good experiences with a different static pressure transducer, please let me know.
 
Also, if you have good experiences with a different static pressure transducer, please let me know.
Thanks Brian. I've got over 30 flights logged and also have not had many RF issues, until recently with the T4.1. Since I ported it, I've only flown it in 4" and 8" rockets without issue, but this weekend I moved it to my 3" avBay for a two stage (4" to 3") flight and it really didn't like that. The combination of close quarters and way more wires for staging/events put it over the RF edge. Anomalous data due to RF can be dangerous with staging, so I am going to rework as much as I can to get back to stable. It is also a good excuse to finally switch over to Lora.

Re pressure transducers, I have an Arduino-based DAQ for pressure and load testing that just uses the 5v 1/8" sensors from eBay. I use them with a 5v Arduino board, as the teensy ADC is not that robust and is only 3.3v. I have another solution that I'm building now for bi-propellant loading and hope to use the Teensy with a voltage divider, but I haven't tested the resolution and reliability yet. I used to fly with a pressure transducer on the motor, but after a few flights I realized that the high resolution accelerometer data was almost as good at mapping my pressure/time curve. Here is a link to my static testing rig w/load cell and pressure transducer info...

https://github.com/AllDigital33/diyDAQ
 
Re pressure transducers, I have an Arduino-based DAQ for pressure and load testing that just uses the 5v 1/8" sensors from eBay. I use them with a 5v Arduino board, as the teensy ADC is not that robust and is only 3.3v. I have another solution that I'm building now for bi-propellant loading and hope to use the Teensy with a voltage divider, but I haven't tested the resolution and reliability yet. I used to fly with a pressure transducer on the motor, but after a few flights I realized that the high resolution accelerometer data was almost as good at mapping my pressure/time curve. Here is a link to my static testing rig w/load cell and pressure transducer info...

Thanks! I actually meant air pressure as a replacement for the BME280.

Regarding staging, when I was working as a researcher at NASA AFRC, we had a close-call where the Flight Termination System on a UAV was triggered from RF noise when the pilot engaged the yaw trim motor. Lucky for us it happened on the ground during preflight. Ended up re-wiring the ground station to reduce the likelihood of RF noise and modified the software to require receiving some number of frames in a row issuing a command before that command was determined to be valid. Maybe a similar software approach could be used for staging?
 
is the nosecone at least 6 inches or 12 inches tall? is it balsa wood?

with some 0.125 od mini 50 ohm coax maybe you could bury a
monopole w short drooping radials or a dipole in the nosecone.
or put a thin dipole made from thick foil in the outside of the
cone or body and hold it down with laquer

is there any room in the empty body tube below the avionics bay?
1/4 inch cardboard is even more transparent than an inch of balsa
 
Thanks! I actually meant air pressure as a replacement for the BME280.
Doh! I do not have my replacement for the BME280, but I have heard good things about the MPL3115A2R1 from NXP. It does not seem to have the same RF issues and the Bosch. I've got one on order to try out.
Yes, on the staging logic, I have over a dozen lock-out logic gates that span hundreds of samples across three sensors over 6 seconds, so data anomalies should just result in an aborted second stage firing. The vehicle has to be at a specific range of integrated velocity (accelerometer), air speed (barometer), tilt (gyro), first stage motor burn-out detection (accelerometer B), etc. If all the stars don't align it won't separate and fire.
 
is the nosecone at least 6 inches or 12 inches tall? is it balsa wood?
is there any room in the empty body tube below the avionics bay?

The rockets are primarily fiberglass, some are carbon fiber (RF blocking) with fiberglass avionics bays. The nosecones are aluminum or aluminum tipped and fiberglass. The rockets are sometimes hitting Mach 3 and 40+ gee's, so anything else would shred. Unfortunately, the avionics bay is in the middle of the rocket and at apogee it separates below to release a tiny drogue chute (100% motor and 3-4 inches for a chute below the avBay) and at around 1500' before landing the top half separates off the avBay for a main parachute. So, any lines above or below the avBay get cut or break away during those events. I've tried antenna's on the outside of the airframe with copper tape and epoxy/glass finish, but they don't last long (connectors) and they need to be on the avBay airframe walls, otherwise they get cut away. So... still too close to the electronics. I could run an antenna to the upper airframe above the avBay, but the explosive charges used for separation in the upper airframe would reek havoc on the feed line and connectors. I really have looked at and tried a lot of options. Without a total redesign of the rocket layout and chute rigging, I'm stuck with the current confined space.
 
Did changing the CPU clock change anything on RF interference?

I had not considered changing the Teensy clock speed, but I will add it to my list. That should be easy to try, although I've found myself consuming all the rooms in my big new T4.1 house, after I moved in. I am using some very computation heavy functions to integrate position using the gyroscope and quaternion math 400 times a second (actual rocket science) to determine my bearing and tilt without a gravity reference. I couldn't do that on the ESP32, but with the extra CPU power of the T4.1 I can now do it, while I do twenty other things on five other threads. So, I'd prefer not to slow it down, but it is an option for troubleshooting.
 
You will be surprised, how much you can do with a lower CPU speed.

Indeed the T_3.6 was potent at 256 MHz - @BrTaylor can fill more details - seems the IMU cycle was 500Hz with what he was doing years back - and reading GPS strings in addition to the 9DOF IMU - and sending all data off on SPI for logging to a second Teensy as the rate of output dropped the IMU Math cycle rate under 400.

A T_4.1 at the same speed has more power to spare with dual execute instruction, especially if all code runs from ITCM/RAM1 and larger 32KB cache on slower Data and Code access. So if splitting the diff 256 to 600 MHz somewhere helps with noise it might still run fast enough.

Mention of SD was because it was noted as failed first - it also does good power spikes itself for card I/O. Not sure how much noise it makes in the process.
 
If you're running I2C at the default 100 kHz clock rate, maybe try adding small capacitors between the signals and GND, located close to Teensy. Shielding the I2C wires might help too.
 
Depends of what other pins you use - it might have an effect to play with the PAD settings.

For example, I use something like this
Code:
// https://www.nxp.com/docs/en/application-note/AN5078.pdf
#define PADCONFIG ((0 << 0) | (1 << 3) | (0 << 6)) //Pg 622 Reference Manual
  //I2C:
  CORE_PIN18_PADCONFIG = PADCONFIG;
  CORE_PIN19_PADCONFIG = PADCONFIG;
 //Clock Pin:  
  CORE_PIN15_PADCONFIG = PADCONFIG;
 //I2S:
  CORE_PIN21_PADCONFIG = PADCONFIG; //BCLK
  CORE_PIN20_PADCONFIG = PADCONFIG; //LRCLK
If that works - or has any effect, depends....
If you have a scope, you can compare the waveforms. Or just use the lowest settings (as above) and test if everything that is connected still works reliable.
You should use that in your setup() after all output pins are configured.
Edit: Also - this has almost no effect - but every little bit can help . you can set all unused pins as output 0.
 
Last edited:
Thanks guys. These are good suggestions. I had not considered setting all unused pins to 0. that is easy. Every little bit helps. I am running my I2C at 400 kHz and will try different combinations of stronger pull-up resistors, ferrites, and caps. The o-scope is good for evaluating a "happy state", but has proved worthless for troubleshooting the RF, since adding the probe into the circuit just creates another antenna.
 
As said, the unused-pins things does not help much and is the last useful thing. But you can view the waveform of I2c with the scope and perhaps use the PAD settings and add small caps until the edges are less sharp..
 
Status
Not open for further replies.
Back
Top