You have to step back and think about your basic approach to the problem.

As I understand it, you don't care about the mcus taking measurements at the absoute time (for example in top of every hour). Instead, you want the measurements to be take at the same time, with 1ms of each other.

As such, all you need to do is to start or to trigger the measurements at the sane time for the two mcus.

It couldn't have been easier.

 

Firstly, let's understand what you are trying to do.
You are using ultrasonic sensors. Hence you must be doing some kind of distance or time-of-flight measurement.
Are you using one Arduino to transmit an ultrasonic pulse and a second Arduino to record the received echo?

Imagine a “mirror scenario”, this is to measure 2 seperate events that supposed to mirror each other.

Each Ardunio works by using several ultrasonic sensors to measure the distance to his target. It “triggers” when the distance to his target is lower than a threshold. Have some more complex calculations to be immune to "interference" due to some less accurate sensor readings. And this "interference" makes the Arduino to detect the “trigger” event some measurements after the fact (and not “on the spot”)

Both Arduinos run independently and send data to PC. Need to be able to combine the readings of both, and compute the time difference between their recorded “triggers”, to check how mirrored both targets were hitting the threshold.
And to compare the readings from both I think need to have 1 of 2 things (maybe their are other solutions or those 2 are not feasible… - that’s what is driving me nuts )

1) Both clocks running synchronized ~the same ticks
this seams like the cleanest way as could compare values as they were collected – both clocks are synchronized and don’t have relevant skews along the way.

2) Starting the clocks at the same time, and knowing what will be the skew between them so both readings can then be adjusted

Hope I helped clarify things… but if not let me know...
Wiring connecting both Arduinos were not my initial thought, as I was thinking on "all wireless" but if it’s the only way I’ll go for it! J

 

Events? Such as one arduino detects a bullet out of the barrel, the other one detects the bullet hitting the target and you want to know the time difference? If that's the goal, simply send a pulse from the first arduino to the second once the bullet left and let the second arduino measure the time difference.

using the bullet exemple, 2 guns firing that are supposed to be syncho shooting
I want to know the delay bettween fire1 and fire2. fire1 ou fire2 might have fired 1st, the only thing I would need to know is the time (ms) between 2 shots from 2 different guns.

one (not so) small detail: I don't know in the exact time the shot was fired. Only some 100ms later, so I cannot "trigger" on exact time the event occours.
I like your ideia and have to think if I can use it, as this "delay" cause for filtering "noise readings" from ultrasonic measurements don't let me trigger on the exact moment "the shot" occours, only later.

 

I like your ideia and have to think if I can use it, as this "delay" cause for filtering "noise readings" from ultrasonic measurements don't let me trigger on the exact moment "the shot" occours, only later.

That is Ok. One arduino (master) is listening to the other arduino (slave). The slaves sends a pulse to the master exactly 100 ms after the shot.

If the master detects its shot (exactly 100 ms after the shot), but there's nothing from the slave, the master starts the timer and as soon as the pulse from the slave comes, the master stops the timer and transmits the time interval to the PC.

If the master sees a pulse from the slave, but it hasn't seen the shot yet, it starts the timer and it stops it exactly 100 ms after it hears its own shot. Then it negates the time interval and transmits it to the PC.

Both timers should expire after some time (just in case only one of the arduinos detected a shot).

 

Imagine a “mirror scenario”, this is to measure 2 seperate events that supposed to mirror each other.

Each Ardunio works by using several ultrasonic sensors to measure the distance to his target. It “triggers” when the distance to his target is lower than a threshold. Have some more complex calculations to be immune to "interference" due to some less accurate sensor readings. And this "interference" makes the Arduino to detect the “trigger” event some measurements after the fact (and not “on the spot”)

Both Arduinos run independently and send data to PC. Need to be able to combine the readings of both, and compute the time difference between their recorded “triggers”, to check how mirrored both targets were hitting the threshold.
And to compare the readings from both I think need to have 1 of 2 things (maybe their are other solutions or those 2 are not feasible… - that’s what is driving me nuts )

1) Both clocks running synchronized ~the same ticks
this seams like the cleanest way as could compare values as they were collected – both clocks are synchronized and don’t have relevant skews along the way.

2) Starting the clocks at the same time, and knowing what will be the skew between them so both readings can then be adjusted

Hope I helped clarify things… but if not let me know...
Wiring connecting both Arduinos were not my initial thought, as I was thinking on "all wireless" but if it’s the only way I’ll go for it! J

If the onboard RTC cannot give you sub-second resolution, I would consider using the MCU XTAL clock.

XTAL stability to 5ppm is not unusual. That works out to be about 1ms every 200 seconds.
If you can sync or reset the hardware timer in the two MCUs every three minutes, then just use a hardware timer module in the Arduino clocked by the MCU clock.

 

If the onboard RTC cannot give you sub-second resolution, I would consider using the MCU XTAL clock.

XTAL stability to 5ppm is not unusual. That works out to be about 1ms every 200 seconds.
If you can sync or reset the hardware timer in the two MCUs every three minutes, then just use a hardware timer module in the Arduino clocked by the MCU clock.

I have some I2C RTC module based on DS3231 but can only give up to second. Not sure if this deviation I have on arduino's mega crystals(or oscilators) are due to cheap materials for this board I have... read somewhere that it could be changed... do you know if it can it be replaced/bypassed for another better crystal?

 

As long as there is a synchronization signal, disparate clocks can produce time deltas between MCUs. And with calibration programs, can even adjust for non-event related processing time.

I am winging it here, but the first part, producing a raw time delta, might go like this.

1. Start signal is sent from MCU A to MCU Bs interrupt, whose ISR saves current time (in milliseconds, using a function provided, millis() on an Arduino)
2. Event occurs
3. Stop signal is received on MCU B
4. MCU B saves current time or calculated delta directly.
5. Optional: adjust for time spent saving times and calculation of delta
6. Result output to desired device

 

It took this long to occur to me, but--

If it's possible to wire two processors together, why not use the wire to do whatever it takes to acquire the data, and just use one processor?

 

It took this long to occur to me, but--

If it's possible to wire two processors together, why not use the wire to do whatever it takes to acquire the data, and just use one processor?

Hi,

1st let me apologize for my lack of reply for this long… heavy professional and personal loads prevent me to dedicate time to this project and reply earlier.

Both units need to be independent from each other and compute values for events they detect independently. They will operate mainly without each other, but occasionally they will “cooperate” to measure the skew from 2 events that are suposed to mirrored each other. So I need to find a way to know the difference from both clocks, so I can find the skew between those events measured by both MCU’s.

My best option now (still open to great ideas J) is to have a wire connecting both for this cooperation scenario.

Use this wire to trigger clock sync and skew measure, so I can compute the deviation from both clocks.
Clocks will be starting at exactly the same time (interrupt triggered on both using the wire connection between them) and will run for some seconds to compute the skew on each other.
That will allow me to compensate millis() read on MCU-A and MCU-B on event detection, and compute on PC the necessary adjustments to detect how close they are from each other. TY all for all your great ideas and suggestions. You probably saved me tons of hours of disappointments J

The only thing I would like to test is a way to do this without connecting a wire between them... line of sight between 2 units are not garanteed so IR might not be the best of options... any ideias to allow both units to wake from sleep with very few ms delay sending some signal (RF?) from MCU-A to MCU-B?

all the best,
LG

 

The only thing I would like to test is a way to do this without connecting a wire between them..

If there is a lesson to be learned from this discussion, it is that don't ask for the best approach to solve a problem in a particular way. Instead, ask how a goal can be best achieved. You will be surprised at the alternatives.

For your particular problem, unless you are in some truly weird place, that wire already exists and it is quite easy for your mcus to synchronize to it.

You will see what it is if you think outside the box.

 

They do this in photography using remote strobes.
In your case, have a single 555-timer circuit pulsing two IR emitters within sight of your two arduinos.
This will sync the two systems to within a few microseconds.

 

You might consider a little radio link like this:
https://nathan.chantrell.net/20130621/using-a-cheap-ook-radio-with-the-tinytx/

There are links with better characteristics for sending serial data, but if all you want is a timing signal, on-off keying may be best. I'm imagining that you would somehow prime the receiving unit to expect a trigger, and then send a pulse that starts the data reading. The thing that I think is attractive about this is that you can look for the edge of the received pulse, or use it to trigger an interrupt. If you had to wait for a serial character, as with Bluetooth or the HC-12 units, there's a delay of uncertain length, so they wouldn't be as good.

 

If you have any kind of MAC (medium access control) layer then you have the problem that the time at which the signal was sent may be significantly unrelated to the time at which the signal was prepared by the MCU. If you have control of the system such that you can control part of the signal content once transmission has started, then you can simply embed a timestamp (provided by the MCU) in the data stream to indicate when the transmission started and another timestamp that indicates when the data was taken. At the receiver, you timestamp when the signal reception started and supply that information up the line. Now you have the propagation delay of the signal, which can be estimated at about 1 ns per foot and is likely to be insignificant with the numbers you are talking about.

 

That's why I suggested the on-off keyed radio devices. The delay from transmit to receive is small, and likely to be consistent, so with a few measurements on a scope it should be possible to know how much time to allow for. The "Keep it simple" principle is obeyed.