I previously wrote here and since then everything was going great up until now. I’m trying to use two ultrasonic sensors in order to measure distance in between them instead of measuring the distance to a random object. I’ve confirmed that such solution works flawlessly if I connect both sensors to the same trigger signal by cable, but the whole idea for me is to have them working remotely, so this option is only a PoC.

In order to get it working remotely I’m trying to use two controllers with nRF24L01+ each in order to synchronize them. nRF24L01+ setup is based on this site. As seen in code below I was hoping, that interrupts on successful transmission are done at the same time, so I tried to put the trigger function in there. That didn’t work, sadly. If I replace trigger function with a blink of a LEDs they seem to work simultaneously for a human eye.

I estimate that the offset must have been larger than 800us while I need it to be less than 10us. That’s based on the speed of sound and my testing setup.

Can anyone suggest a better solution or idea?

Also, I thought that CE signal from both nRFs will drop simultaneously and two same microcontrollers with same frequency will execute same code in the same time, where am I wrong with my current solution?

Hardware, two of each:

ATmega328p, ext. oscillator 16MHz, power supply is filtered properly, fuse bits are set as the should,

While it's not dangerous to cli() in an ISR() there's no real point as the AVR disables I in SREG on the way ot the ISR() anyway. But what you must NOT do it sei() in an ISR(). If you do the ISR() could be interrupted by another instance of the same event before the handling of the current one is complete. Each time that happens it will leave a raft of registers stored on the stack. If it happens too many times the stack will "eat" all the RAM. Disaster then ensues.

I see talk of microsecond level synchronisation then you talk about ISR()s and radio links which almost certainly will add far more delay/jitter to anything you are trying to synchronise.

If the two stations are to measure things then perhaps all they need are accurate coordinating timestamp sources?

For example if each makes regular readings then over time it would probably be possible to track the signals (Kalman perhaps?) therefore from the "trend line" you could probably predict where the signal was (or will shortly be) based on the samples at any given time. Then you can time synchronise that to a reading at the other station.

EDIT: OK a picture might help...

The two sensors are taking readings at different times but in this case the distances they are measuring are changing in linear fashion so if you know that at time 50 Sensor 1 reads 37 then it doesn't matter that you don't actually have a reading for Sensor 2 at exactly time 50. You can predict that it would have been 62.5

Of course this very simple example relies on the distances changing in a linear fashion so it's very easy to predict where the signal would have been at a time for which you don't have an exact reading. If the reading were not so linear you may need some kind of "curve fitting" and that's where something like a Kalman filter might come into play.

Next you have one micro as "master clock" and the other as "slave". Assuming the AVRs are accurately clocked you just need master to send a "time check" packet over the airwaves every now and again so the slave can adjusted his own clock to be in sync. Then he can later pass back his own readings to the master that can then do this "sample matching" exercise I've outlined.

Just an idea anyway. ;-)

EDIT: actually if you are sending "time sync" packets from master to slave (only needs to be from time to time if their might be some "drift") then actually the timing of the actual samples could be synchronised. Instead of (as the picture shows, CPU1 sampling at 10, 30, 50, 70 and CPU2 sampling at 20, 40, 60, 80 then they could both trigger samples at the same time safe in the knowledge that their clocks were sync'd. Then you don't even need the trend matching as you have the samples from the exact same time frame anyway.

Firstly, an understanding of US-015 is required. In normal way of working:

-you send a 10us long signal to his trig pin,

-the sensor measures the distance by sending ultrasound signal and measuring time elapsed before it bounces back from obstacle and come back,

-the sensor sends signal from echo pin, the length of which is in directly proportional to the measurement.

What I want to do is to trigger sensors from both stations simultaneously, so that the one in Station A reads foreign signal from Station B as his own, sort of tricking him into measuring the distance between A and B instead of A and any_obstacle_in_front_of_A.

The result is printed on PC. In practice after turning on Station A the results of measurement should half (I put a screen behind Station B).

About the sei() in ISR(), should I simply remove them? It appears that I was mislead by that tutorial that I've sent in the first post.

About the solution, I'm not sure if you understand what I mean. I don't need to get a reading from both sensors, I need to fool one to treat the other as his own source (as explained above). So I don't really have a way of going around it other than triggering them at the same time.

clawson wrote:

ISR()s and radio links which almost certainly will add far more delay/jitter to anything you are trying to synchronise.

If it was a constant delay that I could define with high precision, maybe I could just add synchronization delay to Station A controller?

It just occured to me, what if both US-015 were connected to a separate controllers receiving signal from master controller? Sending radio signal over a few centimeters sound silly, but if it worked...

yeah this is the problem with the internet. That article certainly looks well thought out and professional and yet it contains such a fundamental error. You can never really know the provenance of anything you ever read on the internet ;-)

Irrehaare wrote:

If it was a constant delay that I could define with high precision, maybe I could just add synchronization delay to Station A controller?

yeah that's kind of what the latter parts of my post above were saying. Assuming you can get both AVrs clocks to run in sync (by A sending regular tiechecks to B to keep it in step) then both could agree "we do the thing when our clocks say 100" and both trigger at exactly that moment. This does not require A to actually send an almost instantaneous trigger to B at that very moment - just to have previously ensured their clocks are in step.

HOWEVER there is still a bit of an issue with that - because the very message A sends to B to say "the time now is ..." could itself be subject to delay/jitter. That's a tricky nut to crack !

I suppose another way to do it is to ensure they BOTH get very accurate time checks from some common reference - the obvious one that springs to mind is GPS. But that would involve both units having a GPS module too.

If I somehow started it with cable in order to get initial sync, how long would it be before the error goes to far (>10us)?

@ki0bk The echo of Station A signal can be ignored, it only forces you to wait a while before sending next signal. I tested it with cable connection and it works that way. You will always hear the first signal (from B) because it has twice less distance to travel and that's the signal I care about.

Like I said, big picture is basically reproduction of this project, or actually only the localisation part of it. In a hindsight, putting it right below the picture could be a bad idea.