Official FutureBit Apollo II/BTC Software/Image and Support thread

[daniel.duese]

The miner_start.sh didn't work and I had to adjust the start file. I then connected the Apollo to the MCU 2 version of the SCB board via USB. The power consumption of "only" 80 watts doesn't seem to be correct. A fully synced SSD 1 TB from the Apollo 1 doesn't seem to work either. I'm really looking forward to the V2, which will be released tomorrow, and I'm looking forward to being able to repair more of your devices.

I made the following notes during installation.

Orangepi4-lts_3.0.6_ubuntu_jammy_desktop_xfce_linux5.18.5.img # flash SD-Card
root/orangepi # user/pass
apt-get update
apt-get upgrade
reboot

# Download and start Image-install
wget https://raw.githubusercontent.com/jstefanop/apolloapi-v2/dev/backend/image_install
chmod 755 image_install
./image_install dev

Yes, there still seem to be a lot of bugs in the code and the bash installation cannot work because the "dev" attribute is missing. You are welcome to integrate me as a beta tester, as I currently have two devices here to be repaired.

curl -o- https://raw.githubusercontent.com/jstefanop/apolloapi-v2/dev/backend/install-v2 | sudo bash   # "dev" attribute is missing

but in Code need attribute "dev"

if [ "$1" = "dev" ]; then

[daniel.duese]

...next step I will try Armbian with kernel 6.6...

Armbian_24.2.1_Orangepi4-lts_jammy_current_6.6.16_xfce_desktop.img

[Tikkle]

Hi All,
I'm new to this community, I've just received my Founder Apollo II.
I'm trying to sync the node. It's going very slow.
After 24hrs I'm still at half chain (490,225/836.701)
It shows 10/32 connections.

Am I doing something wrong?
I'd appreciate any help.

Thank you

Tk

[daniel.duese]

This is completely normal... the first sync of my Apollo 1 took several days.
There is a trick...I sync my Apollos with an existing blockchain in my network. So I transfer the blockchain from one device to the Apollo. This only takes a few hours

[r00tdude]

Hi All,
I'm new to this community, I've just received my Founder Apollo II.
I'm trying to sync the node. It's going very slow.
After 24hrs I'm still at half chain (490,225/836.701)
It shows 10/32 connections.

Am I doing something wrong?
I'd appreciate any help.

Thank you

Tk

Hey TK - you need to allow 8333 to the LAN IP of your node from the internet. Check your firewall settings.

[notabeliever]

Add more lines to pool url  with 3 (or more) default options. Fallback is very important in mining.

Been waiting a couple years for this feature any idea if it will get added?

[bcfr]

Add more lines to pool url  with 3 (or more) default options. Fallback is very important in mining.

Been waiting a couple years for this feature any idea if it will get added?

I'm using miningrigrentals to handle this. I think you can setup up to 5 pools.

[BlazeB]

What did you have to adjust in the miner_start.sh file? I've got my node up and running on the v2.0.2-beta, but can't get the miner started.

The miner_start.sh didn't work and I had to adjust the start file. I then connected the Apollo to the MCU 2 version of the SCB board via USB. The power consumption of "only" 80 watts doesn't seem to be correct. A fully synced SSD 1 TB from the Apollo 1 doesn't seem to work either. I'm really looking forward to the V2, which will be released tomorrow, and I'm looking forward to being able to repair more of your devices.

[daniel.duese]

For testing I use an OrangePi 4 LTS with internal 16 GB ECC memory.
I have to mount my 1 TB SSD with fully synchronized blockchain manually. I took the start file from my old V1 Apollo because the new one unfortunately doesn't work. I connected the Apollo1 to the SBC board via USB.

miner_start.sh

chmod 755 miner_start.sh

Code:

#!/bin/bash

cd /opt/apolloapi/backend/apollo-miner
settings=$(cat miner_config)

start_hashboards()
{
    while [ $1 ];
            do
            screen -dmS miner ./futurebit-miner -comport $1 -ao_mode 1 $settings
            sleep 1
            shift
    done
}

#clear old log files
rm apollo-miner.*

#reset internal hashboard
gpio write 0 0
sleep .5
gpio write 0 1

sleep 30
#start internal hashboard

screen -dmS miner ./futurebit-miner -comport /dev/ttyS1 -ao_mode 1 $settings

#find and start external hashboards

ports=$(ls /dev/ttyACM*)
start_hashboards $ports

echo "Started"

https://duse.de/Node.png

https://duse.de/Miner.png

https://duse.de/Apollo.png

[BlazeB]

I didn't catch that version 2.0 was designed for 22.04, not 20.04. I upgraded to 22.04, and now my full node and extra standard unit are hashing away.

[kimjpeck]

Hi,

I've just received a new Apollo BTC and everything is powered on and synced.

(Ethernet Cable / Port 8333 open)

However in ECO / Balanced mode the Hardware error rate doesn't fall below 20%?

Can anyone advise?  I've dropped a email to Apollo Support but I've heard nothing back.

I have re-installed the image (on a secondary SD Card) but still getting the same issue.

Regards

Kim

Hashboards

Status         ID                     Hashrate           Temp   Fan Speed       Power   Voltage   Error       Active ASICs
Active         HASHBOARD #0         2.48 Th/s.        58°c   2526 rpm       156 W   7.97 v   20.6%     44

Settings

BALANCED
Miner mode  
    
Auto                
Miner power

Auto
Miner frequency

Auto
Fan temp settings

[jstefanop]

Hi,

I've just received a new Apollo BTC and everything is powered on and synced.

(Ethernet Cable / Port 8333 open)

However in ECO / Balanced mode the Hardware error rate doesn't fall below 20%?

Can anyone advise?  I've dropped a email to Apollo Support but I've heard nothing back.

I have re-installed the image (on a secondary SD Card) but still getting the same issue.

Regards

Kim

Hashboards

Status         ID                     Hashrate           Temp   Fan Speed       Power   Voltage   Error       Active ASICs
Active         HASHBOARD #0         2.48 Th/s.        58°c   2526 rpm       156 W   7.97 v   20.6%     44

Settings

BALANCED
Miner mode  
    
Auto                
Miner power

Auto
Miner frequency

Auto
Fan temp settings

This is bug in the ASIC hardware that reports larger than real error rate, it's a long known issue. Hashrate displayed + pool hashrate is all that matters and as you can see yours is within spec of balanced mode.


BTW dropping a stable release of Apollo OS 2 hopefully by tomorrow!

[kimjpeck]

This is bug in the ASIC hardware that reports larger than real error rate, it's a long known issue. Hashrate displayed + pool hashrate is all that matters and as you can see yours is within spec of balanced mode.


BTW dropping a stable release of Apollo OS 2 hopefully by tomorrow!

Thank you ... where would I go to download ?

Regards

Kim

[DarthLego]

BTW dropping a stable release of Apollo OS 2 hopefully by tomorrow!

Are there any plans to update the Apollo LTC firmware to match new OS?

[kimjpeck]

This is bug in the ASIC hardware that reports larger than real error rate, it's a long known issue. Hashrate displayed + pool hashrate is all that matters and as you can see yours is within spec of balanced mode.


BTW dropping a stable release of Apollo OS 2 hopefully by tomorrow!

Hi,

Any update?

Regards

Kim

[jstefanop]

This took way longer than I ever imagined by we are finally here.

Presenting the first stable beta release of Apollo OS 2!

Dropping this here first so we can get some more feedback before going to a wider release. Obviously we have done heavy testing with Apollo II but want to make sure all your setups with Apollo BTC/Standards is also working well.

Moving release and release notes over to GitHub for now and seeing how that goes. We have heard your feedback with hosting a mega, so let us know how downloads go here

https://github.com/jstefanop/apolloapi-v2/releases/tag/v2.0.3-beta

Initial image is just for Apollo BTC MCU2 users (check second post in this thread if you dont know which one you have, but If you bough an Apollo BTC in the last few years its probably MCU2

Will have the image built for MCU1 after we get initial feedback.

As always make sure you backup any files etc that reside on your SD card to the nvme drive (/media/nvme) before you flash.

Having fun solo mining!

[daniel.duese]

Thank you for the great new V2 SD card image. I've been following you on Github for a long time and compiling the image myself.

The installation of the V2 SD card image went smoothly. The Apollo V1 starts with the SCB/MCU 2 board with full fan performance. I don't know yet whether this is a feature or a bug. The Apollo SBC/MCU 1 didn't do that. It's very annoying...
If you shut down the board, the large black fan also runs at full power.
Shortly after switching on, the fan switches off and the volume becomes bearable again.

If you use an OrangePi 4 LTC with internal eMMC storage, the internal SSD is not mounted.

It would make sense to wait until the network has "booted up" before mounting the SSD?!?!?

I assume that the internal flash memory is being read much too quickly, but all services have not started yet. A pause would then have to be inserted in the rc.local before mounting the SSD.

Code:

mount /dev/nvme0n1p1 /media/nvme
#mount nvme drive

[daniel.duese]

...as soon as the SBC/MCU has completely booted up, I can subsequently mount the SSD using the command.

mount /dev/nvme0n1p1 /media/nvme

[jstefanop]

Thank you for the great new V2 SD card image. I've been following you on Github for a long time and compiling the image myself.

The installation of the V2 SD card image went smoothly. The Apollo V1 starts with the SCB/MCU 2 board with full fan performance. I don't know yet whether this is a feature or a bug. The Apollo SBC/MCU 1 didn't do that. It's very annoying...
If you shut down the board, the large black fan also runs at full power.
Shortly after switching on, the fan switches off and the volume becomes bearable again.

If you use an OrangePi 4 LTC with internal eMMC storage, the internal SSD is not mounted.

It would make sense to wait until the network has "booted up" before mounting the SSD?!?!?

I assume that the internal flash memory is being read much too quickly, but all services have not started yet. A pause would then have to be inserted in the rc.local before mounting the SSD.

Code:

mount /dev/nvme0n1p1 /media/nvme
#mount nvme drive

Yes this is normal between the two MCU variants. It's hardware differences in how they hold their control pins before/after shutdown, which affects what state our hashboard is in.

Not sure about SSD not mounting, images are built for our hardware so stock board with different configurations might have different results. You can modify the rc-local.service file to start it up when you want.

[kimjpeck]

Hi,

Update to OS 2 (Thank you)

Still showing >20% Hardware Errors

Please advice.

Regards

Kim

Total pools and hashboards

Hashboards

Active 1/1

2.54 TH/s

59°C

2760 rpm

62.68 W/TH

19.60 A

20.60%