Help with Pic Delay Pulse code please

[g7jiq]

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]

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]

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]

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]

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]

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]

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]

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

[Melanie]

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]

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]

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]

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]

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]

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