Topic: Official FutureBit Apollo LTC Image and Support thread - page 59. (Read 49898 times)

I hit a block last night  ! Doge not LTC  10000 Doge

http://ltc.tbdice.org/ablocks.htm


"18077   2548414   2019-01-07 16:00:42   LM...N.118   confirmed   1.573M   3.088M   196.36%   0.86%"

repeat of issue with adding / changing order of pools today
on miner restart both pools were somehow set as main and active, units giving lots of hardware errors
decided to reboot but neither of my units will shutdown or reboot from the menu, you get the shutdown image but nothing happens it just keeps hashing so I had to do a hard power off/on.



might try a clean install in case anythings gone weird on the os, concerned that both units were acting the same.
I'm using MiningDutch as my failover so I'm not sure if just there's an issue with that pool and these units or the software. I do see a few complaints about it on my MLD's issuing work for old blocks, not matching coinbase etc. I've added #skipcbcheck to the url which removes the coinbase error on the MLD's and repeated this on the apollo's as well as setting the difficulty via the password field.


if you have more than one you can connect via its local ip address  

I got my FutureBit Apollo miner today, easy install/setup and now it is happily mining.

I connected to it by opening http://futurebit.local on my browser. If I add a second or third Apollo box in the same network what is the expected DNS name to us? perhaps someone who has multiple miners running already know.

Thanks !!

Sounds like an internet disconnect knocked the pool offline and it did not auto-reconnect. Simple restart will fix this.

I have seen this happen on a rare occasion and trying to investigate the root cause, but its has to do with the controller randomly locking up. Unfortunately has nothing to do with our code. We have a board level failsafe that will shut down the regulator before any damage happens, but since the fan is controlled by the MCU there is nothing we can do on the fan side, and things will get hot until the emergency shutdown triggers (which it might not in eco mode since board might not get hot enough).

Hello Everyone,

So today one of my two apollos was down on litecoinpool.org but still "online" ( Green on the workers username ) but no hashing.

I just get home the miner seemed to still hashing ( green and red light like always ) doesn't seem to don't have any problems...

So i opened the dashboard and it says miner offline... **

I don't really know what happened today ....

Ok thanks !

You don't have to worry about the discarded number,
it doesnt matter

Just wanted to share I took the PSU tip of the Dell D2 from back along in this thread.

200w brick, runs eco fine, very pleased.

£10 from Ebay. I followed this guide https://egpu.io/forums/psu-cables/us3-dell-da-2-pcie-splitter/, and used this pcie splitter off Amazon: https://amzn.to/2Rxq48x

I received my apollo Easy setup and configuration! But i have a question :

What are the "Discarded" datas? It is normal that they are more numerous than "Accepted" ?:

29091
Accepted

49670
Discarded

Regards

Looking at the content of the current sdcard image and the implementation of the fan control, there does appear to be a failure scenario that could explain what you saw happen.

The startup process of the Apollo first starts the network, followed by apollo.service and bfgminer.service. apollo.service is the UI itself and it has been configured to restart on failure. bfgminer.service on the other hand contains the hardware monitoring and fan control process (apollo_hwmon) and, after a 20 second delay, bfgminer itself is started. The problem here is that the bfgminer.service contains several processes and the init system hasn't been configured to monitor any of these for doing a restart on failure. For some reason, possibly for implementation simplicity, the fan control is that separate process instead of being part of the bfgminer driver.

I suspect that setup results in a situation that if the apollo_hwmon process dies for some reason then nothing is there to notice and restart it. Since the process is handling the pwm signal generation for the fan, this results in the fan either shutting down or getting stuck at 100% depending on what the current setting was when the process dies. With a 25% manual setting, I'd guess there's a 25% chance on getting stuck at 100% rpm and 75% for a fan shutdown (0% rpm).

The easiest fix would be to move that apollo_hwmon process to a separate systemd service that would be configured to have the same restart on failure monitoring as the UI itself has. Having the separate service would also allow to chain the bfgminer process/service as a dependency on fans having started instead of blindly assuming that after 20 seconds everything should be ok. Longer term, the better approach would most likely be having the fan control in the bfgminer process (provided by the Apollo driver) as the unit isn't producing much heat if the bfgminer process itself isn't running.

Disclaimer: this is what I can see based on what's visible in the image itself. Some of it could be wrong as for example the source code of the apollo_hwmon binary isn't available.

Eco

-Dave

What mode were you running in? Eco, Balanced or Turbo?

I have the same 15% manual setting enabled. The unstable rpm was confirmed to be a feature, not a bug:
https://bitcointalksearch.org/topic/m.48986544

I've noticed that the fan speed keeps revving up and down a little,
though I have set it at manual speed 15 %.

Fan control still needs work.
Got the alert from litecoinpool that the apollo had dropped off this morning. I could not get the the web front end, so I ignored it figuring on a crash.
The L3+ that is on the same power supply never dropped so I knew the power and internet were good.

Got in to work and fan was not spinning AND unit was about 1 billion degrees (give or take a bit) was actually hot enough to darken the thermal ink label on the controller.


Once it cooled down it seems to have come back no problem.
I now have the fan set to 25% instead of auto.

In the next revision can you have the fan fail to max speed in case of any issues?

-Dave

Hi,

I'm curently mining on multipool.us and I was wondering what would be the best diff setting for the Apollo. I tried these settings now and I'm still not sure. What do you think, what is your experience?

• Automatic: the pool sets difficulty to 65536, the hashrate seems to fluctuate a lot
• Force it to 32768
• Force it to 16384
• Lower one ?

Ok I am hoping someone can help me out.  I cannot seem to connect that Apollo to my mining pool however, the donation pool is connected perfectly.  I have connected my moonlanders to both litecoinpool and theblocksfactory and had no problem.  I cut and paste the pool address, the username and password identical to the Apollo pool dashboard and it is not connecting.

To make sure there was not a mistake on my end, I changed the password in both accounts to something very simple  and started over and manually imputed the info.  I connected my moonlanders again with no problem but the Apollo is still not working.

At this point I am at a loss because this is very a simple plug and play process.  You simply put the pool address in, then the usnername and password.  Then hit the yellow save & restart button.  The Apollo shuts down and restarts in about 30 seconds.  

My username and password are all lowercase.

Lol all that for an undefined worker 


Once I finish the full writeup I need to get up a list of all the little stupid avoidable things people have issues with 

Thanks!