Time synchronization

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi !

I'm using LW_Mesh.

Which is the longest time interval that can be achieved with timer and sleep timer?

Is it for both, as timer.interval is uint32_t, so

2^32-1 = 4294967296 ms ?

What I'm trying to achieve is time synchronization, all nodes in network wake up at the same time and all go to sleep on sleep comand.

So what I would like to know is how precise is sleep timer

HAL_Sleep()

for sleep times of 5-10 min (that is HAL_Sleep(300 000/600 000)).

What about very long sleep e.g. few hours?

Is it a good idea to realize time synchronization with RTC, maybe?

Thank you for answers !

Regards!

Last Edited: Fri. Oct 16, 2015 - 02:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sleep timer accuracy is primarily defined by your 32kHz crystal, so if you pick a good watch-grade crystal, then your time will be accurate. Note that not all 32 kHz crystals are all that accurate.

On the other hand, the less frequent your wakeups are, the more time you need to wait on each wakeup for synchronization.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Alex !

My plan to realize synchronization is like this:

1. COORD sends boradcast command to ask Rs if they have some data to send.
If R has some data, it sends(I've implemented some delay which is : address of R * 50 ms (addresses grove 1,2,3...)) NOACK message to COORD just for information.(Rs that don't have data to send do not respond on this command).

2.after 5 seconds COORD starts to collect data(by ACK messages) form Rs form 1st step.

3.Now that all data from all Rs are collected and COORD sends boroadcast sleep command.

Rs wake up 2 seconds before COORD issues 1st step.

Is this OK or is there better way?

I have some issues with this above.

I have network of 2 nodes both are Rs and COORD (LW_Mesh).

What sometimes happens is one of R just RESET it self(I write information about it in FLASH) when it receives broadcast sleep command. With sniffer I can see broadcast sleep command form COORD and one R but not form 2nd R.

This reset occurs like toggle(one time on 1st R and another time on 2nd R).

I also track down error message form appDataConf() and I few times I received NWK_PHY_CHANNEL_ACCESS_FAILURE_STATUS.

When Rs receive broadcast sleep command I start sleepTimer() (500 ms delay) so they don't immediately go to sleep.

When I have COORD and only one R everything works OK.

Alex, if you need further information(I'm sure you will) just say.

Thank you !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xtal_88 wrote:
Is this OK or is there better way?
Why not just ask all routers one by one? Most of the communications will happen much faster than 50 ms, so you will save on time and complexity will go down.

xtal_88 wrote:
I have some issues with this above.
It is really hard to say what might be wrong without looking at the code.

xtal_88 wrote:
I also track down error message form appDataConf() and I few times I received NWK_PHY_CHANNEL_ACCESS_FAILURE_STATUS.
This is normal, and is not related to the issue above.
At least not directly.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
xtal_88 wrote:
Is this OK or is there better way?
Why not just ask all routers one by one? Most of the communications will happen much faster than 50 ms, so you will save on time and complexity will go down.

Sorry Alex, but I think I can't do it like you suggested, because some nodes will move around and might be out of network(not reachable) and COORD must know at any time how many nodes(addresses which must be called) are there in network.

If you have another idea, just shoot.

I think that broadcast messages are problem and they cause these resets.

xtal_88 wrote:

1. COORD sends boradcast command to ask Rs if they have some data to send.
If R has some data, it sends(I've implemented some delay which is : address of R * 50 ms (addresses grove 1,2,3...)) NOACK message to COORD just for information.(Rs that don't have data to send do not respond on this command).

2.after 5 seconds COORD starts to collect data(by ACK messages) form Rs form 1st step.

3.Now that all data from all Rs are collected and COORD sends boroadcast sleep command.

Nodes reset in 1st step(very rarely) and 3rd step(often).

Are there in LW_Mesh parameters that have impact on sending broadcast messages?

Like I said, 1st R receives broadcast and retransmits message and 2nd just resets, there is no retransmission form it and vice versa.

With sniffer I see broadcast messages:
1. COORD broadcast
2. 1st R broadcast
3. 2nd R broadcast

After reset of 2nd R:
1. COORD broadcast
2. 2nd R broadcast
3. 1st R broadcast

So messages are not in order all the time(broadcast of 1st and 2nd R switch places).

Maybe it has something to do with routing list/table(I'm guessing here)?

Right now I'm "clearing my code" and I'll post related parts when I'm finished.

Thank you Alex !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xtal_88 wrote:
Sorry Alex, but I think I can't do it like you suggested, because some nodes will move around and might be out of network(not reachable) and COORD must know at any time how many nodes(addresses which must be called) are there in network.
If you still will be wasting your time if devices are not present, since the next one will only send after 50 ms.

And you need to know how many devices do you have, otherwise how do you know when to send unicast requests from the coordinator?

Anyway, if this system works for you, then there is no problems, just use it.

xtal_88 wrote:
I think that broadcast messages are problem and they cause these resets.

I don't think there is a problem in the stack, more likely in a way you handle the responses. IF you can, send the source code, I'll have a look.

xtal_88 wrote:
Are there in LW_Mesh parameters that have impact on sending broadcast messages?

There is a random delay is applied to a broadcast frame. It is set via NWK_TX_DELAY_JITTER_MASK in nwkTx.c. It is not really meant to be changed. Default value is 0x07 and it corresponds to 10-80 ms delay.

It is much better to let all your routers broadcast at the same time and rely on this random delay to spread them apart.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.