@ Wheaton: thanks! The magic button on top: don’t understand that part., but google, yes!
I will wait a bit, tomorrow I will receive parts to build my dedicated file server for the RIVO+.
Also I have to draw some ethernet cables for my new planned setup for streaming.
@nerd @Wheaten
O,K So I killed bluetooth.
See here how to switch on and off ssh Enable SSH on Volumio: A Quick Guide | PDF | Home & Garden | Technology & Engineering
I used terminal in linux
ssh volumio@192.168.0.xxx (enter)
(use password volumio) (enter)
cd / (enter: I think not needed but did it anyway)
sudo systemctl stop bluetooth (this stopped bluetooth, verified with my smartphone)
sudo systemctl disable bluetooth (this prevents bluetooth from starting at power on)
I got at the last commando back:
Removed /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed /etc/systemd/system/dbus-org.bluez.service.
Sounds good to me!
I think it’s good to open a thread here as also raise a ticket with Volumio support.
Now you can post here your findings and let people who have a dedicated device also know about it so they know there is an issue or not.
Otherwise Volumio support get a lot of mail with the same questions and now they know that Volumio support is working on it.
@Kingpin
I did raise a ticket and the outcome was that they said it was probably not possible to switch off bluetooth.
One word of care: sure enough the RIVO+ isn’t sending it’s identification over bluetooth anymore.
I am not knowledgeable enough to be 100% sure if the carrier wave isn’t still being transmitted.
I have to look into that. I could measure the change of the drawn current perhaps to find out, or find a cheap measuring device, or perhaps another person will chime in.
Speaking of current: I did measure it and without USB thumb drives or CD transport attached it doesn’t exceed 1A. It shortly reaches 0.8A at start and after that it is typcial 0.6A.
I will at some point design my own power supply for that thing,
I changed the 10K series resistor to the blue LED to 22K, but I think I have to raise it to 39K to get my preferred lower intensity.
The Lineo 5 is build with high quality parts, nothing wrong with that It uses the brute force method, with lots of capacitance after the rectyfying bridge and even on the output.
It is a matter of taste, but I am not a fan of that method.
It means in a very small conductive angle for charging the large value of elcaps. (they charge in large current pulses 100 times a second).
And large elcaps on the outout is to my taste two captains on a ship, but I didn’t reverse engineer the regulation fully, so I don’t know if Volumio did something clever there.
(the regulator makes the output actively via feedback low impedance and // to that the elcaps are low impedance: like shorting for AC the output, this can result in pumping white noise (or depending on the the design pink noise) into the elcaps by the regulator circuit, or even lead to kinda equivalent of TIM distortion in audio power amps. (In fact a power supply and a power amp are essentially the same)
I am sure everybody reading this will understand the above.
The current spikes (100 times / second) drawn by the LINEO5 do, as by every linear power supply, result in current spikes in the power cord, power strip, fuses, etcetera.
So I build something in line of the power cord to soften things up, and also reduce common mode currents.
The LINEO 5 does it right were it comes to ground loops: the AC ground isn’t connected to the output. We say that it is a floating output. (which doesn’t mean for higher frequencies that it is free of common mode currents of course.
Common mode currents: the big elephant in the room that is largely ignored by audio companies, but I do see that some are taking some action to reduce it.
Hey @Frans,
Glad you got clarity from Marco, but one technical correction before this gets repeated as a recipe by anyone else reading the thread: stopping and disabling bluetooth.service is not the same as disabling the Bluetooth hardware. They are two different layers and it matters.
What you actually did:
- systemctl stop bluetooth shuts down bluetoothd, the BlueZ userspace daemon. That is the process responsible for pairing, profiles, the D-Bus API, and making the device discoverable to your phone. Killing it removes the visible behaviour, which is why your phone no longer sees the Rivo.
- systemctl disable bluetooth removes the symlinks so bluetoothd does not start at boot. Same effect, made persistent.
What that does not do:
- The HCI controller itself (hci0) can still be attached and powered. On device-class hardware the Bluetooth side is UART-attached and brought up by a firmware-load step (brcm_patchram_plus / btattach) that runs independently of bluetoothd. If that bring-up still runs, the radio is up even though nothing in userspace is talking to it.
- The physical layer - the thing you actually care about for RF reasons - is governed by rfkill and by whether the controller has been told HCI Reset / power down, not by whether bluetoothd is running.
The correct analogy is not airplane mode. It is closer to closing the app that talks to the radio while leaving the radio itself powered. You have removed the pairing agent, not switched off the transmitter.
If the goal is genuinely to take the radio off air, the layers to address are, in order of increasing firmness:
- rfkill block bluetooth - soft-blocks the radio via the kernel rfkill subsystem. Reversible, survives until reboot unless persisted.
- Mask the unit that runs the UART bring-up / firmware load, so hci0 is never attached in the first place. After that, hciconfig shows nothing and there is no controller to transmit.
- modprobe.d blacklist of hci_uart (and btbcm where relevant) for belt-and-braces, so the modules do not load at all.
Your instinct to verify by measuring supply current is the right one, and it is the only way to know which layer you are actually at. If current draw is unchanged after stop/disable, the radio is still powered and you have only silenced the daemon. A drop would indicate the controller has gone down, which with what you have done so far would be coincidental rather than guaranteed.
None of this changes Marco’s position that Bluetooth on Rivo+ is always active by design because the controller is shared with the onboarding path, and none of it is a recommendation to modify a shipped commercial unit. It is a correction to the technical description so the thread does not leave “systemctl disable bluetooth” sitting as a synonym for “Bluetooth off”, which it is not.
Kind Regards,
@nerd Thank you very much.
You confirmed my fear that the carrier wave would still exist. (as i mentioned somewhere above)
I tried the rfkill comand first, but got the message it wasn’t recognized.
So: I will remove the antenna’s. Usually when electronics go wrong in is mostly in first 2 weeks if something is wrong, so there is a very slim chance I will have to use the now void warranty.
I’ll take it.
Thank you again!
Yes i know about the current draw, nice you measured it again.
In the past i build a lot of power supplies, most of them uses the LT3045, TPA’s and if i wanted more current the LT78xx or LM’s.
Nowadays i can recommended the Ian Canada ones, they uses 10x LT3045 parallel with Sense, so output wil always stays the same on different loads.
It’s not getting any better than this.
Well … i made ones an 3x LT3045 parallel with LiPo powered, completely free from mains but that’s another story.
Anyway i see you uses an thumbdrive …
I had (have) an issue with SSD on USB drive input problem which is an known issue now at Volumio support.
Wonder if you experience the same.
@Kingpin
I tried a USB stick once to find out that the sound quality sucked, so that was end of the experiment.
I had for a short time a shanling CD transport which I returned as I decided to go for streaming. It had also an USB for a USB stick: that sounded much better.
By the way I will be designing a discrete power supply, no IC’s allowed.
1 Like
O.K. I accept it as it is.
Just to be sure: I still love the RIVO+, it is awesome!
1 Like