FutureBit Apollo III - Next Gen Home Mining

[FP91G]

(Edit : added logs)

Hi

New Apollo III owner here from France  
My unit arrived two days ago and node is now fully synced and operationnal.
Unfortunately, the miner part is not working at all    When clicking the start button, it is spinning an spinning until it stops saying the miner is offline (see images below).
Besides, it is showing a "N/A" in the overview panel in hardware errors.

The fan has also a strange behavior as it launches for one second only every minute. Plus, I can regularly hear a "clicking" sound, as if the miner was trying to switch on but couldn't.
I've just flashed the sd card with the firmware and complete the setup process again. Didn't do anything.
Do you have any idea on how to solve that ?

Thank you

(please excuse my poor english)









Here are some logs if it helps :

2026-09-30T06:43:18.117929-04:00 futurebit-apollo-3 node[1610]: Error getting miner screen output: Command failed: sudo screen -ls | grep "miner"
2026-09-30T06:43:31.315092-04:00 futurebit-apollo-3 miner_start.sh[91318]: Started
2026-09-30T06:43:31.393437-04:00 futurebit-apollo-3 miner_stop.sh[92336]: Stopped
2026-09-30T06:43:31.394644-04:00 futurebit-apollo-3 systemd[1]: apollo-miner.service: Deactivated successfully.
2026-09-30T06:43:31.394900-04:00 futurebit-apollo-3 systemd[1]: Started apollo-miner.service - apollo-miner.
2026-09-30T06:44:01.528059-04:00 futurebit-apollo-3 systemd[1]: apollo-miner.service: Scheduled restart job, restart counter is at 38.
2026-09-30T06:44:01.537357-04:00 futurebit-apollo-3 systemd[1]: Starting apollo-miner.service - apollo-miner...

I’ll quote the images.
There are few logs, and it’s hard to determine from them why the miner is stopping. It might be a software error, but if reflashing didn't help, is there a way to see why critical errors occur when starting the miner?
For this, you need the miner's logs, not the device logs.

[tibiniou]

Thank you

The miner gives me no logs at all. Here it is
"Unable to retrieve miner screen output: Command failed: sudo screen -ls | grep "miner"
. No miner screen sessions found."

I played a little with ChatGPT exploring the options, and it suspects a problem with the temperature sensor. Seems the miner couldn't reach the sensor, and stops immediately the apollo-miner.service.
So now, I have to understand if it is a firmware or hardware failure.

[FP91G]

Thank you

The miner gives me no logs at all. Here it is
"Unable to retrieve miner screen output: Command failed: sudo screen -ls | grep "miner"
. No miner screen sessions found."

I played a little with ChatGPT exploring the options, and it suspects a problem with the temperature sensor. Seems the miner couldn't reach the sensor, and stops immediately the apollo-miner.service.
So now, I have to understand if it is a firmware or hardware failure.

Without the miner's logs, one can only speculate about the nature of the malfunction. Based on this log, the error could be either software- or hardware-related, it is best to return the unit to the seller unless they can offer a remote solution.
I wouldn't bother testing the hardware of equipment that's under warranty, what does the warranty service say?

[crypto_curious]

Thank you

The miner gives me no logs at all. Here it is
"Unable to retrieve miner screen output: Command failed: sudo screen -ls | grep "miner"
. No miner screen sessions found."

I played a little with ChatGPT exploring the options, and it suspects a problem with the temperature sensor. Seems the miner couldn't reach the sensor, and stops immediately the apollo-miner.service.
So now, I have to understand if it is a firmware or hardware failure.

Sorry to hear your miner arrived DOA. You may need to send it back if it's faulty. But before you do that, you can try few things yourself, for curiosity:
ssh into it, let chatgpt tell you diagnostic commands to run and paste back. You may get closer to finding reason why its not mining.
Normally you log into it via

Code:

ssh 192.168.1.100 -l futurebit

replace IP with number assigned to the device by your router. Apollo miner is a systemd service there if I remember correctly, run via "screen", you can query it's status, or stop it (so it does not interfere), and run it by hand to obtain full logs, which you can then paste here or to chatgpt.

[tibiniou]

Thank you both of you.

I played with ssh and ChatGPT. Copying the command results it gaves me, it ended telling me the miner couldn't start because of the temperature sensor which couldn't be reached. It makes sense because I can hear the fan briefly starting and immediately stopping, preventing the miner from burning as the fan wouldn't self adjust without the temperature value.

I'm waiting for the distributor answer now.
Thank you

[FP91G]

Thank you both of you.

I played with ssh and ChatGPT. Copying the command results it gaves me, it ended telling me the miner couldn't start because of the temperature sensor which couldn't be reached. It makes sense because I can hear the fan briefly starting and immediately stopping, preventing the miner from burning as the fan wouldn't self adjust without the temperature value.

I'm waiting for the distributor answer now.
Thank you

It’s great that you were able to check the miner's logs. If it is a hardware issue, I wouldn't attempt to repair it yourself.
In reality, the problem might not even be the temperature sensor. Impacts during shipping could have compromised solder joints on the chip or other components. Alternatively, even a slight voltage drop could be triggering the error.

[jstefanop]

Thank you both of you.

I played with ssh and ChatGPT. Copying the command results it gaves me, it ended telling me the miner couldn't start because of the temperature sensor which couldn't be reached. It makes sense because I can hear the fan briefly starting and immediately stopping, preventing the miner from burning as the fan wouldn't self adjust without the temperature value.

I'm waiting for the distributor answer now.
Thank you

Where did you order from? We have had one other report of a failed temp sensor which causes the board to auto shutdown, want to make sure we get this back so we pinpoint the failure.

[Black_Onyx]

Hello,

After 4 month of waiting it finally arrived last week and working flawlessly.

Wish the UI would have a little more options but looking good.

https://i.postimg.cc/kXfbWRMN/Screenshot-20261006-155152-Chrome.jpg

[tibiniou]

Where did you order from? We have had one other report of a failed temp sensor which causes the board to auto shutdown, want to make sure we get this back so we pinpoint the failure.

I ordered from the official European distributor Bitshopper.de

[FP91G]

Where did you order from? We have had one other report of a failed temp sensor which causes the board to auto shutdown, want to make sure we get this back so we pinpoint the failure.

I ordered from the official European distributor Bitshopper.de

Your colleagues from Europe mentioned that it is very easy to return equipment within the first 14 days of purchase.
I am not sure exactly how the process works in your case, but generally, if a customer requests a replacement with a working unit, the store tends to be more accommodating. All devices have a certain defect rate, and warranty returns usually don't present any issues.

[Black_Onyx]

@jstefanop,

I would appreciate your help determining whether this is normal or if there may be an issue with the back cover of my unit.

When I received the unit, I tried to install a 1 TB Seagate FireCuda 530 NVMe drive. However, I could not install it without risking damage to the NVMe chip because the screw was touching either the chip or the side of the back cover (see attached picture).

https://i.postimg.cc/FzPG4ZdR/20260925-231557.jpg

I then switched to a Samsung 990 Pro, which has more clearance between the screw notch and the NVMe chip. However, with the NVMe installed, the screw still touches the side of the back cover and became lodged in it, preventing me from removing the screw without damaging the cover (see attached picture).

https://i.postimg.cc/8CPR1WGJ/2026-10-07-173053.jpg

To try to resolve the issue, I opened the back cover, loosened the controller board, and pushed the screw to improve its position. This helped slightly, although the fit is still not perfect.

During this process, the red/black wire became disconnected from the controller board, and unfortunately I did not see where it was originally connected.

Could you please confirm where this wire should connect on the board and which side the red and black wires should go on? (See attached pictures.)

https://i.postimg.cc/wBKCZqY4/2026-10-07-173803.jpg
https://i.postimg.cc/DZ6RS1Jt/20261007-141417.jpg

Cheers!!!

[philipma1957]

Fixed the pictures. My unit was also tight but not as tight as yours.

@jstefanop,

I would appreciate your help determining whether this is normal or if there may be an issue with the back cover of my unit.

When I received the unit, I tried to install a 1 TB Seagate FireCuda 530 NVMe drive. However, I could not install it without risking damage to the NVMe chip because the screw was touching either the chip or the side of the back cover (see attached picture).



I then switched to a Samsung 990 Pro, which has more clearance between the screw notch and the NVMe chip. However, with the NVMe installed, the screw still touches the side of the back cover and became lodged in it, preventing me from removing the screw without damaging the cover (see attached picture).



To try to resolve the issue, I opened the back cover, loosened the controller board, and pushed the screw to improve its position. This helped slightly, although the fit is still not perfect.

During this process, the red/black wire became disconnected from the controller board, and unfortunately I did not see where it was originally connected.

Could you please confirm where this wire should connect on the board and which side the red and black wires should go on? (See attached pictures.)




Cheers!!!

[FP91G]

Cheers!!!

Check what kind of cable it is. If it leads to the power button, it should likely be connected to the POWER pins. The board turns on when the contacts are shorted, so it doesn't matter which side the red wire is on and which side the black wire is on. However, you can look for the mark left on the board by the plastic connector to see how it was installed at the factory.

However, check everything yourself before connecting, if you have any doubts, consult a specialist.

[jstefanop]

Cheers!!!

Check what kind of cable it is. If it leads to the power button, it should likely be connected to the POWER pins. The board turns on when the contacts are shorted, so it doesn't matter which side the red wire is on and which side the black wire is on. However, you can look for the mark left on the board by the plastic connector to see how it was installed at the factory.

However, check everything yourself before connecting, if you have any doubts, consult a specialist.

No this is the power wire, it definitely matters which side is black/red. If you plug in the wrong way you will definitely fry the controller board.

Looks like you yanked the whole socket of the pins, you'll need to remove the beige socket off the connector, then place the socket back through those two power pins and plug in the power connector.

Here is the correct orientation since im sure more people than you will need this:

https://imgur.com/YC1MhnT

[crypto_curious]

Here is the correct orientation since im sure more people than you will need this:

https://imgur.com/YC1MhnT

Can you upload it elsewhere? Imgur does not work in some countries including the UK.

[Black_Onyx]

No this is the power wire, it definitely matters which side is black/red. If you plug in the wrong way you will definitely fry the controller board.

Looks like you yanked the whole socket of the pins, you'll need to remove the beige socket off the connector, then place the socket back through those two power pins and plug in the power connector.

Here is the correct orientation since im sure more people than you will need this:

https://imgur.com/YC1MhnT

Thanks for the picture! Yeah, I saw the two power pins. Since just above one of them there is an indicator (O) under the "Power", it made me think they needed to be plugged in a specific way.  


@crypto_curious,

Here you have...
https://i.postimg.cc/X7Bw57Rq/Screenshot-20261009-124122-Chrome.jpg

[FP91G]

No this is the power wire, it definitely matters which side is black/red. If you plug in the wrong way you will definitely fry the controller board.

Looks like you yanked the whole socket of the pins, you'll need to remove the beige socket off the connector, then place the socket back through those two power pins and plug in the power connector.

Here is the correct orientation since im sure more people than you will need this:

It is best to connect it as shown in the photo, you did the right thing by finding the documentation.
From my own experience, I can say that wire polarity does not matter for the POWER button. I have personally started such devices many times by shorting the contacts with a screwdriver. This works on the motherboards of computers, laptops, tablets, and so on.
However, if the wires connect to a different controller, then polarity does matter.

[Madcity]

Apollo III Standard / Web OS v2.1.3: node.service restarts every 30 seconds — workaround verified

I found a persistent local Bitcoin-node service restart loop on my Apollo BTC III Standard running Apollo Web OS v2.1.3. I’ve sent the details to FutureBit support and am posting here in case other Standard owners see the same behavior.

Setup

* Apollo BTC III Standard, miner-only model.
* Apollo Web OS v2.1.3.
* Mining to Public Pool on a separate Umbrel machine.
* No local Bitcoin node or NVMe blockchain storage in use on the Apollo.
* A Bitaxe also connects to the same pool.

How I discovered it

The Apollo’s pool connection uptime reset to approximately 18 hours, along with its session-best share difficulty. The Bitaxe retained its week-long connection.

Running uptime over SSH confirmed that the Apollo’s controller itself had rebooted, rather than just reconnecting to the pool.

While investigating the reboot, I discovered the node-service loop described below. The reboot’s cause remains unknown; I have not established that this loop caused it.

Confirmed behavior

The Apollo attempts to start its local Bitcoin node approximately every 30 seconds. Each attempt reports that /dev/nvme0n1p1 is missing, so bitcoind is not started. The service exits successfully, then systemd schedules another attempt.

The backend also repeatedly attempts to contact the unavailable local Bitcoin RPC endpoint.

Commands used to inspect the logs:

sudo journalctl --list-boots --no-pager
sudo journalctl -b -1 -n 80 --no-pager
sudo journalctl -b 0 -u node.service -n 15 --no-pager

Representative log messages, with timestamps, hostname, and process IDs omitted:

node.service: Scheduled restart job, restart counter is at 31000.
Starting node.service - node...
[node-start] WARN: node drive device not found at /dev/nvme0n1p1; bitcoind not started
No screen session found.
node.service: Deactivated successfully.
Started node.service - node.
Error in _getNodeStats: connect ECONNREFUSED 127.0.0.1:8332

The previous boot reached 31,006 node-service retries. After the reboot, the loop continued and reached 2,223 retries in approximately 18.7 hours.

These are service retries—not 31,006 miner restarts or device reboots. At one attempt every 30 seconds, this produces roughly 2,880 unnecessary startup attempts per day, plus RPC error messages.

The address 127.0.0.1:8332 above is the device’s own local Bitcoin RPC endpoint, not my Umbrel server or a public IP address.

Service configuration

I inspected the service with:

systemctl cat node.service --no-pager

The file /etc/systemd/system/node.service contains:

[Unit]
Description=node
After=multi-user.target
After=apollo-ui-v2.service
After=dev-nvme0n1.device
[Service]
Type=forking
User=futurebit
#Start:
ExecStart=/opt/apolloapi/backend/node/node_start.sh
#WorkingDirectory=/opt/apolloapi/backend/node
#Stop:
TimeoutStartSec=300
TimeoutStopSec=600
ExecStop=/opt/apolloapi/backend/node/node_stop.sh
#Restart
Restart=always
RestartSec=30s
[Install]
WantedBy=multi-user.target

The relevant combination is:

Restart=always
RestartSec=30s

The startup script exits without starting a node because no drive is present. Despite the successful exit, Restart=always causes another attempt after 30 seconds.

Workaround verified on my Standard unit

This applies to my miner-only configuration using an external pool. Do not apply it to an Apollo whose local Bitcoin node you need for solo mining or other node functions.

First, I checked reverse dependencies:

systemctl list-dependencies --reverse node.service --no-pager

Output:

node.service
● └─multi-user.target
●   └─graphical.target

I stopped the unused local node service:

sudo systemctl stop node.service

Then checked the node and miner services:

systemctl is-active node.service apollo-miner.service

Output:

inactive
active

Public Pool continued receiving shares from the Apollo.

I then disabled the node service’s automatic startup:

sudo systemctl disable node.service

Output:

Removed '/etc/systemd/system/multi-user.target.wants/node.service'.

Final verification:

systemctl is-enabled node.service
systemctl is-active node.service apollo-miner.service

Output:

disabled
inactive
active

No reboot, firmware flash, service-file edit, or mining configuration change was required.

What this does—and what remains unverified

* The local node service is stopped and disabled from automatic boot startup.
* The mining service remains active and shares are still being submitted.
* I have not yet tested this across another reboot or firmware update.
* Disabling a service does not prevent software or dashboard actions from explicitly starting it.
* I have not separately verified whether the backend’s local RPC polling stopped.
* This is a user-tested workaround, not yet a FutureBit-confirmed fix.

Separate issue: unexplained reboot

The previous boot’s final journal entries did not show a normal shutdown sequence. This command returned older HDMI audio errors rather than an explanation for the reboot:

sudo journalctl -b -1 -k -p warning -n 60 --no-pager

The evidence inspected so far does not identify the reboot’s cause or link it to the node-service loop.

Suggested software correction

For Standard units not configured to run a local node, it would help if the software:

1. Left the local Bitcoin-node service disabled by default.
2. Treated missing or unconfigured node storage as an inactive configuration rather than repeatedly retrying a successful no-op startup.
3. Avoided polling local Bitcoin RPC when local node functionality is disabled.
4. Preserved the intended node setting across updates and dashboard operations while retaining appropriate recovery behavior for configured Full Node units.

Has anyone else with an Apollo III Standard on v2.1.3 seen this loop? It would also be helpful to hear whether FutureBit considers disabling node.service the appropriate workaround and whether a software fix is planned.