12f675_fuse_about_to_blow!

[mackrackit]

So either the data arrives twice within the 65ms time period to move onto DECODE or my understanding of MATCH = MATCH + 1 is wrong.

Not within the 65ms but just twice. MATCH does not get set to zero until DECODE is reached.
One good set of data could arrive then many not-goods, then one more good THEN DECODE.

Being this came from Bruce it is hard for me to question it but....
Here is what I think it should be

    ' Test new checksum against one received in CHK_SUM
    IF CheckSum != CHK_SUM THEN MAIN ' Failed checksum, return
    MATCH = MATCH + 1        ' We have a match so increment match count

    ' Test data bytes for match
    IF (DAT_IN1) != (DAT_IN2) THEN MAIN ' Failed data comparison, return
    MATCH = MATCH + 1        ' We have a match so increment match count

    IF MATCH = 2 THEN DECODE ' Everything matched twice, we're good
    GOTO Main                ' Else do it all over

[LEDave]

Far more intuitive for a newbie your way mackrackit. I would have been stuck in a loop looking for a second MATCH until my watchdog timer kicked in (that's not to say Bruce's program isn't pure genius from where I'm sitting).

I'm thinking that if one MATCH had occurred but was followed by bad data, then the ASM :

clrf   MATCH         ; Clear match variable

would reset the single MATCH to zero after 65ms?

Onto DECODE then.

Dave

[LEDave]

  ' hardware init
    PORTA = 0
    TRISA = %00111001   ' RA1 and RA2 are LED outputs

So PORTA.1-2 are outputs

And BYTES received will be

%10101011 or %10101101

PORTA = DAT_IN1 & %00000110

The manual says:Bitwise Operators: & %00000001 ' Isolate bit 0 of BYTE.

So I'm thinking: & %00000110 ' Isolate bits 1 & 2, would give:

%00000010 from %10101011 & %00000100 from %10101101 as PORTA, depending on which button was pressed and light the LED's.

Hot, cold or tepid?

Dave

[mackrackit]

Hot, cold or tepid?

Hot
Looks like you got it.

BTW, I missed

clrf   MATCH         ; Clear match variable

So the original code would have to receive two good with out a bad. I wonder why Bruce did it that way?

[LEDave]

Cheers mackrackit

So the original code would have to receive two good with out a bad. I wonder why Bruce did it that way?

I don't know.....

One thing though, from Bruce's code (and please bear in mind this is the thinking of a newbie here).The only way(as I see it) that MATCH can ever reach a count of two and then move onto 'DECODE' is for the program to run from 'SERIN2' all the way to 'GOTO Main' once and then a second time to 'IF MATCH = 2 THEN DECODE' for MATCH to ever equal 2. Am I missing something here?

' Wait for Synch byte, then get new inbound data & checksum
    SERIN2 D_IN,N2400,[WAIT(Synch),DAT_IN1,DAT_IN2,CHK_SUM,TEST]
    
    T1CON.0 = 0    ' Stop Timer1 once we've received data
    TMR1L = 0      ' Clear low byte
    TMR1H = 0      ' Clear high byte
    
    ' / **** Begin data validation **** /
    
    ' Calculate checksum by adding 2 data bytes together
    CheckSum = DAT_IN1 + DAT_IN2
    
    ' Test new checksum against one received in CHK_SUM
    IF CheckSum != CHK_SUM THEN MAIN ' Failed checksum, return
    
    ' Test data bytes for match
    IF (DAT_IN1) != (DAT_IN2) THEN MAIN ' Failed data comparison, return
    
    MATCH = MATCH + 1        ' We have a match so increment match count
    IF MATCH = 2 THEN DECODE ' Everything matched twice, we're good
    GOTO Main                ' Else do it all over

Dave

[mackrackit]

One thing though, from Bruce's code (and please bear in mind this is the thinking of a newbie here).The only way(as I see it) that MATCH can ever reach a count of two and then move onto 'DECODE' is for the program to run from 'SERIN2' all the way to 'GOTO Main' once and then a second time to 'IF MATCH = 2 THEN DECODE' for MATCH to ever equal 2. Am I missing something here?

Yep, that is what I see also.
Maybe Bruce set this up to test how reliable the connection is? If it can do two before the interrupt time out then the connection is solid.

[LEDave]

Maybe Bruce set this up to test how reliable the connection is? If it can do two before the interrupt time out then the connection is solid.

Yes, could well be.

Well I've learnt a lot from going through the TX / RX program code.

There were a lot of new terms which I hadn't come across (very clever in what they did / do though) which all adds to the knowledge base.

So to summarise:

The TX is an Interrupt_On_Change program which sleeps to save power until a button press is received.

The RX is a Timer(65ms) Interrupt_loop, which resets if no Data_In is received within the time period.

Just to be clear in my own mind here, there are two ways to reset the RX Interrupt Timer. One in Main:

 T1CON.0 = 0    ' Stop Timer1 once we've received data
    TMR1L = 0      ' Clear low byte
    TMR1H = 0      ' Clear high byte

Which does it when Data is received (TMR1L/H will have a value of less that 65536 before reset).

The other in the Interrupt_Handler 'RESET_VT' which the program would jump to on a Time_Out.

If the above is accurate and makes sense, then in the time honoured tradition:

What's next?

Dave

[mackrackit]

What's next?

Send some data other than LED on/off stuff and display the received data on a terminal and/or save to EEPROM.

[LEDave]

Send some data other than LED on/off stuff and display the received data on a terminal and/or save to EEPROM.

Ah, the TX project program begins............

[LEDave]

I've made a few changes to the TX / RX programs. I can now send a BYTE called TEST with the value 7, which is received and flashes an LED to the value of the BYTE.

I know I'm the probably the only person on this FORUM who didn't know if this would work but I thought why not make the count 1 TO n the value of TEST and it worked a treat.

lED:
   for X = 1 to TEST  'Test=7
    HIGH PORTA.1  
    PAUSE 500
    LOW PORTA.1
    pause 500
    next X
    GOTO MAIN

Another step forward.

Dave

[mackrackit]

COOL!!!
Do you have it set up so one button sends a value and the other button sends a different value?

[LEDave]

Hi mackrackit,

Do you have it set up so one button sends a value and the other button sends a different value?

No, not at present. At the moment either button press will send the value seven (I've made a few code changes), the receiver code then runs the loop and counts / flashes the led seven times.The test is the value sent & received must = 7 or nothing will happen (and it does).....

[LEDave]

I found this on a nest box website regarding the number of visits or rather the amount of food the parents bring to the young:

Each chick can eat 100 caterpillars a day, so adults need to find as many as 1000 caterpillars a day for a brood of 10!

So with this in mind a WORD would be needed as a counter, so I've modified the code to send a WORD instead of a BYTE and added a test number (600):

TEST   VAR word 

LET Test = 600

SEROUT2 D_OUT,BAUD,[PreAmble,Synch,DAT_OUT,DAT_OUT,CHK_SUM,TEST.HIGHBYTE,TEST.LOWBYTE]

And for the receiver:

TEST  var word  

X   VAR BYTE

SERIN2 D_IN,N2400,[WAIT(Synch),DAT_IN1,DAT_IN2,CHK_SUM,TEST.HIGHBYTE,TEST.LOWBYTE]

 IF TEST = 600 THEN  LED    
    GOTO MAIN 
   
lED:
   for X = 1 to TEST  'Test = 600
    HIGH PORTA.1  
    PAUSE 500
    LOW PORTA.1
    pause 500
    next X
    GOTO MAIN 
       
    END

And it works, the led flashes 600 times (I know I've counted them)

Another small step nearer.

Dave

[mackrackit]

And it works, the led flashes 600 times (I know I've counted them)

That is a heck of a lot of caterpillars!!!!!!

[LEDave]

That is a heck of a lot of caterpillars!!!!!!

Lol...........Can't be too careful here though, checkout the link below

http://www.arkive.org/cuckoo/cuculus...video-09c.html

I need to do some thinking for the next part of the program. I'm going to need another pin as an input for the counter from the sensor and another pin as an input from an LDR to tell the PIC when it's dark and send the days count_data over. I guess I won't be able to use the two pins with buttons on (GPIO.3/4).

Question: How quick does a PIC wake_up from sleep with an IOC?

Steadily moving along.

Dave

[mackrackit]

That bird doing the feeding better not fall into the nest, it might end up being lunch...

Question: How quick does a PIC wake_up from sleep with an IOC?

@SLEEP
From a data sheet

The power-down Status bit, PD is
cleared. Time-out Status bit, TO
is set. Watchdog Timer and its
prescaler are cleared.
The processor is put into Sleep
mode with the oscillator stopped.

But even though the OSC is stopped the IOC pin(s) are still active. When the changes occurs the device "wakes up".

The PBP SLEEP command is different. The device will sleep for a given time period.

So I think to answer the underlying question... You only need one of the buttons.

[LEDave]

Thanks for that mackrackit.

I was thinking that the TX will work in a kind of fully automatic mode, no actual button pressing to transmit the days data_count over. The trigger for this would be the LDR sensing it's dark(so no more feeds / visits) turning a pin high that then triggers the transmit.

This the pin-out as is stands is below:

GPIO.0 - Pot - R1
GPIO.1 - Pot - R2
GPIO.2 - Data_out
GPIO.3 - SW2
GPIO.4 - SW1
GPIO.5 - RF_Enable

So I'm thinking I need two more input pins (one for the sensor the other for the LDR) Pots R1 - R2 look favourite to me, do you think they'd be ok as inputs.

Dave

[mackrackit]

Maybe I am missing something..
Do you want data sent at each sensor trigger?
Have the sensor on one of the pins currently used for a switch.

[LEDave]

Hi mackrackit

Do you want data sent at each sensor trigger?

No I don't think so, a whole days visits in one transmit will do the job.

Have the sensor on one of the pins currently used for a switch.

Well initially I thought ah, just bye-pass the switch then thought I can't do that as it's in series with the pin but once again you inspire me mackrackit, RA3 / 4 bye-pass the switches straight onto GPIO.3 / 4 the switches are connected to ground when pressed (if that makes sense) so looking good to go.

That bird doing the feeding better not fall into the nest, it might end up being lunch...

I know, you gotta feel for the feeder, overworked or what

I almost forgot, I've had a look at RS / Maplins for a product similar to header J3, it would be really handy to be able to just plug the RX / TX modules in and out but can't find anything, I'm going to email Microchip and ask them for a UK supplier and spec.

Dave

[mackrackit]

Do you have mouser over there?
If so look at type "D"
http://www.mouser.com/catalog/catalogUSD/642/1419.pdf

[LEDave]

Mouser Electronics
Artisan Building
Suite C, First Floor
Hillbottom Road
High Wycombe
Buckinghamshire
HP12 4HJ
United Kingdom

Looks like we do

I'll just double check, this is the part? (see attachment) I'll be onto then tomorrow (I wonder if they do a 90 degree one?).

You're a star mackrackit.

Dave

[LEDave]

Have got the night time trigger to send the Visits_total over from the TX to RX working.

It works on a 555 timer chip instead of an op-amp Schmitt trigger (very handy same voltage for 555 & PIC).The cct dia is below(see attachment). Only needed to add an ORP12 - LDR and a 10k resistor across the input, might have to tweak the resistor value but works a treat with my hand acting as approaching darkness.

Another step forward.

Dave

[mackrackit]

COOL!!!!

Not having seen your code so maybe you have this or considered this...

It is easy to have false triggers when sensing light, sensing "dark" at dusk could give trouble. You may want to incorporate a timer of some kind not to send the data until you are "sure" it is dark. The dark trigger has to be active for 30 minutes???

What if there is a bug on the sensor?? A real bug...

[LEDave]

Hi mackrackit

It is easy to have false triggers when sensing light, sensing "dark" at dusk could give trouble. You may want to incorporate a timer of some kind not to send the data until you are "sure" it is dark. The dark trigger has to be active for 30 minutes???

Mm, how about sending the PIC back to SLEEP awaiting another Interrupt_On_Change (the birds have started visiting again it was only a cloud) so carry on counting. If after say SLEEP 1800(about half an hour) the LDR is still high then Send_Data it really is dark!

What if there is a bug on the sensor?? A real bug...

Oh dear, Badgers I don't mind (even Bears seem kind of cuddly) but bugs!!!

I think the code would have to be something like:

IF Count_Input_Pin is HIGH for >50ms THEN SEND:

SEND:

'Mrs LEDave  into the garden and clean the sensor.

RETURN.

That's an interesting point though because the Birds don't always fly straight into the nest box they quite often hang by the hole then enter so the timing(or lenght of time) of the INPUT COUNTER will need some thinking about.

Dave

[mackrackit]

I have not been able to program Mrs. Mackrackit. Fuzzy logic

Mm, how about sending the PIC back to SLEEP awaiting another Interrupt_On_Change (the birds have started visiting again it was only a cloud) so carry on counting. If after say SLEEP 1800(about half an hour) the LDR is still high then Send_Data it really is dark!

That should work.

the INPUT COUNTER will need some thinking about.

"Debounce" so one count per bird...

[LEDave]

I have not been able to program Mrs. Mackrackit. Fuzzy logic

Lol, I think we're starting to skate on thin ice here

That should work.

I sometimes wonder is there a 'best of practise' when it comes to programming - Then again I'm still pretty much at the 'if it works I'm happy' stage of things......

"Debounce" so one count per bird...

Ah, I remember Debounce.

Right then, onto the sensor input / count.

Dave

[mackrackit]

I sometimes wonder is there a 'best of practise' when it comes to programming

Yup, it is called seeing how Darrel or Bruce would do it..

Then again I'm still pretty much at the 'if it works I'm happy' stage of things......

Me too!

[LEDave]

Problem:

I'm using SLEEP uncalibrated to put the PIC to SLEEP until an IOC occurs earlier on in the program. I'm also using SLEEP 1800 to put the PIC to sleep and test that it's still dark before transmitting the VISITS data. I'm getting an error when I compile the program though (see attachment). I've turned the _WDT_ON but still this error. Any ideas? Is using SLEEP an SLEEP Period in the same program uncompatable?

DARK:
     E_OUT=0           ' Disable transmitter
     INTCON.0 = 0      ' Clear int on change flag
     @ SLEEP 1800      ' It could be night time...It might only be a cloud though...   
                       ' so back to sleep for half an hour..zzzz
     @ NOP             ' Do nothing for 1st instruction on wake-up
              
    if  GPIO.4= 0  then ENCODE  ' It really ia dark so carry on and transmit VISITS
    
    IF  GPIO.4= 1  THEN RETURN  ' It's not dark after all so carry_on_counting

Forgot to add, if I comment out the line:

 @ SLEEP 1800      ' It could be night time...It might only be a cloud though...

the program compiles

Dave

[mackrackit]

@SLEEP can not be used like that. The OSC is stopped when sleeping so it would not know what to do with it.

But... Bruce to the rescue again.
http://www.picbasic.co.uk/forum/showthread.php?t=7013

[LEDave]

Hi mackrackit

But... Bruce to the rescue again.

I must add him to my Christmas card list too.....!

So @SLEEP (no period) for the visits count with IOC and a WDT timing loop for the "is it dark or just very cloudy" 30 min sleep.

OPTION_REG = %00001111

So with OPTION reg bit.4 set to 1 prescaler assigned for WDT on and a 128 prescaler I'm thinking that:

30mins x 60sec / 2.304secs = 781 counts for Bruce's timing / SLEEP loop below.

COUNTER=0 ' clear before entry
WHILE COUNTER < 781
@ SLEEP
COUNTER=COUNTER+1
WEND

So not really sleeping, more power napping.........

How does the above sound / look.

Dave

[mackrackit]

So not really sleeping, more power napping.........

That is what I was doing while driving home today....

How does the above sound / look.

Looks like it should work.
And you say that you have been doing this less than a year.

[LEDave]

That is what I was doing while driving home today....

Careful, we don't want any incidents now do we...!

And you say that you have been doing this less than a year.

A year February from memory, I think the progress made has been down to the tutors as much as the pupil.

Dave

[LEDave]

Ok,

Time to stick my neck out and say I think (I think) I've finished the TX / RX programs. I haven't connected them to the sensor / LDR to test for operation but I'd be very interested as to whether you can see any gaping errors in the code, here goes, TX first:

'****************************************************************
'*  Name    : rfPIC_TX.BAS                                      *
'*  Author  : B. Reynolds 90% LEDave 10%...Ok 5%                *
'*  Notice  : Copyright (c) 2007 Reynolds Electronics           *
'*          : All Rights Reserved                               *
'*  Date    : 10/09/2007                                        *
'*  Version : 1.0                                               *
'*  Notes   : 2-BIT Encoder for remote control with the         *
'*          : rfPIC12F675 on Microchip rfPIC demo board         *
'****************************************************************
@ __config _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _CP_OFF
    
    DEFINE OSC 4
    DEFINE NO_CLRWDT 1
    DEFINE OSCCAL_1K 1
    
    SYMBOL D_OUT = GPIO.2 ' RF serial data output
    SYMBOL E_OUT = GPIO.5 ' RF transmitter enable output
    
    
    VISITS   VAR word   ' Holds total daily bird visits
    DAT_OUT  VAR BYTE   ' Holds 8-bit data byte
    DAT_OUT2 VAR BYTE   ' Holds 8-bit test byte 
    LOOPS    VAR BYTE   ' Loop var
    CHK_SUM  VAR BYTE   ' Holds calculated checksum of outbound data
    COUNTER  VAR BYTE   ' Holds WDT count values
    BAUD     VAR WORD   ' Holds baud rate
    
    ' Constants
    PreAmble CON $A5    ' 10100101 preamble
    Synch    CON "~"    ' 01111110 synch byte
    N4800    CON 188    ' 4800 bps 
    N2400    CON 16780  ' 2400 bps
    GUARD    CON 5      ' 5mS guard time pause
    
    
    ' hardware init 
    GPIO = 0            ' Everything off on boot
    ' GPIO.2=data out, GPIO.5=RF enable, GPIO.3,4 = Bird_visit_count / It's dark..maybe
    TRISIO = %00011011  '
    ANSEL = 0           ' Disable A/D
    INTCON = %00001000  ' Enable port change wakeup from sleep
    WPU = %00010000     ' pull-up on for GPIO.4 (external pull-up already on GPIO.3)
    IOC = %00011000     ' Wakeup on change enabled for GPIO.3,4
    VRCON = 0           ' Disable internal Vref
    CMCON = 7           ' Disable comparators
    OPTION_REG = %00001111 'Watch_Dog_Timer ON with a 128 prescaler
    
    
    D_OUT = 0           ' Idles low for inverted serial output
    E_OUT = 0           ' Enable for RF transmitter=0 (transmiter off)
    BAUD = N2400        ' Set baud rate here
    
Main:    
    ' Read port to clear missmatch, if with no buttons pressed, then
    ' clear int-on-change flag & snooze until wake up on change. This
    ' conserves battery power on the demo board with 3V coin cell.
    
  IF GPIO.3= 1 AND GPIO.4= 1 THEN ' Nothing has happened so SLEEP
       E_OUT=0       ' Disable transmitter
       INTCON.0 = 0  ' No Bird detected or it's still light so clear int on change flag
       @ SLEEP       ' and start snoozin..zzzzzzzzzzz indefinatly
       @ NOP         ' Do nothing for 1st instruction on wake-up
  ELSE  
   IF  GPIO.3=0 THEN GOSUB COUNTS 'Bird detected at box - GOTO LABEL COUNTS   
   IF  GPIO.4=0 THEN GOSUB DARK   'It's got dark? or just cloudy - GOTO LABEL DARK
  ENDIF     
  GOTO MAIN          'Back to sleep / continue counting
    
    
 COUNTS:
      VISITS = VISITS +1 'Bird at box so increment counter
      INTCON.0 = 0       ' Clear int on change flag
  RETURN                 ' Then back to sleep....
    
 DARK:
      INTCON.0 = 0     ' Clear int on change flag
      E_OUT=0          ' Disable transmitter
                       ' It could be night time...It might only be a cloud though...   
                       ' so back to sleep / wake / sleep for half an hour..zwzwzw
      COUNTER=0        ' clear before entry
WHILE COUNTER < 781    'Loop for 30 mins
     @ SLEEP
     COUNTER=COUNTER+1
     IF  GPIO.3= 0  THEN COUNTS 'Bird at box so continue counting
WEND     
              
    if  GPIO.4= 0  then ENCODE  ' It really ia dark so carry on and transmit VISITS
    
    IF  GPIO.4= 1  THEN RETURN  ' It's not dark after all so carry_on_sleeping_counting 
    
Encode:  
    E_OUT=1     ' Turn transmitter on 
    pauseus 25  ' Let transmitter settle
    DAT_OUT = %10101001
    INTCON.0 = 0  ' Clear int on change flag
      
    ' Build checksum of 2 data bytes
    CHK_SUM = (DAT_OUT * 2)
    
Transmit:
    LET VISITS = VISITS / 2  'Just VISITS to not from the box
    SEROUT2 D_OUT,BAUD,[PreAmble,Synch,DAT_OUT,DAT_OUT,CHK_SUM,VISITS.highbyte,VISITS.lowbyte]
    PAUSE GUARD ' 5mS guard time gives decoder time to respond,calculate,change,etc.
    
    GOTO Main
        
    END

Dave

[mackrackit]

I do not see anything obviously wrong. Should work.

[LEDave]

Cheers mackrackit,

I guess the next thing is to wire it up and see what happens....

One thing that has become very apparent to me with programming is that due to the permutations / complexity of a program, an error can easily slip in and be very difficult to identify, almost like a sleeping time bomb. I hope the TX program is glitch free, we shall see.

Dave

[mackrackit]

That is part of the reason I write in blocks.

Write a block test a block.

Then stack the blocks up when they are all good.

[LEDave]

That is part of the reason I write in blocks.

Seems obvious when I read it. I think I get newbie-itus (symptoms: rapid typing and tunnel vision + a feeling of excitement) when I can see the end of or the way through a project and just leap in. Blocks make total sense.

Dave

[Bruce]

I would remove DEFINE NO_CLRWDT 1

You want PBP to handle clearing WDT for you when you have the watchdog enabled.

[LEDave]

You want PBP to handle clearing WDT for you when you have the watchdog enabled.

Thanks for that Bruce and for putting the TX / RX programs up in the first place.

Dave

[LEDave]

Hi all,

Have been very busy with other things for a few Months now, things seem to have settled enough now though for me to be able to get on with the project (long overdue).

These last few nights I've been building the project intergrating the rfpic module, ldr night cct sensor and VB program. Things arn't going smoothly though, everything worked well on the breadboard but not in the finished cct.....I'll get there though.

Really pleased to be back.

Dave