[Top][All Lists]
[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