LWmesh - time sync idea

[Nick Novak]

I had an idea reading another thread regarding wireless time slotting and wanted to float it out here.

The hardware documentation is a bit vaugue and I haven't done any experimentation here but could the TOF module be used account for rebroadcast time in a mesh network?

My understanding of the TOF module is that it's a timer that is triggered on packet RX and its count value is inserted directly into an outgoing packet.  I'm just not sure if that can be applied to any packet or if it's locked to a special TOF packet and reply.

I'd ultimately like to use this to synchronize certain functions of my product, but this is low priority for me.  Others may be able to use it as a stepping stone for the holy grail of a time slotted mesh.

Thoughts?

Anyone have any experience with dust in a real network?  It sounds way too good to be true.



 

[ataradov]

The hardware documentation is a bit vaugue and I haven't done any experimentation here but could the TOF module be used account for rebroadcast time in a mesh network?

TOF is designed for ranging application, and on its own it is pretty useless. It is meant to be used in conjunction with a phase measurement unit. PMU results will wrap around every few ft, and TOF is meant to distinguish which wraparound we are in.

But none of this is properly documented and can be used without an NDA.

My understanding of the TOF module is that it's a timer that is triggered on packet RX and its count value is inserted directly into an outgoing packet.  I'm just not sure if that can be applied to any packet or if it's locked to a special TOF packet and reply.

In theory it can be applied to any packet, but the location of this information is fixed, so it must be OK with your protocol.

I'd ultimately like to use this to synchronize certain functions of my product, but this is low priority for me.  Others may be able to use it as a stepping stone for the holy grail of a time slotted mesh.

Normal hardware timers work good enough for timing. The main problem with synchronization is allocation of time slots in a mesh network. It is really hard to do without having a really smart central coordinator and/or fixed mesh of routers.

Anyone have any experience with dust in a real network?  It sounds way too good to be true.

You mean actual physical dust, or the company/protocol?

[Nick Novak]

TOF is designed for ranging application, and on its own it is pretty useless. It is meant to be used in conjunction with a phase measurement unit. PMU results will wrap around every few ft, and TOF is meant to distinguish which wraparound we are in.

It seems perfectly suited for this though if you're looking for sub ms accuracy over multiple hops of a mesh.  I always thought this was used to time an ack turnaround in the ranging scheme... but I guess that doesn't make that much sense if the timer runs at 16MHz.  That'd be like 20m of variability introduced.

But none of this is properly documented and can be used without an NDA.

That's a bummer but I feel like enough is revealed in the data sheet to use it for this purpose.  I was hoping you might confirm the viability.

In theory it can be applied to any packet, but the location of this information is fixed, so it must be OK with your protocol.

Yes I recall it's stuffed in bytes 126 & 127.  Not sure what happens if you aren't using the whole payload?  Will it pad out the packet or just append to the last bytes?  Not sure what happens with security bit on either?  I'm guessing the counter value is added and stripped at the physical layer.

Normal hardware timers work good enough for timing. The main problem with synchronization is allocation of time slots in a mesh network. It is really hard to do without having a really smart central coordinator and/or fixed mesh of routers.

Agreed and I can think my way through time slot assignment in my application but how else would you achieve the synchronized time base if the beacon takes multiple hops to reach the network edges?  If there are other packets in flight and RETs then delivery becomes pretty non deterministic.

You mean actual physical dust, or the company/protocol?

I mean Linear Tech's mesh network.  It's from a company called dust and I think they still call it dust.  It's closed source and runs on their own SOC (which hardware wise also sounds amazing).  It promises the holy grail of mesh networks and I wonder if anyone's actually seen it deliver.

[ataradov]

That'd be like 20m of variability introduced.

And that's fine because phase wraps every 50 m or so.

I also don't see how it can be useful for time-synchronization in mesh networks. Can you elaborate your thoughts on this?

That's a bummer but I feel like enough is revealed in the data sheet to use it for this purpose.  I was hoping you might confirm the viability.

I have not tried TOF, but I did try PMU, and it did not work as expected, and I could not figure out a way to make it work.

Yes I recall it's stuffed in bytes 126 & 127.  Not sure what happens if you aren't using the whole payload?  Will it pad out the packet or just append to the last bytes?  Not sure what happens with security bit on either?  I'm guessing the counter value is added and stripped at the physical layer.

I have no idea about any of this. I was interested in ranging, but without PMU working, TOF was useless to me.

if the beacon takes multiple hops to reach the network edges?  If there are other packets in flight and RETs then delivery becomes pretty non deterministic.

That's the whole problem. You don't actually propagate beacons. Your goal with the design is to assign local coordinators and figure out time slots in a way that noting intersects. This is similar to how cell base stations are spread across the channels. But unlike the ad-hoc networks, cellular networks are designed ahead of time.

I mean Linear Tech's mesh network.  It's from a company called dust and I think they still call it dust.  It's closed source and runs on their own SOC (which hardware wise also sounds amazing).  It promises the holy grail of mesh networks and I wonder if anyone's actually seen it deliver.

I have only looked at it briefly and many years, but I did not find it revolutionary in any way. It is just a solid implementation of  mesh network with some heuristics. It is not magic, and it will suffer from the same issues as your traffic gets closer to the network capacity.

[Nick Novak]

My idea was to use that TOF timer in the rebroadcast beacon rather than a reply packet.  Not a standard broadcast per say but a message that may filter through the application layer where the propagation delay could be accumulated.  The TOF timer is intended to account for the processing time of the node.  The end result should be synchronization to the resolution of the 16M timer or whatever jitter there may be in the trigger mechanism.


 

[ataradov]

Rebroadcasting beacons is a bad idea anyway.

The smart mesh would basically identify a core group of nodes (dynamically) and assign them to be coordinators, which would figure out scheduling between themselves (this may be 10% of the network nodes). And the rest of the nodes will pick a core node as a parent.

All core nodes will hear beacons from each other, and adjust their timers accordingly, so it all will stay in sync.

The biggest problem here is to figure out the algorithm for forming the core of the network. I had some thoughts about this for LwMesh v2.0, but this obviously never happened.

[ehughes]

The Dust products work well.      The modules are in stock at Digikey and make getting running easy.   
There is significant usage data on the Dust modules.  Lots of real world deployments, etc.   If you want to get up and running quickly they are not a bad way to go.

You would be hard pressed to find a lower cost solution that works out of the box the same amount of heritage.