Commands are not working any more after merge?

[EDsteve]

@OOHehir @LIFsCode I know that both of you are busy the next days. So no stress about it. But should be fixed whenever someone has free time again.

Sending serial commands over BT doesn't seem to work any more. Before the merge i could start/stop recording (using setRecordMode) or get status reports with getStatus or getConfig command etc. There is no response any more and i guess the merge broke that somehow.

@OOHehir The commands are described here. These commands can be sent using a Bluetooth serial program. This works on Android and this one on Windows. Pair the device first and after that you are able to connect and send commands. Don't forget that the BT will turn off automatically after 60 seconds. This can be overcome using a config file in the root of the sd card or knock on the device to wake it up.

If i can do anything to help with that, Please let me know.

Cheeers

ED

[EDsteve]

If this issue is dealt with at "Implement wav file writing control from Bluetooth". Then of course my post can be deleted.

[OOHehir]

@EDsteve This is no doubt as a result of the changes I pushed. Should get a chance to look at it tomorrow evening (my time).

[EDsteve]

It would have been a miracle if everything worked right away after the merge. Haha Thanks for looking into it. Only if you have the time of course.

[LIFsCode]

Sorry I'm also quite busy this week, I can be of more help next week.

@OOHehir What I noticed when I saw the merge, is that there is no usage of FreeRTOS Queue, but rather polling the 'buf_ready' flag with a delay of 10 Ms (WavWriter) and 1ms (inference). Based on the priorities this could cause the Bluetooth task to starve during processing commands. Parsing the json may take some time. Also I don't remember the priority of the BT serial driver lib. This could be a potential issue as wenn due to timing requirements.

Just a theory, but maybe it helps.

@EDsteve Is the performance monitor active?do you have any CPU/task loads in the log?

[EDsteve]

@LIFsCode Yes. It comes up every few seconds in the serial log. Looks like this:

    | Task         | Run Time   | Percentage
    |        stats |       3676 |   0%
    |    BT Server |     163583 |   1%
    |         IDLE |    5078727 |  47%
    |         IDLE |    3133361 |  29%
    |         main |     461375 |   4%
    |      Tmr Svc |          0 |   0%
    |         ipc1 |      10512 |   0%
    |       spp_tx |          0 |   0%
    |         ipc0 |      17763 |   0%
    | btController |    1073255 |  10%
    |    esp_timer |       1202 |   0%
    | Wav file writer | Created
    |         hciT | Created
    |     BTU_TASK | Created
    |     BTC_TASK | Created
    |     I2S read | Created
    -----------------------------------

[OOHehir]

@LIFsCode I'm working on this at the moment, when I try starting recording I get the response:

E (294486) BluetoothServer: Invalid Command setGPS^UNKNOWN, Received setGPS^UNKNOWN

Not sure whats causing it, will dig in a bit more..

[LIFsCode]

Are you using the ELOC app?if yes this could be part of deprecated code. The "setGPS^" is deprecated and has been removed from the code. The app must not send it anymore Actually I don't know if there is a new version of the app available @EDsteve ?

Are we maybe mixing up multiple problems?

• Android App
• BT Command interface
• effects of the EI merge

Best just use a pure BT serial terminal.

[OOHehir]

@LIFsCode @EDsteve I'm using 4.67 AppBeta of the ELOC app, I don't see any other version of the app available.

@LIFsCode Just checking if there's changes in other branches that are required? Looking at main.cpp it seems the last commit you made on that file was 15th June. I see some significant in the changes in src/Commands of the master branch that have been incorporated.

[OOHehir]

@EDsteve @LIFsCode I've just checked via a BT serial terminal on an Android app & it looks promising:

13:42:42.802 ^D13:43:14.012 getstatus
13:43:14.809 {"ecode" : 0, "error" : "ESP_OK", "cmd" : "getstatus", "payload" : {

13:43:14.810   "battery": {

13:43:14.810     "type": "LiPo",

13:43:14.810     "state": "Full",

13:43:14.810     "SoC[%]": 91.6,

13:43:14.810     "voltage[V]": 4.12

13:43:14.810   },

13:43:14.810   "session": {

13:43:14.810     "identifier": "not_set1701347816120",

13:43:14.810     "recordingState": "disabled",

13:43:14.810     "recordingTime[h]": 0

13:43:14.810   },

13:43:14.810   "device": {

13:43:14.810     "firmware": "ELOC_V0.1",

13:43:14.810     "Uptime[h]": 0.174331143,

13:43:14.810     "totalRecordingTime[h]": 0,

13:43:14.810     "SdCardSize[GB]": 14.87,

13:43:14.810     "SdCardFreeSpace[GB]": 12.65,

13:43:14.810     "SdCardFreeSpace[%]": 85.07

13:43:14.810   }

13:43:14.810 }}

13:43:14.810 ^D13:44:03.593 record
13:44:04.139 {"ecode" : 258, "error" : "record", "cmd" : "record", "payload" : }

13:44:04.140 ^D13:44:18.459 setrecordmode
13:44:19.273 {"ecode" : 0, "error" : "ESP_OK", "cmd" : "setrecordmode", "payload" : {"recordingState" : }}

13:44:19.273 ^D13:44:32.528 setrecordmode
13:44:33.394 {"ecode" : 0, "error" : "ESP_OK", "cmd" : "setrecordmode", "payload" : {"recordingState" : }}

13:44:33.424 ^D13:44:52.430 setrecordmode
13:44:53.177 {"ecode" : 0, "error" : "ESP_OK", "cmd" : "setrecordmode", "payload" : {"recordingState" : }}

13:44:53.177 ^D13:44:56.705 setrecordmode
13:44:57.214 {"ecode" : 0, "error" : "ESP_OK", "cmd" : "setrecordmode", "payload" : {"recordingState" : }}

13:44:57.215 ^D

The recording of the wav files is started & stopped accordingly..

@LIFsCode The only thing in the code I'm unsure of is this line:

status += "{\"recordingState\" : ";
status += String(rec_req == REC_REQ_START);  <------------------------------------
status += "}";
ESP_LOGI(TAG, "%s Recording...", newMode);

Its commented out at the moment

[EDsteve]

@LIFsCode @EDsteve I'm using 4.67 AppBeta of the ELOC app, I don't see any other version of the app available.

The 4.67 still uses old commands only compatible with the ELOC 2.7 hardware. So that won't work. I should write that in the description actually.

The new app still needs the new commands to be implemented (within the next few days). That's why i am using BT serial tools for now to send commands for testing. As soon as the app is ready i will send you the link.

[EDsteve]

@EDsteve @LIFsCode I've just checked via a BT serial terminal on an Android app & it looks promising:

Ohhh. In windows serial terminal i have to change the line ending settings in order to see the response. So yes. It does work. Sorry for that. My bad.

[LIFsCode]

@EDsteve @OOHehir ok so if I understand it correctly there never has been a problem with the commands except for the start/stop of the recording, it was all about the command termination in the windows terminal.

The only thing in the code I'm unsure of is this line:

status += "{\"recordingState\" : "; status += String(rec_req == REC_REQ_START); <------------------------------------ status += "}"; ESP_LOGI(TAG, "%s Recording...", newMode); Its commented out at the moment

@OOHehir this should best be set to the same as in the getStatus response field. We have defined a format for enums in the json payload which is a tuple of the

• interger value (must not be changed without change of CMD Interface Version) this uniquely identifies the enum state
• string representation for better readability in Log Files

Sorry I have not added this to the command interface wiki yet. I think in your last commit the tuple for the enum state is only a string. Basically the response of setRecordMode should be the same as in getStatus the field--> {"session" : {"recordingState" : }}

[OOHehir]

@LIFsCode Thanks, I think I understand where your coming from. Unfortunately I had used a strongly typed enum for the wav writer mode so it doesn't lend itself to the template conversion. I added a method to the wav writer class to report mode in string & int form & used that in the JSON. I'm not sure what you think of that approach, if you'd rather revert no problem.

From what I can see the wav writer operation is set at boot up, from Bluetooth & GPIO0. I understand the current code uses the FreeRTOS queue. To access the enum modes of the wav writer I had to include the header (in BluetoothServer.hpp) for wav writer & the (globally scoped) object (to enable toggling the mode). At that point it seemed more efficient to set the mode directly rather than the queue but not sure if you want to proceed in that direction? If you wish to proceed in a solely based queue manner I can modifythe code. It is similar for the AI setting (discussed below).

@LIFsCode @EDsteve I've added code to report & set the AI operation. I've tested briefly & it looks to be working as expected. The mode can be changed, similar to the wav writing, as: setAIMode (toggles) setAIMode on setAIMode off

[OOHehir]

The issues are getting a bit mixed up so I´ll close this & split any remaining issues into more appropriate open issues