paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Non-blocking module code


From: Gareth Roberts
Subject: Re: [Paparazzi-devel] Non-blocking module code
Date: Wed, 04 Jul 2012 10:22:29 +0100
User-agent: Opera Mail/12.00 (Linux)

Hi Limaiem & Reto,

in practical way you use the procedure output I mean xbee_reset_ticks to push ananalog output to high during a certainperiod of time to reset the xbee modul ?

I tried this approach initially but found a couple of issues.
The XBee reset pin is open drain, which means it needs grounding to reset. The only pins capable of doing this without additional components are SDA & SCL from I2C-1, as per Jeremies solution.
Unfortunately, on my Umarim I2C-1 is used to drive the IMU.
I then tried using a transistor driven from the usual LED_ macros. Unfortunately, my particular XBees fail to come back up after reset if you are transmitting to them about 25% of the time.

AT commands

As Reto says, I turned to the gluonpilot solution of using AT commands to reset the xbee.
The disadvantages are:
- There is a 2 second stop in telemetry inherent in the reset process

The advantages:
- It should work with any paparazzi board
- It's a software only modification

For my use case, a 2 second interruption in telemetry every 5 minutes is not an issue.

How it works:
Thanks to the cunning mind of Stephen Dwyer, most messages are handled in a fairly elegant manner. You need to have a modified telemetry section which includes a <mode name="blank"></mode> in both Ap and Fbw sections. The current telemetry mode is switched over to the blank telemetry, and then restored after reset.

However, this doesn't stop all telemetry. My branch also contains modifications to main_ap.c, consisting of guard statements which check a disable_telemetry flag around a few hardcoded telemetry calls. I've also modified datalink.c to support this flag. When this flag is set to true, all hardcoded telemetry calls should stop. You need to define <define name="ALLOW_TELEMETRY_DISABLE" /> in the firmware section of your airframe file to enable these guards.

Whilst I can do a github pull request, there may well be a more elegant solution to the hardcoded calls, so it would be great if one of the experienced developers could comment on this.

Also, whilst I have tested this on the ground for several hours and works quite happily, I haven't yet taken it flying. Therefore, I wouldn't recommend using this module in air for now - I posted it for development feedback, not as a finished product.

Cheers,
Gareth



reply via email to

[Prev in Thread] Current Thread [Next in Thread]