请教ESP32-C3在单火场景下的使用

[meibao]

在准备制作生产单火线智能开关，一开始准备使用传统的蓝牙控制，但是某一天看到了乐鑫官方微信公众号一篇推文【乐鑫科技推出基于 ESP32-C3 的 Wi-Fi 单火线智能开关方案】，文章中介绍了ESP32-C3芯片在单火场景下可用，于是采购了一小批ESP32-C3FH4芯片，但是实际测试当中，ESP32-C3芯片在启动WIFI时的电流超过了100mA，随后电流稳定在20mA左右，但是这个功耗对于单火场景下所需要的低功耗依然不够，在实际单火产品中一旦芯片开启WIFI进行MQTT通讯后，开关会变得极度不稳定，尤其当后端通过MQTT发起打开开关的指令后芯片IO电平拉高驱动可控硅导通，此时大约3秒左右芯片会直接重启。
看了官网微信公众号说此芯片可以运用在单火低功耗场景下，但是实际测试下来并不可以，所以官方是指ESP32-C3芯片可以运用在单火场景下是说附带的低功耗蓝牙并不包括WIFI吗？还是说需要其他额外的操作呢？请指教！！

[ESP_ICY]

在单火场景下使用时，采用的是长时间WiFi保活的power_save 模式，也就是定期收包其余时间处于light-sleep睡眠，通过调整发射功率和收包间隔来实现低功耗，如果射频一直处于打开状态功耗是降不下来的。

[meibao]

在单火场景下使用时，采用的是长时间WiFi保活的power_save 模式，也就是定期收包其余时间处于light-sleep睡眠，通过调整发射功率和收包间隔来实现低功耗，如果射频一直处于打开状态功耗是降不下来的。

你好，感谢回复，但是我想了想这样肯定不行呀，单火场景下的比如智能开关，时延性比较敏感，用户在发送开启或者关闭的指令时设备应该立即做出反应，如果系统进行睡眠关闭射频采用定时收包的形式的话，那延时也太大了，用户体验会很差的。只有对时延性不敏感的场景比如水表电表之类一个月上报一次数据的才适合，这个我觉得不合适吧，智能开关肯定要实时接收数据的，这个方案我觉得有问题

[meibao]

在单火场景下使用时，采用的是长时间WiFi保活的power_save 模式，也就是定期收包其余时间处于light-sleep睡眠，通过调整发射功率和收包间隔来实现低功耗，如果射频一直处于打开状态功耗是降不下来的。

请问是通过死循环打开light-sleep和关闭light-sleep这样来实现吗？因为我通过ESP-IDF中power_save示例编译固件后发现设备依然无法正常工作，还是会因为电流不足而频繁重启。目前单火电路最大提供不能超过持续3秒的100mA电流，安全电流在20mA以内，电压3.3V。到目前还是一头雾水，依旧是因为功耗问题导致设备各种异常

[ESP_ICY]

在单火场景下使用时，采用的是长时间WiFi保活的power_save 模式，也就是定期收包其余时间处于light-sleep睡眠，通过调整发射功率和收包间隔来实现低功耗，如果射频一直处于打开状态功耗是降不下来的。

你好，感谢回复，但是我想了想这样肯定不行呀，单火场景下的比如智能开关，时延性比较敏感，用户在发送开启或者关闭的指令时设备应该立即做出反应，如果系统进行睡眠关闭射频采用定时收包的形式的话，那延时也太大了，用户体验会很差的。只有对时延性不敏感的场景比如水表电表之类一个月上报一次数据的才适合，这个我觉得不合适吧，智能开关肯定要实时接收数据的，这个方案我觉得有问题

这个使用WiFi进行设备控制本身就受到WiFi信号强度的影响。时延的多少是你根据功耗的可接受程度来设置的，在WiFi信号稳定的情况下，目前调整到 1S左右的时延在不怎么会影响用户体验的情况下并保持较低的功耗

[ESP_ICY]

在单火场景下使用时，采用的是长时间WiFi保活的power_save 模式，也就是定期收包其余时间处于light-sleep睡眠，通过调整发射功率和收包间隔来实现低功耗，如果射频一直处于打开状态功耗是降不下来的。

请问是通过死循环打开light-sleep和关闭light-sleep这样来实现吗？因为我通过ESP-IDF中power_save示例编译固件后发现设备依然无法正常工作，还是会因为电流不足而频繁重启。目前单火电路最大提供不能超过持续3秒的100mA电流，安全电流在20mA以内，电压3.3V。到目前还是一头雾水，依旧是因为功耗问题导致设备各种异常

并不是通过死循环，powersave模式就是自动根据WiFi的发包频率来控制唤醒，如果手动的进行开启和关闭你是很难做到功耗的调控。可以试下在power_save 基础上添加一些简单的应用看下WiFi保活状态下的功耗。但是单火线方案不是说简单的使用一个芯片或者一个例程就能完成的，如果你想做一个更完整的成品，你还需要对你使用的云进行部分优化，然后也需要电源模块的配合，是一个整体优化的结果。

[meibao]

在单火场景下使用时，采用的是长时间WiFi保活的power_save 模式，也就是定期收包其余时间处于light-sleep睡眠，通过调整发射功率和收包间隔来实现低功耗，如果射频一直处于打开状态功耗是降不下来的。

你好，感谢回复，但是我想了想这样肯定不行呀，单火场景下的比如智能开关，时延性比较敏感，用户在发送开启或者关闭的指令时设备应该立即做出反应，如果系统进行睡眠关闭射频采用定时收包的形式的话，那延时也太大了，用户体验会很差的。只有对时延性不敏感的场景比如水表电表之类一个月上报一次数据的才适合，这个我觉得不合适吧，智能开关肯定要实时接收数据的，这个方案我觉得有问题

这个使用WiFi进行设备控制本身就受到WiFi信号强度的影响。时延的多少是你根据功耗的可接受程度来设置的，在WiFi信号稳定的情况下，目前调整到 1S左右的时延在不怎么会影响用户体验的情况下并保持较低的功耗

您好，很抱歉长时间没有看帖，关于调整时延我前两天试了，但是显然我的方法是不对，我是通过停止WIFI然后再重新初始化这种方式，但是结果一直出错，所以我觉得我这个方式是不对的。在观看power_save这个例程我发现了listen_interval参数，阅读文档后得知此参数为信标间隔参数，我尝试调大这个参数，但是实际结果会导致“wifi:bcn_timout,ap_probe_send_start”延迟确实有了但是也导致了原来建立的MQTT连接接收数据出现问题，好像路又走错了 ，还请指教

[898791901@qq.com]

省电模式都是坑来的，我觉得还不如直接在电源哪里并联一个法拉电容处理这种问题更好。你可以试一下。

[CryptoGL]

你好，感谢回复，但是我想了想这样肯定不行呀，单火场景下的比如智能开关，时延性比较敏感，用户在发送开启或者关闭的指令时设备应该立即做出反应，如果系统进行睡眠关闭射频采用定时收包的形式的话，那延时也太大了，用户体验会很差的。只有对时延性不敏感的场景比如水表电表之类一个月上报一次数据的才适合，这个我觉得不合适吧，智能开关肯定要实时接收数据的，这个方案我觉得有问题

这个使用WiFi进行设备控制本身就受到WiFi信号强度的影响。时延的多少是你根据功耗的可接受程度来设置的，在WiFi信号稳定的情况下，目前调整到 1S左右的时延在不怎么会影响用户体验的情况下并保持较低的功耗

您好，很抱歉长时间没有看帖，关于调整时延我前两天试了，但是显然我的方法是不对，我是通过停止WIFI然后再重新初始化这种方式，但是结果一直出错，所以我觉得我这个方式是不对的。在观看power_save这个例程我发现了listen_interval参数，阅读文档后得知此参数为信标间隔参数，我尝试调大这个参数，但是实际结果会导致“wifi:bcn_timout,ap_probe_send_start”延迟确实有了但是也导致了原来建立的MQTT连接接收数据出现问题，好像路又走错了 ，还请指教

请问你这个单火线的方案最终成功了吗，用了什么方法？