08m divide by 60

[Hydroid]

Hi,

In making a binary clock with the DS1307 as the time keeper, I have discovered that over a period of about 10 days, the time is off by almost 30 seconds. I admit that's not a huge amount, but I like my timekeepers accurate, hence the wristwatch on my arm and wall clock in my den that are corrected by the WWVB time signal in Colorado...

Having been a powerplant operator for almost 32 years, I know that the frequency of the grid is very accurately controlled - it does wander by a VERY small amount over the day, but is returned to a balance, by law, daily.

I'm thinking of using the grid frequency as the 60Hz input to my 28X1 clock program. I know that I could use various means to accurately divide down the 60Hz to 1 Hz (7490's, 4017's or even a 4040 to name a few) but I want to keep it all Picaxe - Using an 08M as a divide-by-60 chip feeding the input to the 28X1.

Playing around with an 08M (see schematic) and the following code, produced results that weren't too bad, but still not perfect:

# picaxe 08M

'60 Hz conditioned signal fed to in1 (pin6)
'out0 (pin7) delivers 1 Hz square wave
'see 1Hz Extractor.dsn

b0=0

main:

if pin1=1 then
	b0=b0+1
endif

if b0>119 then
	goto tog_LED
endif

goto main



tog_LED:

b0=0

toggle 0

goto main

It runs slow, so I figure in the time it's taking to execute the code, it's missing some of the input pulses. Before someone asks, the schematic is based on the chip being on the AXE091 development board, so while not shown, the input resistors for serial input (pin2), are actually there...

I read elsewhere on this forum on the uses of the interrupt routine, so I modified my code to:

# picaxe 08M

'60 Hz conditioned signal fed to in1 (pin6)
'out0 (pin7) delivers 1 Hz square wave
'see 1Hz Extractor.dsn

b0=0

setint %00000010,%00000010		' set interupt for in1 (pin6)

main:

if b0>29 then				'next 3 lines count 30 +ve half-waves of AC,
	toggle 0				'toggles out0 and resets counter back to 0
	b0=0
endif

goto main

interrupt:

if pin1=1 then interrupt		'wait until in1 is low
b0=b0+1					'increment b0 by 1
setint %00000010,%00000010		're-enable interupt
return

As a test of accuracy, I used a very simplistic method - I kept restarting the circuit until the LED blinked on at the exact same time as my watch second hand advanced. In the short term, it seems bang on, but letting it run over-night reveals that the LED and second hand are no longer in sych (I'm betting on my watch being the accurate half here). This, of course, doesn't tell me if the Picaxe is running slightly fast or slightly slow. I hooked up my scope, which has a counter function, to pin7 (out0) to count the pulses against a stopwatch. Over the course of 60 minutes, it was perfect (3600 counts).

I thought that maybe line noise was adding some extra counts over time, but I have never seen any noise on the scope.

So, is this a viable means of using an 08M as a divide-by-60 ?

Should this interrupt code work, or am I missing something ??

Thanks, John.

 

[boriz]

Check out the PULSIN command.

 

[papaof2]

I would want to see your watch during its update period. I have a clock synced to the 60kHz signal and its time may change several seconds during any given update (around 8PM, since that when it was initially set).

Your watch likely has some fixed error at any given hour after being uodated by the NIST signal (3PM is always correct, or always slow by X amount, or always fast by Y amount), but its long-term accuracy without the NIST correction signal may not be that great.

Quick test: Put your watch in a shielded encosure for 72 hours, then compare it wih a known-accurate source.

Remember that the maker can claim wonderful accuracy, since as long as the NIST signal is available even a marginally accurate timepiece will appear correct Good windup watches could keep within a few seconds a day - if you reset them once a day, they appeared to have excellent accuracy (long time spent in broadcast TV, where things were to the second - the studio clocks were synced every hour to keep them correct).

John

 

[Andrew Cowan]

Or the count command.

After some research (on this forum): this link says how to get super accurate timing by using an oscillator, rather than a crystal.

A

 

[hippy]

There may be spikes and glitches on the mains which are throwing the count out slightly, fridges kicking in and out etc, plus, as papaof2 notes, there's the accuracy of what you are using to calibrate against.

The best way to do mains-synch timing is perhaps to have a window of time when the pulse is expected and when a pulse is missing you add one, when one appears outside the window it's ignored. This is where software can do better than simplistic hardware dividers. One thing of course is that the code must execute quickly enough so it doesn't miss any pulses; SETFREQ M8 will help there.

 

[premelec]

@Hydroid... I wonder if you read Maxim AN58 in regard to choosing crystals for the IC? It seems you are out of spec to begin with... you can use 60Hz source but filter it heavily... however why not use a cheap WWVB clock [I bought on for less than $9 at a drug store] for a time source free of the line frequency and odd spikes and excellent accuracy? You can periodically correct the Maxim unit with the WWVB signal...

 

[SAborn]

I fail to see why the DS 1307 is that far out as i have used many and found them to be spot on.

I think it must have been in your setup for it to be so far out as you can set them to give a very accurate 1 Hz pulse and have used them in frequency meters as a time base with outstanding results.

I would forget the mains generated signal and sort the DS 1307 as you will be much better off.

You mension using a 08M and the DS 1307 can only be set with I2C so will require a 18x or other chip with I2C capabilitys to set it.
As long as you have a backup battery connected to it to retain program when powered down it will produce a 1Hz pulse that can be then used with a 08M.

 

[MPep]

Haven't used the DS1307 myself, but could there be a problem with the crystal? Have you tried using another one?

 

[Hydroid]

Check out the PULSIN command.

Or the count command.

Guys,

Not afraid to admit here that I'm stumped on these. I can't see how I would use PULSIN (to measure counts on a pin). I can see that it would be used to determine frequency - so I could calculate that I'm getting a pulse width representing 60Hz, but how do I get that down to 1 Hz ?

COUNT makes a little sense COUNT pin, period, wordvariable but but I have to supply a period (I assume 1000 to count for 1 second), but then what ?

Have any examples of how these commands could work as a divide-by-60 ?

Regards, John.

 

[Hydroid]

Your watch likely has some fixed error at any given hour after being uodated by the NIST signal (3PM is always correct, or always slow by X amount, or always fast by Y amount), but its long-term accuracy without the NIST correction signal may not be that great.
John

True, that would be a reason that the second hand and the LED blink are not in sync in the morning having sync'd them the night before, but since my watch is corrected at 1:00 am every night, over the course of 10 days, it should be accurate. I can't believe that it's out by 30 seconds in a day - especially since each time I compare it to the wall clock, they're exactly the same, to the second.

I'll have to try your idea of the shielded location and see how my watch stands up sans correction.

John.

 

[Hydroid]

The best way to do mains-synch timing is perhaps to have a window of time when the pulse is expected and when a pulse is missing you add one, when one appears outside the window it's ignored. This is where software can do better than simplistic hardware dividers. One thing of course is that the code must execute quickly enough so it doesn't miss any pulses; SETFREQ M8 will help there.

Hmm, I'm thinking this is where the COUNT command comes in. I'll have to play around with this one when I restock my Advil - I see a headache on the horizon...

John.

 

[Hydroid]

@Hydroid... I wonder if you read Maxim AN58 in regard to choosing crystals for the IC? It seems you are out of spec to begin with... you can use 60Hz source but filter it heavily... however why not use a cheap WWVB clock [I bought on for less than $9 at a drug store] for a time source free of the line frequency and odd spikes and excellent accuracy? You can periodically correct the Maxim unit with the WWVB signal...

I didn't choose any crystals. The RTC I'm using is on the AXE091 development board which I purchased complete.

Wow, $9 - I gotta move to the states. Hard to find up here - and certainly not that inexpensive.

I like the idea, but I'm on the fringe of the WWVB signal here in southern Ontario. I had to mount the wall clock on an outside wall and have to put my wristwatch in the window facing SW in order to get the signal. I want a clock that I can place anywhere there's a plug and have it work.

John.

 

[Hydroid]

I fail to see why the DS 1307 is that far out as i have used many and found them to be spot on.

I think it must have been in your setup for it to be so far out as you can set them to give a very accurate 1 Hz pulse and have used them in frequency meters as a time base with outstanding results.

I would forget the mains generated signal and sort the DS 1307 as you will be much better off.

could there be a problem with the crystal? Have you tried using another one?

I didn't setup my RTC - it's part of the AXE091 board, however, I have had reason to question it's performance so maybe trying a stand-alone unit (which I happen to have) would be a good next step. It seems that the general opinion here is that the DS1307 is a VERY good time keeper.

You mension using a 08M and the DS 1307 can only be set with I2C so will require a 18x or other chip with I2C capabilitys to set it.

The 08M is strictly being used as a divide-by-60 chip which then feeds a 1Hz signal into a 28X1 which handles the i2c and clock routines.

John.

 

[boriz]

PULSIN waits for two transitions on a pin. Say you are looking for the duration of a high going pulse. You execute the PULSIN command, it waits until the pin goes high then starts an internal timer. When the pin goes low, the timer stops and program execution resumes at the next command. For your application, the actual pulse length isn’t relevant. All you’re using the PULSIN command for is to synchronise your code with the mains frequency. HALF WAVE rectified mains, properly reduced in magnitude to under 5v, will provide 60 positive going half-sine shaped pulses per second (50 in UK). When the PULSIN command exits, you simply increment a 0-59 counter and repeat. As long as the rest of your code can be executed before the next pulse begins (during the negative going half cycle), it should be perfectly synchronised.

EG:

At 60Hz, it should take about 16mS for a complete cycle. Half wave rectified gives you a positive going hump shaped wave of just over 8mS. The threshold for a pin to read high will vary a little from device to device, but for sake of argument (since it’s not important here) let’s say it’s Vdd/2. So when the pulse reaches about 2.5v, the PULSIN timer starts. Because of the curve of the half-sine, the PULSIN will return a value representing approximately 4mS-6mS or so. That leaves at least 10mS for the rest of your processing (incrementing and testing your counter) and the next PULSIN command to be executed. When your counter reaches 60, exactly one second has passed.

That's just one way of doing it.

 

[Hydroid]

PULSIN waits for two transitions on a pin. Say you are looking for the duration of a high going pulse. You execute the PULSIN command, it waits until the pin goes high then starts an internal timer. When the pin goes low, the timer stops and program execution resumes at the next command. For your application, the actual pulse length isn’t relevant. All you’re using the PULSIN command for is to synchronise your code with the mains frequency.

Sometimes, like now, I feel really stupid

I had it in my head that the code execution would continue cycling while PULSIN was doing its thing - Why, I don't know. Sometimes, it's the most obvious things...

Your explanation was perfect - and makes perfect sense to me. I just tried this bit of code (using the same circuitry posted initially, and it works perfect

b0=0

main:

pulsin 1,1,w3

b0=b0+1

if b0>29 then
   toggle 0
   b0=0
endif

goto main:

I've had the scope counter attached and so far it's perfect. Have to let it run overnight and then do the math to convert counts to seconds and see. I suspect it'll be fast again and that hippy was right and I'm picking up some stray pulses from noise. I live in a rural location so I have a sump pump and well pump cycling as well as all the other usual items like fridges and the like.

Thanks for lighting the lamp above my head on PULSIN

John.

 

[BCJKiwi]

Perhaps you might consider a DS1337C instead of a DS1307.

The C version has a built in crystal and while it is a surface mount deceive, with a bit of fiddling can be hand soldered to an 8 pin socket to create an 8 pin Dip module.

The crystal for the DS1307 is an issue as I have not been able to locate one with the correct capacitance to meet the required spec for accuracy.

It also removes the issue of ground shielding.

 

[Hydroid]

Perhaps you might consider a DS1337C instead of a DS1307.

The C version has a built in crystal and while it is a surface mount deceive, with a bit of fiddling can be hand soldered to an 8 pin socket to create an 8 pin Dip module.

The crystal for the DS1307 is an issue as I have not been able to locate one with the correct capacitance to meet the required spec for accuracy.

It also removes the issue of ground shielding.

Thanks for the info, just downloaded the datasheet and will have a look.

Regards, John.

 

[Hydroid]

Bad RTC ??

Hi,

Thanks to all who offered tips, suggestions...

It seems that I have a bad onboard RTC as part of my AXE091 board.

I've been running an external 1307 RTC that I bought off the internet (http://www.futurlec.com/Mini_DS1307.shtml - incase you're curious) and so far, about 16 hours now, using debug shows that the RTC exactly matches both time pieces I'm comparing it to. I'll have to let it run for a few days to be absolutely sure, but by this time my onboard RTC would have already produced some error, so it's looking good that I've found the soure of the problem. Now to figure out why it's not right. I have a few loose crystals and a few extra 1307 chips, so I guess I'll start there.

Also, it appears that spikes on the mains turned out to be my source of error when using the grid as a timing source. As a test, I took my feed of a filtered 60 Hz signal from the transistor clock that I'm building (http://transistorclock.com/ for those who are curious). It's designed to filter out noise pulses (explained on page 30 of the manual that can be viewed at his site, if interested). My binary clock has been running off grid supplied timing pulses for almost as long as the external RTC and is bang on too

Thanks again for all the help guys, this is a great forum !

Regards, John.

 

[MartinM57]

It seems that I have a bad onboard RTC as part of my AXE091 board.

I've been running an external 1307 RTC that I bought off the internet (http://www.futurlec.com/Mini_DS1307.shtml - in case you're curious)...

I doubt the DS1307 is bad - you (and Futurlec) just need to follow the Maxim datasheet on crystal selection and layout. It is very explicit on both, including two key electrical characteristics, ESR and Load Capacitance.

If you get the right crystal and observe the layout guidelines (which I'm absolutely amazed that Futurlec don't do on their board - I've not looked at an AXE091 closely), then you should be as accurate as the crystal itself.

However crystal are typically 10 parts per million accuracy. So get you're calculator out and see how that pans out per month - mine says 25.92 seconds. You might be luckier than that of course, if you get a more accurate crystal. Also, crystal accuracy changes with temperature so if you're hot/cold where your clock operates that will degrade it also.

There are other Real Time Clock chips available (Google or Farnell for e.g. M41T81S - I2C interface but note it's SOIC only) that have more resolution (1/100ths of a second) and have software calibration to allow you to take account of the actual crystal you have. Cheaper than a DS1307 as well...(and a couple of other nice features like programmable alarms and a power down timestamp)

 

[SAborn]

You comment that the rtc runs to time in debug.

There can be a problem with running in debug as the DS 1307 has a BCD output and this will not display the correct time in debug unless you do a BCD to decimal conversion first.
The BCD time interval will be correct except the digits displayed will not be completely true.

Attached is a section from a DS 1307 kit i put together for another group,
You might find it helpful.

 

[westaust55]

You comment that the rtc runs to time in debug.

There can be a problem with running in debug as the DS 1307 has a BCD output and this will not display the correct time in debug unless you do a BCD to decimal conversion first.
The BCD time interval will be correct except the digits displayed will not be completely true.

Attached is a section from a DS 1307 kit i put together for another group,
You might find it helpful.

Good write-up there SAborn.
Worthy of placing in the completed projects area for general reference.
You might also like to look at the polarity of LED1 in the diagrams on pages 2 and 5.

 

[SAborn]

Whoops!!

Yes the led is back to front in the diagrams and was changed in a revised copy but i have posted a section from a earlier draft.

I will change the file when i get time to fish it out.
Maybe i will post the full lot of data in completed projects seen there looks to be an interest.

Is there file size restrictions in the completed project section, as the full data will exceed the 900 or so Kb in pdf form.

 

[Hydroid]

I doubt the DS1307 is bad - you (and Futurlec) just need to follow the Maxim datasheet on crystal selection and layout. It is very explicit on both, including two key electrical characteristics, ESR and Load Capacitance.

As I've already stated, I have had nothing to do with crystal selection and/or layout. I bought both these devices constructed. I would expect a commercially available product is designed correctly and should work OK. It seems that I'm in the minority on error in timekeeping here, as most people have said that the 1307 is more accurate than mine, so that is why I suspect a problem with the AXE091 RTC - supported by the Futurlec RTC keeping MUCH better time...

If you get the right crystal and observe the layout guidelines (which I'm absolutely amazed that Futurlec don't do on their board - I've not looked at an AXE091 closely), then you should be as accurate as the crystal itself.

If you're referring to the datasheet's Figure 2, Recommended layout for crystal, which details the requirement for local groundplane and not routing signal lines in the suggested area, I agree 100% - They should have made it that way. The AXE091 has no ground plane underneath the crystal, but my Futurlec does. Both run lines near the edge, but inside, the hatched area.

There are other Real Time Clock chips available (Google or Farnell for e.g. M41T81S - I2C interface but note it's SOIC only) that have more resolution (1/100ths of a second) and have software calibration to allow you to take account of the actual crystal you have. Cheaper than a DS1307 as well...(and a couple of other nice features like programmable alarms and a power down timestamp)

Thanks, I'll check it out. SOIC isn't a problem for me - other than the requirement for magnifying headset and steady-handed tweezers. Never needed either when I was younger

John.

 

[Hydroid]

You comment that the rtc runs to time in debug.

There can be a problem with running in debug as the DS 1307 has a BCD output and this will not display the correct time in debug unless you do a BCD to decimal conversion first.
The BCD time interval will be correct except the digits displayed will not be completely true.

Attached is a section from a DS 1307 kit i put together for another group,
You might find it helpful.

Thanks ! Excellent writeup. I've filed that away with my other bits for future reference. Until I read it just now, I wasn't aware that I could write to (or read) from) a single register - so there's a new bit of knowledge already

I'm not sure what you mean when you say that debug will not show the correct time unless I do a BCD to decimal first. I've attached a screenshot of my debug screen taken about 90 minutes ago (@ 23:30:22 on Sunday March 07, 2010). If I look at the second column hex values beside the respective registers, it looks OK to me.

Am I missing something ??

John.

 

[MartinM57]

As I've already stated, I have had nothing to do with crystal selection and/or layout.

Sorry John - I'm not sure why I suggested that...it's quite clear that you are comparing two commercial products.

I suppose the RTC could be bad, but essentially they are simple devices - they just count the oscillations caused by the crystal. Unless you've got a particularly forgetful one, it must point to the oscillations being at the wrong frequency, which is crystal related (either frequency, inherent electrical characteristics (ESR and LC) or layout).

Can you swap DS1307's between the boards to check?

 

[SAborn]

Hi Hydroid,

BCD is not a straight decimal equivilent and the count will not show correct in debug but the period of actual time will be correct. (see foot note)

You need to write to the DS 1307 chip to set it up and to be able to set the current time of day and month etc.

I would not think there is anything wrong with the board or chip you have, but more so that you havent configured the chip itself.

Heres a bit more from the kit information i posted earlier that might help explain it further.


‘**************************************************************************
A COPY & PASTE CLOCK TEST SETUP.
‘*********************************************************************
symbol seconds = b0
symbol mins = b1
symbol hour = b2
symbol day = b3
symbol date = b4
symbol month = b5
symbol year = b6
symbol control = b7
symbol temp = b8

' set DS1307 slave address %11010000

i2cslave %11010000, i2cslow, i2cbyte

start_clock:

let seconds = $00 ' 00 Note all BCD format
let mins = $01 ' 01 Note all BCD format
let hour = $05 ' 05 Note all BCD format
let day = $03 ' 03 Note all BCD format
let date = $01 ' 01 Note all BCD format
let month = $04 ' 04 Note all BCD format
let year = $09 ' 09 Note all BCD format
let control = %01110000 ' Enable output at 1Hz in 12 hour mode PM set

' Clock will be set to 05:03:00 PM on (03 tues) 03/04/09

writei2c 0,(seconds,mins,hour,day,date,month,year,control)

end
‘********************************************************************************************************

‘**************************************************************************
‘A COPY & PASTE READ CLOCK TEST DISPLAYED IN DEBUG
‘***************************************************************************
symbol sec = b0
symbol mins = b1
symbol hour = b2
symbol day = b3
symbol date = b4
symbol month = b5
symbol year = b6
symbol control = b7
symbol temp = b8
symbol rtc = %11010000

main:

Debug

i2cslave rtc,i2cslow,i2cbyte

readi2c 0,(sec,mins,hour,day,date,month,year)

goto main

‘******************************************************************

Please Note:-

When the above program is run in debug the seconds, etc. will count to 89 before the minutes will advance this is because the data from the RTC is in BCD ( binary coded decimal ) and debug
displays information in decimal.

You will find the time periods are correct.
This program is only intended to be used as a test without the need to use a display.
*******************************

Admin.... What is up with the code box as it only showed a small portion of the code posted above when i used it.
I was unable to scroll the whole code, only a few lines.??

 

[MartinM57]

In making a binary clock with the DS1307 as the time keeper, I have discovered that over a period of about 10 days, the time is off by almost 30 seconds...

I think OP has his BCDs/decimals all lined up and had a working clock, and is just asking about accuracy. 30 seconds in 1 month is all you are going to get from a 10ppm crystal and a DS1307. That doesn't mean it's a 'bad' DS1307.

Maybe John could summarise where we are, rather than us going in two directions (accuracy vs. fundamenatal BCD/decimal confusion) at once...

And yes, SAborn, the code window is small and you have to scroll. It's been mentioned many times...

 

[westaust55]

Is there file size restrictions in the completed project section, as the full data will exceed the 900 or so Kb in pdf form.

When you go into the Attachment Manager (use the paper clip icon at the top of the post/edit window) the pop-up window has details of the file sizes. See attached screen shot

PDF's are permitted up to 976kB.

Past experience on many occasions however finds that the 1.9MB size for txt files is questionable. I have never been able to save a txt file that bit.

With images not that jpg is 976kB but jpeg is far smaller.

 

[SAborn]

Thanks Westy,

I have posted the full kit data in the completed projects section should you guys want a look.
The guts of it is listed above already so mainly only extra dribble in the full doc.
.

 

[Hydroid]

When the above program is run in debug the seconds, etc. will count to 89 before the minutes will advance this is because the data from the RTC is in BCD ( binary coded decimal ) and debug
displays information in decimal.

Hi,

I wrote a small file that I use to set / read the RTC to the debug screen. I believe it is doing it correctly:

setfreq m8

i2cslave %11010000, i2cfast_8, i2cbyte

writei2c 0, ($00, $30, $11, $02, $08, $03, $10, $10)     'Set RTC to 11:30:00 on Mon. Mar. 08, 2010 and enable 1Hz blink on pin7

main:

readi2c 0, (b0, b1, b2, b3, b4, b5, b6)

debug

goto main

When I look strictly at the second column of the debug screen, the values beside the registers are correct- without any conversion. I watched it for a minute to see the rollover at the 59 second point, and while the b0 value in the first column beside b0 was '89' which I see is the rightmsot column '%01011001' converted, in the second column it was '$59 (Screenshot attached). The very next update of the debug screen changed them to '00', '$00' and '%00000000' respectively.

I've editted the file to manually set time and date to various values to watch rollovers at midnight, months end, years end... and each time, if I look strictly at column 2 values, they are correct without any conversion.

I appologize if I'm being thick here, but I'm not seeing what you're saying about debug not showing me accurate information. If I use column 2 only, it appears to accurately reflect the current time /date values ??

Regards, John.

 

[Hydroid]

Can you swap DS1307's between the boards to check?

I must have read your mind...

Yes, both DS1307 chips are socketted, so I did swap them bewteen boards. The AXE091 still runs slow, the Futurlec is almost spot on as far as I can tell.

I know I have a few loose crystals and as soon as I find them I'll have to do some crystal replacement surgery to see if that helps. I would think so as there's nothing left - I think ?

Regards, John.

 

[Hydroid]

I think OP

'OP'

has his BCDs/decimals all lined up and had a working clock, and is just asking about accuracy. 30 seconds in 1 month is all you are going to get from a 10ppm crystal and a DS1307. That doesn't mean it's a 'bad' DS1307.

Maybe John could summarise where we are, rather than us going in two directions (accuracy vs. fundamenatal BCD/decimal confusion) at once...

Summarizing:

Yes, I have a working binary clock that displays the time (HH,MM,SS) and then with a button push also displays the date (DOW,DD,M,YY) using a 6 column by 4 row multiplexed LED display. There's no issue with that.

The original post wasn't even initially about the discrepancy in the 1307 timekeeping; it developed into that.

My original query, which was never really talked about, was a confirmation that I was using the code I had written (which I included in the first post) was correctly dividing the grid frequency of 60Hz to a 1Hz output.

That being said, it's been an interesting and useful discussion - in my view anyway

Thanks, John.

 

[Andrew Cowan]

OP = Original Poster (ie you).

A

 

[vttom]

Getting back to the pulsin idea....

Instead of throwing away the pulse width measurement, use it to detect a shorter than expected half-wave to reject glitches...

do
pulsin 1,1,w3
loop until w3 > (some threshold)

 

[Hydroid]

OP = Original Poster (ie you).A

Ah, makes sense.

I learn most of my short forms from the text messages that my daughter sends, like lol, rotfl, ttyl...

Hadn't seen that one

 

[Hydroid]

Getting back to the pulsin idea....

Instead of throwing away the pulse width measurement, use it to detect a shorter than expected half-wave to reject glitches...

do
pulsin 1,1,w3
loop until w3 > (some threshold)

I like it.

I've just had a look at the manual, and if I understand the PULSIN description correctly, the register (w3) in your example, would not hold the actual pulsewidth timing, but the # of 5us units (assuming I'm running at 8MHz).

So, if I'm measuring 60Hz, 1 cycle would be 1/60s = 16.66ms and the positive going half of that (assuming again that I code a '1' per your example to detect a low to high transistion) would be half or 8.33 ms.

Then, w3 should contain 1666 (8.33ms / 5us = 1666).

I'm wondering, does the PULSIN routine start timing exactly when the sinewave crosses above the zero point, or is there some delay there ?

I can't seem to find it in the manual just now, but I'm certain that I read that debug affects the timing of some commands - PULSIN I believe was one of them. Would I see accurate results ?

I'll have to breadboard up a chip after dinner and see...

John.

 

[boriz]

“I'm wondering, does the PULSIN routine start timing exactly when the sinewave crosses above the zero point, or is there some delay there ?”

That would depend almost entirely upon your interface circuit. The one shown in your first post is incomplete. If you present the input with a scaled down version (<5v peak) of the half-wave rectified mains waveform, then PULSIN will return < 8.33mS because of input threshold issues. IE: Digital input is considered LOW when the voltage is below a certain threshold and HIGH when above a certain threshold. These thresholds are not the same voltage. There is an ‘uncertainty’ zone between the two levels which may be read as HIGH or LOW depending on the particular bit of silicon you’re using. For precise timing of a slowly varying waveform, you’ll need to do some experiments.

With reference to your circuit, it looks like the transistor is configured as an emitter follower, so the input voltage to the Picaxe pin is coming from the emitter and is a copy of the waveform on it base (minus the Vbe drop of around 0.7v). But exactly what is the source of this base voltage? What’s the peak? What is the transistors collector connected to?

On noise:
PULSIN carries a certain amount of noise immunity since it requires two transitions. EG: If the normal HIGH duration is, say 6mS (reads 1200 at 8MHz) and a positive going spike hits half way through, the input will not go below the LOW threshold and the PUISLIN timer will not stop, so in that particular case, the spike will have had no effect. Also, if the spike is negative going and does stop the timer prematurely, giving say 3mS (reads 600), then unless the spike is very drawn out and lasts long enough for the next PULSIN command to be executed, it will also have no effect since the next PUILSIN command needs to read a LOW-to-HIGH transition before its timer starts.

It’s not infallible though and some basic filtering of the mains waveform is recommended.

On Debug:
It’s a slow command. It takes quite a while to execute and you will miss some pulses during its execution. Better to take several samples, store them in RAM then read them out later. EG: Sample pulse width, store in RAM location 1, sample pulse width, store in RAM location 2, etc.. until you have taken (say) 20 samples. Then read the RAM data using SERTXD or DEBUG.

See the POKE/PEEK commands for handling RAM.

 

[SAborn]

Yes you are correct column 2 do read correct as it is in BCD my comment refered to the decimal figures in colunm 1.

The only difference i see on first look ar what you are doing compared to me is you use
I2Cfast_8 and i use I2Cslow, i have never used I2Cfast to know if it makes any difference but you might want to try I2Cslow and see, as it will operate plenty fast enough in this mode.

 

[Hydroid]

The only difference i see on first look ar what you are doing compared to me is you use I2Cfast_8 and i use I2Cslow, i have never used I2Cfast to know if it makes any difference but you might want to try I2Cslow and see, as it will operate plenty fast enough in this mode.

The ic2fast_8 was in the code where I first got the desire to build myself a 6 column clock with day/date. I saw it here on this forum (http://www.picaxeforum.co.uk/showthread.php?t=11126)

Being new to Picaxe, and not fluent at all in i2c, I just left everything as is.

Your reply got me curious though. I looked through the Picaxe and i2c bus tutorial and saw reference to i2cslow and i2cfast , but nothing on i2cfast_8. The only place I came across i2cfast_8 was in manual 2 under hi2csetup .

I tried dropping the _8 and just have i2cfast , but that caused the program to lock up. I found that i2cfast would work if I removed the setfreq m8 from the program and have the 28X1 run at 4Mhz, but then the multiplexed display was jittery.

I did try i2cslow and it works just fine so I left it at that - at least it now matches the i2c tutorial.

Thanks, John.

 

[Hydroid]

That would depend almost entirely upon your interface circuit. The one shown in your first post is incomplete.

I suppose it is. The 60Hz signal is direct from a 9VAC walwart and the collector connects to the regulated 5VDC line.

IE: Digital input is considered LOW when the voltage is below a certain threshold and HIGH when above a certain threshold. These thresholds are not the same voltage. There is an ‘uncertainty’ zone between the two levels which may be read as HIGH or LOW depending on the particular bit of silicon you’re using. For precise timing of a slowly varying waveform, you’ll need to do some experiments.

Makes sense. I did some experimentation and saw that my circuit gave me a w1 value of 1503 +/-2.

So then, I would think that I should set the value somewhere below that, say 5% lower, so I don't miss any valid pulses - as well as have some basic filtering of the AC input as you mention.

Thanks, John.