Discussion RCAP2 autopilot troubleshooting and testing.

[Hovertime]

Well I have finished assembly of my new project - RCAP2, or RCAP V2 which is basically the same as original RCAP, with some improvements.

Tested it in E-MAXX electric powered monster truck. While not the perfect test bed - it is not able to drive slow enough to walk by it, it had all the radio connections needed, I used gear channel to turn RCAP2 on or off.

[Hovertime]

RCAP2 manual 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]

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

[hihptsi]

Originally Posted by kd7ost

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]

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]

Originally Posted by hihptsi

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]

Originally Posted by kd7ost

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]

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]

Originally Posted by typicalaimster

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]

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]

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]

Originally Posted by Hovertime

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.



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]

Originally Posted by Hovertime

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]

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]

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]

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]

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]

Originally Posted by Hovertime

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Originally Posted by Mr.RC-CAM

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.

Originally Posted by Mr.RC-CAM

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.

Originally Posted by Mr.RC-CAM

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]

Originally Posted by Mr.RC-CAM

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).

I'll attach the original circuit schematic and the board layout schematic.. Good point if RCAP2 changed any..

[Mr.RC-CAM]

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]

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]

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]

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

Dan

[kd7ost]

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]

Originally Posted by Mr.RC-CAM

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]

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]

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]

Originally Posted by Mr.RC-CAM

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]

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]

Originally Posted by Mr.RC-CAM

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]

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?

Originally Posted by Hovertime

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]

Originally Posted by Hovertime

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]

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

[Mr.RC-CAM]

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]

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