Official FutureBit Apollo BTC Software/Image and Support thread

[WLColsher]

Two Issues:

1: I can't load the pool settings from the UI. The page just has a spinner.
2: Pools are inactive. The Apollo BTC is blinking red, but the pool status is inactive with no hash rate.

Background: Recently had a power outage. Seems that this behavior occurred afterwards.
Background: All other functionality seems to work with the Apollo BTC besides changing the pool and actually mining.

Any help would be appreciated!

Regarding number 2, I think if the Apollo loses connection it doesn't seem to reconnect by itself but it keeps mining locally. I remember having an issue like that one time, and just restarting the miner software solved it.

The power outage may be the issue here. These miners want to be shut down properly so it may be that you'll need to re-flash the SD card. There are instructions and links to image files back at the beginning of this topic.

[1714780773]

1714780773

[1714780773]

1714780773

[Sledge0001]

I am baffled by one thing and would love to hear feedback on this.

Even though I am adding additional units (As of this morning I now have 1 full and 3 standards hashing away perfectly and effortlessly on Turbo) I noticed the pool difficulty seems to stay the same as with just one unit.

The CPU usage on the full node is amazingly low as it is appears to only be at 4% while running the full node as well as 3 standards. Which means the full node as more than enough processing power based on what I can see to run and expand on.

Is there a way to configure these so that the hashing power is combined or used together in such a way that improve the share difficulty from the pool?

For instance with my 12 x Compac F's I have total hashpower on one machine of 4.6T. Using Kano's cgminer that roughly receives a difficulty from CK's solopool is 4917.  They all show up as 1 worker.

The 4 Apollo's are pushing 12.2T but the difficulty seems to show only 2660 which I assume is just the result of a single hashboard? Could this not be combined in the gui to include the others if so?

The pool does see each unit as its own worker however it combines the hashpower under 1 name see here:
   "workername": "xxxxx.xxx",
   "hashrate1m": "13.8T",
   "hashrate5m": "12.2T",
   "hashrate1hr": "7.37T",
   "hashrate1d": "5.62T",
   "hashrate7d": "2.6T",
   "lastshare": 1653444284,
   "shares": 515238645,
   "bestshare": 272288676.814902,
   "bestever": 272288676

So my question is is the 2660 difficulty just being reported for the full board or are all boards running at a total of 2660? Or is this really getting a difficulty of 2660 x 4?

Ideas?

[nullama]

OK, I've found something not ideal with the Apollo that might be fixed with an updated software.

If you're mining, and then suddenly your connection to the internet stops working (for example you need to restart your router, etc), the connection to the pool is lost forever, it's never reconnected.

Even after the internet comes back, the miner will show the blinking lights as normal and everything would look like it's working, but there's no actual activity in the pool. This is not great since you can lose basically hours, days, or more worth of mining if you're not monitoring the pool itself.

I tried stopping the miner software, and restarting it, but still there was no activity in the pool.

Only after I restarted the host, which is a Raspberry Pi by the way, and the miner was disconnected by the reset, eventually it came back online.

[n0nce]

OK, I've found something not ideal with the Apollo that might be fixed with an updated software.

If you're mining, and then suddenly your connection to the internet stops working (for example you need to restart your router, etc), the connection to the pool is lost forever, it's never reconnected.

Even after the internet comes back, the miner will show the blinking lights as normal and everything would look like it's working, but there's no actual activity in the pool. This is not great since you can lose basically hours, days, or more worth of mining if you're not monitoring the pool itself.

I tried stopping the miner software, and restarting it, but still there was no activity in the pool.

Only after I restarted the host, which is a Raspberry Pi by the way, and the miner was disconnected by the reset, eventually it came back online.

That's interesting; I'm still running the provided OS on my 'full package' and I do have short internet dropouts from time to time (one very recently, just a few days ago). My uptime is spotless and in the pool's dashboard everything looks alright. But in theory it should be the same binary, is it not?
I'll install custom OpenSUSE on it fairly soon, with this binary and will keep an eye on this issue to see if it happens on my system, too.

[nullama]

~snip~
That's interesting; I'm still running the provided OS on my 'full package' and I do have short internet dropouts from time to time (one very recently, just a few days ago). My uptime is spotless and in the pool's dashboard everything looks alright. But in theory it should be the same binary, is it not?
I'll install custom OpenSUSE on it fairly soon, with this binary and will keep an eye on this issue to see if it happens on my system, too.

Interesting. Note that if you have a full package the miner is connected directly through the IOs of the board, not through USB. This potentially could be the reason why it keeps working for you, but not for me. Maybe they do manage some kind of reset in the direct connection, or something to that effect, that is not done with USB.

[vsc-miner]

Full Node finally finished the blockchain sync. Any guess as to when we will need to upgrade the 500gb to something bigger?

2 years

Full Node disk space additions without address index and also ignoring blocks/index:

Dec 6.1G
Jan 6.4G
Feb 5.8G
Mar 6.4G
Apr 5.8G
May 6.4G

So going on 6.1G a month and a 512GiB drive holds 460GB in disk space (and ignoring anything else there)
and current is 383G, the answer would appear to be 12.6 months - if you let it fill up and didn't care about it failing due to that.

Just hope there's way less transactions due to a lower BTC price, and I guess then it may make it to 2 years?

Hi FutureBit gang,

I have a Full BTC Node running fantastically, mostly unattended except for the few times I got it dusted off. I noticed that disk is almost full with space remaining at 3.31%. I am wondering if there is a recommended upgrade path and instructions I should follow. Thanks for your help!!

Fidel Vanegas


PS: Seems like phiplipma1957 has already cloned the original 500GB into a 1TB NVMe disk using a replicator. I did not see any more updates on this issue so I can just assume it did work just fine. Here the BOM for the gig from Philip ...

this ssd
https://www.amazon.com/gp/product/B089DNM8LR/ref=ppx_yo_dt_b_asin_title_o02_s00?

this cloner
https://www.amazon.com/gp/product/B08LPDTZGQ/ref=ppx_yo_dt_b_asin_title_o03_s00?

[nullama]

@jstefanop

Good morning,

On Futurebit Apollo LTC, there is a switch in settings which give access to Api. ("api-allow"). Is there a similar feature on the interface of the Futurebit Apollo BTC?

Thanks in advance.

They use different software, so there's no api-allow option as far as I know in the Apollo BTC.

But if you're interested in reading the data from the miner, you can get that from a text file that gets written in the same folder of where the miner is. After you run the miner, a file with a name like this is created: apollo-miner.4A122E121471674B52383109. If you open it you'll see json encoded data in clear text. The "official" web UI uses that file to present it in a nice way in the browser. You can just read that file and you'll get similar data that the api in Apollo LTC sent.

[n0nce]

~snip~
That's interesting; I'm still running the provided OS on my 'full package' and I do have short internet dropouts from time to time (one very recently, just a few days ago). My uptime is spotless and in the pool's dashboard everything looks alright. But in theory it should be the same binary, is it not?
I'll install custom OpenSUSE on it fairly soon, with this binary and will keep an eye on this issue to see if it happens on my system, too.

Interesting. Note that if you have a full package the miner is connected directly through the IOs of the board, not through USB. This potentially could be the reason why it keeps working for you, but not for me. Maybe they do manage some kind of reset in the direct connection, or something to that effect, that is not done with USB.

Good point! I'll add this to my list of things to test and try out. I'm not sure I will get the internal connection going with the custom Linux install, so in that case a short micro-USB cable will have to be used and might present the same issue. I'll definitely make sure to still test both options if internal connection does work, though.

[Sledge0001]

I am baffled by one thing and would love to hear feedback on this.

Even though I am adding additional units (As of this morning I now have 1 full and 3 standards hashing away perfectly and effortlessly on Turbo) I noticed the pool difficulty seems to stay the same as with just one unit.

The CPU usage on the full node is amazingly low as it is appears to only be at 4% while running the full node as well as 3 standards. Which means the full node as more than enough processing power based on what I can see to run and expand on.

Is there a way to configure these so that the hashing power is combined or used together in such a way that improve the share difficulty from the pool?

For instance with my 12 x Compac F's I have total hashpower on one machine of 4.6T. Using Kano's cgminer that roughly receives a difficulty from CK's solopool is 4917.  They all show up as 1 worker.

The 4 Apollo's are pushing 12.2T but the difficulty seems to show only 2660 which I assume is just the result of a single hashboard? Could this not be combined in the gui to include the others if so?

The pool does see each unit as its own worker however it combines the hashpower under 1 name see here:
   "workername": "xxxxx.xxx",
   "hashrate1m": "13.8T",
   "hashrate5m": "12.2T",
   "hashrate1hr": "7.37T",
   "hashrate1d": "5.62T",
   "hashrate7d": "2.6T",
   "lastshare": 1653444284,
   "shares": 515238645,
   "bestshare": 272288676.814902,
   "bestever": 272288676

So my question is is the 2660 difficulty just being reported for the full board or are all boards running at a total of 2660? Or is this really getting a difficulty of 2660 x 4?

Ideas?

Okay so after some digging and tinkering it looks like if you look at the raw stats in the Full Node it does show that each hashboard is getting its own difficulty.

BTW... I'm now up to 2 Full's and 6 standards and I must say again so simple to setup its just amazing!!!

Still looking to expand further!!!

[jstefanop]

@jstefanop

Good morning,

On Futurebit Apollo LTC, there is a switch in settings which give access to Api. ("api-allow"). Is there a similar feature on the interface of the Futurebit Apollo BTC?

Thanks in advance.

They use different software, so there's no api-allow option as far as I know in the Apollo BTC.

But if you're interested in reading the data from the miner, you can get that from a text file that gets written in the same folder of where the miner is. After you run the miner, a file with a name like this is created: apollo-miner.4A122E121471674B52383109. If you open it you'll see json encoded data in clear text. The "official" web UI uses that file to present it in a nice way in the browser. You can just read that file and you'll get similar data that the api in Apollo LTC sent.

Yes that file is essentially the Apollo-BTC api. You can just ssh and pull /opt/apolloapi/backend/apollo-miner/apollo-miner.* and parse the json and do what you like with it!

[dupdeedo]

Hi All,

Thanks for the help.
Issue is resolved.

After flashing the drive a couple times, the pool is actively hashing. 
I'm not sure why the first flash didn't work.

For full disclosure, I reset my router and changed the DNS to cloud flare before the second SD flash that ultimately resolved the issue.
I am not sure if my router would have had any impact. Just wanted to detail the troubleshooting steps involved.

Again, I really appreciate the communities support.

Two Issues:

1: I can't load the pool settings from the UI. The page just has a spinner.
2: Pools are inactive. The Apollo BTC is blinking red, but the pool status is inactive with no hash rate.

Background: Recently had a power outage. Seems that this behavior occurred afterwards.
Background: All other functionality seems to work with the Apollo BTC besides changing the pool and actually mining.

Any help would be appreciated!

Regarding number 2, I think if the Apollo loses connection it doesn't seem to reconnect by itself but it keeps mining locally. I remember having an issue like that one time, and just restarting the miner software solved it.

The power outage may be the issue here. These miners want to be shut down properly so it may be that you'll need to re-flash the SD card. There are instructions and links to image files back at the beginning of this topic.

[poonasor]

does anyone know why one hashboard has a lot more errors than the rest?

This is higher than normal usually its around 23%

[Sledge0001]

Can anyone tell me if is it possible to take a "Full" version and make it a "Standard" version?

I have the opportunity to purchase another "Full" unit however I already have 2 "Full" units running and really want to use those as controllers to control more standard units.

Is this possible?

TIA.

[nullama]

Can anyone tell me if is it possible to take a "Full" version and make it a "Standard" version?

I have the opportunity to purchase another "Full" unit however I already have 2 "Full" units running and really want to use those as controllers to control more standard units.

Is this possible?

TIA.

The main difference between the Full version and the Standard version is one Linux device similar to a Raspberry Pi but more powerful.

The Full and Standard units come with the same BTC Miner. If you buy a full version you can just ignore the Linux device if you want to, and then it would be a Standard unit (hopefully you're getting them cheaper than Standard versions).

On the other hand, you can supply your own Raspberry Pi device and connect to the USB connector of a Standard unit, making it "Full".

Basically it is possible to turn a Full into a Standard, and vice-versa, after you bought it.

Having said that, I'm still getting pool disconnections when the Internet restarts with a Standard unit that doesn't seem to be present in the Full unit, so there's something going on there. Probably because of the USB connection instead of the direct GPIO connection of the Full.

[jstefanop]

does anyone know why one hashboard has a lot more errors than the rest?

This is higher than normal usually its around 23%

A few units display abnormally high error but this is mostly a display issue. If you hashrate is where it should be (which it is for your unit) you're fine.

Can anyone tell me if is it possible to take a "Full" version and make it a "Standard" version?

I have the opportunity to purchase another "Full" unit however I already have 2 "Full" units running and really want to use those as controllers to control more standard units.

Is this possible?

TIA.

Yes all units are built from the same "base" standard unit, the Full package simply has the controller and SSD installed. You can remove the controller and use it as a standard unit via its USB port.

[digg_er]

I did some detailed cleaning of my full unit by removing cover, unmounting fan and taking dust out.
By doing so I realized it's not necessary, because most of dust stays outside and it's enough to make sure that visible side edges of radiator are clean. Anyway...

My PI board stopped booting now

I tried re-flashing with Apollo image, Armbian image (for Orange Pi4), but I still get no HDMI output. Red and Green LEDs are lighted up (w/o blinking).
Do I need serial cable to investigate or is there something I can do without cable?

[digg_er]

I did some detailed cleaning of my full unit by removing cover, unmounting fan and taking dust out.
By doing so I realized it's not necessary, because most of dust stays outside and it's enough to make sure that visible side edges of radiator are clean. Anyway...

My PI board stopped booting now

I tried re-flashing with Apollo image, Armbian image (for Orange Pi4), but I still get no HDMI output. Red and Green LEDs are lighted up (w/o blinking).
Do I need serial cable to investigate or is there something I can do without cable?

UPDATE: I can boot Apollo, but it takes ages (about 30 minutes).
SDD drive is not mounted automatically. I can do it via mount /dev/nvme0n1p1 /media/nvme. I cannot save settings through UI - I get Internal error.
Device is hashing to default pool and user

There are strange errors in DMESG (I listed all in red):

[   20.926563] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   21.125371] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   21.125602] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   21.126264] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01        -a41d86bd es7.c5.n4.a3
[  193.002541] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[  193.002579] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22

OK, I think I broke something on the PI board while unscrewing. JStefano, can I replace it with Orange PI4 LTS, or does it need to be original PI4?

[notabeliever]

I did some detailed cleaning of my full unit by removing cover, unmounting fan and taking dust out.
By doing so I realized it's not necessary, because most of dust stays outside and it's enough to make sure that visible side edges of radiator are clean. Anyway...

My PI board stopped booting now

I tried re-flashing with Apollo image, Armbian image (for Orange Pi4), but I still get no HDMI output. Red and Green LEDs are lighted up (w/o blinking).
Do I need serial cable to investigate or is there something I can do without cable?

I ran into the same problem and determined it is the Year old Controller board. Both my units run nicely using a PC so I know its the controller .
edited...6-7-22
Several post above I had problems flashing card and getting controller to boot and through trial and error........ The cards will flash easily. Using Windows 7 and raspberry imager.
Though my problem is controller.
upon taking Apollo apart  I retightened loose fan on controller(suggest locktight).  controller will boot into its os, after setting up software and playing around with linux, 3 minutes later the sytem goes dark. Controller doesn't boot into os.

Could be HDMI ?Controller overheating?  Everyday I get it to boot when its cold for 3 minutes?

With that said having binaries is working on a windows PC and both miners are hashing.


@ jstefanop
Nice job on the build as I took it apart and put it together it really was thought out and designed impeccably.
also I need windows binaries  to work on Windows server2012 and when plugged in it finds usb device put needs a driver. Do you have a driver to install using device manager?

[n0nce]

Hey @jstefanop and @crypto_curious, I'm trying to mount the NVMe from a custom Linux install on another microSD card and it just doesn't show up in lsblk or elsewhere.
Does the 'Futurebit OS' have a special driver included or anything like that to recognize the small daughterboard which connects the NVMe SSD to the SBC?

Edit: It seems an OpenSUSE / JeOS specific issue. With ARMbian for Orange Pi 4 it works nicely.

But if there's any information you can share about accessing the hashboard through the internal connection, I'd really appreciate it!

Yea you could technically run the whole UI off a rasberry pi (or any ARM SBC with a UART port for that matter), or simply run it off the USB port if you dont want to deal with setting up the internal UART. I should probably post the board connector pinout for anyone that wants to do this. Will probably release a pi image at some point as well (or at least update the installer so its a one step RPI installation).

Oh, it's internal UART, alright. Would it be possible to know how to 'activate' it?

I can see on 'Futurebit OS', it's activated, while on my Armbian SD card it's not.

Code:

root@futurebit-btc:/boot/dtb/rockchip/overlay# dmesg | grep tty
[    0.000000] Kernel command line: root=UUID=98eceb4e-f6db-4229-bee6-b02137879d0c rootwait rootfstype=ext4 bootsplash.bootfile=bootsplash.armbian console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=37857158-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    0.001497] printk: console [tty1] enabled
[    2.729455] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 47, base_baud = 1500000) is a 16550A
[    2.729630] serial serial0: tty port ttyS0 registered
[    2.730549] ff1a0000.serial: ttyS1 at MMIO 0xff1a0000 (irq = 48, base_baud = 1500000) is a 16550A
[    2.731757] ff370000.serial: ttyS4 at MMIO 0xff370000 (irq = 50, base_baud = 1500000) is a 16550A

I need stock Armbian to recognize ttyS1...

Edit 2: I changed a few things as I noticed you swapped uart1 and uart2 in your Futurebit OS.

Code:

sudo dtc -I dtb -O dts /boot/dtb/rockchip/rk3399-orangepi-4.dtb -o /boot/dtb/rockchip/rk3399-orangepi-4.dts
sudo vim /boot/dtb/rockchip/rk3399-orangepi-4.dts
sudo dtc -I dts -O dtb /boot/dtb/rockchip/rk3399-orangepi-4.dts -o /boot/dtb/rockchip/rk3399-orangepi-4.dtb

Now, a ttyS1 device shows up, but I'm not sure everything's correct. The miner binary doesn't recognize it yet. The IRQ is probably wrong (wrong pin).

Code:

:% dmesg | grep tty
[    0.000000] Kernel command line: root=UUID=3398764f-7f34-4184-b0c2-c76e0b416579 rootwait rootfstype=ext4 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=c257b905-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    0.002018] printk: console [tty1] enabled
[    1.530133] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 44, base_baud = 1500000) is a 16550A
[    1.530315] serial serial0: tty port ttyS0 registered
[    1.531269] ff1a0000.serial: ttyS1 at MMIO 0xff1a0000 (irq = 45, base_baud = 1500000) is a 16550A
[    6.630819] systemd[1]: Created slice system-getty.slice.
[    6.635376] systemd[1]: Created slice system-serial\x2dgetty.slice.
[    8.463791] systemd[1]: Found device /dev/ttyS2.

[jstefanop]

Hey @jstefanop and @crypto_curious, I'm trying to mount the NVMe from a custom Linux install on another microSD card and it just doesn't show up in lsblk or elsewhere.
Does the 'Futurebit OS' have a special driver included or anything like that to recognize the small daughterboard which connects the NVMe SSD to the SBC?

Edit: It seems an OpenSUSE / JeOS specific issue. With ARMbian for Orange Pi 4 it works nicely.

But if there's any information you can share about accessing the hashboard through the internal connection, I'd really appreciate it!

Yea you could technically run the whole UI off a rasberry pi (or any ARM SBC with a UART port for that matter), or simply run it off the USB port if you dont want to deal with setting up the internal UART. I should probably post the board connector pinout for anyone that wants to do this. Will probably release a pi image at some point as well (or at least update the installer so its a one step RPI installation).

Oh, it's internal UART, alright. Would it be possible to know how to 'activate' it?

I can see on 'Futurebit OS', it's activated, while on my Armbian SD card it's not.

Code:

root@futurebit-btc:/boot/dtb/rockchip/overlay# dmesg | grep tty
[    0.000000] Kernel command line: root=UUID=98eceb4e-f6db-4229-bee6-b02137879d0c rootwait rootfstype=ext4 bootsplash.bootfile=bootsplash.armbian console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=37857158-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    0.001497] printk: console [tty1] enabled
[    2.729455] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 47, base_baud = 1500000) is a 16550A
[    2.729630] serial serial0: tty port ttyS0 registered
[    2.730549] ff1a0000.serial: ttyS1 at MMIO 0xff1a0000 (irq = 48, base_baud = 1500000) is a 16550A
[    2.731757] ff370000.serial: ttyS4 at MMIO 0xff370000 (irq = 50, base_baud = 1500000) is a 16550A

I need stock Armbian to recognize ttyS1...

Edit 2: I changed a few things as I noticed you swapped uart1 and uart2 in your Futurebit OS.

Code:

sudo dtc -I dtb -O dts /boot/dtb/rockchip/rk3399-orangepi-4.dtb -o /boot/dtb/rockchip/rk3399-orangepi-4.dts
sudo vim /boot/dtb/rockchip/rk3399-orangepi-4.dts
sudo dtc -I dts -O dtb /boot/dtb/rockchip/rk3399-orangepi-4.dts -o /boot/dtb/rockchip/rk3399-orangepi-4.dtb

Now, a ttyS1 device shows up, but I'm not sure everything's correct. The miner binary doesn't recognize it yet. The IRQ is probably wrong (wrong pin).

Code:

:% dmesg | grep tty
[    0.000000] Kernel command line: root=UUID=3398764f-7f34-4184-b0c2-c76e0b416579 rootwait rootfstype=ext4 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=c257b905-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    0.002018] printk: console [tty1] enabled
[    1.530133] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 44, base_baud = 1500000) is a 16550A
[    1.530315] serial serial0: tty port ttyS0 registered
[    1.531269] ff1a0000.serial: ttyS1 at MMIO 0xff1a0000 (irq = 45, base_baud = 1500000) is a 16550A
[    6.630819] systemd[1]: Created slice system-getty.slice.
[    6.635376] systemd[1]: Created slice system-serial\x2dgetty.slice.
[    8.463791] systemd[1]: Found device /dev/ttyS2.

You have to use our custom DTS, the UART port we use is not activated by default on Armbian.

If your doing custom stuff you can easily use any active UART port on any board/sbc. All you have to do is change the /dev/ttySx port number the app uses to start the hashboard via internal UART (its in /opt/apolloapi/backend/apollo-miner files).


FYI below is the board pinout for anyone that wants to tinker with rpi or any other SBC (Pin #1 is towards the bottom of the board). You can ignore the BOOT pin, all you have to do is reset the board using the RES pin (low then high), and start the miner program. The 5v pin can provide up to 15 watts of power so it can power most SBCs boards internally.