Skip to content

Troubleshooting

Jump to bottom
Shane Rounce edited this page Mar 3, 2026 · 5 revisions

This page documents common issues, expected behaviour, and known hardware limitations of the uConsole AIO v2 upgrade kit and aiov2_ctl.

The aim here is clarity and practicality — this is not guesswork, and it is not distro-specific folklore. Where limitations exist, they are documented plainly.

Hardware Installation Warning

After installing the the AIO v2 or the RJ45 Ethernet and USB 3.0 expansion board, if the uConsole fails to boot or power on, check the ribbon cable orientation immediately.

Make sure the AIOv2 ribbon cable is installed as per this image. image

⚠ Never connect the charger if the ribbon cable is installed the wrong way round.
Doing so can permanently damage the uConsole mainboard.

If the system does not power up after installing the expansion board:

  1. Disconnect all power immediately
  2. Remove the expansion board
  3. Re-check the ribbon cable orientation
  4. Only reconnect power once the cable is confirmed correct

Audio & SDR Behaviour

No Audio in SDR++ (Debian Trixie / PipeWire)

On Debian Trixie, SDR++ does not automatically create an audio output sink.

This is expected behaviour and not a fault in SDR++.

Fix:

  1. Open SDR++
  2. Open the left sidebar
  3. Go to Module Manager
  4. Search for audio
  5. Add linux_pulseaudio_sink
  6. Open Sinks and select your audio output device

Once added, audio output will persist across restarts.

SDR Conflicts (One App at a Time)

Only one SDR application can access the RTL-SDR at any given time.

This means:

  • SDR++ and tar1090 cannot run simultaneously
  • tar1090 uses readsb, which takes exclusive control of the SDR device

The AIO app setup handles this by:

  • Starting readsb automatically when tar1090 is launched
  • Stopping it again on exit so SDR++ can be used afterwards

If SDR++ reports the device as busy or unavailable, ensure tar1090 / readsb is not running.

Power & Telemetry

What aiov2_ctl Measures

aiov2_ctl treats battery current as the single source of truth.

  • Battery rail current is used for all power calculations
  • USB-reported values are ignored
  • Internal rail estimates are ignored

This avoids misleading readings caused by USB negotiation, regulator losses, and transient load changes.

Noise Floor

  • Power deltas below 0.05 W are considered noise
  • Differences under this threshold should be ignored

This is intentional and based on real-world measurement stability.

Boot preference set but live rail OFF

If a feature is configured ON at boot but appears OFF live, check the boot apply path end-to-end.

1) Check configured boot preferences

aiov2_ctl --boot-rails-status

2) Check boot service state

systemctl status aiov2-rails-boot.service --no-pager
systemctl is-enabled aiov2-rails-boot.service

3) Check boot service logs for current boot

journalctl -u aiov2-rails-boot.service -b --no-pager

4) Check raw pin state and interpreted status

pinctrl get <pin>
AIOV2_CTL_DEBUG=1 aiov2_ctl --status

Interpretation:

  • hi/lo should report source (pinctrl)
  • -- should report source (boot_default)

If needed, apply configured boot states immediately (without reboot):

sudo aiov2_ctl --apply-boot-rails

Wi-Fi + Bluetooth Stability Issues

Summary

Some uConsole AIO boards cannot reliably power Wi-Fi and Bluetooth at the same time without hardware modification.

This is not:

  • a Linux driver problem
  • a kernel issue
  • a faulty MT7921AUN card

It is a USB power delivery limitation on the AIO board.

What’s Actually Happening

The MT7921AUN is a USB combo device providing:

  • Wi-Fi
  • Bluetooth

Both functions share the same USB power rail.

Key findings from testing and schematic review:

  • Bluetooth initialisation causes short but real current spikes
  • The AIO board limits USB current using a resistor (Rset)
  • As shipped, Rset caps the USB rail at roughly ~1A
  • Wi-Fi alone remains stable
  • Enabling Bluetooth causes:
    • brown-outs
    • USB controller resets
    • device disconnects

Reducing the Rset value (or adding appropriate buffering) resolves the issue.

Why This Likely Occurred

Evidence strongly suggests:

  • The power budget was validated against a Wi-Fi-only device
  • A Wi-Fi + Bluetooth combo card was introduced very late
  • The final configuration was not fully validated under dual-function load

Additional indicators:

  • The antenna mount PCB includes extra connections beyond early documentation
  • This strongly implies a late design pivot to support a combo module

Clear Statement of the Issue

As shipped, some boards:

  • Support Wi-Fi reliably
  • Support Bluetooth unreliably or not at all
  • Cannot power both functions simultaneously without modification

This is a hardware power budget issue, not a software one.

If Bluetooth stability is required, this limitation must be addressed.

Official Resolution Options

HackerGadgets have acknowledged the issue and outlined the following options.

The guiding principle is that users should not bear any additional cost.

Option 1 — Self-Repair

  • User performs the resistor modification themselves (0402 SMD)
  • Partial refund provided
  • No shipping required

Option 2 — Return for Repair

  • Product is mailed back for repair
  • Shipping costs covered
  • Partial refund provided (slightly less than Option 1)

Option 3 — Full Refund

  • Return the product as defective
  • Full refund
  • Shipping costs covered

For more info see: https://forum.clockworkpi.com/t/statement-regarding-aio-v2-internal-usb-c-power-supply-issue-and-compensation-plan/21131

RTC & Backup Battery (SR69 / Button Cell)

The AIO v2 board includes a hardware real-time clock (RTC).
To retain correct time across power loss, the RTC requires a SR69 watch battery fitted to the AIO v2 board.

Without this battery:

  • The RTC will reset when the system loses all power
  • Logged times, RTC sync operations, and time-based functions may behave unpredictably
  • You may see the date/time revert to the epoch on reboot

Installing the Battery

  1. Locate the RTC battery holder on the AIO v2 board (small metal clip)
  2. Insert the button cell with the correct polarity (flat side “+” up)
  3. Power the system off and on to confirm the RTC keeps time

Why it Matters

The RTC is used by:

  • aiov2_ctl --sync-rtc (writes system time into hardware)
  • Some GNSS or time-dependent applications that read the RTC
  • Keeping correct time across power cycles without network time

If you do not install a backup battery, the RTC will not retain time when the unit is powered down.

Practical Advice

  • Do not assume Bluetooth will be stable without modification
  • If you are comfortable with SMD work, the fix is small but precise
  • If not, returning the board for repair or refund is entirely reasonable
  • This limitation should be understood before deployment, especially for portable or field use

This page will be updated if hardware revisions or official fixes change the situation.


   db    88  dP"Yb      Yb    dP oP"Yb.
  dPYb   88 dP   Yb      Yb  dP  "' dP'
 dP__Yb  88 Yb   dP       YbdP     dP'
dP""""Yb 88  YbodP         YP    .d8888

---------------------------------------

aiov2_ctl — HackerGadgets uConsole AIOv2 control + telemetry tool

https://hackergadgets.com/products/uconsole-upgrade-kit

Clone this wiki locally