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

[eagleye]

IMO: This system is not designed to run a lightning node.  From what I've read to run a lightning node you need multiple open channels.  You need an efficient and online system 24/7 with quick response.  You need backup servers in case a server crashes.  Your dedicating 1 BTC or more to your lightning network to make it attractive to use.

The apollo II can barely handle a node and mining.  Anything else I think will just overload the small CPU in the system and a bitcoin node will conflict with a lightning node.

Many seem to choose an AWS service, or similar,  as being more reliable to run a lightning node  capacity and speed of server network connections.

I think the designers mentioned they designed this apollo system to do just one thing host a node and mine.  That's it, KISS.  Theres not a lot more you can add.  I've seen system performance deteriorate quickly when you try to run multiple programs above what's provided.  What is more impressive is your apollo II can pool multiple bitcoin miners within your network.

[PZ]

I am running V2.06. I purchased a Full node and a standard weeks ago.  From day 1, the full node has not worked. The box disconnects, locks up, and hasn't moved past 15%; numerous connections have been refused.  I've reflashed the SD card, performed a format on the SSD drive innumerable times, and even placed two node configuration lines provided by Futurebit support (dbcache=128 and maxmempool=128); both did nothing.  I went through all my firewall settings, as I have a Firewall router, and placed the full node IP address in emergency mode, which essentially opens all ports and disables all existing rules and policies that did not work.  I connected it directly to my ISP via WIFI, that did not work.  At this point, I feel like I'm doing FutureBit's job, and I didn't pay $1,700 to play helpdesk support on my own.  I also tried to reflash the SD card to version 2.05, as some stated that the version was much more stable, but that did not work.

The most disappointing experience was that I purchased over $1,700 of equipment and have not received one response from Future Bit for days, except one email, which took almost 4 days to respond.  I am incredibly frustrated with the equipment and lack of support.

Another one with a similar problem. I bought it new and it gives an error when synchronizing the node. It always stays on the same block. It fails on wifi and lan. The error always occurs in the same place, regardless of whether the miner is on or not. Does anyone who has solved it already have a way to solve this problem?

Have you reflashed the microsd system card?  Replaced the Microsd system card and flashed a new card.  Also checked the issues with placement of the microsd card in the slot?  There was tape on mine to secure the card in transportation, which makes sense, but I think it could cause issues with card operation.

My system had a defective microsd card.  These cards seem old.  The new card worked fine and many problems I had went away.
I've had a 128GB microsd running v2.0.5 for several months without issue.  This card is new and ran 180MB/sec read  pretty well.
I felt it would take too long to claim a warranty and these cards are so cheap it would be faster to just get one to try out.

I just picked up a cheap ONN 32GB microsd at a cheap worldwide supermarket.  IT's speed is slower.  100 MBsec read / 11MBsec write.  flashed v2.0.6.  It's up and running.

The difference between the new fast 128GB card and 32GB card is there.  Here's the report: booting 128GB card and the system boots within 15 seconds main screen is up in 60 seconds.  The 32GB card took longer to boot   30 seconds boot and 90 seconds main screen.  As system is running no noticeable difference.
  Maybe slightly slower response when you click on a program.

No, it's new, just bought. I did a "reindex" and for 3 days (I think I have 3 more days left to finish) the operation seems a bit "robust" to me. Many crashes, restarts, errors and blocks... so far more doubts than certainties.

[oneeighteen]

[/quote]

The only officially supported NVMe drives are Kingston NV2s and Curcial P2/P3s.

We have also noticed some newer Gen4 drives are not compatible and this is a hardware issue. Our custom SSD drive adapter for this board is only designed for 2x PCIe Gen 2 lanes.

There is no need to buy higher end NVMe drives for this system as its a waste, they will either fail because they draw to much power, or newer Gen4 pcie protocol is incompatible with our hardware.

We are currently sourcing Kingston NV3 drives, but only one type with a certain controller works with our system, they have two types with a different controller that does not work.

Also I know 660GB/1TB seems like the drive is almost full, but bitcoin is growing at about 100GB/Y even in its current maxed out full blocks state. 1TB drives have at least 2-3 years of life left, and 2TB drives will literally last the life of the system at over 10 years.

2TB is boarderline overkill, 1TB will last enough where you can get a 2TB for half the cost in 2 years.
[/quote]



Does a Gen 3 drive work? Specifically a Crucial P3 Gen 3 x 4
model# CT2000P3SSD8

[slurfius]

The newest Etcher version works fine for flashing the new MCU2 v2.0.6. Old Etcher (v1.18.11) fails to load on my Mac now, advises to immediately dismount or will cause damage.

I was trying to update one of my batch 1 apollo and now that the new version of etcher failed to flash the compressed img and my mac won't load etcher v1.18.11 I have a paperweight with no os how did you get around this?

[slurfius]

The newest Etcher version works fine for flashing the new MCU2 v2.0.6. Old Etcher (v1.18.11) fails to load on my Mac now, advises to immediately dismount or will cause damage.

I was trying to update one of my batch 1 apollo and now that the new version of etcher failed to flash the compressed img and my mac won't load etcher v1.18.11 I have a paperweight with no os how did you get around this?

I figured out that using archive utility to unzip first then flashing with the latest etcher worked

[eagleye]

Cleaning dust off the APOLLO II.

It's been 3 months since I received my Apollo II.  I have mine turned sideways for better airflow through the bottom, which it does.  The top vents are clogged from dust accumulation.  I suspect that would get worse faster if I had the top vents pointed up. 

Shut down my node, got the Air compressor blower and blew the dust back out.  Lots of fine dust was blown out the top and bottom.  No noticeable cooling difference.  I thought there might be but the unit seems to be cooling well even with a small coating of dust.  Now good for another 3 months.

running a fresh flash of v2.0.6 does seem more stable than v2.0.6 as long as I don't load up a bunch of other stuff In the browser.   And don't try to restore saved settings as this wipes the settings installed in v.2.0.6.  When I did this my node became less stable with the settings I saved from v.2.0.5  includes reverting back to 32 node connections.  On v2.0.5 when I upped the nodes to 64 the system would crash.  Not under v2.0.6.

[aurel57]

Cleaning dust off the APOLLO II.

It's been 3 months since I received my Apollo II.  I have mine turned sideways for better airflow through the bottom, which it does.  The top vents are clogged from dust accumulation.  I suspect that would get worse faster if I had the top vents pointed up.  

Shut down my node, got the Air compressor blower and blew the dust back out.  Lots of fine dust was blown out the top and bottom.  No noticeable cooling difference.  I thought there might be but the unit seems to be cooling well even with a small coating of dust.  Now good for another 3 months.

running a fresh flash of v2.0.6 does seem more stable than v2.0.6 as long as I don't load up a bunch of other stuff In the browser.   And don't try to restore saved settings as this wipes the settings installed in v.2.0.6.  When I did this my node became less stable with the settings I saved from v.2.0.5  includes reverting back to 32 node connections.  On v2.0.5 when I upped the nodes to 64 the system would crash.  Not under v2.0.6.

I also have mine on its side with the large vent and switch pointed up, also sitting on top of a laptop cooler. I notice a few days ago the dust on the top vents and used my vacuum to suck it away. I am still using v.2.0.5 and I have set mine to 64 node connection without a problem. It will bounce between 63-64.  (Just checked and it's connected to 3 other Apollo nodes right now)

[PakoTor]

I have 1 node and 2 standard Apollo 1 units running well for a couple years.
Wanted to upgrade but the Apollo 2 is extremely overpriced compared to the Avallon.
I instead got 5 Avalon Nano 3 and thinking about the mini now.
Why would I buy American for twice or 3 times the cost when Trump is threatening Canada

[jdh3]

On the solo mining page where it shows users and workers.  I was doing some testing outside the network to see if I could get the Apollo to work as an off the internal network pool.  It did work 

Now for the question.

How long will it show the red X and user active 0/1.  Will it timeout and go away or is there a way to reset it since I don’t want to see this every time I check the pool.  I will be adding other mining devices later but not that one.  I just want it to display what's going on now.  Would be great to just to click the x and have it go away.

Thanks

J-

[jstefanop]

Software Bug Found:  Changing system time zone will cause miner data to reset to 0 while miner and node programs are running.  Stopping and restarting the miner did not fix the problem.
v2.0.6  apollo II

I changed the time zone on the Apollo II.  This caused all miner data to reset to 0 and not report any data.  I waited an hour and no update.  It did not affect node data and solo mining data.  Miner operated as normal and fan speed is working.  But you can't see temp data for the miner nor fan speed.

A reboot after setting the time zone did fix the problem.

Thanks will look into fixing this for UX. Prob a local time bug instead of using UTC.

The newest Etcher version works fine for flashing the new MCU2 v2.0.6. Old Etcher (v1.18.11) fails to load on my Mac now, advises to immediately dismount or will cause damage.

I was trying to update one of my batch 1 apollo and now that the new version of etcher failed to flash the compressed img and my mac won't load etcher v1.18.11 I have a paperweight with no os how did you get around this?

I figured out that using archive utility to unzip first then flashing with the latest etcher worked

Yes etcher is a mess right now very annoying...use latest version and decompress the image first

Cleaning dust off the APOLLO II.

It's been 3 months since I received my Apollo II.  I have mine turned sideways for better airflow through the bottom, which it does.  The top vents are clogged from dust accumulation.  I suspect that would get worse faster if I had the top vents pointed up. 

Shut down my node, got the Air compressor blower and blew the dust back out.  Lots of fine dust was blown out the top and bottom.  No noticeable cooling difference.  I thought there might be but the unit seems to be cooling well even with a small coating of dust.  Now good for another 3 months.

running a fresh flash of v2.0.6 does seem more stable than v2.0.6 as long as I don't load up a bunch of other stuff In the browser.   And don't try to restore saved settings as this wipes the settings installed in v.2.0.6.  When I did this my node became less stable with the settings I saved from v.2.0.5  includes reverting back to 32 node connections.  On v2.0.5 when I upped the nodes to 64 the system would crash.  Not under v2.0.6.

I also have mine on its side with the large vent and switch pointed up, also sitting on top of a laptop cooler. I notice a few days ago the dust on the top vents and used my vacuum to suck it away. I am still using v.2.0.5 and I have set mine to 64 node connection without a problem. It will bounce between 63-64.  (Just checked and it's connected to 3 other Apollo nodes right now)

DO NOT DO THIS.

Figured this is also a contributing factor to failed power switches as well.

The unit is carefully designed to have balanced airflow coming from top and bottom of device (even the height of the rubber pads was painstakingly chosen for optimal flow). This is because the PSU is passively cooled via the main heatsink fan, if you put it on the side almost all the airflow goes through the bottom (with yes slightly reduced fan speeds which is why people are probably doing it), but means the PSU gets NO airflow and overheats.

[moderator's note: consecutive posts merged]

[eagleye]

APOLLO II in field temperature performance.

The case design is tight.  The metal case is critical in thermal dissipation.  Airflow is also critical.  When the fan increases speed it means the temp sensors need more airflow to compensate higher temperatures.  IF fan speed is lower there is sufficient airflow to cool the cpu and miner.

With the miner in normal position, the design as you say is to increase flow through the top vents.  THis is correct that the airflow through the top vents does help cooling of the power supply.  But there are only 3 fine vents on the top.  It looks like the design was for most airflow through the bottom.  The problem with this design is air is pulled through the top and bottom and then out the side.  The side exhaust creates a feedback airflow loop back to the bottom of the unit.  Thus, a percentage of hot exhaust air gets pulled back into the bottom increasing temps entering unit.   Next, in the real world where there is dust, if you watch with the correct light you will see dust pulled into the top vents and dust landing on the surface also gets pulled into the bottom at a higher rate than fans than intakes located on the side.  The top vents accumulate dust much quicker causing the same airflow problem that increases heat into the power supply.  Most computer designs I've seen and used have the intake and exhausts on the side.  I would think a future design with the fan vent pointed up and intakes on the side and bottom would be better as thermal heat wants to rise.

Now, for this SITU: The power supply seems to have a heat sink connected to the case looking through the vents.  WIth an infrared temp sensor I measured the metal sides and top.

In normal position the APOLLO II reported temps 2-3deg. C. higher and fan speed 200-300 RPM higher than turning my unit on its side.  This tells me the unit is not getting enough airflow based on measured temperatures.  The exterior side where the power supply measured 37-38 Deg. C.   When turning the unit with the HDMI pointed up.  miner temp dropped and fan speed dropped.  The temp on exterior case was 39-40 Deg C.  This all while running in turbo mode.  This should not be hot enough to create problems.  I would think running the miner cooler is more important to extend life of miner.  Case temperature next to power supply was similar to apollo reported system temperaure.  System temperature was actually warmer than case temp and did not change much based on position.  Maybe there needs to be a temp sensor in the power supply for future design.  With intake on the sides there is no exhaust feedback to the bottom part of the case that is now on the side.  The volume of air pushed out the exhaust actually creates airflow over the sides helping fresh airflow into the vents and natural cooling of the metal case

Regarding the Switch.  Either its a design flaw in excess current through the small switch or its a faulty switch.  Temp measured at switch is same at case temp 38-40 Deg. C.  It's also next to fan.  I've had no problems with my switch from a unit shipped in October.  5A through a 5A switch will fail more often than 4A through a 5A switch and 3A through a 5A switch will fail much less if at all.  I would suspect a bad batch of switches.

Running the miner in normal mode or eco mode should automatically pull much less power reducing stress on the power supply, no matter what position the miner is placed.
In eco Mode the miner runs very well in the normal position. is very quiet and uses little power.  
I run the Apollo II in turbo mode when the ambient room temp is below 72F.   I notice a higher ambient temperature and the miner seems to run hot no matter the position and higher fan speed.  I don't want to push it.

Overall this is a very nice design and I'm sure was not easy to fit everything into this small package and slick look.  The exhaust heat sink and heat pipes are very efficient to pull heat away from the cpu and miner.  The other reason I like the unit sideways is so I can look inside the bottom and see all the LED lights hidden from view which tell me how my miner is operating.   The LED light on my NVME lets me know when data to memory is active or inactive.  

Hardware hacking.

Update:  i'm playing around with mining speeds and position.  I will say, when running in eco mode I think the miner should be placed as designed.  While fan speed is lower sideways and power draw is low, you lose airflow volume with this low fan speed.  Placing the miner as suggested in eco mode does cool the miner overall with a slightly higher fan speed but not too noticable.  Sideways cooling in eco at 75F ambient and the fan was running 2600 to 2800RPM.  In standard apollo II display position, fan speed increased to 3100 RPM.  overall case temp dropped on 3 flat sides.  Power supply side cooled 2-4 deg C. no change in apollo measured miner temp at 68C and system temp at 44-46C.

[eagleye]

Pulled the I-Standard windows .exe off github. Windows defender objected (Trojan:Win32/Wacatac.B!ml). So I, verified with VirusTotal.com, which confirmed a risk (37 of 73 scanners objected).
Is there a story here that anyone else has seen?
The Apollo II .exe for windows does not get flagged.
Thank you for all input.

https://www.virustotal.com/gui/file/3c9316d98efee1615e21dafcf378fb7ecd43d4ded408df4825f8e561a52b460f

Windows doesn't like mining software.  It gets flagged a lot and you have to exclude it from windows defender.  it will run fine then on a specific update they flag it.  It's from the days when viruses would load mining software to run in the background of the computer and use up resources.  I have old versions of mining software running my USB and CPU miners of other systems and a recent windows update flagged these files.  I have them running on isolated laptops and I tell defender to ignore the file as ok and not trojan.  It should isolate it out.  If you execute the defender fix then it gets deleted.

Your link gives tips to programmers for what is being detected and why with possible fixes to those detections. Some may be fixable, others may be the result of the miner software design. The programmers should sign the file and you can verify the checksum to make sure there was no additional manipulation of those files.  If there was and not a match, then I'd be suspicious and programmers should look into it.

[sopsy8t]

The core cpu is a raspberry pi

Nope! It isn't a RaspberryPi!

It is listed as "6 ARM Core CPU @ 2GHZ and 4GB of RAM" which I believe is actually an OrangePi 4!

I have a non-working USB port in my batch 1 node. Does this mean I can replace the pi in the node with a new board (OrangePi 4) - reflash and it will be fixed?

thanks.

[jstefanop]

The core cpu is a raspberry pi

Nope! It isn't a RaspberryPi!

It is listed as "6 ARM Core CPU @ 2GHZ and 4GB of RAM" which I believe is actually an OrangePi 4!

I have a non-working USB port in my batch 1 node. Does this mean I can replace the pi in the node with a new board (OrangePi 4) - reflash and it will be fixed?

thanks.

Technically yes, the boards are interchangeable between Node/USB variants and both boards have all required ports for either use case.

[aurel57]

#881423 FutureBit block! Looks to be the same one that hit a block before, #867760 also it looks like they are mining with a lot of miners thru it. Hashrate (24h) 5.1 EH/s

[mf22433]

Is there any way to fix this error without reformating the node and restarting from scratch (I am at 94% now):

2025-01-30T10:27:36Z LevelDB read failure: Corruption: block checksum mismatch: /media/nvme/Bitcoin/chainstate/938066.ldb
2025-01-30T10:27:36Z Fatal LevelDB error: Corruption: block checksum mismatch: /media/nvme/Bitcoin/chainstate/938066.ldb
2025-01-30T10:27:36Z You can use -debug=leveldb to get more complete diagnostic messages
2025-01-30T10:27:36Z Error: Error reading from database, shutting down.
2025-01-30T10:27:36Z Error reading from database: Fatal LevelDB error: Corruption: block checksum mismatch: /media/nvme/Bitcoin/chainstate/938066.ldb

[eagleye]

The chainstate is a temporary database that updates on every cycle of starting the node and it keeps a record of the blockchain status.  Forget trying to reindex.  Try to shut down and restart the node.  You will get the error but check if the  bitcoind program is running.  It takes a few minutes for bitcoind to rewrite the chainstate.  The program may run even with this error and will eventually overwrite the old corrupt data and run fine. 

More often shut down the apollo and start it up may get the download going again.  Trying to stop and start the node is less successful.  As long as bitcoind is running it will fix itself.  From experience, don't bother trying to reindex your chainstate or blockchain.  It is much easier to start a fresh blockchain download than trying to reindex.  The CPU is not fast enough.

[bubbAJoe]

#881423 FutureBit block! Looks to be the same one that hit a block before, #867760 also it looks like they are mining with a lot of miners thru it. Hashrate (24h) 5.1 EH/s

Yeah, dude clearly has some heavy hitter miners connected to his Futurebit node.  I'm 99% sure the block wasn't found by a FutureBit, but I'd also like to be 100% wrong, LOL.

[bubbAJoe]

#881423 FutureBit block! Looks to be the same one that hit a block before, #867760 also it looks like they are mining with a lot of miners thru it. Hashrate (24h) 5.1 EH/s

So they did kind of a Bitcoin-block telethon where several miners pointed their hash to this guy's Apollo node and that's how they hit a block.  Don't have the details, but it was mentioned on BitsBeTrippin youtube video just released on solo mining.

https://www.youtube.com/watch?v=ICZbOyuLHY0

[minecrusher]

The core cpu is a raspberry pi

Nope! It isn't a RaspberryPi!

It is listed as "6 ARM Core CPU @ 2GHZ and 4GB of RAM" which I believe is actually an OrangePi 4!

I have a non-working USB port in my batch 1 node. Does this mean I can replace the pi in the node with a new board (OrangePi 4) - reflash and it will be fixed?

thanks.

Technically yes, the boards are interchangeable between Node/USB variants and both boards have all required ports for either use case.

Why not use a powered USB hub if you have one working port?