PDA

View Full Version : Pulsin Stabilization



Bobbo_ZA
- 30th August 2011, 17:36
Hi All,

Below is my code for turning on and off the landing lights of an RC model, however, I find the lights turning on and off randomly.... ??? ... confused...

I'm using a 12F675, the pin connections as follows:

GPIO.0, 1, 4 and 5 have LEDs connected (landing LEDs on gpio.4) all via the respective Resistors.

GPIO.3 is connected to the RC input through a 1k Res (i've tried it direct)

The program responds as expected on the RC input however on either side of the switch (on or off) the lights randomly turn on (when they are sposed to be off) and off (when they are sposed to be on.)

There is nothing connected the GPIO.2, however I am not sure if tis "open" pin could be causing it.

I checked with the scope and the input signal seems to be stable, just dont know why the signal seems to be jumping within the pic, any ideas?

Many thanks
Rob



@ DEVICE INTRC_OSC, MCLR_off, PROTECT_OFF, WDT_ON, PWRT_ON, BOD_ON
CMCON = 7 ' Comparators OFF
ANSEL = 0 ' A/D OFF -- Port pins all digital
TRISIO = %001000 ' All output but GPIO3 = input
GPIO = %000000 ' All 0 on boot
ADCON0 = 0
WPU = 0
DATA @1,$FF, $FF
'DEFINE PULSIN_MAX 3000

wing_led2 Var GPIO.5
land_led1 VAR GPIO.4
tail_Led VAR GPIO.0
strob_led VAR GPIO.1
servoin VAR GPIO.3
p var word
'---------------------------------------------------------
start:
'---------------------------------------------------------
Pause 200 ' Stabilisation at startup
p = 0
High wing_led2
High tail_led

PulsIn servoin,1,P
SELECT CASE p
CASE is >160
HIGH land_led1
Case is <130
LOW land_led1
End select
Low strob_led
pause 250
High strob_led
pause 100
low strob_led
GOTO start
End

cncmachineguy
- 30th August 2011, 18:44
Your Rx may be glitching, maybe set it up to wait for 3 vaild pulses before changing states of the lights. Now if the are staying on when they should be off, and staying off when they should be on, maybe you need to hit the rev for that channel in your radio

Bobbo_ZA
- 30th August 2011, 20:51
Thought about that too, tried it on a 2.4ghz set (which should be a more solid signal) and yet it still does it, also I would expect it to remain in the last state when the Rx is off yet they still randomly turns on and off again, :-(. I tried a 1k res to ground from GPIO.3 but then it does not work at all, :-(

Its ironic that something this "simple" is proving such an issue, probably spent 24 hours solid on this project and hundreds of rewrites but still not etting it, :-(

I have another circuit that i had done for another application where i used the same principles that works flawlessly, yet this just doesnt, only this one is on vero board.

mackrackit
- 30th August 2011, 21:04
An open pin is not a problem as long as you code it as an output near the beginning of the program.

You might try a debounce type of routine to hide false signals.

Charles Linquis
- 31st August 2011, 00:30
It might be helpful to take your unused GPIO.2 and connect it to the Rx of a RS-232 port on your PC, then use DEBUGOUT or SEROUT2 to send the value of PULSIN to the PC. It is even better if you have one of those little TTL-RS232 converters lying around and use that.

Serial ports make wonderful debugging tools.

mister_e
- 31st August 2011, 00:35
Motion seconded.

Bobbo_ZA
- 31st August 2011, 08:28
I actually have a Max232N board hanging around that i made up some time back and never used, will have a look at the DS again and see how to connect it again, :-) see if it can give me abything usefull.

So strange that the same / similar circuit can work in one application and then slightly modified it gives unstable results.

I suspect there may be something in my soldering but I went over it with a fine tooth comb and still its doing it, :-(

was tempted to dump it and remake it from scratch last night and start with the Rx input and single outout and then add the rest to it if it worked.

Question, Is it wise / required to run the Rx singnal through a resistor or should i connect it straight to the pin? Aslo, is there anything else i should do to the pin? i.e. res to Vcc or pullups etc?

Bobbo_ZA
- 31st August 2011, 16:01
Well, so i plugged the 12f onto the breadboard that has a 18f connected to a LCD and programed the 18F to show me what pulsin was giving me, the pulsin value ranges between around 120 and 180 which is what i expected, however, it only fluctuates by 4-5 points, in the code (above) I'm aksing it when the value is greater than 160 turn on the lighs and less than 130 turn them off, even when the pulsin is staying less than 130 or above 160 the lights randomly flash, :-(, pulling my hair out with this.

Replaced the PIC, rechecked all the connections and that all the respective tracks were cut on the vero etc yet it keeps doing it.

I tried averaging 3-4 readings but it still does it (causes my "strobe" LED to slow down quite a bit as well).

Considering scrapping it completly and starting from scratch, even replaced the cap (1uf...should i be using .1uf?) on vcc.

Many thanks
Rob

Bobbo_ZA
- 31st August 2011, 23:02
Just bought a Pickit 2, reckon my dodgy homebrew programmer might be a part of the issue, think i've been through 10 PICs in the last 2 hours keeps bombing the OSCAL value and toasting them, :-(

Bobbo_ZA
- 5th September 2011, 20:55
Damm, been busy this afternoon with the Pickit 2 and seems i still get the same issues, at least now i'm not killing Pics at a serious rate, even managed to recover some the winpic wouldnt read anymore.

Built a onboard glow this afternoon and its working 100%, the only difference between this issue and the onboard glow is that this one does not read / store the switch value, I'm working with hard coded values, :-(

Bobbo_ZA
- 5th September 2011, 21:02
Question, would powering the pic from a LM7805 (5v reg - giving 5.01v on the DMM) make a difference? all the others I power from the Rx, this one i've decided to use an external battery regulated down, still using a cap on vdd and gnd.