SLN-ALEXA-IOT responds to the 3rd wakeup word

[vitaliyavramenk]

Hello,

on my end the SLN-ALEXA-IOT   board always starts listening as soon as  it detects  the "ALEXA" wakeup word. It works very stable and reliable. I can always see the BLUE light as soon as I say "ALEXA"

However, the board does not do any action. In other words, it does not accept any voice command. The same happens on the 2nd "ALEXA" wakeup word. Only after the 3rd try the board responds. Then, it works very reliable. It listens to all next commands.

However, if I don't ask Axexa anything for few minutes the problem appears again. The board executes all commands only after the 3rd ALEXA word.

The WiFi connection is very stable to the board. I could obtain info about the board IP from DHCP log of a router. The ping is only few ms on the local WiFi network. The internet connection is  stable as well.

Did anybody face the same problem ?

Thanks in advance

[Sabina_Bruce]

Hello ,

Hope you are doing well.

Could you please describe your environment. How did you come to this behavior? Has it always happened or did you make any changes that I could replicate from my end. 

If you reset the device and re-do the provisioning do you experience the same behavior?

Best Regards,

Sabina

[vitaliyavramenk]

Hello Sabina,

thanks for your response. I am doing well. Hope you too.

>Could you please describe your environment.

I read the complete 32MB image using a JTAG adapter  from the board ( as soon as I had the NXP hardware in my hands) and saved to a PC hard drive. This way I can always return to the initial NXP state. I could also generate my custom binary image, pass through the registration process, connect to my developer account, get the shared secret, etc. and save that image as well. Both firmware versions have the same 3rd word problem.

Anyway let's stick to the original NXP state in the discussion.

I have few additional ALEXA devices on my table (echo show 10, echo dot, echo flex).

I switched the echo show 10 device from 5GHz to the same 2.4GHz WiFi network where the NXP-ALEXA-IOT is connected. There is no problem with the echo show 10.

Also, I tried to connect the NXP-ALEXA-IOT to my phone that acts as the hotspot.

It is interesting. The NXP-ALEXA-IOT   works very good with that type of  connection.

The 3rd wakeup issue disappears. However, as soon as I switch back to my regular WiFi network the problem appears again.

Thus, any single component (NXP-ALEXA-IOT, regular WiFi network) worked well separately.

However, 2 components do not work reliably together.

I added the WiFi mesh network based on Eero in front of my cable modem/router combo (Motorola  MG7550) and switched both devices to that WiFi connection.

There is the exactly same behavior. The 3rd wakeup issue exists for NXP-ALEXA-IOT only.

Echo show 10, echo dot and  echo flex devices worked without any problem on the WiFi mesh network.

I adjusted the DHCP settings on my router from the default provider DNS IP  to 8.8.8.8. It does not help.

Please let me know what I can try else.

Thanks

Vitaliy

[vitaliyavramenk]

I could obtain additional information from the board log. Every 30 seconds the board synchronizes the clock

Publishing SynchronizeClock
11093 24614520 [AIS_Publish_Task] Sending command to MQTT task.
11094 24614520 [MQTT] Received message 4220000 from queue.
11095 24614520 [MQTT] Initiating MQTT publish.
11096 24614520 [MQTT] Notifying task.
11097 24614520 [AIS_Publish_Task] Command sent to MQTT task passed.
11098 24614520 [AIS_Publish_Task] Successfully published on topic event, seq: 12
11099 24614730 [MQTT] Received fixed header, 220 bytes to receive.
11100 24614730 [MQTT] [AIS] directive received, sequence: 19
11101 24614730 [MQTT] [AIS] SetClock received
11102 24614730 [MQTT] [AIS App] SetClock: Thu Sep 17 23:40:10 2020

So, the MQTT connection is valid.   Then, in 1 second I ask Alexa to do something.

And the board can't publish

11103 24616810 [Audio_proc_task] Wake word detected locally
11104 24616810 [APP_Task] [AIS DevbmlZjrD+KDM13] Publishing MicrophoneOpened
11105 24616810 [APP_Task] Setting audio processing state to 2
11106 24616810 [AIS_Publish_Task] Sending command to MQTT task.
11107 24616810 [MQTT] Received message 4230000 from queue.
11108 24616811 [MQTT] Initiating MQTT publish.
11109 24616811 [MQTT] Notifying task.
11110 24616811 [AIS_Publish_Task] Command sent to MQTT task passed.
11111 24616811 [AIS_Publish_Task] Successfully published on topic event, seq: 13
11112 24616822 [Audio_proc_task] [audio processing] Mic Recording Start.
11113 24616870 [AIS_Task] [AIS] Publish microphone size: 4800, offset: 279360, seq: 59
11114 24616871 [AIS_Task] Sending command to MQTT task.
11115 24616871 [MQTT] Received message 4240000 from queue.
11116 24616871 [MQTT] Initiating MQTT publish.
11117 24616882 [MQTT] Notifying task.
11118 24616889 [AIS_Task] Command sent to MQTT task passed.
11119 24616922 [AIS_Task] [AIS] Publish microphone size: 4800, offset: 284160, seq: 60
11120 24616930 [AIS_Task] Sending command to MQTT task.
11121 24616930 [MQTT] Received message 4250000 from queue.
11122 24616930 [MQTT] Initiating MQTT publish.
11123 24622400 [MQTT] MQTT_Publish failed!

I can duplicate the same scenario many times back to back

In the sources   the  keep-alive interval is defined as  1200 seconds ( by default).

However, for some unknown reason the MQTT connection is lost. So, the board starts to re-establish the connection. And as the result it skips the 1st wake word.

What can cause the problem ?

[Sabina_Bruce]

Hope you are doing well. I have been trying to reproduce this error but have not been able to. I tried my home network and my cellphone hotspot and all is well. The one that does not work is in the office, because they have blocked certain ports and it is not possible to connect it through there. However this is completely not connecting, I am not able to replicate the behavior you are having with every 3rd invocation it works.

Is it possible that you wifi network has any additional security measures that do not allow you to have a consistent connection with the SLN-ALEXA-IOT kit? Are you able to try a different network at a different location?

Also could you please test pressing the push to talk button and provide a command to see if it proceeds in executing the command each time. For the push-to-talk option you do not need to say "Alexa". Press the button and the blue light should go on wait for a command.

Could you please share your logs from when you initially connect the SLN-ALEXA.

Best Regards,

Sabina

[vitaliyavramenk]

Hi Sabina,

>Is it possible that you wifi network has any additional security measures that do not allow you to have a consistent connection with the SLN-ALEXA-IOT kit? 

theoretically, it may be possible. But for now I don't see anything that can effect.

What are typical problems ?

>Are you able to try a different network at a different location?

yes, I tried  the different WiFi network. The same problem.

>Could you please share your logs from when you initially connect the SLN-ALEXA.

I have  attached the logs.zip with 2 text files inside:

- startLog.txt  provides all info about the power on sequence;

- problemLog.txt shows the the 3rd wakeup word issue 

Thanks

[vitaliyavramenk]

I have  re-attached the logs.zip

[vitaliyavramenk]

I could localize the issue.

The MQTT connection is still alive. I can send PING to the MQTT server every 15 sec. And it always responds. So far so good.

As soon as the wakeword is  detected the LWIP TX buffer is empty. The tcp_sndbuf returns  8670 bytes.

Then, the board starts sending  the microphone data stream.  Per each new  data portion the tcp_sndbuf returns the smaller number. It means the board can't send data at all

even if  a couple of seconds ago the PING response has been received.

Finally the LWIP TX buffer is full.  So, the system re-establishes the MQTT connection.

I added a simple fix to send  a JSON message  through the MQTT connection as soon as the wakeword is detected to "$aws/things/NAME/shadow/update" topic.

And it solved the problem.  The  board always responds in time. 

It looks like the problem is AWS IOT server.  However, I don't have the reasonable explanations.