Official FutureBit Apollo LTC Image and Support thread

[whiteogre]

I have a new Apollo. It works great for a few days then one of two things happen.
1. The fan stops completely and start smelling. I have to unplug and plug back in. Glad I?m around when that has happened because I fear it was heating up.
2. Fan speed jumps to full speed. Can?t log in to reboot. Have to unplug etc.
These happen regularly.
Glad I?ve been around in each case. Thoughts?

What mode are you running the miner in?

This is probably related to the MCU lockup issue we know about that can happen in a rare occasion. It should be fixed in the next update we are releasing soon.

I've just had number 1 happen for the first time in several weeks. Luckily happened to check on the Apollo, fan was off, very hot indeed (painful to the touch). Switched off and on again, front light wouldn't come back on (no boot?), left overnight and is fine this morning. Obviously did overheat significantly. Is this the MCU lockup?

(I'm running on Eco, everything auto, on a 200W Dell PSU brick)

Sounds like it. Probably will cut out some features for the next release to just get some bug fixes out quickly by the end of this week and hopefully resolve this.

Since the heatsink so so efficient even with no fan spinning the PCB does not get hot enough to kick in the passive protections and shutdown the regulator...while its very hot to the touch (near boiling temps) its still not hot enough to damage anything, so dont worry if it does happen to anyone else, just shut it down and wait 20-30 min for it to cool down and restart.

Another reason why we need Minimum Fan speed to be adjustable in Auto Fan mode.

That's not really going to help in a lockup scenario. There's a process running on the MCU that's essentially constantly telling the fan to keep spinning. If that process or the MCU gets stuck then the fan simply stops spinning due to lack of instructions what to do. Without adding any new hardware, the only solution is to fix all software bugs and harden that fan controller process to stay running no matter what.

Solving that with a hardware addon (=hack) could be something like adding the cheapest Arduino (or similar) in between the MCU and the fan. That extra chip would then keep repeating the last fan setting received from the MCU and have a delayed failsafe if no new instructions are received within some defined time.

[jstefanop]

I have a new Apollo. It works great for a few days then one of two things happen.
1. The fan stops completely and start smelling. I have to unplug and plug back in. Glad I?m around when that has happened because I fear it was heating up.
2. Fan speed jumps to full speed. Can?t log in to reboot. Have to unplug etc.
These happen regularly.
Glad I?ve been around in each case. Thoughts?

What mode are you running the miner in?

This is probably related to the MCU lockup issue we know about that can happen in a rare occasion. It should be fixed in the next update we are releasing soon.

I've just had number 1 happen for the first time in several weeks. Luckily happened to check on the Apollo, fan was off, very hot indeed (painful to the touch). Switched off and on again, front light wouldn't come back on (no boot?), left overnight and is fine this morning. Obviously did overheat significantly. Is this the MCU lockup?

(I'm running on Eco, everything auto, on a 200W Dell PSU brick)

Sounds like it. Probably will cut out some features for the next release to just get some bug fixes out quickly by the end of this week and hopefully resolve this.

Since the heatsink so so efficient even with no fan spinning the PCB does not get hot enough to kick in the passive protections and shutdown the regulator...while its very hot to the touch (near boiling temps) its still not hot enough to damage anything, so dont worry if it does happen to anyone else, just shut it down and wait 20-30 min for it to cool down and restart.

Another reason why we need Minimum Fan speed to be adjustable in Auto Fan mode.

That's not really going to help in a lockup scenario. There's a process running on the MCU that's essentially constantly telling the fan to keep spinning. If that process or the MCU gets stuck then the fan simply stops spinning due to lack of instructions what to do. Without adding any new hardware, the only solution is to fix all software bugs and harden that fan controller process to stay running no matter what.

Solving that with a hardware addon (=hack) could be something like adding the cheapest Arduino (or similar) in between the MCU and the fan. That extra chip would then keep repeating the last fan setting received from the MCU and have a delayed failsafe if no new instructions are received within some defined time.

Either way it will get resolved in the next update. Tweaks to the base system should prevent the lockup altogether, and I also enabled the hardware watchdog that's present on the MCU and kept alive by the hardware monitor process. If something happens to this process it will auto-reboot the MCU. This should cover all cases.

There is another semi-hardware solution I can implement that will force the internal pullup on the fan controller high during boot, but this is not very consumer friendly since the fan will startup running full speed for a while until the hardware monitor kicks in (this will force the fan full speed if something shits on the MCU)...i might actually configure this during runtime instead and this will add another layer of protection and the fan will only be full speed for about 5 seconds during boot.

[letsdancemusic]

https://screenshots.firefox.com/xkG1VyC4KD5RxLXy/192.168.1.114   says this nothing happening on pool side
tried 2nd pool according to a nicehash user it's red marked

[crypto_curious]

https://screenshots.firefox.com/xkG1VyC4KD5RxLXy/192.168.1.114   says this nothing happening on pool side
tried 2nd pool according to a nicehash user it's red marked

What is your problem, what's the question? I don't understand you here

[A_Renaissance_Man]

Two quick questions:

1. Is the loose bit under the Apollo the WIFI-antenna?
2. When will WIFI work?

Thanks!

[philipma1957]

https://screenshots.firefox.com/xkG1VyC4KD5RxLXy/192.168.1.114   says this nothing happening on pool side
tried 2nd pool according to a nicehash user it's red marked

What is your problem, what's the question? I don't understand you here

I see you have zero shares.

You have a lot of rollover pools here is a suggestion  try just 1 pool  the one on top.

let it hash  for 30 minutes then send a screen shot.

[whiteogre]

Two quick questions:

1. Is the loose bit under the Apollo the WIFI-antenna?
2. When will WIFI work?

Thanks!

1. Yes. Don't detach it even if you don't use wifi as that would likely fry the wifi chip.

2. Unknown. The MCU board is an Orange Pi Zero and the wifi chip that comes with it appears not to be that stable with the available drivers. If you don't have the possibility for using wired ethernet then some cheap usb powered portable router/access point in client mode could be a good far more stable alternative. I suspect wifi usb sticks could work as well but based on experience in older Raspberry Pis, those can also by a little bit hit and miss until you find one that uses a chip with good support and stable driver.

[Fenboy]

try to run only MMR, no failover

Spot on, mate. It worked 

https://imgur.com/a/W2MKbxC

At least for now. Dashboard show status as "unknown", but Apollo continues to mine there. Thanks!

Yea the issue is how bfgminer handles failovers. Currently it assumes that everything its mining is the same coin (this is based from bfgminers original bitcoin origins, it was never designed to handle multiple coins of the same algorithm).

This gets pronounced when your on a multipoool, then have failover/donation configured to Litecoin. This ASIC is different from the Moonlanders and uses a midstate, so the midstate of one coin is injected into another and stuff gets confused.

Sadly bfgminer is starting to show its age, ill see if there is a short term fix, but for now if your on mutipool/rental pool make sure thats the only pool configured.

I had the exact same issue, MRR as first pool, Litecoinpool as 2nd.

Rig was rented, problems with renters pool, Apollo swapped over to 2nd pool, but never swapped back. Ended up removing 2nd pool, and just having MRR (now need to keep eye on email notifications)

[Fenboy]

I think I've solved the reason why the fan rpm doesn't sound stable even when the fan is manually set to some specific speed and have a solution to fix it.

The fan is being controlled with software generated pwm as there doesn't appear to be any hw pwm capable pins unused on the board. The software solution needs to keep a stable timing with the pwm in order for the fan to keep the same rpm. At the same time, the MCU can have a frequency of several values between 240 MHz and 1.20 GHz. By default, this works so that if there's zero load then the frequency will eventually drop to 240 MHz and when there's any load spike then the frequency jumps directly to 1.20 GHz no matter how small the actual cpu demand was. I used the following command to monitor the frequency and it's clear that it's constantly jumping between minimum and maximum even when nobody is using the dashboard:

Code:

while true ; do echo "$(date) - $(sudo cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq)" ; sleep 1 ; done

The constant cpu frequency variation makes it difficult for the software pwm to maintain exact rpm. It's close but still the variation is audible. Looking at the frequency usage stats with the "cpufreq-info" command, we can also see that the cpu is spending much time at maximum frequency:

Code:

240 MHz:42.72%, 480 MHz:24.41%, 648 MHz:0.00%, 816 MHz:0.00%, 912 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.01%, 1.10 GHz:0.01%, 1.20 GHz:32.85%  (2229569)

The solution itself is rather simple. The default behaviour is to react instantly to any processing power demand and bump the frequency to maximum. However, other behaviours are also available and switching to the one called "conservative" results in slower changes in the frequency is processing power is needed. It turns out that the demand with the current software content is so low in reality that with the "conservative" setting the frequency rarely increases resulting in the software pwm staying stable and the audible changes in the manually set fan rpm going away.

First, without saving the change, the behaviour (frequency governor) can by changed with:

Code:

sudo cpufreq-set -g conservative

If that doesn't help then the change can be reverted back with:

Code:

sudo cpufreq-set -g ondemand

Making the change permanent requires modifying /etc/default/cpufrequtils and replacing "GOVERNOR=ondemand" with "GOVERNOR=conservative". The other positive side effect is that since the higher frequencies are no longer used that often, the MCU temperature also stays a little bit lower.

With the changed governor, "cpufreq-info" now shows (after a stats reset):

Code:

cpufreq stats: 240 MHz:99.21%, 480 MHz:0.30%, 648 MHz:0.07%, 816 MHz:0.08%, 912 MHz:0.05%, 960 MHz:0.05%, 1.01 GHz:0.03%, 1.10 GHz:0.03%, 1.20 GHz:0.17%  (18182)

Hi, how do I make this change? Absolute beginners guide please 😀

[jstefanop]

Hi, how do I make this change? Absolute beginners guide please 😀

All these things will be updated on the next release that will be uploaded soon, if you don’t know how to do it you will probably cause more issues by trying to do OS Level changes yourself.

[vsc-miner]

Have the same overheating problem last night. I have two Apollo miners, the newest of them have been running for 30 hours this week and got overheated, FAN and LED in red stayed on all night but not mining and it was flaming hot until this morning. I pull power off and let it cool,

It is back up and running now. I have not changed any settings still running on the factory ECO settings. Should I leave the fan on at 25% or so all the time? any recommendations?

Thanks!

[whiteogre]

Have the same overheating problem last night. I have two Apollo miners, the newest of them have been running for 30 hours this week and got overheated, FAN and LED in red stayed on all night but not mining and it was flaming hot until this morning. I pull power off and let it cool,

It is back up and running now. I have not changed any settings still running on the factory ECO settings. Should I leave the fan on at 25% or so all the time? any recommendations?

Set the fan manually to something that can keep the miner temperature at around 60C or below. That's most likely somewhere around 15-25% in ECO mode. Then wait for the next release and upgrade to it once available.

[jstefanop]

Have the same overheating problem last night. I have two Apollo miners, the newest of them have been running for 30 hours this week and got overheated, FAN and LED in red stayed on all night but not mining and it was flaming hot until this morning. I pull power off and let it cool,

It is back up and running now. I have not changed any settings still running on the factory ECO settings. Should I leave the fan on at 25% or so all the time? any recommendations?

Set the fan manually to something that can keep the miner temperature at around 60C or below. That's most likely somewhere around 15-25% in ECO mode. Then wait for the next release and upgrade to it once available.

Yea, still have not found a root cause for this, but I'm starting to think its due to some lower quality MCUs running hotter than others. If your seeing this happen then turn your fan speed manually to at least 25% in ECO. That should keep the MCU from overheating if this is the problem.

I have 10 miners running 24/7 and overheating them purposely and non of them are getting locked up in the past two weeks, so I can't diagnose this on my end. If anyone has a unit that has done this consistently (ie not a random one off which the 3 or so people that have reported this seem to be so far) shoot me a PM.

Going and try to get the image update out tomorrow or tuesday so there is a least a built in protection for rare edge cases like this.

[vsc-miner]

After last night overheating incident. I decided to speed up my quest to find a better power supply (quiet than my current Bitmain APW3), I had the suspicion that APW3 is way too much of a PSU for these FutureBit Appollo miners, at least in terms of noise levels but potentially on power too.

I am running two Apollo miners in our family room, the home thermostat is set to 68F (~20C) on central heating so the temperature is pretty constant all day and night. This afternoon after paying a visit to Fry's electronics store I got a Corsair RM 650x PSU, figure out how to jump start the ATX mother board signal and got the whole setup going. The noise levels are not only tolerable but insanely low compared with the APW3 previous setup.  The new PSU fan barely turns on due the threshold is around 230W and even loading the two Apollo miners it has not gone over that threshold at this time yet.

I will keep monitoring the Apollo miner that got overheated and definitely report back if it happens again. Currently this Miner is running at 67C and and MCU at 63C, sometimes the MCU temperature is higher than the sensor of the miner shows. The first Apollo miner I got is running cooler 65C and MCU 58C and I have not seen anytime when its MCU temperature is higher than the miner sensor, so for some reason my newest Miner MCU is running nominally warmer than the oldest one. If helps I can send the serial number on the boards so you guys can check on vendor's part batches.

I am hoping to get all my power and LAN setup work completed by end of this week and move the miners to a definitely cooler place, the garage should be between 32F and 40F, guess that will help with keeping the miners temperature pretty low, hope running close to Zero C is not going to be a problem.

I will check for the firmware upgrade!! Thanks everyone!
https://drive.google.com/file/d/0B59OjOFQHO2JaDFqM0JKQ01JdVVHNVVlcmJpckFDYXEzdUZz/view?usp=sharing

[philipma1957]

After last night overheating incident. I decided to speed up my quest to find a better power supply (quiet than my current Bitmain APW3), I had the suspicion that APW3 is way too much of a PSU for these FutureBit Appollo miners, at least in terms of noise levels but potentially on power too.

I am running two Apollo miners in our family room, the home thermostat is set to 68F (~20C) on central heating so the temperature is pretty constant all day and night. This afternoon after paying a visit to Fry's electronics store I got a Corsair RM 650x PSU, figure out how to jump start the ATX mother board signal and got the whole setup going. The noise levels are not only tolerable but insanely low compared with the APW3 previous setup.  The new PSU fan barely turns on due the threshold is around 230W and even loading the two Apollo miners it has not gone over that threshold at this time yet.

I will keep monitoring the Apollo miner that got overheated and definitely report back if it happens again. Currently this Miner is running at 67C and and MCU at 63C, sometimes the MCU temperature is higher than the sensor of the miner shows. The first Apollo miner I got is running cooler 65C and MCU 58C and I have not seen anytime when its MCU temperature is higher than the miner sensor, so for some reason my newest Miner MCU is running nominally warmer than the oldest one. If helps I can send the serial number on the boards so you guys can check on vendor's part batches.

I am hoping to get all my power and LAN setup work completed by end of this week and move the miners to a definitely cooler place, the garage should be between 32F and 40F, guess that will help with keeping the miners temperature pretty low, hope running close to Zero C is not going to be a problem.

I will check for the firmware upgrade!! Thanks everyone!

Is that pet an orange tabby?
or a golden retriever?

fixed image yours was too big.
nice neat setup BTW

[roudaille]

Hiya,

miner stopped 2 times in 36h with no option than hard restart of Apollo. Miner restart nor reboot system in GUI make miner go back to work.
Any indication in syslog about miner failure?

[whiteogre]

Hiya,

miner stopped 2 times in 36h with no option than hard restart of Apollo. Miner restart nor reboot system in GUI make miner go back to work.
Any indication in syslog about miner failure?

The syslog is gone if you end up needing to power cycle the Apollo in order to get it rebooted or responding again. The logs are stored in ram and only synced back to sd card if the shutdown is graceful. If the error situation is caused by something the kernel sees then some information is likely to end up in the log. However, thermal information isn't being logged.

[Turocik]

7 hours do download the apolo_final.img.zip? any mirror available? just received 2 units and i don't want to wait, bruuu

[Fu Ren]

Hi everybody

I have been mining non-stop 15+ days in a row with the following setup:
PSU corsair CS750M, powering up two Apollo units working in ballanced mode, all the other values set in auto (default) and via ethernet LAN.
I am very satisfied with their simple setup and robustness (restart and mine again in case of power off etc).
A few days ago my 3rd Apollo unit arrived, this one is not for me but it's a gift for a friend of mine who has an absolutely non-technical soul so it has to work unattended, forever
I bought a brand new PSU, this time a smaller 450 W corsair VS450 and prepared the initial setup as before but with only one unit attached.
To my surprise, afterwaiting a few seconds for the initial system load and get it reg/green blinking, the PSU shuts off.
I suspected a power surge or something coming from the 3rd Apollo.
The shut off happens after doing the full load and not before.
To start isolating the problem my workaround was using my former rig with the older, bigger PSU feeding all three boxes and let it run overnight. The whole system went on mining whitout any problems.
When I did further crossovers - e.g. using one of the older units with the new 450w PSU, the sudden shut off happens again so it seems that it is not something from a specific miner - unless I'm wrong of course.
I judged too unlucky that the corsair PSU could be responsible of the problem as it's a quality brand.
But the issue is driving me bonkers. I do not know how to go on.
Atm I was about to order a PSU replacement but I'd like to share with you here in case I'm missing something or there is a known incompatibility or other issues I may have oversighted before returning the 450w psu to the shop.

Your ideas will be much appreciated - Thanks in advance!

[dwood443]

Hi everybody

I have been mining non-stop 15+ days in a row with the following setup:
PSU corsair CS750M, powering up two Apollo units working in ballanced mode, all the other values set in auto (default) and via ethernet LAN.
I am very satisfied with their simple setup and robustness (restart and mine again in case of power off etc).
A few days ago my 3rd Apollo unit arrived, this one is not for me but it's a gift for a friend of mine who has an absolutely non-technical soul so it has to work unattended, forever
I bought a brand new PSU, this time a smaller 450 W corsair VS450 and prepared the initial setup as before but with only one unit attached.
To my surprise, afterwaiting a few seconds for the initial system load and get it reg/green blinking, the PSU shuts off.
I suspected a power surge or something coming from the 3rd Apollo.
The shut off happens after doing the full load and not before.
To start isolating the problem my workaround was using my former rig with the older, bigger PSU feeding all three boxes and let it run overnight. The whole system went on mining whitout any problems.
When I did further crossovers - e.g. using one of the older units with the new 450w PSU, the sudden shut off happens again so it seems that it is not something from a specific miner - unless I'm wrong of course.
I judged too unlucky that the corsair PSU could be responsible of the problem as it's a quality brand.
But the issue is driving me bonkers. I do not know how to go on.
Atm I was about to order a PSU replacement but I'd like to share with you here in case I'm missing something or there is a known incompatibility or other issues I may have oversighted before returning the 450w psu to the shop.

Your ideas will be much appreciated - Thanks in advance!

Since the first two have been working just fine swap the newest one with one of the older units and power supply. And for fun move one of your older apollos to the new power supply