Jump to content

Attention: RC-CAM.com will be closing down August 2021.

The RC-Cam.com forum was the very first online community dedicated to the advancement of wireless video cameras on radio controlled (R/C) models. This is now called "FPV" (First Person View). We are proud of the contributions that our members have made to the FPV hobby.

We've seen significant changes over the last twenty years. Initially there were a lot of eager R/C hobbyist that built their own video systems. Allowing these creative individuals to share their work was the purpose of this site. Now the FPV market is flooded with low cost systems; Sadly DiY FPV video projects are now rarely discussed.

RC-CAM.com (main site and forum) will be closing down August 2021. This is being announced now (March 2021) so that everyone has time to download any information that is important to them. After the site is shutdown the information will no longer be available here.

We appreciate every member's involvement with advancing the FPV hobby. It is indeed sad to say goodbye to all our online friends. Be safe and stay healthy.

Recommended Posts

Radiohand, I really think you are onto something good here. I just emailed unav about the possibilities of a new batch of PDC-10's but they are playing hard ball and not at all interested. Seems they just want to sell their expensive PicoPilot to those that have deep pockets and not interested in us normal folks :D

Hopefully Dan's dream of having an affordable, reliable set up will come to pass with your project....keep up the good work!


Link to post
Share on other sites

Hi everyone.

Has any of you flying experience with the RCAP as me? Do you have the Gain or Travel limit trims working?

They are not working on my piece. I have tried Alt Hold of my construction. There are some problems but it looks it will work fine. I have bought and tested PicoPilot and returned it to the producer. I was not able to set it working. The support I got from the producer was nearly nothing. I would have to spend a lot of hours adjusting my plane and the control surfaces to start with it.

Besides the software that enables the route planning was clumsy and not precise.

RCAM, FMA Copilot, Alt Hold, Speed hold will do much better (with their limitations) and will fly any plane. I would need to talk to radiohound about his trims.

Link to post
Share on other sites
Has any of you flying experience with the RCAP as me? Do you have the Gain or Travel limit trims working? They are not working on my piece.

I'm not a user, but can offer some insight. The gain and travel pots are not used with traditional A/D circuits. Instead, they rely on their adjacent caps (C9, C10) to create a variable R-C time constant rather than an analog voltage. Any significant component tolerance issues may mess things up. First thing to check would be the C9 & C10 cap values.

Link to post
Share on other sites

Well as soon as it gets to technical language. English is not my mother tongue. Can you give me more detailed explanation of what you mean. Please do not use abbreviations, as they are difficult to find in a dictionary if they are listed at all.

Why would Mike (creator of RCAP) put the C9 and C10 of the published value there, if they were not supposed to work? I suppose he must have had them checked working.

Would you have any different suggestion?

We are nearly through the Alt hold and Speed hold, working on RCAP to guide a model properly.

Link to post
Share on other sites
Can you give me more detailed explanation of what you mean.

The Gain and Travel variable potentiometers (pots) are not used as analog voltage sources. Instead, they rely on the capacitor attached to them and form a resistor / capacitor (RC) time constant. Rather than read a raw voltage from the Gain or Travel Pot, the PIC microcontroller determines how long it take to charge and discharge the capacitors (labeled as C9 and C10 on the schematic). This special software method does not use the Analog to Digital Converter (A/D) input on the microcontroller.

This technical information is important to recognize since it can affect the way a skilled technician would troubleshoot the problem.

Why would Mike (creator of RCAP) put the C9 and C10 of the published value there, if they were not supposed to work? I suppose he must have had them checked working.

Yes, Mike would specify the correct value that you should use (he designed it). However, I assumed you built the RCAP yourself (Mike offered it as a Do-It-Yourself project). Regardless of who built it, the values of the variable Travel and Gain Pots, and the C9 & C10 capacitors, should be checked to ensure they match Mike's specifiations. If they are the correct value and installed properly, then you will probably need Mike's help to determine the problem.

Link to post
Share on other sites
Hi everyone.

Has any of you flying experience with the RCAP as me? Do you have the Gain or Travel limit trims working?

They are not working on my piece.

Gain and Travel are working for me. I can see the servo travel furthest when the pot is set counter-clockwise, and minimally when the pot is turned clockwise. I can also see the values change coming out the debug port in debug mode (have to program chip in debug, as oposed to using main.hex).

Here is what I get when I am in debug, with autopilot switched on:



!cs=118 gpscs=118



!cs=15 gpscs=15


!Center : 1525

!Position : 805

!Pos in ms : 1705

!Gain : 3

!TrvlMax : 2100

!TrvlMin : 925

!GPS Valid : 1

!Offcourse : 180

!Dir : 0

!Servo Dir : 0

!TrackErr : 000

!Steer : L

!Bearing to dest: 1805

!CMG : 0004

I can change the value of Gain from 1 to 10 with the pot.

I can also change travelmin = 925 and travelmax = 2100 (good amount - probably too much travel for autopilot)

to travelmin = 1523 and travelmax = 1527 (basically no travel)

I can't think why you could not ..... hmm.

Why not try debug to check yours to see if you get the same results. The debug.hex is in the same zip file as the main.hex.

Let us know what you find out.

Edited by radiohound
Link to post
Share on other sites
Well as soon as it gets to technical language. English is not my mother tongue. Can you give me more detailed explanation of what you mean. Please do not use abbreviations, as they are difficult to find in a dictionary if they are listed at all.

Why would Mike (creator of RCAP) put the C9 and C10 of the published value there, if they were not supposed to work? I suppose he must have had them checked working.

Would you have any different suggestion?

We are nearly through the Alt hold and Speed hold, working on RCAP to guide a model properly.

Hi Pista,

Help us understand what you have going on. Can you post a picture of your plane and the setup? I'm interested in your rudder style and size. Also what GPS you're using. We can start working it bit at a time. Can you run the system outside of the plane?


Link to post
Share on other sites


Rcap has its imperfections. Have you read my report about RCAP testing? There would be the answer to most of your questions. I am using Garmin E-Trex, Acrobatic plane with a 2 meters wingspan,

The trouble is not the pots. The trouble is the behavior at the final waypoint, and the servo handling when RCAP is on board. The servo works in jerky movements. Have you noticed?

So far guys, it looks like no one here has actually flown the device on a route that ends with a destination waypoint.

I am going to solve my problems in this order:

1 I will reprogram the chip with a file that radiohound is using (I hope he will send it to me)

2 If this doesn’t help, I will have Radiohound sending me his peace to find out if it works better.

It might be possible that the problems are caused by using a bad file, or wrong components.

The question of the day is:

Can RCAP guide a plane without a cross track error?

We know it can go from a waypoint to a waypoint. If the plane receives strong wind from a side, the flown track would look like a bow. But if RCAP can eliminate the cross track error, it would be a straight line. Can someone answer this?

We need to know from some other person how RCAP did on the route. Built it and fly it and send the report here people.

I am sending a picture of my RCAP

Other pictures regarding the RCAP and SPEED HOLD could be found here:



Link to post
Share on other sites

Hello Pista,

Good to hear from you.

It sounds like your biggest complaint was at final destination waypoint, and the random turns it would make holding there. Some of the random turns could be reduced by using more of a trainer style model. An acrobatic plane is not recommended by the original author. Although you have a large acrobatic plane, this could be part of the problem. It is meant for a trainer, high wing type aircraft. Another help would be to limit the throw of your servo by changing the gain setting and travel (if they were working). This would round out all your autopilot turns though. Random turns doesn't seem like such a large problem, but performing a circumference turn around a waypoint would certainly be ideal.

I have sent you the file I used in testing debug mode, as well as v1.1. Let me know if I should send it again. However, the ones I am using should be exactly the same as the ones provided on the web. I did compile the debug.hex file though. It was compiled for a PIC16F876A.

Yes, actual flying tests are important, and I have not performed this yet, so your opinion is very valuable to me. I need to get a model of mine up and running, and get some good weather on my available days off (which unfortunately are not many).

I have noticed the rudder servo work in jerky movements. If you are talking about when you have autopilot off, this is because the RCAP is pretty busy reading the serial port, and perhaps checks your rudder input signal what I am guessing to be 5 to 7 times a second or so.

If you are talking about it passing a waypoint and going to its next turn, yes, I have seen it turn abruptly after passing a waypoint. Again, I think this is one of the reasons that a trainer type aircraft is recommended. I will have to review the code some more to see if gain has an effect on this. I am unsure. If you do not have trims working, then you cannot limit your throws of the servo. On an acrobatic airplane this would certainly be important.

Again, my code is the original code, so I don't expect it to work any better (or worse) than the original.

If you could perform a test with the debug program in your PIC chip, you could see what results you got for gain, and travel out the debug port of J7. This could tell you whether there is a hardware problem on your board, or whether there may be some type of PIC chip problem.

I think there is room for improvement and I hope to do everything I can to help people impliment new ideas and refine the code.

In the near future, there should be more feedback from recent builders of the kits.

I was looking at your picture, and it looks like you are using different style potentiometers. What is their rating?

As for the question of the day: You stumped me for a bit, but here is my answer. I feel flames coming soon ........

The current code relies on True Course (not heading) and bearing to waypoint. So the RCAP will keep steering your rudder until your true course meets the bearing required to get directly to the waypoint. So im my mind, your plane will fight the cross wind and fly a fairly direct path to your waypoint.


Edited by radiohound
Link to post
Share on other sites


I just got a report from a customer that the pots are not working for them. I will look into this further. It worked for me in debug mode, now I will need to do a compare of the programs, and see what could be happening.

I will look into it futher. If a reprogram is required to get the pots working, I will provide a new programmed chip for free to those that purchassed the RCAP2.


Edited by radiohound
Link to post
Share on other sites

I was the one that reported they didn't work, but I was premature. What I didn't know was the code isn't looking at those pots every time around. It only checks them right after the unit has been enabled. I was trying to adjust then on the move and see the throw decrease and when it didn't work, that’s what I reported. Radiohound told me about only being read during enabling so I did that and it worked then.

I have a lot of experience with the PDC-10 so am making comparisons. So far it’s a little different alright. I’m still working on it. I don’t have it dialed in yet and that’s a shame. The weather is perfect for flying this weekend but I won’t have it in the air yet.


Link to post
Share on other sites


Good looking project Pista. I have a RCAP and am beginning testing on it now. I don't know what the erratic behavior at the last waypoint would be caused by. Depending on what it is, it might be normal. Let’s make some points for everyone working with these units here.

Firstly, I have a lot of experience with the PDC-10. I am anxious to see how the RCAP functions to take over for the retired UNAV product.

These devices are typically designed to manage flight with dynamically stable airframes. If your aircraft is an aerobatic one it does not likely have a lot of dynamic stability. It looks like the plane in your picture on your site does have a co-pilot on so that will certainly manage the pitch and roll for you. The bigger issue of course has three elements involved. 1. How fast your plane fly's coupled with 2. How much Yaw authority you have in an acrobatic plane coupled finally with 3. How often you get control updates from the GPS to the RCAP.

Turn rates in aircraft, and also UAV's, should be limited to a max rate of 20 degrees per second as a good starting point. Trainer aircraft with small rudders can achieve this quite easily. This means a painfully slow 4.5 seconds just to turn 90 degrees. If you have a fast yaw rate, with a GPS that only refreshes the rudder signal once a second it can be radical in movement. It will wag or zig zag.

As far as the behavior at waypoint, this sounds normal. It might go left or it might go right. That’s not a product of the RCAP device but is a product of the GPS and where it is in relation to the waypoint as it passes through it. You can observe the same thing by walking with your GPS through a waypoint. There is a small error in position information. Maybe a few meters. There is also wind and aircraft dynamics where it might pass to one side or the other of that way point by a small margin. The arrow on the GPS will suddenly swing around to point behind. Not usually exactly 180 degrees. If it is 179 degrees to the right, the plane will turn right. If it’s 179 degrees to the left, the plane will go left. The plane will not go into a left or right turn by programming code located in the PIC chip and stay that way. It will "loiter" based on GPS heading information and the plane making left and right turns in many possible combinations is normal.

As far as cutting through the way point and first going one way, then the other, is this consistent? Does it always do that? If the above theory about too much rudder and yaw is indeed the case, it is natural to see that at times. You can be approaching the waypoint but have it slightly off one side of your track. In one second you decode a GPS string that tells you to turn that way. The plane cranks over a lot due to large rudder motion and actually passes the waypoint now on the other side of the plane. A second later the GPS outputs the next string and swings the rudder opposite direction and causes the abrupt "wag" turn you describe.

Anyway, the fact that it’s an aerobatic plane and your description both lead me to speculate there is too much rudder authority. I don’t know this but only suspect it.

That is the same symptom that would show up in the PDC-10 if you set it up like described.

Do you ever have any situations occur where your red LED comes on and stays on?

How many waypoints and at what range between them have you flown the plane?

Thanks Pista


Edited by kd7ost
Link to post
Share on other sites


Thanks a lot for the replies.

The reason why I chose this plane is as it is fast, big, can carry some payload and a lot of fuel.

Copilot handles it very well, even the rudder driven by RCAP is fine. I shortened the linkages and it is fine now. It flies 50 - 70 Mph. I am a licensed pilot. I fly ultra light planes. When all is ready I will follow the model plane on a route by a real plane. The model must be fast, otherwise I could not do it. It might happen, that when it arrives at the final point, it is so fast, that the reaction to the rudder takes some time, and before it actually starts turning, the GPS decides the opposite direction of the turn. Well I have to admit this doesn’t happen always, but often. If you leave the plane holding at the final point for some time – let’s say 10 minutes, the event will come and the plane disappears in left and right half turns. I do not know what would happen if I let it go. Maybe it would return back after having flown some distance. I didn’t have the nerves to allow the plane get away. I had the nerves to let it go pretty far from the waypoint (in the half turns) It might have been 0.5 mile distance. It didn’t appear that it would come back. It would be good to add some software specifying the holding patterns.

Do I understand that the pots are supposed to work only when the Rcap is being enabled? And then it is not possible to affect the rudder servo movement by them?

I must try this.

Dan, the GPS sends data to RCAP once per 2 seconds

I have flown 5 waypoints beyond the visual range of a pilot. Not much, but enough to see it works.

I am not sure about the led, but I have interesting story when due to vibrations the GPS batteries lost contact in the GPS case. Very dangerous, once the plane is on its way. Everyone prevent this to happen.

Walter, give me some time to have a look at your technical questions.

That is my friend’s part.

Link to post
Share on other sites


I flew a Kadet Senior using the same basic setup that you are using, Copilot, RCAP, and eTrex GPS handheld. I got two sucessfull flights before I had to pack it up for shipment to Panama'.

I notice that in your setup that you have the eTrex 90 degrees to the longitudenal axis of the aircraft. I aligned the eTrex up with the longitudenal axis in my installation, and pictures that I have seen of other installations do the same. I have not flown the system since arriving in Panama so I can not give any further comments.

Nice aircraft.


Edited by joekadet
Link to post
Share on other sites

Both of my flights were as follows:

1. Turn on eTrex and acquire satellites and set one waypoint to that of the flying field.

2. Set eTrex to GOTO that waypoint.

3. Deactivate the RCAP on the Transmitter.

4. Activate the Copilot

5. Take aircraft off and fly to a point some distance from the field- the aircraft was still visiable but very small and hard to see.

6. Activate the RCAP. The aircraft made a lazy turn to the left and began to fly back to the field. Once that it arrived to the field it passed over and flew away and began a lazy turn to the left again. Each time it returned to the field it would pass over and start a turn to come back. The turn was not always to the left. My aircraft is very stable and makes flat turns on rudder. It continued this pattern until I deactivated the RCAP.

The first time I flew the system I was apperhensive because it was not set to an agressive setting and the response of the aircraft was slow. The second flight was a little better because I increased the gain a little on the Copilot as well as the RCAP.

From what I have observed on this forum all of you are way past my level of expertise.

I plan on using the RCAP as a failsafe return to base type system.

Link to post
Share on other sites
Once it gets to the last waypoint, it starts holding there. As the intelligence of the RCAP relies on the GPS receiver, it would not hold in right or left patterns, but it would hold in random patterns. Typical example is: 3 right patterns, then two left ones then 1 right and so on.

The RCAP behaves OK during navigating on a route. It has only the mentioned problem when it overlies home waypoint and the waypoint stays exactly180 degrees behind it.

Do you have the same experience? If not what GPS are you using and how often does the position data refreshes?

Althought this is a very old thread I thought I would reply.

I would guess that if you lowered the turn rate you would have better result on that last waypoint. My plane pretty much keeps flying a figure eight when it reaches the last waypoint.

Link to post
Share on other sites
  • 5 months later...

Hi everyone.

We have rebuilt the RCAP as I promised. It is now working much better then the original RCAP. The main fault with the old one was that the servo kept the rudder position for only 1/10 of a second. Then the servomotor stayed without power. If the plane was fast, the wind would blow down the rudder in to the center position. That was the trouble. Such a fast plane would not be able to turn. Our GPSNI (GPS Navigation Unit) keeps the rudder under power all the time.

There is another success. We built the speed hold and ALT hold as wel. Our acrobatic plane is able to travel on a predefined route in set altitude. It keeps the alt within +- 10 meters, but we will improve this. Copilot levels the wings.

If there is an interest, we would be able to sell these things. Guys it is such fun. Imagine. You take off the plane, and switch off the transmitter at a constant speed and a determined ALT. then the GPSNI navigates the model to a waypoint lets say 10 miles away. When it gets there, it starts holding over it. Meantime, you drive a car to the place. When you get there, you have a look above and it is there, circling. Just make sure there is enough fuel for it.

Link to post
Share on other sites


The autopilot set up is so easy. The goal is in an idea that struck me one day.

Speed hold.

We measure the difference between static and dynamic pressure. All of you understand how this works. On the plane we have the Pitot tube, from where the two pressures are lead to the engine servo interface (Speed Hold). It is a board where two pressure sensors are integrated along with electronic that tells the engine servo what to do. It works in this way: After take off you fly the model at a requested speed. Then activate the speed hold by a switch from the transmitter. By another proportional channel you adjust the sensitivity and time reaction for the servo. After it has been activated, the plane maintains the set speed and the engine servo operates the accelerator. When the speed hold is activated, you cannot operate the throttle from the transmitter.

The FMA Copilot levels the plane. Here is the golden idea: We put the infrared sensor on a swing. The swing can turn the sensor forward or backward according to what we want from the plane to do (climb or descend). The swing is operated by a servo that takes the decision from ALT HOLD. The elevator servo is operated by the copilot elevator output. By this way we ensure nice climb or descent without any abrupt changes of attitude, even using such an unstable acrobatic plane as we used.

Alt hold

It is a similar thing as the speed hold. It has only one super sensitive pressure sensor and it takes the static reassure from the Pitot tube. You gain some altitude with the model plane, than you activate the Alt Hold and the Copilot. Since than the swing with the sensor on it starts rocking and the elevator does what the copilot says. The result is that the plane maintains the altitude that the plane was at when the ALT HOLD was activated. You can still operate the elevator, but cannot operate the swing servo. If you force the plane down and than loose the controls, it would climb back to the decided altitude. It is really funny. It is possible to change the gain settings of the ALT HOLD by a spare proportional channel.

The plane goes on a route thanks to a GPSNI. It works on the same basis as the RCAP, but without its inefficiencies. I studied RCAP for a long time and believe me it is not a good thing to use on big fast planes. We are not happy with the GPSNI yet as it is not able to solve the crosswind error. We are working on it. At this stage it is capable of flying on a predefined route. We deal with the CTE (cross track error) by setting more waypoints along a longer route. In this way, the plain is not blown away from the wanted track. Basically it navigates very well. I like its behavior when it gets to the last waypoint. It holds there in nice circles without any hesitations. The GPSNI switches on and off by a separate channel. When it is switched on, you cannot operate the rudder control.

All the autopilot channels are predefined on the fail safe. If the radio is switched off, the plane lives own life and starts the programmed route.

This set up is really at the beginning. We need to do more tests before the components are ready for any sale. I expect the prices for the components would be:

Speed hold - 250

Alt hold - 270

GPSNI - 300

Count up the copilot price, the Pitot tube can be made in the workshop.

I am a user of the www.u-nav.com things. The Pico pilot I got from them never worked, the sped hold can not be compared with the one we made and the alt hold integrated in the Pico pilot was useless. I tested their products on an electrical sale plane. What ever I did with the surface linkages or other adjustments, it would not fly the plane at all. I finally returned it back. It cost me a lot of time and money for nothing. I believe them their stuff flies autonomous planes, but it did not fly mine. I need a set up that would fly any plane. The incorporation of the autopilot must be fast.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...