RFI Mitigation

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Coop

Well-Known Member
Joined
Dec 15, 2011
Messages
1,768
Reaction score
8
TRF:

I was wondering what techniques others have used to minimize RFI in dual- or multi- altimeter av bays. I realize one could "always move it to the nose," but let's pretend, for a moment, that this is not an option. What have you done to help decrease the effects of RFI? Has it worked? How well has it worked? Have you considered other things?


I've been fiddling with this ulcer-inducing phenomenon for a few days, and have achieved a workable solution for me and my configuration. I plan on sharing it, once I get the data together (yes, it's going to have actual numbers and measurements), but I am curious what others have run across and what workarounds they've implemented...



Later!

--Coop
 
I have thought about it before, but do not have any way to measure.

Could you mount the devices on opposing sides of the sled, and at the same time make the sled conductive. You could them also line the electronics bay with copper foil. Sort of a faraday shield.

You could go further I suppose and twist along the wired pairs.
 
Twisted pair wires will help reduce EMI/RFI induced into the electronics from the charge wells. Theoretically at least that shouldn't really be a path into the sensitive part of the electronics because that should be a relatively low impedence path, which makes it less likely to be a problem. If you really want to reduce EMI/RFI into your electronics, you could put them into a Faraday cage; I've never seen that done in a hobby rocket, though. If you look at the Eggfinder TX board you'll see some long narrow pads at the bottom edge of the board opposite the RF module; I put them there for a shield. After doing some testing I decided that it really wasn't necessary; I haven't heard any reports of an Eggfinder dorking anything. (But I would certainly like to hear if anyone has seen anything untoward...)
 
This is an interesting topic for me, and timely, since I'm building an avbay for AZRT in a 10" rocket that will have two sleds. One will hold two altimeters and the other will hold an Eggfinder. Plenty of room, but I hadn't considered RFI. With only 100 mW output, I wouldn't think it is powerful enough to cause RFI.
 
I have thought about it before, but do not have any way to measure.

Could you mount the devices on opposing sides of the sled, and at the same time make the sled conductive. You could them also line the electronics bay with copper foil. Sort of a faraday shield.

You could go further I suppose and twist along the wired pairs.

Mark:

The devices (in this case, a Raven 3 and a Telemetrum 2.0) were mounted on opposite sides of the sled, and wire pairs were twisted to the extent possible. Copper foil was considered to further isolate out the wire pairs... glad to see I wasn't far off in my idea, there. Have you done this and seen any improvement? Like you, I don't have a way to measure the RFI; only the relative performance of doing one thing against another.

Later!

--Coop
 
Twisted pair wires will help reduce EMI/RFI induced into the electronics from the charge wells. Theoretically at least that shouldn't really be a path into the sensitive part of the electronics because that should be a relatively low impedence path, which makes it less likely to be a problem. If you really want to reduce EMI/RFI into your electronics, you could put them into a Faraday cage; I've never seen that done in a hobby rocket, though. If you look at the Eggfinder TX board you'll see some long narrow pads at the bottom edge of the board opposite the RF module; I put them there for a shield. After doing some testing I decided that it really wasn't necessary; I haven't heard any reports of an Eggfinder dorking anything. (But I would certainly like to hear if anyone has seen anything untoward...)

Cerving:

I had considered a Faraday cage, too... but did not pursue this route. While my testing was not done with an Eggfinder (to be honest, I am too intimidated by the kit to commit to one), I'd be very interested to hear about the way you tested it from a manufacturer's standpoint as compared to mine as a mere end-user.

Later!

--Coop
 
This is an interesting topic for me, and timely, since I'm building an avbay for AZRT in a 10" rocket that will have two sleds. One will hold two altimeters and the other will hold an Eggfinder. Plenty of room, but I hadn't considered RFI. With only 100 mW output, I wouldn't think it is powerful enough to cause RFI.

Wayco:


Glad to bring a well-timed topic onto TRF for you! The same has happened with me several times--I'm working on --or considering-- something, and BAM! Someone else goes and posts about it! My configuration is different than yours, but perhaps this whole thread will yield some ideas for all of us to consider.


Later!

--Coop
 
THE CONFIGURATION:


The av-bay is a LOC style 7.5". The "stiffy" is installed (my inner Beavis cackles at this every time). There are two rotary switches set flush into the wall. The sled is 1/2" ply (yes, overkill by a fair margin, but I had plenty of scrap laying around, so this was used). 1/4-20 allthread connects the top (permanent) lid to the bottom (removable). The sled measures 6.5" across. Sled guides are a pen from my former employer cut in half and epoxied to the bottom of the sled. Batteries are secured on the back side of the sled, with a small battery box for the Raven's LiPo, and the Telemetrum Lipo secured with a couple of wire ties. Raven 3 is mounted on the left, with its USB toward the sled edge. Telemetrum 2.0 to the right, with its USB similarly oriented.

THE PROBLEM:

It was noted that, with the Raven 3 running, there seemed to be excessive times to acquiring GPS lock with the Telemetrum. Once, thirty-five minutes had passed without acquiring lock. Sometimes, it would get lock in a few minutes... others, it seemed to take forever. Lock times without the Raven 3 running always seemed shorter. I'd considered that, at flight time, to get lock, THEN power up the Raven, but realized that I may lose lock during boost, and never reacquire it. I found this possibility disconcerting.


THE TESTS:

A string of tests were run to see if it was just me dismissing the short lock times mentally, and noticing only the long ones. So I did some comparisons running the Raven OFF and ON. When on, the Raven 3 was started first, and after it beeped out its ready state, the Telemetrum was turned on and the clock was started. The clock was stopped when AltOS reported "GPS ready." The test was run six times, and the averages were as follows:

OFF: 8:30
ON: 20:00+

It seemed clear that something about powering up the Raven 3 increased time to lock. The test was stopped after 20 mins, as this seemed an unreasonable amount of time to wait for initial lock, however, the clock was permitted to run until lock was achieved.

Raven 3 shares a common power. Its event triggers are grounds coming out of the altimeter to the event charges. Featherweight electronics offers an elegant little solution to wiring this with their Power Perch, which I have used in the past on other projects. I did not on this one because I want the rotary switches for off/on duties, not the magnetic switch inherent to the Power Perch. I'd considered attempting to modify the Power Perch to accept the rotary switch, and take off the magnetic switch. Then I looked at it. Ain't no frigging WAY I'm going to start trying to take those little itsy bitsy components apart. What I did, then, was use a #4 screw, and attach the wires to it. This was a simple solution at the time, and seemed to work well, until I noted the decrease in Telemetrum performance. I tried, then, to move the screw to see if it had any effect.

The same test was run as above, and the average of the six times were:

OFF: 6:19
ON: 20:00+

I found it interesting that the OFF time decreased with the movement. There were two of the six that acquired lock at 17:41 and 18:27, but these were offset by the excessive times from the other 4 tests. This position did show some benefit, though was not considered a full solution.

Moving to this position placed the power hub (for lack of a better term) close to the allthread on the Raven side. It was at this point I considered a Faraday cage. Then I realized I was considering a Faraday cage, and went into the living room to watch Family Guy and idiotic youtube videos on the couch with my girlfriend.


Next: The Solution...



Later!

--Coop
 
I wonder, how many people have actually had a problem with this? It almost seems that we are overthinking something. Of course, I can't think of any way that you would actually prove that this was a problem that resulted in a sub optimal recovery. At least no way that any of us are likely to implement.
 
So, at this time, I saw some improvement by moving the power hub, yet, was not happy with the results.

I picked up, at Radio Shack, a few ferrite chokes. My intent was to place these around the wires to see if, in conjunction with twisting, I could improve the lock time. Placing them on the wires had little effect. I hadn't left myself enough slack in there to wrap around the choke more than once or twice, and more (or more cores) is recommended. I returned and picked up snap-on cores, which simply clip over the wire bundles. This, too, had little effect.

I looked again at the av-bay, and where each component was. The Raven on the left, with its power hub near the allthread. The Telemetrum on the right, also positioned over the allthread.

Maybe the allthread had something to do with the lock times I was seeing? This struck me as unlikely, but at this point, if I saw one (1) more frigging stupid human trick video on Youtube, I was going to go out of my mind.

So I ran a few tests with the av-bay put together, in pad position. Raven 3 was powered up first, then the Telemetrum.

No choke. I retroactively named this as "position 0":

1: 20:00+
2: 01:21
3: 09:46
4: 09:10
5: 07:33
6: 08:36


Average: 09:24

This was taken as my baseline, and time to beat. The clock was stopped at 20 mins. If it had not achieved lock at that time, the test was considered a failure.

I placed one of the chokes on the Raven 3 allthread. I called this position 1.

1: 07:00
2: 02:44
3: 09:34
4: 03:46
5: 03:38
6: 03:57


Average: 05:07

This, to me, showed a clear improvement. Not only did the average time decrease, but the difference between shortest and longest did, also. There were no time-out (20min+) failures.

I then placed the choke on the allthread on the Telemetrum side.

1: 00:37
2: 02:24
3: 05:35
4: 04:13
5: 02:45
6: 02:42


Average: 03:03

I found this result surprising. Where I was attributing the delay in GPS lock to the other altimeter, the allthread beneath it seemed to be significantly more involved than I'd ever dreamed. Perhaps there is EMI from the wiring that the allthread picks up and makes misbehave with the GPS receiver? Interesting result, and has since been repeatable.

What kind of performance could I expect, then, if I placed a choke on BOTH? We'll call that position 3...

Choke Position 3:

1: 01:36
2: 03:01
3: 01:44
4: 12:50
5: 20:00+
6: 01:23

Average: 06:46

Well, that was interesting, and disappointing. I'd expected further increase, and did not get it. Well, I did... kind of. If I can dismiss the 20:00+ timeout and 12:50 result. While the lock time decreased on average, the results were mixed. Where I may attribute the time-out to battery voltage (it was 4.11 at test start), I can't dismiss the 12:50 result as easily, as that voltage was 4.14. I'd like to explore this further at some point. Anyone have ideas on why this configuration seemed so erratic?


As it stands now, I'm going with position 2.

I'd love to hear other interpretations, and other solutions. What would you think of a wire linking 1 allthread to the other?


Later!

--Coop
 
I wonder, how many people have actually had a problem with this? It almost seems that we are overthinking something. Of course, I can't think of any way that you would actually prove that this was a problem that resulted in a sub optimal recovery. At least no way that any of us are likely to implement.

Excellent point, Al, and overthinking... I may be. It could well be that I'm the only one with the problem, too--and if so, well... then this is merely an exercise in how I attempt to resolve the issue when I don't know the cause.

Proving this is a problem is, like you said, not something I'm keen on implementing with sub-optimal recovery tests to establish a baseline to work from. If GPS lock time on the ground can be improved by adding a ferrite choke or two, I think it is a good solution, and not one I recall seeing discussed before.


Later!

--Coop
 
This is an interesting topic for me, and timely, since I'm building an avbay for AZRT in a 10" rocket that will have two sleds. One will hold two altimeters and the other will hold an Eggfinder. Plenty of room, but I hadn't considered RFI. With only 100 mW output, I wouldn't think it is powerful enough to cause RFI.

Actually a 100mw tx is more than capable of causing rfi if it's output is close to other electronics.
I run my 440Mhz trackers down around 10 - 12 mw output which is more than enough output to give me a great range, and have never had an issue with rfi bothering the altimeters.
Can the Eggfinder be run at a lower output? That would be a lot easier of a fix than trying to shield your altimeters...
Greg
 
If you take it out of the rocket completely and outside into the open air - how long does it take to lock?
 
If you take it out of the rocket completely and outside into the open air - how long does it take to lock?

Excellent point--yes, I did do this, several weeks ago, and didn't notice any excessive delays with them both on. I noticed when I put things in the av-bay when the problem started, but that was all working from memory. I suppose I could repeat the test outside of the av-bay, time it, and compare to the installed baseline. Perhaps later today, I'll do exactly that.


Later!

--Coop
 
Actually a 100mw tx is more than capable of causing rfi if it's output is close to other electronics.
I run my 440Mhz trackers down around 10 - 12 mw output which is more than enough output to give me a great range, and have never had an issue with rfi bothering the altimeters.
Can the Eggfinder be run at a lower output? That would be a lot easier of a fix than trying to shield your altimeters...
Greg

I'm not sure the power output on the Telemetrum is configurable (even though you were talking about Wayco's Eggfinder), but that's a good point--playing with the power outputs to see if that makes a difference. Thanks!


Later!

--Coop
 
I've had similar issues with my Telemetrum. I asked what the average time to get a lock was and got a range of answers. I was told that it usually goes quicker when you're at the launch site because you're not surrounded by trees, houses, etc. I hope so. My times ranged from 2.5 minutes - 10+ minutes.

I printed a cardstock template and backed it with aluminum tape to make a Faraday cage for my Mobius camera that is contained in the same altimeter bay.

https://www.rocketryforum.com/showthread.php?122968-The-City-Slicker-was-The-Space-Cowboy-rides-again&p=1472339#post1472339
 
Excellent point--yes, I did do this, several weeks ago, and didn't notice any excessive delays with them both on. I noticed when I put things in the av-bay when the problem started, but that was all working from memory. I suppose I could repeat the test outside of the av-bay, time it, and compare to the installed baseline. Perhaps later today, I'll do exactly that.


Later!

--Coop

So the electronics were mounted on the sled and the only difference is one case was inside the rocket and the second was outside the rocket?

How about pictures of the insides of the bay? It would be easier to visualize everything.
 
I've had similar issues with my Telemetrum. I asked what the average time to get a lock was and got a range of answers. I was told that it usually goes quicker when you're at the launch site because you're not surrounded by trees, houses, etc. I hope so. My times ranged from 2.5 minutes - 10+ minutes.

I printed a cardstock template and backed it with aluminum tape to make a Faraday cage for my Mobius camera that is contained in the same altimeter bay.

https://www.rocketryforum.com/showthread.php?122968-The-City-Slicker-was-The-Space-Cowboy-rides-again&p=1472339#post1472339


Chris, my av-bays aren't anywhere NEAR as complex as yours... you make much better use of available space. Excellent way to fabricate the cage, there... did you notice any improvement afterward?

My average lock time in my configuration, prior to attempting to speed it up, was 9:24 with both altimeters running. There was a fair degree of variance --some shorter, some much longer. I started getting uncomfortable with it at 10 mins, and wrote off 20 mins as a complete fail. Maybe you could use this as a comparison for yours?

Later!

--Coop
 
So the electronics were mounted on the sled and the only difference is one case was inside the rocket and the second was outside the rocket?

How about pictures of the insides of the bay? It would be easier to visualize everything.

When I did the initial test with everything outside the av-bay yes, I had the electronics mounted to the sled, and the sled out of the av-bay. The battery placement was the same, but the charge leads were disconnected.

Photos would help, sure. I'll see if I can get some posted. That feature has not been working well for me the last few times I tried it.


Later!

--Coop
 
If GPS lock time on the ground can be improved by adding a ferrite choke or two, I think it is a good solution, and not one I recall seeing discussed before.

Never considered the idea that cleaning up the DC bus would help with GPS acquisition and lock. Are you just going to filter the power in, or every lead connected to the avionics?
 
Never considered the idea that cleaning up the DC bus would help with GPS acquisition and lock. Are you just going to filter the power in, or every lead connected to the avionics?

I don't think I'm going to do either --at least directly. The allthread seems to be the culprint here. Placing the choke on it seemed to improve performance. I'm suspecting that, because of the threads, it's causing some interference which messes with the receiver --perhaps due to its orientation or position (neither I'm willing to mess with at this point). In the future, however, I'll leave myself some room for chokes on the wiring, see if that helps any. I'll allow this may be an inherent problem with the av-bay in this configuration which is exacerbated by powering up the other altimeter...

I'd considered placing a wire with ring terminals across the end of the allthreads, pretty much linking them together, in the hopes that any EMI will be spread out, then, and not interfere with the GPS receiver so much. Does that sound reasonable? Or is there something there that I'm overlooking?

Later!

--Coop
 
Very nice. Always interesting to see different approaches to solving the same challenge. Lots to learn.

What is the rocket body made of and what type of paint did you use?
 
Very nice. Always interesting to see different approaches to solving the same challenge. Lots to learn.

What is the rocket body made of and what type of paint did you use?

Much thanks!

Airframe is FG-wrapped LOC 7.5." I did a wrap of kevlar tape at the body section joints, under the FG. Paint there was just the Rustoleum 2x black. I had so many Sharpie marks on the av-bay and sled I just gave it a coat to make things less confusing.


Later!

--Coop
 
Guys, if you are at a new location it can take GPS up to 15 min. to lock in your location. If it is where you normally fly and have not gone to a new field with it it should find your location much quicker as it keeps a memory of the satellites it last acquired. Whenever I am at a field I start my units and let them lock up. Then when I am ready to fly it is much faster. Just something to remember when doing your testing.

Dennis
 
Guys, if you are at a new location it can take GPS up to 15 min. to lock in your location. If it is where you normally fly and have not gone to a new field with it it should find your location much quicker as it keeps a memory of the satellites it last acquired. Whenever I am at a field I start my units and let them lock up. Then when I am ready to fly it is much faster. Just something to remember when doing your testing.

Very good point, Dennis.

Before I started the clock on any of the tests, I had let the GPS sit and acquire lock for as long as it took. This was the "turn it on, go feed the goats, make a pot of coffee, and come back," phase. All of these were, then, what could be considered "hot" locks.

Later!

--Coop
 
This one started out as just a TeleMetrum in the NC, then I decided to add the camera, then I decided to add the RRC2+ as a backup. :rolleyes:

I was doing some testing in my backyard in the shade of a tree and the times were terrible. I moved the TM about 6-8 feet away and my times came back down to 3-8 minutes.

With the unshielded camera and RRC2 powered up it took over 10 minutes if it ever got a lock. The shielding brought the times back into the same range as when the camera was off, so it seemed to work.


Chris, my av-bays aren't anywhere NEAR as complex as yours... you make much better use of available space. Excellent way to fabricate the cage, there... did you notice any improvement afterward?

My average lock time in my configuration, prior to attempting to speed it up, was 9:24 with both altimeters running. There was a fair degree of variance --some shorter, some much longer. I started getting uncomfortable with it at 10 mins, and wrote off 20 mins as a complete fail. Maybe you could use this as a comparison for yours?

Later!

--Coop
 
That definitely seems like the TM's GPS receiver is susceptible to certain kinds of interference. Glad you got yours corrected with the cage! That's fantastic!

Later!

--Coop
 
Back
Top