Topic: Official FutureBit Apollo BTC Software/Image and Support thread - page 17. (Read 50429 times)

I know this was requested by me to be fixed in the next release. Hopefully we will see this soon!

I have miners about to be pointed from offsite locations to my apollo 2 node. Is there are way for me to see each offsite miner on the dashboard so I know if and when a minter is offline?

Right now I have 5 miners working but Only see 4 in the total pools and hashboards section.

Cheers

Much appreciated for your reply. Yes finally i will use only the custom settings.  LOW setup during Day Time (higher Temp and cost for Khw/h) and HIGH Settings during night time.
I set a crontab job to switch between these setting automatically. The only problem is that the GUI still shows the old values. (Not sure how to force a refresh)

I noticed also that increasing the Frequency (same Power) there are no changes in Speed,Watt/T,Temp etc.

Hard question to answer as your question actually creates more questions than answers. Regardless, the short answer is it's the luck of the silicon draw. In other words, it's simply all the variables involved that creates the inconsistency in the expected values. First of all, you're trying to replicate a hard-coded algorithm preassigned to accommodate all those variables when you try to do it via the custom settings. It's probably not going to happen. Maybe pretty close, but no cigar (which I think you already achieved). I have found for instance, if I do a simple reboot of the miner I will see a variation of 3-4 watts just because I restarted. Don't know why. And it will stay that way until another reboot in the future. Then it will change a little. Sometimes it's just because the fan is running at a slightly different speed. Sometimes it's because I'm pulling more power to other units on the same circuit and starving the Apollo a bit (guess). I've even noticed that some pools put more of a drag (slight) on my system than in other cases such as my own node or solo.ckpool. Then, of course, there's heat and humidity, and maybe even the alignment of the stars and moon phase (just kidding). All kidding aside, unless there's a good reason to try and replicate what the algorithm is doing I would sincerely suggest using the custom settings to your advantage in promoting higher hash-rates without overheating your units. Just my opinion but cheers anyway!

Hi, Just got also the New Apollo II.

Can someone confirm what are the ECO default values.

I saw in an older post that is Power:48 Freq:30 (-brd_ocp 48  -osc 30) but when i use these as custom i have totally different behavior.

After 10min

Power     Freq      Watt         Watts/T    Temp   Speed
48        30      173            35           62           4.97
eco   Mode      197            37           68           5.35


Thank you

Yeah, kind of annoying of course.  I ordered in April and received late July only to have to send it back after a short time.  Hopefully they rectify it right away and I can get to hashing.

Yeah, I was thinking heat problems as well but since you were running ECO it didn't really add up (unless there's intermittent fan issues / malfunctions). Oh well, I hope it all works out for you. On a side note, I've still got an overdue standard unit just sitting at the FEDX hub in Memphis now 3 days late with no updates or explanations as to why or when I'll ever see it. Three cheers for PATIENCE!

Will do.  They finally got back to me today and said it sounds like it's having an overheating issue and I'm shipping it back to them.  stinks I have to pay to ship it back but hopefully gets straightened out asap.  They said approx two weeks.

When you get this straightened out let me / us know what the cause was please. Appreciate it. Cheers!

Tried this.  When the issue happens it dissapears from the ip scanner as well.  Happened again for the 4th time last night.  Just turned it off at this point and emailed support.  Obviously I have a faulty unit so hopefully they will come through and give me a way to send it back for a fix or replacement since its only been in my home for around 30 days

If you cannot connect remotely again, try to access the miner, with a PC on the same network, as the Futurebit. If this fails, then try to ping it and last use a IP scanner to see all the devices, within your netwok.

Thank you very much for this!  I will look into each of these.  I've also emailed support, so will see what they say as well

The first thing in the "idea / guess" category would be heat - but since you're in ECO mode I doubt that's an issue unless there's an air flow problem for whatever reason. My second thought is related to a post from jstefanop back on 8/17/24 (Post #2398 & #2399) regarding a bad batch of power switches that are causing some issues on a small number of units. Perhaps that's the culprit? I also remember reading somewhere about loose cords not inserted 100% into the back of the units causing some grief. Outside of that, I'll go out on a crazy limb and say maybe check the seating on your memory cards underneath the full node unit (just a guess). Wish I had more to offer. Cheers!

Hi all - has anyone run into this issue? I've had my Apollo II for about a month.  Working fine for the first few weeks.  Over the last week and a half.  3 times the node and miner both stop.  I monitor it using remote desktop.  Unfortunately since I lose access to it when this happens I cannot reboot it from where I'm at.  When I get home I have to physically turn it off with the power switch and back on again to get it back up and running.  The first time it happened was about a week ago.  Then again yesterday and again today.  When running the miner is set to eco mode.  Any ideas?

Thank you!

When running a single hash board, my particular Apollo 2 runs an "average" of 5.5 on ECO, 7.0 on BAL, and 8.5 on TURBO. Of course, by adding two more Apollo standard units I see an "average" of 16.5 on ECO, 21.0 on BAL, and 25.5 on TURBO. Although my hash rate does vary up and down throughout the day from hour-to-hour and minute to minute, the average stays about what was stated.

Quick question. I just connected my new apollo 2 node and while its syncing I have it mining to my old node but my hashrate is around 5.3-5.5. Is it normal for it to be below 6 TH/S?

Good news! After some work and digging into the problem, I’m excited to share that I’ve developed a Python-based script to control the Apollo II miner. I faced concerns about the miner not stopping even when the mining program was closed, but Futurebit has provided the apollo-helper proprietary binary, which can put the device into a reset state where it stops any work. This way, when the miner is not mining, power usage drops to almost zero, as it should. Currently, this solution only works on Arm64 boards because the apollo-helper binary is only available for that architecture. Windows or Linux AMD64 are not yet supported. Once Futurebit releases their binary for these systems, I will be happy to update my script.

The script I’ve created monitors the temperature using a TEMPer USB thermometer and can automatically start or stop the mining process based on configurable temperature thresholds. It also supports two mining speeds: ECO and BALANCED modes, depending on the external temperature. Additionally, it can send notifications via Telegram when the miner state changes (started, stopped, or miner binary crashes) as well as hourly notifications with stats.

I’ve published the code on my GitLab, and I’m thrilled to share it with the community. I hope this will be helpful. Please check it out! 😊

https://gitlab.com/UyosDP8sQsgO/apollo-ii-temperature-control/

Thank you for your answer.
No, I run the Apollo Server as a pure network server (without keyboard, mouse and monitor).
Regarding “sudo apt update” and “sudo apt upgrade” I don't share your concerns.
As far as I have understood the support, you just should not do a distribution update, but these updates are ok (as they also contain security fixes) and can be done in addition to the Web-IF updates from Appollo.
My Apollo 2.0.5 system runs very stable even after having installed the latest Ubuntu OS updates with above commands using SSH.

To enable other BTC nodes to connect to your BTC node, you must enable port forwarding in your router to the apollo node.

Example:
Inbound rule:
Allow ANY SOURCE IP:Protocol:TCP:ANY SOURCE PORT -> APOLLO INTRANET NODE-IP:Protocol:TCP:PORT:8333

I highly advise to configure suitable internal and external firewall rules, accordingly, and place the Apollo node into a VLAN network which is separate from your normal untagged intranet LAN.

Example:
internal firewall: full isolation of apollo server from intranet network. Except access for specific admin device (allow access to web-if (port 80) and SSH (port 22)).
external firewall: allow access from any external port to apollo server tcp port 8333 only.

As Ubuntu is a very safe OS, I have no real doubt to get hacked.
However, you could consider additionally using TOR via flag in settings, to increase security.

You can try out, if your node is accessable using this link to bitnodes.io (or just check, whether your node is connected to > 11 nodes):
https://bitnodes.io/#join-the-network

\Trimmed as this got too damn long!  

I personally wouldn't leave my Apollo UI exposed to the internet. Keep it behind your firewall otherwise you're asking to get hacked.

It is my understanding (correct me if I am wrong) that the Apollo offers a Non-SSL encrypted login page via (Port 80) but I don't believe it offers a secure login connection via SSL (Port 443) through the UI to securely login.

This means if you expose Port 80 of the Apollo UI it will be available to anyone that knows your IP and worse yet when you try to connect remotely you would be sending your password over the internet in clear text. Not good by any means from a security perspective.


You'd be much better off if your router offers VPN functionality / connectivity this way you will be able to access your VPN and then your Apollo (and all other devices on your LAN) in a much more secured manner.