I've just noticed that the maximum number of time periods allowed in the latest Configuration App has been reduced from 5 to 4 - defined as MAX_PERIODS = 4 in timePeriods.js. However in the latest version of the firmware (main.c) we have "#define MAX_START_STOP_PERIODS 5" .
It's a small point but I'm trying to complete a Visual Basic config app that will be compatible with my XP field netbooks (I don't possess a laptop with a more recent version of Windows) and it would be helpful to know whether there is a reason to limit the number of periods to 4.
Incidentally - it would be very helpful if you would add version numbers into the source code files - or at least remember to update the dates in the code when you make updates. At the moment it is quite confusing to have several versions of all the source files all with the same dates.
Hi; I am trying to add another config parameter to the configSettings_t struct, right after the "uint8_t disableBatteryLevelDisplay" field in main.c.
However, what worries me is that the AudioMoth Configuration App (Electron) v1.2.2. sends exactly four time periods and there is room for five time periods in the configSettings_t struct. Therefore I am afraid that the fields in the configSettings_t struct and the configuration data received over the USB will be misaligned in the AudioMoth RAM.
I have read the posts above and I am aware that four time periods can sometimes become five, however, I looked at the "app.js" file and could not find the JavaScript code that does that in the configureDevice() function. Is the fifth time period added somewhere else?
As I see things, the following fields will be misaligned by four bytes when sent from the Configuration App to the firmware 1.2.1 (app.js):
packet[index++] = ui.isLocalTime() ? ui.calculateTimezoneOffsetHours() : 0; packet[index++] = batteryCheckbox.checked ? 1 : 0; packet[index++] = batteryLevelCheckbox.checked ? 0 : 1; /* For non-integer timezones */ packet[index++] = ui.isLocalTime() ? (ui.calculateTimezoneOffsetMins() % 60) : 0;
Would you please let me know if the above really is an issue, or am I mistaken? Maybe the firmware realigns the data correctly after the usb package is received? If so, where?
Also, please suggest how I should add another configuration parameter (field) into the configSettings_t struct?
Thank you!
Thanks again Alex. That is helpful.
If I can make a suggestion - I think that it may be useful to save the UTC/Local status in the config file as it is easy to overlook when re-configuring the device (particularly since everything else is restored). Perhaps also to load a default config file automatically on opening the application.
The start and stop periods are in UTC (so that the firmware is compatible with older versions of the configuration app) and must be in ascending order. The timezone value at the end of the configuration packet is then used to format the date and time formats in the filename and the file header. The timezone should be +1 for UTC+1 (BST).
Thanks for the explanation Alex.
However your reply has made me realise that there is one other point I'm not clear about.
Should the time periods be sent to the device as either Local Timezone or UTC as selected in the Configuration App or always as UTC with the time format defined by the supplied Local Timezone Offset?
I can imagine that it could be implemented either way, but I'm having a bit of trouble wading through the jscript code to find the answer.
Yes, we reduced the limit in the configuration app since four time periods entered in local time can become five time periods when converted to UTC if they cross midnight. The firmware is still expecting five start-stop periods to be sent. Alex