XBee transmissions causing servo glitching

[ben levitt]

First off, I'm using a pair of XBee Pro 900s, and the SparkFun XBee
Explorer Regulated board in the plane. And I use a 2.4GHz Spektrum
receiver, and a ublox running at 4Hz.

I did some test flights this morning, but unfortunately I had to
remove the XBee from the plane first. The servos were making a
ticking sound at 4 Hz (one tick per line of telemetry) which seemed
weird, but didn't actually move the servos perceptibly, so seemed
hopefully harmless. But when I tested switching on stabilized/auto
mode, the servos were glitching pretty hard (very noticeably) at 4 Hz,
and it seemed like a bad idea to fly it like that.

I'm wondering if the servo cables or receiver are picking up some hint
of the transmission. But it seems that since the glitching is mainly
happening when in stabilized/auto mode, it must be affecting the
gyro/accelerometer readings.

My top ideas right now are that either the transmissions are
interfering with the sensor readings, or that the XBee pulls extra
power when it transmits, and the extra power draw messes with the
readings.

Maybe to try to see if it's the power or the transmission, I'll try
powering the xbee board from an external 5V power source and see if
the problem still happens.

Has anyone else seen and solved similar problems?

Thanks!

Ben

[SIDDHARTH]

Hi Ben,
I have used 900 MHz modems in the past with standard 72 MHz
radio, I also had the same problem typically when there was a transmission
from modem the servos were making a tick but fortunately I was using IR
stabilizing sensors, so probably could not see what you are facing right
now. The servo tick issue got resolved by having more separation between
Xbee antenna and servo wires.

Using another supply would definitely help if your setup do not need
a common ground between them.

Theoretically 900 and 2.4 are usable frequencies together. You can
try binding both once again, it may catch a different channel perhaps.

A ferrite core coil over servo wires also would help.

Ultimate solution is to have opto isolator on all servos. I think
Jordi has one.

http://store.diydrones.com/ProductDetails.asp?ProductCode=BR%2D0003%2D11

Regards
SID

[Adam Bellchambers]

I have been involved with a development program that had similar sorts of issues as well, we had a plane with 36mhz RC gear, 1W 900mhz xTend, and a 2W 2.4ghz analogue video transmitter, as well as a spark ignition engine. EMI / EMC is a huge issue for these small aircraft, as it is virtually impossible to achieve any significant separation between components, and our airframes are non-conductive, providing no shielding from outside sources, or our own emitters, and also denying us any sort of common ground plane.

There are a few possibilities that spring to mind here:

1. The xbee is sucking lots of power when it transmits as you suggest. This seems quite possible, i know the xtends would buffer the data internally and then send it in 1mb/s bursts, and would draw over an amp while doing so. Hopefully this is the case as its not really an interference issue and is easily fixed - run the xbee from a seperate supply, or maybe just add some caps across it's input to help buffer any surges.

2. The xbee signals are being picked up by the servo leads. This is possible as the servo leads will be more than long enough to act as 900mhz antennas. Shielding servo leads or adding ferrite cores may help.

3. The xbee signals are being picked up somewhere on the dev board and affecting the sensors. you could try sending the raw adc outputs to the debugging port to see whats happening, but that then changes the behavior of the xbee so you lose the control part of the experiment. If you can get at the sensor outputs directly with a scope before they go into the adc. While you're at it, look at the power lines on the dev board with the scope, and whatever reference voltage goes to the ADC's (if it's not just vcc, i can't recall right now). If this was the case, i wouldn't expect any glitches in manual mode, as i would have thought the UDB just passes the rc signals straight through in manual mode? (could be wrong, haven't looked at it yet, still don't have my dev board on anything that moves, so i haven't needed to...)

4. The xbee signals are affecting the receiver. With constant stick settings, watch the servo signals coming out of the RX with a scope, and see what the pulse width does when the xbee transmits. This may be a hard one to fix, but it it was the case then i don't think it would show up in autonomous mode?

4. The xbee signals are affecting the dsPIC. This could be from noise being fed through the power rail (which could be being picked up by any device with a power lead connected to that rail, so pretty much everything!), or could just be power surging/drooping as you suggested. The combination of steps in 1 and 3 should show if this is the case.

Finding what is causing these sorts of problems isn't too hard. People make out like it some black art determining the causes of interference, but the reality is our platforms are pretty simple, and as long as you are methodical* it should be possible to work it out. I have watched people waste days in the field changing stuff around randomly trying to fix emi issues, when what they needed to do was put the thing on a bench with some test equipment and think about what they were doing. Once you're found the issue, *fixing* it may not be nearly as easy, but at least you'll know *what* you're trying to fix.

* note that being methodical does not mean you will have an answer any quicker than the person who swaps stuff randomly, but at least you will have some degree of confidence in your solution.

SID, i don't know that optos on the servo leads will help in this case, although i'm not sure if you mean the leads from the RX to the dev board, or the ones from the dev board to the servos? Whilst as a general rule, running anything with motors or solenoids or other horrible inductive loads off a separate supply with opto isolated signal lines is a good idea, i don't know that it would help with RF interference here.

Cheers all!

Adam

I think in this case opto's on the TX and RX lines between the dev board and the 

[SIDDHARTH]

Adam,

                        It will not eliminate RF interference but basically OPTO is for servo signal isolation. Definitely if you use them the servos will not jitter. To be installed between dev board and servos.

 

Regards

SID

 

---

[prem...@nycap.rr.com]

Team,

 

Adam's email contains some good advice. I will add a couple of thoughts.

 

1. One way to eliminate interference with the Rx as a suspect, is to run a test without an Rx. The closest we have to firmware that will do that is the roll-pitch-yaw demo, except it does not have any serial output. Ben, if you want to revise the roll-pitch-yaw demo to serve as a "glitch" sleuth, I can tell you what to do, though I suspect that you could figure it out for yourself. If roll-pitch-yaw demo runs smoothly without an Rx, but with everything else hooked up and running, than there is a good chance the problem is interference to the Rx. Ben, another way you can run this sort of test is to take your latest firmware, and change the PWM input routines to simply always give the same hard-coded pulse width values.

 

2. Not that it matters, I suppose, but interference with the accelerometers would not cause a problem, because the accelerometer signals are heavily filtered. There could be interference to the gyros.

 

3. Ben reported that he saw more glitching in any of the stabilized modes. That would be easy to explain if he was using a non-zero value of "BOOST", because that would amplify any variation in the width of the pulses coming out of the Rx.

 

4. The UDB is more sensitive to glitches in the pulses than a servo is, because it can respond to very high frequencies, where the servos tend not to.

 

5. Because of the CMOS Schmidt triggers in the PWM inputs of the dsPIC, it is more susceptible to glitching if the peak voltage of the Rx pulses is closer to 3 volts than to 5 volts. The reason is, if the pulses are close to 3 volts, they are right on the hairy edge of triggering the dsPIC, so a little bit of noise added to the signal can cause a large variation of the timing of the triggering. So, one thing to check is the peak voltage of your Rx pulses. If they are close to 3 volts, you might want to use a different receiver with higher peak voltage. SparkFun has changed the design of the UDB to use a 4.5 volt regulator instead of a 5 volt regulator, that should help, if this is the problem.

 

6. The accelerometers and gyros on the redboard run off a regulated 3.3 volt supply. The supply to the A/D runs off the main 5 volt supply. The reference for the A/D is the regulated 3.3 volt supply. So, the main supply voltage would have to dip below about 3.5 volts to have any impact on the A/D.

 

Best regards,

 

Bill

[Russell Duffy]

Greetings,

 

I have a GPS tracker/telemetry gizmo that uses a 900 MHz XBee XSC (100mw) unit, and came very close to putting it in the plane last weekend.  Probably a good thing I didn’t :-)

 

I powered up the plane, let it finish it’s initialization, GPS, etc, and verified that it was working OK in manual and stabilized mode.  Next, I turned on the XBee close to the UDB.  All was still fine in manual, but when I turned on the stabilization mode, I found the elevator down, and ailerons right.  When I turned off the XBee, the ailerons slowly went left, and the elevator up, then over the course of a minute or two, finally came back came back to neutral.  This was strange, but repeatable.  I also tried a 500mw 900MHz video transmitter, with the same result. 

 

If you leave the UDB in stabilization mode, then turn on the XBee, I hear a “ticking” sound from the servos, but it’s the sound of them slowly moving as they drift.  They will go almost full throw one way, then maybe back the other part of the way, but all very slowly.  During this time, the stabilization controls still deflect if you move the aircraft. 

 

In my tests, there’s no electrical connection between the XBee and aircraft, so it’s certainly going to be radiated RF getting into something, and my guess is something on the UDB.  I think the manual mode would have problems if it were getting into the receiver, and I’ve used these Futaba FASST receivers with the 500 mw video TX lots of times, with no issues like this.  Really cheap servos will jitter, but I’ve never seen on drift.

 

In case there’s a betting pool going, my guess is going to be that the RF is somehow making the ACC offset change.  That’s just a SWAG, and I fear I won’t be able to resist looking at this more on the bench. 

 

Cheers,

Rusty (I hate RF)

 

[prem...@nycap.rr.com]

Rusty,

 

You may be right that the RF is getting into the accelerometers. At first I thought it was the Rx, but now I am not so sure.

 

There is a simple test to narrow down the possibilities:

 

1. Change the firmware to ignore the PWM inputs and set them to constant values that will put the control into stabilized mode. (Ben, can you make a version available with that feature?)

 

2. Connect everything up the way that is giving trouble, including the Rx. Just leave the motor disconnected, or take off the prop if you don't have connectors in the motor leads.

 

3. Turn everything on. After initialization, check the response of the servos to pitch and roll. If they are normal, the problem is with the Rx. If not, the problem is elsewhere, probably in the UDB.

 

PS: I have found receivers that are experiencing interference may still operate servos ok, but not the UDB. That is because the two respond differently to glitches in the middle of the pulses. Analog servos are generally more forgiving of glitches than the UDB is. Ben and I have discussed revising the PWM input firmware to tolerate the glitches, but first we need to see what they look like. It is on our lists of things to do.

 

Best regards,

Bill

----- Original Message -----

From: Russell Duffy

To: uavde...@googlegroups.com

[Russell Duffy]

Bill,

 

I set up the spare board on the workbench, just like the one in the plane, and can easily make the problem occur.  I used the XBee with a small rubber ducky antenna, and probed around as best I could.  While this is far from conclusive, my current thought is that the gyros are likely the guilty party.  Moving the antenna near the gyros one at a time, you can make one servo at a time act up.  No amount of probing around at the receiver outputs caused any noticeable problem.  Of course you can’t scope anything, without the risk of ruining the results by turning the probe into yet another antenna, so this may have to be solved via software troubleshooting.  

 

I agree that eliminating the receiver inputs in software is a great test.  I assume it’s also possible to fake the gyro or acc values in software, so you can disable those inputs to the PIC?  If so, that’s going to be another good test.  I’m software challenged, but if someone can modify the software, I’ll be happy to test it.

 

Rusty

 

 

 

From: uavde...@googlegroups.com [mailto:uavde...@googlegroups.com] On Behalf Of prem...@nycap.rr.com

Sent: Friday, October 30, 2009 3:16 PM
To: uavde...@googlegroups.com

[Adam Barrow]

Rusty,

 I'm unfortunately way out of my league with RF, but I'm curious if the same behavior happens with the XBee 'wire' antennas? 

I just purchased a UDB from SparkFun and haven't set up the source code in my development environment yet, but if no one beats me to it, I'll be happy to compile the code for you (I'm a programmer by trade). Do you want a version of the firmware with gyros and receiver inputs 'frozen'? Or would it be more useful to have two versions -- one with receiver inputs 'frozen' and another with the gyros fixed?

Adam

[Adam Bellchambers]

Guys,

Ben appears to already have a no radio config option in the latest revision of the code, and it's been there for a little while (he must have forseen this issue :). If you look in options.h there is the following:

// Set this to 1 if you want the UAV Dev Board to fly your plane without a radio transmitter or

// receiver. (Totally autonomous.)  This is just meant for debugging.  It is not recommended that

// you acually use this since there is no automatic landing code yet, and you'd have no manual

// control to fall back on if things go wrong.  It may not even be legal in your area.

#define NORADIO 0

if you set this to one, the servo pulses are only controlled by the UDB, and the RX inputs are ignored. This means you will not be able to switch between manual and autonomous modes, and the plane will be autonomous as soon as you turn it on. so like the comment says, for DEBUGGING ONLY!!! But it should help with the troubleshooting, with no programming required :)

Cheers

Adam

[ben levitt]

Note that this is untested, and wasn't really meant to work while
actually connected to a receiver. :) But it might work!

Come to think of it, you could also test by turning off the
transmitter after gps lock, if you're set up to recognize a loss of
signal.

I wish I could test this more right now, but work exploded, and will
probably keep me from playing much for a couple weeks...

Ben

[SIDDHARTH]

Guys,

                        Just to give you some inputs. I do not know what UDB is but thought this will help. I have used 2.4 Ghz video Tx (500 mW) and  434/444 MHz UHF RC link with Red board successfully in all modes. I have not tried 900 MHz video TX but I do have; I will test the same and will let you know the results. Hope it helps.

 

Regards

SID

 

---

[Russell Duffy]

Greetings all.  I’m going to try to mix all the replies in one message, so I don’t get flagged by the spam filters :-)

 

 

 I'm unfortunately way out of my league with RF, but I'm curious if the same behavior happens with the XBee 'wire' antennas? 

 

Adam,   I’m no RF expert, though I’m learning more all the time, mostly out of desperation.  RF is just evil.   As for the antenna type, I can’t imagine it will matter.  I get my XBees in the U.FL connector variety, so I can use most any antenna.  I think any antenna that transmits the power relatively efficiently, will cause the same problem. 

 

As for the programming offer, stand by for now, and I’ll try the NORADIO option in Ben’s software to eliminate the receiver, and probably more importantly, the wiring from the receiver to the UDB.   

 

---------------------------------

 

Note that this is untested, and wasn't really meant to work while actually connected to a receiver.  :)  But it might work!

 

Come to think of it, you could also test by turning off the transmitter after gps lock, if you're set up to recognize a loss of signal.

 

Ben,  I saw this option yesterday, but of course didn’t try it.  There are a few other settings in the new options.h file that I wasn’t sure how to set, but we’ll save that for another discussion.  As for the NORADIO setting, I’ll try it tomorrow when I get a chance, and see if it seems to work.  I presume it’s fixed in the waypoint mode, since there’s no radio connected?  

 

Turning off the TX won’t work for me, because the Futaba FASST will hold the last signal, or give the failsafe value, so it never appears to lose signal.  I did try unplugging channels 1 and 2 from the UDB after it was up and running.  It seems like that still had the same problem, but I’d have to try it again to make sure. 

 

------------------------------

 

Just to give you some inputs. I do not know what UDB is but thought this will help. I have used 2.4 Ghz video Tx (500 mW) and  434/444 MHz UHF RC link with Red board successfully in all modes. I have not tried 900 MHz video TX but I do have; I will test the same and will let you know the results. Hope it helps.

 

Sid,  UDB is UavDevBoard.  I’ll be interested to hear what your 900 MHz video does, but it almost has to cause the same problem. 

 

------------------------------

 

(Speaking of which, I am presently working with SparkFun on the next design. Should we test it for interference resistance?)

 

Bill, Sounds like maybe we should, though I’m not sure how the best way to test it would be.    It’s still sort of hard to imagine that this could be causing a problem with gyros, or ACC, since I’ve never seen that before.  I fly mostly quadrocopters, and often have a 500mw 900MHz video transmitter within inches of the flight control board.  Of all the problems I’ve had (GPS interference mostly), I’ve never seen any hint of a problem with the RF getting into the sensors on the board, so I’m not sure why it would be doing it here. 

 

If the problem is that the Xbee is interfering with the UDB power supply by dragging the voltage below 3.3 volts (that would certainly cause a problem), then the solution would be to provide a separate power supply for the Xbee.

 

For my particular test, the XBee has its own power supply, as did the 900 MHz video TX.   The XBee’s do pull about 180ma average when transmitting steadily, and they really strain that SF “regulated” board’s 150ma regulator, so it’s something to consider when deciding how to power it.

 

Finally, distance is your friend, and with airplanes, there’s at least some room to relocate items for some separation.  If I get desperate, there’s always the copper tape :-)

 

Rusty

 

 

 

[Adam Bellchambers]

Hi all!

One of the joys of RF stuff is that the same stuff organised differently cause easily cause problems where none have existed before. the length required for a 1/4 monopole antenna at 900mhz is about 80mm, and about 30mm at 2.4ghz. *anything* that is conductive and around those lengths, or a multiple thereof, will act as an antenna. This could be servo leads, power leads, PCB tracks, internals of the batteries, brackets, pushrods etc. things that aren't connected electrically to the system in question, such as pushrods and landing gear can still re-radiate the RF energy they receive, which can change the RF environment around the device under test. Typically on a real aircraft, all your equipment enclosures will be shielded and electrically bonded via a low impedance path to a common ground plane, which will probably be the fuselage, or perhaps a specific grounding plate in equipment bays. I'm just going through my stuff at the moment trying to find the notes from the EMI/EMC course i did at uni, in the meantime the following wiki links have some excellent material to get a background on how this stuff works. (probably better than any explanation i can produce!).

http://en.wikipedia.org/wiki/Electromagnetic_interference

http://en.wikipedia.org/wiki/Electromagnetic_compatibility

http://en.wikipedia.org/wiki/Electromagnetic_shielding

http://en.wikipedia.org/wiki/Twisted_pair

Adam

[Russell Duffy]

Greetings,

 

Very quick update-  I loaded Ben’s code, with the NORADIO set, and fired it up with no receiver connections.  It seems to function, and after a few minutes, the red LED starts flashing, the aileron assumes the position, and both aileron and elevator servos respond to pitch and roll of the board. 

 

Next, I tried the XBee, and the video TX, and I’d have to say that the problem is unchanged, pretty much as we expected.  I’m still guessing it’s the gyros, but probing around with the end of an antenna is like soldering SMD components with a flame thrower, so it’s hard to know for sure. 

 

If we can get a version of software with the gyros, and/or the acc sensors locked, I’m still interested in knowing which is it, though I’m not sure it matters much.  I wasn’t kidding about the copper tape either :-)

 

Rusty

[Adam Barrow]

Rusty,

 I'm about to start the Halloween madness (two little ones in our house) so I'll be busy for the next couple of hours, but I can modify a version based on Aileron Asisst 1.7 to 'freeze' the gyros and the acc sensor after that's all done. If you would rather I base it off a different version, please let me know.

With the copper tape, are you thinking to just build a sloppy shield out of copper tape? Would separating the antenna (I've already got a set of XBee modules with telemetry in mind) help, based on your testing?

Adam

Sent from my mobile phone.

[Russell Duffy]

Hi Adam,

 

The version probably doesn’t matter I guess, but it might be better to use Aileron Assist 8b since that’s what I have in the plane for comparison.

 

Yes, for the copper tape, I’d be trying to wrap the whole board, but I don’t know if I’d do that for more than just a test. 

 

Separating the antennas will absolutely cure the problem, assuming you can get far enough away, and haven’t angered any of the RF spirits.  Even with the 100mw XBee, I only have to move it about 6 inches away on the bench, and the 500 mw video TX doesn’t have to move much farther than that.   I’m sure the reasonable solution to this will be separation. 

 

Have fun. 

Rusty

 

 

 

From: uavde...@googlegroups.com [mailto:uavde...@googlegroups.com] On Behalf Of Adam Barrow
Sent: Saturday, October 31, 2009 6:03 PM
To: uavde...@googlegroups.com
Subject: Re: XBee transmissions causing servo glitching

 

Rusty,

[Adam Barrow]

Rusty,

 Here are two versions based off Aileron Assist 8b (the zip file downloaded from the Google code website). Each zip file contains the MPLAB project as well as a compiled HEX file, since I'm not sure what you'd be more comfortable with. Not having setup my board in a plane yet, I've only done basic testing, but the changes were trivial, so I'm pretty sure this will work. I also don't have my XBee modules setup at all, so I couldn't try and repeat any of the testing you've started.

 

Team,

 for the programmers on the list, I decided to edit 'analog2digital.c' lines 73-78. For each change, I basically commented out the respective inputs' filtering and being added to the value. As I read the code, this means that the initial values will be initialized (the first part of the if block) but then none of the subsequent inputs will be considered.

 

Regards,

Adam Barrow (since there are at least two Adam B's on this list)

[Russell Duffy]

Greetings,

 

While I was waiting for my main computer to finish a bunch of housekeeping activities, I went out to the garage and poked around in the software a bit to see if I could figure out how to set the gyros and acc to fixed numbers.  What I found was the following section at the bottom of analog2digital.c

 

                        // perform just a little bit of filtering to improve signal to noise

                xaccel.value = xaccel.value + (( (xaccel.input>>1) - (xaccel.value>>1) )>> FILTERSHIFT ) ;

                xrate.value = xrate.value + (( (xrate.input>>1) - (xrate.value>>1) )>> FILTERSHIFT ) ;

                yaccel.value = yaccel.value + (( ( yaccel.input>>1) - (yaccel.value>>1) )>> FILTERSHIFT ) ;

                yrate.value = yrate.value + (( (yrate.input>>1) - (yrate.value>>1) )>> FILTERSHIFT ) ;

                zaccel.value = zaccel.value + (( (zaccel.input>>1) - (zaccel.value>>1) )>> FILTERSHIFT ) ;

                zrate.value = zrate.value + ((( zrate.input>>1) - (zrate.value>>1) )>> FILTERSHIFT ) ;

 

 

I have no idea what a normal number would be, but I first set the xrate, yrate, and zrate to 100.  This (amazingly) seemed to work, and the board seems to initialize, and the red light starts flashing.  When I tilt the board, the aileron and elevator servos very slowly move, rather than moving quickly.  Since I believe ACC values are typically used as long term corrections, this seems to be about what I’d expect. 

 

For these tests, I’m still using Ben’s code, with the NORADIO option turned on.  With the rates set to 100, I can move the XBee, and even the 500mw video TX all around the board, and nothing happens.  This would seem to be pretty strong evidence that the gyros are indeed the problem, and I wonder if someone could try one of the green boards?

 

For fun, I also tried leaving the rate lines alone, and setting the accel values all to 100.  That initialized OK, and moves more normally when tilting the board.  Bringing the XBee or video TX close to it causes the same problems as before. 

 

From what I can see, I’d say the gyros are the source of the interference. 

 

Rusty

 

[Russell Duffy]

Hi Adam,

 

Our messages crossed paths on the send/receive.  I’ll take a look at what you changed, since I’m curious if I did it right.  I’m really lousy at programming, but I’m trying to learn. 

[prem...@nycap.rr.com]

Rusty,

 

Thanks for your fine detective work. Nice work with the firmware, too. That was as good a way as any to separately freeze the gyros and the accelerometers.

 

I agree 100% with you, the problem is with the gyros. Not much we can do about that, short of changing the gyros, or keeping the Xbee away from the board.

 

How much separation between the board and the Xbee did you need for the problem to go away?

 

When I get a prototype of the next generation board with the Invensense gyros (some time this winter, probably), can I send it to you for RF testing?

 

Best regards,

Bill

----- Original Message -----

From: Russell Duffy

To: uavde...@googlegroups.com

[Adam Barrow]

Rusty,
From your description, I think we both made essentially the same change. The way I did it (by commenting out certain lines) will just keep the values at whatever they were initialized to, where your aproach sets them to 100 specifically.

Adam Barrow

Sent from my mobile phone.

---

From: Russell Duffy <ru...@radrotary.com>
Sent: Sunday, November 01, 2009 11:32
To: uavde...@googlegroups.com

Subject: RE: XBee transmissions causing servo glitching

[Russell Duffy]

Hi Bill,

 

I tried Adam Barrow’s version as well, to see if there was any difference in how the board behaved, and to add the live receiver to the test.  The results were the same, so it would seem the problem is only with the gyros. 

 

This of course begs the question of whether the gyros are especially sensitive to 900 MHz.  I’m planning to convert all my video to 1280 MHz as soon as the boat from China arrives, and I’ll be interested to see if that interferes with the gyros as well.  Didn’t someone say they used 2.4 GHz video transmitters around the UDB without a problem?  If so, then 2.4 GHz XBees would surely be OK, assuming you’re not using a 2.4 GHz radio. 

 

I just ran a test using the 900 MHz XBee (100mw XSC version) and the 900 MHz 500mw video TX.  The first sign of movement from the servos comes when I’m 8-10 inches away with the XBee, and about 24 inches with the video TX.    Proximity of other metal, such as pushrods, wires, etc could change these distances, and sharing the power between the 900 MHz source and the UDB could add to the problem as well.   The best suggestion would be to try to keep it as far away as possible, and test it in stabilization mode (on the ground) to see if it seems to cause a problem. 

 

As for testing the next version, I’d be honored to blast it with any RF I can lay my hands on, except for the 30kw RF amplifiers on our MRI scanners :-)

 

Rusty

 

 

 

 

From: uavde...@googlegroups.com [mailto:uavde...@googlegroups.com] On Behalf Of prem...@nycap.rr.com

Sent: Sunday, November 01, 2009 12:03 PM
To: uavde...@googlegroups.com

[Russell Duffy]

Rusty,
From your description, I think we both made essentially the same change. The way I did it (by commenting out certain lines) will just keep the values at whatever they were initialized to, where your aproach sets them to 100 specifically.

Adam Barrow

Adam,

Your way was the smarter way to do it.  I just got lucky :-)

We crossed paths on the send/receive again, but you’ll see in my other message that I tried your version as well. 

Thank,

Rusty

 

[Adam Barrow]

Rusty,

 having just invested in a pair of the XBee Pro 900MHz transceivers, I'm interested in exploring options to make them work with the UDB. You mentioned that copper tape might be an option, how would that work? Just build a box out of copper tape around the UDB / gyros and tie that to ground? Would you still want the XBee operating on a separate power supply with that setup? 

My first aircraft was going to be an Easy Star (already flying). I'm thinking that I can mount the XBee at the rear of the boom (by the tail) and keep the UDB forward of the wing, which from your description might be enough separation (~18"). I'll  need to get the XBees setup before I can test that setup, however. Is it really obvious if there is any interference? In your  testing have you found anything particular with the XBee that increases the interference?

Thanks,

Adam

[Peter Hollands]

Russel:

I am using the 2.4Ghz Xbee pro without any problems on my Multiplex Twinstar 2.
My main Futaba radio gear is running at 35Mhz.

The Xbee pro is cut into the forward cockpit canopy. (see picture - you can see the aerial sticking out). The UAV Devboard is mounted low down in the main fuselage behind the wing. They are 11 inches apart.  I connected the two together by cutting up an old shielded USB mouse cable to make a 15 inch serial cable.

Pete

[Russell Duffy]

Hi Adam,

 

If I tried the copper tape, that’s how I would do it.  You’d have to put the board in a non-conductive bag, then wrap the tape around that, and ground a spot on the tape.  As for the power supply, I simply don’t know if it would make a difference or not.  The primary thing I know about RF is that I can’t predict what will or won’t work, so I’m afraid you’d just have to try it to find out. 

 

The distance you describe will almost certainly be OK.  Probably the easiest way to see the problem is to have the plane held level and still, then turn everything on but the XBee.  Once it’s ready to go, you should be able to turn the switch from manual mode to stabilized mode, and not see anything happen on the plane.  Turn the XBee on when in manual mode, and wait a couple minutes.  Now flip the switch to stabilized mode.  If you’re getting interference, you’ll see the servos move.  You can also just leave it in stabilized mode, and watch them slowly creep. 

 

Another factor might be the amount of transmitting that the XBee is doing.  Mine is set up with a GPS, and is sending data 5 times per second, so that would likely be worse than if you were sending only once per second.  Also remember that the 900 Pro is only 50mw, not 100mw like my XSC version.  I have the Pro version as well, but it’s not set up with the GPS tracker gizmo. 

 

Cheers,

Rusty

 

 

---------------------------------

[Russell Duffy]

Hi Pete,

 

I’m using that same area in the TwinStar for the UDB, only mine is accessed from the top.  I cut a fairly large rectangle on the top of the fuselage, just behind the wing, and have that whole (enormous) section open.  When I don’t have an AP in there, I can carry a sandwich :-)

 

As for the XBee, it would be interesting to know if the 2.4 GHz XBee could cause a problem.  If you ever have the opportunity, you could move the XBee canopy to the fuselage where the UDB is, and see if it causes a problem.

 

Rusty

 

 

 

 

From: uavde...@googlegroups.com [mailto:uavde...@googlegroups.com] On Behalf Of Peter Hollands
Sent: Sunday, November 01, 2009 4:41 PM
To: uavde...@googlegroups.com
Subject: Re: XBee transmissions causing servo glitching

 

Russel:

[ben levitt]

Thanks all of you for the great ideas on this. I finally made time to
try a few things out tonight:

I moved the XBee further from the UDB (~10 inches away instead of
about 3). This seemed to help slightly, but just a little.

I then tried adding a decent sized capacitor between +3.3V and GND on
the XBEE regulated board, and then between +5 and GND. Neither seemed
to make much difference. (Moving the position my arms near the plane
made more of a difference!)

I then tried powering the XBee from a separate source, while still
connecting the IO pins to the UDB. I also connected the ground of the
UDB to the ground of the external power source for the XBee. When set
up like this, and with the XBee still separated from the UDB by about
10 inches, this interference seems to be gone!

So now I'm wondering if the problem is sharing the power source, or if
it's having unshielded power lines for the XBee running right past the
gyros. :) I think I'll try to rig up a similar grounded cable to
what Pete made, and also pull power from the receiver instead of from
the pins next to the UDB's serial IO pins, since the power for those
pins runs right under the gyros.

I'm really hoping to avoid needing a 2nd battery on board!

Thanks for all the great help!

Ben

[joke...@comcast.net]

Hi Ben,
Sounds like a ground loop.
Joker

----- Original Message -----
From: "ben levitt" <ben...@gmail.com>
To: uavde...@googlegroups.com

[Charles Birlenbach]

Hi everyone,
since I'm using Telemetry too, I tought I could share with you...

As a matter of fact, I have the same "issue" here with my
transceivers. They're no XBees, work with 250mW Transmission Power,
but operate at 868MHz, not 900. Since the Plane I use is rather small
and lightweight, no way to separate the Gyros from the Transceiver by
18". So, indeed I ended up using copper tape, but only to isolate the
Transceiver, wich did help. It's not entirely quiet yet as the antenna
is, well, say custom and way from perfect, but it certainly helped.

However, when I read your messages, it seems as if you would have a
lot of interference to the point that the plane is becoming unstable?
In my case, altough you hear the Servos stuttering, it's not anywhere
near the point where it could destabilize the plane, even without
copper.

FYI, here's a linkt to them:
http://lairdtech.thomasnet.com/viewitems/868mhz-modules/ac4868-transceivers?&plpver=10&forward=1

However, reception is great, I can send the plane quite some distance
away and still upload new waypoints and receive Telemetry.

So, yeah, just wanted to share my two cents ^^

Regards,
Charles

[jlchapman]

So did anyone ever get the XBee Pro 900 transceivers to work with the
red board? What was the solution, distance? Just want to know before
I invest in them.

> > Rusty- Hide quoted text -
>
> - Show quoted text -

[Russell Duffy]

I haven't done it yet, but mostly just because I haven't gotten around to
setting up telemetry. I think distance will be easy enough to manage for
the XBee Pro 900, particularly if you get the version with the ufl antenna
connector. That will give you more options for remotely locating the
antenna.

FWIW, I worked on the interference problem some this week, but had my usual
luck with RF (I hate RF). I was trying to filter the RF out of the power
for the gyros, but the caps I tried were way off, and did nothing. I'll
order more Monday, and take another shot at it.

I'm able to recreate this with a single gyro breakout board on the bench, so
it's definitely the gyro, and the UDB is largely out of the picture. I
tried the same test with a completely different gyro from a UAVP quad, and
it does exactly the same thing. Funny though, because I've used 500mw
900MHz video on the UAVP on many occasions. The antenna was just a few
inches from the board too, so they must somehow filter it out. No idea how,
unless it's in software though.

Video and XBees don't affect the MK quads either, and I intentionally
blasted one with RF to see if I could even see some change on the MK
software utility. Nope, nada. As with all things RF (I hate RF), it's a
mystery.

Rusty

[Adam Barrow]

On a related note, I'd actually be interested in (detailed) accounts of how people got the XBee Pro 900 transceivers to work. The pair I bought from Sparkfun (http://www.sparkfun.com/commerce/product_info.php?products_id=9099, http://www.sparkfun.com/commerce/product_info.php?products_id=9097, and two of http://www.sparkfun.com/commerce/product_info.php?products_id=9132) still won't even transmit a byte between them (anything I send is output as a null, 0x00 on the other transceiver).

After looking on both the Sparkfun and Digi forums, I've opened a support ticket with Digi, but so far even their troubleshooting advise hasn't worked. I would begin to suspect the Sparkfun adapter boards, except they work just fine with a pair of the 2.4GHz 'series 2.5' transceivers.

I'm not trying to discourage anyone from investing in these, I think it should work fine. I'm just hoping for some good advise as to something I might have missed (or mistook) that will get the transceivers working.

Adam Barrow

[Russell Duffy]

Hi Adam,

Those should work right out of the box, just as advertised. In fact, I've
done it many times. I usually recommend two of the USB explorers as your
first two adapters, because they're so easy to connect to the computer for
testing. You can use the XCTU program to run a test between the two
modules, to confirm the connection.

http://www.sparkfun.com/commerce/product_info.php?products_id=8687

Of course you can do the same thing with the "regulated explorer", but it's
more work to connect them. These are better for the airborne units though,
and cheaper without the FTDI stuff.

Now if you've read this far, I'll tell you what could likely be causing the
problem. I could name several people who've had problems getting the
"regulated" explorer to work, including me. In at least a couple of the
cases, the "USB" version would work fine, but the "regulated" version would
not. As it turns out, Sparkfun put a diode in the DIN line on the
"regulated" version, but not on the "USB" version. Sure enough, jumpering
it out cures the problem. Best I can figure, the voltage drop across the
diode must be enough to cause it to not be able to communicate. I told
Sparkfun about this, but they haven't received other complaints, and don't
feel like it's a problem.

My advice would be to at least temporarily jumper across the diode in the
picture, and see if that works. I bet it will.

Cheers,
Rusty

[Adam Barrow]

Rusty,
thanks for the tip! I'm working now, but I'll see if I can't russtle up a soldering iron somehow. I assume that since this is on the DIN line I only need to modify the board that I'm transmitting from to confirm this? I'd purchased four of the regulated explorers and I'm more than happy to 'risk' one of them for this purpose. If it does make a difference, I'm also happy to report that back to Sparkfun (so you aren't the "only one"). Either way, I'll report back here after I test it.

Out of curiosity, do you know if anyone is running these at 3.3v for telemetry? Seems to me that would not only reduce components (weight and bulk) but also reduce power consumption.

Thanks,
Adam Barrow

[Russell Duffy]

Hi Adam,

Correct that it would only be required on the transmitting unit. I'm not
quite sure I understand the 3.3V question though. The XBee is a 3.3V
device, so if you have that available, by all means use it. The regulator
is just there in case you need it. Hopefully I didn't miss the point of the
question?

Rusty


-----Original Message-----
From: Adam Barrow [mailto:adam....@gmail.com]
Sent: Saturday, December 05, 2009 9:53 PM
To: uavde...@googlegroups.com
Subject: Re: XBee transmissions causing servo glitching

[Adam Barrow]

From what I've read (and my assumptions) people are using the Sparkfun XBee explorer regulated board to connect the XBee modules to the UDB. That is, in effect, regulating the 3.3V XBee to operate with 5V circuits (in this case the UDB). Since the UDB does already have a 3.3V rail (for the gyros) I was thinking about running the XBee module off that. With the 'pro' module (and I think the series 2.5 as well, but I'm not sure) the inputs are 5V tolerant so I think they would work with the dsPic even though it's running at 5v. Then again, I'm much better at software than hardware, so I might be missing something, or even making some incredible assumptions.

 

Adam Barrow

[Russell Duffy]

Hi Adam,

 

The main concern I’d have is the current capacity of the 3.3V regulator on the UDB.  The schematic isn’t really that complete, and doesn’t give the actual component, so we’d have to look at a board to figure out what it is, then check the datasheet.  The XBee module pulls about 180 ma, which is actually higher than the 150ma “guaranteed” rating of the regulator on the Sparkfun explorer board.  I’ve never had a problem using the Sparkfun regulator, so clearly it’s capable of a bit more than 150ma. 

 

The secondary concern (pretty close second) would be that the XBee’s large, rapid current draws would affect the 3.3V supply on the UDB, and make it vary.  Since it’s used for gyros, ACC sensors, and the CPU, that might not be a good idea.   

 

Rusty

[Adam Barrow]

Rusty,

 those are very good reasons not to. Considering how light the regulated explorer is anyways, it's probably just not worth the risk.

Your point about the rapid (and relatively large) current draws on the XBee module does bring up an interesting concern, even at 5v: Can the regulator on the UDB be safely used to power it? The UDB 5v regulator is already handling everything on the UDB board (the 3v regulator's input comes from the 5v regulator's output on the schematic) as well as the GPS. I can't find any specifications on what the part is, or it's power capacity. 

Since I'm currently using one of Dedadz's (Tom's) oil pan boards (unmodified - I think I will yank the Vcc pin but wanted to look at the three options Tom posted first) with a 5V ESC I'll probably just power the XBee from there for now. I can see, however, this becoming a concern for people who plan to add extras onto the UDB (including XBee modules).

Adam Barrow

[Peter Hollands]

Adam,

Your point about running the Xbee Pro 2.5 of off the regulated 5V pin that is next to the
spare TX and RX is a good one.

I've been using that (and connecting it to the Xbee explorer regulated) for some time - and in practice it has worked over many flights.

But in a dimly lit room, and with the green led of the UDB showing "radio on", is is possible
to see a faint flicker of the green light where the LED lights up the EPP foam of my twinstar every time the Xbee transmits. There is definitely a voltage drop occurring in sync with the transmissions. I can see the transmitted information arriving on my computer screen at the same time as the flicker in the green LED. (you can only see this in the ambient green light
shining on the elapor foam, not be looking directly at the LED).

Putting my cheap multimeter on the regulated 5V ouput pin without the Xbee attached I see the voltage varying rapidly each second between 4.68 and 4.74 volts.

Then measuring with the Xbee connected and transmitting I see 4.58 to 4.67 volts varying over each second.

The main power supply of the aircaft is rock solid over this time at 4.86 volts. The main power comes from a switching power supply that can deliver 4A. (I have installed a sail
winch servo for my camera turret).

So it look like I've been lucky. I've not had any discernible problems flying like this, but it would seem I should move my power supply for the Xbee Explorer Regulated to be directly from the main power supply of the aircraft.

Pete

[Adam Barrow]

Rusty,
thanks for the excellent suggestion! As soon as I put on the jumper, not only could the XCTU software read and write to the module, but the transmissions started working too! I've posted a comment to that effect on the Sparkfun product page, Sparkfun forum (where I'd asked for help and others were having similar issues -- not sure if this will help them or not) and lastly updated the support ticket from Digi).

I'm not sure if I'll trust these explorers with the 2.4GHz 'series 2.5' modules (I don't understand the intended purpose of the diode) so I plan to dedicate these explorer modules to the XBee Pro 900MHz (which probably makes sense for other reasons too).

In light of the fact that I see many UDB users being interested in using an XBee setup for wireless telemetry / ground stations, does it make sense to put some of this on a page in the Wiki? If we think it's worth doing, I'm even willing to write one up (but I'll be happy if someone else wants to as well).

Thanks again Rusty, I was really bummed about the XBees 'not working'.

Regards,
Adam Barrow

> <diode problem.jpg>

[ben levitt]

This morning was my first test flight with a working XBee Pro 900
connection to the ground, and without the interference I was seeing
before. (Woo!)

Here's what I'm doing to make it work:

- I had to configure my XBee radios to use the XBP09-DM (DigiMesh)
firmware, or else I only ever received null / 0x00 bytes.

- I connect the XBee power and ground directly to a spare channel on
the receiver, so power for the XBee does not run through the UDB.

- I connect the Rx and Tx lines from the board to the XBee, each
through a 560 Ohm resistor. (I think I was getting some current
leaking back through these lines and causing problems on the board.)

- I'm now using a 4 conducter, shielded cable to connect the XBee to
the board and receiver, and for the ~2-3 inch stretches of wire at the
ends outside of the shielding, I twisted the power and ground wires
tightly around each other, twisted-pair-style.

Now it works great!

(I'd send a link to my flight path from today, but unfortunately my
Serial Terminal program is dumb, and decided that when I clicked the
big save button on the screen full of text, it would just save a text
file with the serial port configuration. So I lost my flight data
when I quit.)

Ben

[ben levitt]

Oh right, I forgot to mention:

I'm using a usb explorer to connect my XBee on the ground to my
laptop, and I'm using an explorer regulated to connect the XBee to the
plane. Both are unmodified.

Ben

[prem...@nycap.rr.com]

Ben,

That is great news. Very nice.

It sounds like you have found a good way to hook up the XBee Pro 900.
Wonderful.

[Adam Barrow]

Ben,

 Can you 'read' your module configuration using the XTCU tool and save it for me? I was receiving the NULL (0x00) issue until I took Rusty's advice to short out the diode on the XBee Explorer Regulated boards. I don't have a USB explorer, so I couldn't even get the firmware to reload. I'm curious, however, if I flash one of my modules using a modified regulated board to your config if it will then work in an unmodified board.

 

I have my setup on the plane (a Multiplex Easy Star) and the ground testing looks promising. Since I'm using a Dedadz oil pan, the XBee is being powered from the ESC (like yours). I didn't, however, do anything to shield the connector cable (approx 18" of four conductor ribbon cable) and didn't observe any issues with interference. In fact, the only way I could observe any interference was to touch the XBee module antenna (wire) up to a gyro. If the weather does clear up tomorrow, I'll perform a test flight and let you know.

 

I'm really anxious to get the telemetry working, since I can't explain what the plane is doing in waypoint mode (I have a hunch that the EM406 just isn't accurate enough for what I want to do) by watching it from the ground.

 

Adam Barrow

[ben levitt]

Here are my module configurations for ground and plane. (You'll need
to have the correct firmware installed before you can apply my
configurations.)

Ben

[Riccardo Kuebler]

Hi,

if that could be of general interest I just had the same feeding problem.

What I noticed is that with SF regulated unmodified adapter 2.4GHz Xbee works well and 900MHz only output points.

I tryied this adapter from Adafruit and it works well with both. It is rated 250mAh. Probabily is for that that Jordi recommend this unit for Ardupilot telemetry.

Xbee were flashed with XBP09-DM, as recommended by Ben.

I verified the gyro interference too and noticed that my homemade antenna only cause important glitch when at less than 7-8 cm. The worst case is if antenna is put at 45° between gyros. At 90° it is only noticeable.

Anyway coaxial antenna cable is 46cm long. Antenna is then in the rear of the plane far away from UDB and RC rx.

Best regards,

Ric

2009/12/7 ben levitt <ben...@gmail.com>

[John McClelland]

Ric

 

I didn't quite understand what you were saying in the second sentence referring to the 2.4 GHz and 900 MHz units.  Was there a problem with the 900 MHz?

 

Best,

John

[Riccardo Kuebler]

John,

yes, you will find a very interesting discussion about this in the precedent posts of this thread.
It seems that the SF regulated board for Xbee has problems feeding Xbee. It is rated for 150mAh.
Adafruit is rated 250mAh.

Strange is that Xbee 2.4GHz transmission consumption is rated 215mAh and 900MHz is 210mAh.
Transmit mode is different: 2.4GHz is DSSS and 900MHz is FHSS.
Could it be that FHSS needed transmission current is higher than DSSS and its real consumption higher then too?

Cheers,

Ric

2010/2/1 John McClelland <mcclell...@gmail.com>

[Andres Pena]

Hello. Im new to this group. I am also new to the red UDB and im in
the experimental phase. Today i was setting up my GPS (EM406) and xbee
(znet 2.5 pro). My main goal was to be able to obtain an NMEA output
off the MatrixPilot firmware but i dont seem to find where in the code
i can obtain the NMEA. I need to keep the UDB coordinate system but i
also want to be able to output the NMEA. Does anyone have a clue on
where i can locate that? i checked the GPS parse program but didnt see
it.

I also thought on connecting the xbee directly to the GPS's tx pin,
working at 4800 baud, 8bits, non parity, 1stop bit. i do get an output
and i can see some data off the xbee in my pc but the data I see is
all BS, doesnt make any sense. Any ideas? i tried all baud rates.
anyways i know my GPS. if im not wrong im supposed to obtain pure NMEA
off the GPS...

I would really appreciate your help... if you need more information
let me know! Thanks!!

On Feb 1, 6:25 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:
> John,
>
> yes, you will find a very interesting discussion about this in the precedent
> posts of this thread.
> It seems that the SF regulated board for Xbee has problems feeding Xbee. It
> is rated for 150mAh.
> Adafruit is rated 250mAh.
>
> Strange is that Xbee 2.4GHz transmission consumption is rated 215mAh and
> 900MHz is 210mAh.
> Transmit mode is different: 2.4GHz is DSSS and 900MHz is FHSS.
> Could it be that FHSS needed transmission current is higher than DSSS and
> its real consumption higher then too?
>
> Cheers,
>
> Ric
>

> 2010/2/1 John McClelland <mcclelland.j...@gmail.com>

>
>
>
> >  Ric
>
> > I didn't quite understand what you were saying in the second sentence
> > referring to the 2.4 GHz and 900 MHz units.  Was there a problem with the
> > 900 MHz?
>
> > Best,
> > John
>
> > ----- Original Message -----

> > *From:* Riccardo Kuebler <kueb...@ticino.com>
> > *To:* uavde...@googlegroups.com
> > *Sent:* Monday, February 01, 2010 12:45 PM
> > *Subject:* Re: XBee transmissions causing servo glitching

>
> > Hi,
>
> > if that could be of general interest I just had the same feeding problem.
>
> > What I noticed is that with SF regulated unmodified adapter 2.4GHz Xbee
> > works well and 900MHz only output points.
>

> > I tryied this<http://www.adafruit.com/index.php?main_page=product_info&cPath=29&pro...>adapter from Adafruit and it works well with both. It is rated 250mAh.

> > Probabily is for that that Jordi recommend this unit for Ardupilot
> > telemetry.
>
> > Xbee were flashed with XBP09-DM, as recommended by Ben.
>
> > I verified the gyro interference too and noticed that my homemade antenna
> > only cause important glitch when at less than 7-8 cm. The worst case is if
> > antenna is put at 45° between gyros. At 90° it is only noticeable.
>
> > Anyway coaxial antenna cable is 46cm long. Antenna is then in the rear of
> > the plane far away from UDB and RC rx.
>
> > Best regards,
>
> > Ric
>
> > 2009/12/7 ben levitt <ben...@gmail.com>
>
> >> Here are my module configurations for ground and plane.  (You'll need
> >> to have the correct firmware installed before you can apply my
> >> configurations.)
>
> >> Ben
>

> >> On Sun, Dec 6, 2009 at 12:48 PM, Adam Barrow <adam.bar...@gmail.com>

> >> >> > On Sun, Dec 6, 2009 at 1:45 AM, Adam Barrow <adam.bar...@gmail.com>

> ...
>
> read more »

[William Premerlani]

Hi Andres,

 

For efficiency, and to get access to more information, the UDB interfaces with the EM406 in binary mode at 19,200 baud. So, if you connect to the GPS pin, even if you had the baud correct, you would see what would appear to be gibberish.

 

However, if you want to see useful information in readable form, select a value for SERIAL_OUTPUT_FORMAT in the options.h file, and take a look at the file serialIO.c to see what will get printed out for each options. There is a "UDB" format, an Ardustation format, and debugging format. In each case, there is a wealth of information that will appear on the spare serial port, at 19,200 baud. This is the way that is used to connect your XBee to obtain telemetry.

 

The default value of SERIAL_OUTPUT_FORMAT is "none", so unless you select one of the options, nothing will come out on the serial port.

 

For more information, if you have not already done it, take a look at the instructions under the Wiki tab of the UDB project website.

 

Bill