Battery drain when off is excessive.
Full charge at 3pm yesterday - unused for 22 hours. Switched on and battery flat.
Thanks for reporting this issue I will analyse this mid of next week and let you know my findings
Look forward to fix/workaround. Thanks.
1 Like
Confirmed here too. Fully charged overnight, and left with the power switch in the off position. 24 hours later the battery is flat.
I have just the “dead” issue that was reported on LMS forum.
This morning, speaker left plugged in overnight, no green LED when switched on.
I did notice the blue internal LED (behind usb socket) which is normally constant was flashing.
What does blue led flashing mean.
I have reflashed speaker and LED on top is green again and am now setting it up again.
There is data coming USB serial port.
Rather than trial & error, any idea what are the line speed, stop bits settings etc.
This works " stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb"
Now get this info from speaker
====> 2467 ff0000
====> 2472 ff0000
====> 2472 ff0000
====> 2472 ff0000
[00:13:29.406202] discover_server:828 sending discovery
Next time speaker is “dead” is may be useful to check serial port before reflashing in case it is a failure of Squeezelite startup
edit:
Not just serial output, there is a monitor with commands, so if “dead” happens again, it should be used to determine the state.
According to the small leaflet that was included in the package:
Blinking blue: charging
Blue steady: discharging
My interpretation of “Blue steady” is: fully charged, because after unpacking and connecting a 5V power supply to the USB port, the blue LED was blinking for a few hours, and after that is was constant on. If you leave the power supply plugged in overnight I would expect the blue LED to be constant on.
The blue led is not software controlled, it is directly controlled by the charging chipset and behave as CJS described.
I will be back in the lab this Thursday and work on the battery leaking issue to find the root cause. And there is probably a workaround I would like to test.
Olivier
FYI, philippe_44 has now added support for the Muse Luxe to the squeezelite-esp32 firmware. The firmware can be downloaded from here: Release 1.995-16#v4.0#Muse#master-cmake. This post on the squeezebox forum shows how you can flash the firmware using the ESP32 download tool. If there is a next firmware update, the firmware can be updated OTA (over the air).
EDIT: A new firmware update v996 is available now. Check Releases · sle118/squeezelite-esp32 (github.com) to see the latest firmware releases. Use the 16-bit Muse version for maximum functionality.
1 Like
FYI, I have noticed that my Muse Luxe starts to produce an audible “pulsing hiss noise” when the battery voltage is discharged below approximately 3.8V. The noise seems to correlate with microprocessor and/or RF activity in the ESP32 WROVER module.
I have not opened my Muse Luxe, but I have a theory that the 3.3V supply of the WROVER module and the 3.3V analog supply of the audio codec (ES8388?) are supplied from the same voltage regulator, and that this voltage regulator does not regulate properly anymore when the difference between input voltage (battery voltage) and output voltage drops below circa 0.6V.
For more details see this post on the squeezebox forum. Are there other people that have heard this pulsing noise? And maybe Olivier of Raspiaudio can comment on my theory?
I want to emphasize that this noise pulses do NOT occur when the Muse Luxe is supplied from a 5V power supply, and also not when the battery is full. Only when the battery voltage drops below a certain threshold voltage the noise pulses become audible, at least with my Muse Luxe.
Hi CJS
Indeed when the Luxe is very low on battery (close to the ESP32 not be able to boot) you might hear some hiss noise. In “normal” commercial bluetooth speakers the device turns off before you can hear this kind of audible instabilities, it could be also done in our software to avoid this in the future. I’m not sure how you measured your 3.8v as this threshold should be more around 3v.
Regarding your question, the power supply is not working exactly as you described, as the codec have a separate supply than the ESP32, and another one for the serial IC, and there is also a voltage booster for the audio amplifiers and all power supplies.
Otherwise I’m looking at the battery leakage in standby mode since this morning, and I’m not done yet. As I’m running some deep cylcle of charge/discharge it takes longer that I first expected to get a conclusion. I will keep you posted here.
Regarding stock, Europe is out of stock, a few units will be availbale in the UK this week. Still waiting for the big batch to arrive next week, enough to be in stock for a while.
EDIT: some Luxe will be available next week here in Germany https://www.berrybase.de/search?sSearch=raspiaudio
Cheers
The voltage is just my guess based on what Louis told me on GH. It’s probably a too-high scale b/c it leads to 4.45V full charge. Thinking about it he probably meant that “2300” (DAC value) is the threshold for green, not the max. I’ll change that so that max is 4.2V but I don’t know what dividor you’re using.
[edit]: at the end of the day, I can put whatever you want for scale and GREEN/YELLOW/RED threshold. Now I’ve made the scale so that max observed value in V max matches 4.2V and GREEN is >4.0 and RED is <3.6
Hi Olivier/Raspiaudio,
Thank you for your feedback. I did not measure the battery voltage below which the pulsing hiss noise occurs with a Voltmeter. The value of 3.8V that I have mentioned is the battery voltage that the squeezelite-esp32 firmware reports to LMS. According to the source code, the LED color is green for Vbat > 4V, red for Vbat < 3.6V, and white/yellow for Vbat between 3.6V and 4.0V, and he has set a scale-factor to match the reported voltage with the real voltage.
ESP Muse player information in LMS with battery fully charged is as follows:
Player Model: SqueezeESP32
Player Type: squeezeesp32
Firmware: v1.0-999-16
Player IP Address: 192.168.0.106
Player MAC Address: xx:xx:xx:xx:xx:xx
Wireless Signal Strength: 76%
Voltage: 4.25
The voltage value of 4.25V for a fully charged Li-ion battery seems a realistic value to me. So it seems that the scale factor is reasonable accurate, and the 3.8V battery voltage at which I noticed the pulsing hiss noise would then also be close to the real voltage. The 3.0V threshold that you mention is probably the supply voltage of the WROVER module? This would then be the voltage at the output of the voltage regulator for the WROVER.
Since you describe that separate voltage regulators are used for ESP32, audio codec and power amplifier, I wonder how ESP32 activity couples into the analog audio path. Maybe the battery voltage itself is modulated by the ESP32 supply current?
When I have time and courage, I may open my Muse Luxe and measure some supply voltages with an oscilloscope to find out what happens at low battery voltage.
Our post crossed, but I’ve changed the max value to be 4.2V. You can have some cells that do 4.4V but I agree this is uncommon.
Ok Philippe, that makes sense. If I get a chance to open my Muse Luxe, I can measure the battery voltage and adapt the scale factor in the bat_config key to match the reported battery voltage with the measured voltage.
Question: In case that I want to change the scale factor, can I use the Muse build of squeezelite-esp32 and enter alternative bat_config parameters in the NVS editor? Or do I then need to use the generic I2S build?
no worries I will soon provide an equivalence mesured voltage at the battery with voltmeter to raw adc.
Having successfully flashed OK a few time, I’m now having problems. It still plays OK, wifi etc but cannot do any commands with esptool to reflash. As an example using esptool with trace and read_mac command - esptool reads a number of blocks OK and then fails.
Any idea how to reset the board (e.g. remove and short pins).
Chip is ESP32-D0WDQ6 (revision 1)
TRACE +0.000 command op=0x0a data len=4 wait_response=1 timeout=10.000 data=0ca0f53f
TRACE +0.000 Write 14 bytes: c0000a0400000000000ca0f53fc0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a040000a0000000000000c0
TRACE +0.000 Received full packet: 010a040000a0000000000000
TRACE +0.000 command op=0x0a data len=4 wait_response=1 timeout=10.000 data=0ca0f53f
TRACE +0.000 Write 14 bytes: c0000a0400000000000ca0f53fc0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 13 bytes: 010a040000a0000000000000c0
TRACE +0.000 Received full packet: 010a040000a0000000000000
TRACE +0.000 command op=0x0a data len=4 wait_response=1 timeout=10.000 data=10a0f53f
TRACE +0.000 Write 14 bytes: c0000a04000000000010a0f53fc0
TRACE +0.003 Read 1 bytes: c0
TRACE +0.000 Read 12 bytes: 010a040033000000000000c0
TRACE +0.000 Received full packet: 010a040033000000000000
TRACE +0.000 command op=0x0a data len=4 wait_response=1 timeout=10.000 data=18a0f53f
TRACE +0.000 Write 14 bytes: c0000a04000000000018a0f53fc0
TRACE +10.010 Serial data stream stopped: Possible serial noise or corruption.
Really strange b/c with the FTDI chip used, when connecting such tool, the WROVER (esp32) is reset and put in download mode from ROM, so nothing can interfere and AFAIK, there is no use of locked firmware (burnt fuse). Did you try to erase everything from esptools?
In the unlikely event that the autodownload mode fails I have hidden a secret IO0 button to force the download mode. Insert a paperclip in the jack port until you feel a click and hold it, turn off and on. Then you should be in download mode.