I just got my Apollo with pre-burned image flash card installed. Plugged both PCIE power connectors in and LAN cable..
Just getting flashing yellow light on the front and don't see a new device on the LAN.
Any ideas for trouble shooting?
Thanks
Is the front yellow flashing slowly or fast? Do the leds around the ethernet connector show any signs? Is there a dhcp server in the LAN? How long have you waited for it to start? It's a fast flash. The LEDS come on initially then turn off. Yes there is a DHCP server on the network. Waited plenty Thats a network issue, either your local LAN is not providing an IP address or it cant connect to the pre-configured pool. Have you tried logging into your router and checking whether you see a new IP/Device show up there? |
|
|
|
This looks like a great form factor for home mining!
Do I understand correctly that the PCB houses 3x9 chips underneath that big heatsink?
I wonder how you lay out 27 chips in a square space...
Did you do the ASIC design in-house?
Any plans to branch out to other PoWs in future?
Several other memory oriented PoW have daily issuance comparable to scrypt,
like Equihash and Cuckoo Cycle.
Yes its 27 ASICs in a 3x9 Parallel block/serial configuration. It wasn't easy that's for sure. We are exploring whether we want to concentrate on scrypt or branch out to more algos so don't have anything to announce now. |
|
|
|
|
Check out my Apollo miner in my sig which was released a few months ago. It might not be the fastest, but its currently the most efficient scrypt miner out ~1 W/MH.
|
|
|
|
Hey everyone,
The fan on one of my moonlanders gave out a few days ago. I noticed that a few people have posted links to replacement fans earlier on this thread. I noticed however that these replacement fans do not come with a connector. That is, they come with bare wires on them. Would you happen to know where I can get the appropriate connector or where I can find a replacement fan with the correct connector?
Thanks!
You can message FutureBit on Facebook Messager and order fans that way. Thanks! I'll give that a try. I keep putting of listing replacement fans on shop.futurebit.io...ill try and put them up this week. |
|
|
|
Power question:
The original data posted on Futurebit says "Two Six Pin PCIE power connectors for wide-range of power draw (only one is needed in ECO mode)". I've been running in "Balanced" mode with just one PCIE connector used. I just felt the power wires at the Apollo back and they are a little warm, not hot at all. I'd like to leave this running in Balanced mode while I'm away a few days - should I worry? Do both power connectors need to be used for Balanced mode?
My PSU is very adequate (Raidmax Cobra RX-700AC-B 700W 80 PLUS) - runs quiet and cold. Anyone else running in Balanced mode with just 1 power connector?
I'd like to save the 2nd PCIE output for my 2nd Apollo.
As long as the wire is not hot it should be fine, but it comes down to the wire gauge used by that PSU, which I assume will probably be 18 gauge. Balance uses about ~150 watts, which is pushing it for a single 6pin PCIE. I personally would not run it on one cable unless its at least 16 gauge, and even then it comes down to safety and it will always be safer to run it on two. I obviously cant recommend anything other than having both plugged in but im sure others can chime in  |
|
|
|
HELP! OK, with that out of the way. One of my Apollos seems to be having issues. bfg starts and then stops. I have replaced the SD card and removed all pools, twice. With just the donation pool looking at the sudo screen -dr miner I see bfgminer 5.5.0-41-gb0cd450 - Start: [2019-02-27 00:02:21] - [ 0 days 00:00:02]
[M]anage devices [P]ool management [S]ettings [D]isplay options [H]elp [Q]uit
Pool 0: us.litecoinpool.or Diff:1 +Strtm LU:[00:02:21] User:jstefanop.a1
Block: ...5f3733dbdb447146 Diff:8.25M (59.04T) Started: [00:02:21] I:?
ST:3 F:0 NB:1 AS:0 BW:[546/119 B/s] E:0.00 BS:0
--------------------------------------------------------------------------------
APL 0: | 0.0/ 0.0/ 0.0 h/s | A:0 R:0+0(none) HW:0/none
--------------------------------------------------------------------------------
[2019-02-27 00:02:14] Loaded configuration file /opt/bfgminer.conf
[2019-02-27 00:02:15] Probing for an alive pool
[2019-02-27 00:02:21] Pool 0 stratum+tcp://us.litecoinpool.org:3333 alive
[2019-02-27 00:02:21] Pool 0 is hiding block contents from us
[2019-02-27 00:02:21] Network difficulty changed to 8.25M (59.04T)
[2019-02-27 00:02:21] Stratum from pool 0 detected new block
[2019-02-27 00:02:21] API running in IP access mode on port 4028 Then something pops up quickly that I can't read and then. [screen is terminating] and I'm back at the prompt. It does the same if I put in my own pools. Anything I can look at? -Dave Is the dashboard loading fine? Whats the last state you had the miner in before this happened? |
|
|
|
I was playing around with making this thing even more quiet. My stock fan is a little noisy. Might have just gotten a noisier one out of the bunch. I strapped on a silent noctua fan onto a fan controller and threw it on top of the heat sink. Ran it on eco mode. Had it sitting at 60 Degrees pretty much completely silent. But If i connect the noctua fan connector onto the apollos board, the miner will shut off after 45ish seconds. Is that the apollo just telling me to stick with the stock fan? Lol. Just curious if i could make the switch.
Which Noctua fan model did you use and what was the fan speed setting in Apollo? The Apollo comes with an around 6k rpm fan producing a maximum airflow of about 93 m³/h (if I found the right specs). For comparison, the Noctua NF-A9 PWM is 2k rpm and about 78.9 m³/h. Most likely the shutdown you got is caused by a failsafe, possibly either the fan rpm not being connected, the fan rpm being too low to detect or the fan rpm being lower than some hardcoded minimum. Set the fan speed manually to 100% before swapping to the Noctua fan and see if that helps. If that keeps the miner running then you can start experimenting with lower fan speed settings up to the point that the failsafe kicks in again or the temperature gets too high. Yea the hardware controller is hardcoded with failsafes based on the stock fan. If you use anything below a 3-4k RPM fan the controller will shutdown the miner because it thinks something is wrong with the fan. I won't be supporting any third party fans, I could possibly but in a "disable fan monitoring" option, but I wouldn't include that for at least several more months. The stock fan is a 6k RPM 120 CFM fan. That noctua tops out at ~ 45 CFM which is probably enough for only ECO mode cooling. |
|
|
|
|
Yea sorry guys I know I need to update the binaries for the pi that fixes this issue...you can just pull the latest source off the repo and compile though.
|
|
|
|
Just got mine in today and it was a very easy setup. Thanks for bringing this tech home. Runs beautifully, as well as the 6 MoonLanders and 2 L3+ I've got in my mini setup. Thanks again, really really nice work.
Thanks for coming on here and posting! |
|
|
|
if it was at least a trade off between them, vega56 1800mhs, rvii 2800mhs on monero, rvii is 50% shorter on computing performance than it was supposed to be and yet it costs 50% more, not worth, brainwashed trolls will make it to be worthy, trust me.
Give it time, Mr Doom & Gloom. Unoptimised drivers, unoptimised miners - that's what we're mainly dealing with currently. Vegas were allegedly crap until somebody found out they weren't, remember? Well the Radeon VII isn't running on a new architecture. It's essentially a Vega 56 on a smaller node with higher bandwidth and memory bus. The smaller node allows it to clock at the 2-2.1Ghz range giving it that big boost in performance. I doubt drivers will do much more than we are seeing already. The performance numbers make sense based on what we know from Vega 10 (which is essentially Vega 20 at 14nm). This, nothing new about it, actually i think vega 14nm is way more powerful given is 14nm and i dont think drivers will help it either. If it was a pure die shrink then monero was supposed to have hashrates around 4000mhs which is not the case. I'm a lot more interested in navi. There is no reason why Radeon VII cant hit 4k monero. Its doing 90MH eth. Something in the cryptonight kernel is not properly optimized to take advantage of the full bandwidth. Only other thing I can think of is that the algorithm is way more compute bound, so reduced number of cores is having a significant bottleneck. |
|
|
|
I read that bfgminer on Apollo is 5.5.
Any chance the rest of us could use it for ML2 on Windows, macOS, Linux? If you have binaries, that'd be awesome... but I could certainly tab a stab at compiling it if the code is available on a public git repo.
Yea ill get around to giving some love to the Moonlanders and update the binaries to latest bfgminer + fixes that I need to get in. I have obviously just had zero time. Please post this stuff in the Moonlander support thread though. |
|
|
|
Sorry for all the questions, this is on nicehash and it seems unhappy. What does Dis mean - disallowed? This is way more HW errors than I was getting on Litecoinpool. Thanks  Looks fine to me. Dis is disconnects, which is normal for nicehash. This is just the nature of mutipools, they switch around so much that you will not get the "ideal" rates you see on a straight blockchain pool. |
|
|
|
Hi
Been working on the Apollo and its a nice job but i have a couple of errors that i cant see fully addressed for my dim mind.
I am trying to run some mining on two pools i can get ML2s running on no issues as long as i use the /#skipcbcheck option.
I run the same pools on apollo then i go inactive after about 2 minutes. System is stable and i am quite happly running up the accepted shares on the donation pool.
I put in the /#skipcbcheck on the two mining pools and hardware errors go through the roof (north of 40%) and we are talking discards in the 3E7 range in a few minutes. At time hash rate will drop to a ML2 level.
take it all off reset and the donation pool runs fine.
Frustrated. Is there a command i can use that will stabilise the units on pools i want to mine? or do i need ot search for pools that surviave the cbcheck?
Thanks
Buddy_hell
If you are running on a mutipool or have failovers for different coins bfgminer is going to go crazy because it only designed for one blockchain at a time. You need to disable the donation pool, and have no failover pools if you mining anything other than Litecoin. |
|
|
|
So hey, i'm new.
I just bought the Apollo and it looks great. I understand the economics and its a hobby with a possible LT investment aspect. I was going to mine at litecoinpool, but then I saw a few posts on solo mining. I'd be interested to see where the Apollo users are mining.
Thanks.
Its a large mix. Lots of people just mine straight Litecoin on pools to support the network, others mine low diff scrypt coins (which you can collect ALOT of with this device), and rest solo mine on solo pools like ltcdice. Speaking of solo mining I hit a block on one of my dev Apollos last week  |
|
|
|
Yeah this will be third XMR fork as a miner to kick out the undesirables. I'm doing exactly what I have done in the past. A month or two prior to the scheduled fork, when the network difficulty goes sky high, I switch my Vega rig to something else. And then I hop right back on post fork.
Interesting that previous forks have seen the difficulty rise gradually before the fork, making Vegas gradually less usable, but this time it has rocketed out of control. I wonder if the 'boom and bust' cycle of XMR's forking schedule has encouraged asic devs to speed up their process, so they go full out immediately rather than ramp up secretly. I think its FPGAs this time, and a lot of them. I wouldn't be surprised if this round they simple update their bitstreams and hash rate goes back to where it was. |
|
|
|
The number in the "current hashrate" box appears to still be some sort of all uptime average instead of "right now". The uptime of my unit is now a little over 7 days and today during few hours without external network connectivity I noticed that the front led of the unit had stopped flashing red (as expected). The dashboard was still claiming the hashrate to be over 95 Mh/s when it should have shown a zero. The only thing in the dashboard (apart from the red led not flashing) that pointed to some ongoing issue was the green line below the uptime having turned red and the small "Last share" text telling how long had been from the last share.
Once network connectivity was restored, the red led came on for about 10 seconds until if went back to the normal flashing routine. At least I didn't have to reboot the unit.
Yea hash rate displayed is the pool average, and this is a more realistic number to display than what the hardware is doing, since it takes into account hardware errors, rejected shares, network downtime etc. So it more closes matches to what the pool is showing and the "real world" rate. I probably should update it to a 24hr moving average though. Im still trying to figure out the best way to deal with network downtime. Next update will put the miner in idle mode and have a better visual indication that its not getting new work (instead of just the red flashes stopping). |
|
|
|
|
Show Posts
