I have a new Apollo. It works great for a few days then one of two things happen.
1. The fan stops completely and start smelling. I have to unplug and plug back in. Glad I?m around when that has happened because I fear it was heating up.
2. Fan speed jumps to full speed. Can?t log in to reboot. Have to unplug etc.
These happen regularly.
Glad I?ve been around in each case. Thoughts?
What mode are you running the miner in? This is probably related to the MCU lockup issue we know about that can happen in a rare occasion. It should be fixed in the next update we are releasing soon. |
|
|
|
I think I've solved the reason why the fan rpm doesn't sound stable even when the fan is manually set to some specific speed and have a solution to fix it. The fan is being controlled with software generated pwm as there doesn't appear to be any hw pwm capable pins unused on the board. The software solution needs to keep a stable timing with the pwm in order for the fan to keep the same rpm. At the same time, the MCU can have a frequency of several values between 240 MHz and 1.20 GHz. By default, this works so that if there's zero load then the frequency will eventually drop to 240 MHz and when there's any load spike then the frequency jumps directly to 1.20 GHz no matter how small the actual cpu demand was. I used the following command to monitor the frequency and it's clear that it's constantly jumping between minimum and maximum even when nobody is using the dashboard: while true ; do echo "$(date) - $(sudo cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq)" ; sleep 1 ; done
The constant cpu frequency variation makes it difficult for the software pwm to maintain exact rpm. It's close but still the variation is audible. Looking at the frequency usage stats with the "cpufreq-info" command, we can also see that the cpu is spending much time at maximum frequency: 240 MHz:42.72%, 480 MHz:24.41%, 648 MHz:0.00%, 816 MHz:0.00%, 912 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.01%, 1.10 GHz:0.01%, 1.20 GHz:32.85% (2229569)
The solution itself is rather simple. The default behaviour is to react instantly to any processing power demand and bump the frequency to maximum. However, other behaviours are also available and switching to the one called "conservative" results in slower changes in the frequency is processing power is needed. It turns out that the demand with the current software content is so low in reality that with the "conservative" setting the frequency rarely increases resulting in the software pwm staying stable and the audible changes in the manually set fan rpm going away. First, without saving the change, the behaviour (frequency governor) can by changed with: sudo cpufreq-set -g conservative If that doesn't help then the change can be reverted back with: sudo cpufreq-set -g ondemand Making the change permanent requires modifying /etc/default/cpufrequtils and replacing "GOVERNOR=ondemand" with "GOVERNOR=conservative". The other positive side effect is that since the higher frequencies are no longer used that often, the MCU temperature also stays a little bit lower. With the changed governor, "cpufreq-info" now shows (after a stats reset): cpufreq stats: 240 MHz:99.21%, 480 MHz:0.30%, 648 MHz:0.07%, 816 MHz:0.08%, 912 MHz:0.05%, 960 MHz:0.05%, 1.01 GHz:0.03%, 1.10 GHz:0.03%, 1.20 GHz:0.17% (18182)
Thanks for this! This was known and our internal build has the frequency set to a fixed 800mhz permanently (since thats all the MCU needs right now), and also sets the voltage state to the lower value, but I like your solution even better if it keeps CPU frequency at 240 for a large percentage of time. |
|
|
|
Got ya...yea thats obviously keeping the MCU nice and cool. |
|
|
|
Thanks. The powersupply does not start. I read somewhere that I have to jump some pins of an adapter. Any ideas?
Yes just search online for ATX PSU Pin jumper. Easiest way is to just paper clip the green wire to any black wire (if its color coded, if not use the pinout pics that are online), |
|
|
|
Is it possible in the current software version to run a full node with an SD card of sufficient capacity?
The binary needed for a full node isn't provided by default. With the right tools, it's still possible to compile it yourself and get it running but I haven't checked how much memory would also be required if every setting is minimized. The default settings appear to have caches of 450 MB + 300 MB. The MCU has only 256 MB ram and about half of that is already being used. As for storing the blockchain, most likely using a separate USB stick would be the better approach as that way any updates of the SD card image wouldn't require fetching the blockchain again. Yes we have internal builds with full node running, but we still have a lot of work to do before its stable. There are a lot of system level changes that need to be done to keep the full node + webui + miner backend stable, plus tweaks on the node itself to run on this hardware efficiently. Plan is still on to have full node + LN + wallet functionality done before Q1 this year. FYI also hope to have an update to the image complete by end of next week with lots of bug fixes/improvements. Just got back from holiday break and some serious downtime I needed so getting back into he swing of things. |
|
|
|
Latest reports and observations after a couple weeks of tinkering:
Got the wifi working, but I couldn't get a hashrate above 65 Mh/S no matter what mode I tried.
Might be something on the provider end, wifi generally sucks in our house anyway...
Also had the dashboard freeze up with the wifi running and couldn't adjust controls which got a little terrifying.
Plugged the cable back in and mined litecoinpool for 6 days with no issues in eco mode and fan at 15%
Currently mining litecoinpool in balanced mode for the last day with no issues. Avg 120 Mh/S
Fan set at 30%, miner temp 68.15, mcu temp 55.05, have the unit sitting on a $5 laptop fan plugged into the USB port
Tried some other coins and pools, but keep returning to litecoinpool 'cos I like their dashboard layout
Verdict: having a blast with my new cool toy! Thanks!
Yea, if your wifi is bad it was most likely dropping packets so shares were not reaching the pool, hence the lower hash rate. Thanks for the rest of the feedback! What do you mean by the laptop fan plugged into the USB port? |
|
|
|
Just to add to the miner going offline reports: My Apollo went offline after what may have been exactly 6 days of hashing. I had connected it to wifi about 2 or 3 days ago and removed the ethernet cable. The wireless interface appears to have lost its IP address, and reconnected the ethernet cable did not lead to a DHCP lease. Power cycling the Apollo brought everything back online. How would I go about connecting to the shell to get a log file? I am using the pre-loaded 4gb card at the moment.
Is it possible in the current software version to run a full node with an SD card of sufficient capacity?
Yea this is a known issue, most likely the wifi driver crashed and when that happens only a reboot recovers it. Next version will most likely have some sort of reboot script to check for basic internet outages and stuff like this will happen auto. |
|
|
|
Hello Everyone,
So today one of my two apollos was down on litecoinpool.org but still "online" ( Green on the workers username ) but no hashing.
I just get home the miner seemed to still hashing ( green and red light like always ) doesn't seem to don't have any problems...
So i opened the dashboard and it says miner offline... **
I don't really know what happened today ....
Sounds like an internet disconnect knocked the pool offline and it did not auto-reconnect. Simple restart will fix this. |
|
|
|
Fan control still needs work. Got the alert from litecoinpool that the apollo had dropped off this morning. I could not get the the web front end, so I ignored it figuring on a crash. The L3+ that is on the same power supply never dropped so I knew the power and internet were good. Got in to work and fan was not spinning AND unit was about 1 billion degrees (give or take a bit) was actually hot enough to darken the thermal ink label on the controller.  Once it cooled down it seems to have come back no problem. I now have the fan set to 25% instead of auto. In the next revision can you have the fan fail to max speed in case of any issues? -Dave I have seen this happen on a rare occasion and trying to investigate the root cause, but its has to do with the controller randomly locking up. Unfortunately has nothing to do with our code. We have a board level failsafe that will shut down the regulator before any damage happens, but since the fan is controlled by the MCU there is nothing we can do on the fan side, and things will get hot until the emergency shutdown triggers (which it might not in eco mode since board might not get hot enough). |
|
|
|
Thank you. I had not defined the worker.
Lol all that for an undefined worker  Once I finish the full writeup I need to get up a list of all the little stupid avoidable things people have issues with  |
|
|
|
no hashing on any pool I try to put it on is mining or errors up, same with your moonlander 2 sticks, so rushed off and expensive devices I was planning to buy 20 but lucky I bought a prototype
MAYBE I STUFFED UP SOMEWHERE maybe hub on moonlander sticks or something ill play with those, but this Apollo is too good to be true atm Maybe if you tried to ask for help in the support thread you would figure out what your doing wrong. We have shipped hundreds of these with very few issues. |
|
|
|
|
Yea figured it was something like that. Wait so did you have to change this poolside? Is there a bug with my ui and it does not save caps?
|
|
|
|
I have the Apollo powered up and I am in the dashboard. I am not connecting to the miner or to blocksfactory. I have burned a new Apollo image that was successful, entered the username, password and address in the pool dashboard. I have not added the proxy address. Is this needed? Here is the message I am getting in my dashboard.
It seems there is a problem to communicate with the miner, check error message.
Error: connect ECONNREFUSED 127.0.0.1:4028
That means bfgminer is not connecting to your pool...double check your pool info/username. I have tried both litecoinpool and blocksfactory using cut and paste to enter usernames and passwords. I can't get either to work. I have logged out of the mining pools and used the same username and passwords (cut and paste that I used on the Apollo dashboard) and had success logging back in. Do I need to enter the proxy address? Update: I changed the password to something very simple in the both mining pools and I am not getting the Apollo to connect. I am not sure what I am doing wrong. I was successful with my Moonlanders but this is not connecting. I am connected via ethernet cable. The Apollo is working thought because the donation is both active and the status is alive. My main pool is active and the status is dead. If donation pool is working then your definitely imputing something wrong in the url field probably. Delete the whole pool entry and put in a new one and make sure you are copy and pasting the whole stratum url correctly. Pool worker names/pass are case sensitive as well so you’ll fail authentication and get a “dead” pool. I am using this address. stratum+tcp://us.litecoinpool.org:3333 plus username and password. My moonlanders are working on the same pools with same passwords. I am not sure what else I can do? Did you do this on the setup wizard? There is a bug that's not saving this info. Make sure your going to the pool tab on the main side panel. Delete whatever is there and input a new entry using the pool info. You need to press the save button on the top of the screen. If that still does not work try rebooting the MCU. |
|
|
|
I have the Apollo powered up and I am in the dashboard. I am not connecting to the miner or to blocksfactory. I have burned a new Apollo image that was successful, entered the username, password and address in the pool dashboard. I have not added the proxy address. Is this needed? Here is the message I am getting in my dashboard.
It seems there is a problem to communicate with the miner, check error message.
Error: connect ECONNREFUSED 127.0.0.1:4028
That means bfgminer is not connecting to your pool...double check your pool info/username. I have tried both litecoinpool and blocksfactory using cut and paste to enter usernames and passwords. I can't get either to work. I have logged out of the mining pools and used the same username and passwords (cut and paste that I used on the Apollo dashboard) and had success logging back in. Do I need to enter the proxy address? Update: I changed the password to something very simple in the both mining pools and I am not getting the Apollo to connect. I am not sure what I am doing wrong. I was successful with my Moonlanders but this is not connecting. I am connected via ethernet cable. The Apollo is working thought because the donation is both active and the status is alive. My main pool is active and the status is dead. If donation pool is working then your definitely imputing something wrong in the url field probably. Delete the whole pool entry and put in a new one and make sure you are copy and pasting the whole stratum url correctly. Pool worker names/pass are case sensitive as well so you’ll fail authentication and get a “dead” pool. |
|
|
|
Thanks for the great work, jstefanop I found a great place for the pod. It is in my kitchen, on top of the fridge. It was kind of tricky to get the power cord pulled inside the closet where the electrical socket is located, but I managed to pull it through by using a measuring tape as a tool.  And I managed to get the wifi working, so no ethernet cable is needed for my setup.  Occassionally, after some time I'm not able to reach the miner web UI. But I think the miner network connection to the AP remains ok. I forgot to look at the pool stats while this happened to me. I will look more closely at this if it happens again. Awesome! This is pretty much the "ideal" setting I envisioned for these  |
|
|
|
I have the Apollo powered up and I am in the dashboard. I am not connecting to the miner or to blocksfactory. I have burned a new Apollo image that was successful, entered the username, password and address in the pool dashboard. I have not added the proxy address. Is this needed? Here is the message I am getting in my dashboard.
It seems there is a problem to communicate with the miner, check error message.
Error: connect ECONNREFUSED 127.0.0.1:4028
That means bfgminer is not connecting to your pool...double check your pool info/username. |
|
|
|
- 4 bytes of data every 2 seconds wont have any noticeable life reduction of SD card  The filesystem block size is 4096 so that's how much gets written every time a file with 4 bytes of content is overwritten and due to the overwrite, the same inode is being used every time. With two files, that results in a constant 4KB/s write on the sd card. Unless it does wear leveling internally (that appears to depend based on the make and model, somewhat hard to find exact details), such usage is sure to reduce the life of the card. - see point #2 above regarding bfgminer api
I was mainly looking to have (=wishlist) some easy way of polling the status of the unit from an external server within the same network. I'd then store the status with a timestamp in a database for later trend graphing (something the dashboard doesn't provide) and possible other automation. Having the option of polling for example something like http://futurebit.local/stats (+ some api key) would be a more usable approach instead of having to write some script to run on the unit mcu itself which would the push the sama data at some interval. I’ll do some more research and see if this is something of a concern for a time scale of a few years, it’s easy enough to switch to a ram disk either way. We have some interesting stuff planned down the line that’s even better than some api backend (think server login/remote control/mass configuration/mobile control ) |
|
|
|
Got my unit few days ago and here are some findings/comments/observations that could be of use to someone. First of, the unit itself was intact so not broken side panels. However, I did notice that it didn't sit flat on the table and appeared to have a tendency of rocking between two opposite corner (more on that later). Many have claimed the fan to be quiet but that's not something I can really agree with since at least my unit has clear bearing noise/rumble coming from it on low fan speeds until the air noise takes over on higher fan speeds. Additionally, there was a clear resonance audible from the case itself which led me to disassemble the casing is it didn't sound normal. It turned out that the fan had been screwed with too much force to the heatsink causing two of the corners of the fan to look visibly bent. The fan install had also forced two of the aluminium ring spacers(?) to get partially embedded in the heatsink resulting in the fan not sitting straight and most likely making contact with the side panel as a result. Fixing those issues removed the resonance noise and made the unit also sit flat on the table. Then more software related things (not in any order): - it would be nice for the Lockscreen to automatically focus the input field instead of having to click it first
- for some reason the raw data (bfgminer json) doesn't show the MH/s value anywhere correctly, values are in the 3-6 MH/s range, something to do we the current beta driver?
- auto fan settings isn't really that usable (as has been discussed already in previous comments)
- touching the fan setting on the page causes the slider to jump down due to the save dialog appearing on the top of the page
- the manual fan setting could be an input box or have more than 5% resolution as manipulating the filesystem side files show that 1-2% resolution is usable
- even with fan speed set manually, there's some audible repeating variance in the the rpm (unstable pwm generation? don't have scope to check)
- the mcu appears to be jumping mostly between maximum and minimum frequency depending if the UI is displayed or not, lowering the maximum frequency could make the mcu colder since it isn't being actively cooled and there's not much space for a heatsink either
- hwmon is writing /var/local/apollo/hwmon/fan_rpm and /var/local/apollo/hwmon/pcb_temp every 2 seconds and that directory isn't on tmpfs, this will most likely reduce the life expectancy of the sd card
- some sort of read only json api endpoint for getting stats from the unit is missing, the bfgminer api could do (if it would provide usable values) but it's still missing the fan rpm and temperatures
As a side note, if someone is looking for passive power supply for a single unit in eco mode then the Dell DA-2 (12V 18A) is one possible option worth looking. I happened to have one without use and it only needed an adapter to be made for the power connector. I have no idea what the official efficiency of that brick is but the meter says 130-133W @ 102 MH/s which appears to be in line with other comments in this thread. Thanks for the feedback...build issues you mentioned are already known and have been addressed at the factory. Here some comments from your other points -lockscreen point added to-do -bfgminer is only used for stratum support...all miner code and hardware controls is done separately and completely custom...thats why we don't use bfgminer api for anything other than pool info/status -we are releasing updated fan algorithm next release that will be much better than initial version -actually fan resolution is only 5%...messing around with system level files like this will most likely cause some sort of crash to happen with hardware controller and you'll just end up with a burned up miner. -thats just normal fan acoustics...we had to choose a fan that could handle cooling for turbo mode and beyond..had to sacrifice some low level "quietness" for this, but its still under 30decibles and definitely the quietest ASIC miner fan in production. -MCU frequency issue is known, it will be locked to a lower frequency on next build - 4 bytes of data every 2 seconds wont have any noticeable life reduction of SD card - see point #2 above regarding bfgminer api |
|
|
|
Got my unit few days ago and here are some findings/comments/observations that could be of use to someone. First of, the unit itself was intact so not broken side panels. However, I did notice that it didn't sit flat on the table and appeared to have a tendency of rocking between two opposite corner (more on that later). Many have claimed the fan to be quiet but that's not something I can really agree with since at least my unit has clear bearing noise/rumble coming from it on low fan speeds until the air noise takes over on higher fan speeds. Additionally, there was a clear resonance audible from the case itself which led me to disassemble the casing is it didn't sound normal. It turned out that the fan had been screwed with too much force to the heatsink causing two of the corners of the fan to look visibly bent. The fan install had also forced two of the aluminium ring spacers(?) to get partially embedded in the heatsink resulting in the fan not sitting straight and most likely making contact with the side panel as a result. Fixing those issues removed the resonance noise and made the unit also sit flat on the table. Then more software related things (not in any order): - it would be nice for the Lockscreen to automatically focus the input field instead of having to click it first
- for some reason the raw data (bfgminer json) doesn't show the MH/s value anywhere correctly, values are in the 3-6 MH/s range, something to do we the current beta driver?
- auto fan settings isn't really that usable (as has been discussed already in previous comments)
- touching the fan setting on the page causes the slider to jump down due to the save dialog appearing on the top of the page
- the manual fan setting could be an input box or have more than 5% resolution as manipulating the filesystem side files show that 1-2% resolution is usable
- even with fan speed set manually, there's some audible repeating variance in the the rpm (unstable pwm generation? don't have scope to check)
- the mcu appears to be jumping mostly between maximum and minimum frequency depending if the UI is displayed or not, lowering the maximum frequency could make the mcu colder since it isn't being actively cooled and there's not much space for a heatsink either
- hwmon is writing /var/local/apollo/hwmon/fan_rpm and /var/local/apollo/hwmon/pcb_temp every 2 seconds and that directory isn't on tmpfs, this will most likely reduce the life expectancy of the sd card
- some sort of read only json api endpoint for getting stats from the unit is missing, the bfgminer api could do (if it would provide usable values) but it's still missing the fan rpm and temperatures
As a side note, if someone is looking for passive power supply for a single unit in eco mode then the Dell DA-2 (12V 18A) is one possible option worth looking. I happened to have one without use and it only needed an adapter to be made for the power connector. I have no idea what the official efficiency of that brick is but the meter says 130-133W @ 102 MH/s which appears to be in line with other comments in this thread.that is a good 1 unit eco power solution. 12 x 18 = 216 and 133/216 = 61.5% of the brick https://www.trcelectronics.com/carries a lot of 12 volt psu's https://www.trcelectronics.com/ecomm/pdf/hrp300.pdfthis one does 300 watts so 1 unit would work it is 88% eff. it is about 73 dollars it can be found elsewhere. here is a lower cost model 32 usd and 85% eff https://www.trcelectronics.com/ecomm/pdf/lrs350.pdflastly this one has a nice look to it. https://www.trcelectronics.com/ecomm/pdf/enp360.pdfit is 91% eff and power can adjust 11.5 to 13.8 volts dc it is fanless and only 79 bucks . Never used it but I may buy it to test with these units FYI the 92-94% Platinum efficient 200 watt brick I am building will cost 40-60 USD range..it will probably be ready end of next month. |
|
|
|
|
Show Posts
