RCAP2 autopilot troubleshooting and testing. [Archive]

Hovertime

Feb 26, 2006, 04:23 PM

RCAP2 manual (http://www.uavs.net/rcap.html) says :

"When the RCAP is first powered, it samples the transmitters rudder stick for neutral position. This is important for the autopilot function. It will not work correctly if you power up the RCAP2 before powering your receiver and transmitter. You will see the LED light for the first 6 or so seconds after you apply power to the RCAP. This is normal. With a GPS receiving good data, and plugged into the RCAP2 while autopilot is selected, you should see the LED blink every 2 seconds or so."

So I powered TX/Rx , GPS. Then turned RCAP on, and led illuminated for 2-3 seconds.
Next I tested it in off mode - and steering servo was controlled by truck's radio. Then I turned RCAP on, and led started blinking. I was driving the truck up and down the street, and it just drove straight line, no GPS steering. Garmin Emap GPS was set on "go to"

Then I stopped checked RCAP - its led was on all the time., or blinking at random time...

By that time I got so cold I had to get back home.
Later on that night I tried to test it using servo, TX and servo tester, and again, all was working as far as it letting TX control the servo while RCAP was off, and servo was sitting still when RCAP was turned on.

Prior to inserting chips I have measured voltage at regulator and it was 4.95V
I have no idea why it is not working??? Can it be caused by twisted serial cable wires?
Help!

kd7ost

Feb 26, 2006, 05:45 PM

hihptsi

Feb 26, 2006, 06:18 PM

Good idea to put this here Hovertime. I sent Radiohound an email with the symptoms. He's putting a setup together to further test. Let's wait on his results. The bad news is it's happening. The good news is that it's happening to at least two of us.

I also feel quite strongly that I never got it to work at all with WAAS enabled. It worked better without it. Maybe the code isn't parsing the strings just right all the time.

It also seemed to be more prevelent if I was moving East and not as much as when moving West. This might have just been coincidental timing though. Once it did come on solid, I couldn't get it to go out unless I power cleared it.

Dan

it most likely is a pic chip that somehow got screwed up..either a problem in programming,or somehow got skewed by a static discharge.
were you careful not to allow any Static discharges to come in contact with it when assembleing as in did you make sure you had no static stored on your fingers and inadvertantly touch the Pic 16f876a when assembling??

Walter (Radiohound) is a good guy no doubt he will take care of you..
i have a Rcap that i received from him and it seems to be working great on ground tests..i still have yet to air test it as im still testing the airframe it will be going in...

i turn on my receiver and radio on first,i make sure RCAP and Copilot is turned off i then arm RCAP and the rest of the electronics.rcap status LED lights for approx 5 sec then shuts off.upon powerup it centers the rudder nicely everytime.when a route is activated in my GEKO201 and i Flip the switch to turn on RCAP the RCAP status LED will light every 1 sec or so and the rudder will follow the route(this is in TEST mode) i have noticed no instances of when the RCAP unit "Freezes". im going to do some further tests to figure out any flaws..

Hovertime:may i ask what city you are in ?if you are not to far from me mabie we could try my RCAP unit on your Rc Truck :)

Thanks
Walter

Hovertime

Feb 26, 2006, 06:46 PM

Location - Chicago ;)
North end of it, major roads close by are route 43 (Harlem) and 19 (Irving park road)

Could you guys post a few pictures of your boards and cable setups? You bought them built or as kits?

kd7ost

Feb 26, 2006, 06:54 PM

i turn on my receiver and radio on first,i make sure RCAP and Copilot is turned off i then arm RCAP and the rest of the electronics.rcap status LED lights for approx 5 sec then shuts off.upon powerup it centers the rudder nicely everytime.when a route is activated in my GEKO201 and i Flip the switch to turn on RCAP the RCAP status LED will light every 1 sec or so and the rudder will follow the route(this is in TEST mode) i have noticed no instances of when the RCAP unit "Freezes". im going to do some further tests to figure out any flaws..
Thanks
Walter

I used two different geko's and an eTrex. They all had the same symptoms. My testing included puting in a waypoint and walking around watching the pointer on my servo direct my course. By and large it did this OK unless the pot's were tweaked to extreme throws. I spent about 4 hours testing, evaluating, swapping GPS units, taking notes, etc. The failure wasn't there all the time. But it showed up if you continued to walk around changing course.

I also set the geko to demo mode and never saw a glitch. But demo mode won't fly the plane back. Only when I put in a valid waypoint and performed a "goto".

How are you testing your's Walter?

Dan

hihptsi

Feb 26, 2006, 11:59 PM

I used two different geko's and an eTrex. They all had the same symptoms. My testing included puting in a waypoint and walking around watching the pointer on my servo direct my course. By and large it did this OK unless the pot's were tweaked to extreme throws. I spent about 4 hours testing, evaluating, swapping GPS units, taking notes, etc. The failure wasn't there all the time. But it showed up if you continued to walk around changing course.

I also set the geko to demo mode and never saw a glitch. But demo mode won't fly the plane back. Only when I put in a valid waypoint and performed a "goto".

How are you testing your's Walter?

Dan

im going to attempt to duplicate your problem tomarrow with my rcap.ill let you know how it goes..

typicalaimster

Feb 27, 2006, 10:41 PM

Hmm I'll order one on Friday and help you guys test it out. Any issues on a cheap Garmin 201? I think I'll end up doing like Hovertime and put it in my RC Truck first.

kd7ost

Feb 27, 2006, 11:06 PM

Any issues on a cheap Garmin 201?

Mine doesn't do well with it but it's not a geko 201 problem. So I think that will be fine. I couldn't get it reliable with a eTrex either.

Dan

Hovertime

Feb 28, 2006, 02:04 AM

OK did some more testing, looks like led is blinking every second, inside the house.

As soon as it gets satellite fix - led goes to fully on, and no guidance.

Using simulated GPS mode I was able to get it to work, pointing to the right direction, but not using real live data. What does it mean???

It "semi-worked" a few times using battery save mode on GPS, which updates GPS data less often, while still sending serial data every second...

Something is not right somewhere...
While looking for some more ideas I have found this old thread (as did some others;))
Might be worth reading it. http://www.rc-cam.com/forum/index.php?showtopic=666

We need more brain power on this guys! :)

Hovertime

Feb 28, 2006, 02:25 AM

I was also wondering why does it have both serial in and serial out wires? Seems that only ground and serial IN would be needed?

typicalaimster

Feb 28, 2006, 08:35 AM

I was also wondering why does it have both serial in and serial out wires? Seems that only ground and serial IN would be needed?

That should be correct. It should be a passive listening device on the wire. If you want to get creative you can add a diode, and another device.

http://www.airborn.com.au/serial/rs232f.gif

This will allow you to listen on two devices. For example the RCAP and a wireless serial downlink.. I was actually running without the 2.2k resisitor just fine in half duplex. At that time I had my OSD and a Maxstream in line.

kd7ost

Feb 28, 2006, 09:51 AM

I was also wondering why does it have both serial in and serial out wires? Seems that only ground and serial IN would be needed?

In this variant, it was set up for user's to continue making code changes and loading it in. There is a "debug" employed to get functional data back out so if you're connected up to a computer you can see how it's performing. I don't know if I like it either. The word is though that these chips have Mike P's original code in it. The board has the option but so far the chip doesn't.

I believe Walter is still making some checks and just got wrapped up.

Dan

Hovertime

Feb 28, 2006, 11:12 AM

I had another idea, while sleeping ;) My unit "works fine" without GPS fix, and goes to led full on and no guiding as soon as GPS data is good.

That means change from "v" to "a" on GPS serial streams. I have noticed that in debug mode it gets simulated (V) data also, and tests OK. Maybe I got debug software on my chip by mistake?
Oh just shooting blind here guys...
Thanks for 2 way serial explanation, I thought you would need to read it off special debug port though....

Hovertime

Mar 01, 2006, 12:41 PM

Another thing I noticed - PIC's used in original RCAP and RCAP2 are different, can this have anything to do with some problems me and others are having?

RCAP : PIC16F876-20/SP
RCAP2: PIC16F876A -I/SP

kd7ost

Mar 01, 2006, 01:15 PM

I got a message from Walter at Scalerobotics. He got a little wrapped up in other pressing business and hasn't had time to further test very much. He did indicate when he went to standard mode with GPS active instead of in demo mode, he was seeing the LED operate in strange ways. It looks like this issue is going to be accross the board.

He's also aware of the chip differences. He indicated the first version of PIC's was becomming obsolete but shouldn't be an issue. It is still being looked in to. Maybe we should get an original PIC chip from any source we can and program it with the code just to see if that's it.

Dan

Mr.RC-CAM

Mar 01, 2006, 02:07 PM

Generally speaking, if the original code used a 16F876, then it should be backwards compatible with the newer 16F876A PIC. The 'A' has a nice comparator and Vref module in it (affects IC pins 2-7), which defaults Off for backwards compatibility. However, it would be a good idea to recompile the original code before using the 'A' (just to be safe). The F876A burn algorithm is different, so be sure to use a programmer that can handle it.

FWIW, the original non-A part is not obsolete. Microchip still supports it and it is in production. Thousands are in stock at DigiKey.

Edit: I looked through my inventory and I have a non-A 16F876-20/SP. I can program it with the RCAP code and send it to someone to try. All I ask is that my out of pocket expenses are covered.

typicalaimster

Mar 01, 2006, 02:16 PM

RCAP : PIC16F876-20/SP
RCAP2: PIC16F876A -I/SP

I'm looking at Jameco Electronic's website. The 20/SP holds 256 ROM words where the I/SP holds 8k ROM words.

And Err what RC-Cam said ;)

Mr.RC-CAM

Mar 01, 2006, 02:26 PM

It would be better to check the actual component data sheets. You should find that both releases have 8K words of code space, 368 bytes of RAM, and 256 bytes of E2Prom.

The major difference is in the silicon fab process used to create the die. While they were at it, Microchip added the comparator/Vref module to the 'A' part. The other features stayed the same. There is a couple of errata sheets on these parts that should be looked at too to see if they impact the compiled code.

Hovertime

Mar 01, 2006, 02:32 PM

Cool, thanks guys for any help with this!:) Any advice about in circuit programming?

Mr.RC-CAM - thanks for the kind offer, I'll take you up on it:) Please send a PM with your Paypal and amount.

Mr.RC-CAM

Mar 01, 2006, 05:37 PM

PM sent about the 16F876 PIC. Cost is strictly what I paid Digi-key, plus a couple dollars to cover PayPal fees and shipping.

Any advice about in circuit programming?Just be sure that the two RCAP pots are NOT set to minimum (max them if you can). It would also be a good idea to change R1 (MCLR pullup) from 4.7K to 15k ohms or so. Other than that, just solder your five ICSP wires to the RCAP board and go at it. Of course your programmer will need to support the PIC that you intend to program.

Hovertime

Mar 01, 2006, 09:13 PM

HM I'm a little confused - do I leave the new R1 in circuit after programming, or is this change needed just to program it and I should switch it back out after?

I'm also not sure where to solder those 5 wires on RCAP...???

Thank you so much for your help and providing me w a chip, I couldn't find one locally today, and ordering from Digikey can be a pain...

Mr.RC-CAM

Mar 01, 2006, 10:10 PM

Just permanently change R1 to the higher value. RCAP will not know the difference.
The five wires are:
+5V: PIC Pin 20
GND: PIC Pin 19
VPP: PIC Pin 1
RB7 DAT: PIC Pin 28
RB6 CLK: PIC Pin 27

If your programmer can supply enough current you won't have to apply external power to the RCAP. But, I have a feeling you will have to use external power or remove the MAX232 IC during programming to reduce current.

The 16F876 will ship in the morning. I hope it helps you solve your problem.

kd7ost

Mar 04, 2006, 01:32 PM

I wonder about GPS units in use. I don't think any of us has heard from Mike P yet about his original code, but if anyone does get a chance to ask him, let’s find out what GPS unit he was using. (Just brainstorming here) There are early GPS units with code that do not function with "Smart route finding". The Garmin GPS12 was suggested back in the early days of the PDC-10 as a unit that could be used and the waypoints would be followed in the sequence they were selected as a route. I have a GPS12 but it's been on loan for a long time to a friend of mine. It occurs to me to get it back from him and connect it up to the RCAP and see if it acts differently. I imagine there could easily be pieces of code information in newer GPS software/processor variants that might not be read by the RCAP PIC because of how it might parse the strings. The eTrex and geko are not very different from each other. But the 12 is a lot different from either of them.

I have an e-mail in to my buddy, As soon as I can get my hands on the 12, I'll run it through the tests and report back here.

Dan

typicalaimster

Mar 04, 2006, 01:50 PM

Blah wait I'm an idiot.. So I'll erase that and start over. I thought that GPS's usually spit out the same NMEA sentence?

Hovertime

Mar 04, 2006, 02:22 PM

I have tried mine with Garmin E-map and Lawrence Ifinder GO .
E-map data stream is not configurable, while Ifinder GO is, so I set it to spit out GPRMC and GPRMB lines only.
While I saved E-map streams on my PC to compare battery sav and regular modes, I don't have Lawrence units streams, but they must be the same.

I'll try to find some time today to try read / reflash PIC ....

Mr.RC-CAM

Mar 04, 2006, 02:30 PM

I thought that GPS's usually spit out the same NMEA sentence?The NMEA protocol is a standard. In the real world, Standards are never really standard. :(

From my GPS code writing experiences, there is a variation in the NMEA sentences used in different GPS products. The order of the sentences, the handling of null or empty fields, the pacing time between sentences, and more, all act together to really ruin your day.

typicalaimster

Mar 04, 2006, 02:30 PM

If you read the source code for the pic main.bas you can see what it is reading in DoB and DoC.. In DoB it is reading field 12 which is bearing to waypoint. In DoC it is reading field 9 which is true course. I'm still reading through the code trying to understand it *scribbles on paper with pen and highlighter*..

DoB = GPRMB
DoC = GPRMC

--Scott

kd7ost

Mar 04, 2006, 10:38 PM

I haven't heard from my friend that has my GPS12 yet. I agree the NMEA output should be standard but I think sometimes things grow or show up in later "standard" packages that might not be backward compatible with older versions of equipment. In this case I just don't know. We assume the original version worked just fine. We don’t know what GPS Mike P used. We do know that the PIC chip and board have been modified or changed slightly. We know we aren’t getting reliable results at the moment. As much as I hate to ask, do we know anyone who ever did use an RCAP in the beginning and can confirm it ever worked as it should? It might have always had this problem. Here’s a note in the documentation about v1.1. Among a few other things it “Fixed problem relating to eTrex GPS non-standard NMEA format.” That’s Mike’s note.

It does look like Scott says. It also doesn't care which string it gets first. The LED comes on at the beginning of that process, it parses the data, performs a checksum and then goes to a sub routine for each one to look at the data and process it. The LED doesn't go back out until it gets both of those strings and performs a checksum on both. Once it gets those items done, it turns back off the LED. The unit then goes and moves the servo and starts the process over.

The LED staying on indicates it's not getting a valid checksum or something in that area. But I know the program is still running. While everything is connected, and you are following a waypoint, when the LED comes on and stay’s on, you can disable the unit and you have rudder control back. The LED is still on and will stay that way until it gets the strings and finishes processing them accurately. But the program is going back to the top and checking to see if it’s enabled or bypassed.

MrRCCam,

What’s the chance we talk to you with your engineer hat on to see if the components look like they’re rated and configured properly?

Also, I've been running this with a Futaba PCM receiver with 3.3 vdc pulses. It seems to be OK with that. I mean it enbles and disables accurately as well as passes through the rudder pulses just fine when bypassed. I'm assuming the Futaba 3.3 vdc pulses are OK?

Dan

Hovertime

Mar 04, 2006, 10:53 PM

Well guys I have decided to try and play with the chip out of board, so made a makeshift adapter using few 8 pin sockets... I wasn't getting much luck reading PIC16F876A that was included in the kit... As I was playing with programmers settings I think I selected master clear from hardware testing page, and erased the chip.

I have also received programmed chip form RC-Cam, which i tried right away. With it it did not light the led on as battery was plugged in, and RCAP was completely dead. Checked all voltages and radio link OK.
I though maybe he forgot to flash the pic, so attached it to the programmer and verified HEX file OK. Interesting that programmer worked OK with tis chip??
All this is very confusing....?? I thought it must work at least as good as with substitute PIC?? Was board or components modified apart from added possibility for future upgrades? Doesn't look like it.
Anyways, I'm back where I started, or even further back LOL...

Mr.RC-CAM

Mar 04, 2006, 11:17 PM

It does look like Scott says. It also doesn't care which string it gets first. Although the RCAP code does not care which NMEA string is seen first, the GPS's pacing delay time between NMEA strings might matter. If the $GPRM strings arrive too fast, that is, faster than the string parser can handle them, then periodically entire sentences will be rejected. My gut feeling is that if there is a weird parsing problem, then this would probably be first on my list of things to investigate.

What’s the chance we talk to you with your engineer hat on to see if the components look like they’re rated and configured properly?Mike's original V1.0.0 schematic looks fine. The most critical components that someone could easily overlook are CR1, C9, C10. The MAX232A must be the 'A' part. Cap C1 should be directly across PIC pins 19 and 20 (short traces). I don't know what an RCAP2 board schematic looks like or what components are on it (other than the PIC16F876A is used).

Also, I've been running this with a Futaba PCM receiver with 3.3 vdc pulses. It seems to be OK with that. The servo hardware uses Port B of the PIC, which will support the lower signal levels from the Futaba PCM Rx. Basically, logic lows must be less than 0.75V and logic highs must be greater than 2.0VDC. Fortunately, the Futaba PCM Rx has that covered. However, some of the channels on the PCM Rx are sent in "parallel," rather than sequentially, which can be problematic with some software designs. But, you don't seem to be having any problems, which is a good thing.

I'm sort of out of touch since I don't have an RCAP or RCAP2. Just to help me understand the details, am I hearing that the RCAP2 works when it is sent test sentences (perhaps from a test function of the GPS?), but goes wacky when actual real time data is used?

typicalaimster

Mar 04, 2006, 11:38 PM

Well it's a long shot but I went ahead and ordered an RCAP today. Also Dicks Sporting Goods had the Etrex Legend bundle on sale for $200 so I picked one of those up.

kd7ost

Mar 04, 2006, 11:40 PM

Mike's original V1.0.0 schematic looks fine. The most critical components that someone could easily overlook are CR1, C9, C10. The MAX232A must be the 'A' part. Cap C1 should be directly across PIC pins 19 and 20 (short traces). I don't know what an RCAP2 board schematic looks like or what components are on it (other than the PIC16F876A is used).

On my board the Max chip is a 232A. The leads aren't overly long on the caps. They are a little small in form factor than the lead spacing in the PCB calls for though. So the caps stand up a little to prevent from spreading the legs too far.

However, some of the channels on the PCM Rx are sent in "parallel," rather than sequentially, which can be problematic with some software designs. But, you don't seem to be having any problems, which is a good thing.

Good point. We discussed this once didn't we. ;) I recall the Futaba pairs are on 1&2, then 7&8, then 3&4 and finally 5&6. My rudder is channel 4 and I'm using channel 6 for enable. So this keeps them from occuring at the same time at the PIC.

I'm sort of out of touch since I don't have an RCAP or RCAP2. Just to help me understand the details, am I hearing that the RCAP2 works when it is sent test sentences (perhaps from a test function of the GPS?), but goes wacky when actual real time data is used?

Would you mind looking it over closer if I get one to you?

Dan

typicalaimster

Mar 04, 2006, 11:43 PM

Mr.RC-CAM

Mar 04, 2006, 11:44 PM

I have also received programmed chip form RC-Cam, which i tried right away. With it it did not light the led on as battery was plugged in, and RCAP was completely dead. ... I though maybe he forgot to flash the pic, so attached it to the programmer and verified HEX file OK. That sux. Yup, it was definitely programmed with the hex file you sent me using a very good commercial PIC programming system. It verified fine for me too.

The problem sounds like an oscillator issue. What exactly is being used for CR1? Crystal or Resonator? Is it the exact part shown on Mike's schematic?

It could be a bad PIC too. That would be a rare situation, but possible. I'll assume that is the case and send a PayPal refund to you since it was a bust experiment. Just toss the PIC in the chip graveyard.

Would you mind looking it over closer if I get one to you?Sounds fine to me.

kd7ost

Mar 04, 2006, 11:54 PM

My Buddy Jeff hooked up an eTrex to his PC and looked at the strings with Hyperterminal. I don't have a DB9 comm port or a USB adapter so he got these and e-mailed them to me. I took out all the strings except the two that are parsed by the RCAP. As labeled these show what is there in Demo mode, Normal Mode, Before Lock and with WAAS enabled.

In Demo mode, the V in the RMC string means it's not a valid GPS lock.

Dan

In Demo Mode:

$GPRMC,035050,V,4332.1805,N,11618.3374,W,17.4,89.9 ,050306,15.2,E,S*35
$GPRMB,V,0.00,L,,002,4332.181,N,11617.236,W,0.799, 90.0,17.4,V,S*7B

In Normal Mode:

$GPRMC,035402,A,4332.1801,N,11618.7986,W,0.0,0.0,0 50306,15.2,E,A*3E
$GPRMB,A,0.00,L,,002,4332.181,N,11617.236,W,1.135, 90.0,,V,A*63

Before GPS lock:

$GPRMC,,V,,,,,,,050306,15.2,E,N*0E
$GPRMB,V,0.00,L,,002,4332.181,N,11617.236,W,0.996, 89.9,,V,N*7A

In WAAS mode:

$GPRMC,035728,A,4332.1799,N,11618.7943,W,0.0,0.0,0 50306,15.2,E,A*32
$GPRMB,A,0.00,L,,002,4332.181,N,11617.236,W,1.131, 89.9,,V,A*66

Mr.RC-CAM

Mar 05, 2006, 12:11 AM

If you are up to some experimentation, have your buddy capture several minutes of GPS locked data and save as a text file. Then use HyperTerminal and feed it to RCAP as a ASCII file. To poke sticks at my theory that it might be a pacing issue, use HyperTerm's line and character delay parameters to slow down the strings (don't go too slow or it definately won't work). If you can get RCAP to work with this data then you have your smoking gun.

kd7ost

Mar 05, 2006, 12:20 AM

Sounds interesting. I'll get him to read this thread. I'm trying to get him to sign on here.

Dan

kd7ost

Mar 05, 2006, 12:32 AM

FYI to all,

If you're digging into this and need a source of what the GPS is sending and what is where in each string, check this link. http://home.mira.net/~gnb/gps/nmea.html#top
Look at "26 interpreted sentences" and then the $GPRMB and $GPRMC sentences.

Dan

kd7ost

Mar 05, 2006, 01:01 AM

If you can get RCAP to work with this data then you have your smoking gun.

It's also important to emphasize that at least in my case I experienced as much as 5 minutes or so of reliable operation at times. The LED staying on was intermittent even though it was common.

Dan

Mr.RC-CAM

Mar 05, 2006, 01:11 AM

In Demo mode, the V in the RMC string means it's not a valid GPS lock.From a quick glance at the PBasic code, the sentence parsing is skipped when the 'V' field is present during demo mode. From what I can see at this point, nothing of GPS importance is going on during the demo state except the LED updates.

Also, before a GPS lock occurs, the sentence parsing cannot be properly executed due to the presence of some NULL fields. So, any symptoms you see before a valid sat lock are probably of little consequence.

What does this seem to mean? Well, it's all just one more reason to experiment with the text file method I mentioned earlier. Frankly, if there is a problem, I'm sort of leaning towards this being related to the lack of processing time between sentences (a pacing problem).

radiohound

Mar 05, 2006, 01:27 AM

Here is a jpeg of the schematic. Most traces are very similar to the original RCAP. CR1 is a ceramic resonator, see http://www.ecsxtal.com/pdf2/ZTT.PDF This is the same part that was specified in the original RCAP bill of materials BOM file.

Walter

kd7ost

Mar 05, 2006, 01:54 AM

Frankly, if there is a problem, I'm sort of leaning towards this being related to the lack of processing time between sentences (a pacing problem).

Agreed,

I just did a little more playing around with it. It doesn't matter if it's a selected Waypoint with a "goto", or a selected route with a "follow". However, you must select a waypoint or route in order to get the LED to go off at all. A GPS powered on by itself will cause the LED to come on if the RCAP is enabled but there is no route selected.

So if anyone else experiments with this, you have to collect data while a route or waypoint is being navigated to.

(Hmm, is that a clue)

Dan

Hovertime

Mar 05, 2006, 04:49 PM

Well it looks like I was able to flash 876A Pic again, using desktop pc (I normally use laptop) IC-Prog software verifies it OK, compared to "MAIN.HEX" file ... however it is acting same as RC-Cam's chip - no led, no life. Looks like I haven't changed anything else in the board?

Can someone verify - I forgot - when RCAP is disconnected from everything and power is applied to it - led indicates all OK for a few seconds, or does it have to see radio signals for that first?

BTW I have managed to erase RC-Cam's chip too, and I am unable to program it even using desktop PC.

Walter - could you post a link to the file you use in your kits and your programing method / pic device settings?

Hovertime

Mar 05, 2006, 04:54 PM

From a quick glance at the PBasic code, the sentence parsing is skipped when the 'V' field is present during demo mode. From what I can see at this point, nothing of GPS importance is going on during the demo state except the LED updates.

When I was using PIC supplied with a kit and using GPS inside with no lock it was blinking its led. After 5 minutes or so GPS would say that it cant get no lock, and I had option to manually changed coordinates for new search. After I changed it a few thousand miles and used "GPS off mode" it would turn servo toward correct direction, even with "V" present (not A)

Hovertime

Mar 05, 2006, 05:06 PM

Someone asked if original RCAP ever worked OK, yes it did - you can read about it in this old thread, and probably find some info here on RCG too?

While looking for some more ideas I have found this old thread (as did some others;))
Might be worth reading it. http://www.rc-cam.com/forum/index.php?showtopic=666

We need more brain power on this guys! :)

kd7ost

Mar 05, 2006, 05:51 PM

Can someone verify - I forgot - when RCAP is disconnected from everything and power is applied to it - led indicates all OK for a few seconds, or does it have to see radio signals for that first?

I never tried that before but just did it to get you the symptoms. With power only applied, and nothing else connected, the LED does still come on for a few seconds then goes out.

We have more brain power involved. It's being dug into pretty deep right now.

Dan

kd7ost

Mar 05, 2006, 06:19 PM

Mr.RC-CAM

Mar 05, 2006, 07:24 PM

verifies it OK, compared to "MAIN.HEX" file ... however it is acting same as RC-Cam's chip - no led, no life.That sort of seems to suggest that the Hex file is goofy. But, if it is a hardware issue, then I would suspect that either MCLR (PIC Pin 1) is not pulled logic high (should be 5VDC during operation from the pullup resistor) or the Oscillator (CR1) needs attention. As far as the Oscillator goes, the RCAP uses a low cost resonator with internal caps. I'm not a big resonator fan for apps like this and would have probably spent the extra nickel and used a 20Mhz xtal and two 27pF caps. If you have a scope, check the Oscillator pins for the telltale 20 Mhz. If it is missing, then for sure make sure MCLR is high and that th PIC power pin has 5.0VDC. Beyond that, your resonator would be suspect.

If the above does not help then program the chip again with the Watchdog (WDT) fuse turned off. This is a setting within your programmer.

Can someone verify - I forgot - when RCAP is disconnected from everything and power is applied to it - led indicates all OK for a few seconds, or does it have to see radio signals for that first?When power is first applied, the LED should come on for two seconds, regardless of how confused the GPS may be. This startup LED activity is indicated in the source code from the RCAP site. But, if the compiled code is from a different release version, all bets are off.

kd7inn

Mar 05, 2006, 08:48 PM

Hi,
I have been helping Dan (kd7ost) with this problem. Dan has convinced me to sign up with this group and participate in the discussions. Since
this is my first post I hope I do this right. I apologize if it's a bit long.

First, a little about myself. I am not an expert programmer. It's just a hobby for me. Most of my experience is with the BASIC Stamp 2 writing
programs for my Near Space Capsule (see www.tvnsp.org ). I have recently purchased PicBasic Compiler but I'm beginning to think I should have
spent the money for the PicBasic Pro which is more like the BS2. Oh well. In any case I found a link to the PBPro manual which is what the RCAP
program is written in (http://www.melabs.com/resources/pbpmanual/ ).

I have been studying the software and added to the description of what the program does. See the bold text below.
----------------------------------------
Init:
Get PulsIn value of Neutral for the servo
Get Gain Value
Get Servo Direction

MainLoop:
If Autopilot ON then
GoTo Autopilot
Else
GoTo Passthru
EndIf

PassThru:
Pulsin Receiver
PulsOut Rudder
GoTo MainLoop

AutoPilot:
Get GPS Data
Get RMC or RMB sentence, whichever comes first.
Turn on LED
Do CheckSum of Data
If checksum fails then GPSvalid = 0 else GPSvalid = 1
If GPSvalid = 0 then goto MainLoop
(Note: LED does not get turned off in this case.)
Fill in Vars (Extracts data from GPS string)
Get the other GPS sentence (RMB or RMC)
Do CheckSum of Data
If checksum fails then GPSvalid = 0 else GPSvalid = 1
If GPSvalid = 0 then goto MainLoop
(Note: LED does not get turned off in this case.)
Fill in Vars (Extracts data from GPS string)
Turn off LED
(Note: This only happens after successfully reading and checking both the RMC and RMB sentences.)

If Correction needed then DoCorrection
GoTo MainLoop

DoCorrection:
If Direction Normal
Turn normal
Else if Direction Reverse
Turn Reverse
GoTo MainLoop
--------------------------------------
The thing that I wanted to point out is what the LED means. As you can see the LED comes on after the program gets it's first GPS string. It
does not turn off again until after the program has finished collecting data from the GPS, performing checksums, and extracting the data. If it
fails the checksum then the program goes back to the Main Loop and the LED is still on. Or, if it takes too long for the GPS sentence to show
up it also goes back to Main Loop and the LED is still on. The symptom that seems to be common among us is that the LED stays on for long
periods of time. It's possible that it is failing the checksum but I have a different theory. It is my theory that the program is having a
difficult time collecting the data from the GPS simply because of timing. Take a look at this program line:

HSERIN 100, Main, [WAIT("$GPRM"), STR gpsdata\MAXDATA\13]

This line tells the program that if no GPS data is seen for more that 100 milliseconds then goto Main (which is the Main Loop). Now let me
describe my GEKO 201. My GEKO puts out GPS sentences every 2 seconds. The first sentence is the $GPRMC sentence and the second one is $GPRMB followed by 10 more sentences. It takes more than 1.5 seconds to transmit all this data. I don't know the exact amount of time. Now let's set up a scenario:

Let's suppose the program just started the DoAuto routine. Let's also suppose that it(the program) captured the RMB sentence first since it is allowed to capture whichever comes first. Next it would perform the checksum and finding that RMB sentence is okay it would extract data from it. The next step is to capture the RMC sentence. The program line looks like this:

HSERIN 100, Main, [WAIT("$GPRMC"), STR gpsdata[1]\MAXDATA-1\13]

Let's further suppose that the program happen to look at the GPS as it was halfway through transmitting the GPS sentences and therefor the RMC
sentence already went past. When all the sentences are finished transmitting there is a time gap before the next sentence starts. Let's suppose the time gap is greater than 100 milliseconds. Because it is greater that 100 milliseconds the program is redirected back to the Main Loop and performs some other tasks. It spends time rechecking to see if the user still has the AutoPilot on (APon = 1). That means it takes time to measure the pulse width coming in from the enable pin. After deciding that the AutoPilot is still on the program goes back to the DoAuto routine. Next it is directed to once again look at the GPS and wait for the RMB sentence. Again the RMB sentence has already gone by because it is the first sentence transmitted and the program took too long to get back here. We are stuck in a loop. Only when the timing works out to bring the program back to the GPS just before it starts transmitting the sentences will it capture the RMB sentence. This takes a while and therefore the LED remains on and no corrections are made to the flight path for sometimes long periods of time.

Someone who had PicBasic Pro can change the wait time to perhaps 1500 and see what happens.

I hope this helps.

Jeff

kd7ost

Mar 05, 2006, 09:01 PM

So what do you think Walter? It's not a glamorous fix and Jeff confided in me he thought the program was too complicated for the job and wants to revise it much more. But in the mean time, how much trouble would it be to change this line
HSERIN 100, Main, [WAIT("$GPRM"), STR gpsdata\MAXDATA\13]
to this
HSERIN 1500, Main, [WAIT("$GPRM"), STR gpsdata\MAXDATA\13]

And see if that fixes the problem.

Dan

kd7inn

Mar 05, 2006, 09:15 PM

And just to be clear, the other program lines need to be changed to 1500 also.

HSERIN 1500, Main, [WAIT("$GPRM"), STR gpsdata\MAXDATA\13]
HSERIN 1500, Main, [WAIT("$GPRMC"), STR gpsdata[1]\MAXDATA-1\13]
HSERIN 1500, Main, [WAIT("$GPRMB"), STR gpsdata[1]\MAXDATA-1\13]

Jeff

kd7ost

Mar 05, 2006, 09:17 PM

Cool Jeff,

That's why you need to be here. So there are three lines total?

Dan

kd7inn

Mar 05, 2006, 09:35 PM

Yes. These three lines do all the data collecting from the GPS.

Jeff

radiohound

Mar 05, 2006, 09:49 PM

Here is an edited file, with the 1500 ms for hserin time. It may be that we want to try it at a few different timing settings, as this may be too long ... but great starting point. Thanks!

Turns out I have to charge my transmitter before I try this file. I have made the changes, and here is the hex file. Anyone with a programmer want to give it a try? I will be charging my transmitter for a little while, then I will give it a go a little later tonight.

Walter

Oscillator HS
Watchdog Timer Enabled
Power Up Timer Enabled
Brown Out Reset Enabled
Low voltage programming disabled
Flash program memory write All
Code Not Protected
Data Eeprom Not protected

radiohound

Mar 05, 2006, 10:17 PM

Ok, here are the results of a 5 minute test in the dark, wandering about the neighborhood aimlessly.

I would have normally noticed the light stay on for at least 2 to 4 seconds once in a while in a 5 minute period while on Nomral GPS mode with a Geko 301. However, with the change that KD7INN suggested, I got perfect blinking from the LED for the entire (but short) 5 minute test. Also, the servo seemed to be trying to steer me toward the waypoint, noticed it turn in relatively large movements when I radically changed my direction to or from the waypoint.

This was in no way a complete test, but it does show promise, and I will have to do some more testing tomorrow in the light, with a recharged transmitter, and more area to enter and exit the waypoints from.

Walter

typicalaimster

Mar 05, 2006, 10:36 PM

Hey Walter. I don't know if you shipped my order out yet. Could you flash mine with the latest code and I can give it a whirl out here.

kd7ost

Mar 05, 2006, 10:45 PM

I was just talking to Jeff (kd7inn) and we don't have a way to program that PIC up here so are anxious to hear of others results. Hopefully it will be replicated across the board. We need to figure out what to do to get set up better for that.

Dan

radiohound

Mar 05, 2006, 11:18 PM

Radiohound,

I have a request for future versions. I modified the picture here. Can you connect the Servo + voltage buss with the input to the regulator? (White line) Also, The holes for the servo wires are a little small. (Violet box) I used the heavy gauge servo wires, twisted and tinned but really struggled to get them inserted. Can those go up a diameter or two?

Dan
Great suggestions Dan. I will make it so on the next batch. Jumper will be provided for those that will not want to use power from their motor controler to power the unit. Hopefully noise will not be an issue, but if it is, it can always be powered seperately.

Walter

kd7ost

Mar 05, 2006, 11:32 PM

Cool Walter,

That rocks.

Dan

Hovertime

Mar 06, 2006, 12:04 AM

Well guys my PIC programmer is pissing me off, maybe its time to get a new one, with USB port perhaps? Any recommendations for low budget??

I have tested and voltage is 4.94 from regulator, also same voltage at pin 1.
I wanst sure where to test oscillator, so I tested pic pins 9-10, also 9 to ground and 10 to ground, with DVM set to Hz-auto. Nothing. I checked it at mains plug and it measured as its supposed to.

UPDATE - I was able to get my programmer work on my laptop with RC-CAM's chip this time (only with it :confused: )

NEW UPDATE. I saw that oscillator is supposed to be "HS"?
MAIN.HEX automatically selects it as XT which I suppose means external... anyways, I changed it to HS and RC-CAM's chip came to life!:) Same symptoms as 876A. Next will try new code with longer waiting time, update to follow! :)

radiohound

Mar 06, 2006, 12:47 AM

Well guys my PIC programmer is pissing me off, maybe its time to get a new one, with USB port perhaps? Any recommendations for low budget??

XT is just for low mhz externals. For 20 mhz, you need HS.

Glad to hear you seem to have got your programmer working.

I just bought a USB programmer from www.microchip.com. For info on this programmer, click on development tools, then click on PicKit 2. You will need to wire up a 28 pin socket or something for it though.

I like the cheap part of the microchip PicKit2 ($35), and I dont have to wory about grounding it anywhere, because it is completely encased. Also works on my laptop without having to plug in a big parallel port connector, and it is self powered.

But I still like the integration part of the www.melabs.com programmers. You can open up the programmer from PicBasic Pro, right after compiling, and it automatically loads the hex file for you - then you just click program. More cables, more bulk, and more expensive though.

Mr.RC-CAM

Mar 06, 2006, 01:14 AM

It looks like things are coming to a close for you RCAP users. That is a relief. :)

Hovertime

Mar 06, 2006, 01:34 AM

I was looking at this right this moment: http://www.sparkfun.com/commerce/product_info.php?products_id=4 Is it worth the extra $$ over one that you are using? Will have to take a look at microchip one...
I was unable to get my programmer to program either chip with 1500main.hex ...
I think I'd rather spend some money and get USB programmer - I have wasted all day today messing with that programmer... argh... Well I'll try it on desktop PC tomorrow. I don't use pic programmer very often so not really a needed investment, still - I'm kinda sad I couldn't test new fix file tonight.

Hovertime

Mar 06, 2006, 02:35 AM

radiohound

Mar 06, 2006, 12:41 PM

I wonder why I could not flash my currently programmable PIC16F876-20/SP with he new tweaked file??? Was it specially made for PIC16F876A -I/SP and is not inter-compatible?? I did select correct chip in the programmers software..

The program was compiled for the 876A. Could be that that is the reason. Perhaps there is a config setting that is not available in the non A model. Don't know for sure, and I dont have a non A to test. Is your 876A currently dead?

Hovertime

Mar 07, 2006, 12:02 AM

I see.. My 876A is OK, I just didn't want to fight with the pic programmer all day again... I have no idea which settings I chose last time that made it work with 876A... I think I had to use desktop PC too, which I have limited access to.

I'm also not sure about which USB programmer does what and still have yet to order one. If I manage to get RCAP project working I might leave this purchase off until next time my programmer drives me nuts LOL :)

I wonder If I got USB to serial converter - would my current programmer work better and act similar to the USB one?

Anyways - will try to get it flashed in the next few days...

radiohound

Mar 07, 2006, 05:30 PM

I'm also not sure about which USB programmer does what and still have yet to order one. If I manage to get RCAP project working I might leave this purchase off until next time my programmer drives me nuts LOL :)

I wonder If I got USB to serial converter - would my current programmer work better and act similar to the USB one?

I would think that if you are already having troubles with your serial programmer, then a usb to serial converter is probably not going to help you. If the serial output on your laptop is not quite up to rs232 specs, then your new $erial to usb converter may not read your serial port properly either.

If you think you may be getting into development of PicBasic /Pro code, then the melabs programmer with 840z adapter for $119http://www.melabs.com/products/usbprog.htm may be the best bet, as it can handle a very large number of Pic products.

If you are just going to be using it for limited devices, or are just going to program using other peoples code, then I would go for the $35 microchip USB pickit2. I have not seen specifications on the sparkfun programmer, so I can't really speak to that one.

muc

Mar 07, 2006, 06:37 PM

Has anyone else noticed that the “pass through” of the servo signal isn’t very smooth? This is with the guidance disabled. I did try the 1500ms delay on the hserin and it seemed to fix the problem. BTW I’m using a geko 201. It will probably be some time before I can test things in a plane. I’m hard up for time right now. I was thinking about the altitude sensor. What if we were to use the Z-log to obtain accurate altitude readings in 1 foot resolution? http://www.hexpertsystems.com/zlog/ It may be overkill but it would be easy to add it to the system (I think). It will send out altitude when sent a certain command. One negative thing is that it’s 3.3V TTL so this will have to be dealt with. Maybe it wouldn’t be such a good idea but it’s just a thought.

Hovertime

Mar 07, 2006, 09:25 PM

No, I will never write my own code most likely, while I like assembling something, and solder few parts here and there, I'm not too fond of electronics in general, and math makes my head ache... :)

Spark and fun programmer is actually Olimex unit that is "is MPLAB compatible and is fully recognized under MPLAB as a PicStart+ device" and is promised to have lifetime firmware upgrades to keep up with MLAB...

On the other hand 35$ is much lower and I also love its fully encased looks:) Can you select different fuses for PIC devise using Pic Kit 2 USB programmer? Like in case of original MAIN.hex file - it self select XT oscillator, and I needed to change it to HS?

If main1500.hex work with my unit then its for sure the main problem as mine goes belly up as soon as GPS signal is locked on...

kd7ost

Mar 07, 2006, 10:11 PM

Has anyone else noticed that the “pass through” of the servo signal isn’t very smooth? This is with the guidance disabled. I did try the 1500ms delay on the hserin and it seemed to fix the problem. BTW I’m using a geko 201.

I don't know about the hexpert system but I can answer to the Servo issue. It is rougher action. But not too much. Due to more pressing issues, that hasn't been looked at. There are only X amount of steps in pulse duration to the servo during "Passthru". In fact the receiver pulse isn't really being passed through. The servo program looks at the input pulse duration. If it's between two small incremental durations, it will replicate a pulse on the output that is in that range. As the input rudder pulse changes in a quite linear fashion it will get into the next range and the PIC code "steps" to the next output pulse duration. You can see it especially if you move the rudder really slow.

In my opinion it won’t be a problem. UAV type aircraft need to be stable and not respond real fast. Standard sized rudders and a 20 degree per second turn rate should be set into the systems by the builder/integrator. (Not pattern or 3D style rudders) The small rudder step increments aren’t likely going to transfer to anything you can see in flight. It would show up in slow speed 3D flight or even pattern flying where tiny amounts of throw make the difference in manuvers. The steps are there, but they’re small.

Changing the code to 1500 from 100 on the wait part won’t have any effect on that. When the program runs, the first thing it does right after MainLoop: is check to see if the autopilot is on. Here it is after MainLoop:

MainLoop:
If Autopilot ON then
GoTo Autopilot
Else
GoTo Passthru

If it’s not on, it goes to the Passthru routine. The 1500 millisecond delay takes place in the autopilot mode. It will only do the 1500 delay if the unit is enabled.

Dan

muc

Mar 07, 2006, 10:35 PM

Hi Dan,

I should have been more specific. When I wrote about the 1500ms delay I was referring to the original problem everyone else was having. Not the servo motion. I do understand the main program very well but not the servo.inc file so much. I usually use a high-pauseus-low command to drive a servo. I know it can’t be done this way because of the program waiting for the GPS data. I just wish the servo pulses had better resolution. Can the servo.inc file be modified to do this? I was comparing the RCAP and PDC10 and it looks like the PDC10 has 1us resolution based on the servo motion. It seemed much better than the RCAP.

kd7ost

Mar 07, 2006, 10:43 PM

I just wish the servo pulses had better resolution. Can the servo.inc file be modified to do this? I was comparing the RCAP and PDC10 and it looks like the PDC10 has 1us resolution based on the servo motion. It seemed much better than the RCAP.

Good question muc.

I don't know code like some of you guys do. I don't know what to do to increase the resolution. But, since this is open source and we're looking to have everyone involved, I think we would all appreciate any expertise you can put towards that. Is that an area you would be willing to tackle? If you can post the what and whyfores here, we'll get involved with you as much as we can in our own ways.

Dan

kd7ost

Mar 07, 2006, 11:02 PM

I did try the 1500ms delay on the hserin and it seemed to fix the problem. BTW I’m using a geko 201.

BTW muc,

Now that I understand this comment, (I can be a little slow at times) :rolleyes: I'm glad to hear it. I have some parts on the way and will be able to run it through the mill pretty soon myself. I'm glad to hear the delay waiting for the GPS strings seems to work for you too. That's two confirmed improvements out of two test's. So far so good. :D

Dan

muc

Mar 07, 2006, 11:03 PM

I don't mind trying, but like I said I don't understand the servo.inc too much. If I come up with anything I'll post it. My day job takes me out of town for a week or two at a time so it won't be fast. I've also just started to code with PBP so I'm a beginner/novice at this stuff.

Mark

kd7ost

Mar 07, 2006, 11:12 PM

Cool Mark,

We're anxious to see anything new. Welcome aboard.

Dan

Mr.RC-CAM

Mar 07, 2006, 11:45 PM

Is the complaint that the pass-thru servo resolution is poor or is it that the servo jitters too much? These require different solutions.

I suggest that before the servo code changes begin, someone should measure the pass-thru servo pulses to determine what needs to be fixed. You should measure framerate, pulse resolution, and pulse jitter. Any decent o-scope can do this and shouldn't take more than a couple minutes to gather the information.

From looking at the code, the general servo output resolution is slightly less than 1uS, which is very good. In pass-thru mode the incoming pulse is measured (in main.bas) with 2uS resolution, so it is effectively slightly lower resolution in that mode. But not enough to be a big deal. The framerate is coded to be 50Hz. The jitter is an unknown, but for sure will be much more than 2uS.

Some goals: Aim for jitter that is under 4uS (<2uS would be ideal). Resolution can be pretty low and still not be a problem. For example, some low end DSP Rx's have resolutions that are barely 6uS in step size, and many users don't seem to notice.

I would like to help more but I am just a fellow that is looking over the fence. Good luck!

muc

Mar 08, 2006, 12:14 AM

I’m going to have to go with the jitters. If I move the stick really really slow it does appear to have better resolution than I thought. If the stick moves with any pace it’s pretty jumpy. I don’t have a way of measuring with a scope anytime soon so someone else will have to do this.

Mr.RC-CAM

Mar 08, 2006, 12:25 AM

If the stick moves with any pace it’s pretty jumpy.
That is an update problem that is related to the way that the pass-thru mode measures the incoming pulse. For a possible turbo-boost in performance, just delete (or convert to a comment) the debug statements in main.bas that are in the passThru function:

PassThru:
DELETE ME: DEBUG "!===PassThru:", 13
PULSIN PWInputPin,1,w
DELETE ME: DEBUG "!PWInput=", #w*pwifactor, 13
IF w = 0 THEN
Position = center - 900 ' Position between 0-1200 for 900ms-2100ms
ELSE
w = w * pwifactor
Position = w - 900
ENDIF
GOSUB SetPWPS
DELETE ME:DEBUG "!Position=", #Position, 13
GOTO Main

No promises that this will help reduce the lag, but it certainly will not cause any harm.

muc

Mar 08, 2006, 12:36 AM

For a possible turbo-boost in performance, just delete (or convert to a comment) the debug statements in main.bas that are in the passThru function

That made a world of difference. Nice and smooth now. I highly recommend everyone make this change. thanks RC-CAM

Hovertime

Mar 08, 2006, 12:53 AM

WOW, another major breakthrough made !?! :)

Sorry for the dumb question - did you add "delete me" comments or were they actually in the code ?????? :confused: That extra code is there for what exactly?

I hope I was reading post #22 right: - Mr.RC-Cam is getting one RCAP to have a closer look? :cool:

Mr.RC-CAM

Mar 08, 2006, 01:26 AM

Nice and smooth now. That is good news.

... did you add "delete me" comments or were they actually in the code ?????? That extra code is there for what exactly? The "Delete Me:" is what I added so that you could see which lines to remove (or comment out). The debug statements were used by Mike to debug his code. I have a feeling that he removed them in his released the hex file. I suggest that ALL the debug statements be converted to comments before compiling the "production" hex file (there are more scattered in the source code).

Hovertime

Mar 08, 2006, 02:35 AM

Well since I used Main.hex file, downloaded from original RCAP site - it was jumping the servo in similar size steps (when TX stick was moved fast) as with the RCAP V2 chip that came with the kit. I too think that it shouldn't affect aircraft much or at all in the air, its just "different" and does not "look" right.

When I moved TX stick slowly servo did move nice and smooth

Mr.RC-CAM

Mar 08, 2006, 03:57 PM

I was thinking about the altitude sensor. What if we were to use the Z-log to obtain accurate altitude readings in 1 foot resolution? How much real interest is there in an altitude hold feature? If it was significant (few dozen folks), I might actually tackle it later in the summer. However, my solution would involve an entirely new "RCAP" sort of design.

For sure, the popular Zlog altimeter from Hexpert can be used for the elevation data. I am definitely familiar with exchanging data with the Zlog (soon I will be offering a small OSD video board that plugs into it). But, maybe a solution should utilize a GPS that has an integrated barometric altimeter (like the Garmin 301)?

Just tossing ideas out here. For sure, the task at hand is to beef up the RCAP design. I have a feeling that is what you folks really want. :)

Mar 08, 2006, 04:50 PM

Has anyone else noticed that the “pass through” of the servo signal isn’t very smooth? This is with the guidance disabled. I did try the 1500ms delay on the hserin and it seemed to fix the problem. BTW I’m using a geko 201. It will probably be some time before I can test things in a plane. I’m hard up for time right now. I was thinking about the altitude sensor. What if we were to use the Z-log to obtain accurate altitude readings in 1 foot resolution? http://www.hexpertsystems.com/zlog/ It may be overkill but it would be easy to add it to the system (I think). It will send out altitude when sent a certain command. One negative thing is that it’s 3.3V TTL so this will have to be dealt with. Maybe it wouldn’t be such a good idea but it’s just a thought.

The processor on ZLog has 5v tolerant I/O pins, so you could hook up 5v serial lines to it, as long as the other end can read 3.0 volts as a logic high.

MX

kd7ost

Mar 08, 2006, 10:20 PM

How much real interest is there in an altitude hold feature? If it was significant (few dozen folks), I might actually tackle it later in the summer. However, my solution would involve an entirely new "RCAP" sort of design.

I don't know the interest level. It will largely depend on end use. If the consumer is using it as an autonomous device, there needs to be some altitude control. If it's a return to pilot device such as in longer range RC AP use, there is not likely a significant need for altitude hold. My take is everyone would ask for real altitude control. I believe the two functions, rudder steered by GPS and elevator controlled by altitude should be jumpered or ? to be activated by two different enable lines. Some people might want one spare switch to activate them both. But, there are times where some uses will want one but not the other.

Dan

kd7ost

Mar 08, 2006, 10:25 PM

I got a brand new PIC today with the 1500's line in. It is raining like crazy and about 35 degrees outside so I could only tolerate about 20 minutes worth of testing before the gear was getting too wet and my teeth were chattering. :D

I experienced no LED lock ups. It operated fully and reliably as I did my neighborhood rambling. It enables and disables as it should, and as soon as it is enabled it continues to track to the waypoint. I have the gains set to mid range and didn't play with them yet. Further testing will follow.

Excellent so far. Good work you guys. If it keep's looking like this, I'll fly it in my big plane.

Dan

Hovertime

Mar 08, 2006, 10:58 PM

OK i cant take it anymore, time to go fire up that big old PC and try to flash my own copy of 1500main.hex :)

Update to follow!:)

Hovertime

Mar 08, 2006, 11:53 PM

Well guys - its ALIVE !!! :D
Works like a charm. Rate of update might make some interesting driving with RC truck , but should be perfect for slow stick type plane, if adjusted right:)

Thank you all who made this happen!

Next on my schedule - somehow remove that extra bits of code.

BTW I was thinking about my programmer + USB-to-serial adapter versus USB programmer: USB programmers basically just have serial adapter chip integrated, so they are still serial programmers, right? As I seem to have much better luck using this simple programmer with desktop PC (normal serial output voltages?) and not so successful with laptop(nonstandard/lower serial output voltages?) then probably USB to serial converter would make it work OK on my laptop, and I could squeeze some more life out of it.

typicalaimster

Mar 08, 2006, 11:54 PM

Some people might want one spare switch to activate them both.

I'm just throwing this out there.. I know Walter added the other plug for a servo. Would it be logical to add something like an expansion port to the board? The second board could just rest on top of the other like a daughter board. Would it also be that hard to write and include for the secondary board? I'm stupid when it comes to PIC programming.. I've ordered a few books since this grabbed my attention and the source reads pretty easily...

Coming from a systems admin point of view here.... It just seems like we have the main code debugged and should check that into a repository. Perhaps someone can create an optional code and accessory page we can submit things to?

Almost makes me feel like we're writing the Paparazzi project over again...

radiohound

Mar 09, 2006, 12:50 AM

Next on my schedule - somehow remove that extra bits of code.

Hovertime, if you are refering to the Debug lines, they were all edited out when I first posted main1500.hex, but there may be other places for improvement on the updates for the servo.

Walter

Hovertime

Mar 09, 2006, 10:35 PM

LOL, and I was thinking while testing yesterday "hm, it does not jump around all that much, maybe its not worth the trouble to remove debug lines " .... :rolleyes: :o You think there are some other areas in the code that could be improved ?

Talking about altitude. GPS w barometric sensor are 2-3 times more expensive than without it... (geko201 vs geko 301 for example)

Is it worth doing that vs adding barometric sensor to RCAP?

How about using simple GPS data for altitude? with WAAS it should be pretty accurate?

Mr.RC-CAM

Mar 09, 2006, 11:14 PM

How about using simple GPS data for altitude? with WAAS it should be pretty accurate?The altitude data on the WAAS GPS's I used has varied +/-20 meters. That is open area with plenty of satellites in view.

kd7ost

Mar 09, 2006, 11:22 PM

I think you need to keep altitude managed with BP. Either that or a blind GPS with a much faster refresh rate than a handheld unit. But then you end up with two GPS units because you still need the handheld to manage the waypoints. If you fly in totally calm air it might not be a big deal. But if you have a high lift or sink vertical velocity situation (Winds effecting flight) the slow refresh rate will cause the unit to have trouble keeping up. If there is enough gain to keep it at altitude, it will likely cause your plane to porpoise up and down. To smooth it out, you reduce gain. Reduced gain with fast vertical direction and at some point it won't keep up.

If there's a BP sensor, on line at all times with the elevator or throttle settings, you can optimize the gain to work in the variety of conditions.

Dan

LukeZ

Mar 10, 2006, 01:30 AM

Hi fellas... I know I've brought this up before, and still there have been no tangible results, but I am working on an altitude hold unit that could easily be interfaced with the RCAP2 or used standalone. By no means should anyone wait around for it with baited breath - but I have been putting more time into it lately and I truly hope to have some test units ready within the next few months. My goal was to have them ready by the new year, but obviously that didn't happen...

Mr. RC-Cam you've helped me out on this project, over on my thread in the DIY Electronics forum, so maybe you kind of know where I'm at. I had to take a break from the project for a few months but I'm back on it now every chance I get. I am working on my testbed PCB and I intend to post my layout on that thread within the next few weeks to get some feedback. It won't be the final circuit but will allow me to put it in a plane and do some tweaking.

It seems like real life always interrupts these projects so I can't promise anything by any kind of deadline. I would, however, be more than willing to share what I have so far with anyone else, if that would help. I intend for all my code to be open source. Right now though my main task is to get the hardware cleaned up. Because I am going for 1 foot resolution all the way from sea-level to 45,000 feet, and because I'm only using a 12 bit A/D, there's some circuitry tricks that are being employed and the whole thing needs to be very clean. But my initial tests so far have been very promising. I can raise and lower my breadboard up and down along a tape measure placed against a wall, and the altimeter accurately measures the feet it has moved. How it will perform in the field has yet to be determined...

Anyhow, just throwing that out there. I know it doesn't do anyone any good yet but thought I'd mention it for what it's worth.

Luke