Topic: Official FutureBit Moonlander 2 Driver and Support Thread - page 46. (Read 71725 times)

I found that if the MIners are pointing at vardiff ports and they start to change th difficulty often the ML2s will slowly decrease hashrate to 0 and not auto-restart. So i spend my time trying to find the right dfficulty on the port to match the miner and get enough shares to be meaningful. Try as low as you can go on XVG and look for a fixed diff that works on Nyancoin and see if that helps stability.

Not really, just whatever system limit for USB devices is, which is probably around 255. Im sure the pi would start choking way before then.

Check the back heatsink, it could have not been applied correctly. Just put some pressure on it and make sure its stuck on there well.

Is there any limit to how many can be run off a Pi3b with a powered hub?

After receiving a better powered hub today i've started tuning the 3 moonlanders which i currently have.

They are all running stable at 832 clock speed. I've copied the setting for core voltage and memory so all 3 are set in the same way.

HW error rates are at 0.38, 0.06 and 0.94% so thats nice and they are hashing along at ~4.70mh/s each. Quite happy with that figure.

One 'issue' though, 2 of the MLD's reach a temperature of about 51-54 degrees celsius. The third goes up to 72-75 degrees celsius. I've already ordered some external fans so that should bring it down a couple of degrees but other than that, any suggestion as to why 1 of them is running so hot?

Thanks for any ideas

I've been toying with about 10 moonlander2's for the past few weeks and have noticed a trend.
several have declining hash rates, that is a device will start at say 4.68 Mh/s and with every refresh the hash rate declines a little until the device is hashing a a few hundred Kh/s or in some cases 0.0Mh/s.

im using two systems to test a RasPi3 with a 49 port block eruptor USB hub and a win 10 Pc with A 13 port Anker hub.
I don't think I have a USB power issue.
HW error rate is under 2.5%
Also I never get the ASIC has stopped hashing message, just a slow decline.

Thoughts or ideas?   

I always thought it would be a nice little Arduino project to pwm control the fans and regulate them via a temp sensor glued onto each heatsink.

The fan should start working the second you plug it into ANY usb port, as the green led comes on. You don't have to run bfgminer. Note that in some circumstances the fan can be really quiet (I think especially if it is facing downwards). Make sure to double check (I sometimes touch the fan on the backside just to feel), Also check and press on the little white connector, just to make sure it is making proper contact (normally that should always be the case). Also, without power, make sure that the fan can spin freely, if necessary loosen the 2 screws that hold the fan onto the heatsink a little (just a little).

No red LED flashing usually means they have stopped mining, but you will also get a notification in bfgminer saying they have stopped mining and it should restart them.

Sounds like your hub is not providing enough power. Try plugging one at a time and run it at stock 600mhz or below. If it works fine then its a power issue.

Stock Fans are dumb and are regulated via voltage. @ 5v they reach about 10k RPM. If your replacement fan has a third yellow wire, you can control it via PWM signal, but that would require and external PWM fan controller.

HI I hope you are well.
I was hoping for some help/ info. I am new at this.
I purchased 2 moonlanders 2 Iand  have managed to get my two Moonlanders going using your instructions (they are running on a Pi 3 externally powered hub) and i can monitor them.
So far I have tried to mine nyancoin from multiple pools and also XVG.
When I first execute the BFGMiner  i get them mining with  thered led flashing, however, within a minute or two the difficulty on the block goes up and my moonlanders seem to stop mining, green led ok, no red led I have tried the lower difficulty ports on the sites and I have tried changing the difficulty in the start shell script too.

Do you have any ideas?? Are they still mining or have they been frozen out. Is there a work around.

any info would be great

these are cool little machines

thanks

Do you mind sharing the 3d model?
Regards,
ac1dbit

Hello,


 I have a couple MLDs that NO MATTER what combination of frequency or pot adjusting I do, they don't get over 2.5 mh.  I'm really frustrated....  What can I do??

Im still wondering this myself. Does anybody know?

You can look at the mld-bfgminer source code to see the interface commands (so-called MLD driver), i.e. the commands that are used to talk to the MLD. That's effectively what makes the MLD run. Page 1 gives the link to the code including source.

Pi Update 2:

So for those interested.

I am pretty sure it is not power but an issue when the communication. The ML2s trip-up when the pool and Miner get out of sync (crude so more elegant explanation welcome!).

So i am mining a lowdiff coin on a vardiff port. If i put it on med-diff start on the var-diff or low on the vardiff, the ML2s quickly start throwing accepted shares at the pool but just as quickly start to mount up the hardware errors, or start to slow down. This coincides with old share or pool issued old block messages at times, but can also be when the pool starts shifting difficulty a lot.

If i mine a higher difficulty altcoin or using the high vardiff port or a high fixed-diff port, errors remain below 1% for all ML2s at the higher 768 Hz frequency.

As everything else is the same it is pointing strongly towards communication.

When mining a low diff altcoin that is finding blocks really fast on the pool the setup will still get out of sync, but at least i am starting to see a pattern.

Most likely this is my kit, and i am sure more seasoned miners may have figured this out, but if it helps a fellow newbie then hopefully there is some help in here.

bye for now

Quick footnote. Since writing this initially some 5 hours ago i have the system stable on a more difficult setting on same altcoin.  definetly some for of synch issue between BFGminer and the pool.

Update on the Pi experiment.

So i got two running fine then added a third unit.

The issue i get is that just now i get mining at 20 minute intervals before the ML2's start to effectively start hashing.

I have tried 2 units and messing with the clock frequency but same issue.

Problem seems to be if the miner gets out of synch with the pool - so i get a steady 10-20 minutes now at about 4.3MH/s but after the 20 minute mark i have to reset which takes 2-3 times to get all three hashing (or two when i unplugged one).

I know the most common error is power. I am using a 7 port Anker 60W unit with only the 3 ML2s on it so i would have hoped this would be no issue. I have also tried with 2 rather than 3 with no impact unless it is the maximum draw per USB port that is the issue? For info the pot slots are vertical when tuning - running MLD of 768.

I will play with the pots now and turn them down a litle to see if this stabilises issues.

In the meantime is there a config option that allows a restart to happen when hash rate hits 0 or kH/s so i dont have to keep monitoring it?

thanks

Note: In the time it toook me to write this i have had to reset again!

No firmware, as it is an ASIC miner. If you want to look at how these things work, there's a good chance the individual cores run a version close to this FPGA implementation, but of course at higher clock rates and there are 64 of these in the chip:

https://github.com/kramble/FPGA-Litecoin-Miner

The 'controller' is just a USB to Serial interface to the ASIC, nothing to see there

Without looking at the chip's architecture, I would think the firmware is 'masked' or 'etched' onto the chip during manufacture, not blown on afterwards.  A very sophisticated lab could possibly look at the firmware, but it may be easier to ask the manufacturer for the details.