Topic: Official FutureBit Apollo LTC Image and Support thread - page 61. (Read 50023 times)

The Moonlanders are connected to a powered USB hub which also powers the 12V 80mm fan using a 5V->12V regulator. That hub is then connected via usb to the Apollo which will automatically detect the two Moonlanders as /dev/ttyUSB0 and /dev/ttyUSB1. As there aren't other serial usb devices connected, it can be assumed that all /dev/ttyUSB prefixed devices are Moonlanders.

After that, it's only a matter of getting bfgminer running. I didn't try using the bfgminer that runs the Apollo (as root user) as the dashboard showed no signs of supporting multiple devices internally. I transferred the Moonlander bfgminer binary package for Raspberry Pi (works because of being the same cpu architecture) to the unit using the futurebit username, configured it to scan only those specific serial usb devices and use a different api port:


That's added to a script with freq defined and started in a screen which results in the Moonlanders working without disturbing anything Apollo related. Obviously, nothing new shows up in the Apollo dashboard.

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?

Awesome! This is pretty much the "ideal" setting I envisioned for these

That means bfgminer is not connecting to your pool...double check your pool info/username.

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

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.

Did you just plug the moonlanders in how did they connect?

Thanks, looking forward for the next release.

The workaround (or fix) for those two files is indeed simple:

I also noticed there's a service configured looking for a serial port that isn't available so disabling it stops warnings getting constantly logged (commands as root):

My Moonlanders are finally connected to the Apollo so no more need for a separate Raspberry Pi:

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 )

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.

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.

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.

Guys just use etcher if you don't know how to use DD properly. For example the above is incorrect, your imaging to the SD cards partition instead of to the root of the sdcard (not exactly sure how you got it to work with it burned this way).

Proper dd command would be something like this

sudo dd if=apollo_final.img of=/dev/rdisk2 bs=1m

I format it one more time and burn it again and it is starting now  Thank you so much !!

I've got a Samsung 32 GB microSD HC 1 and I burned it this way : sudo dd if=apollo_final.img of=/dev/rdisk2s1 bs=1m

what is the size of yr sdcard and how did you burnt it?

Ok thanks, I just tried that now and Apollo is starting few seconds (fan spins and stops) but it won’t go any further: it stays with the 2 lights of Ethernet solid and not blinking. Not light in the front. I tried to unplug everything wait for 1 minute and plug everything back, but I get the same behavior.

you have to short PS ON signal to GND in your 24pin connector like that :



with your psu switch off of course

Hi,I'm a newbie here and I've got just received my Apollo and I'm really thrilled to make it work  .

I did everything with the SD Card and it seems to have been burned right.

I have an issue and I'm not able to power up my Apollo : I'm using a brand new Egva G3. I plugged a VGA cable in VGA 1 in the EVGA and put the end of the  6+2 cable into one of the power inlet in the Apollo (I'm using only the 6 part cable, the +2 is floating in the air next to it). But it doesn't power up.

What did I do wrong ?

Thank you for your answers !! Dave