ADC Common Message Set

[JLJu]

Referring to the ADC Common Message Set implementation. Message No.19 LGA LOG_FILE_ASSERT This message is supposed to retrieve a specific line of the log file. I'm lost about the possible criterion to index the file. The use of lines no by themselves does not seem too user-friendly. I mean, it seemed good to me in the past. Now that I have a working implementation it feels useless to me :-). Any use case is welcome :-)

[GrazianoCapelli]

This was thought in order to avoid the ugly buffer flooding that occurs when a whole file is sent. But this behavior maybe introduces a potential indexing issue (a index is not necessary if the file is opened and sent sequentially, but we have to find a way to restart from the begin of the file), and mainly slows down noticeably the download process.

Maybe we have to find a better way to perform the operation.

[JLJu]

To be added: Command to get the log file size in bytes Command : $LFS Reply: $LFA,12534548 (file size in bytes)

[GrazianoCapelli]

It is possible to also add a timestamp to message? Maybe the file creation datetime, or the first (or last) sample datetime.

Something like $LFA,timestamp,size. For example $LFA,1494365158,12534548

With the timestamp (and the file size) we could know for sure the following things:

• if a log is already been downloaded by the user.
• if the user added samples to a previous (downloaded) log.

[JLJu]

It sounds good. File management system? We will need to restructure the ADCCMS.

To be added Command to get the required log file size in bytes msg # 22 Request: $LFS, filename msg # 23 Reply: $LFA,1494365158,12534548

To be added Command to get the list of files on SD card. msg # 20 Request: $LLQ msg # 21 Reply: $LLA,n, filename1, filename2,filename3,filename_n

To be modified to include multiple files

msg # 17 LGD LOG_FILE_DELETE Delete specified log file msg # 18 LGQ LOG_FILE_REQ Ask for specified log file

Filename = Timestamp.csv

Work in progress for new ADCCMS + Lib release.

[GrazianoCapelli]

In case we opt to implement a sort of file manager, it's also possible, as alternative, to include all commands in one msg header. This way we have a single $LFA for answers and a single $LFQ for questions.

For example: $LFQ,L Query files (L = List) $LFA,L,File1,File2,File3 Answers with the file list

As alternative, we could define the first parameter: FILE_LIST = 1 NEW_FILE = 2 DEL_FILE = 3 FILE_PROPERTIES = 4 and so on

and use them: $LFQ,1 Query files $LFA,1,File1,File2,File3 Answers with the file list

This way we can start implementing a single command when needed and expand the possibilities in next releases without add / change message set.

[JLJu]

We need some change, that is unavoidable. In your scenario, current messages # 17, # 18 will need to be eliminated. I guess we can replace the old command with the new ones. As a parameter for LFQ we need to include also:

LOG_FILE_REQ = 5 to get a specified log file for example $LFQ,5,filename File list can be then fetched with $LFQ,1,, That request msg maintains the same structure at the ADC end and allow for file selection. For example $LFQ,1,day can be used to list the files of one specified day.

Given that a parameter will lovely. ADC code complexity should be kept low as possible, we should avoid complex file handling operations on ADC.

Msgs will be incorporated as soon as ADCCMS is updated.

[GrazianoCapelli]

In effect we can use messages # 17 and # 18 to perform all operations, it seems a good idea. For now we could start implementing the following commands:

FILE_DUMP = 1 to get a specified log file FILE_PROPERTIES = 2 to get the properties of the log file FILE_DELETE = 3 to delete a specified log file

Thus, we'll have the following commands available:

File dump: $LFQ,1,filename $LFA,1,Line1 first line $LFA,1,Line2 second line $LFA,1,Line3 third line . . . and so on

File properties: $LFQ,2,filename $LFA,2,1494365158,12534548 the datetime and the size of the specified file

Delete File: $LFQ,3,filename $LFA,3,filename the file deleted

This way we could start implementing a single file, with a predefined name, in order to test the system.

[JLJu]

Negative. No file dump per line (That is fine for the next release) List command missing. No functionalities added respect current implementation. Better to stay still instead :-) If we have only one logfile all that functions are not useful nor essentials. Test can go ahead with no modifications at all.

[GrazianoCapelli]

I agree, no file dump per line, I intended one message per line, but flooding all $LFA,1,LineN.

[JLJu]

Tu oder tu nicht. Es gibt kein versuchen! Yep, we can use some sort of line breaking. To avoid an eventual flooding it is better to use a soft form of software synchronization. Explicit line ACK should be raw but effective. We will refine the question when we've tested all the other stuff.

[JLJu]

ADC Common Message Set updated. Library and firmware sketch update will follow.

[JLJu]

Common Message Set + Library + Sketch updated and working

[JLJu]

Implemented msg 11, 12, 13

[JLJu]

Release 0.3 of library is now available. That can be a start point for fine tuning and architetture considerations.