NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.
Microcontroller Programming » Syncing up 2 or more microcontrollers
January 15, 2013 by scootergarrett |
Here is an interesting problem with probably many solutions, I would like to open up for ideas. Say I had 2 identical independent sensors/microprocessors units, and I wanted them both to take data starting at the same time, so they could be compared without having to post process sync data. Easiest way would just to turn them on at the same time, but I’m thinking the activation time might vary too much, and this is just too simple. So I was thinking have a master and slave sensors, which would be connected temporarily then a signal would be sent and all the sensors would start. Sound feasible/ any other ideas? I’m looking to sample at 400Hz to give an idea of the time accuracy I’m thinking of |
---|---|
January 15, 2013 by Ralphxyz |
Hi scootergarrett, now I've actually thought about doing something like this before but ended up realizing that I really could not detect what was not simultaneous actions with a 14.7456 clock tick and then I could go to 16 mhz or even 20 mhz with the ATmega 168 or 328 processor. At 400Hz you would get over 3,000 cycles a second is your perception faster than that? That aside lets think about this. You can simultaneously change 8 pins at a time by simply addressing a port so you could theoretically turn two (8) sensors on at the same time. Ralph |
January 15, 2013 by JimFrederickson |
It is often customary in Critical Industrial Control Applications to have multiple sensors subsystems reporting results. Many systems even implement a "voting scheme" in order to protect against bad measurements. Personally, in your case, I would just have the sensor take it's measurements continuously, and process the results using averaging and a maximum delta/change rate. Then you could use and I2C implementation, or a 3-wire Communications Implementation, to send the results on demand. The I2C Standard already supports "multi-drop"/"multiple device on a bus" at one time. A 3-wire implementation is "point-to-point", but it is not too hard to make a Master to to use a "token-ring scheme" or to have multiple 3-wire buses from a Master to communicate to multiple devices. (Usually a 3-wire bus will use a "device select line" to select a device tied to a common bus.) If you really need to have measurements that are as "close to simultaneous as possible" then you can tie the sensor subsystems to a "trigger I/O" that the Master would assert when a measurement is desired. Then you can use the chosen communications bus to gather the results. From what you have described so far, I wouldn't think this would be necessary for what you want to accomplish. |
January 15, 2013 by scootergarrett |
Ok this is what I got so far 2 chips (but could just as easily be 5) connected, as shown here. The primary chip sends a low command on PC4 then starts normal code while the secondary chip(s) wait for PC4 to go low then start normal code. The 'normal' code I have is just blinking LED's so I need a 2 channel scope to test this (which I will to tomorrow) to see if they are out of phase. Anyways after the normal code is going the chips can be disconnected from each other. To keep from having to pull the serial cable wires and navigate to a different directory with command prompt I made a variable 'primary' that controlled which code was run.
|
January 16, 2013 by scootergarrett |
Well somehow I ended up with 2 slightly different crystal oscillators (14.7456N and F14.74P), so after running the code for a while they drift apart as expected, but I was able to measure the first cycles of the 'normal' code and there was no measurable phase difference (measuring at 0.065ms per sample). So 400Hz should be fine. close up of scope output |
January 16, 2013 by JimFrederickson |
Scooter, There are, as you have discovered, numerous issues that can cause a differences between timing of microcontrollers. (Type of clock, quality of any and all parts involved, variances in solder joints, operating temperature and temperature variances, power fluctuation, etc...) With separate systems/subsystems that are not connected it would be impossible for
you/I/us to get 100% synchonization through a practical method. (In fact even test
equipment has "acceptable skew"/"tolerance" even when on a single board/subsystem.) Pretty much all things are built to operate "within tolerances", which is basically "allowable differences". So what is your "tolerance" going to be? You can do a "simple adjustment for "drift", as you phrased it, that will get you a little closer to 100%. Do the following:
(Note, if you have more than a single subsystem then you would need to connect them all
together before resynchronizing them. If you did it individually your
"post-processing" would have to take into account the "Master" will have a
"synchronization tag" for each slave and each slave will only have it's own
"synchronization tag".) Now your "sample data" will have "samples" and "synchronization tags". Comparing the "synchronization tags" in a "slave subsystem" to the appropriate "synchronization tag" in your "Master subsystem" will tell you "how far off and in what direction off" the subsystems are. Now this won't account for "all of the drift possibilities", but it would get you a little closer. If you did this over several "sample sessions", and if the differences
between the Master and any particular slave subsystem remained somewhat consistent you
can be more assured of the accuracy. But again... Another change needs to be made as well... The current synchronization method will not work. Breaking apart a common GND, if your subsystems are battery powered, is unlikely to
disturb processing too much. (With the assumption that both batteries are very similar
and charged to a similar level. Although it likely will have some affect.) Now
reconnecting them" will likely have a much greater affect. (The assumption here, is that you said you didn't want wires to connect sampling subsystems, so I am thinking that may very well apply to "power connections". Hence, the assumption of "battery power".) Most likely the best method would be to use and IR LED and IR Phototransister pair to
transfer/detect the synchronization signal between your subsystems. That way there doesn't need to be an electrical connection. |
January 16, 2013 by pcbolt |
@ scootergarret Another possibility you could try is to calibrate your MCU's ahead of time. Arbitrarily assign one MCU/clock as "right" and the other as "wrong". Then you could setup an identical interrupt driven timing program on each system to measure the "drift". Once you deploy the "wrong" system in the wild, you can compensate along the way. You could even extend the scenario to compensate for temperature differences if the MCU's are connected while in different environments during the calibration process. |
Please log in to post a reply.
Did you know that electric fields behave differently in different materials? Learn more...
|