Decimal clock so close

jcbarber

Hi everyone
I have been working on a base 10 clock and have it very close to done but I have hit a major snag. My clock made from a CD4060 oscillator and a 25.6 KHz crystal produces 100 Hz which I read with th Basic Stamp 2 OEM at pin 0. The code seems fine and I have my display working OK as well. However the clock was very inaccurate. I double checked the clock output with my Parallax USB scope and it shows 100 Hz. But when I check what the stamp reads at Pin 0 using the following program I get strange results

DO
debug BIN IN0
LOOP

From the above program you'd expect to see 101010 on and on showing on the debug screen but some times I get 10101001 or 10101101 even 1010001 I have no idea as to why thhis happens, any ideas?

JCB

Bean

JCB,
Use PULSIN to measure the pulse, then DEBUG the value obtained from the PULSIN command.

10milliseconds is not much time on the basic stamp. Your clock code is probably missing some pulses causing your clock to be too slow. Is that what is happening ?

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman

Mike Green

The debug statement takes some time to execute. If the timing is just right (or wrong), the 100Hz clock and the loop timing can get out of sync and you'd see several adjacent bits that are the same. You would do much better to check the time between pulses with a PULSIN statement and record the minimum and maximum widths for a string of maybe 1000 pulses, then display the times using debug. The Stamp's accuracy for PULSIN is quite good.

jcbarber

Bean and Mike
Thankyou I will try the pulsin command to check my clock. Bean Yes my clock is very slow. I have a seven segment display I'm using to show the "time". Sounds like I need to increase my oscillator or adjust the counter I'm using to keep track of the time

JCB

Unsoundcode

Hi JCB , the Stamp frequency is a little faster than the clock so eventually the phase's will overlap, when this happens the debug will read either twice (or more) during the low clock cycle or twice (or more) during the high clock cycle. You might be able to program a do loop to wait for each transition and accumulate the results in a counter but as the size of your program·grows so will the phase relationship so if your sampling time becomes greater than the clock frequency you are going to miss pulses. You could overcome this maybe with a divider and reduce the clock frequency a little.

Jeff T.

jcbarber

Jeff

Thanks for you help I'll give it a try

JCB

Franklin

You might think of dividing the frequency to 1hz if you don't need extra accuracy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Chris Savage

Franklin beat me to the punch (err, post)…If you don’t need better than 1 second resolution you’re better off using a 10Hz or 1Hz pulse over the 100Hz pulse. The slower pulses will give you more time to detect the next pulse while updating the display and making calculations.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

jcbarber

Hi
I'm trying to make a base 10 clock. 1/10000 of a day is my base unit (8.64 sec)
What happens in the program is it checks Pin 0 for a low on the clock cycle if it is low it goes to the subroutine tock. Where it increments the counter and returns if the counter hase not reach 8.64 seconds (1728 counts 2 counts or lows per cycle). If it has reached the 8.64 seconds then it zeros the counter adds 1 more to the clock value, checks to see if the clock has reached 10000 (midnight) to re-zero the clock then sends the clock value to the clock display then returns. This is probably taking way to much time for my stamp to get each of the 100Hz so I guess I need to adjust my counter total so that it times better or maybe figure the basic stamp can't keep up with my oscillator and try a new approach

JCB

Chris Savage

Another option would be a faster Stamp Model which may be able to keep up with the pulse. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

jcbarber

to all

Yhanks for all the help but it looks like the Basic Stamp 2 model is too slow to do what I want. I'll look into a faster model. Again thanks for all your help

JCB

Chris Savage

John,

·· It’s not that the BS2 itself is too slow…It just may be unable to keep up depending on what is happening in your program loop. Other Stamp Models are rated in approximate instructions per second and you can find the comparison table at the link below. I hope this helps. Take care.

http://www.parallax.com/html_pages/tech/faqs/stamp_specs.asp

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

jcbarber

Chris
thanks, I checked it out and I have a question: is there a way to calculate the most efficient instructions per second model of stamp (no need for overkill) based on my code and the 100 Hz oscillator?

John

jcbarber

JCB again
I just checked my clock and it is FAST not slow. It is off by about %50 in an hour and a half. VERY STRANGE. What now?

JCB

Tracy Allen

Instead of 100 hertz, why don't you divide it down to 6.25 hertz? On the CD4060 that is the 2^12 tap.

Then the period will be 0.16 second, and that still divides 8.64 seconds evenly (54 times), so you can get your 1/10000 of a day precisely. In 0.16 second, the Stamp has plenty of time for other tasks.

If you use a BS2p series Stamp, you can use the POLLWAIT commands to sychronize very precisely to the transitions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

jcbarber

Tracy
GREAT IDEA I'm on it and

THANKS

JCB

LSB

Actually I might expect, in the case you present, to see: 1111100000111111110000000... as the Stamp loops many times in 100th of a second. The problem remains the same--timing. I suspect that perhaps you are recording many ticks per second and the Stamp is therefore counting time much faster than is accurate. Perhaps a better approach would be to slow your tick frequency with a counter of some sort... binary or decade. Either would offer several frequencies slow enough that the Stamp would be waiting for a pulse when it arrived, then happily execute it's code to completion before pausing to wait for the next tick. An LED could help you troubleshoot by coming on when the Stamp starts waiting and going off when the tick it recorded--move your in-pulse pin to faster and faster output pulses until the light flashes briefly--or verify the shortest possible consistant wait using your 'scope. This point is the best resolution your clock can manage, and has the added advantage of allowing you many frequencies of clock source to adust your resolution and allow for more code execution time.

More times than I can count I've been confused by how fast even the slowest mcus work... my experience says to slow everything w a y down until you can verify that what you expect to see happen, happens (or you see why it isn't happening).

HTH--

Chris Savage

JCB,

To answer your question though…In order to see how long it was taking for the loop to work you would really have needed a way to generate a pulse every iteration through the loop. A very small pulse which could be picked up by a Scope or Logic Analyzer. That’s the only real way you’d know. A small enough pulse shouldn’t have interfered with your timing too much and would still give you a good idea either way.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Chris Savage

LSB,

You bring up a good point too…If you’re only waiting for a LOW there is always a possibility that the pin could be low on more than one iteration through the loop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

LSB

I think that the primary point is that the code must not simply check the pulse state, but be triggered by the transition from one known state to the other-- a fact not clearly addressed in several of the posts. Slowing the clock will only make the problem worse unless this point is taken.

DO
Debug BIN IN0
LOOP

I believe this is the answer to JCB's problem because in the code posted in his original inquiry (included above), a simple loop, he states that he expected to see "101010" as output--indicating some lack of understanding in regard to the difference between the processor clock and a regular, cyclic input signal.

jcbarber

HI
I tried the idea of 6.25 Hz but I could find a 2^12 pin the c;osest was 2^8 at pin 15 which should give me 25 Hz but on my scope it showed 26.5 Hz (???). I tried it and the clock ran extremly fast. I'll try the other suggestions. LSB I agree I have very little undersdtanding on how all this works, but now that I see your idea it makes sense with the clock running as fast as it does, I must be reading the same low (0) several times. (I'm very very new to all of this and have learned a ton so far, but there is much more to learn thanks) My next question is how to write code that would wait for the next transition? Maybe

DO
LOOP UNTIL IN0 = 0

JCB

LSB

JCB,
I'm not fluent enough in PBASIC (or with the specifics of your project) to write code I'd trust to offer as a solution; however, the code below demonstrates signal transition edges and how to detect them. It is necessary to remember the state of IN0 between loops and respond only to the transition (only once and only in one direction).

OldState=IN0
Do
IF (OldState=0) AND (IN0=1) THEN 'ON RISING EDGE
OldState=1 'SET OldState
GOSUB RunTickRoutine 'Run clock tick routine
END If
IF (OldState=1) AND (IN0=0) THEN 'ON FALLING EDGE
OldState=0 'RESET OldState
END IF
LOOP

The above may work for slow clocks (where RunTickRoutine completes before the falling edge occurs), but will fail else because the OldState variable will not be reset; on a faster osc pulse this reset would have to be done in the RunTickRoutine—as the Stamp will be running ‘Tick Code’ rather than watching for the falling transition, but will still require to know that IN0 has changed states and it is 'safe' to update OldState.

It is possible too that the ‘Tick code’ will run beyond the rising edge as well; the clock will run slow in that case and the IN0 pulse must be slowed (or the tick code abbreviated).

CAUTION though: If the loop is executed after the OldState variable is reset to 0, but before the osc pulse changes back to low, the rising edge conditions will exist prematurely and the rising edge loop will execute not only prematurely, but repeatedly until IN0 changes state.

--as I read back my post I’m not sure my answer offers clarity. Perhaps others will add to my clumsy explanation.

Unsoundcode

Hi JCB, the do loop you mention above will catch a high to low transition the key is synchronising it with your clock pulse. For example at 25Hz there is a high to low transition every 40mS. That means you must be ready to look for the transition in less than 40mS or in other words your program cycle must be less than 40mS. Having said that your program cycle must also be above 20mS or you will be reading the same period of the wave more than once . At 25Hz that shouldn't be too much of a problem and could even mean including a pause. You could pulse a pin once a cycle and use a scope to measure the program cycle. The use of debug , especially in your first post , is not ideal for measuring the program cycle unless its going to be a part of the completed project, depending on the system and baud sending one byte can increase the program cycle one or two mS.

Jeff T.

allanlane5

Actually, what you want is a square wave. The BS2 can do quite a lot in 10 mSec -- but you MUST make sure it doesn't miss any pulses.

This is a really nice 'real-time' implementation. What you must make sure of is that the BS2 does all character updates in less than 10 mSec -- less than 5 mSec would be better. It does about 2000 instructions per second, so that's about 20 instructions. A longer 'tick' would be helpful.

LSB's code has the right idea -- wait for the rising edge, do something, then wait for the falling edge, then wait for the rising edge again.

jcbarber

I think right now my problem as far as time is concerned is the time it takes to diplay the time on a 7 segment 4 digit diplay with the MAX 7219 diplay driver. I guess now I have a great deal of calculating. Thanks everyone

JCB

PJAllen

I was going to add that you might try a high-pass filter on the input, so you'd end up with some real pulses instead of trying to do edge-detection through software.

Tracy Allen

jcbarber said...
HI
I tried the idea of 6.25 Hz but I could find a 2^12 pin the c;osest was 2^8 at pin 15 which should give me 25 Hz but on my scope it showed 26.5 Hz (???).
DO
LOOP UNTIL IN0 = 0
JCB

Hi JCB,

A starting crystal frequency of 25.6 khz divided by 256=2^8 should be giving you a frequency of 100 hz. According to the diagram of the CD4060 (attached), that is pin 14. The 2^12 tap is pin 1, and that should give 6.25 hertz. You could even use the tap at 2^13, on pin 2, and the 0.32 second period there would still divide evenly into 8.64 seconds (27 times).


Just curious, where did you get the 25.6khz crystal, and what feedback components (resistors and capacitors) are you using with it attached to pins 10 and 11? It matters for stability. Diagram attached.

Here is another program suggestion for counting on transitions. This uses the properties of the XOR and AND operators (^ and & in PBASIC).

new var bit     ' these bits keep track of changes at the input
old var bit
change var bit
tocks var word  ' counts 0-9999, units of 1/10000 of a day
ticks var byte   ' counts 0 to 54 units of 0.16 seconds, up to 8.64 seconds

old = in0
DO
    new = in0   ' read the pin
    change = new ^ old & old     ' change=1 only if old->new is 1->0
    old = new    ' new becomes old
    ticks = ticks + change // 54   ' count ticks in cycle of 54
    IF ticks=0 AND change=1 THEN 
        tocks = tocks + 1 // 10000   ' 10000 tocks per day
        DEBUG DEC tocks, CR
    ENDIF
LOOP

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

jcbarber

Tracy
I have at 10 Mohm resitor across pin 10 and 11 and a 220 kohm from pin 10 to the crystal and no capacitors. The crystal is rated at 11 pF. I'v been getting a 6.66 Hz frquency using my USB oscilloscope from pin 1 and a 150 ms period (more like .150150... sec period)

JCB

Tracy Allen

I presume that the other frequencies are high by the same proportion, and that the putative 100 hertz output is coming out at around 106 Hertz?

The crystal oscilator does indeed need the capacitors. The 10pf on the input at pin 11 and a 39pf variable capacitor at the output as shown in the diagram in my previous post (from the CD4060BC data sheet) is a good start. The variable capacitor will allow you to tune the frequency to get it right on. (At least as good as the standard you are using to measure it!). If you don't have a variable capacitor, try something like 30 pf there and see if it improves.

You said in pm that the crystal is rated at 11pf. The two capacitors in the circuit are effectively in series, and the one on pin 11 is effectively in parallel with the input capacitance of the CMOS gate. It is the series/parallel combination that has to come out at around 11 pf.

I a surprised even so that the frequency deviation without the capacitors is more than 5%. That is quite a lot. But do try the capacitors first.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

jcbarber

Tracy
I checked pin 15 and the scope shows 26.6 Hz rather than 25Hz BUT when I check the frequncy on pin 14 I get 100 Hz! something seems out of wack

JCB

Tracy Allen

What are you using to measure the frequency? Could there be a measurement error?

Try it with the capacitors installed in the crystal circuit. Without them, the oscillation frequency _might_ depend on how you wave your hand at the pins. But this is a binary divider. The output frequencies should be rigidly powers of two!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com