Replies to This Discussion

Permalink Reply by James Turner on March 8, 2009 at 2:29pm

Has anyone used the RSSI pin on these devices yet? The reason I ask is because if the output of this pin drops whenever these devices require a reset due to this duty cycle problem then I'm thinking I could use this to disable my SSC which should switch the Ardupilot to RTL.

• ▶ Reply

Permalink Reply by Reto on March 8, 2009 at 4:00pm

Hi James. Maybe I am not understanding well, but you would read the RSSI drop to recognize the transmission drop due to duty cycle? I don't think this would do because (if I am right) RSSI is just the RF intensity (proportional to distance and environmental RF conditions) measured between 2 xbees. It wont drop in your plane when the duty cycle threshold is reached.
Easier would be as posted before here to monitor the duty cycle value and decrease transmission throughput to keep it under 10%.
Through AT commands, the present average duty cycle can be read from the device. The temperature of the xbee can be read and monitored too.
I did not try to implement such monitoring for now, but I will sometime.
But maybe your thought was another with RSSI.

• ▶ Reply

Permalink Reply by James Turner on March 9, 2009 at 7:43am

Hi Retro, Your probably right. I think I have misunderstood and assumed that the units simply switch off until reset when the duty cycle has been reached and therefore the RSSI would drop. I have managed to reduce the data flow by using a PIC to strip off all unwanted data from the GPS stream but I'm looking for some way for the receiver(plane) side to determine the difference between no data being transmitted from the base unit because of a link failure and simply no data because there's no servo position changes required. Without this detection I don't think I can get Ardupilot to switch to RTL because the SSC will simply keep it previous values regardless of the link state.

• ▶ Reply

Permalink Reply by Reto on March 9, 2009 at 10:02am

You're right in imagining using the signal strength to engage RTL below a given threshold value. You may monitor the signal strength of the last received data packet with the ATDB command:
"Received Signal Strength. This command reports the signal strength of the last received RF data packet. The value returned as though it is positive although the actual value is negative.
Takes values from 0 to 115."
But I think you may have to be sending/receiving in API transmission mode to use it. I read somewhere that there was some way getting those diagnostic data while remaining in "transparent mode" without hardware modification (reading pins), but I have to find out where! It is this way I would like to achieve. but I am not as far yet.

• ▶ Reply

Permalink Reply by Reto on March 10, 2009 at 1:39pm

If someone wants to read RSSI signals while keeping in transparent mode, read this.
It explains two alternative ways:
1) using the pin 6 on Xbee
2) using only code
I am trying to get into second solution to read RSSI, but also other infos from xbee.

• ▶ Reply

Permalink Reply by James Turner on March 11, 2009 at 2:55pm

Thanks for the link Retro. I read the post and it answered my thoughts about using the RSSI pin. I wanted to only use the pin and hoped it may be an analogue signal level relative to the signal strength which I could read using an ADC. I never thought it might be a PWM signal. I'm wondering if some sort of modified RC switch on the RSSI pin would work as a basic low signal detector.

• ▶ Reply

Permalink Reply by Reto on March 11, 2009 at 3:07pm

You may read the PWM signal in ArduPilot recoding for a free digital INPUT pin and using the pulseIn function to determine the pulse width. This width corresponds to signal strength: pulseIn reference

• ▶ Reply

Permalink Reply by Reto on March 11, 2009 at 3:10pm

By the way, I am not a programmer, but an archaeologist! But that's no reason to rename me "Retro" .-}
But don't worry, I do not take it bad.

• ▶ Reply

Permalink Reply by James Turner on March 11, 2009 at 3:24pm

ooops!! sorry about that. I can't even blame it on the keyboard, just me not reading close enough.

• ▶ Reply

Permalink Reply by Noth666 on March 17, 2009 at 4:46am

I finally got mine, and ran some small tests last night.

I tried 50 bytes, 9600bps, 25mW tx on PC side, 300mW tx on loopback.. With rather poor results until I put my finger on the loopback chip (the PC side was not really warm) to test if it was hot.

3sec max after I put my finger on the chip it started pushing 100% link, and every packet went through :P.

I really think cooling should help them work better than without.

• ▶ Reply

Permalink Reply by James Turner on August 15, 2009 at 10:48am

I know this is an old discussion now but to anyone using it for info I thought I would just add my findings. Cooling them makes a big difference to the run time at higher power levels. I'm running mine at 300mW on both sides @ 9600bps and have attached a small heat sink to the module on the EZ* which is mounted near the tail. The base unit has a larger heat sink and fan. both are cold to the touch and have run for 2 hours today so far dropping only 3 packets. 9600 bps is enough for me but I could not get anywhere near that runtime before cooling them.

• ▶ Reply

Permalink Reply by Reto on August 15, 2009 at 11:54am

Good news, James. Since I use Xbee for pan&tilt I had to shift to the Pro 60mW fro its throughput. But it's good news for later long range use with lesser data in the stream.
Did you experiment range with the 300mW setting yet ?

• ▶ Reply

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• 8
• 9
• Next ›
• Page