Topic: [ANN] FutureBit MoonLander: A Modern and Efficient Scrypt USB Stick Miner! - page 6. (Read 30586 times)

I found a workaround for this, if you're compiling bfgminer from source. Open up miner.c, and find the line that reads:


This is the timeout, in seconds, before a device is declared SICK. You can set it to any value less than or equal to 600, though I recommend setting it to a divisor of 600. (300 works well for me.) For example...


Once you've done that, rebuild bfgminer. If you've used the value 300, your sticks can now mine for 5 minutes without finding a share above the pool difficulty before they go SICK. They'll also reset every time a new block is found on the network (that behavior is already part of bfgminer), so this works great for coins with < 5 min block time.

Note that this doesn't fix the problem where the MLBs stop submitting shares, just the problem where they go SICK because the pool diff is too high.

DISCLAIMER: I have no idea if this is bad for your MoonLanders. It works okay for me, but I'm not responsible if this workaround causes your MLB to release the magic smoke.

Same problem here.

The miner with BFGMiner works well (very well) only with low diffs pools.

This means only pools which allow settting a low diff can be choosen.

I use to mine on multipools (Clevermiming, Prohasing). But Moonlanders with
BFGMiner didn't work with them. Most of them use vardiff, and starts with high
diff and after they drop it... But of course, the miner will get SICK before...

Really interested on how to avoid the SICK problem when the miner not
sendind shares for one minute.

I bought an scrypt miner, not an "only LTC on some pools" miner...

Sure problem is in BFGMiner, not the miner, but as we have not other software option...

Regards.

this is the error message i am getting when my sticks go idle..

the yellow light still blinks and the stick is being detected.


 [2016-04-14 11:32:59] [thread 0: 0 hashes, 0.0 khash/sec]
 [2016-04-14 11:32:59] MLD 0: Popping work from get queue to get work
 [2016-04-14 11:32:59] MLD 0: Got work 461 from get queue to get work for thread
 0
 [2016-04-14 11:32:59] Selecting pool 0 for work
 [2016-04-14 11:32:59] Generated stratum header 00000004c216fb62957dd18ffd5be87b
c33b86ca835d73a9db14f2a7fb78cc7b4f03d57909641a2e49e80050b3c094f1c9195e01df76940 3
0fa8672c39e264c71391861f570fe2581b01431900000000
 [2016-04-14 11:32:59] Work job_id 9f39 nonce2 0d000000
 [2016-04-14 11:32:59] Generated stratum work
 [2016-04-14 11:32:59] Pushing work 485 from pool 0 to hash queue
 [2016-04-14 11:32:59] Failed to start job


ok i think i figured it out.. on the sticks that go idle, if you restart bfgminer it says it detected 0 cores.

 [2016-04-14 11:42:51] futurebit: Successfully opened \\.\COM1
 [2016-04-14 11:42:51] MLD: cgpu_set_defaults: Matched with set default: MLD:clo
ck=104
 [2016-04-14 11:42:51] MLD: Applied rule MLD:clock=104
 [2016-04-14 11:42:51] futurebit: Core clock set to 104 mhz
 [2016-04-14 11:42:52] futurebit: Identified 0 cores on \\.\COM1


you have to pull it out and rest the power for it to come back on.

it has to be something with the futurebit driver and bfgminer

 

unfortunately probably nothing you can do..

its something in bfgminer.

i cant get these to work on the nicehash pool. bfgminer restarts because it thinks the network is timing out. it keeps saying its working on an old block over and over and over, probably because NH isnt mining litecoin.


i cant get these to work on ANY LTC pool that you cant really set the difficulty.. because bfgminer thinks they are "sick" if they dont send a share every 30 seconds or so.


litecoinpool.org works if you want to mine litecoin, so does ltc.tbdice.org if you want to try solo mining..

i havent gotten these to work on mining WDC or DGC or any other scrypt coin. they just dont work. times out.



i cant get all 8 to run at the same time.. almost always one drops off as soon as they start up and then one drops off one by one until they are all showing zero hash.. takes about an hour..


they do turn a profit on mining litecoin.. each stick will make about 7$ a year.. you may get lucky and litecoin will go back up in value.

that's very strange - my newest experience is

the same:

• Computer
• Hub
• Moonlander Stick
• OS
• Temperature & fan location
• mhz & core voltage
• usb cables
• mining pool & settings

but: i start bfgminer - sick after seconds, ( i have a *.bat file to start the miner on windows where i actually use it)
->quit and restart immediately - runs since yesterday  for approx 20 hrs

so whats up now? voltage ups and downs in the local electricity grid?   thats absurd, there must be a reason imho  
a loose connection in any wire? I didn't even touch one while doubleklicking on the executable batch file ^^ yea except the one of my computermouse. most wires are as new.
the only comprehensible difference is the position of earth in milky way   maybe a solar flare

the point is: I start the bfgminer twice under exact same circumstances, once it went nuts and another time it works 
greetings

The sick and then fade out happens on whatever OS, hubs and setup I try.
Only solution I found is to have Minera restart the miners after two go offline for more then 10 mins.

AFAIK "sick" only means that it has spent too much time without bfgminer detecting a share
okay but then its probably a bfgminer specified problem cause i use to crunch with my intel I5  @ 4x 4,5 khashes with CPUMINER and my GTX720 @ 11khashes witch GUIMINER and thats way slower than the moonlander can do but there's no prob with the shares. I use wemineltc.com where 32 is the lowest selectable diff.
but sometimes it says that the moonlander is "sick" after less than 60 secs too. Mostly when I change the voltage over 0.760V. but then the bfgminer not even accept at least 1 share.

Try just leaving the miner running for a while and the sick might go away when a share is submitted
somethimes that happens, but sometimes not
i'm afraid it's because of I don't use a proper USB hub. meanwhile the moonlander works fine from 104 to 144 mhz and next week I'll get one of those powerful hubs. but i'm from austria , here are not all of those hubs available. I'll buy 2 of them: Sabrent 60 Watt (12 Ampere) 10-Port- http://www.amazon.de/Sabrent-10-Port-Familie-gro%C3%9Fe-Schnellladeger%C3%A4t-Smart-USB-Ladeger%C3%A4t-AX-TPCS-W/dp/B019GB57R4?ie=UTF8&psc=1&redirect=true&ref_=ox_sc_act_title_2&smid=A1E3IQLEA4G42D

atm the red light is constantly on after ~ 1-2 hours of working. Does that mean overheat? the computer with the stick is located in my cellar where I have between 60 and 65° F (~16-18°C). I use a fan and the black cooler metal is very cold when i touch it so i hope/think it's no thermal problem 

AFAIK "sick" only means that it has spent too much time without bfgminer detecting a share. It can be normal, if the pool is rejecting low difficulty shares (as the miner takes a long time to produce high difficulty shares). It will stop showing "sick" when the miner throws a share over the pool difficulty.

Some pools adjust difficulty and lower it down to your stick miner; others don't. Try just leaving the miner running for a while and the sick might go away when a share is submitted, then declared sick again if much time passes without a share.

hi guys, I got mine yesterday and it drives me crazy    

but I have an info: the Moonlander does absolutely NOT work in a 10 Port Digitus USB 2.0 Hub (5V 4A) with only 1 device connected.
I tryed the Moonlander unter serveral circumstances with this USB Hub:
Banana Pi & Raspberry PI, on a Netbook with debian 7.4, and a Win7 PC - no chance.


but - it works fine without the -d 8 or 16 and without the clock=XXX options even directly connected to all theese devices/pc but only ~0.320 KHS and it works 24/7 without going "Sick" in bfgminer

if I adjust the voltage or the clock speed it seems to go randomly sick. I'll buy one of theese HUB's and then t'll try again.
Does "Sick" mean to low power?

I also tryed a voltage of .890V but my bananapi just turned off (so the poti & voltmeter seems ok)
Btw I use the Digitus 10 Port ub for 6 BTC blockerupter and it works fine.

Thanks, that's perfect!. Is the price still $32 USD each? If so, how much would be the shipping of 2 FutureBits to Mexico?

Again, thanks in advance for your answer.

Hey sorry I missed your PM. Yea I still have a few left, but this last batch is dwindling fast.

@jstefanop:

Some days a go I sent you a PM asking you if do you still have some FutureBit for sale. As I haven't received any answer I'll ask you here: Do you still have any for sale? I would be interested in buying 2 if that's the case.

Thanks in advance.

thats not it.. if i unplug the usb cable from the pc.. the lights still blink.. they will go forever until i turn off the superbpags.

they are locked in some kind of internal loop.

The yellow light does stop blinking when they fade away on my end. I am not sure if that helps.

Unfortunately its next to impossible to track down what is causing this, but my guess would be the vcom driver, or a bug in bfgminer thats out of the scope of my driver. The driver is fairly simple and low level...if the yellow lite is blinking it means the ASIC is operating fine and correctly returing shares, but for whatever reason those share bits are never making it to my driver thread thats "waiting" to read a response. I know the windows vcom driver had this issue, especially with USB 3 ports. If your on windows make sure you download the latest silicon lab driver that was updated last month.

i cant track down why they stop hashing.. it has NOTHING to do with speed or heat, i have 2 superbpag hubs and sometimes the 4 on one hub go for hours and then one on the other one will stop in seconds from turning on and its completely random, different stick each time. it has nothing to do with hardware errors cause my errors are 1 or 2 per hour. the red and orange light still blinks on them all. so its receiving data. turning on the bfgminer stats it says its sending the stick that isnt hashing data from the queue.. for some reason bfgminer isnt seeing the share.

My stopped hashing.  Is recognised when plugged in but no hash reported

I am at 272.
Cranked up the voltage a bit so far about .890mv
Still cannot keep them running more than 30 mins before they fade away. I do have Minera restarting after two out of three die and do not come back for 10 mins.

Thanks jstefanop! I'm on a Raspberry Pi and the problem with this is that Linux (or at least Raspbian) assigns different ttys to the sticks on each boot. So if I write a shell script with a line like that, it's invalidated next time I reboot. It would be cool to be able to do something like:


I took a quick look at the bfgminer code but it wasn't clear to me whether those serial numbers were available at init time.

Bfgminer already lets you do this...quote from the FAQ section.



If your running windows just use the proper windows COM port syntax @\\.\COM1 etc.