Official FutureBit Apollo BTC Software/Image and Support thread - page 12.

BrokenTractor

newbie

Activity: 10

Merit: 0

Quote from: MakerAZ on November 19, 2024, 03:18:44 PM

Quote from: PennyBit on November 19, 2024, 10:31:06 AM

Basically, you have three options:

1) Wait. It will eventually get to 32, but for how long is anybody's guess. Maybe a minute, maybe more, maybe less.
2) Increase your Max Connections if you want more than 31/32. However, I've seen that it will just as often stay one under even then: 37/38 - 41/42, etc.
3) Go to https://bitnodes.io/ and find some juicy nodes to add to your list using the addnode=IPADDRESS:8333 command. I've found this will usually max out my connection choice: 32/32 - 42/42, etc.

Cheers!

Thank you for response. However, I am ok with the number of outgoing connection. My issue is that there is NO incomming connections, so the numer 32 is grayed out. How can I make sure that I there are incoming connections?

The default Outbound connections a Bitcoin Core node will make is 10, sometimes 11. This is hard coded into the application. You can force it a little higher with the addnodes command.
All the rest of the connections you have are Inbound connections.
31/32 means you have 10 Outbound and 21 Inbound connections.

bubbAJoe

newbie

Activity: 68

Merit: 0

Quote from: MakerAZ on November 19, 2024, 09:47:30 AM

I am sure I do not have inbound connections, what should I do?

What makes you sure of no inbound connections? I assumed that all connections are inbound and outbound.

MakerAZ

jr. member

Activity: 27

Merit: 5

Quote from: PennyBit on November 19, 2024, 10:31:06 AM

Basically, you have three options:

1) Wait. It will eventually get to 32, but for how long is anybody's guess. Maybe a minute, maybe more, maybe less.
2) Increase your Max Connections if you want more than 31/32. However, I've seen that it will just as often stay one under even then: 37/38 - 41/42, etc.
3) Go to https://bitnodes.io/ and find some juicy nodes to add to your list using the addnode=IPADDRESS:8333 command. I've found this will usually max out my connection choice: 32/32 - 42/42, etc.

Cheers!

Thank you for response. However, I am ok with the number of outgoing connection. My issue is that there is NO incomming connections, so the numer 32 is grayed out. How can I make sure that I there are incoming connections?

PennyBit

jr. member

Activity: 95

Merit: 7

Quote from: MakerAZ on November 19, 2024, 09:47:30 AM

My Node shows 31/32 Connections. With number 31 in bold, but number 32 is grayed out.
I have confirmed with portchecker.co that my 8333 port is open. My node is synced months ago. I have also added port forwarding to my router.
I am sure I do not have inbound connections, what should I do?

Basically, you have three options:

1) Wait. It will eventually get to 32, but for how long is anybody's guess. Maybe a minute, maybe more, maybe less.
2) Increase your Max Connections if you want more than 31/32. However, I've seen that it will just as often stay one under even then: 37/38 - 41/42, etc.
3) Go to https://bitnodes.io/ and find some juicy nodes to add to your list using the addnode=IPADDRESS:8333 command. I've found this will usually max out my connection choice: 32/32 - 42/42, etc.

Cheers!

MakerAZ

jr. member

Activity: 27

Merit: 5

My Node shows 31/32 Connections. With number 31 in bold, but number 32 is grayed out.
I have confirmed with portchecker.co that my 8333 port is open. My node is synced months ago. I have also added port forwarding to my router.
I am sure I do not have inbound connections, what should I do?

eagleye

newbie

Activity: 104

Merit: 0

Quote from: DoofyWops on November 18, 2024, 04:27:28 PM

Has anyone run into an issue where their mouse just refuses to click on anything after running for days?

I've had this continuously happen since before version 2.x and it still happens in 2.x. I can move the mouse around just fine, but I none of my clicks register. I can't click on desktop items, I can't click on the browser window or open new tabs to change focus. My keyboard inputs also don't work. It's weird that my mouse cursor moves around the screen but clicks aren't registering. My only option is to hard power off my unit and turn it back on. This usually happens after running for a number of days.

Yup. Your not alone. My best way to minimize it from happening is to keep minimal processes running on the Raspberry PI linux interface. Only the node, the miner status monitor and a couple of log monitor windows showing me the node report and the miner status. no browser window open. Backup UPS with line conditioning.

Sometimes, I've been able access the GUI remotely while the mouse and keyboard were frozen and shut down the miner and node exit and do a restart which fixed it. Keep an eye on heat and fan speed, which tells you if its running hot.

i'm on v2.0.5

I have not yet investigated the linux logs after a crash like this.

PennyBit

jr. member

Activity: 95

Merit: 7

Quote from: aurel57 on November 18, 2024, 07:31:59 PM

Quote from: bubbAJoe on November 18, 2024, 04:58:06 PM

Well, silly me. I didn't know you could purchase directly from FutureBit so I bought an Apollo II 1TB from BitCoinMerch.

Sam from BitCoinMerch just informed me that there is nothing they will do about my ded Apollo II because it's 3 days out of their 30-day warranty. Yes, 3 days. Delivered on Oct 15, went ded on Nov 17.

So word to the wise, think twice before buying from a place like BitCoinMerch that only offers a 30-day warranty.

I'm hoping for mercy from FutureBit. I filled out their support form yesterday, but last time I did that (to ask a setup clarification), it took them 7-days to respond.

If FutureBit won't help me, I'm out ~ $1200 and now have a stylish paper weight.

In the meantime, BitCoinMerch won't be getting any more of my business.

Did you buy it with a credit card? If so file a claim/charge back against BitCoinMerch.

If FutureBit is no help a VO meter is your best friend to check the PSU and the switch which was mentioned to be a problem.

@bubbAJoe
Well, if you don't get satisfaction from Futurebit or your CC company, and you also decide to not and try to fix it yourself, you could always sell it at a loss for parts. I for one would be willing to pay an insultingly low price for your misfortune as I'm sure I could dissect it over time to feed my needs.

Cheers!

aurel57

legendary

Activity: 1316

Merit: 1001

Quote from: bubbAJoe on November 18, 2024, 04:58:06 PM

Well, silly me. I didn't know you could purchase directly from FutureBit so I bought an Apollo II 1TB from BitCoinMerch.

Sam from BitCoinMerch just informed me that there is nothing they will do about my ded Apollo II because it's 3 days out of their 30-day warranty. Yes, 3 days. Delivered on Oct 15, went ded on Nov 17.

So word to the wise, think twice before buying from a place like BitCoinMerch that only offers a 30-day warranty.

I'm hoping for mercy from FutureBit. I filled out their support form yesterday, but last time I did that (to ask a setup clarification), it took them 7-days to respond.

If FutureBit won't help me, I'm out ~ $1200 and now have a stylish paper weight.

In the meantime, BitCoinMerch won't be getting any more of my business.

Did you buy it with a credit card? If so file a claim/charge back against BitCoinMerch.

If FutureBit is no help a VO meter is your best friend to check the PSU and the switch which was mentioned to be a problem.

PennyBit

jr. member

Activity: 95

Merit: 7

Quote from: bubbAJoe on November 18, 2024, 04:58:06 PM

Well, silly me. I didn't know you could purchase directly from FutureBit so I bought an Apollo II 1TB from BitCoinMerch.

Sam from BitCoinMerch just informed me that there is nothing they will do about my ded Apollo II because it's 3 days out of their 30-day warranty. Yes, 3 days. Delivered on Oct 15, went ded on Nov 17.

So word to the wise, think twice before buying from a place like BitCoinMerch that only offers a 30-day warranty.

I'm hoping for mercy from FutureBit. I filled out their support form yesterday, but last time I did that (to ask a setup clarification), it took them 7-days to respond.

If FutureBit won't help me, I'm out ~ $1200 and now have a stylish paper weight.

In the meantime, BitCoinMerch won't be getting any more of my business.

I feel your pain. BitCoinMerch stopped getting my business some time ago for many reason, all beyond the scope of this topic. Good luck!

Cheers!

bubbAJoe

newbie

Activity: 68

Merit: 0

Well, silly me. I didn't know you could purchase directly from FutureBit so I bought an Apollo II 1TB from BitCoinMerch.

Sam from BitCoinMerch just informed me that there is nothing they will do about my ded Apollo II because it's 3 days out of their 30-day warranty. Yes, 3 days. Delivered on Oct 15, went ded on Nov 17.

So word to the wise, think twice before buying from a place like BitCoinMerch that only offers a 30-day warranty.

I'm hoping for mercy from FutureBit. I filled out their support form yesterday, but last time I did that (to ask a setup clarification), it took them 7-days to respond.

If FutureBit won't help me, I'm out ~ $1200 and now have a stylish paper weight.

In the meantime, BitCoinMerch won't be getting any more of my business.

DoofyWops

newbie

Activity: 11

Merit: 0

Has anyone run into an issue where their mouse just refuses to click on anything after running for days?

I've had this continuously happen since before version 2.x and it still happens in 2.x. I can move the mouse around just fine, but I none of my clicks register. I can't click on desktop items, I can't click on the browser window or open new tabs to change focus. My keyboard inputs also don't work. It's weird that my mouse cursor moves around the screen but clicks aren't registering. My only option is to hard power off my unit and turn it back on. This usually happens after running for a number of days.

PennyBit

jr. member

Activity: 95

Merit: 7

Quote from: aurel57 on November 17, 2024, 08:22:03 PM

Quote from: PennyBit on November 17, 2024, 08:11:48 PM

Quote from: PennyBit on November 07, 2024, 09:55:56 AM

@ Any Apollo II Gurus,

I have a question about what should have been a simple configuration but it stumped me nonetheless . . .

Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .

Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username: ) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .

Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?

Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?

Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?

Cheers!

Has anyone come up with any ideas on the above issues? How about you jstefanop? Am I overlooking something simple?

Cheers!

I am not sure if this helps but I have 2 Avalon miners pointed to my Apollo node and I use different wallet addresses for each miner, so the solo miner page shows each miner separate with its best share and hash rate.

Thanks for the reply. Yes, by adding different wallet addresses for each miner you are actually adding different "users" to your Apollo pool and so the "User" count will go up accordingly, and it will also display a numeric total of "workers". However, in our case of being mostly "small home farms" this process is certainly the exception and not the rule. We can't be expected to create wallet addresses for each and every miner we want designated as a "worker" on our node just so we can monitor them. And in fact, I do believe at one point (possibly on v2.0.4) you could add a "worker" by using "same_wallet_address.worker" and each would display separately on the Solo Mining interface listing as a single User. See link for example image: https://ibb.co/THcqhHk

Also, I'm still trying to figure out why I have to use "stratum+tcp://" in front of the local IP on the Apollos I'm using to point at the full node: "stratum+tcp://192.xxx.x.x:3333" in the required pool URL field. I don't have to do this on any other miner I use to point at the Apollo full node as I can simply use the IP "192.xxx.x.x:3333" in the required pool URL field.

Cheers!

shaotai

newbie

Activity: 7

Merit: 2

Quote from: bubbAJoe on November 18, 2024, 12:22:27 AM

Well, less than 30 days and this POS is ded. WTF? Apollo II, 1 TB. Came home and it was off. Won't power back on. Unplugged, let it sit, plugged it back in, nothing. Any ideas?

There was a batch of miners with a bad power switch. You might need to flip/jiggle it to get it to work. I actually opened my unit up and bypassed the switch, so it feeds power directly from the plug into the PSU.
But they'll replace the switch if you send it back.

heslo

legendary

Activity: 1235

Merit: 1202

Yeah sounds like PSU to me

aurel57

legendary

Activity: 1316

Merit: 1001

Quote from: bubbAJoe on November 18, 2024, 12:22:27 AM

Well, less than 30 days and this POS is ded. WTF? Apollo II, 1 TB. Came home and it was off. Won't power back on. Unplugged, let it sit, plugged it back in, nothing. Any ideas?

I wonder if the PSU went out? Should be covered under warranty

bubbAJoe

newbie

Activity: 68

Merit: 0

Well, less than 30 days and this POS is ded. WTF? Apollo II, 1 TB. Came home and it was off. Won't power back on. Unplugged, let it sit, plugged it back in, nothing. Any ideas?

aurel57

legendary

Activity: 1316

Merit: 1001

Quote from: PennyBit on November 17, 2024, 08:11:48 PM

Quote from: PennyBit on November 07, 2024, 09:55:56 AM

@ Any Apollo II Gurus,

I have a question about what should have been a simple configuration but it stumped me nonetheless . . .

Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .

Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username: ) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .

Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?

Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?

Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?

Cheers!

Has anyone come up with any ideas on the above issues? How about you jstefanop? Am I overlooking something simple?

Cheers!

I am not sure if this helps but I have 2 Avalon miners pointed to my Apollo node and I use different wallet addresses for each miner, so the solo miner page shows each miner separate with its best share and hash rate.

PennyBit

jr. member

Activity: 95

Merit: 7

Quote from: PennyBit on November 07, 2024, 09:55:56 AM

@ Any Apollo II Gurus,

I have a question about what should have been a simple configuration but it stumped me nonetheless . . .

Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .

Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username: ) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .

Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?

Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?

Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?

Cheers!

Has anyone come up with any ideas on the above issues? How about you jstefanop? Am I overlooking something simple?

Cheers!

Poker8

newbie

Activity: 8

Merit: 0

Quote from: eagleye on November 15, 2024, 07:25:45 AM

Quote from: Poker8 on November 15, 2024, 06:19:00 AM

Quote from: eagleye on November 10, 2024, 07:23:15 PM

samsung pro plus sdxc 128gb was on sale at the local BB store.
180 mb/sec read 130 mb/sec write
I was looking for any new memory card with video grade speed microsdxc.

I picked up the same micro card mentioned. Thursday. I have a PC with two SD card slots. What program did you use to clone the old card to the new please?

follow the futurebit instructions online.
https://www.futurebit.io/flashing-sd-card

It went smooth sailing!! I made sure to back up the sittings first. After flashing the new microSD card to the firmware and changing it, I just restored the settings and a few minutes later was back up to 32/32 connections.

aurel57

legendary

Activity: 1316

Merit: 1001

Can you check the node on bitnodes.io? I tried every address config I could think of, and it keeps saying not a valid address?

edit: I got it and it shows up

It's strange as I can not access bitnodes.io from my network that I am running the apollo node on. I get a not authorize with my IP address. So i had to use my cell phone with the wifi turned off and enter my IP address (the ID not authorized) and it says my futurebit apollo node is found and working.

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