Can I point the FutureBit Apollo to a testnet mining pool or solo testnet mine?
I tried pointed it to a local Public Pool instance that's sitting on a testnet Bitcoin Core, but the FutureBit Apollo shows the pool as inactive (I even tried rebooting the futurebit).
Do I also need to update the FutureBit bitcoin.conf to testnet=1 and reboot--I would have thought the pool is doing the work of the testnet node behind the scenes...
the UI is not setup for testnet, with the launch of Apollo OS 2 you'll be able to switch to test net to test your solo mining setup (not on initial release but its in the works for a . release) |
|
|
|
Hi, My Apollo 1 BTC Full node suddenly stopped running with no changes made on my side. Only the cooling fan was running at high speed with no LED's or lights on for the board or the NIC. Successfully flashed a new SD card with the latest image but NO change.....  It will not boot and no lights are coming on. Only the cooling fan. Is there ANY after sales support for the Apollo's? Or do I just own an expensive paperweight at this point? Thanks! We dont really monitor this forum anymore...all support is doing through email on the site, just either reply to your order email or reach out via contact form. Also In the process of revamping our support site on a real support platform + knowlegebase...hope to have all that done after which ship out the initial Apollo II's |
|
|
|
Been trying to fight this, but it's a shared codebase we co-maintain and we are still under NDA. The 14nm IC is essentially "EOL" so hopefully we will be able to push to open source the firmware.
The 14nm IC is the one in the original Apollo? That would be ideal. Looking forward to your update regarding this. Updated Apollo-Miner binaries are in the works for the Apollo 2 release in the coming weeks.
Are there going to be any new miner binaries updates for the original Apollo or just for the Apollo 2? Yes 14nm was the regional and 5nm is the Apollo II Both binaries will be updated with a bunch of fixes and updates (major fix is the device now powers down when there is no active internet connection). |
|
|
|
@jstefanop
The noise level for the ECO mode [less than 40 dba] is good for home miners, but I'm curious to know what the noise levels are on the TURBO mode [especially for using custom settings to get it up to 11 TH/s].
It's a 7k RPM fan and Turbo mode ~9-10TH sits at around 55dB @5-6kRPM depending on local environment. If you max it out you'll max out the RPMs and will prob be over 60db. We left a lot overhead on the original Apollo BTC (and mostly limited by the 6 Pin power connectors). Now that we eliminated that with internal PSU and high gauge internal connections the limitation is cooling on the high end and noise levels are much louder but wanted to give everyone the option to take full advantage of the ASICs especially in winter/heating conditions. In short turbo mode will live up to its name this time so dont expect to be able to run it in your bedroom. I would say up to 8TH or so is doable in most room settings based on my personal testing. |
|
|
|
We have relationships with the major pools and will bootstrap all solo nodes directly to them. Any block found by a futurebit solo miner will propagate to the major pools first before the rest of the network.
So if you are only selling a total of 50 of these, that 'may' be possible. If you are selling more than 100 of them, it's not possible. Bitcoin wont allow 100's of connections by default since that would cause dramatic network performance issues. No pool in their right mind would allow that either. If instead you said you setup a transaction/block distribution network like bluematt used to run, for all these apollos, then yes that would be possible. However, without that, it's not possible what you said. Our CPU is pretty fast as well and block creation is not a bottle neck.
It is a bottleneck on every CPU. The question that matters is how long it takes. e.g. does it include the CPU instructions to dramatically speed it up? (no it doesn't) Can it average block template generation well under 100ms? (no) Also a valid block is a valid block, even if it shows up seconds late as long as no other block is found within those few seconds it will be included. 10 min block times were created for reasons like this where even small miners running regular computers can still participate at base layer...
Um, nope, seconds late is too late. It dramatically increases the chances of an orphan. Orphans still happen with the large pools every so often, they just don't tell anyone. Since I have a world wide distribution of nodes and I track/report the block submissions/reorgs that happen in my monitoring, I can see them when they happen. If the blocks generated by these nodes all say they are solo futurebit nodes, then that will be interesting to see what actually happens ... Yes we are in the process of creating a few regional supernodes that are all connected to major pools, and those nodes are connected to our backend infrastructure that will send a block notify to every single solo miner that is opted in within milliseconds of a valid block detected. Backend is a propriety network that bypasses the p2p bitcoin network similar to what all major pools use among themselves. Regardless you are still exaggerating the chances of an orphaned block even on the normal p2p network. There are 600 seconds within a block, lets say you are on a slow network and broadcast hits the major pools 6 seconds late, thats just a 1% chance someone will find another block before you (ie if EVERYONE solo mining has a slow connection, for ever 100 solo blocks found one will be extremely unlucky and get their block orphaned). If you really want to get into the meat of the matter and the type of research I do to come up with the systems we do you can read these research publications for a deep dive on the topic: https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/bitcoin-delay#:~:text=The%20median%20time%20until%20a,not%20yet%20received%20the%20block.https://www.researchgate.net/publication/363879722_Analysis_of_segregated_witness_implementation_for_increasing_efficiency_and_security_of_the_Bitcoin_cryptocurrencyMean block propagation times were on the order of 6 seconds in the early days (2013 when the first article was published), due to more efficient core upgrades/computational increase/network bandwidth increases the mean has come down to around 2 seconds. For everyday users trying to secure the network a .333% chance of orphaning a block compared to lets say major pools of .1% wont matter at the end of the day (and im not discounting the fact that it will matter HORRIBLY for that one person that will find a solo block after mining solo for years and it ends up orphaning but that is the nature of the bitcoin network and the risk solo miners take). |
|
|
|
~snip~
I like the product. Bring mining back to small people, decentralized, quiet etc. Would be happy to support the project and preorder.
But for sure I will not buy a closed source miner, which has never shown that it can find blocks.
Especially not if it is to be used for solomining. (Whether this is right for the target group "are first time miners" is another question.)
I really don't see any understandable reason not to publish the code.
If I could I would. The backend software runs Exahashes worth of hashrate, and finds BTC blocks everyday. Of course you have to take my word for it, and I wish you didn't but I think I have built enough reputation around here that im not some bad actor. Unfortunately to be able to provide a product like this I had to make some compromises I did not want, but we weighed those to be worth being able to get a product like this out to market. Of course the more successful this product is, the less compromises we have to make...would love to port the firmware over to cgminer and hopefully we can get there soon. We are now in 2024, almost three years after this statement was made. Apollos have been sold successfully over these years, and a new Apollo II has been recently announced. You could argue that the product has been very successful. Given that you now can make less compromises, will it be possible to have an open source version of the Apollo miner? Apollo BTC Standard Software/InstructionsIf your purchased an Apollo BTC Standard USB controlled version please find the software binaries for your system and instructions below: https://github.com/jstefanop/Apollo-Miner-Binaries/releases/This is the ONLY place you should download these binaries from. If that changes this post will be updated. Detailed instructions are on the GitHub and inside the start scripts. As noted in the pre-order this is command-line based software and only intended for more advanced users. Support for the software is limited and initial binaries are for Windows and 64 Bit x86 and ARM based Linux systems. This software is only for users that do not have a Full Package/Node version. Please follow the instructions above in the first post on how to hook up your standard unit to your Apollo Full Package unit for a plug and play experience. The last official binaries were published in 2021 (Apollo-Miner v1.1) It would be really handy to have an open source version of this, or at a minimum have a new binary after all these years. Been trying to fight this, but it's a shared codebase we co-maintain and we are still under NDA. The 14nm IC is essentially "EOL" so hopefully we will be able to push to open source the firmware. Updated Apollo-Miner binaries are in the works for the Apollo 2 release in the coming weeks. |
|
|
|
@jstefanop how 'off the shelf' are the fans?
From the USB sticks you used to sell and the LTC Apollo and the BTC Apollo I have wound up replacing just about every fan over the years.
Probably just bad luck on my end, I don't think the office is THAT dusty, but are the fan(s) in these user replaceable and easily sourceable?
-Dave
It's a custom 80x35mm 7k RPM PWM fan. Its a much more beefier fan that the original Apollo BTC and should last a pretty long time if your running in Eco/Balanced mode...fan runs at about 5-6k RPM in turbo but no where near max. |
|
|
|
Great, giving everyone the chance to lose blocks with ck's solo code, like he does. https://bitcointalk.org/index.php?topic=789369.msg61755036#msg617550365 so far, though if anyone found a block during his most recent problem where the solo ckpool kept going for a while, while bitcoin had stopped updating, that would have been another ck block lost ... At least be sure to point out to your buyers, that you are selling something with a much higher chance of losing a block due to being an orphan, unless they replace the tiny hardware in it with a fast CPU to do fast bitcoin block work changes, and add a distribution of high performance nodes around the world so their blocks are actually seen and not show up seconds late and thus ignored by ALL the pools. Went to extra lengths to discourage anyone from solo mining directly on the device unless they understand the limitations and risks, they can't enable it without pressing a big red button. With that being said con has fixed all the bugs you mentioned and we have ensured solo miners have risks mitigated as much as possible compared to the big guys. We have relationships with the major pools and will bootstrap all solo nodes directly to them. Any block found by a futurebit solo miner will propagate to the major pools first before the rest of the network. Our CPU is pretty fast as well and block creation is not a bottle neck. Also a valid block is a valid block, even if it shows up seconds late as long as no other block is found within those few seconds it will be included. 10 min block times were created for reasons like this where even small miners running regular computers can still participate at base layer... |
|
|
|
 Keeping up with tradition I have to make an announcement post here even though im sure most of you have already heard the news! www.futurebit.ioProduct #5 and the one I have been trying to build since the start. This one probably took a few years off my life, and is about 6 months late due to needing to redesign it not once but 3 times. 5nm ASICs are no joke. As with everything we do we dont announce or ship until we know we can make them and they are ready. This is a first of many for Futurebit, first time we have nearly caught up to the latest node, first time we have integrated a PSU directly in the box for a completely plug and play and seamless experience, first time we have created a completely in house thermal system capable of cooling 400 watts in nearly the same volume as Gen 1, and a first for creating a modern mass producible aluminum case and injection molded parts. One of the biggest bottlenecks with the Apollo BTC design was the sheet metal case that took forever to make, and with these have already produced thousands of cases and are just waiting on our thermal system and PCBs. Should have everything in by end of December and start shipping the Founders Edition in January. One of the biggest announcements is our revamped OS thats finally releasing the Solo mining feature everyone has been waiting for, and the OS will be released on the original Apollo BTC first in hopefully about a month. We hope the Apollo II launch finally gives us an opportunity to really focus on software this time around, which we never really had the resources for after the Apollo BTC launch. The hardware has finally caught up to where it needs to be, but software needs a lot of work to make it a seamless experience for people outside of this forum. We will also be partnering with Lukes pool and offering a one click BTC address setup, and working with them to finally enable lightning payouts for small miners like the Apollo and others, that will finally end the nearly year long payouts on some other pools (FYI we also got braiins pool to reduce their minimum no fee payout to .005 BTC which is half of what it was). Im sure many of you have noticed but our efforts and others in the small miner space are finally paying off and people are taking notice. People are starting to understand the importance of self-mining no matter how small, and as censorship attacks mount on the Bitcoin network this will be more important than ever. Can't wait for the first solo block to be mined directly on an Apollo device after we launch the new OS, it will truly be a dawn of a new era for Bitcoin. |
|
|
|
Hi Everyone. Just received and setup my Apollo Full Node miner. Its running fine, and connected to the pool but the whole OS will freeze after about 45-60 minutes. No mouse control, no keyboard input. The red light on the Apollo is still blinking, but it doesn't connect to the pool anymore, no hashing being reported. The only way to get it back is to flip the switch off, and then flip it back on. It freezes even if the miner is off, and yes its still syncing the blockchain, but if its going to keep freezing even without the miner running its going to take more than 48 hours to sync this blockchain. Its not hot to the touch really, but with the miner on its temp is about 76 C.
Any ideas on why this would be freezing and what can be done to fix it?
I think I may have figured it out. It appears that the thermal/temp sensor was flopping around inside the case, as in it was just dangling near the bottom, so it wasn't taking proper readings of the temps. I took off the right side panel, and sort of wedge it in as best as possible next to the plate that the CPU heatsink sits on. Not really sure if that is where it goes or not, but so far the miner has been running without issues for a few hours now. I ordered some thermal tape and plan on taping it into place so that it doesn't start flopping around again. Anyone have any ideas where exactly the sensor is supposed to be located so I can put it in its proper place? I think you might have moved the WiFi antenna, not a temp sensor. You could be right although I've never seen a wifi antenna like that before. Thanks for the help I guess... Is it wrapped in black shrink-wrap with 2 segments under the wrap? Can you put it outside of the metal housing through the rubber plug in the hole in the metal? If so, that the antenna. And if you put it out of the metal box and orientate it vertically up or down, you might get much better connection. Thank you for the guidance. Ok, back to square one then. Why the freezing? It has been running fine all day except one freeze in the morning. Is it due to it losing wifi connectivity? What temp do you see on the top menu bar (CPU temp of controller). This could indicate the heatsink on the blue controller is not properly installed, and from your description I can't really tell if you installed it back on right. It sides on top of the blue controller and you'll need to remove the side plate and the controller (two screws on bottom lip) to get it on there right. There is a grove in the heatsink where the audio jack is for proper alightment, and you need to press it down on top of silver CPU cap. Attached is an image of what it should look like installed. Be careful with the ribbon cable attachment as this can pop off while moving the controller around. https://i.imgur.com/A30ePkr.jpeg |
|
|
|
Hello,
I've been running the BTC miner with full node for a while now, but since this week end the node randomly goes offline and does not reconnect.
Anyone having this issue? I need the node to stay online.
The miner is still mining but the node just goes offline
I have been having the exact same issue, which means it's not us but something wrong on futurebit's end. I wrote them and they never wrote back Good luck trying to get support, its almost non existent, if not EXTINCT... Not sure where you are coming up with this, we respond to every email and im looking at our support que right now and there are only 10 outstanding tickets that will probably be answered in the next few hours (and we only have queues after weekends). So if your definition of non existent support means not answering your immediate question within 10 minutes, then yes we have non existent support and will continue to have non existent support. Im not hiring random support agents from India and driving up costs of our units by 20% to satisfy this urge. All our support emails are answered by my team that work on the units themselves (including myself) and can actually answer your question, but this means you might not have a response for a few days. Now in terms of the nodes issues we are not seeing anything on our test systems, nor any widespread outages (my first thought was the ordinals/BRC-20 fiasco causing issues, but even with 1G mempool we have plenty of memory overhead). Second issue could be if you have a recent system (bought after Nov/Dec last year), we switch to a new controller heatsink and some units were assembled without the heatsink adhesive properly installed. If your node/system is shutting down, or your your MCU temp (the one on the top menu bar) is higher than 85c then this could be the issue. You'll need to remove the side panel the MCU is on and remove the MCU and reseat the heatsink (press down on it hard for at least 10 seconds to make sure the thermal pad is stuck on there well). Second step if your still having an issue is to reflash your SD card to make sure there is no corruption that could be causing system instability, if your still having node issues email us with two below logs: take a screenshot of system monitor while the node is still active (preferably after it has started up and synced), you can open a terminal and type htop for this send log file of bitcoind, its in the Bitcoin folder inside the node drive (debug.log) So it appears the node goes offline only when I connect to it after a few minutes (via Sparrow Wallet). Can it be because it is overheating, connecting to the node actually makes it run hotter?!? I bought the unit couple years ago and I just cleaned it so it shouldn't overheat? The fan is on Auto as well. No, unless sparrow wallet is doing something crazy when you connect to it. Can you email us your logs after this happens (logs are in node drive /Bitcoin folder). Any updates on this? Having the same issue. This is a known issue with the wallet devs, problem is on their end and how they query data from low memory nodes like ours. I believe latest version has fixed it but reach out to their support. Craig Raw believes that the issue stems from the Apollo running bitcoin core v.22. Is there a way to upgrade to v.24? Yes you can just swap out the arm binary in /opt/apolloapi/backend/node/bin We will be updating to latest core with our solo mining mode update soon as well |
|
|
|
Hello,
I've been running the BTC miner with full node for a while now, but since this week end the node randomly goes offline and does not reconnect.
Anyone having this issue? I need the node to stay online.
The miner is still mining but the node just goes offline
I have been having the exact same issue, which means it's not us but something wrong on futurebit's end. I wrote them and they never wrote back Good luck trying to get support, its almost non existent, if not EXTINCT... Not sure where you are coming up with this, we respond to every email and im looking at our support que right now and there are only 10 outstanding tickets that will probably be answered in the next few hours (and we only have queues after weekends). So if your definition of non existent support means not answering your immediate question within 10 minutes, then yes we have non existent support and will continue to have non existent support. Im not hiring random support agents from India and driving up costs of our units by 20% to satisfy this urge. All our support emails are answered by my team that work on the units themselves (including myself) and can actually answer your question, but this means you might not have a response for a few days. Now in terms of the nodes issues we are not seeing anything on our test systems, nor any widespread outages (my first thought was the ordinals/BRC-20 fiasco causing issues, but even with 1G mempool we have plenty of memory overhead). Second issue could be if you have a recent system (bought after Nov/Dec last year), we switch to a new controller heatsink and some units were assembled without the heatsink adhesive properly installed. If your node/system is shutting down, or your your MCU temp (the one on the top menu bar) is higher than 85c then this could be the issue. You'll need to remove the side panel the MCU is on and remove the MCU and reseat the heatsink (press down on it hard for at least 10 seconds to make sure the thermal pad is stuck on there well). Second step if your still having an issue is to reflash your SD card to make sure there is no corruption that could be causing system instability, if your still having node issues email us with two below logs: take a screenshot of system monitor while the node is still active (preferably after it has started up and synced), you can open a terminal and type htop for this send log file of bitcoind, its in the Bitcoin folder inside the node drive (debug.log) So it appears the node goes offline only when I connect to it after a few minutes (via Sparrow Wallet). Can it be because it is overheating, connecting to the node actually makes it run hotter?!? I bought the unit couple years ago and I just cleaned it so it shouldn't overheat? The fan is on Auto as well. No, unless sparrow wallet is doing something crazy when you connect to it. Can you email us your logs after this happens (logs are in node drive /Bitcoin folder). Any updates on this? Having the same issue. This is a known issue with the wallet devs, problem is on their end and how they query data from low memory nodes like ours. I believe latest version has fixed it but reach out to their support. |
|
|
|
I'm having two separate issues with my Apollo Node (Full + Standard) affecting its continued operation:
(1) The unit randomly stops working while maintaining power and the appearance of hashing activity. The miners remain on with the fans running, but the unit does not "wake up" when the mouse or keyboard are manipulated and there is no output from the video (HDMI) port to my monitor. I have tried all possible layer 1 manipulations to wake the machine, but my mining pool shows a reported hashrate of 0, and the only way to regain control of the system is a hard shutdown and restart. This wastes both my time and my power at a premium.
(2) My machine is randomly dropping off the network with a syslog error reporting a failed handshake and stating my device has the WRONG KEY. However, the password has not changed since Ive owned the Apollo and it is the only one on my network to drop its LAN connection in this manner. Unfortunately, I don't know what (if anything) the following log dump is telling me, due to my limited, but anyone venture a guess as to why my LAN connection keeps dropping or how I might fix it?
Mar 18 18:55:44 futurebitbtc wpa_supplicant[1558]: wlan0: Trying to associate with **:**:**:**:**:** (SSID='*****WiFi' freq=5200 MHz)
Mar 18 18:55:44 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=**:**:**:**:**:** status_code=1
Mar 18 18:55:45 futurebitbtc kernel: [2534781.191339] unisoc_wifi unisoc_wifi wlan0: sprdwl_report_connection sm_state (5), status: (2)!
Mar 18 18:55:45 futurebitbtc kernel: [2534781.191399] unisoc_wifi unisoc_wifi wlan0: sprdwl_report_connection *****WiFi failed status code:1!
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.0030] device (wlan0): supplicant interface state: completed -> associating
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.0032] device (p2p-dev-wlan0): supplicant management interface state: completed -> associating
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.0179] device (wlan0): supplicant interface state: associating -> disconnected
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.0181] device (p2p-dev-wlan0): supplicant management interface state: associating -> disconnect>
Mar 18 18:55:45 futurebitbtc gnome-shell[1803871]: An active wireless connection, in infrastructure mode, involves no access point?
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.1072] device (wlan0): supplicant interface state: disconnected -> scanning
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.1074] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> scanning
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: Trying to associate with **:**:**:**:**:** (SSID='*****WiFi' freq=2462 MHz)
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-DISCONNECTED bssid=**:**:**:**:**:** reason=0
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.8560] device (wlan0): supplicant interface state: scanning -> associating
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.8563] device (p2p-dev-wlan0): supplicant management interface state: scanning -> associating
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: Associated with **:**:**:**:**:**
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: nl80211: kernel reports: key not allowed
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: WPA: Failed to set PTK to the driver (alg=3 keylen=16 bssid=**:**:**:**:**:**)
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-DISCONNECTED bssid=**:**:**:**:**:** reason=1 locally_generated=1
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="*****WiFi" auth_failures=1 duration=10 reason=WRONG_KEY
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9110] device (wlan0): supplicant interface state: associating -> disconnected
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9112] device (p2p-dev-wlan0): supplicant management interface state: associating -> disconnect>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9116] device (wlan0): supplicant interface state: disconnected -> 4-way handshake
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9117] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> 4-way han>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <warn> [1679180145.9139] sup-iface[0xaaab0a17a100,wlan0]: connection disconnected (reason -1)
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9143] device (wlan0): supplicant interface state: 4-way handshake -> disconnected
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9245] device (wlan0): Activation: (wifi) disconnected during association, asking for new key
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9253] device (wlan0): state change: activated -> need-auth (reason 'supplicant-disconnect', sy>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9261] dhcp4 (wlan0): canceled DHCP transaction
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9263] dhcp4 (wlan0): state changed extended -> done
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9333] manager: NetworkManager state is now CONNECTING
Mar 18 18:55:45 futurebitbtc dbus-daemon[1514]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatche>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]: <info> [1679180145.9836] device (p2p-dev-wlan0): supplicant management interface state: 4-way handshake -> discon>
Mar 18 18:55:45 futurebitbtc systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 18 18:55:46 futurebitbtc NetworkManager[1515]: <info> [1679180146.0302] device (wlan0): supplicant interface state: disconnected -> inactive
Mar 18 18:55:46 futurebitbtc NetworkManager[1515]: <info> [1679180146.0304] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> inactive
Mar 18 18:55:46 futurebitbtc dbus-daemon[1514]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 18 18:55:46 futurebitbtc systemd[1]: Started Network Manager Script Dispatcher Service.
Mar 18 18:55:47 futurebitbtc kernel: [2534783.200532] Purging 4202496 bytes
Mar 18 18:55:47 futurebitbtc kernel: [2534783.216659] Purging 4198400 bytes
Mar 18 18:55:47 futurebitbtc kernel: [2534783.222814] Purging 4399104 bytes
Mar 18 18:55:57 futurebitbtc systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Mar 18 18:57:31 futurebitbtc Tor[1780]: Tor has not observed any network activity for the past 107 seconds. Disabling circuit build timeout recording.
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]: <warn> [1679180266.0625] device (wlan0): no secrets: No agents were available for this request.
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]: <info> [1679180266.0629] device (wlan0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state:>
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]: <info> [1679180266.0695] manager: NetworkManager state is now DISCONNECTED
Mar 18 18:57:46 futurebitbtc gnome-shell[1803871]: An active wireless connection, in infrastructure mode, involves no access point?
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]: <warn> [1679180266.0813] device (wlan0): Activation: failed for connection '******WiFi'
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]: <info> [1679180266.0863] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'm>
Mar 18 18:57:46 futurebitbtc gnome-shell[1803871]: An active wireless connection, in infrastructure mode, involves no access point?
Mar 18 18:57:46 futurebitbtc gnome-shell[1803871]: message repeated 2 times: [ An active wireless connection, in infrastructure mode, involves no access point?]
Mar 18 19:00:01 futurebitbtc CRON[1834468]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs)
Mar 18 19:01:49 futurebitbtc Tor[1780]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 18 19:01:49 futurebitbtc Tor[1780]: Our circuit 0 (id: 127850) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configur>
Mar 18 19:05:01 futurebitbtc CRON[1834483]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 18 19:05:27 futurebitbtc Tor[1780]: Failed to find node for hop #1 of our path. Discarding this circuit.
Thought I had this figured out, but it turns out both issues are still occuring --random shutdowns and random network drops, not that I've received any responses from the group. How do I get on the "respond to my query" list? What kind of wifi interface do you have? Wifi controllers on these boards usually can't handle anything complex like mix mode/WPA3/etc. Try separating networks and using WPA2 with no spaces or special characters in SSID. Could also be a distance issue (try brining closer to base station), or corruption issue on SD card (reflash SD card and see if error goes away). |
|
|
|
One of my Apollo's has a problem and I want to figure out how to fix it or at least diagnose what is wrong.
...
I can temporarily get rid of the problem by unplugging the USB cable to the standard unit, then plug it in again and then restart the miner. Then it will run for maybe half a day before becoming erratic again, as shown below:  It seems to me there is something wrong, either related to the USB ports (they are fickle and often don't work) or maybe related to total power requirements of the OrangePi not being met at times, so that either an extra USB plugged in, or the HDMi cable plugged in will kick it over the edge into malfunction. This looks like an internet connectivity issue, if you're running on wifi can you try ethernet and see if it resolves? Adding another device via USB wont increase power requirements for controller, standard units have internal USB power and only use data lines on USB cords. One usb port is les reliable than the rest on the device (keep forgetting which it is but think its one of the USB 3 ports), and a good way to avoid is to use a USB hub (trying to get this fixed in time for the next major upgrade to the OS) HDMI does activate the GPU on the controller which does use a lot more power, also double check your heatsink on the controller is firmly attached and has not come loose. |
|
|
|
Hello,
I've been running the BTC miner with full node for a while now, but since this week end the node randomly goes offline and does not reconnect.
Anyone having this issue? I need the node to stay online.
The miner is still mining but the node just goes offline
I have been having the exact same issue, which means it's not us but something wrong on futurebit's end. I wrote them and they never wrote back Good luck trying to get support, its almost non existent, if not EXTINCT... Not sure where you are coming up with this, we respond to every email and im looking at our support que right now and there are only 10 outstanding tickets that will probably be answered in the next few hours (and we only have queues after weekends). So if your definition of non existent support means not answering your immediate question within 10 minutes, then yes we have non existent support and will continue to have non existent support. Im not hiring random support agents from India and driving up costs of our units by 20% to satisfy this urge. All our support emails are answered by my team that work on the units themselves (including myself) and can actually answer your question, but this means you might not have a response for a few days. Now in terms of the nodes issues we are not seeing anything on our test systems, nor any widespread outages (my first thought was the ordinals/BRC-20 fiasco causing issues, but even with 1G mempool we have plenty of memory overhead). Second issue could be if you have a recent system (bought after Nov/Dec last year), we switch to a new controller heatsink and some units were assembled without the heatsink adhesive properly installed. If your node/system is shutting down, or your your MCU temp (the one on the top menu bar) is higher than 85c then this could be the issue. You'll need to remove the side panel the MCU is on and remove the MCU and reseat the heatsink (press down on it hard for at least 10 seconds to make sure the thermal pad is stuck on there well). Second step if your still having an issue is to reflash your SD card to make sure there is no corruption that could be causing system instability, if your still having node issues email us with two below logs: take a screenshot of system monitor while the node is still active (preferably after it has started up and synced), you can open a terminal and type htop for this send log file of bitcoind, its in the Bitcoin folder inside the node drive (debug.log) So it appears the node goes offline only when I connect to it after a few minutes (via Sparrow Wallet). Can it be because it is overheating, connecting to the node actually makes it run hotter?!? I bought the unit couple years ago and I just cleaned it so it shouldn't overheat? The fan is on Auto as well. No, unless sparrow wallet is doing something crazy when you connect to it. Can you email us your logs after this happens (logs are in node drive /Bitcoin folder). |
|
|
|
Hello,
I've been running the BTC miner with full node for a while now, but since this week end the node randomly goes offline and does not reconnect.
Anyone having this issue? I need the node to stay online.
The miner is still mining but the node just goes offline
I have been having the exact same issue, which means it's not us but something wrong on futurebit's end. I wrote them and they never wrote back Good luck trying to get support, its almost non existent, if not EXTINCT... Not sure where you are coming up with this, we respond to every email and im looking at our support que right now and there are only 10 outstanding tickets that will probably be answered in the next few hours (and we only have queues after weekends). So if your definition of non existent support means not answering your immediate question within 10 minutes, then yes we have non existent support and will continue to have non existent support. Im not hiring random support agents from India and driving up costs of our units by 20% to satisfy this urge. All our support emails are answered by my team that work on the units themselves (including myself) and can actually answer your question, but this means you might not have a response for a few days. Now in terms of the nodes issues we are not seeing anything on our test systems, nor any widespread outages (my first thought was the ordinals/BRC-20 fiasco causing issues, but even with 1G mempool we have plenty of memory overhead). Second issue could be if you have a recent system (bought after Nov/Dec last year), we switch to a new controller heatsink and some units were assembled without the heatsink adhesive properly installed. If your node/system is shutting down, or your your MCU temp (the one on the top menu bar) is higher than 85c then this could be the issue. You'll need to remove the side panel the MCU is on and remove the MCU and reseat the heatsink (press down on it hard for at least 10 seconds to make sure the thermal pad is stuck on there well). Second step if your still having an issue is to reflash your SD card to make sure there is no corruption that could be causing system instability, if your still having node issues email us with two below logs: take a screenshot of system monitor while the node is still active (preferably after it has started up and synced), you can open a terminal and type htop for this send log file of bitcoind, its in the Bitcoin folder inside the node drive (debug.log) |
|
|
|
|
You wouldn't be able to get much higher exhaust heat from air cooled devices even if you ran ASIC temps higher, air is such a bad carrier of heat it requires ALOT of it to move significant heat (ie high RPM fans) which means that air will be significantly cooler than what its trying to cool.
There are some silicon formulations in fabs that can be run over 100c continually, and here it gets interesting because you can use distilled water to cool the ASICs directly and actually boil the water, steam is a much more useful wast heat. We are playing around with some of these types of ASICs.
|
|
|
|
Is there one? If so, what is it? I've reached out through multiple direct channels for help with a failed unit < 90 days old and have received no response (yet). Is this typical post sales support?
If it's a warranty case, check back with your reseller first. He should be able to directly sort that out with you or file a support case on Futurebit side. I bought direct from futurebit and have tried all the usual support channels (chat, email, replying to my order email etc) over the past week but no response. Wondering is that was to be expected or an anamoly? We respond to all support emails and as far as I can see we dont have any open tickets right now so maybe your email is not going through? FYI all Apollos comes with a standard one year warranty. |
|
|
|
~snip~ Well someone here solve the last ckpool solo block using 10TH worth of Apollos  Probably why the pool has attracted more Apollo users since then. The benefit is that you are using your own node to construct and broadcast the bitcoin block if found, with ckpool, the pool itself has control over the block creation (and therefor could theoretically censor transactions). Until we release our own implimination of solo mining I would not suggest trying to do this on your own unless you know your node is well connected to other pools (which is hard to do on an individual level). We are working with pool partners to directly connect all Apollo solo miners to major pools once our implementation launches. You mentioned in theory ckpool can censor transactions, wouldn't exactly the same statement apply to the "Apollo Pool" since you said the plan is to connect to other servers? At the end of the day using any pool you need to trust the person behind it. By connect to other servers I mean your node will be highly connected to the major mining pool backbone for faster block propagation. You would still be your own "pool" and mining your own blocks/transactions. FYI cool functionality we are building out is that solo mining will essentially be your own stratum pool (so the pool will run locally on your device and your hashboard will be connected to that internal pool), but the fun part is that you can use it as your own pool infrastructure, so if you have other miners (even non Apollo hardware) you could point all of them to the Apollo and solo mine. "Pool in a box" |
|
|
|
|
Show Posts
