Putting music source in M.2 SSD

[laluciol6990]

Hi

Power supply is exactly this one https://allo.com/sparky/5v-power-supply.html#features
5V - 3A. (from Xing Yuan XY24S-0503000Q-U)

PSU → Allo Kali Reclocker Barrel 5V input → Power is passed to 1) Allo Piano DAC 2.1 through GPIO & 2) Raspberry Pi 3 through GPIO → A) SSD through USB-2 & B) Wifi Dongle through USB

Power from Kali is shared through GPIO to Allo Piano Dac 2.1 on TOP & Raspberry Pi 3 on BOTTOM through GPIO.
Then Raspberry Pi 3 give power to SSD & Wifi Dongle through USB-2

[nerd]

Hey @laluciol6990,

Thanks for the clarification - this setup sheds light on the actual configuration, but also highlights a critical discrepancy:

The original post said:

“I own a Raspberry 5…”

But this reply describes a power chain that only applies to Raspberry Pi 3:

• PSU → Allo Kali Reclocker → GPIO power to Pi + DAC
• SSD + Wi-Fi dongle running off USB-2, which only exists on Pi 3

This is important because Pi 3 and Pi 5 have completely different power and USB architectures. Debugging undervoltage and USB enumeration requires knowing exactly which SBC we’re dealing with.

Action Required: Confirm Your Actual Board

Please use the following link to generate an SBC identification form:

[GUIDE] Identifying Your Raspberry Pi Board on Volumio: A Comprehensive Guide to Revision Codes

Dear Volumionauts, Introduction Proper board identification is critical for troubleshooting your Volumio system. When posting for help, please include the raw outputs from your system so that others can accurately diagnose your issue. In particular, please share the revision code details (from /proc/cpuinfo) and the device tree information (from /proc/device-tree/compatible). This post provides a comprehensive reference table for new‑style Raspberry Pi revision codes along with the necessary co…

Or run this directly via SSH:

cat /proc/device-tree/model

Expected output for Pi 3:

Raspberry Pi 3 Model B Rev 1.2

Expected output for Pi 5:

Raspberry Pi 5 Model B Rev 1.0

Once we have positive identification, we can proceed with the correct diagnostics. Power routing and USB stack behavior vary significantly between Pi 3 and Pi 5 - especially with chained devices like the Kali and Piano DAC.

Let’s confirm this before digging deeper.

Kind Regards,

[laluciol6990]

Sorry for the confusion
The original poster mentioned a Raspberry model.
I joined the thread because of the M.2 SSD mounting issue, but my Raspberry Model is, according to the command you suggested: “Raspberry Pi 3 Model B Rev 1.2”

[nerd]

Hey @laluciol6990,

Thanks for the details. Full power path breakdown - this matches what we’d expect for an Allo stack powered via the Kali reclocker. The PSU used (Xing Yuan XY24S-0503000Q-U, 5V 3A) is within spec on paper, but the actual layout introduces multiple weak points under load:

Power Flow Analysis

[5V 3A PSU] 
   ↓
[Kali Reclocker 5V Barrel Input]
   ↓ GPIO
[→ Piano DAC 2.1 (top)]
[→ RPi 3 (bottom)]
        ↓ USB
      [SSD] + [Wi-Fi dongle]

This creates a single-rail, passive distribution tree with no power buffering or current prioritization. Issues:

• SSD and Wi-Fi dongle both draw peak current from the Pi’s USB port, which itself is powered through GPIO from the Kali
• The Pi 3’s USB power is not current-limited or isolated, so any sudden demand (SSD spin-up, Wi-Fi burst) causes a brownout across the system rail
• No dedicated 5V injection to USB, no powered hub, and no inline capacitance

The kernel’s undervoltage warning (hwmon hwmon1) is a direct result of this design - even if average load is acceptable, brief voltage dips are enough to trigger this error.

Confirmed Symptoms

• Intermittent device enumeration or failures (as originally seen with the SSD)
• Potential audio dropouts under load
• Reduced USB throughput or flaky Wi-Fi in high-bitrate streams

Recommended Fixes

1. Use a powered USB hub for Wi-Fi and/or SSD

   • Offloads transient current draw from the Pi’s 5V rail
   • Reduces brownouts on GPIO-fed logic

2. Inject 5V directly to the Pi’s USB rail

   • Only if you understand backfeeding and protection (not recommended unless you’ve isolated the Pi’s polyfuse)

3. Switch to a beefier PSU with tighter voltage regulation

   • Some 5V/3A units dip below 4.75V under real load - not acceptable for USB + I²S + Wi-Fi combined

4. Add local capacitance

   • Placing a 470µF–1000µF electrolytic cap across 5V and GND near the USB socket can dampen brownouts (hardware mod)

---

Further testing

One-Time Check (Snapshot)

Run this command via SSH:

vcgencmd get_throttled

Sample output:

throttled=0x50000

Then interpret the bits:

Bit	Meaning	Value
0	Under-voltage now	0x1
1	Frequency capping now	0x2
2	Throttling now	0x4
16	Under-voltage has occurred	0x10000
17	Frequency capping has occurred	0x20000
18	Throttling has occurred	0x40000

If you see:

throttled=0x50000

It means:

• Bit 16 → Under-voltage has occurred
• Bit 18 → CPU throttling has occurred
• (no Bit 0) → Not currently undervolting

Periodic Monitoring Script

To monitor over time and log when undervoltage occurs, use this shell script:

#!/bin/bash
LOGFILE=/home/volumio/undervoltage.log
INTERVAL=60

while true; do
    STATUS=$(vcgencmd get_throttled)
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    echo "$TIMESTAMP $STATUS" >> "$LOGFILE"
    sleep "$INTERVAL"
done

Save as monitor_uv.sh, then run:

chmod +x monitor_uv.sh
nohup ./monitor_uv.sh &

This will log entries like:

2025-04-14 21:30:01 throttled=0x0
2025-04-14 21:31:01 throttled=0x50000

You can later grep for events:

grep -v 'throttled=0x0' undervoltage.log

Kind Regards,

[laluciol6990]

Thanks for so much details!
I would check to put the script in place this weekend when i have some time.

Regarding the possible solutions, i think the easiest is to buy a beefier & better regulated PSU, like 5V >4A, industrial or medical grade from Mouser/Digikey or electronic components website…
Others solutions are a bit more complex or i don’t have the necessary knowledge…
But thanks again for the pointers!