Replies to This Discussion

Permalink Reply by William Premerlani on January 30, 2009 at 11:53am

Thomas,
The two options of an external 16MHz crystal and the FRC were chosen to combine with the various PLL options to give a wide range of clock frequencies for several choices for balancing computational speed with power requirements. As I am sure that you know, the power drawn by the CPU increases with crystal frequency. The FRC is not as precise as the 16MHz crystal, but it is precise enough for where it is typically used, namely pulse width generation, A/D sampling rate, and baud rate for communications with the GPS. I have tested with the FRC, it works just fine. If, for some reason you need a precise frequency, the FRC has software selectable adjustment.
For the navigation program that I have been using, I am running with the 16MHz clock without PLL. I measured the CPU loading to be only 2%, so there is still plenty of processing power left even at the slower clock rate. So, I don't think I will ever have to run it at a higher frequency, even when I move to aerobatic algorithms. Also, all of my firmware is written in integer arithmetic. If you decide to use floating point, then you might want to use a higher clock frequency.
best regards,
Bill Premerlani

• ▶ Reply

Permalink Reply by Thomas Roell on January 30, 2009 at 3:08pm

Bill,

Makes sence with the low load. If you add however more complex filtering that might change. IMHO with a 40bit ACC you may avoid floating point anyway.

With the FRC I was surprised to see the 1PPS signal from the GPS not being connected. That would have been a nice way to limit the drift over time. It's kind of a bummer anyway, that you cannot drive the timer/counters off the crystal and other subsystems with the FRC.

Have you tried to experiment with the low-power modes of the MCU ? If the load is so low anway, and activty is only in short bursts, then powering down the whole thing might help even more.

- Thomas

PS: I am really more of a SW fellow; and the chips I deal with are more limited by the 130W power envelope ;-)

• ▶ Reply

Permalink Reply by William Premerlani on January 31, 2009 at 8:37pm

Thomas,

I agree with you that with the 40 bit accumulator of the dsPIC30F4011, I will be able to avoid floating point. The math library furnished by Microchip includes some vector and matrix math routines that take full advantage of the PIC architecture. I believe it is possible to use the UAV v2 with a 16 MHz clock to maintain an updated estimate of the 9 direction cosines between pairs of body and ground axes at a 50 Hz update rate, and still have only a few percent loading on the CPU. I am presently working on the math with Paul Bizard, who is also doing some simulations that show that the algorithm that we plan to use will work quite nicely.

Regarding the FRC, again I want to point out that the FRC is more than adequate for A/D conversion, baud rate generation, and pulse width control. If for some reason you want a clock more accurate than that, you can get it via the GPS communications. One of the GPS messages comes through time stamped, and generates an interrupt as it comes into the CPU, so it could be used to maintain a GPS accurate clock.

I have not experimented with any of the low power modes of the MCU, they would impose a much lower clock rate. The FRC running at 7.5 MHz is about as low as I would recommend. The 16 MHz crystal is the oscillator that I expect most applicatons will use. It is the one I used for my "GentleNav" firmware. With the 16 MHz crystal clock the total load current for CPU, gyros, accelerometers, and GPS is 0.09 amps at 5 volts, or 0.45 watts. With the FRC with 16X PLL running at 120 MHz, the total current to the board is 0.180 amps at 5 volts, or 0.9 watts.

best regards,
Bill Premerlani

• ▶ Reply

Permalink Reply by William Premerlani on February 1, 2009 at 5:24pm

Thomas,
I finally understand what you are getting at. You are concerned about aligning the data streams that are not sampled at the same time. I will give you the short answer and the long answer.

First, the short answer.

The short answer is that with the algorithms that I use, the timing of the GPS information is not critical, it only has to be within 5 seconds accuracy. In fact, it is not necessary for any of the data that I am using to be precisely aligned in time.

The longer version:

1. First, the description of the GPS dynamics is more interesting than I thought. There are separate processes within the GPS computer for measuring location and velocity. Location is calculated just the way you might imagine. However, velocity is based on Doppler shift, and is more accurate. Both signals are apparently filtered internally by the GPS computer. Based on tests that I have run, the actual data that streams out of the GPS takes about 5 seconds to respond to changes in direction or velocity.

2. The algorithm that I am use for my "GentleNav" combines pairs of signals. In each case, I am able to pair a fast signal that drifts with a slow signal that does not drift with what is called a "washout" filter that extracts the best features of both into a signal with fast response and no drift. In the case of the GPS, I combine gyro information with GPS information. It is really the gyro that is controlling the yaw axis, with GPS serving to correct for drift. In that case, I am not so much interested in the transient behavior of the GPS data stream as I am in its average values.

3. I am presently working with Paul Bizard on an "artificial horizon" algorithm that computes direction cosines for a 3D transformation matrix by fusing information from GPS, gyros, and accelerometers.

By the way, in the work that I do for a living, there are several systems that I work on in which data alignment is critical, and there are several techniques that I use to assure that data streams are aligned.

I apologize for not understanding your question at first.

best regards,
Bill

• ▶ Reply

Permalink Reply by William Premerlani on January 30, 2009 at 12:39pm

Thomas,
Here is a shorter answer.
The FRC is precise enough. With PLL options, it can be set for 7.5, 30, 60, or 120MHz.
The external 16MHz clock fills the gap between 7.5 and 30, so there is a choice of FOSC between 7.5 and 120MHz, with each frequency approximately equal to double the next lower frequency. The intention is that you select the frequency that meets your power and processing requirements.
best regards,
Bill Premerlani

• ▶ Reply

Permalink Reply by William Premerlani on February 2, 2009 at 3:01pm

On a related topic, Thomas thought that the source code for the PWM for my GentleNav firmware produced pulses that were 2-4 milliseconds wide instead of 1-2 milliseconds wide. The code is correct, the pulses are between 1-2 milliseconds wide. Here is the explanation:

In the dsPIC30F4011, the duty cycle for PWM is measured in half clock cycles, in effect providing one fractional bit.

• ▶ Reply