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

[AloTheMax]

just got my used unit home. it booted up fine first startup, but i couldnt login so i tried the reflash-method. and now it seems it wont boot at all. the ethernet-connection lights up and flashes, but i cant seem to get any ip-address to sign in to the miner.
what am i doing wrong and what can i do to fix it?  unit has been loading for 10 minutes now.

i even tried reflashing it again, with the newest firmware available.
its a full-node package and im using my own 1600W EVGA T1 power supply.


help PLS!

//edit//

Red light on front is lighting up solid, a small green light is lights up on the blue controlboard, a red LED is lighting up right next to the SSD, and it looks like a red light is lighting up below the controlboard towards the hashboard?

Ciao Emilio1992, I also have the same problem as you for days and days and I almost went crazy trying to solve it, maybe I succeeded. Last night I wrote to Futurebit support and they replied that most likely my Apollo BTC Miner goes into temperature overheating and therefore to deactivate the mining process until the node is fully synchronized. Probably the mining process together with the download of the blockchain and the synchronization of the node in addition to an environment that is not cold but at ambient temperature (about 21 ° C) overheats our Apollo BTC too much and disconnects from the network to avoid damage from temperature or operation . In fact, when this happens I turn off the miner for about ten minutes and when I turn it back on the IP reappears and I can access it from the web dashboard. Now I have turned off the mining process and I am only synchronizing the node (I have reached 98%) when everything is synchronized I will start the mining process and see the results. However, I have already ordered two 120mm fans on amazon to be placed on the sides to cool it even more. I hope to solve bye...

Ok I can finally say that I have solved the problem and I am very happy !!! The crux of the matter was because it frequently disconnected from the router or network and went into lockdown, the IP address disappeared and I could no longer log in via the web dashboard. From a recent email from Futurebit support they advised me to first finish the synchronization of the node and blockchain download, and then start the mining process.
My Apollo Full Node has been continuously undermining for 3 days without network interruptions or overheating problems and therefore disconnections. I am very happy with this and have found the solution thanks to Futurebit support.
So I recommend to those who have problems similar to this, first to terminate the synchronization process of the entire blockchain and deactivate the mining process by holding Apollo Full Node in a not too hot environment and then when the node has finished synchronizing all the blockchain start the mining process.
Happy mining to all guys...

[crypto_curious]

So I recommend to those who have problems similar to this, first to terminate the synchronization process of the entire blockchain and deactivate the mining process by holding Apollo Full Node in a not too hot environment and then when the node has finished synchronizing all the blockchain start the mining process.

Yep, overheating of Orange Pi 4 controller is causing a lot of trouble, as we discussed earlier in the thread.

As crypto_curious said, ideally it would have a bit more space between the SBC and hashboard, at least that way you could install a slightly thicker fan for better cooling. I found it difficult to source a replacement fan in the thickness thats required (6mm) most were 10mm, which IMO wouldve been the better choice for cooling and noise levels.

Yes I'd love to see that improvement, or something similar. Just a little bit more of breathing space.. and thicker fan would fit no problem.

[Glpragma]

Hello everyone. Since the latest firmware update 0.3.2 my Apollo doesn't behave well. Before it was mining for weeks, now it remains active for three, four days and then I find it blocked, inoperative, with the steady red LED. This is very annoying, does anyone have the same problem and maybe a solution? Thank you.
D.

[jstefanop]

So I recommend to those who have problems similar to this, first to terminate the synchronization process of the entire blockchain and deactivate the mining process by holding Apollo Full Node in a not too hot environment and then when the node has finished synchronizing all the blockchain start the mining process.

Yep, overheating of Orange Pi 4 controller is causing a lot of trouble, as we discussed earlier in the thread.

As crypto_curious said, ideally it would have a bit more space between the SBC and hashboard, at least that way you could install a slightly thicker fan for better cooling. I found it difficult to source a replacement fan in the thickness thats required (6mm) most were 10mm, which IMO wouldve been the better choice for cooling and noise levels.

Yes I'd love to see that improvement, or something similar. Just a little bit more of breathing space.. and thicker fan would fit no problem.

Issue with cooling on the SBC is only relevant for 100% CPU load sustained for hours and either a hot environment or running mining past ECO. This should only happen during initial node sync and we recommend everyone to either not mine during this time or make sure its in a cool environment in eco mode.

Its not worth putting in a faster/noisier fan for a very small case/usage pattern of the device and is a trade off we intentionally made.

[Tempestblack]

Dr.J!!!!....my man...Happy New Year to you and the entire staff there at FutureBit...I have read your posts and know you are in production and cranking them puppies out...believe me so I am chomping at the bit to get my 2 new babies scheduled for shipment...but indeed if it takes a lil bit longer to make sure that the units pass muster...you know....quality control and stuff...then I rather wait an extra day or two so long as the units ship in working order and all...but yea...I am rooting for you and the team...and yea I want my two new girls...LOL...God bless y'all....Tempestblack....

[crypto_curious]

So I recommend to those who have problems similar to this, first to terminate the synchronization process of the entire blockchain and deactivate the mining process by holding Apollo Full Node in a not too hot environment and then when the node has finished synchronizing all the blockchain start the mining process.

Yep, overheating of Orange Pi 4 controller is causing a lot of trouble, as we discussed earlier in the thread.

As crypto_curious said, ideally it would have a bit more space between the SBC and hashboard, at least that way you could install a slightly thicker fan for better cooling. I found it difficult to source a replacement fan in the thickness thats required (6mm) most were 10mm, which IMO wouldve been the better choice for cooling and noise levels.

Yes I'd love to see that improvement, or something similar. Just a little bit more of breathing space.. and thicker fan would fit no problem.

Issue with cooling on the SBC is only relevant for 100% CPU load sustained for hours and either a hot environment or running mining past ECO. This should only happen during initial node sync and we recommend everyone to either not mine during this time or make sure its in a cool environment in eco mode.

Its not worth putting in a faster/noisier fan for a very small case/usage pattern of the device and is a trade off we intentionally made.

We the users, are not happy about this trade off. Please reconsider this. This trade off is preventing users from using the device as intended, as they wish, for example as fully functional desktop device (as it has been advertised to users).

[LeftLane10Under]

So I recommend to those who have problems similar to this, first to terminate the synchronization process of the entire blockchain and deactivate the mining process by holding Apollo Full Node in a not too hot environment and then when the node has finished synchronizing all the blockchain start the mining process.

Yep, overheating of Orange Pi 4 controller is causing a lot of trouble, as we discussed earlier in the thread.

As crypto_curious said, ideally it would have a bit more space between the SBC and hashboard, at least that way you could install a slightly thicker fan for better cooling. I found it difficult to source a replacement fan in the thickness thats required (6mm) most were 10mm, which IMO wouldve been the better choice for cooling and noise levels.

Yes I'd love to see that improvement, or something similar. Just a little bit more of breathing space.. and thicker fan would fit no problem.

Issue with cooling on the SBC is only relevant for 100% CPU load sustained for hours and either a hot environment or running mining past ECO. This should only happen during initial node sync and we recommend everyone to either not mine during this time or make sure its in a cool environment in eco mode.

Its not worth putting in a faster/noisier fan for a very small case/usage pattern of the device and is a trade off we intentionally made.

We the users, are not happy about this trade off. Please reconsider this. This trade off is preventing users from using the device as intended, as they wish, for example as fully functional desktop device (as it has been advertised to users).

You don’t speak for me. I’m fine with quieter performance. Short term pain for long term gain.

Also didn’t you already make this “desktop as advertised” argument and get shut down earlier in this thread? Or was it the other thread?

Edit: LMAO YES THATS YOU from October https://bitcointalk.org/index.php?topic=5340015.msg58277556#msg58277556

Dude get outta here. You also said you have no use or interest in running a full node.

[heslo]

So I recommend to those who have problems similar to this, first to terminate the synchronization process of the entire blockchain and deactivate the mining process by holding Apollo Full Node in a not too hot environment and then when the node has finished synchronizing all the blockchain start the mining process.

Yep, overheating of Orange Pi 4 controller is causing a lot of trouble, as we discussed earlier in the thread.

As crypto_curious said, ideally it would have a bit more space between the SBC and hashboard, at least that way you could install a slightly thicker fan for better cooling. I found it difficult to source a replacement fan in the thickness thats required (6mm) most were 10mm, which IMO wouldve been the better choice for cooling and noise levels.

Yes I'd love to see that improvement, or something similar. Just a little bit more of breathing space.. and thicker fan would fit no problem.

Issue with cooling on the SBC is only relevant for 100% CPU load sustained for hours and either a hot environment or running mining past ECO. This should only happen during initial node sync and we recommend everyone to either not mine during this time or make sure its in a cool environment in eco mode.

Its not worth putting in a faster/noisier fan for a very small case/usage pattern of the device and is a trade off we intentionally made.

We the users, are not happy about this trade off. Please reconsider this. This trade off is preventing users from using the device as intended, as they wish, for example as fully functional desktop device (as it has been advertised to users).

You don’t speak for me. I’m fine with quieter performance. Short term pain for long term gain.

Also didn’t you already make this “desktop as advertised” argument and get shut down earlier in this thread? Or was it the other thread?

Same here; don't put words in my mouth mate. I'm happy, it mines and it runs a node, all I need it to do. You want a full fledged PC to do everything on? Build a dedicated one

[crypto_curious]

You don’t speak for me. I’m fine with quieter performance. Short term pain for long term gain.

Also didn’t you already make this “desktop as advertised” argument and get shut down earlier in this thread? Or was it the other thread?

Edit: LMAO YES THATS YOU from October https://bitcointalk.org/index.php?topic=5340015.msg58277556#msg58277556

Dude get outta here. You also said you have no use or interest in running a full node.

And what is your problem? Yes that was me mentioning it months ago, problem with overheating is still the same. Nothing has changed. You still have users reporting today, running into problems when synchronizing node, etc. More newbie user is, bigger the problem, because they don't know what is wrong and why their device has shutdown, overheat, stop mining, stop responding, etc. Why discussing this is a problem to you?

You also said you have no use or interest in running a full node.

Sorry "dude" it wasn't me, I bought this device specifically to run node and other functions. I reformatted Apollo to use it with fully customizable headless Armbian so I can run my own services on it. Not a "desktop PC", I don't need it do do that. I just want it to work as advertised and not overheat when put under any stress.

EDIT: Thanks for quoting my post, great link. All points from October are still valid.

Same here; don't put words in my mouth mate. I'm happy, it mines and it runs a node, all I need it to do. You want a full fledged PC to do everything on? Build a dedicated one

Don't get me wrong, I love my apollo miner, no offence to Futurebit team. BUT

100% of users are affected by this problem. Majority of users will not notice, or will notice but will ignore it, or be happy about this overheat issue (like you? ). Your statement doesn't make problem go away. Problem should be addressed and/or mitigated, but not ignored (from your point of view, problem doesn't exist because you are happy with your device?).

You want a full fledged PC to do everything on? Build a dedicated one

Most useless and offtopic recommendation ever, thanks 😳😅

[heslo]

Same here; don't put words in my mouth mate. I'm happy, it mines and it runs a node, all I need it to do. You want a full fledged PC to do everything on? Build a dedicated one

Don't get me wrong, I love my apollo miner, no offence to Futurebit team. BUT

100% of users are affected by this problem. Majority of users will not notice, or will notice but will ignore it, or be happy about this overheat issue (like you? ). Your statement doesn't make problem go away. Problem should be addressed and/or mitigated, but not ignored (from your point of view, problem doesn't exist because you are happy with your device?).

You want a full fledged PC to do everything on? Build a dedicated one

Most useless and offtopic recommendation ever, thanks 😳😅

Mine doesn't overheat, I've never run into this issue and my ambient temp in the house the other day was 38 degrees celcius, mining in turbo mode. Temps were 70 odd from memory, I was happy with that.

And my recommendation was not useless or off topic. You bought a miner that self hosts a node and you're acting like you want it to do CAD drawings as well?! It's a low powered device that is fit for its use case

[crypto_curious]

And my recommendation was not useless or off topic. You bought a miner that self hosts a node and you're acting like you want it to do CAD drawings as well?! It's a low powered device that is fit for its use case

I don't want anything. Just read device description will ya
https://bitcointalk.org/index.php?topic=5340015.msg58277556#msg58277556

[Aldin1978]

With so many of us now using an Apollo for mining BTC and the fact that the box has its own node, has anyone taken the time to do a write up for us "slower" old guys that might want to take full advantage of the functions of the box as in use the node and the box together to solo mine?

Is it even possible to set up the Apollo BTC and Node to mine into itself in solo mode?

I'm mining to CKPool but wondering if I have the ability to use the Apollo to mine in my old world and not have to go to a pool.

A write-up or cheat sheet would be really welcome!

ml

I know this post is a couple months old, but in case the OP is still needing this (or others who might be looking to do the same), I was able to get my full-node unit mining my own node.  I didn't do a 'write-up' of this, and it does require some basic / intermediate Linux knowledge, but in a nutshell:

I installed ckpool - source package found here (they don't supply pre-built binaries): (https://bitbucket.org/ckolivas/ckpool/get/b8f668524835.zip) and set up a simple pool in standalone mode (without ckdb support), with my local full node (127.0.0.1:8332) as the btcd, and 127.0.0.1:3333 as the address for miners to connect.  Once I got bitcoin.conf (from the node) and ckpool.conf (from ckpool) set up so that everything was working as expected, I modified the script that starts up the node, to also start up the ckpool process.

Someone else may know a solution to this problem, but I had to replace the bitcoind binary with an earlier version 0.19.1 - this is because version 0.20.0 and later which removed the coinbaseaux flag from the GBT response, and ckpool doesn't play nice without it there (even though it isn't a required flag ...).

Then in the ApolloUI, I set up my pool as:  stratum+tcp://127.0.0.1:3333 - User and pass: <same as rpcuser and rpcpassword from bitcoin.conf>.

Everything comes up on its own when I (re)start the device -- and if you don't change the RPC username / pass from the defaults, it also remains fully integrated with the UI, though obviously you don't see anything about ckpool (since the node_start script modification I made launches ckpool in a screen session (screen -dmS ckpool), like the node and miner services do, I can pull up the running ckpool output via (as root): screen -x ckpool).  If you do change the rpcuser and rpcpassword from default, it breaks the UI - but at some point I'll probably take the time to figure out how to change the values the UI uses to connect so that I can change the RPC credentials.

Screenshots of results:

https://www.filehosting.org/file/details/976274/miner.jpg

https://www.filehosting.org/file/details/976275/node.jpg

@jstefanop : this unit has always had ~40% hardware errors since I first started it up 12/27, regardless which mining pool I used (tried ckpool, nicehash, slush, etc).  The hashrate is as advertised, so I haven't been too worried about it - but is this a cause for concern?

[jstefanop]

With so many of us now using an Apollo for mining BTC and the fact that the box has its own node, has anyone taken the time to do a write up for us "slower" old guys that might want to take full advantage of the functions of the box as in use the node and the box together to solo mine?

Is it even possible to set up the Apollo BTC and Node to mine into itself in solo mode?

I'm mining to CKPool but wondering if I have the ability to use the Apollo to mine in my old world and not have to go to a pool.

A write-up or cheat sheet would be really welcome!

ml

I know this post is a couple months old, but in case the OP is still needing this (or others who might be looking to do the same), I was able to get my full-node unit mining my own node.  I didn't do a 'write-up' of this, and it does require some basic / intermediate Linux knowledge, but in a nutshell:

I installed ckpool - source package found here (they don't supply pre-built binaries): (https://bitbucket.org/ckolivas/ckpool/get/b8f668524835.zip) and set up a simple pool in standalone mode (without ckdb support), with my local full node (127.0.0.1:8332) as the btcd, and 127.0.0.1:3333 as the address for miners to connect.  Once I got bitcoin.conf (from the node) and ckpool.conf (from ckpool) set up so that everything was working as expected, I modified the script that starts up the node, to also start up the ckpool process.

Someone else may know a solution to this problem, but I had to replace the bitcoind binary with an earlier version 0.19.1 - this is because version 0.20.0 and later which removed the coinbaseaux flag from the GBT response, and ckpool doesn't play nice without it there (even though it isn't a required flag ...).

Then in the ApolloUI, I set up my pool as:  stratum+tcp://127.0.0.1:3333 - User and pass: <same as rpcuser and rpcpassword from bitcoin.conf>.

Everything comes up on its own when I (re)start the device -- and if you don't change the RPC username / pass from the defaults, it also remains fully integrated with the UI, though obviously you don't see anything about ckpool (since the node_start script modification I made launches ckpool in a screen session (screen -dmS ckpool), like the node and miner services do, I can pull up the running ckpool output via (as root): screen -x ckpool).  If you do change the rpcuser and rpcpassword from default, it breaks the UI - but at some point I'll probably take the time to figure out how to change the values the UI uses to connect so that I can change the RPC credentials.

Screenshots of results:





@jstefanop : this unit has always had ~40% hardware errors since I first started it up 12/27, regardless which mining pool I used (tried ckpool, nicehash, slush, etc).  The hashrate is as advertised, so I haven't been too worried about it - but is this a cause for concern?

Cool write up! We are testing a similar setup with ckpool codebase for our solo mining feature as well. RPC issue is on our to-do list as well. Once more services and apps are part of the system the RPC credentials will be tied to the user password that is set during setup.

HW error issue is not a concern, very small number of units will have this issue and its because 1 or 2 bad cores out of thousands of cores that are any our Apollo are constantly spitting back bad data. The way our system is designed its hard to filter out "real" HW errors due to low voltage/overheating on the cores from "bad" HW errors due to bad cores.  As long as your rejected shares are not high, and the pool hashrate matches what you see in the dashboard your unit is operating fine.

[Aldin1978]

With so many of us now using an Apollo for mining BTC and the fact that the box has its own node, has anyone taken the time to do a write up for us "slower" old guys that might want to take full advantage of the functions of the box as in use the node and the box together to solo mine?

Is it even possible to set up the Apollo BTC and Node to mine into itself in solo mode?

I'm mining to CKPool but wondering if I have the ability to use the Apollo to mine in my old world and not have to go to a pool.

A write-up or cheat sheet would be really welcome!

ml

I know this post is a couple months old, but in case the OP is still needing this (or others who might be looking to do the same), I was able to get my full-node unit mining my own node.  I didn't do a 'write-up' of this, and it does require some basic / intermediate Linux knowledge, but in a nutshell:

I installed ckpool - source package found here (they don't supply pre-built binaries): (https://bitbucket.org/ckolivas/ckpool/get/b8f668524835.zip) and set up a simple pool in standalone mode (without ckdb support), with my local full node (127.0.0.1:8332) as the btcd, and 127.0.0.1:3333 as the address for miners to connect.  Once I got bitcoin.conf (from the node) and ckpool.conf (from ckpool) set up so that everything was working as expected, I modified the script that starts up the node, to also start up the ckpool process.

Someone else may know a solution to this problem, but I had to replace the bitcoind binary with an earlier version 0.19.1 - this is because version 0.20.0 and later which removed the coinbaseaux flag from the GBT response, and ckpool doesn't play nice without it there (even though it isn't a required flag ...).

Then in the ApolloUI, I set up my pool as:  stratum+tcp://127.0.0.1:3333 - User and pass: <same as rpcuser and rpcpassword from bitcoin.conf>.

Everything comes up on its own when I (re)start the device -- and if you don't change the RPC username / pass from the defaults, it also remains fully integrated with the UI, though obviously you don't see anything about ckpool (since the node_start script modification I made launches ckpool in a screen session (screen -dmS ckpool), like the node and miner services do, I can pull up the running ckpool output via (as root): screen -x ckpool).  If you do change the rpcuser and rpcpassword from default, it breaks the UI - but at some point I'll probably take the time to figure out how to change the values the UI uses to connect so that I can change the RPC credentials.

Screenshots of results:

https://www.filehosting.org/file/details/976274/miner.jpg

https://www.filehosting.org/file/details/976275/node.jpg

@jstefanop : this unit has always had ~40% hardware errors since I first started it up 12/27, regardless which mining pool I used (tried ckpool, nicehash, slush, etc).  The hashrate is as advertised, so I haven't been too worried about it - but is this a cause for concern?

Cool write up! We are testing a similar setup with ckpool codebase for our solo mining feature as well. RPC issue is on our to-do list as well. Once more services and apps are part of the system the RPC credentials will be tied to the user password that is set during setup.

HW error issue is not a concern, very small number of units will have this issue and its because 1 or 2 bad cores out of thousands of cores that are any our Apollo are constantly spitting back bad data. The way our system is designed its hard to filter out "real" HW errors due to low voltage/overheating on the cores from "bad" HW errors due to bad cores.  As long as your rejected shares are not high, and the pool hashrate matches what you see in the dashboard your unit is operating fine.

Thanks!  It seems very stable, got it going yesterday evening (not quite 24 hours yet), but looking good!

Lemme try those screenshots again:

https://i.postimg.cc/MK9KMsgP/miner.jpg

https://i.postimg.cc/rFVwp6ZR/node.jpg


Is there a batch 4 forthcoming?  I'd like to pick up a couple standard units to attach, but not willing to pay double on eBay ...

[Tempestblack]

Dr. J!!! my man... ...hope all is going well for you and the staff there with the shipments but I am reaching out to you for an issue with my power supply.  I have at this time one of the FutureBit power supplies powering my Node/Miner and well it had been doing just great since I got the unit back in July/August of last year....not a single hiccup thankfully...but a couple of days ago I had to rearrange where I had the miner and power supply devices physically located and was also installing a UPS/Surge protector.  So of course I went thru the process of powering down the miner and then powering down the Node for well I tend to use canned air to blow both the miner and the power supply out of dust.  It was at that moment that I noticed the Lil fan on the inside of the power supply unit was not spinning.  It alarmed me of course that the power supply unit had not failed or simply burned out from overheating for I do not know how long indeed the unit had been working without a freely spinning fan.  Turns out that 1 or 2 the Lil blades are getting caught up in the circular plastic housing part of the fan and therefore had not been letting the fan spin freely.  Well I was able to fix it temporarily and the fan, for now, is spinning freely thereby the power unit not getting possibly overheated but indeed I have to check on it constantly...Question...the Lil component fan in the power unit...what are its specs and is there a vendor whom I can purchase a replacement for it so that way I can order one and simply swap it out with the one in the power unit right now that though for the moment it is working I do not completely trust to remain as such.  Well, that is my story...sighs...lol...any info would be appreciated...and oh by the way...I am chomping at the bit even worse these days awaiting news of the shipment to come...LOL...ok to you and gang there keep up the good work... ....Tempestblack

[pro_bono]

• Do NOT hard shutdown your system while the node is running (ie press the off button on your power supply). You should always shutdown your system via the shutdown menu in the Apollo Dashboard, or via the Desktop. This will ensure your node saves the chain state properly and does not corrupt the node, or your SD card
• The node should automatically configure your router to open port 8333 via UPnP, and you should see more than 8 connections in your dashboard. If it stays on 8, this means you need to manually open the port to your Apollos IP address in your router port forwarding rules. This will help count your node as a public node, help other nodes sync, and further decentralize the Bitcoin network.

I made the mistake of performing a hard shutdown 5+ times while the node was running. Temp reading was working normally after first few boots.

Now, dashboard under Miner reads:

"There is a problem fetching system stats (Internal error)."

2.36 Th/s 0.00°C Balanced Mode. Internal temp. reads 0 degree C at very top of dashboard. Update: temperature reading operational elsewhere in system stats.

Fan seems to be working.

Front LED flashes red once per second. Seems to be mining and generating revenue according to pool account (.94 cents so far).

30 / 32 Connections  --- is this abnormally low after port forwarding?

Could someone please confirm External AND Internal Port is 8333? TCP? UDP? Or TCP+UDP? Update: Seems to be functioning on TCP w/ 8333 for both internal + external.

Bitcoin Core v22.0.0

Insights greatly appreciated.

THANK YOU.

[crypto_curious]

30 / 32 Connections  --- is this abnormally low after port forwarding?

Could someone please confirm External AND Internal Port is 8333? TCP? UDP? Or TCP+UDP? Update: Seems to be functioning on TCP w/ 8333 for both internal + external.

Anything higher than 10 means you have successfully opened the port. After each restart, bitcoind will build up network and peers will come with time. bitcoind default is 125 max connections. I think Futurebit lowered that in GUI, to 32 max. But if you have Ethernet connection and good upload, increase max number of connections back to 125, or whatever number you prefer to contribute more data into the network.

[Cornyjokester]

I have set port forwarding to the ip address of one of my futurebit btc miners and it has 10/32.  But the router won't let me forward 8333 for any other futurebit node ip address.  What am I supposed to do with my other futurebit btc full nodes if i can't use 8333 for them?  They all say 10/32.
   Or is it that after one is forwarded the other in my "subnet" works with it?

[macpilot]

@jstefanop Any chance the upcoming intel mining chip could be incorporated into the next Apolo version? not sure if there would be benefits as it may be vaporware but curious if you somehow know specs and details.

[jstefanop]

I have set port forwarding to the ip address of one of my futurebit btc miners and it has 10/32.  But the router won't let me forward 8333 for any other futurebit node ip address.  What am I supposed to do with my other futurebit btc full nodes if i can't use 8333 for them?  They all say 10/32.
   Or is it that after one is forwarded the other in my "subnet" works with it?

You can only port forward to one device in a single network. This is why more than one full node per household/network does not make sense. You can setup your other nodes at other locations  like work/another home etc.