Author Topic: Synchronizing multiple Moteinos  (Read 415 times)

mah115

  • Newbie
  • *
  • Posts: 31
Synchronizing multiple Moteinos
« on: December 07, 2018, 01:18:46 AM »
Hello, looking for some expert advice here.
   First, the Moteino looks like a very thoughtfully designed product, nice work!
I'm trying to synchronize some strobe lights wirelessly with a camera, and the Moteino seems like a great fit if I can get them to synchronize within less than a millisecond. *edit: millisecond, not microsecond! *

My idea is simply to broadcast a periodic heartbeat from the master mote with a timestamp (maybe every 10 seconds or so), and then subtract out a pre-measured time delay that it takes to clock the bits in and out of the radio, etc.

My question is, when I send the RFM69 radio a packet, is the time that the packet dwells in the buffer before hitting the airwaves deterministic?  I'm guessing that these radios are smart enough to hold the data in a buffer if there is someone else transmitting on the same channel, or maybe there's internal processing time that's not deterministic.

In my case, I would like to transmit immediately or after a deterministic time, and if the packet gets lost due to collision, we'll just try again 10 seconds later.  It seems like if I put the radio in "Continuous Mode" it will do what I want, but it would be nice to have the robustness of packets.  Is there a way to make the packets get sent and received in very precise intervals?

 I've read through some forum threads where others have had similar needs:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/a-few-fundamental-questions/
https://lowpowerlab.com/forum/moteino/moteinos-ds3234-rtc-sharing-spi-require-hard-reset-each-time/msg13009/#msg13009

 but I'm still a bit unclear on the behavior of the radio.

Thanks!
Mike
« Last Edit: December 07, 2018, 04:48:24 PM by mah115 »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6019
  • Country: us
    • LowPowerLab
Re: Synchronizing multiple Moteinos
« Reply #1 on: December 07, 2018, 08:44:18 AM »
I'm trying to synchronize some strobe lights wirelessly with a camera, and the Moteino seems like a great fit if I can get them to synchronize within less than a microsecond.
Why so ultra fast?
How do commercial wireless camera flashes work, how fast do they sync (ie from depressing the shutter in the camera and the flashes in the room to flash).

Unfortunately with RFM69 it will take at least a few ms to transmit even the shortest packet. That's thousands of times slower than what you say you need  :'(
You may stand a chance with the MoteinoM0 if you hardwire.

mah115

  • Newbie
  • *
  • Posts: 31
Re: Synchronizing multiple Moteinos
« Reply #2 on: December 07, 2018, 12:08:55 PM »
It's for a video camera with high frame rates, where we want illumination on some frames and not others.  Delay is ok as long as I can calibrate it out, jitter is the problem.  So if it takes a few ms to transmit, that's fine, as long as it's the same amount of ms every time.

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Synchronizing multiple Moteinos
« Reply #3 on: December 07, 2018, 04:35:59 PM »
can you use GPS at each of the nodes?  That will give you an excellent time reference. +/- 10ns

If you want to try the radios, you'll probably be able to do something more predictable if you switch to OOK mode with one Node transmitting a pattern to all the others.  That should have better than 1uS repeatability.

Tom

« Last Edit: December 07, 2018, 04:42:07 PM by TomWS »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6019
  • Country: us
    • LowPowerLab
Re: Synchronizing multiple Moteinos
« Reply #4 on: December 07, 2018, 04:37:53 PM »
@mah115,
In your first post you mentioned microseconds so maybe you really meant milliseconds?
Even so it will be tough with any wireless protocol, to get a guaranteed timing. There are things to consider like collisions and other events that prevent a transmission to complete successfully, so retries and ACKs are implemented in the library to account for that. For most applications this is transparent and some small milliseconds delays are acceptable.
When you call the library to send a packet, the timing can be deterministic, if you dont care about things like listen-before-transmit to avoid collisions, and it can just fire the packet regardless what's in the medium at that time.

For high precision applications I would recommend using a wired setup to ensure timings are met.

mah115

  • Newbie
  • *
  • Posts: 31
Re: Synchronizing multiple Moteinos
« Reply #5 on: December 07, 2018, 04:58:22 PM »
Ah yes you're absolutely right, I meant a millisecond, not a microsecond!  Good catch!
Which function should I call in the library to turn off listen-before-transmit?  Occasional packet loss is acceptable in this application because I only need to re-sync once in a while to correct for oscillator drift.

@TomWS Unfortunately I can't use GPS because it's indoors, but I'll look into the OOK mode.

I've ordered a pair of Moteino M0s and I'll give it a shot.  I'll report back how it goes.
« Last Edit: December 07, 2018, 05:08:27 PM by mah115 »

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Synchronizing multiple Moteinos
« Reply #6 on: December 07, 2018, 05:16:46 PM »
Ah yes you're absolutely right, I meant a millisecond, not a microsecond!  Good catch!
Which function should I call in the library to turn off listen-before-transmit?  Occasional packet loss is acceptable in this application because I only need to re-sync once in a while to correct for oscillator drift.

@TomWS Unfortunately I can't use GPS because it's indoors, but I'll look into the OOK mode.

I've ordered a pair of Moteino M0s and I'll give it a shot.  I'll report back how it goes.
GPS would be overkill if all you want in millisecond repeatability anyway.  Millisecond repeatability should be achievable fairly easily, but I'd still use OOK mode which would avoid messing with collision detection uncertainty among other things.

M0 will have HW timers that SHOULD be easily synchronized.  Unfortunately configuring them is a nightmare!  328P also has T1 & T2 timers that could be used with much less hassle. 

Tom


mah115

  • Newbie
  • *
  • Posts: 31
Re: Synchronizing multiple Moteinos
« Reply #7 on: December 07, 2018, 05:23:45 PM »
Thanks Tom.  Can you explain why the M0 timers are hard to configure?  Is it just too many features/register settings, or are there bugs/quirks?

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Synchronizing multiple Moteinos
« Reply #8 on: December 07, 2018, 06:31:02 PM »
Thanks Tom.  Can you explain why the M0 timers are hard to configure?  Is it just too many features/register settings, or are there bugs/quirks?
I will try to say this in a civilized way  ::)

ARM SOCs, in general, have a bunch of different peripherals that can be configured in a variety of ways.  Some chips provide a very extensive interconnect matrix that literally lets you tie any peripheral to any set of IO pins, or, better yet, to internal 'Event' busses that allow setting up hardware connections between peripherals so that you could, for example, set a counter to count incoming pulses and, at a trip point, trigger the AD converter, which, when done, will in turn signal the processor and wake it up (as it can sleep the entire time all this is going on in the background). 

The SAMD21 has this ability in a less universal way, ie, there are only a subset of interconnects that are implemented on the chip.  Consequently, the interconnect choices are governed by what other choices are made on the chip.  If you're using one set of choices, a whole slew of options disappear.  Now, this might be reasonable to make it more HW efficient, however, the combination matrix is so complex, to date (and to my knowledge), no one has produced a set of library functions that make it trivial to say, set this timer/counter in count mode and take the clock input from GPIO5 and the enable from the overflow of Timer 1.  To implement this you have to declare a set of macros that, IMO, make the code unreadable and extremely difficult to debug.

By contrast, Nordic Semiconductor chips have a consistent syntax for virtually all of their internal interconnects that allows you to learn ONE syntax and then apply this knowledge to any other peripheral you want to use.

For the most standard configurations, the Arduino library authors have taken care of this problem for you.  However, good luck if you want to deviate from the 'normal' configuration.

Tom

mah115

  • Newbie
  • *
  • Posts: 31
Re: Synchronizing multiple Moteinos
« Reply #9 on: December 07, 2018, 07:22:45 PM »
Oh dear.  I didn't go with the 328P because I wanted something with a capture module that can measure the pulse width of a reference signal coming from the camera.

I know you can do this with timer interrupts with the 328P, but the Arduino libraries often the timers for this or that function so I figured I'd throw money at the problem and get all the timers and peripherals I'd ever need.  Maybe I should have gone with the ATMega1284P?

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Re: Synchronizing multiple Moteinos
« Reply #10 on: December 07, 2018, 08:46:20 PM »
Oh dear.  I didn't go with the 328P because I wanted something with a capture module that can measure the pulse width of a reference signal coming from the camera.
Well, the M0 is certainly capable of doing that!  I'd like to see your code when you're done, though  ;)
Quote
I know you can do this with timer interrupts with the 328P, but the Arduino libraries often the timers for this or that function so I figured I'd throw money at the problem and get all the timers and peripherals I'd ever need.  Maybe I should have gone with the ATMega1284P?
I haven't evaluated the 1284 from this perspective so I don't know.  In general the ARM timers have great capture capability.  I suggest working on problem #1, synchronizing multiple nodes, but use the M0 because it WILL be able to measure the pulse width accurately, you may have to do some learning, that's all...

Tom
PS:  There are some references to OOK implementations in this forum.