This is another catch-up post on my GPS rocket navigation project.

As mentioned in my last post, over the winter of 2010/2011 I got the code working to drive the telemetry radio. I also built a new version of the PCB, “Rev 4.2.1”, the same one I’m flying now and discussed in this post.

April 30 was my first chance to test the new telemetry system in flight I got in 3 flights that day – here is the first, my 4″ “SuperHorizon” rocket on a Skyripper H155PP:

The parachute deployed OK (eliciting some surprise), but there was no obvious steering of the parachute – it just spun around slowly counterclockwise (as seen from the ground).

Other than that, everything including the telemetry system worked fine until a few seconds before landing, when the telemetry stopped abruptly. On recovery, the electronics were completely powered down, and one of the two LiIon cellphone batteries had 4.1 volts on it (a full charge), but the other appeared short – so only 4.1 v was reaching the electronics, not enough to run it.

I didn’t know why the parachute didn’t steer, but I was happy enough that the parachute was deploying and the new hardware and telemetry stuff seemed to be working.

I tried to extract the log data from the PIC32 flash memory via the telemetry system, but there was nothing there. I wasn’t sure why (then) – it might have had something to do with the power system problem.

Since my goal for the day was to acquire navigation experience that I could analyze afterward, I went ahead and flew my 3″ “Thrud” on a Cesaroni H100. Here it is:

It got to 1577 feet AGL. This was just the second flight for the “Rev 4.2.1” hardware, and again it worked fine – this time with no power system problems. It seemed to steer somewhat back toward the launch pad, but the wind was also blowing that way, so it wasn’t so clear at the time if this was just good luck.

Again I had problems extracting the log data via the telemetry system. I was ultimately able to do it by connecting to the physical serial port on the PCB.

I still had time for one more flight. I decided to fly the SuperHorizon again after stealing the batteries from Thrud (since I didn’t trust the batteries that had failed on the first flight).

This time I shortened the forward parachute lines by about 1 inch, hoping to decrease the angle of attack and get a faster forward airspeed for the parachute. The wind was really low so I went with a bigger motor – a Skyripper J144:

As you see, shortening the forward lines resulted in a parachute that didn’t fully inflate. So I won’t do that again.

Again I lost all the logged navigation data from this flight. I did have some info from the telemetry, which showed a very confused navigation algorithm, with no consistent mapping of servo position to turn rate, and no consistent system lag values. Some of this might have been from the poorly-inflated parachute, but it wasn’t a good sign. I was concerned that the swinging of the whole electronics bay (including the GPS) under the parachute was confusing my navigation algorithm – the swings were so large that I imagined the GPS could think it’s heading in the direction of the swing, while the parachute itself was going in a completely different direction. At the time, that was my theory as to why the navigation wasn’t working.

Post-flight analysis

It turned out that cellphone LiIon batteries have an over-current protection circuit, which is supposed to reduce the chance of the battery catching fire in case of too much current draw. On the first flight, the servo loads triggered this circuit in the “short” battery. Once I ripped that circuit board out of the battery, that cell was fine. Lesson learned – I now take the over-current protection circuit board out of all my batteries before flight.

The logging data turned out to have been lost because of a minor bug in the way I was handling buffer overruns in the telemetry software – this was easy to fix once I’d discovered it.

Last winter (2010/2011) I finally got around to writing code that drives the Microchip MRF24J40MB transceiver module on the PCB for my GPS-guided rocket recovery project.

The transceiver module is a very nice little part – it’s an IEEE 802.15.4 (ZigBee) radio that uses the 2.4 GHz ISM band – the same band that WiFi and microwave ovens use. The “-MB” is Microchip’s long-range module – it has the radio, antenna, power amplifier (PA), and low noise amplifier (LNA) all on a surface-mountable board a bit bigger than a postage stamp. It comes pre-approved by the FCC for unlicensed use. And the price is reasonable.

Here’s a pic showing the size:

It outputs 100 mW (20 dBm) and has a receive sensitivity of -102 dBm, so the range is quite good; well over 2500 meters outdoors (line of sight).

Microchip also offers a “-MA” module that’s both smaller and cheaper, but it only outputs 1 mW and doesn’t have the LNA, so it has less range.

It talks to the MCU with a simple 4-wire serial SPI interface; internally it has a lot of registers – you send it SPI commands to read and write the registers.

I’d already included an interface to the module on my PCB layout (posted elsewhere on this site – see here), so now I had to write some code that would talk to the module.

My goal was to get real-time telemetry from the rocket in flight, as well as to be able to send the rocket commands from the ground. I was already logging flight data to the flash memory in the PIC32, but if the rocket isn’t found I can’t get that data out of the PIC. So at a minimum, I wanted to get GPS fixes in flight, so if the rocket is lost I know where to go looking for it.

As well, the ability to send commands to the rocket is useful. With the telemetry system I can arm/disarm the ejection charges from a safe distance, as well as manually force ejection, switch modes, and power down the PCB (to save battery power after a scrub).

Software

IEEE 802.15.4 is the basis of ZigBee, a rather complicated protocol for smart gadgets and appliances to talk to each other wirelessly. Microchip offers source code for the entire ZigBee stack, but I didn’t need anything like that kind of complexity for this application.

Microchip also offers source code for something they call “MiWi P2P”, which is a vastly simplified protocol that implements a small subset of the ZigBee functions (it’s not compatible with ZigBee).

I had a look at the datasheet for the MRF24J40 transceiver chip – it’s 156 intimidating pages long. So I decided to use Microchip’s MiWi P2P source code, thinking that would be an easier solution than figuring out the datasheet and writing my own code.

That was a big mistake, at least for me. The MiWi P2P code has lots of functionality that I didn’t need – it will route messages around a network of peer devices, do store-and-forward for sleeping radios, etc. All I needed was simple point-to-point transmit and receive. So I started to modify the code to simplify things – all that functionality was making the interface to the rest of the system needlessly complicated. In the process of doing that, I found lots and lots of problems and bugs in the MiWi code. I ended up spending several weeks porting and debugging it; by the end I’d rewritten 98% of it (and thrown away a good 85% as useless overhead for my application). I used version 3.1.3, which is no longer the latest, but I don’t think the newer versions are much better.

The MiWi P2P code does work if you treat it as a “black box” and don’t attempt to do anything other than the few example things documented by Microchip. The bugs either aren’t exercised or are worked around for those cases. But if you want to customize or optimize anything at all you quickly run into trouble. It’s a bloated, buggy, poorly written and poorly documented piece of code. (It is well-architected. And it is free.)

In the process of rewriting the MiWi code, I learned how the MRF24J40 hardware works, and how to code to it myself. It turns out that “intimidating” 156 page datasheet isn’t nearly as bad as it first seems – from a software point of view, you only need to read sections 3.2 (Initialization), 3.11 (Reception), and 3.12 (Transmission) – that tells you everything you need to know in less than 10 pages! (It helps to skim over the IEEE 802.15.4 document first to know what to expect – but you don’t have to implement all of it to get simple data transfer working.)

If you’re going to do this yourself my advice is to ignore Microchip’s source code and write directly to the MRF24J40 hardware per the datasheet, unless you really need the whole ZigBee stack. Follow the datasheet’s initialization instructions exactly. Do not even look at Microchip’s application notes – they’ll only add confusion.

If you do that, you can have it running with 2 or 3 days of work (instead of the 2 or 3 weeks I spent). The hardware is excellent and it works like the datasheet says.

[Update January 2012: I’ve posted the source code; see: https://nerdfever.com/?p=1797]

Once I had basic radio I/O working, I implemented a set of commands the rocket would respond to – they’re all simple ASCII strings (think a command-line interface). Here is the list as of this writing:

STATE NAMES (forces rocket software into commanded state)

NONe
SAFe
ARMed
TLAunch (timed launch – used for ground testing)
ASCent
DEScent
GROund
TESt

NOUN ALONE

DUMp (dumps log as hex)

RESET-LOG *
RESET-NAV *
RESET-ALL *
POWER-DOWN *

* must type whole command for these

PARAMETER COMMANDS (noun verb)

(no parameter = report current status)

CHAnnel n (set radio channel)
BUZzer on/off
BEEp on/off
LOWbuz on/off
GPS_enable on/off (GPS power)
DROgue on/off (drogue output)
MAIn on/off (main parachute deployment output)
ST2 on/off (“stage 2” output)
ST3 on/off (“stage 3″output)
RED on/off (LED)
YELLow on/off (LED)
GREen on/off (LED)
VSWbatt_pwr on/off (switched battery power circuit)
VSErvo_pwr on/off (servo power)
STEer / S 0 to 255 (both servos same)
S1 0 to 255 (servo #1)
S2 0 to 255 (servo #2)
UPDates on/off (transmit updates every 40 mS)
LTHreshold  meters (launch detect threshold)

PARAMETERS

<integer> value
ON 1
OFF  0
TOGgle  !<oldValue>

I only have to send the capitalized characters (usually the first 3); the rest are ‘syntactic sugar’ to make it easier for me to remember them.

In addition to responding to the commands, the rocket will also send status information each time the software changes state (for example, when launch is detected and the rocket goes from ARMED to ASCENT) and on each GPS fix and each cycle of the navigation algorithm (for diagnostics/debugging).

Ground station

Now that I had telemetry software in the rocket, I needed a ground station to talk with the rocket.

The ground station consists of a 802.15.4 radio that talks to the rocket, plugged into a netbook computer that acts as a terminal. Here’s a pic of the ground station radio:

Look familiar? It’s pretty much the same PCB that goes in the rocket – this was an earlier spin of the PCB that didn’t work out too well – I’d used a ADP3335 LDO as a voltage regulator, but forgot to put in any heatsink for it. The LDO got too hot for comfort when running of the 7.4v flight battery, but it wasn’t bad when running off the 5v USB from the netbook, so I used the board as the ground station radio. (As you can see, I was experimenting with making the radio module a separate board at the time.)

There are two USB connectors that go to the netbook – one powers the board, the other has a USB-to-serial converter on it, because I still haven’t gotten around to writing a driver for the USB port on the microcontroller side. On the netbook side I’m just running a terminal emulator (PuTTY if you must know) for now – in the future I’m planning to write something that will process the data in real-time to produce plots, etc.

Here’s the netbook, with the radio attached by velcro to the back:

It’s a Samsung N130 running Ubuntu. There’s no particular reason to run Ubuntu instead of Windows (my usual OS) for now, except that Ubuntu seems to be a better-supported Python development environment, and eventually I plan to write some Python code to talk to the rocket in real-time. And it was a good excuse to play around with Ubuntu a little.

One major change I made to the netbook was to replace the standard LCD screen with a Pixel Qi display. Normal (backlit) LCDs are almost impossible to read in direct sunlight – and rocket launches are very often outdoors. I’ve had terrible problems trying to read laptop screens at launches. So I bought the ridiculously overpriced display from Maker SHED ($275 plus shipping for a display to go in a $300 netbook!).

Although I still grumble about the price, the Pixel Qi display is great. It’s a normal color LCD except that, in addition to the backlit mode where it acts like any other LCD display, it has a reflective layer that makes it readable in full sunlight – the more light the better. Some people call this a separate “mode” from when it’s backlit, but there really isn’t a mode – the display is reflective all the time, but you can’t tell unless there is a lot of light.  If there is so much ambient light that it washes out the backlighting (outdoors), you can just turn off the backlight altogether and save the battery power it consumes.  The reflective mode is black-and-white, but that’s fine with me – it’s readable and I love it.

While I had the netbook apart, I swapped out the HDD for an 80 GB SSD – so it runs a little faster now, with no moving parts except the CPU fan.

Universal controller

Lastly, after a few test flights (which I’ll describe in an upcoming post), I decided that I wanted a way to manually steer the parachute, mainly so I could try to analyse what the navigation system was doing with known steering inputs (which didn’t work for reasons I’ll explain later too).

So I built what I call the “universal controller” to steer the parachute:

It’s nothing but a potentiometer and switch.  But, hey, on/off and less/more – what else could you possibly need?  🙂

The pot is connected to an analog input of the microcontroller on the ground station PCB. When the switch is set to ON (switch is attached to a digital input), the position of the pot is read and transmitted as a steering command to the rocket; the steering servo just tracks the position of the knob. When the switch is OFF, the rocket steers itself with the on-board navigation algorithm.

The telemetry system has worked very well, at ranges of well over a mile.

Continuing with my update on my GPS rocket navigation project, in this post I’ll quickly run thru my progress (or lack thereof) in latter half of 2010.

17 July 2010 – Flight #28 – First navigation attempt

Last year I posted a video of flight #28 of 17 July 2010, which was my very first flight with the GPS navigation software running and the steerable parachute.

As I mentioned in my recent post, that flight used a steering baseline of just 2.5 inches, yet the system appeared (from the ground) to be able to steer the parachute OK with that tiny baseline. Here’s the video (again):

As can be seen in the video, the rocket appeared to be steering purposefully, although not in the right direction. So I came away with the idea that (somewhat to my surprise) a tiny 2.5″ baseline was a workable thing.

Below, the red arrow shows the 2.5″ baseline – the distance from the left steering line (kevlar braid) to the right steering line.

Here’s the plot of the flight path (click for the Google Earth KML file):

The navigation didn’t really work at all, but this was my very first attempt and I didn’t expect much; I knew there were a lot of variables in the navigation software that would need tweaking from flight experience. The winds aloft were much higher than expected and the rocket landed way off the field – 40 feet up in a pine tree. It took me 4 days to find it and get it down, but I’ll spare you that sob story.

One thing that came out of the flight was a determination to get the telemetry radio working – if I’d had that on this flight, I’d have had the GPS coordinates of the landing site, and it wouldn’t have taken days of searching to find the rocket.

18 September 2010 – Flights #29 and 30 – Test of piston ejection

The July 17 flight also had a problem with the ejection charge burning the steering control line to the parachute.

To avoid that happening again, I redesigned the rocket to use piston-type ejection, where the electronics bay is the piston. That way, instead of having the ejection charges on the parachute side of the electronics bay (where they can burn the control lines), the charges are on the opposite end of the electronics bay. The charge fires into the space between the altimeter bay and a fixed bulkhead in the body tube. The whole electronics bay slides out, pushing the parachute ahead of it.

Earlier in the year (April), I’d run some ground tests in my backyard to find out how big a BP charge was needed for piston ejection. I’d been using 3 to 4 grams of BP in conventional (non-piston) ejection in my 3″ and 4″ rockets. Here’s a video of the tests with the piston, in my 3″ rocket “Thrud”:

I started with 2.5 grams – I didn’t mean to build a cannon, but it seems I did. I ended up using just 0.5 grams of BP in the 3″ rocket (“Thrud”), and 750 mg in the 4″ rocket (“SuperHorizion”).

Two flights on 18 September tested the new system (without any attempt at navigation); it worked perfectly (and has continued to work great since). I’m sticking with piston ejection!

2 October 2010 – Flight #31 – Bad chute deployment

By October, I’d made a few software tweaks, had the piston ejection working smoothly, and was ready to try again with navigation. Here’s what happened:

The parachute lines were horribly tangled up, which prevented the parachute from inflating.

6 November 2010 – Flight #32 – Another crash

By the November launch I fixed the damage and was ready to try again:

Oof. Again, the parachute lines tangled in flight, resulting in a crash. This time there was no damage (just lucky).

Here are a couple of stills from video, showing what the parachute lines looked like at recovery – all twisted and tangled:

6 November 2010 – Flight #33 – Some navigation! ?

Undeterred by the tangling/twisting problem, I packed the parachute and lines even more carefully and tried again.

Despite the taunts from my long-suffering fellow club members (they’ve seen a lot of my failures), the applause at landing was encouraging, even though I wasn’t sure at the time if the navigation was real or just good luck with the wind.

It was a low altitude flight – just 650 feet AGL on a Cesaroni H133 motor (a very small H), so the navigation system didn’t have a lot of descent time to learn to fly the parachute.

Here is the flight path as plotted in Googe Earth (again, click to download the KML file):

From the ground the parachute appeared to have deployed OK, but on recovery I found, again, tangled lines, but not as bad as in the previous flight. Have a look:

After the flight I had a careful look at the logged navigation data (including the internal state of the navigation algorithm) and decided that the rocket probably had navigated successfully for part of the flight – at least for a few seconds of the short descent. So this was a real milestone.

More importantly, I’d learned a lot. The tangling issue was clearly an ongoing problem, even with the most careful packing.

Looking at the video, I became concerned that another problem might be the swinging of the whole electronics bay (including the GPS) under the long parachute lines. Since the rocket estimates its flight direction based on sucessive GPS fixes, a significant swing could easily confuse the rocket into thinking it’s heading in the direction of the swing, instead of the direction of the parachute’s flight.

Club member Boris Katan – a much more experienced rocketeer – suggested that my parachute lines were much too long. I’d made them long to reduce the impact of the short baseline on the angle that the steering lines reached the parachute, but Boris convinced me to vastly shorten the lines – both to reduce the swing, and also to reduce the chance of tangling.

21 November 2010 – Flight #34 – Last launch of the 2010 season

The next launch on 21 November was the last of the year (here in Boston we get snow soon after that).

With much shorter lines to the parachute, I launched the 3″ “Thrud” rocket again, on an Aerotech H180:

That was bad.

In my earlier flights, I’d been using one of Robert DeHate’s PICO-AD4 altimeters as a backup to my own electronics for deployment. But I’d made some software changes to save battery power on the pad by powering down the servo until launch was detected. Inadvertently, that had also disabled power to the AD4 altimeter.

So as a quick “fix” to provide backup deployment in case the first flashbulb didn’t go, I’d wired two flashbulbs, with 0.5g of BP each, in parallel onto my own apogee ejection output. This was my half-baked ejection redundancy. It seems that 1g of BP going off at once was too much for the kevlar cord retaining the electronics bay/piston.

A lesson I learned late is to avoid using epoxy on Kevlar cords – I’d plugged the hole where the cord went thru a bulkhead with epoxy, but epoxy is stiff and doesn’t let the other fibers in the cord take up strain. So the Kevlar becomes brittle and weak – it ripped right at the end of the epoxy. (Hot glue is a much better solution; it’s flexible so it still allows the different fibers to take up the strain.)

The whole e-bay was ejected from the main body tube, together with the parachute and nose cone. The bottom plate of the e-bay (with the ejection charge holders and power switch) and the tube around it were ripped off (never found that). The wires running to the flashbulbs and power switch were ripped off at the PCB.

As you saw in the video, without the weight of the back end of the rocket, the parachute drifted a long way, bounced off a power line, and landed in the dreaded CMASS swamp.

The only good thing was that my PCB kept running, as it’s designed to turn off only when the power switch is closed (not open).

So that was it for the 2010 season.

I’d had one good flight of the system. That had worked only a little bit. But I got valuable data from the flight, which I was optimistic would enable me to tweak things so they work properly. The tangling problem was clearly serious, but I hoped that the shorter parachute lines and careful attention to packing of the parachute would address that in the new year.

This post continues my update of progress toward a steerable parachute system that automatically returns rockets to the launch pad.

In early July 2010, coding of the navigation software was done – it worked well in the simulation, but as a reality check I built another truck to at least test it on the ground.

I stripped a $15 toy truck down to the chassis and installed an old hobby servo to steer it:

Here’s the sophisticated steering linkage – a bent paper clip:

Then I stuck the CPU board in there with some batteries to run the truck motor:

There was no R/C radio – the system is autonomous and steers itself.

This one wasn’t as robust as the truck I’d tested back in 2006 or so (see my slides) – that was a $80 toy truck, and big enough to run on grass and drag around a whole laptop and lead-acid battery- but I didn’t need the laptop anymore since the navigation was running on the flight hardware. It was good enough for a quick-and-dirty test in a nearby parking lot.

It was a very useful test – I found lots of bugs, as documented in my notes. But, after a mere 6 or 7 tries over the July 4 weekend, it was successfully navigating its way around the parking lot. The road to flight glory seemed open.

It’s been quite a while since I posted an update on my GPS-steered parachute for recovery of rockets. This is is the first in a series of posts where I’ll try to bring things up to date.

(For those who want way-too-much-dry-detail, my Flight Test Notes updated thru August 2011 are here; by the time you read this, there might be a newer version linked from the main project page.)

The bottom line is that, as of this writing (August 2011), it’s not working yet, but I think I’m very close. I seem to have have been sidetracked for a whole year by using a very small baseline (horizontal distance between the left and right parachute control lines) to steer the parachute. My flight #28 in July 2010 seemed to work OK with a tiny baseline (just 2.5 inches), so for the past year all my flights have used small baselines – and none of them have steered very well (altho some worked a little bit). Only in July 2011 did I realize the small baseline was causing most of my problems – the steering lines simply get twisted together, preventing steering.

I’ll get to how I figured that out, and what I plan to do about it, in future posts.

Current hardware – Rev 4.2.1 PCB

Here’s a picture of the hardware I’m flying now – I call it “Rev 4.2.1”:

It’s a slightly-updated version of the Rev 4.1 board I posted earlier:

• A Microchip PIC32 MCU (PIC32MX440, with the USB interface),
• GlobalTop PA6B GPS (updates at up to 10 Hz),
• Microchip MRF24J40MB IEEE 802.15.4 radio transceiver for telemetry,
• Freescale MP3H6115A pressure sensor for the altimeter,
• Some buttons, LEDs, and a piezo beeper,
• A USB port that right now is only used to power the board on the test bench,
• Some MOSFET switches to drive four pyro outputs (on the back side; not visible)
• Logic power is 3.3v from a Microchip TC105 switching DC-DC converter (also on the back side) – this is much more efficient than my old LDO design – the board can now sit on the pad for hours without me worrying about the battery dying.

I layout the board in Eagle PCB and have them made in China by BatchPCB.com, then populate the boards myself by hand with a soldering iron, heat gun, stereo microscope, and patience.

It runs off 6 to 9 volts; normally I use two LiIon cellphone batteries in series (see next pic) or 6 NiMH cells in series.

At this moment I have a very slightly updated version (Rev 4.2.2) out at BatchPCB being made, but I’m aiming for a new version this winter which will, I hope, run off a single LiIon cell (3.6 v) and have a charging circuit on board, so it’ll charge off the USB port.

Also visible in the picture is the back side of the steering servo, and the 808 keychain camera I’ve written about before. This looks upward at the parachute in flight, and has proved extremely useful in diagnosing what is going on with the parachute and steering (see videos linked in the Flight Test Notes).

Note the little glass-bulb thing at the top between the PCB and the camera. This is a magnetic reed switch, and it’s how I turn on the board inside the rocket without making a hole in the rocket for a switch. Unlike a Hall effect sensor, the reed switch doesn’t draw any power at all. I hold a magnet on the outside of the rocket, opposite the reed switch. The switch closes while the magnet is there, which powers up the CPU. As soon as the CPU boots, it pulls up an output line to keep the power on, even after the magnet is removed.

I can turn the power off with the reed switch too (the CPU monitors the switch as an input), but these days I usually power down with a telemetry command – when the CPU gets the command, it drops the same output line and turns itself off.

Electronics sled

Below is a picture of the back side of the e-sled, with the batteries and servo top visible.

A few lessons I learned the hard way:

• Pot wires with hot glue, not epoxy. Potting is important to keep wires from flexing and eventually breaking, but epoxy is brittle – the wire will flex exactly where the epoxy ends. Hot glue dries rubbery, so it allows some gentle flexing but spreads the load out along the wire. It’s easier to remove if you have to, too.

 

• Modify cellphone LiIon cells before using them in another application. Cellphone LiIon cells have a protection circuit – usually a tiny PCB mounted at the connector – which limits charge and discharge current for the battery. Lithium batteries can catch fire (or theoretically even explode) if improperly charged or damaged – these circuits are supposed to prevent some of that, but the circuit can turn off the battery just at the critical moment when you need maximum current from it (it happened). So rip those boards out and connect directly to the cell. (And take proper precautions in general.)

 

• Note the screw terminal connector at the end of the payload bay. This position lets me connect up the ejection charges without having to remove the whole e-sled and use long wires – my next spin of the PCB will mount the screw terminals on the end of the board directly, so I don’ t have to remotely position them this way.

This is post #6 in a series covering the hardware and software design for my work-in-progress GPS-guided rocket recovery project. The main index to the series of posts is here, and an introduction to the project (a PowerPoint presentation) is here.

This is the last post about the source code, it covers the interrupt service routine (ISR) in isr.c.

On any interrupt, PIC instruction execution goes to memory location 0x0008, where int_vector() causes execution of the interrupt service routine (ISR), isr().

Z-80 SPEEDOMETER

On entry to the ISR, macro PUSH_DEBUG_STATE() (in debug.h) stores the current state of the Z-80 speedometer output SPEEDO in variable pushed_debug_state. This will be restored on exit from the ISR by macro POP_DEBUG_STATE. (BTW, the only thing this has to do with a Z-80 is that’s what I’ve been calling this trick since I first did it on a Z-80 project back in the early ’80s…)

Then the ISR raises the SPEEDO output, because regardless of whether the PIC was busy when the interrupt occurred, it is busy during interrupt servicing.

TIMER1 (RTC) RESET

The ISR then checks PIR1bits.TMR1IF to see if the interrupt was caused by Timer1 overflowing, which generates the RTC tick interrupt. The result is recorded in variable timer1_expired.

If Timer1 did overflow, it is reset by reloading it with the value TMR_START, to trigger the next RTC interrupt at the proper time.

Note that the value of TMR_START (calculated in hardware.h) accounts for the 6 Timer1 tick periods of interrupt latency between Timer1 overflowing and the ISR resetting it. A few NOP instructions are executed before resetting Timer1 to round up this time to a whole number of Timer1 ticks. (The number of NOPs needed was found using Microchip’s PIC18 simulator, included in the MPLAB IDE).

Ideally, the first peripheral to be serviced in the ISR would be the UART receive buffer. At 38,400 bps data bytes from the GPS can arrive as little as 260 microseconds apart, making this interrupt much more time-critical than others. But servicing the UART involves enough conditionals that predicting the exact number of CPU cycles becomes complicated, making it difficult to keep the RTC tick interval accurate.

So instead, the Timer1 interrupt is dealt with first, but just the minimum necessary to reset it. Other tasks that will be performed on the RTC interrupt are postponed until after dealing with GPS data in the UART receive buffer.

RECEIVED DATA

While there is data to be read in the UART receive buffer (PIR1bits.RCIF == TRUE), the data is read out of the UART and stored in NMEAbuffer[] for later parsing by CheckForNewGPSFix() in main().

Before each byte is stored in the buffer, I check:

if (RTC - LastUARTrxRTC > GPS_BURST_PERIOD_MS/RTC_INTERRUPT_INTERVAL_MS)

If so, this means that no data has been received from the GPS for longer than one GPS data burst period. Since the time between data bursts (typically 950 mS or so) is longer than the duration of each burst (typically 50 mS), this indicates that this is the first byte of a new burst, and so the current RTC value is saved in global GPSBurstStartRTC. This is logged with the GPS fix data, to indicate the exact time the fix burst started in terms of the RTC.

Next, the current RTC time is stored in LastUARTrxRTC. This will be used byFlushFlashBufferSafe() and BetweenGPSFixesFor() (both in hardware.c) to detrmine if we are current receiving a GPS data burst, and so if writing to Flash memory needs to be postponed.

If the received byte was a comma, it is converted into a zero. This transforms the NEMA-0183 formatted GPS message (a series of comma separated values) into a series of zero-terminated C strings, to make parsing of the data simpler for CheckForNewGPSFix().

If the overrun flag (RCSTAbits.OERR) was set, this indicates that the UART receive data buffer overflowed (was overrun) and one or more bytes of data were lost. This should never happen, and I don’t think it ever does. But just in case I’m wrong (for example if the CPU clock speed were reduced, the UART baud rate increased, or the ISR changed, this could happen), the flag is reset and the entire line of received data in the buffer is discarded – it’s important to avoid parsing corrupted data. (A wrong GPS fix is much more confusing to the navigation algorithm than a missed one.)

RTC SERVICING

Once the UART has been dealt with, the timer1_expired flag, which was set earlier in the ISR, is checked. If the flag is set, this indicates that the ISR needs to service the Timer1 RTC interrupt, regardless of whether or not there was any received UART data to process.

Macro ServiceBeep() (defined in peripherals.h) is called twice in the RTC handling portion of the ISR – here and again at the end. On each call, this inverts the PIEZO output bit (to the piezo buzzer) if the global variable Beep is set. Since the RTC timer runs at 1 kHz (1 mS intervals), this generates a 1 kHz tone whenever Beep is set – this is used, for example, by BeepOutMaxAltitude() which is called in the FULL state.

Servo pulse generation

Servo control pulses. (Image from Seattle Robotics Society, http://www.seattlerobotics.org/guide/servos.html)