Official FutureBit Moonlander 2 Driver and Support Thread

[charlie137]

I was running the stick for a while without any problem, but recently all of a sudden the bfgminer log started to look like this:

 [2018-01-10 19:41:27] Accepted 005114ba MLD 0  Diff 12m/7m
 [2018-01-10 19:41:33] Accepted 002be7f3 MLD 0  Diff 22m/7m
 [2018-01-10 19:41:48] MLD 0: ASIC has stopped hashing, attempting to restart
 [2018-01-10 19:41:49] Accepted 0038776b MLD 0  Diff 17m/7m
 [2018-01-10 19:41:50] New best share: 73m
 [2018-01-10 19:41:51] Accepted 000d96a3 MLD 0  Diff 73m/7m
 [2018-01-10 19:41:51] New best share: 115m
 [2018-01-10 19:41:52] Accepted 0008abcc MLD 0  Diff 115m/7m
 [2018-01-10 19:41:56] Accepted 002f34f2 MLD 0  Diff 21m/7m
 [2018-01-10 19:41:57] Accepted 006701af MLD 0  Diff 9m/7m
 [2018-01-10 19:42:16] Accepted 0045588e MLD 0  Diff 14m/7m
 [2018-01-10 19:42:17] Accepted 00256d79 ZUS 0aq Diff 26m/7m
 [2018-01-10 19:42:17] MLD 0: Unrecognized response
 [2018-01-10 19:42:19] Accepted 00798f2c ZUS 0bs Diff 8m/7m
 [2018-01-10 19:42:29] MLD 0: ASIC has stopped hashing, attempting to restart
 [2018-01-10 19:42:32] New block: ...a64ee3d1e95b8290 diff 3.66M (26.21T)
 [2018-01-10 19:42:32] Stratum from pool 0 detected new block
 [2018-01-10 19:42:42] Accepted 00592a2d MLD 0  Diff 11m/7m
 [2018-01-10 19:42:43] Accepted 00180ccc ZUS 0bk Diff 41m/7m
 [2018-01-10 19:42:47] Accepted 006127ac MLD 0  Diff 10m/7m
 [2018-01-10 19:42:53] Accepted 005c4df2 MLD 0  Diff 10m/7m
 [2018-01-10 19:42:55] MLD 0: Unrecognized response

etc

So it still hashes, but with frequent errors and at degraded hash rate.

All settings are default, I never overclocked the miner. No configuration changes (which I know about) were made. Powered USB hub.

What could it be?

same results with powering from usb port on the machine (non hub)?

[1715280650]

1715280650

[jstefanop]

I was running the stick for a while without any problem, but recently all of a sudden the bfgminer log started to look like this:

 [2018-01-10 19:41:27] Accepted 005114ba MLD 0  Diff 12m/7m
 [2018-01-10 19:41:33] Accepted 002be7f3 MLD 0  Diff 22m/7m
 [2018-01-10 19:41:48] MLD 0: ASIC has stopped hashing, attempting to restart
 [2018-01-10 19:41:49] Accepted 0038776b MLD 0  Diff 17m/7m
 [2018-01-10 19:41:50] New best share: 73m
 [2018-01-10 19:41:51] Accepted 000d96a3 MLD 0  Diff 73m/7m
 [2018-01-10 19:41:51] New best share: 115m
 [2018-01-10 19:41:52] Accepted 0008abcc MLD 0  Diff 115m/7m
 [2018-01-10 19:41:56] Accepted 002f34f2 MLD 0  Diff 21m/7m
 [2018-01-10 19:41:57] Accepted 006701af MLD 0  Diff 9m/7m
 [2018-01-10 19:42:16] Accepted 0045588e MLD 0  Diff 14m/7m
 [2018-01-10 19:42:17] Accepted 00256d79 ZUS 0aq Diff 26m/7m
 [2018-01-10 19:42:17] MLD 0: Unrecognized response
 [2018-01-10 19:42:19] Accepted 00798f2c ZUS 0bs Diff 8m/7m
 [2018-01-10 19:42:29] MLD 0: ASIC has stopped hashing, attempting to restart
 [2018-01-10 19:42:32] New block: ...a64ee3d1e95b8290 diff 3.66M (26.21T)
 [2018-01-10 19:42:32] Stratum from pool 0 detected new block
 [2018-01-10 19:42:42] Accepted 00592a2d MLD 0  Diff 11m/7m
 [2018-01-10 19:42:43] Accepted 00180ccc ZUS 0bk Diff 41m/7m
 [2018-01-10 19:42:47] Accepted 006127ac MLD 0  Diff 10m/7m
 [2018-01-10 19:42:53] Accepted 005c4df2 MLD 0  Diff 10m/7m
 [2018-01-10 19:42:55] MLD 0: Unrecognized response

etc

So it still hashes, but with frequent errors and at degraded hash rate.

All settings are default, I never overclocked the miner. No configuration changes (which I know about) were made. Powered USB hub.

What could it be?

Looks like something weird is going on there, you got shares coming from a Zeus board? Did you custom compile the driver and try and run both at the same time? That is most likely the issue as Zeus commands could be messing up the Moonlander.

[kcw-grunt]

BFGMinerRPC issues:

I hoped others have hacked through the forest already.  RPC is completely new to me and I'm also a novice python dev.  But, I tried to use the example RPC python script to RPC into my miner and I either can't get it to receive the data and parse it or I get no response.

Here are the 2 methods I tried:

1. Using Thomas Sileo CGMiner blog bigups (https://thomassileo.name/blog/2013/09/17/playing-with-python-and-cgminer-rpc-api/)

Code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
Created on Tue Jan  9 11:00:14 2018

@author: kerrywashington
"""

import socket
import json


class BFGMinerAPI(object):
    """ Cgminer RPC API wrapper. """
    def __init__(self, host='mylocalhost', port=4028):
        self.data = {}
        self.host = host
        self.port = port

    def command(self, command, arg=None):
        """ Initialize a socket connection,
        send a command (a json encoded dict) and
        receive the response (and decode it).
        """
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        try:
            sock.connect((self.host, self.port))
            payload = {"command": command}
            if arg is not None:
                # Parameter must be converted to basestring (no int)
                payload.update({'parameter': unicode(arg)})
                sock.send(json.dumps(payload))
            received = self._receive(sock)
            print(received)
        finally:
            sock.shutdown(socket.SHUT_RDWR)
            sock.close()
        
        return json.loads(received[:-1])

    def _receive(self, sock, size=4096):
        msg = ''
        while 1:
            chunk = sock.recv(size)
            if chunk:
                msg += chunk
            else:
                break
        return msg

    def __getattr__(self, attr):
        def out(arg=None):
            return self.command(attr, arg)
        return out

I started this script and tweaked it for my setup I'm remotely running the script with my server name.
The response is when I run c.command('summary') and I get no response. I set breakpoints in my Anaconda/Spyder IDE but get nothing.

                c = BFGMinerAPI()
                c.command('summary')

When I run the same script on locally..it still freezes...same behavior

2. Using the BFGAPI script:

Code:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Copyright 2013 Christian Berendt
# Copyright 2013 Luke Dashjr
#
# This program is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free Software
# Foundation; either version 3 of the License, or (at your option) any later
# version.  See COPYING for more details.

import argparse
import json
import logging
import pprint
import socket

logging.basicConfig(
         format='%(asctime)s %(levelname)s %(message)s',
         level=logging.DEBUG
)

parser = argparse.ArgumentParser()
parser.add_argument("command", default="summary", nargs='?')
parser.add_argument("parameter", default="", nargs='?')
parser.add_argument("--hostname", default="localhost")
parser.add_argument("--port", type=int, default=4028)
args = parser.parse_args()
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
    s.connect((args.hostname, args.port))
    
except socket.error, e:    
    print "Error receiving data: %s" % e 
    logging.error(e)

try:
    s.send("{\"command\" : \"%s\", \"parameter\" : \"%s\"}"
            % (args.command, args.parameter)
          )
except socket.error, e:
    print "Error receiving data: %s" % e 
    logging.error(e)
data = '' 
while True:
    try:
        newdata = s.recv(1024)
        if newdata:
            data += newdata
            print('Data:' + newdata)
        else:
            break
    except socket.error, e:
        break

try:
    s.close()
except socket.error,e:
    logging.error(e)
if data:
    data = json.loads(data.replace('\x00', ''))
    print('dat data') 
    pp = pprint.PrettyPrinter()
    pp.pprint(data)

Nothing prints to output

Could anyone offer some help?  Thanks!
 

[kcw-grunt]

Can you try putting a non usb powered hub between your powered hub and your RPI.

Yes..in my rig I have a power USB hub with USB adapters (HIGHROCK 30cm USB 2.0 a Power Enhancer Y 1 Female to 2 Male Data Charge Cable Extension Cord(1pc) that connect the USB port of my CPU.  So, the MLDs draw power and communicate as so.  The cost of the adapters was annoying (~$5 USD ea.) but it works.

[jstefanop]

Where are  getting that "clock freq" from? Maybe I missed something.

the setup hasn't changed for weeks. i used to run them on 768 with zero problems, so this is not he case

Well, you are getting around 4Mh/s for MLD0, and 700Mhz gives 700*5.66 (see page1) = 4.0Mh/s, so normally that means 700 or maybe 720Mhz.  At 768Mhz you should get 768*5.66 = 4.35Mh/s and you are not getting that by far (MLD0), so no matter what I think something is wrong and it could be powerdraw.  Why do you think you have zero problems if your hashrate is substantially below target? Or were MLD0 and MLD1 properly hashing at 4.35Mh/s in the past _and_ both have gone down?

current setup is 720Mhz. i used to run them on 768 but speed gain wasn't big, so i tuned back to 720. it worked for weeks on 720 with 8.20mhps total until day before yesterday

Try going back down to 600mhz speed and see if that resolves the issue, could be that you were near the max of what your USB supply could do, and its failing to output a clean max supply after a few weeks of use.

[cameloid]

I was running the stick for a while without any problem, but recently all of a sudden the bfgminer log started to look like this:

 [2018-01-10 19:41:27] Accepted 005114ba MLD 0  Diff 12m/7m
 [2018-01-10 19:41:33] Accepted 002be7f3 MLD 0  Diff 22m/7m
 [2018-01-10 19:41:48] MLD 0: ASIC has stopped hashing, attempting to restart
 [2018-01-10 19:41:49] Accepted 0038776b MLD 0  Diff 17m/7m
 [2018-01-10 19:41:50] New best share: 73m
 [2018-01-10 19:41:51] Accepted 000d96a3 MLD 0  Diff 73m/7m
 [2018-01-10 19:41:51] New best share: 115m
 [2018-01-10 19:41:52] Accepted 0008abcc MLD 0  Diff 115m/7m
 [2018-01-10 19:41:56] Accepted 002f34f2 MLD 0  Diff 21m/7m
 [2018-01-10 19:41:57] Accepted 006701af MLD 0  Diff 9m/7m
 [2018-01-10 19:42:16] Accepted 0045588e MLD 0  Diff 14m/7m
 [2018-01-10 19:42:17] Accepted 00256d79 ZUS 0aq Diff 26m/7m
 [2018-01-10 19:42:17] MLD 0: Unrecognized response
 [2018-01-10 19:42:19] Accepted 00798f2c ZUS 0bs Diff 8m/7m
 [2018-01-10 19:42:29] MLD 0: ASIC has stopped hashing, attempting to restart
 [2018-01-10 19:42:32] New block: ...a64ee3d1e95b8290 diff 3.66M (26.21T)
 [2018-01-10 19:42:32] Stratum from pool 0 detected new block
 [2018-01-10 19:42:42] Accepted 00592a2d MLD 0  Diff 11m/7m
 [2018-01-10 19:42:43] Accepted 00180ccc ZUS 0bk Diff 41m/7m
 [2018-01-10 19:42:47] Accepted 006127ac MLD 0  Diff 10m/7m
 [2018-01-10 19:42:53] Accepted 005c4df2 MLD 0  Diff 10m/7m
 [2018-01-10 19:42:55] MLD 0: Unrecognized response

etc

So it still hashes, but with frequent errors and at degraded hash rate.

All settings are default, I never overclocked the miner. No configuration changes (which I know about) were made. Powered USB hub.

What could it be?

Looks like something weird is going on there, you got shares coming from a Zeus board? Did you custom compile the driver and try and run both at the same time? That is most likely the issue as Zeus commands could be messing up the Moonlander.

Yes, I run Zeus board as well on the same machine (never had any issues with this setup before). I'm using bfgminer-5.4.2-futurebit2-beta2 from this thread built from the source code, and the host OS is Linux.

However, I'm pretty sure that the problem is not related to this bfgminer build, possible interference with Zeus and/or hub power issues, as I just tried to run this Moonlander 2 under Windows on a completely separate machine (using "official" bfgminer binary from you) without any USB hub involved, and got exactly the same result. The stick hashes at about 2.6 Mh/s, but the driver spits out "Unrecognized respose" every few seconds.

Seems that the device itself is faulty (even though it used to work just fine for about a month before this issue came out). Should I send it to you for further investigation/warranty exchange, or you want some more debug info?

[Benzzino]

Does anyone know how many monnlanders can be run off a raspberry pi?

[Bitfort]

Does anyone know how many monnlanders can be run off a raspberry pi?

Directly from PI? None.
You need to use powered hub. Then you are limited by number of hub slots, space around and the hub adapter.

[neochi]

Does anyone know how many monnlanders can be run off a raspberry pi?

I tried it out and i was not able to run a single one. The stick is recognized but restart a lot. It guess because of missing power. In general i had issues to run the stick on USB2.0. Any USB 3.0 was smooth out of the box.

[lennyNO]

as I just tried to run this Moonlander 2 under Windows on a completely separate machine (using "official" bfgminer binary from you) without any USB hub involved, and got exactly the same result. The stick hashes at about 2.6 Mh/s, but the driver spits out "Unrecognized respose" every few seconds.

I have had similar issues, and the 2.6Mh/s sounds all too familiar (several ppl reported similar effects throughout this thread). What clockfrequency are you using? Did you twiddle with the potmeters? Also, when it starts up, that is right after bfgminer starts up, is the MLD behaving normal, do you get the expected hashrate before the first restart? Make sure to check, and that it only drops down to 2.6 after it starts restarting.

When connected directly on the PC, go back to at least 600Mhz or (even) less, until the problem completely disappears. Then scale up from there and see where it starts.

For me it is definitively seems power supply issue, and I seem to have it under control now on my external hub, but I have been struggling with the same error messages and one MLD stopping and restarting all the time too. There is a debugoutput option on bfgminer and the futurebit-driver has a lot of debugoutput (see corresponding .c file in the source code), but it didn't get me much wiser other than understanding how this thing really works under the hood, which is fascinating in itself...

[cameloid]

I have had similar issues, and the 2.6Mh/s sounds all too familiar (several ppl reported similar effects throughout this thread). What clockfrequency are you using? Did you twiddle with the potmeters? Also, when it starts up, that is right after bfgminer starts up, is the MLD behaving normal, do you get the expected hashrate before the first restart? Make sure to check, and that it only drops down to 2.6 after it starts restarting.

When connected directly on the PC, go back to at least 600Mhz or (even) less, until the problem completely disappears. Then scale up from there and see where it starts.

For me it is definitively seems power supply issue, and I seem to have it under control now on my external hub, but I have been struggling with the same error messages and one MLD stopping and restarting all the time too. There is a debugoutput option on bfgminer and the futurebit-driver has a lot of debugoutput (see corresponding .c file in the source code), but it didn't get me much wiser other than understanding how this thing really works under the hood, which is fascinating in itself...

I'm using default frequency (600 MHz), and I never touched anything on the board. Also tried 500 Mhz setting just now, same difference.

It reads about 3.6 MH/s initially, but restarts begin almost immediately, so it's really hard to tell what the accurate hash rate is.

I'm 99.99% sure that this is not a power issue. Tried to connect the stick directly to different machines, tried two powered hubs, tried Lenovo dock station with 40W power supply and USB 3.0 ports - no changes. And, as I said, it all began just a few days ago - before that I had no issues at all in exactly the same configuration.

[lennyNO]

I'm using default frequency (600 MHz), and I never touched anything on the board. Also tried 500 Mhz setting just now, same difference.
It reads about 3.6 MH/s initially, but restarts begin almost immediately, so it's really hard to tell what the accurate hash rate is.
I'm 99.99% sure that this is not a power issue. Tried to connect the stick directly to different machines, tried two powered hubs, tried Lenovo dock station with 40W power supply and USB 3.0 ports - no changes. And, as I said, it all began just a few days ago - before that I had no issues at all in exactly the same configuration.

Ok. One of the things I wanted to find out with the debug mode is WHY the hashrate drops to around 2.5M/s, is it because some cores stop being activated (after a restart), is it because some data doesn't get transmitted, (USB hub clogged up has been suggested). I know it drove me mad at one point, but since now everything is stable (running 11 sticks on 1 hub at around 55Mh/s total) I am happy.

For example I noticed (via the debug mode) that sometimes bfgminer doesn't recognise the MLD serial number or even that it is a MLD connected to the COM port -- although it still works though! You can also see/check this via the [M] option (Manage device) and see if the device serial number and type comes up correctly. But when I restarted bfgminer it was ok again. This happened very repeatedly, especially when I had the restart problems. From the debugmode I saw this happened in the usb-2-serial initialisation of devices phase where bfgminer checks what's connected to each port. No idea why that happens.

So you may want to check via Manage devices in bfgminer if it your MLD is actually recognised properly or not (Should say Futurebit Moonlander and a serialnumber (long string, not the label that is on the unit). It won't resolve your problem, but every piece of the puzzle helps.

[dem0nlord]

I was curious about the amps being drawn on the ML2 running at 900Mhz and 5.10Mhs and today i received a little USB inline meter. To my surprise the sole unit I have right now says that it is drawing about 4.6v and 2.5 amp - did not expect it to be that high on the amperage.

Link to the meter you're using? I considered getting one but after seeing several reviews saying they smoked the meter with a high amp draw USB device I figured these stick would do the same to them. No doubt these are ragged edge USB power consumption with the speed turned up. I've yet to have success with any hub supporting more than 2 of them at 954mhz.

[JustAnotherPLT]

Been running my M2 on RPI with a USB hub. I've noticed with a fresh start it runs well but over time it slowly loses steam and hashing decreases from 4MH down to the 2's. I'm confused as to if its the USB hub considering it starts out fine. I'm using Beta 2. Suggestions?

Thanks

[lennyNO]

I was curious about the amps being drawn on the ML2 running at 900Mhz and 5.10Mhs and today i received a little USB inline meter. To my surprise the sole unit I have right now says that it is drawing about 4.6v and 2.5 amp - did not expect it to be that high on the amperage.

Try to tune down the core (and mem) voltage as much as it goes without increasing the hw error rate. But yeah, 900Mhz and above and the current goes significantly up (I think it is linear in clockfrequency and quadratic in core voltage, but not sure).

I've yet to have success with any hub supporting more than 2 of them at 954mhz.

Any hub?? I ran 6x954Mhz without problem but then I upgraded to 11 and ran into hashing problems (i.e. MLDs not wanting to hash properly), although I am not 100% sure I think that the voltage drop over the power lines from where the PSU connects to the USB PCB to the furthest USB slots is just too much with high current draw > 2A. But right now I have 5 units closest to the PSU running at 924Mhz and 6 at 832Mhz. I will try to convert one more to 924Mhz. All on one Eyeboot 19 port hub, rated at 40A, but ....  

I opened up the hub at one time to see how the ports and powerlines were laid out. The closer you have your MLDs to where the power comes in to the PCB the better (if you are running at 900Mhz++)

NB, I have external fans, nothing fancy but 4 of them, also connected to the same hub. When I stop the hashing one notices how much faster the fans start to run, again indicating that the powerdrop from zero-load voltage to full load. That's an issue.

Right now it is winter and I have no problem drawing in cold air, but when spring/summer comes I have to do something with the cooling to keep the babies cool. My MLDs are between 30-40degs C (depending on which clock, and for some of the ones at 832Mhz I have removed the stock-fan). I am not yet entirely sure how I will do it. But loads of youtube videos on that subject.

[TimBuck2]

Link to the meter you're using? I considered getting one but after seeing several reviews saying they smoked the meter with a high amp draw USB device I figured these stick would do the same to them. No doubt these are ragged edge USB power consumption with the speed turned up. I've yet to have success with any hub supporting more than 2 of them at 954mhz.

Just this inexpensive one on eBay

[aballen]

Hoping you can help.

I'm having some driver troubles here

I had no trouble on my raspi2, but I decided to use a fresh rpi3, with a 64gb sd card, nice open air case with a fan.

here is what I'm seeing, I had to install headers, which i did, I also had to create the build directory.  I'm stuck, here is what I'm seeing.


pi@raspberrypi:~/silabs $ uname -a
Linux raspberrypi 4.9.76-v7+ #1076 SMP Wed Jan 10 17:34:49 GMT 2018 armv7l GNU/Linux
pi@raspberrypi:~/silabs $ ls -ltra
total 160
-rw-r--r--  1 pi pi   278 Sep 27 19:25 Makefile
-rw-r--r--  1 pi pi  1043 Sep 27 19:25 cp210x_gpio_example.c
-rw-r--r--  1 pi pi 44684 Sep 27 19:25 cp210x.c
-rw-r--r--  1 pi pi   222 Sep 27 19:25 ._cp210x.c
-rw-r--r--  1 pi pi  1610 Oct  3 21:32 CP210x_VCP_Linux_4.x_Release_Notes.txt
-rw-r--r--  1 pi pi   209 Oct  3 21:32 ._CP210x_VCP_Linux_4.x_Release_Notes.txt
-rw-r--r--  1 pi pi 12687 Oct 18 16:19 Linux_3.x.x_4.x.x_VCP_Driver_Source.tar.gz
-rw-r--r--  1 pi pi 37968 Jan 13 19:51 .cp210x.o.cmd
-rw-r--r--  1 pi pi 20513 Jan 13 19:51 .cp210x.mod.o.cmd
-rw-r--r--  1 pi pi   178 Jan 13 19:51 .cp210x.ko.cmd
drwxr-xr-x  2 pi pi  4096 Jan 13 19:58 .tmp_versions
drwxr-xr-x 19 pi pi  4096 Jan 13 20:08 ..
drwxr-xr-x  3 pi pi  4096 Jan 13 20:17 .
pi@raspberrypi:~/silabs $ make
make -C /lib/modules/`uname -r`/build M=/home/pi/silabs modules
make[1]: Entering directory '/lib/modules/4.9.76-v7+/build'
make[1]: *** No rule to make target 'modules'.  Stop.
make[1]: Leaving directory '/lib/modules/4.9.76-v7+/build'
Makefile:7: recipe for target 'all' failed
make: *** [all] Error 2

[aarons6]

to anyone curious, this is stock voltage at speed 796


this is why you need a good hub and why you cant plug these directly into the usb ports on your pc

[racebyu]

is there a list of pools these work with and pools they don't? I'm trying to mine on multipool.us and it connects and shows accepted shares but the site doesn't show any hashrate. Works fine on litecoinpool

I had mine working just fine on multipool.us.

I'm currently using mining-dutch.nl and I was using hash-to-coins.

No problems with Multipool, been mining a few weeks no issues.
Also use Hash to Coins with no issues and good hash rates.

[headhunter21]

HI fellow miners, anyone know how to use bfgminer to solo mine with any scrypt wallet? read all the help from google but to no avail, can't connect to my wallet at all, is it bfgminer problem or something else, did all the conf files and all as per google search, i just wanna know is it possibe or anyone have any luck with scrypt coins.