Pages:
Author

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

legendary
Activity: 2156
Merit: 1400
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.  Cheesy

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 Smiley
legendary
Activity: 2156
Merit: 1400
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.
newbie
Activity: 8
Merit: 0
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

legendary
Activity: 2464
Merit: 1710
Electrical engineer. Mining since 2014.
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.  Cheesy

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.


legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
- 4 bytes of data every 2 seconds wont have any noticeable life reduction of SD card Wink
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’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 Cheesy)

Thanks, looking forward for the next release. Grin

The workaround (or fix) for those two files is indeed simple:
Code:
cd /var/local/apollo/hwmon
mv fan_rpm /dev/shm/ && ln -s /dev/shm/fan_rpm fan_rpm
mv pcb_temp /dev/shm/ && ln -s /dev/shm/pcb_temp pcb_temp

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):
Code:
systemctl stop "[email protected]"
systemctl disable "[email protected]"

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




Did you just plug the moonlanders in how did they connect?
jr. member
Activity: 61
Merit: 4
- 4 bytes of data every 2 seconds wont have any noticeable life reduction of SD card Wink
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’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 Cheesy)

Thanks, looking forward for the next release. Grin

The workaround (or fix) for those two files is indeed simple:
Code:
cd /var/local/apollo/hwmon
mv fan_rpm /dev/shm/ && ln -s /dev/shm/fan_rpm fan_rpm
mv pcb_temp /dev/shm/ && ln -s /dev/shm/pcb_temp pcb_temp

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):
Code:
systemctl stop "[email protected]"
systemctl disable "[email protected]"

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


legendary
Activity: 2156
Merit: 1400
- 4 bytes of data every 2 seconds wont have any noticeable life reduction of SD card Wink
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 Cheesy)
jr. member
Activity: 61
Merit: 4
- 4 bytes of data every 2 seconds wont have any noticeable life reduction of SD card Wink
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.
legendary
Activity: 2156
Merit: 1400
legendary
Activity: 2156
Merit: 1400
legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
jr. member
Activity: 61
Merit: 4
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.
legendary
Activity: 2156
Merit: 1400
I format it one more time and burn it again and it is starting now  Grin Grin Grin 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

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
newbie
Activity: 7
Merit: 0
I format it one more time and burn it again and it is starting now  Grin Grin Grin 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
full member
Activity: 181
Merit: 100
what is the size of yr sdcard and how did you burnt it?
newbie
Activity: 7
Merit: 0
you have to short PS ON signal to GND in your 24pin connector like that :

https://www.boulineau.com/wp-content/uploads/2013/02/connecteur-PC-300x179.png

with your psu switch off of course

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.

full member
Activity: 181
Merit: 100
you have to short PS ON signal to GND in your 24pin connector like that :



with your psu switch off of course
newbie
Activity: 7
Merit: 0
Hi,I'm a newbie here and I've got just received my Apollo and I'm really thrilled to make it work  Smiley.

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
legendary
Activity: 2210
Merit: 1109
My Apollo is not powering up.  I had it up and running and was in the dashboard.   I went to settings and scanned for WIFI.  Once it found my WIFI, I connected it.  The Apollo never connected and so I restarted it.  It has not powered on since.  When I power up the EVEA 500, the Apollo fan turns for a second but the yellow light never comes on.  Any suggestions?  Is there a reboot on the Apollo?   

try this: power off PSU, disconnect all cables from the Apollo, wait 1 minute, connect them again and powered your PSU.
newbie
Activity: 8
Merit: 0
My Apollo is not powering up.  I had it up and running and was in the dashboard.   I went to settings and scanned for WIFI.  Once it found my WIFI, I connected it.  The Apollo never connected and so I restarted it.  It has not powered on since.  When I power up the EVEA 500, the Apollo fan turns for a second but the yellow light never comes on.  Any suggestions?  Is there a reboot on the Apollo?   
Pages:
Jump to: