PDA

View Full Version : Help with Pic Delay Pulse code please



g7jiq
- 27th March 2009, 00:57
Hi all

I big thanks to all that have help me in the past,
But I have a small problem I hope someone can put me straight with.

Below is my code I have had running for some time with no problems,
What it does is to allow an input to output with a delay on the output when the input is removed,
What I would like to add to this is if the input trigger is longer than say 1 second the output is triggered as before but doesn't have any delay,
If the input has smaller pulses of say less than 1 second the delay is as before.

I hope this makes sense,
Any ideas...?

Many thanks to all ....

************************************************** *************

'G7JIQ MICRO LINK REPEATER
'PIC 12F675
'Internal RC clock
'
' PIC Defines
' -----------
@ DEVICE pic12F675, INTRC_OSC_NOCLKOUT
' System Clock Options (Internal)
@ DEVICE pic12F675, WDT_ON
' Watchdog Timer
@ DEVICE pic12F675, PWRT_ON
' Power-On Timer
@ DEVICE pic12F675, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE pic12F675, BOD_ON
' Brown-Out Detect
@ DEVICE pic12F675, CPD_OFF
' Data Memory Code Protect
@ DEVICE pic12F675, PROTECT_OFF
' Program Code Protection

'
' Define Hardware
' ---------------
InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1
'
' Define Variables
' ----------------
DelayTick var Byte ' 100mS Tick Counter

'
' Initialise PIC
' --------------
Reset:
TRISIO=%00100100 ' Preset I/O
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' Disable ADC
DelayTick=0 ' Reset Counter
high OutputLine ' Everything RESET


' pause 4000

' Main Program Loop
' -----------------
Loop:
'
' Test for RESET
' --------------
While InputReset=0 ' Just wait here if RESET
DelayTick=0 ' Reset Counter
high OutputLine ' Reset Output
Wend
'
' Test for Trigger
' ----------------
If InputTrigger=0 then ' Test for Trigger
low OutputLine ' Enable Output
DelayTick=1 ' Arm Counter
'Goto Loop
endif
'
' Timeout Counter
' ---------------
If DelayTick>0 then
DelayTick=DelayTick+1 ' Count Time
Pause 60 ' Waste 100mS
If DelayTick>50 then goto Reset
' 50 = 5 sec
' 100 = 10 sec
' origanly set at 201 Reset at 20 Seconds
endif
Goto Loop

'
End
Reply With Quote

Chris Barron
- 27th March 2009, 13:21
It depnds on what sort of accuracy you need. If it is just a rough gating effect you need then a loop counter will get you there.

PIN_dur var byte

PIN_dur = 0
While Input_Trigger = 0
pause 10 ;10mS pause
if PIN_dur != 255 ;Check time delay isn't 255
PIN_dur = PIN_dur + 1 ;Or it rolls over back to zero
Endif
Wend

Stored in PIN_dur, now, is the number of 10mS periods the button was held down for.

100 x PIN_dur = approx 1 second

If PIN_dur >100 then
goto/gosub long press code
else
goto/gosub shorter press code
endif

You could also use the PULSIN command which measures pulse lengths. Reading the result into a 16-bit variable, and at 4MHz, you can accurately measure to about 0.65 seconds, so yoiu would need to call it twice to get a 1 second push (and gate off the first reading)

Chris

g7jiq
- 30th March 2009, 01:43
Hi Chris

Thanks for your reply,

I get the drift of your coding, (I am still a bit new to this)
Where abouts would you insert it.
( I am using a 4mhz clock)

The i/p trigger would need to be less than one second for no delay and longer than 1 second to trigger the delay,

Cheers
Dave...

Chris Barron
- 31st March 2009, 23:01
Hi Chris

Thanks for your reply,

I get the drift of your coding, (I am still a bit new to this)
Where abouts would you insert it.
( I am using a 4mhz clock)

The i/p trigger would need to be less than one second for no delay and longer than 1 second to trigger the delay,

Cheers
Dave...

Sorry Dave, I think I am reading your desired output in this message to be the inverse of your original message which asked for a delay on the short pulse HIHI.

Can you please explain a little bit more about when you would like the output to be triggered ? Should it trigger immediately when the Input_Trigger pin is down ?

Or do you mean that you don't want there to be any activity at all on the output until after the Input_Trigger has been released ?

Chris
GM4UCD

g7jiq
- 1st April 2009, 00:50
Hi Chris

Sorry I didn't make it clear enough, I do seem to go off running..

Ok lets start at the beginning.

I had a go at sorting out some coding, and was failing, I got sorted out on here and was sent the corrected code, (listed in the first post) This works fine.

What it does is as follows -: (its part of a small local repeater to stop it chattering on a weak/mobile i/p)

When the i/p is triggered (rx) it instantly triggers the o/p (tx), when the i/p drops it gives a 2 second hang before dropping the o/p.
(if the i/p o/p chatters on a mobile/weak signal the problem occurs the when the ctcss delays add up and I hear nothing, the delay stops this happening, I just hear the audio chopping)

What I would like to do is add some coding to allow it to add the delay if the i/p chatters (mobile rx) the i/p re-triggers in say less than 1 second,
If the i/p signal is solid for longer than say 1 second it will remove the delay and drop the o/p as soon as the i/p is removed.

I hope this explains it.

Any ideas,,

Cheers
Dave...

Chris Barron
- 1st April 2009, 12:25
I hope this explains it.

Any ideas,,

Cheers
Dave...

Yes I see what you need now.
I've approached this by starting a timer of 1 second (Delayticks = 100) every time the input is activated, by detecting the high to low transition of the input signal.

On a long (good) signal the timer will elapse after 1 second because there have been no other high to low transitions of the input signal
On a short droppy signal there are lots of high to low transitions, so the 1 second timer keeps being reset.

By buffering the states of pins this way you can isolate high-low and low-high transitions, as well as both-high and both-low conditions. The program doesn't 'stop' in any wait loops so you should be able to add more functions inline, there is just the 10mS pause holding things up every iteration.

It compiles alright. How does it work ?
Chris




'************************************************* ***************
'* Name : UNTITLED.BAS *
'* Author : Chris Barron *
'* Notice : Copyright (c) 2009 Chris Barron *
'* : All Rights Reserved *
'* Date : 01/04/2009 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************
'************************************************* * *************

'G7JIQ MICRO LINK REPEATER
'PIC 12F675
'Internal RC clock
'
' PIC Defines
' -----------
@ DEVICE pic12F675, INTRC_OSC_NOCLKOUT
' System Clock Options (Internal)
@ DEVICE pic12F675, WDT_ON
' Watchdog Timer
@ DEVICE pic12F675, PWRT_ON
' Power-On Timer
@ DEVICE pic12F675, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE pic12F675, BOD_ON
' Brown-Out Detect
@ DEVICE pic12F675, CPD_OFF
' Data Memory Code Protect
@ DEVICE pic12F675, PROTECT_OFF
' Program Code Protection

'
' Define Hardware
' ---------------
InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1

'
' Define Variables
' ----------------
DelayTick var Byte ' 100mS Tick Counter
myflags var byte
'
' Initialise PIC
' --------------
Reset:
TRISIO=%00100100 ' Preset I/O
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' Disable ADC
DelayTick=100 ' Reset Counter
myflags = 0
high OutputLine ' Everything RESET



' Main Program Loop
' -----------------
Loop:
'
' Test for RESET
' --------------
While InputReset=0 ' Just wait here if RESET
high OutputLine ' Reset Output
myflags = 0
DelayTick = 100
Wend

' We're using the lower 2 bits of the 'myflags' register to store the state of
' the input pin over the last two program loop iterations
' myflags.0 stores the current pin state and myflags.1 stores the previous
'state.
myflags.1 = myflags.0 ' Move the last 'current state' into the 'last state' bit
myflags.0 = InputTrigger ' Store the current state

' By storing the two states we can detect the transition from high to low
' A high to low transition = 00000010 = decimal 2
' A low to high transition = 00000001 = decimal 1

if myflags = 2 then
DelayTick = 100 ' A high to low transition, reset the delay
else
if delaytick > 0 then delaytick = delaytick - 1
endif

pause 10 ' adjust to get the resolution required (10 x DelayTick = total hang time)

if inputtrigger = 0 then low OutputLine; if input is active set output active

if ((inputtrigger = 1) and (Delaytick = 0)) then high outputline

goto loop:

g7jiq
- 2nd April 2009, 01:03
Hi Chris

That looks great, Many thanks,

I will blow it to pic tomorrow and give it a try, and let you know how it go's.

Thanks again
Dave...

g7jiq
- 3rd April 2009, 18:52
Hi Chris

I have given it a try, and nothing happens,
I get no errors on programming etc, but nothing.

I have changed the control pins around as you have used a different orientation, wonder why this was? any reason,

All looks fine as far as I can see.

?????

Cheers
Dave.

Chris Barron
- 4th April 2009, 09:11
Hi Chris

I have given it a try, and nothing happens,
I get no errors on programming etc, but nothing.

I have changed the control pins around as you have used a different orientation, wonder why this was? any reason,

All looks fine as far as I can see.

?????

Cheers
Dave.
Not sure what you mean by a change in pin orientation? Could you explain what it was you neded to change.

Chris

g7jiq
- 4th April 2009, 12:38
Hi Chris

My pin out was

InputTrigger var GPIO.0 ' Input normally HIGH, goes LOW to Trigger
Output0 var GPIO.1 ' Normally high, goes low when triggered
Output1 var GPIO.2 ' Normally high, goes low when triggered
'

You changed it to

InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1

The pinouts in my circuit (GPIO.0 , 1, 2 ) were transposed to ( GPIO.5, 2, 0, 1 )
The i/p and o/p are switched around, the trigger is on GPIO.0 you have it on GPIO.5, this is unused on my i/c, I also don't have a led (but I can add one tho if needed)



Cheers
Confused Dave..

Acetronics2
- 4th April 2009, 13:54
Hi, G7

Just think a while ...

What you ask is to know IN ADVANCE if your input will be shorter or longer than 1 second ...

You can't know that before the second is elapsed ...

Just my two cents ...

Alain

Chris Barron
- 4th April 2009, 17:54
Hi Chris

My pin out was

InputTrigger var GPIO.0 ' Input normally HIGH, goes LOW to Trigger
Output0 var GPIO.1 ' Normally high, goes low when triggered
Output1 var GPIO.2 ' Normally high, goes low when triggered
'

You changed it to

InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1

The pinouts in my circuit (GPIO.0 , 1, 2 ) were transposed to ( GPIO.5, 2, 0, 1 )
The i/p and o/p are switched around, the trigger is on GPIO.0 you have it on GPIO.5, this is unused on my i/c, I also don't have a led (but I can add one tho if needed)



Cheers
Confused Dave..


Sorry Dave but, the code I used was the code in your original message, and pin assignements are clearly listed there the same as they were in my reply

' Define Hardware
' ---------------
InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1
'

The assignments in my reply are the same as in your first message on this thread. I can only think that your copy of the program has either merged together this file with another (Did yiou cut and paste ?) or something else is wrong.

Either way I happy that my reply and your first message use the same pinouts, as you will see when you check for yourself

g7jiq
- 4th April 2009, 21:30
Hi Chris

Beg your pudin, its been driving me mad for weeks, (I got in a right mess, thus the reason for the post on here)
I did cut and paste (several times) I have about 9 versions of the code here.
The mix up is I had cut pasted the original code from here for my 1st message,
I had changed it around to match my circuit, both did work ok.
(maybe I should had given up and gone down the pub)


With a clear head I have re programed the pic,
I have tried in my circuit and also bread boarded it.
Here's what I get when powered up,

GP0.0 high no change
GP0.1 low no change
GP0.2 high no change
GPO.3 high no change
GPO.4 high no change
GPO.5 high/low trigger (i/p toggle)

Your coding is re pasted below so you can check nothing was corrupted in the copy/past process.

Cheers..

'************************************************* ***************
'* Name : UNTITLED.BAS *
'* Author : Chris Barron *
'* Notice : Copyright (c) 2009 Chris Barron *
'* : All Rights Reserved *
'* Date : 01/04/2009 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************
'************************************************* * *************

'G7JIQ MICRO LINK REPEATER
'PIC 12F675
'Internal RC clock
'
' PIC Defines
' -----------
@ DEVICE pic12F675, INTRC_OSC_NOCLKOUT
' System Clock Options (Internal)
@ DEVICE pic12F675, WDT_ON
' Watchdog Timer
@ DEVICE pic12F675, PWRT_ON
' Power-On Timer
@ DEVICE pic12F675, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE pic12F675, BOD_ON
' Brown-Out Detect
@ DEVICE pic12F675, CPD_OFF
' Data Memory Code Protect
@ DEVICE pic12F675, PROTECT_OFF
' Program Code Protection

'
' Define Hardware
' ---------------
InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1

'
' Define Variables
' ----------------
DelayTick var Byte ' 100mS Tick Counter
myflags var byte
'
' Initialise PIC
' --------------
Reset:
TRISIO=%00100100 ' Preset I/O
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' Disable ADC
DelayTick=100 ' Reset Counter
myflags = 0
high OutputLine ' Everything RESET



' Main Program Loop
' -----------------
Loop:
'
' Test for RESET
' --------------
While InputReset=0 ' Just wait here if RESET
high OutputLine ' Reset Output
myflags = 0
DelayTick = 100
Wend

' We're using the lower 2 bits of the 'myflags' register to store the state of
' the input pin over the last two program loop iterations
' myflags.0 stores the current pin state and myflags.1 stores the previous
'state.
myflags.1 = myflags.0 ' Move the last 'current state' into the 'last state' bit
myflags.0 = InputTrigger ' Store the current state

' By storing the two states we can detect the transition from high to low
' A high to low transition = 00000010 = decimal 2
' A low to high transition = 00000001 = decimal 1

if myflags = 2 then
DelayTick = 100 ' A high to low transition, reset the delay
else
if delaytick > 0 then delaytick = delaytick - 1
endif

pause 10 ' adjust to get the resolution required (10 x DelayTick = total hang time)

if inputtrigger = 0 then low OutputLine; if input is active set output active

if ((inputtrigger = 1) and (Delaytick = 0)) then high outputline

goto loop:

Chris Barron
- 4th April 2009, 21:43
Hi Chris

Beg your pudin, its been driving me mad for weeks, (I got in a right mess, thus the reason for the post on here)

It's alright Jeff,
I am merely interested to know if it works or not, and if not, what is the problem and I will try to help to rectify it.

Cheers
Chris

g7jiq
- 10th April 2009, 00:14
Hi Chris

Is there any updates yet, Have you got it working??

Cheers...

Chris Barron
- 10th April 2009, 09:08
Hi Chris

Is there any updates yet, Have you got it working??

Cheers...

Sorry Jeff , I have been wating for you to tell me what is wrong with it (as in what it does or does not do correctly.)

I am very busy for a few days so you may better off doing some debugging of yoiur own in the meantime. If you have enough spare pins you can attach an led to each pin and activate the leds as the program reaches each section.....when the leds stop lighting is where the problem lies.
If you're short of pins, possibly you are, I usually write a small flashing led sequence and change the number of flashes for each part of the program and that way I always know where the program reached, but if you're going to debug with picbasic you could easily just use the 'debug' command and send serial data out to your PC to tell you where the program stopped.

g7jiq
- 10th April 2009, 22:01
Hi Chris,

It doesn't do anything, (by the way the names dave)

I have re programed the pic, (it programs fine with no errors)
I have tried in my circuit and also bread boarded it.
Here's what I get when powered up,

The pins of the i/c are as follows:-

GP0.0 high no change
GP0.1 low no change
GP0.2 high no change
GPO.3 high no change
GPO.4 high no change
GPO.5 high/low trigger (i/p toggle)

Cheers
Dave..

Melanie
- 10th April 2009, 22:31
One step at a time...

Compile this and ensure your LED blinks on GPIO.1... ensure your LED has a suitable series Resistor...



'
' PIC Defines
' -----------
@ DEVICE pic12F675, INTRC_OSC_NOCLKOUT
' System Clock Options (Internal)
@ DEVICE pic12F675, WDT_ON
' Watchdog Timer
@ DEVICE pic12F675, PWRT_ON
' Power-On Timer
@ DEVICE pic12F675, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE pic12F675, BOD_ON
' Brown-Out Detect
@ DEVICE pic12F675, CPD_OFF
' Data Memory Code Protect
@ DEVICE pic12F675, PROTECT_OFF
' Program Code Protection

'
' Define Hardware
' ---------------
InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
LED var GPIO.1

'
' Define Variables
' ----------------
DelayTick var Byte ' 100mS Tick Counter
MyFlags var byte

'
' Initialise Hardware
' -------------------
TRISIO=%00100100 ' Preset I/O
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' Disable ADC
DelayTick=100 ' Reset Counter
MyFlags=0
High OutputLine ' Everything Reset

'
' Main Program Loop
' -----------------
Loop:
Pause 500
Toggle LED
Goto Loop

End

g7jiq
- 11th April 2009, 20:50
Hi Melanie

Thanks for your reply,

Yes my led blinks ok.

Cheers
Dave...

g7jiq
- 11th April 2009, 23:26
Hi Melanie

Just an addon to the above test, which worked fine,,,

Last year you very kindly drafted me a piece of code for a project that has been working flawlessly,

I am having problems adding an led command to it, if I add an low led command to it, it locks up when its triggered.

Any ideas,

Cheers
Dave..

'G7JIQ MICRO LINK REPEATER
'PIC 12F675
'Internal RC clock
'
' PIC Defines
' -----------
@ DEVICE pic12F675, INTRC_OSC_NOCLKOUT
' System Clock Options (Internal)
@ DEVICE pic12F675, WDT_ON
' Watchdog Timer
@ DEVICE pic12F675, PWRT_ON
' Power-On Timer
@ DEVICE pic12F675, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE pic12F675, BOD_ON
' Brown-Out Detect
@ DEVICE pic12F675, CPD_OFF
' Data Memory Code Protect
@ DEVICE pic12F675, PROTECT_OFF
' Program Code Protection

'
' Define Hardware
' ---------------
InputTrigger var GPIO.5 ' Input normally HIGH, goes LOW to Trigger
InputReset var GPIO.2 ' Input normally HIGH, goes LOW to RESET
OutputLine var GPIO.0 ' Normally HIGH, goes LOW when triggered
Led var GPIO.1
'
' Define Variables
' ----------------
DelayTick var Byte ' 100mS Tick Counter

'
' Initialise PIC
' --------------
Reset:
TRISIO=%00100100 ' Preset I/O
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' Disable ADC
DelayTick=0 ' Reset Counter
high OutputLine ' Everything RESET
pause 2000

' Main Program Loop
' -----------------
Loop:
'
' Test for RESET
' --------------
While InputReset=0 ' Just wait here if RESET
DelayTick=0 ' Reset Counter
high OutputLine ' Reset Output
Wend
'
' Test for Trigger
' ----------------
If InputTrigger=0 then ' Test for Trigger
low OutputLine ' Enable Output
DelayTick=1 ' Arm Counter
'Goto Loop
endif
'
' Timeout Counter
' ---------------
If DelayTick>0 then
DelayTick=DelayTick+1 ' Count Time
Pause 60 ' Waste 100mS
If DelayTick>50 then goto Reset
' 50 = 5 sec
' 100 = 10 sec
' origanly set at 201 Reset at 20 Seconds
endif
Goto Loop

'
End

Melanie
- 12th April 2009, 11:09
OK, that's good, we know the PIC works...

Now from your Posts I assume the following...

1. InputTrigger goes Low... this causes OutputLine to go Low
2. If the InputTrigger < 1 Second then OutputLine is held on by DelayTime
3. If the InputTrigger => 1 Second then DelayTime is Terminated
4. And you want a Blinky

Thinking about it... is it as simple as the following conditions (this isn't PBP code btw)...

If InputTrigger < DelayTime then OuputLine = DelayTime
If InputTrigger => DelayTime then OutputLine = InputTrigger

?

Chris Barron
- 12th April 2009, 14:53
OK, that's good, we know the PIC works...

Thinking about it... is it as simple as the following conditions (this isn't PBP code btw)...

If InputTrigger < DelayTime then OuputLine = DelayTime
If InputTrigger => DelayTime then OutputLine = InputTrigger

?

That seems to be the goal (That's what i read into it anyway)

The output signal of the RF repeater is switched when the input signal is switched, but sometimes the received signal can be 'choppy' (Like any mobile radio signal, the signal strength varies wildly depending on terrain and the movement of the antenna)

If the input signal is very short it is assumed to be a choppy signal, and the output is held on because if the signal is choppy it will be restored very soon. The idea seems to be to keep the output RF stages switched on so that they transmit in the 'dropout' period too for the case of a choppy input signal.

If I get a chance later I'll flash the code I wrote into a pic and see what happens.

In the meantime,Dave (Don't know where Jeff came from !) sticking with the LED flashing diagnostic technique, each subsection of the program can be modified to flash the led for a different number of times, that way you will know which sections of the program are being run and which aren't

As another idea, if you are using a pickit2 to program it has a great serial USART device built in which saves you having to build a level convertor and that would let you SEROUT messages to it (for display on the PC) which could tell you where the program execution goes.

Chris

Melanie
- 12th April 2009, 18:11
The output signal of the RF repeater is switched when the input signal is switched, but sometimes the received signal can be 'choppy' (Like any mobile radio signal, the signal strength varies wildly depending on terrain and the movement of the antenna)


That doesn't equate to the new requirement as described... if for example you have had good reception for say 5 seconds and then your signal starts to break up, because the DelayTime has elapsed the repeater will disengage immediately. You should have your Repeater timeout only START at the end of reception and if reception is re-enabled within the timeout period, then you simply go back to the start with the Transmitter still holding on. That way, as long as reception re-occurs within the 1 Second Time-Delay the repeater is still held on... so this now becomes (in a simplified form)...

Loop:
If InputTrigger=0 then OutputLine=0
If InputTrigger=1 and TimeDelay>1Second then OutputLine=1
Goto Loop

You should also consider a secondary feature... an additional timeout to disengage the Transmitter regardless if it has been held on for say 15 minutes continuously (in case of some localised lock-up in the repeater receiver from it's own transmitter).

Chris Barron
- 12th April 2009, 23:28
That doesn't equate to the new requirement as described... if for example you have had good reception for say 5 seconds and then your signal starts to break up, because the DelayTime has elapsed the repeater will disengage immediately. You should have your Repeater timeout only START at the end of reception and if reception is re-enabled within the timeout period, then you simply go back to the start with the Transmitter still holding on. That way, as long as reception re-occurs within the 1 Second Time-Delay the repeater is still held on... so this now becomes (in a simplified form)...

Loop:
If InputTrigger=0 then OutputLine=0
If InputTrigger=1 and TimeDelay>1Second then OutputLine=1
Goto Loop

You should also consider a secondary feature... an additional timeout to disengage the Transmitter regardless if it has been held on for say 15 minutes continuously (in case of some localised lock-up in the repeater receiver from it's own transmitter).


I thought it a good idea to just keep the one second delay too, but for some reason it seems to have caused Dave a problem not to have. You make a very good point regarding a good signal transitioning into a bad one over the course of one reception period, and that alone probably justifies keeping the delay on all transmissions.

Often you hear amateur operaters stop transmitting to check if they still have the repeater control, which indicates that the TX signal is still strong enough to keep the repeater's RX output switch engaged

The tx/rx lockup prevention is already taken care of by the rx/tx frequency offset, which is 0.6MHz for the 2m band (144-146 MHz) and 1.6Mhz (or 7.6MHz) offset for the 70cm band (430-440MHz approx)

g7jiq
- 13th April 2009, 01:09
Hi Melanie and Chris

Many thanks for all your input,
Yes your final configs are about right, both of you added points I hadn't thought of,

(The repeater controller is for a small low power unit, the timeout/lockup watchdogs are incorporated in the main radios, so are not required.)

1. InputTrigger goes Low... this causes OutputLine to go Low
2. If the InputTrigger pulses at anytime that InputTrigger is Low < 1 Second then OutputLine is held on by DelayTime
3. If the InputTrigger => 1 Second then DelayTime is Terminated
4. And I want a Blinky for diagnostic.
5. If possible an led to display whether the delay has been triggered, (this would be an added diagnostic function and a help when setting the rx radio up)

It needs to self monitor for InputTrigger pulses for as long as InputTrigger is Low, and self cancel if InputTrigger stops pulsing.

Hope this is makes sense,

Cheers
Dave..

Melanie
- 13th April 2009, 13:32
OK, it's not the way I would do it... but I can see your logic...

As long as InputTrigger keeps pulsing, the Delay Timer keeps resetting back to the start as long as the Delay Time hasn't already expired, during this time OutputLine will be kept Low. If the Delay Time has expired then on the first occasion InputTrigger goes High, then so does OutputLine.

You have a 2Hz Blinky (which stops whilst you do an Input Reset).

And you have a DelayLED for your Diagnostic purposes...

g7jiq
- 13th April 2009, 22:50
Hi Melanie

Many many thanks for the code,
I have given it a try, (like the diagnostic leds)
Just a small thing,
Can you tell me where the hang delay value is, and for some reason I get a delay nearly all the time, even after a 30 sec TriggerInput. Any ideas..??

Apart from that its just what I was looking for.


Thanks again,
Cheers
Dave...

Melanie
- 13th April 2009, 23:05
Don't know what you're doing... I just breadboarded to test what I wrote and it works as expected. The DelayLED goes out if InputTrigger is constantly ON (solid ON) for 1 Second (that's active pulled LOW). If InputTrigger fluctuates, then DelayLED will be on all the time. You got AC coming down the line into InputTrigger? You forgot you need external Pull-Up's on the InputReset and InputTrigger?

The Delay value is one of the two Constants defined at the start. Change that to change the Timeout.

g7jiq
- 14th April 2009, 23:29
You don't know whats going on?? I wish I knew..

Sorry to be a pain, But this is doing my head in.....
It must be something silly Im doing,

I have blown it to a second pic in case it was faulty,
I have checked for any mains hum or Rubbish on the input/output lines, all seem good.

I have pullup/pulldown resistors, caps on power rails etc,
mmmmm what pullup resistor values do you suggest,,?? I have 4k7 and 10k,,, are these to high, ?? (they seem to work elsewhere)
The 8 pin pics seem to be a bit touchy I find,, what am I doing wrong.

When it is in standby (no i/p) the led is on and the heartbeat is flashing,
When I give an i/p of 30 seconds the led go's off and then on after 1 second,
I get a o/p delay of 5 seconds, and sometimes 10 seconds.

The blinky works fine and it resets any delay when called.

I have tested it with a chattering i/p and found it sometimes it drops out instantly, and other times it can hang for anything up to a 45 or more seconds.
(I locked it up playing oops, it took 2 mins to drop out)

I have run it up out of the unit (as its on a sub board) to eliminate RF etc,

The only thing I keep going back to is the resistors,,,
By the way the i/p is being driven via an opto isolator (it seems to be a clean 5v to 0v switch)

Cheers
Dave..

Chris Barron
- 15th April 2009, 01:47
You don't know whats going on?? I wish I knew..

The only thing I keep going back to is the resistors,,,
By the way the i/p is being driven via an opto isolator (it seems to be a clean 5v to 0v switch)

Cheers
Dave..

Dave, do you really need to invoke the WDT ?
Also, I have had problems with the MCLR define (in MPLAB, not picbasic) working inversely. When set to off it needed a pullup ! Bizarre


Chris

Melanie
- 15th April 2009, 10:02
Make a girl work why don't you!

1. I downloaded the Repeater.TXT file from the forum and renamed it Repeater.BAS

2. I compiled it with PBP 2.46

PBP -p12F675 Repeater -v

3. I drew the test schematic and posted it here

4. I breadboarded it

5. I tested it

6. I documented it



It works as expected thus...

A. When SW2 is pressed OUTPUTLINE illuminates along with DELAYLED.

B. If SW2 is released within one Second, DELAYLED and OUTPUTLINE still remain illuminated until one Second expires - then both go out.

C. If SW2 is held beyond one Second, DELAYLED goes out at the one Second count, but OUPUTLINE remains illuminated for as long as SW2 is held. The instant SW2 is released OUTPUTLINE goes out.

D. If SW2 is pulsed within it's initial one Second period, both DELAYLED and OUTPUTLINE remain illuminated (and the one Second count keeps being reset) until the pulsing stops. Thereafter either condition B or C will apply.

E. If SW1 is pressed, all LEDS go out - including BLINKY until SW1 is released.

F. BLINKY tells you you've paid your electricity bill unless condition E applies.



If yours don't work like that then...

1. Breadboard my test schematic and run it...

2. Check your Supply +5v is good... (you don't need anything on your MCLR pin unless your programmer isn't programming the CONFIGS properly).

3. Check your INPUTTRIGGER with a scope... is it waving about keeping the DELAYTIME (DELAYLED) running (per condition D above)? This is the ONLY thing that I can think of immediately that would cause your PIC to malfunction the way you describe.

g7jiq
- 15th April 2009, 23:44
Hello again,

Sorry to put you to all this, Its very much appreciated.

I have run up the circuit as your diagram,
I think I may be on the right trail of the problem.
As you have it it does nothing,
I have to add a pullup 4k7 to the MCLR pin, like on the 16F84 ( I have always done this)

It looks like my programmer isn't set correctly (as you rightly said)
Looks like we've found it... (I do hope this is it)

My programmer is a K149-BC USB programmer, (don't know if you know of it)

I have fuse settings, I don't really know what they do, and the help doesn't really help.

My fuse edit screen has the following.

WDT this is enabled
MCLRE this is disabled ( could it be this....!!!!)
Code protect ROM this is disabled
Bandgap this is set to highest
PWRTE this is enabled (I know what this does)
BODEN this is enabled
Code Protect EEP this is disabled (I know what this does)
Oscillator INTOSC IOGP4 IOGP5 (I know what this does)

Any ideas on the other ones,
I have programmed 16F84's, 16F627's etc all set as default, and these have been fine.


Thanks again,
Cheers
Dave..

Melanie
- 16th April 2009, 08:34
I can't answer questions on your programmer as I don't have one.

Your CONFIG settings should match those preset into the program, but whether your programmer is actually programming them is another qustion.

If MCLR needs a pull-up, then the CONFIGS sure don't match (or yor PIC is broke)... it could be there's another tick-box in your software for your programmer that needs activating. My software for example has the ability to program the PIC and leave the CONFIGS untouched unless I've set it on another screen. This also means that GPIO4 could have OSC coming out of it instead of it being used for I/O.

Worst case scenario is I can send you my PIC, but it means you can't make changes if your programmer is misbehaving.

g7jiq
- 17th April 2009, 01:40
Hi Melanie,

Some very good news, I managed to get it sorted,
It works superb,

The problem I had was two fold,
The first one was the configs fuse settings, It now works without the 4k7 pullup resister on the MCLR pin. (just as you said)

It would then work in the breadboard fine but not in my circuit,

To cut a long story short,
When I lifted the output pin and dropped an led on it, it worked fine,

So.... I found that,

The pic's output drives an opto and led in series, with a 470 ohm to the 5v rail.
The pic also feeds an input to another pic, (which drives my lcd)
Somehow there wasnt enough current to drive the circuit even tho there should have been,
so I fitted another opto isolator as a buffer and this sorted it.

What a run around,

Many many thanks for all your help and patience, your a star...

Cheers
Dave...

Archangel
- 17th April 2009, 01:55
2 rules in this forum:
#1. Never doubt Melanie.
#2. Go back to Rule #1

g7jiq
- 17th April 2009, 08:46
I never doubted her in the first place,
I just couldn't see the wood for the trees....

Chris Barron
- 17th April 2009, 19:19
I never doubted her in the first place,
I just couldn't see the wood for the trees....

Out of interest Dave, did you try inverting the MCLRE config assignment ?

The only reason I suggested it may be a problem was because I had a similar problem once. Now that you mention whcih programmer you used I recall that was the same programmer I had when I had the problem. (Did you know you can upgrade the firmware of that thing to the latest version to make it cover more pics with more memory etc ? it's worth looking into.)

As for the led and the opto in series, you had a 470ohm resistor across 0.4V, which means the current limiting was in the order of I=V/R = 0.4/470 = 0.00085 A (850uA microamps)

That's not normally enough to drive anything requiring a strong switching signal, though most TTL circuits should cope.