Replies: 17 comments 10 replies
-
|
Easy to implement would be a mechanism that shifts the wakeup time of a device to top-of-minute, once the device is preparing to sleep and has a valid time-of-day. It would then wake up after the sleep time is expired and the next top-of-minute arrived. This way all devices which use this sync mechanism would wakeup at top-of-minute, once they got a time-of-day from their time source (e.g. LORAWAN network, or GPS). After this happened, it should make all devices start scanning and sending their payload at the same moment, if they use the same scan cycle. Would this meet your requirements? |
Beta Was this translation helpful? Give feedback.
-
|
Would top of minute get all devices scanning at the same time?
I use a 600 second sleep time. Would it work in that case and get all the
units scanning at the same time?
…On Sat, 25 Feb 2023, 21:55 Verkehrsrot, ***@***.***> wrote:
Easy to implement would be a mechanism that shifts the wakeup time of a
device to top-of-minute, once the device is preparing to sleep and has a
valid time-of-day. It would then wake up after the sleep time is expired
and the next top-of-minute arrived. This way all devices which use this
sync mechanism would wakeup at top-of-minute, once they got a time-of-day
from the network. Aftert this happened, it should make all devices sending
their payload at the same moment, if they use the same scan cycle.
Would this meet your requirements?
—
Reply to this email directly, view it on GitHub
<#941 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO4ALE5K2UPA6J44SMDWZJ5UDANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
No, it won't, since it would be a time relative approach. It just syncs all devices to start scan at top of minute. So, you need an time absolute approach, e.g. all devices start scan at certain times? |
Beta Was this translation helpful? Give feedback.
-
|
A spcific time could work also. Would it be more difficult to do?
But if it was just top of the hour, that would work for all sensors running
a sleep cycle that is shorter than an hour.
…On Sun, 26 Feb 2023, 11:46 Verkehrsrot, ***@***.***> wrote:
No, it won't, since it would be a time relative approach. It just syncs
all devices to start scan at top of minute. So, you need an time absolute
approach, e.g. all devices start scan at certain times?
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCOYHYK7JO3Z6FRVYT6LWZM7AVANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Shifting wakeup times by an offset is easier to implement, than absolute wake up times. Let's start with a simple version which syncs all device to to of hour. It will shift wake up to top of hour with first sleep, and keep it there for all following sleeps by comparing with time-of-day while time is available. This feature will be "hardwired" by setting a flag in paxcounter.conf. A more elaborated version would use a dynamic wakeup time control field which can be altered by remote command and sets one ore more absolute time points like Sunday, 17:30, when a device wakes up next. For this we need to select a data compact format which specifies an absolute time point. Any suggestions? |
Beta Was this translation helpful? Give feedback.
-
|
The first option for a hardwired top of hour solution looks good and should
do what is needed to get all devices scanning in sync or very close.
The second one is interesting. It would be a very useful feature but for a
different reason. In many use cases we only care about foot fall during
week days and during certain hours. Being able to sleep until a specific
time would therefore extend battery life dramatically. Probably by a factor
of 2. So this would be a worthwhile investment in development just for
extending battery life.
…On Sun, 26 Feb 2023, 13:11 Verkehrsrot, ***@***.***> wrote:
Shifting wakeup times by an offset is easier to implement, than absolute
wake up times. Let's start with a simple version which syncs all device to
to of hour. It will shift wake up to top of hour with first sleep, and keep
it there for all following sleeps by comparing with time-of-day while time
is available. This feature will be "hardwired" by setting a flag in
paxcounter.conf.
A more elaborated version would use a dynamic wakeup time control field
which can be altered by remote command and sets one ore more absolute time
points like Sunday, 17:30, when a device wakes up next. For this we need to
select a data compact format which specifies an absolute time point. Any
suggestions?
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO63PCHPRKTH5CDC5S3WZNJAHANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
@Qmick01 I implemented your suggestion "use a reset window and sync to top of hour" in development branch. I added some documentation, too. Please give it a try! Thanks. See eaa8bdf |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I went to start a test. It looks like all changes for the "sync" function are in reset.h and reset.cpp - is this correct? I am currently running version 3.4.4. If I add these two updated files to my current build, would they function correctly or are they based on a later release and not function inside 3.4.4 ? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it's only reset.h and reset.cpp, plus adding this line in paxcounter.conf: You can try to add this manually to code base v3.4.4, it should work. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. Will do.
…On Wed, 8 Mar 2023, 15:01 Verkehrsrot, ***@***.***> wrote:
I implemented you suggestion in development branch, you can try.
I added some documentation, too.
Please give it a try! Thanks.
See eaa8bdf
<eaa8bdf>
—
Reply to this email directly, view it on GitHub
<#941 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO2AB6KVBU3ET5F7HADW3CNMFANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you.
…On Thu, 9 Mar 2023, 10:32 Verkehrsrot, ***@***.***> wrote:
Yes, it's only reset.h and reset.cpp, plus adding this line in
paxcounter.conf:
#define SYNCWAKEUP 300 // shifts sleep wakeup to top-of-hour, when +/- X
seconds off [0=off]
You can try to add this manually to code base v3.4.4, it should work.
But i would recommend an upgrade to current 3.4.7, e.g. to get the new
feature store syslog on SD card of device.
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO76AU7PB3RPZKKCQULW3GWUNANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
I have tried to use my 3.4.4 version and replaced the reset.h and reset.cpp
and added the new value in the paxcounter.conf file but I get a lot of
errors.
Is it possible there is some other dependency in the new reset.h which is
failing in the older release I am using.
Or have I just done something really stupid?
======================================================================================
Building in release mode
Compiling .pio\build\usb\lib647\FastLED\FastLED.cpp.o
Compiling .pio\build\usb\lib647\FastLED\bitswap.cpp.o
Compiling .pio\build\usb\lib647\FastLED\colorpalettes.cpp.o
Compiling .pio\build\usb\lib647\FastLED\colorutils.cpp.o
Compiling .pio\build\usb\lib647\FastLED\hsv2rgb.cpp.o
Compiling .pio\build\usb\lib647\FastLED\lib8tion.cpp.o
Compiling .pio\build\usb\lib647\FastLED\noise.cpp.o
Compiling .pio\build\usb\lib647\FastLED\platforms.cpp.o
Compiling
.pio\build\usb\lib647\FastLED\platforms\esp\32\clockless_rmt_esp32.cpp.o
Compiling .pio\build\usb\lib647\FastLED\power_mgt.cpp.o
Compiling .pio\build\usb\lib647\FastLED\wiring.cpp.o
Compiling .pio\build\usb\src\antenna.cpp.o
Compiling .pio\build\usb\src\bmesensor.cpp.o
Compiling .pio\build\usb\src\boot.cpp.o
Compiling .pio\build\usb\src\button.cpp.o
Compiling .pio\build\usb\src\configmanager.cpp.o
Compiling .pio\build\usb\src\cyclic.cpp.o
Compiling .pio\build\usb\src\dcf77.cpp.o
Compiling .pio\build\usb\src\display.cpp.o
Compiling .pio\build\usb\src\gpsread.cpp.o
In file included from include/reset.h:3,
from include/reset.h:3,
from include/reset.h:3,
from include/reset.h:3,
Compiling .pio\build\usb\src\hash.cpp.o
from include/reset.h:3,
from include/reset.h:3,
from include/reset.h:3,
from src/boot.cpp:1:
include/reset.h:2:21: error: #include nested too deeply
#include "globals.h"
^
include/reset.h:3:19: error: #include nested too deeply
#include "reset.h"
^
*** [.pio\build\usb\src\configmanager.cpp.o] Build interrupted.
*** [.pio\build\usb\src\cyclic.cpp.o] Build interrupted.
*** [.pio\build\usb\src\boot.cpp.o] Build interrupted.
*** [.pio\build\usb\src\hash.cpp.o] Build interrupted.
Error: Aborted by user
Michael Joseph
+44 (0) 7790928628
"In Velo, Veritas"
…On Thu, Mar 9, 2023 at 10:32 AM Verkehrsrot ***@***.***> wrote:
Yes, it's only reset.h and reset.cpp, plus adding this line in
paxcounter.conf:
#define SYNCWAKEUP 300 // shifts sleep wakeup to top-of-hour, when +/- X
seconds off [0=off]
You can try to add this manually to code base v3.4.4, it should work.
But i would recommend an upgrade to current 3.4.7, e.g. to get the new
feature store syslog on SD card of device.
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO76AU7PB3RPZKKCQULW3GWUNANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Dont't replace the files. Only add the changes. Otherwise you need to migrate to v3.4.7. |
Beta Was this translation helpful? Give feedback.
-
|
Dont't replace the files. Only add the changes to existing files. |
Beta Was this translation helpful? Give feedback.
-
|
Aha. Got it. That makes sense. Thank you.
Michael Joseph
+44 (0) 7790928628
"In Velo, Veritas"
…On Thu, Mar 9, 2023 at 11:36 AM Verkehrsrot ***@***.***> wrote:
Dont't replace the files. Only add the changes to existing files.
Otherwise you need to migrate to v3.4.7.
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCOYNKY4GP4PNBHMLHZTW3G6FBANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
The first set of boards running the sync code has produced an interesting result. See below image. These are the Liligo OLED LORA board version 1.6 running 3.4.4 code with the code updated in reset.h and reset.cpp modified to show the small changes for the sync function and an additional parameter in the paxcounter.conf file added to enable the function. They are all configured to sleep for "60" which is about 600 seconds and the sync window is set to 300 which I believe means that if the boards sees it is within 300 seconds of the top of the hour it will wait for the top of the hour before it proceeds. Question: what happens after that? If the board is now synced to the top of the hour, does it check each following cycle and resync - which would seem to be what would happen. In the image below you can see a vertical trace for each time the board scans and over a period of about 10 hours you can see that boards which started out at random intervals (left hand side) have slowly aligned so on the righ hand side we see tham all in sync - except for board 18. So the good news is that the code appears to work as it should with all boards except 1 and it syncs up inside about 8 hours. That one outlier board (18) seems odd, I will leave it a bit longer and then may re-flash that board and see if that fixes it. Should I try any other scenarios for this test?
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for testing. The result shows that it is worth starting to more elaborate the sync code, since the approach seems basically working. The "odd" board probably does not receive a valid time-of-day, while it is running. Without valid time the current sync code will show random results. Small deviations, as seen in the table, may result from different TX times, due to different Lora SF Spreadfactors. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, it looks like it is working as hoped. Great work on your part
doing it.
Can I suggest some next features would be to be able to set the parameter
remotely as well as see it reported when sending an 80 or 81 uplink.
Thanks for doing this.
Michael Joseph
+44 (0) 7790928628
"In Velo, Veritas"
…On Fri, Mar 10, 2023 at 10:00 AM Verkehrsrot ***@***.***> wrote:
Thanks for testing. The result shows that it is worth starting to more
elaborate the sync code, since the approach seems basically working.
The "odd" board probably does not receive a valid time-of-day, while it is
running. Without valid time the current sync code will show random results.
Small deviations, as seen in the table, may result from different TX
times, due to different Lora SF Spreadfactors.
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO3LUIIJH5CJBGJZQ2LW3L3TZANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Remote command to set remotely is no problem. Adding parameter to rcommand x80/x81 would be a breaking change to the rcommand API, thus i won't add this. But we can introduce a new rcommand for this, that wouldn't break the API. |
Beta Was this translation helpful? Give feedback.
-
300 means: if the next wake up cycle would happen 5 minutes before or after top-of-hour, this wake up will be adjusted to top-of-hour (means delayed or shifted).
Yes. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks.
So: If the board checks every cycle, it will keep adjusting itself whenever
it drifts off the top of the hour, so in effect staying at the top of the
hour.
It sounds like the optimal window is half of the sleep time? Does that
sound right?
Michael Joseph
+44 (0) 7790928628
"In Velo, Veritas"
…On Fri, Mar 10, 2023 at 11:14 AM Verkehrsrot ***@***.***> wrote:
300 which I believe means that if the boards sees it is within 300 seconds
of the top of the hour it will wait for the top of the hour before it
proceeds.
300 means: if the next wake up cycle would happen 5 minutes before or
after top-of-hour, this wake up will be adjusted to top-of-hour (means
delayed or shifted).
Question: what happens after that? If the board is now synced to the top
of the hour, does it check each following cycle and resync
Yes.
—
Reply to this email directly, view it on GitHub
<#941 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO2VX6I2Z4JKEM6FGRDW3MEKPANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
I need to think more about that. Currently my thoughts are:
Not sure, what is the optimal solution. May depend on use case. Generally: We don't want a device to wait while staying idle, because this means waste of power. Thus, we go to sleep immediately after scan, and adjust the next wake up time in advance. Rcommands/API: I will start to enhance this in development branch, but i will not merge this to master yet. A good milestone for a merge would be, after a "calendar mode" for advanced and remote programming of wake up time schemes is implemented. I think this would be a feature that is worth a breaking change to the rcommand API. To build this, we first need a compact scheme to define wakeup times, maybe a bitmap format. |
Beta Was this translation helpful? Give feedback.
-
|
@Qmick01 could you gain some experience with the top-of-hour sync feature? If it works satisfactory, i'm thinking of adding a calendar function, which allows to define "run" and "sleep" hours for each day of a week. This way sleep time of device can be stretched if scanning is not needed during certain hours or certain weekdays. The calendar will be remotely adjustable by rcommand, using small 4 bytes of upload. This should work even with devices which are on SF12. |
Beta Was this translation helpful? Give feedback.
-
|
That would be a very slick feature and would go a long way to extending
battery life.
How can I help?
…On Sun, 16 Apr 2023, 14:53 Verkehrsrot, ***@***.***> wrote:
@Qmick01 <https://github.com/Qmick01> could you gain some experience with
the top-of-hour sync feature?
If it works satisfactory, i'm thinking of adding a calendar function,
which allows to define "run" and "sleep" hours for each day of a week. This
way sleep time of device can be stretched if scanning is not needed during
certain hours or certain weekdays. The calendar will be remotely adjustable
by rcommand, using small 4 bytes of upload. This should work even with
devices which are on SF12.
—
Reply to this email directly, view it on GitHub
<#941 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO2SFVTL5NPJ62VXGRTXBP2UBANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
It would be important for this enhancement to know, if the top-of-hour sync feature is working stable, because code will be based on this. |
Beta Was this translation helpful? Give feedback.
-
|
I have deployed 10 units in the field using it and they seem to fine but
they are not yet commissioned as I have not managed to get a dedicated
gateway for them commissioned yet. So I have only seen them periodically.
And I presume they would only be fully functional on the sync function when
they can get time via the gateway.
But at present I don't believe the sync code has introduced any bugs.
…On Sun, 16 Apr 2023, 18:55 Verkehrsrot, ***@***.***> wrote:
It would be important for this enhancement to know, if the top-of-hour
sync feature is working stable, because code will be based on this.
—
Reply to this email directly, view it on GitHub
<#941 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOZZCO5BLW5VN6VYOT5HIIDXBQXBLANCNFSM6AAAAAAVGDPSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Following up on this and I can report that the sync code has been running several months on about 20 boards and has not produced any problems that I can detect. A format for setting a schedule would be handy to add. Currently I am looking into remotely managing the sleep cycle every 24 hours to achieve the same thing. I note that the sleep cycle time isn't yet in the Config report - was this something that would break the format? I am just testing version 3.6.1 currently. |
Beta Was this translation helpful? Give feedback.
-
Hello All.
I am managing an estate of the Paxcounter units in an environment where it would be incredibly useful to be able to synchronize all the units to scan at the same time - or within a couple of seconds - of each other.
To do this could be quite simple: I was thinking that as the time of day is available to the unit from the TTN network, it might be possible to set a flag so that if SYNC=TRUE then each device would, upon wake up, do a quick check for the closest hour (as 1:00 pm or 2:00 pm etc) and if it was within perhaps 1 minutes of an hour (call this the reset window) , it would pause for the period between the current time and the hour, and then it would continue the scan cycle and go back to sleep. This would cause the estate of all units to synchronize scanning with a day or two.
So if the device wakes up at 1:59:50 it would see it was 10 seconds from the hour and if the reset window was set to 60 seconds, it would wait the 10 seconds (as this is less than the reset window) and then proceed with the scan.
If the reset window was remotely configurable along with the SYNC flag, then remote admin could be used to get all the units synchronized.
The value of this is it provides a snap shot of the whole context, not just a series of random small snapshots which lack overall contextual consistency.
Would this be a piece of work of value to other users of the Paxcounter?
Mike
Beta Was this translation helpful? Give feedback.
All reactions