Urgh. Watching two Micros with identical hardware, down to the SD cards (both of which just got formatted and fresh data put back on them), get out of sync within 2 minutes. I’m pondering just making the controllers as is right now and hope that using a crystal will give me more accurate timings versus the resonators that Arduino uses on their boards. Failing that the other option is to stick a simple RTC on just to provide a timing clock, not necessarily to keep time (though that’s a bonus.) Blah.
I think you will find even crystals will drift pretty quickly I’m sorry to say. Temperature controlled oscillators will give you pretty good results, depending on how much you can afford to spend.
I have used some costing over £500 in the distant past (1990’s) to keep a group of isolated data loggers in sync over several months with great success. But that is probably well over the top for your need and these temperature units are much cheaper.
But things to remember with synchronous code requirements are:
- Oscillator drift - do the calculations from the data sheets (processor and clock);
- Code path variations - unless the units will be executing exactly the same code ALL the time and can never have difference code routes, they will drift due to execution code differences;
- Timer interrupt delays - most systems use an internal timer which cause interrupts to increase the resolution of the clock. There is a delay from the interrupt happening, to it being detected and then the processor switching to the service routine and back again. All this is accumulative and very difficult to account for within code.
Your best solution is to get some way that they synchronise with each other: Physical electrical pulse, radio pulse (not a packet that needs decoding), IR pulse or whatever you can achieve.
Then the master unit, preferable with the most accurate clock, can send out the sync pulse to the waiting slaves. With a bit of skill, this pulse can also be relayed from unit to unit, but that does require more skill on the part of programming, especially with poor clocks.
Reading an RTC is a solution, but again getting these in sync at the start is fun (and re-syncing). If you can find one with better than 1s resolution then you can interrogate it more often, that will help. A lot don’t always take updates when you want, but when they want. So syncing is difficult, you may only get them to sync with +/- 1s, which is pretty rubbish. But remain stable for many months. Hence being able to read smaller intervals is important.
I guess you have serious issues in getting a sync pulse between them anyway! But it will be your best solution.
There are no TCXO/VCXO in the 5V range that I could fine. Everything’s in the 3.3-3.6V range which won’t work for this. All I need as at the most 5 minutes. If I can reach that, I’m happy. Right now it’s not even reaching 2 minutes.
Plenty of 5v oscillators. Here is a 1Mhz 1PPM:
http://www.ebay.co.uk/itm/PRECISION-1PPM-1-000MHz-TCXO-/380174345926?pt=LH_DefaultDomain_0&hash=item58842826c6
This is 5v and TTH mount too. Get a 16MHz and you can feed it directly into your processor
Or I would use a 1MHz (or whatever) through a suitable fixed divider or programmable divider onto an I/O pin. Then at certain points in your software, sit waiting for a state change on the pin, then off you go again.
Depending on the processor, you will probably have a spare timer (16 bit ideally) with external input to drive the divider, then poll (not interrupt) for zero. Then you only need the TCXO.
Any use?
Nope. Find one in SMD form factor, under 5mm.
Yes, bit harder that. But you did not mention the SMD form factor before. I guess you want to replace something.
Not replacing anything, designing from the ground up. I do not have the real estate to use either through hole components, or large ones. I can get a 1ppm crystal that’s 3.2x2.5 mm in size. Crystals are generally much better than resonators, and since I only need it to remain relatively closely synced for only 5 minutes, I’m hoping the crystal is enough. Right now with the resonators by the 2 seconds mark it’s very noticeable that they are out of sync. By 5 minutes it’s horrible.
I see now. Depending on the swing of the 3v3 TCXOs, these might be enough to clock your processor from their 3v3 supply. If the TCXO can swing rail to rail and the processor is not so tolerant, then it may well clock it.
Without knowing which TCXO and processor combination you are considering, then I can’t check datasheets, but I’m sure your are able too.
If you want the best accuracy from a crystal, then try to make sure the processor, crystal and load capacitors are all from the same batches. Rail voltages also significantly affect frequency too. So good stable supplies are just as helpful. Maybe don’t use the same rail that supplies the LEDS.
I can’t have a processor running at 5V and the TCXO at 3.3V. And with three different manufacturers (processor, crystal, caps), getting those parts from the same batch is impossible.
If you purchase the parts from a supplier like Farnell/Element14, then in the order notes you can specify ’ Items x,y,z are to be issued from the same production batch’ and your wish will be delivered. It is likely any two components would come from the same production reel anyway if ordered at the same time.
Last I checked, Atmel does not make capacitors, and Kemet doesn’t make processors. Multiples of the same component sure, but not different components.
I get what you’re suggesting though, multiples of the same thing. Since I generally buy reels of components, that won’t be an issue.
I think you need an external “conductor” to keep them on the same beat, as Adam says. For physically separated devices, I’ve had good luck with a cheaper TSOP IR receiver on each device, and a discreet IR transmitter hidden somewhere that can see all the devices. This transmitter could be something as simple as an old IR remote hooked up to a 555 doing fake button presses, a reflashed TV-B-Gone, or just an ATtiny with an IR LED.
I’m not dismissing this idea, not at all. One of the (future) ideas is to have an external “influence”. However, because of the speed at which these things run and flash LEDs, I can’t quite wrap my head around the whole ‘wait for master signal before continuing’ part. Especially since both of them are running the same identical software. Having to maintain two separate applications (one slave, one master) adds to the complexity, both now as well as in the future. I want self contained units, whether just one, two, or two + an external controller. And if the end-user has a pair, but just wants to use one (no specific reason), I don’t want them to have to figure out which one is the master and which is the slave so they know which to use (since presumably the slave will do nothing till it gets a signal from the master.)
And my experience with an IR LED is that it needs to be in line-of-sight to work. These things will most definitely not be. They’ll be moving with the performer.
Syncing software is not quite a complex as it appears, I have always intended to write a web page that discusses the principles. But someone must have already done it somewhere.
And there is no need to have two versions of your software, the software can interrogate a marker and process either the master or the slave section or even both. This can be a link on an unused pin or a value stored in EEPROM, or anything else.
Then it does not really matter how good the clocks between units are as long as they remain pretty much similar. 16MHz against 8Mhz will probably be more trouble than it is worth. But all based on the same 16MHz clock source will be easily OK.
From what you have described, you will probably need some sort of radio link. However, if you do get the clocks stable enough, then a simple link wire connecting the units before use will keep them stable. This could also be used to keep the units fully charged too and the master ‘sync’ signal can come from the charger. For the radio link, I think you would have master box somewhere just transmitting the ‘sync’ out.
IR is possible, but these will need to be pretty omnidirectional and more trouble than its worth if these are spinning battens. A dumb radio unit that just transfers logic states, rather than actual data sequences is all you would need. Keeps the software oh-so-simple - Always in favour of KISS.
Yeah, I’m going to stick with just the crystals for now and see what they do once the boards are made. If it turns out they’re wildly off, then it’s the cost of those boards plus components that I’ll chalk up to R&D. At this point there’s no sense in adding more complexity to a system that’s only theoretically not going to remain in sync for the short amount of time that I need it to be. I’m not going to add a third “external control” right now. At some point down the road, for a whole different purpose, yes, but not now. These need to be self contained pieces.
My test rigs have too many variables to say it’s definitely the clock source that’s not staying accurate (although I do still say the resonators are a big factor.)
The wire link is pointless. They’re physically turned off. The idea here is that the user will turn them on which will initiate the programming and it’ll sit dormant. When the user pushes a trigger button, that’s when the program actually start running. At that point, till the end of roughly 5 minutes (could be 2 minutes too), I need to keep them in close sync with each other.
My experience with having a master/slave setup is with RF (though I suspect the same process applies to any type of link.) Both were running the same code (with it/then/else conditions determining whether it’s running as a master or slave.) The distinction between the two was made through a value set in EEPROM, so when the unit’s turned on, it knows what it’s supposed to be. The slave would run it’s program and reach a timeout at which point it sits and waits for the master’s signal to continue.
There are two problems with that:
a) the master/slave are permanently set that way. Assume the master unit dies, and the user wants to use the slave. It won’t work because it’s not receiving any signals from the master.
b) if the slave happens to reach its timeout faster than the master, you’re left with a “dead spot” where nothing happens.
Since these are POV displays that are spinning, any break in the display will be visible as a big dark nothing, where the master doesn’t show that. So I can’t use that technique. Then you may suggest, just keep the slave running till the master says to stop and move on. With both of them running the same code, that would mean adding the aforementioned if/then/else condition to determine what it is.
Ultimately I’m left with the whole master/slave setup where I also need to be able to use one without the other, either one, without relying on the other, which is the whole point behind a master/slave: one relying on the other.
Ashley, thank you for more information, it is always good to know a little more about peoples projects. This does make suggestions more accurate and applicable.
You are quite correct with your decisions detailed and I respect those. It does appear you have an interesting situation requiring multiple solutions to various different aspects of the whole problem. And I wish you luck with this and if you would like a ‘sounding board’ then please feel free to air your thoughts.
What about a RFM12B radio module? Then you have a master and slave and send a latch signal to show()?
Quoted from my previous post:
“Ultimately I’m left with the whole master/slave setup where I also need to be able to use one without the other, either one, without relying on the other, which is the whole point behind a master/slave: one relying on the other.”
It’s not a matter of what type of link is used, there are a plethora of options. It’s the constant reliance on a master/slave configuration where if the master fails, so will the slave.