Wednesday, February 8, 2012

Encoders for the Prop

The last day are so I have been trying to get a Chronodot Real Time Clock (RTC) to interface with my Propeller beacon. The idea is to have it schedule the WSPR Transmit Cycle, which are required to start on the even minute of hour, plus 2 seconds (ideally plus or minus 1 second). In PC environment a WSPR beacon uses the system clock for scheduling. With my Propeller Microprocessor, a PC is not connected, and therefore the processor has to do the scheduling. Which can be done, but without a RTC, adjustment to the micro's clock it done by hand - what a pain.

But sadly, I can not get the RTC to talk back to the Propeller. Maybe my Chronodot is dead, I have ordered a Bus Pirate to help with diagnostics. Much more work is needed.

While awaiting the Bus Pirate order, I decided to tackle the next GUI item that is needed  for the Propeller Beacon Controller. Which is, the two Rotary Encoder Service Routine.

On a  previous projects based on the Arduino Board, I had to resort to a complex state machine programming to achieve the multitasking that I desired. The Rotary Encoders were a part of the state machine, and were interrupt driven.

With the Propeller, there are NO interrupts !, . . but there are eight processor where one processor (or more) can be dedicated to the Encoder task. Originally I thought it would take one whole processor for each (Arduino style) Rotary Encoder task. But more reading through the manual and Spin Programming Syntax, I found a "waitpne" (wait for pins not equal to mask) statement. This statement allows all of the Rotary Encoder (and push button) pins to act as one big switch. All that is needed is to decode (poll) which pin was changed, and increment counter as necessary. This was a 100% self written program/driver Object, a fun project, I will post the code later.

Two Rotary Encoder Knobs
with Integrated Push Buttons

The first thing did with my new programmed function was to implement a RF Frequency Calibration Offset, I have several Propellers that I have been using, and keeping track of the CAL Offset for each Prop Board has been a problem. Now if it is not exactly on Frequency it is just a quick twist of the knob to correct it.

The second programming function I implemented; was a reset of the Epoch clock on a push of a button,  which starts the WSPR time cycle. Until I get the RTC working a little manual intervention is still necessary.

It's just more fun stuff with the Prop !

--

1 comment:

  1. Hi Eldon,

    Try my delay function implementation. So far, I have been able to run this on any of my propeller boards for weeks at a time and WSPR is able to stay on time.

    CON
    WMin = 381

    VAR
    LONG SecondCnt, Stack[16]

    PUB delay(Duration)
    waitcnt(((clkfreq / 1_000 * Duration - 3932) #> WMin) + cnt)

    PUB Clock ' Runs In its own COG
    repeat
    delay(1000) ' Update second counter every 1000 ms
    SecondCnt++ ' Should be good for 2^32 seconds or about 136 years

    In the initialize code, I start what you call your Epoch clock, thus:

    SecondCnt := 0 ' Set clock to zero seconds
    cognew(Clock, @Stack) ' Start the clock COG

    I have been able to just turn the device on at the top of an even minute (you can push the button apparently) and it keeps excellent time. Of course there is going to be some variation in crystal accuracy which you are able to zero out nicely. Of course I will need much longer testing times (months) in order to pick up the low level drift, but so far it has been very solid.

    ReplyDelete