The "Add to cart" button is missing which would suggest all the options are sold out. If it's the MCU board upgrade you are missing for a batch 1 then look for a 512MB version of Orange PI Zero (not "plus", not "2") with straight pins soldered in the expansion port. It's nothing FutureBit specific. Batch 1 came with a 256MB version of that MCU board which doesn't have enough memory for running the node.

futurebit

Mainly a suggestion for a future release:
Package the "app" as a container (Docker for example) and map the necessary i/o connections directly to it. That way all the dependencies and changes needed by your own implementation can stay as you want without a risk of a system update making modifications and on the Ubuntu side the system updates and package installs (which may also pull updates as dependencies) can be used without having to worry of something getting unintentionally modified. That could also make reseting the setup back to defaults easier since it would just be a matter of discarding the container and starting a clean one.

The fan specs and requirements have been mentioned in a older message: https://bitcointalk.org/index.php?topic=5081750.msg48627834#msg48627834

If it's the MCU board you are missing, it's the 512MB version of Orange PI Zero (not "plus", not "2") with straight pins soldered in the expansion port.

That front led is software controlled. It showing no activity suggests that the system doesn't boot at all or not correctly at least. In that situations your options are somewhat limited:

Option 1) Re-flash the sd card. In many cases that appears to help.

Option 2) Flash another sd card. The current one may be dead.

Option 3) The non-trivial option: Get a USB to TTL adapter and attach it to the uart of the mcu board. That will allow you to see what is happening during system boot and possibly give a clue what's wrong.

Assuming that payout issue is the same I found when searching for possible pools for the Apollo BTC before concluding not to participate in the pre-order, it really shouldn't be underestimated from new users point of view. I haven't been following BTC pools at all so it's likely I may have missed some (and I assumed KanoPool wasn't anymore even active due to the stats page not having anything recent), but the conclusion was that with one unit running at about 2.8 TH/s (based on the screenshot), the payout interval would end up being around 2-3 months with the current difficulty and the minimum payout threshold that pools are having. From a new user point of view, that's too long and the user will start to doubt things like settings being correct or the pool not being the right one. Especially when in comparison a single Apollo LTC unit still gives a payout interval of 2-4 days (litecoinpool with minimum payout threshold being my datapoint).

The mostly blue SBC board model on the site looks awfully lot like an Orange Pi 4. If it is, does it come with the onboard microphone still attached?

Samsung EVO Plus cards at least are supposed to be high quality and I haven't had any issue with those in any devices. However, I haven't seen this frequent need for reflashing the SD card in the Apollo either (114 days uptime currently). At least in Raspberry Pis, the eventual failure mode of a SD card is such that it can no longer be written and also reads result in failures nor is reflashing it anymore possible. That's why I suspect there's something else going on if the usability can be recovered by reflashing the same SD card.

Regarding the current firmware, this is one change that I've done after installing it that may have some improving effect. You'll need ssh access and root to execute the commands:


This only disables a service that is constantly trying to start and will always fail to do so due to such serial port not being available (not that you'd need that terminal anyway). Every start is likely to get written to the systemd bookkeeping which may also result in card write operations.

If it had been a small status / monitoring display you were looking for then https://github.com/Qrome/printer-monitor is probably the closest that comes to mind that could be made Apollo compatible with some code changes (new output layout + bfgminer json parsing instead of octoprint json).

If with command line process you refer to the bfgminer console output then one possibility could be to modify the startup parameters a little bit and make it use a log file. Then you'd need some process to read that log and dump it to some display. As there's only a USB port available, you'd either need some USB->VGA converter (DisplayLink may be supported enough) + a small VGA display. Most likely the cheaper option would be to have an Arduino connected to the USB which would then become visible as a serial port. With some scripting, it would be possible to dump new lines from the log file to the serial port which would the be read by the Arduino and shown on some supported display (https://www.buydisplay.com/default/9-inch-arduino-touch-screen-shield-ssd1963-library-for-mega-due for example, the largest I could find). With the Arduino, you'd have full control on how to output the input text and that way make it as artistic as you'd want/can.

What sort of display did you have in mind?

The bfgminer api exposes most of the useful information so I suppose something like attaching an Arduino with a 7-segment display to the USB port and having a script to feed it for example the hashrate from the api could be one simple option. Replace that 7-segment display with some commonly used small OLED and you could fit a little bit more info there. Replace the Arduino with a ESP8266 or ESP32 and it could read the bfgminer api by itself without needing to be attached to the USB port.

It could be more practical to store the blockchain on some USB flash stick since there's an USB port available anyway. That way the SD card size wouldn't matter that much and updating the firmware by fully erasing the card content wouldn't reset the blockchain back to zero (or to some other older snapshot the firmware possibly provides).

That will vary and it can vary a lot. Most likely the LTC difficulty will still keep slowly increasing so the LTC/month/Apollo will decrease and eventually it comes to the value of LTC itself. The history graph below shows the 24 hour reward for the last 3 months from litecoinpool with a single Apollo running 24/7. As you can see, the LTC/day is decreasing but USD/day far more unpredictable.




From efficiency point of view, it's not worth it. The Apollo can be tuned to run around 1.1 W / MH/s where as the Moonlander 2s I had were somewhere around 2.5 W / MH/s. On the other hand, there's the learning aspect of getting the Moonlander running in the Apollo which may be worth something.

The Apollo doesn't have out of the box support for Moonlanders. However, the bfgminer binary for raspberry pi is directly compatible with the Apollo MCU and I've had such combination running without issues. The reality is that it doesn't make much sense from efficiency point of view even if possible.

Molex 48037-1000 should be compatible.

Optimizing efficiency using custom mode

I spent some time playing around with custom mode with the target of optimizing the unit efficiency while keeping the hashrate the same as in eco mode. Here are some findings and instructions that may be of use to also others.

The setup

My unit is powered with a Dell DA-2 PSU which is connected to the unit using a custom cable using XT60 connector in between before the pci-e connector. This allowed having one power meter before the PSU and another one after it (HobbyKing HK-010 in this case). That way, it didn't matter if the efficiency of the PSU changed depending on load as I was able to see how much the unit was actually using. Fan was set 15% as I also expected to see some changes in the miner temperature and litecoinpool was used as only configured pool to ensure constant and steady load. The current firmware (0.0.2) was in use.

The tuning process

The basic idea is really simple: start with the same settings as in eco mode and lower the voltage until the error percent jumps.
The reality was that I found some bugs but did get the job done.

The first issue I noticed was that the "reset to default value" in custom mode doesn't, at least currently, match the same voltage as in eco mode. Based on the power meters, it would look like the eco mode is using 760.20 mV as voltage and 598 MHz as frequency. However, the default for custom mode is 747 mV and 598 MHz. But at least the frequency is likely to be the same so I started from 760.20 mV while keeping the frequency fixed at 598 MHz.

The next issue, at least with Firefox, is that moving the voltage slider results in the save dialog popping up on top of the page which then moves the voltage slider down and sometimes gave the impression that the slider had moved more than I intended. That can kind of be solved by just clicking the slider to put focus on it and then pressing the left arrow from the keyboard once. That guarantees a reduction of one increment and the save button can then be clicked to make the change go live.

Finally, there's some sort of calculation or rounding error with the numbers of the voltage slider as those don't always correctly match the value that the miner then gets from the /var/local/apollo/hwmon/reg_voltage file that gets updated. As an example, both 743.6 mV and 747.75 mV result in reg_voltage being set to 24 so there's no change being done even when on of the values is smaller in the user interface. Then sometimes one increment results in reg_voltage being decreases by 2 instead of 1. For example, 739.45 mV gives reg_voltage 23 but the next step 735.3 mV results in reg_voltage 21. This results in some voltage steps not being available for selection from the user interface. These issues repeat few times within the tested range and can be seen as missing reg_voltage values in the table below.

I was also missing a button to reset the bfgminer stats back to zero (="feature request" ) so that it would be faster to see what the error rate is. Without stats reset, you'll be looking at the full runtime average. As a workaround, I accessed the bfgminer screen from the command line and executed a stats reset directly from its interface after every voltage change. That also resets the stats in the web interface.

Here are finally the steps I repeated during about 30 minutes until I found the lowest usable voltage:

1) drop voltage by one increment and press save
2) verify from /var/local/apollo/hwmon/reg_voltage and power meters that some change was applied
3) reset bfgminer stats
4) give the stats 1-2 minutes to stabilize
5) record the values for later analysis
6) if error % stays below 1-2% then go back to step 1

The results



With my unit, the error % started increasing at 689.65 mV and 685.50 mV was clearly too low. As a result, I've set the voltage to 697.95 mV. This gave me a reduction of about 20W when looked from the wall socket side while still keeping the hashrate exactly the same. Also the temperature dropped from around 60C (forgot to record the exact initial value) to 54C which would make the unit produce less noise if the automatic fan is used. As an interesting side note, the voltage increments appear to match exactly 0.1A changes at 12V on the unit side.

The lowest possible voltage for a given frequency is likely to be somewhat unit specific and therefore using the lowest value I got may not produce the same end results. That's why the steps above should be followed if something like this is tried. Having a power meter or two isn't really mandatory but having at least one helps to give some idea what the power usage is before and after.

Re-flash the sd card with the latest firmware. That will erase all settings and give you a clean start.

At some point when lowering the voltage, the hardware error rate will start increasing but nothing else should happen. Just in case you manage to still trip some undocumented failsafe and the unit ends up in a reboot loop due to the test settings having been saved, you'll still always have the option to re-flash the sd card and return back to the default settings.

Note that it may take some minutes for the hardware error rate to stabilize so don't be in too much hurry when making voltage changes.

Were the stock ECO values changed at some point?

Looking from the MCU side file /var/local/apollo/hwmon/reg_voltage with the current firmware (in ECO mode), I can see it output 28, which according to
(from /opt/apolloapi/src/configurator.js) results in 760 mV.

As you can probably guess from the lack of such details from the first page instruction posts, this isn't officially supported and falls to the category of "do only if you know what you are doing": ssh with username 'futurebit' to the Apollo IP, default port 22 using password 'futurebit'.