two PCF8583 using the same watch crystal

crazynight

Senior Member
Is it possible for two PCF8583 chips to use the same watch crystal? My assumption is that they can but would like someone with more technical skills to confirm. The reason I want to use the same crystal is that it will reduce the margin of error between the two timings or atleast they will both be wrong by the same amount.

Basic layout is as follows:


PICAXE (1) PICAXE (2)
: :
PCF8583 (1) PCF8583 (2)
: :
WACTH CRYSTAL

I am using two PCF's as there is a chance that the read command will take place at the same time for both picaxe chips.

Thanks
 

hippy

Technical Support
Staff member
It would seem unlikely you can wire the two PCF8583 is parallel, OSCI to OSCI, OSCO to OSCO and a crystal between those. The two will be fighting each other to oscillate the crystal.

It might be possible to have one control the crystal with the other having its OSCI driven from OSCO but you will probably need to experiment. The usual arrangement for driving two devices from the same clock source would be to have a single logic level output oscillator circuit and drive both OSCI pins from that but you would have to check the PCF8583 datasheet to see if it supports that.
 

AllyCat

Senior Member
Hi,

It might be possible, but probably not as you've shown, particularly with two different types of chip.

Of the two "crystal" connection pins, one is an outut and the other an input, so it's unlikely to work if you connect two outputs together (such that they "fight" each other). You probably need to connect the crystal to just one chip and connect the other chip so that its input looks at the other's output. Looking at the full data sheets for the chips may help.

It depends what test equipment you have, but in principle, I'd try the crystal on each chip in turn and see which oscillator pin looks most tolerant of loading (using a "wet finger" or whatever). Then try connecting each of the pins of the other chip to see which works best (or at all). It may also be necessary to add, remove or change the value of any capacitors on the oscillator pins.

Ah, beaten by hippy again.

Cheers, Alan.
 

westaust55

Moderator
Additionally, your very basic diagram (hand sketch would be far clearer) suggests that the two PICAXE and two RTC may be sharing a common i2c comms bus in which add there is no way the two PICAXE chips can read from the RTCs at the same time.
What is the objection to a few extra pence/cents for a second crystal?
 

inglewoodpete

Senior Member
I'll second hippy's caution. Having two loads connected to the crystal will almost certainly change the loading and consequently may shift the frequency slightly. You may have to do some testing over an extended period to see if it keeps good time.

It begs the question: why two clock chips?
 

westaust55

Moderator
Additionally, your very basic diagram (hand sketch would be far clearer) suggests that the two PICAXE and two RTC may be sharing a common i2c comms bus in which add there is no way the two PICAXE chips can read from the RTCs at the same time.
What is the objection to a few extra pence/cents for a second crystal?
 

srnet

Senior Member
My assumption is that they can but would like someone with more technical skills to confirm
My assumption would have been that even if by chance it did work, it would be a very bad design decision to rely on it.

There is no guarantee that the two oscillators wont fight each other and fail to start correctly, so you are introducing a feature that just might start OK most of the time, but is waiting to fail.
 

inglewoodpete

Senior Member
Additionally, your very basic diagram (hand sketch would be far clearer) suggests that the two PICAXE and two RTC may be sharing a common i2c comms bus in which add there is no way the two PICAXE chips can read from the RTCs at the same time.
What is the objection to a few extra pence/cents for a second crystal?
If one bus, both clocks would have the same address too? More explanation required.

srnet: As hippy says, only one chip could excite the crystal.
 

westaust55

Moderator
Furthermore, the PICAXE chips are not intended to have two master devices on the same i2c comms bus.
Norm is 1 master and many slave devices.
 

crazynight

Senior Member
quick diagram attached below (I am at work so can not check the pinouts and resistor locations, but the logic is there)

Just to explain I am still working on my flyball timing system. Which requires times to be recorded for 2 lanes running at the same time

I have discovered that it is possible for multiple I2C commands to be sent at the same time as both lanes could have an activity at the same time (techincally 4 things happen over I2C. get time read lane, get time blue lane, display time red lane, display time blue lane) so have started to split the reading of the time from the PCF8583 and then the displaying on the 4x7 seg display for each lane on a separate i2c hence the 2 picaxe chips.

I understand the crystals can be slightly different so was thinking if PCF8583's use the same crystal at least they will be wrong together as its the time relevant to each other that is important. (Am I worrying about such a small difference and should ignore it?)

Any further questions just ask any assistance will be appricated.
 

Attachments

Last edited:

srnet

Senior Member
Am I worrying about such a small difference and should ignore it?
Probably.

But you need to work it out.

What timing resolution do you need and over what period ?

What is the stated tolerance of the crystals are using ?
 

crazynight

Senior Member
This is what I have to work to, I guess its point 4 which I am working on.

-the timing system shall display the time down to at least the hundredth of a second (xxx.xx) to 2
decimal points
- the timing system must be precise to within 3ms (all system latencies combined)
- the timing system shall be accurate to within 3ms over 60 seconds (50 ppm)
- the timing system shall provide the same timing for both lanes to within 2ms over 60 seconds
- sensors electrical latency shall not exceed 2ms and if scanned, scan latency shall not exceed 1ms
 

hippy

Technical Support
Staff member
I can understand your approach but it all seems a little over-complicated for something which could probably be done with a single 20X2 chip.
 

crazynight

Senior Member
I can understand your approach but it all seems a little over-complicated for something which could probably be done with a single 20X2 chip.
A 20x2 still only has 1 i2c channel so would have the same problem of trying to read and write to multiple addresses at the same time
 

john2051

New Member
Hi,
As far as the using one crystal for both chips, couldn't you use one of the ttl oscillator modules for
32767kHz and feed both inputs on the rtcs?
regards john
 

hippy

Technical Support
Staff member
I can understand your approach but it all seems a little over-complicated for something which could probably be done with a single 20X2 chip.
A 20x2 still only has 1 i2c channel so would have the same problem of trying to read and write to multiple addresses at the same time
That's only a problem if you need to read and write to multiple I2C addresses at the same time. I don't think you would need to do that with an appropriate design which would not need a physical RTC chip either. That seems to be there only to be an elapsed time counter and the PICAXE can provide the same without additional hardware.

If you are having to interrupt an I2C update of a display to read the RTC and then wish to continue with the update of a display you are going to run into problems no matter how it's done. If you can use I2C to only update the displays you will have a much easier time of things.

If the two displays happen to have the same I2C device addresses that can be overcome by bit-banging the I2C. Or stay with a PICAXE per lane. I don't really have a problem with that; it's having any RTC chips which I see as unnecessary and likely causing unnecessary complexity or problems.
 

crazynight

Senior Member
That's only a problem if you need to read and write to multiple I2C addresses at the same time. I don't think you would need to do that with an appropriate design which would not need a physical RTC chip either. That seems to be there only to be an elapsed time counter and the PICAXE can provide the same without additional hardware.

If you are having to interrupt an I2C update of a display to read the RTC and then wish to continue with the update of a display you are going to run into problems no matter how it's done. If you can use I2C to only update the displays you will have a much easier time of things.

If the two displays happen to have the same I2C device addresses that can be overcome by bit-banging the I2C. Or stay with a PICAXE per lane. I don't really have a problem with that; it's having any RTC chips which I see as unnecessary and likely causing unnecessary complexity or problems.
I seem to be going backwards after 3 months :(

The reason I went down the RTC/Crystal route was to get an accurate timer as the picaxe would not report hundredth of a second.

Most races are sub 20 seconds and have no relevance to real time(in terms of is 13:28 now) I just reset the RTC to 00:00:00 and then read the seconds, tenths, hundredths off it.

The time display is only updated when a dog crosses the line its not a continual update as the teams need time to see the time.

All my monitoring of the gates and displaying of times are done by seporate processes there is a chance that multiple read/write commands can happen at the same time changing to a gosub setup would cause a delay and opertunity for the sensor activation to be missed.
 
Last edited:

hippy

Technical Support
Staff member
The reason I went down the RTC/Crystal route was to get an accurate timer as the picaxe would not report hundredth of a second.
I cannot recall any particular discussion but a PICAXE should fairly easily be able to report elapsed time with a resolution of 100th of a second. To 1000th of a second for races under 65s would be achievable, and it should be equally accurate to that using an appropriate PICAXE.

Triggering for start and latching result times should also be achievable as per the desired spec. It should be possible to have elapsed time showing as it progresses and the latched result times without too much difficulty.

I suppose the big question is what you currently have and how best to move that forward. If it is working and simply worry that the clocks may get out of sync with separate crystals I doubt you have anything to worry about in that respect.
 

crazynight

Senior Member
I cannot recall any particular discussion but a PICAXE should fairly easily be able to report elapsed time with a resolution of 100th of a second. To 1000th of a second for races under 65s would be achievable, and it should be equally accurate to that using an appropriate PICAXE.

Triggering for start and latching result times should also be achievable as per the desired spec. It should be possible to have elapsed time showing as it progresses and the latched result times without too much difficulty.

I suppose the big question is what you currently have and how best to move that forward. If it is working and simply worry that the clocks may get out of sync with separate crystals I doubt you have anything to worry about in that respect.
Seems like the hardware for V2 just got a lot less. V1 currently working with dual picaxe, PCF8583 and watch crystals. :D
 

srnet

Senior Member
Seems like the hardware for V2 just got a lot less. V1 currently working with dual picaxe, PCF8583 and watch crystals. :D
Could you provide the details ?

I have been following the thread, but I dont understand your comment above at all.
 

hippy

Technical Support
Staff member
I have been following the thread, but I dont understand your comment above at all.
I believe crazynight is saying he's pushing on with what he has as a "version 1" implementation, but is considering a simpler configuration for "version 2" using just PICAXE with no RTC.
 
Top