I spent some time this evening trying
to dig into the CAN-Do noise. I was able to reduce it by 3 or 4 dB
by temporarily shielding the module with aluminum tape. Before getting
too excited we need to answer the question – is this noise going to be a
problem? I think as a general suggestion we should move the RF to the far
end of the enclosure. We have the space. I think it would be best
to just extend the traces and not get involved trying to decouple the leads
with ferrite beads and a cable – or perhaps build in some filtering into
the PCB and implement with SMD components. Extend the input and output
traces so we can stick with the three PCB
I have another idea that would involve a milled enclosure with multiple compartments. I can see a modular structure where the sections are assembled into a chassis and pulled together with threaded rods. The individual sections would be kept in alignment with pins. That would take care of all the RFI and mechanical flexing issues. If you’re willing to consider this idea I’ll follow up with details. Unless the existing chassis is made rigid and plumb it is a bit concern of mine.
Moving to microphonics… I did a quick check of available information on the Internet and found this: “Barium titanate, which is the base ceramic material for most dielectric systems, will exhibit microphonic effects…” That article went on to suggest tantalum as a non-microphonic choice. Since it should be pretty quiet out there in orbit microphonics shouldn’t be a problem. I did find out where the bulk of is coming from however – C27 and C28. You’ll find them on schematic page 4 between U4 and U5. Almost every capacitor on the board appears to exhibit some microphonics but those two seem to be the worst.
I have seen, in my professional life, a similar situation where an inductor was radiating noise with unacceptable impact. Replacing the inductor with a shielded version was more effective than any overall shield, tho those did work.
Good luck, and thanks again for all your hard work.
Juan Rivera wrote:
Please refresh me on the function of the watchdog timer. In the state I was running, while observing the 3-second jumps, the receiver was shut down but the CAN-Do module and dongle were both powered up (pins 39 and 40 not connected to the receiver.) I thought the module only reset if it detected no heart beat from the dongle.
I think this evening I will fire up the receiver to recreate the noise I've been seeing and then start playing with some brass sheet in front of the inductor as a shield. I tried probing all the pins with a 10x scope probe connected to the SDR-IQ but I didn't see anything. I'll repeat that test with a 1x probe. Based on last night I'm currently thinking that the noise is radiated from that inductor rather than conducted via the 40-pin connector. There are receiver components very close to that inductor.
On 6/11/07, Bdale Garbee <[email protected]> wrote:
On Sun, 2007-06-10 at
20:04 -0700, Juan Rivera wrote:
> To my surprise the module jumps briefly to about 57 kHz at regular
> intervals of about 3 seconds.
Yes, that's the watchdog timer firing and causing a software reset. I
have no doubt that the reset cycle causes a short-term variation in the
current consumption profile on the board itself. If the frequency is
power consumption dependent, note that it's likely to move around a bit
during normal operation... might want at some point to look at
conditions with the CAN-Do! running at a "normal" 20ms update rate.
> My next plan is to probe all 40 pins by using a 10x scope probe. I'll
> start another log called CAN-Do Noise and start posting there as I
> start on this task.
As Lyle pointed out in an off-list email, the power supply on the
CAN-Do! widget was designed to be efficient, not necessarily to be
quiet. Switchers always have noise issues... we've flown a lot of them,
and this isn't the first time some filtering or shielding has been
required to keep everything happy. You're doing the right things to
characterize what's going on, and we'll all help if/as needed.
We (the CAN-Do folk) are following your progress with great interest.
Augmenting the CAN-Do! documentation with some summary of your findings
and mitigation approach to aid future users is something we'll look
forward to doing.