Maximum Number of Time Periods

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.

7 comments

7 Comments

Share Your ThoughtsSign up to leave a comment.

Djordje Herceg

Jul 02, 2019

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!

Alex Rogers

Jul 03, 2019

Replying to

The configuration app will always write five start startStopPeriod_t data structures into the packet so that the data packet sent exactly matches the bytes in the configSettings_t data structure.

The code below (app.js lines 243 - 263) fills in the used time periods, and then write blank ones at the end to fill up the space.

packet[index++] = timezoneTimePeriods.length; for (i = 0; i < timezoneTimePeriods.length; i += 1) { writeLittleEndianBytes(packet, index, 2, timezoneTimePeriods[i].startMins); index += 2; writeLittleEndianBytes(packet, index, 2, timezoneTimePeriods[i].endMins); index += 2; } for (i = 0; i < (timeHandler.MAX_PERIODS + 1) - timezoneTimePeriods.length; i += 1) { writeLittleEndianBytes(packet, index, 2, 0); index += 2; writeLittleEndianBytes(packet, index, 2, 0); index += 2; }

Adding the fractional timezone at the end makes sense. To ensure backwards compatibility between firmware and configuration app we have always added additional parameters to the end of the packet and ensured that the default behaviour occurs if a zero is sent. This means that your new firmware will work with the existing configuration app and always receive a zero time zone minutes value.

If you then edit the existing timezone handler prototype in AudioMoth.h from:

extern void AudioMoth_timezoneRequested(int8_t *timezone);

extern void AudioMoth_timezoneRequested(int8_t *timezone, int8_t *timezoneMinutes);

You should then be able to go through the code and add the additional functionality to handle the fractional part wherever it is used - this includes calculating the timestamps for the files, calculating the file name, and writing the file header.

Djordje Herceg

Jul 03, 2019

Replying to

Thank you very much for your explanation! I missed this part: " (timeHandler.MAX_PERIODS + 1) " the first time I went through the code.

davidlee_malvern

May 06, 2019

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.

Alex Rogers

May 06, 2019

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).

davidlee_malvern

May 06, 2019