FredericG's blog View Details
Posted by FredericG | May 18, 2007 @ 06:56 AM | 10,608 Views
My current hardware just allows me to detect 2 servo signals and drive one servo, just enough to start experimenting with the rudder-home functionality.
For now, all parameters are hardcoded and I will need to do additional experimenting to get this completely right. The direction to the pilot I have, but driving the rudder from that seems more complicated than it seems. Perhaps I should ask the UAV guys how they do it. One of the problems is the wind: one time it causes overshoot, other times it prevents the plane to reach the optimal direction.

Here I have a small video where you can see it. Ignore the sometimes bad downlink, I still use the standard antenna and I think there is interference from my wlan access point.

Posted by FredericG | May 11, 2007 @ 12:24 PM | 9,648 Views
It's a long time since my last report in my blog....

During the initial test flight I ignored some unusual glitches and it resulted in a crash. I spend some time finding out what the problem was.

After that I have done many successful flights with my FPV plane and my home-brew OSD module.

This is one video that was shot at the BeNeLux meeting in April in Holland, these video's still contain debugging values on the 2nd line: (20 Mb) (80 Mb...)

This is a short video that demonstrates the "north"-indicator that I added:

I am working now on the rudder-home functionality.

Posted by FredericG | Feb 24, 2007 @ 02:07 PM | 9,784 Views
The missing video transmitter / receiver arrived yesterday. In addition my I-Vision goggles arrived. So many new toys at once

Connected camera and transmitter to OSD module and everything works fine!

Regarding the goggles, they seem to dislike the video signal the OSD module generates in full image mode, see At first I panicked a bit, but it seems that everything will behave well in the real application where the background is the camera image.

GPS, the camera and the transmitter all operate on 5V. I all feed them from the voltage regulator on the OSD board. Complete consumption is over 700 mA and the linear regulator is getting real hot. I replaced it with a switching regulator from Dimension Engineering.
Posted by FredericG | Feb 10, 2007 @ 03:55 PM | 9,799 Views
I now have the GPS connected.

It sends GGA, RMC and VTG every second and GSA and GSV every 5 seconds. The GPS comes with a program that allows you to change the GPS settings and configure what messages to send and how often. I did not try that as the default settings are just fine.

In contradiction to what is mentioned in some specifications, I could not find any TTL level signal; the TX swings between -5V and 5V. As I suppose it will be very difficult to get the DS275 for which there is place on the PCB, I soldered a transistor on the extension PCB that converts RS232 levels to TTL, just for reception.

I knew that the SIRFIII receivers are sensible, but, being used to a SIRFII, I am very impressed. Just being in the vicinity of a window is enough to get a fix, and fast !!!

I now take the first GPS data as reference for the pilot, and 0 for altitude. It is clear that I will have to refine that. There seems to be a lot of jitter on the first data.

Posted by FredericG | Feb 04, 2007 @ 02:31 AM | 9,096 Views
I have also made a video of the test I described yesterday:
FPV cockpit. Preview/Test with gpsfeed (1 min 27 sec)

I can't wait to test it in flight. The weather is good in Belgium now but I am still waiting for my RangeVideo downlink...
It is also high time I decide on goggles and order.
Posted by FredericG | Feb 03, 2007 @ 07:18 AM | 9,078 Views
Lots of progress to report !!!

By coincidence I discovered this little free tool:
It is a GPS simulator and can generate NMEA messages on the serial port. It can simulate a track in a form of a circle, square and spiral. This might be useful for testing our systems. It works on Linux and Windows.

I received the PIC with more memory a few days ago and for the first time I could place all code at once in the controller: NMEA parsing, calculations and displaying.

I now test with gpsfeed; a PC generates NMEA messages an simulates that we are describing a path in the form of a square. This goes to the OSD module. The first valid coordinates it gets is considered as the pilot position.

What you see on the picture below is the output of the OSD module. As background image you see the PC screen where gpsfeed runs.

Posted by FredericG | Jan 27, 2007 @ 01:27 PM | 8,727 Views
Most of the code for Phase 1 is now ready. I can only test parts at once as the code does not fit in the 16F628. It will fit nicely in the 16F648 but it did not arrive yet.

I decided to buy this GPS: It remains a bit unclear what levels the NMEA signal will have. I will test with this GPS next week.

The STV5730A allows to shift each individual line in horizontal and vertical directions. I already used that to move the arrow down, closer to the markers. I could also use it to move the arrow horizontally with pixel resolution, not character resolution as I now do.
Posted by FredericG | Jan 24, 2007 @ 01:39 PM | 10,793 Views
I wanted a boxed device and planned ordering the version with the PC interface. By mistake I ordered the version with the keyboard interface. The TX and RX of the PSII connector are directly connected to the PIC uart pins.

RA0, RA1 and RA2 are used for the connection with the OSD chip. Most other pins (apart for RX and TX) are available on the extension pads on the side of the PCB. This allows reflashing without removing the PIC. However, the resistance that pulls the /MCLR high was to low (1K) for the programmer to generate the required tension. After replacing it with 33K, in-circuit programming worked!

I found this sample code designed for the previous version of the board using an old 16F84: After swapping CLK and DATA signals and slowing down the signals, it started working.

As the code was obviously not written with memory footprint in mind, I decided to rewrite the code and only support the features I need.

I hardcoded a screen (meaning that the screen is static) that shows what user-interface I have in mind. On top of the screen there is the altitude speed and direction of the plane. Below on the screen there is the distance to the pilot. The arrow shows the direction to the pilot. Each vertical line represents 45 degrees.

Posted by FredericG | Jan 20, 2007 @ 09:20 AM | 9,120 Views
The code for parsing the NMEA and calculating distance and direction to a waypoint (the pilot) is now ready!

The code was first debugged on a PC and afterwards copy/pasted into a PIC project. A problem I had was that on the PC variables where easily promoted to 32 bit while it was not the case with the PIC compiler. I must say I am very impressed with the SourceBoost IDE. At first I was printf-debugging but than I discovered the simulator/debugger and that helped me a lot.

At first the code was too big to fit but after optimising the code a bit, it worked. There is still room for improvement and the biggest code is written, but for sure, I will have to switch to a PIC with more memory.

For testing I use a GPS for hiking. It has a demo mode in which it simulates traveling a route. I use the wisp628 programmer as pass-trough for interfacing between RS232 and TTL levels. The PIC parses the NMEA messages and calculates the distance and direction to a (still hardcoded) waypoint. The PIC than send the calculated data on its serial point. The message is transformed to RS232 and captured by a PC.

In the meantime the OSD module arrived. I will now start experimenting with that...

Posted by FredericG | Jan 10, 2007 @ 03:25 PM | 8,745 Views
I am waiting for my BlackBox platform. In the meantime I can experiment with a 16F628 on a breadboard

I downloaded a C-compiler ( Setting up (it contains its own IDE) and writing the first application was almost trivial. I wrote some code on a PC for parsing NMEA messages and it functioned right away on the 16F628.

I am now developing code on a PC to calculate bearing and distance between 2 points. First I wrote code using floating-point operations and trigonometric functions. I already eliminated the latter and now try to circumvent the floating-point operations.
Posted by FredericG | Jan 10, 2007 @ 03:19 PM | 8,140 Views
I decided to start my own OSD (On Screen Display) for FPV/RVP (“First Person View/Remote Piloted Vehicle) project and call it “RPV cockpit”. The main purpose is to superimpose GPS and other useful information of the video signal that is being broadcasted.

I was inspired by another project started by AndyOne ( that is composed of BOB4 ( OSD module, a Basic Stamp for interpreting the GPS data and driving the OSD module, 2 PIC controllers and a Garmin GPS with screen and keyboard. This setup could have fitted my needs but I wanted to replace the Basic Stamp with another PIC controller.

Somebody drew my attention to this “BlackBox” platform: it houses a standard OSD chip (STV5730A) and a PIC16F628 ( My idea is now to replace the BOB4 and the Basic Stamp of AndyOne’s project, by this board and replace the PIC16F628 code.

Many people report that wandering off and loosing orientation is an issue with RVP. So in the project of AndyOne, the GPS is configured to constantly calculate the distance and bearing to the pilot. This information is than displayed on the screen. In addition it allows the system to drive the rudder in case radio contact is lost so that the plane automatically flies towards the pilot and control can be regained.

In my project I would like to replace the GPS by a simpler one that just reports the actual...Continue Reading