Hi. Sorry to say but the instructions are for nix type installations, not Windows. I did it on raspberry pi myself. I suppose they could possibly be tweaked to work on Windows with some effort (for example the scripting was done for bash vs cmd or even powershell), but if your issue isn't resolved restarting bfgminer then the tricks I did won't likely help you anyway. If the computer is dedicated to mining you might be able to work in a restart of the computer but that could be ugly.  Hopefully the new compiled binaries once jstefanop releases are available soon & will help with your issues & not need to bother with these sort of work-arounds.

Btw for what it's worth I had all kinds of issues on 1 of my Win10 computers where I had to power cycle the hub and/or unplug the moonlanders often. Funny thing was exact same setup worked fine on another Win10 computer but I'm not sure what was different other than the one that had issues was a few years newer. In any case I got sick of fighting with it so I ordered a pi kit for like $60 off amazon and it's make mining much less of a hassle. (Besides the locking of the miners I had an odd issue where keyboard keystrokes were delayed or lost until bfgminer.exe was restarted which was mega annoying.)  The bad news was that the moonlanders still locked (went to 0 mhs) but unlike Windows, a power cycle of the powered hub or removing/replacing the moonlanders was no longer needed thus the above "fixes" being born out of necessity.

Ok thanks. I had checked github but didn't see any new release but will look again. EDIT: it shows last edit was Nov 2018.. Am I missing something?

awesome! glad it worked & you found it useful I've been very pleased with it here myself. I'm seeing my daily payouts increased already since there is less downtime where I was AFK & didn't notice 1 or more moonlanders were 0.  Now it's rare to look & find one stuck.

NEW AND IMPROVED METHOD!
So while my big hammer method above worked it felt too dirty & dumb. Here's a smarter "2.0" method that reads in the speed via RPC & only stops bfgminer if the speed falls below a certain level.

nano run.sh
NOTE: This run.sh is same as previous method except --api-listen is added to enable RPC API for localhost reading of mining stats. Be sure to set the correct path to your bfgminer, your own POOL, PORT & USERNAME etc. Set your own command line options like clock speeds etc as needed

Make it executable:
sudo chmod +x run.sh

We also need a new script:
nano monitor.sh
NOTE: Be sure to set MINSPEED, MINWAIT & path to where bfgminer-rpc is (the cd line)

Make it executable:
sudo chmod +x monitor.sh

sudo crontab -e
(Don't forget sudo so you're editing root's crontab.  This runs the monitor every 5 minutes, adjust accordingly. Be sure to set path to your script as well. I just put mine in my pi home directory)

So what the heck does this do? Well like before I'm running bfgminer a screen session, in a loop, so that if told to exit it will just run again after a 5 second delay to give you time to hit Ctrl-C to terminate the script.  But now instead of blindly killing off bgminer every hour, I'm running my monitor script every 5 minutes.  The monitor script calls bfgminer-rpc to get the stats (remember you must enable RPC with --api-listen option unlike the earlier method above), parses that output for the 20 second average speed and how much seconds have elapsed since bfgminer started. If the speed is less than MINSPEED (default is 10 MHS since I have 4 stock moonlanders running. Obviously adjust this to suit your speed. Go a little under the average you see in bfgminer though to give it a little wiggle room. I see 12-13 on my 4 so 10 seems like a pretty safe level to detected 1 or more that are stuck) and elapsed time is at least MINWAIT (default is 180 seconds or 3 minutes to give the miners time to settle in & not try to restart bfgminer while it's ramping up. Adjust if needed) then the script kills off bfgminer otherwise it does nothing. (Checking elapsed isn't really needed if you're careful to only run the monitor script after the miner gets up to speed but it was simple enough sanity check that it seemed worth the trouble adding it.)

So far this method is working quite well for me here but no promises.  I'd highly recommend you manually run ./monitor.sh while testing before adding it to your crontab to help troubleshoot. Once you're sure it's working as expected then add it to the crontab.

Some word of warning: Not much error or sanity checking is done to keep the script small & simple. For example you'll get an error if you run monitor.sh when bfgminer is not running, if RPC API isn't enabled, if the bfgminer was just started & RPC isn't ready, etc. So far the errors I've seen are benign & can be ignored. The script does nothing unless the stated criteria is met so it should be harmless if it hits a snag.  The only issue I've seen myself is if I set the MINSPEED too high or if one of the miners is locked enough that it needs power cycled then the script will restart the bfgminer over & over at whatever interval you set in crontab. So keep that in mind & adjust accordingly.  Also note that 20s speed is floating point but to keep it simple in bash script I "convert" to integer chopping off everything after the dot.  I realize this isn't ideal but again was trying to keep it simple & it should be accurate enough for the purpose of monitoring. Obviously if your speed is less than 1 the script isn't going to work right so you'd need to adjust the script. Also note that this assumes . vs , so I'm not sure if bfgminer is localized so you'd need to modify the script for that if needed.  You'd try SPEED=${SPEEDFLOAT%,*} instead perhaps.

EDIT: See next post for the updated "smart" method that bases the kill on speed vs just blindly timed
I've tested these moonlanders on multiple systems, multiple hubs, default & custom settings, original release & newer beta, and for some reason they each show 0 for speed eventually.  It's not an ideal solution but so far the cleanest I've found is on my raspberry pi running latest raspbian is to restart bfgminer every hour. I didn't see an option in bfgminer itself so I went a more brute force way which while maybe not pretty, so far seems to do the trick. (Surely there are cleaner ways to go about this but I worked with what I know how to do the fastest since I've wasted too much time on this already)

I start a screen session manually, then start bfgminer in a looping script that's in my home directory with a delay after it to have time to stop with ctrl-c it if needed:
(Be sure to set the correct path to your bfgminer, your own POOL, PORT & USERNAME etc. Set your own command line options like speed as needed)

nano run.sh

Make it executable:
sudo chmod +x run.sh

Then I use the root crontab to tell bfgminer to shutdown every 60 minutes using pkill:

sudo crontab -e
NOTE: Be sure to use sudo crontab -e otherwise if you don't use sudo pkill won't have permissions to work under normal user's crontab

Once setup & running I can watch the screen session cleanly restart hourly. (Use more or less time to balance work lost restarting with how long you're willing to accept 1 or more miners hung)

No doubt this solution isn't ideal & has drawbacks (such as while pskill tells bfgminer to shutdown the same as if you hit Q, it does not help if the issue is USB or hardware related.  Plus unless set on command line, the difficulty has to be negotiated again.  It's possible to lose out on work being done but not as much work is being lost having moonlander's hung up at 0 mhs.

I got 4 moonlander 2's on a powered hub. On Win10 the moonlanders would eventually 1 by 1 show 0 for speed & restarting bfgminer didn't help. I'd have to power cycle the hub or remove each miner & plug them back in then they'd work for hours to a couple days.  I figured it could be a Win10 issue & was sick of dealing with restarting them so I bought a raspberry pi and now they still eventually go to 0 but i can just restart the bfgminer & they'll work again.  Granted I could just cron or script a restart but I'd prefer to get a real fix.  I'm testing the older initial release on the pi to see if it makes any difference because I noticed the latest says it had restart logic added which i figured there was a chance that was the issue.  Btw I'm running them stock (not specifying any speed on command line) and the hub claims to support 2A per port. It's the "Sipolar Well Work 20 Port Industrial USB 3.0 Hub Charger for iPhone/iPad/Cellphone with Box Shape Speed Up to 5Gbps " "Provides up to 5V, 2A (10 Watts) of power per port, for charging battery-intensive devices such as an iPad" so I didn't figure that was the issue.  It's actually a nifty hub in that it's like 2 hubs in 1.. The 20 ports are split into 2 sides, each with own USB type A port like a separate 10 port hub combined in 1 box.  In fact the other half of the hub is running 1 NEWPAC using an older pi without issues. Actually, before I bought the newpac I was running the 4 moonlanders on that pi with this hub with zero issues.. (unfortunately the moonlanders & newpac don't play nice together mining on same machine)  I was tempted to swap the 2 pi's around to see if the problem followed or not. For now i'm testing the initial release bfgminer with fingers crossed.
Thx
Bill

Generally speaking yes it's a bad idea to run non-original or unofficial firmware *except* in my case (and seems with others), downloading the source for the original/official miner from official bitmain github, building it per included instructions, then running it on T9+ essentially bricks the cards. One by one.. The longer you leave it running & auto-rebooting, the more cards it kills. It seems to happen if someone upgraded to the autotune firmware which must flash updates to the boards then the older software thinks the boards are corrupt so it tries to flash them & it appears to flash them wrong or with wrong version etc.  I didn't make note of what version of firmware these shipped with but if it wasn't the autotune one that's available on their site it's possible anyone flashing the pre-autotune firmware might end up in the same boat.

Thanks for the response. So far the crashes stopped since adding the config change recommended by vh few posts back. Could be coincidence we'll see but it was crashing at least daily before.  I'll keep this in mind though.

Yeah that one supports up to 2100mA each port for the 10 ports which is good for mining. It'll let you crank the speed up nicely.  It is only USB2 but not biggie for mining,

The earlier hub you picked could do a few but it was only 900mA max each port so a few would work but you couldn't set the speed very high.  In other words you want to look at the power per port the hub supports to determine max speed you can go and the TOTAL power the hub supports & multiply out how many moonlanders you got to be sure you don't overload it.

Ok thanks for the reply & the link. I would have never found that!  I added it & restarted the pi as directed in that post & will now wait & see. Not sure what is supposed to happen but i can research that setting. It's been crashing daily so shouldn't take long.

Btw deja vu flashbacks seeing miaviator in those 2014 posts.

Look closer into the Apollo like jstefanop suggested but as far as that hub, here are the specs & it's matter of math:


Max 900mA per port and total of only 3A. That hub could run a few at less than optimal speeds (to get full speed you need more than 900mA per port) but obviously it's way under powered to run 7. So if you stick to moonlander route look into more beastly hubs.  I bought one of these beasts: https://smile.amazon.com/gp/product/B01KPOEX9O/

Granted due to the spacing you can only get 12 on there without short USB extension cables but yeah it's more suited for mining than that hub you linked.
Or there are options such as this one:
https://smile.amazon.com/dp/B07MK5CLMB
Good luck

EDIT:
Figured it out.. It's a Samsung tablet I had plugged into the computer charging..    It's powered off but shows up as USB Serial Device (COM5) in device manager.. If I unplug the tablet, or uninstall COM5 the error goes away.. Seems bfgminer sees COM5 & tries to mine with my tablet   I'll leave this post up in case anyone else runs into this issue.  I bet other devices could result in errors as well.. I figure there's a way to disable COM5 on command line so I'll look into that or just keep it unplugged.

ORIGINAL POST:
Anyone know what this means?

Odd thing is it mines fine other than complaining at startup and repeatedly while mining:

I've got 4 Moonlander 2's all doing the same thing, 1 alone or all together.  They work fine using same hub on rasp pi & another win10 box but 2nd win10 box giving this invalid argument error. Of course the one I want to mine with is the one giving the error.. lol

Nothing exciting in my config:

It gives the same error if moonlander 2 plugged in directly to computer (usb2 or usb3) or in hub and in fact it gives the same error even if no moonlanders are plugged in at all.. I installed the win10 drivers listed on the 1st post: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers  About only thing I haven't tried yet is rebooting because I'm unable to conveniently at the moment but will do that once I'm able.
Thx
Bill

what kind of price point?  should be handy to have a ready to go kit for someone starting out or not interesting in the trouble of setup.

Btw any idea what the heck is causing this crash running cgminer with 1 newpac at 200mhz?  my pi is dead to the world. Can't login or anything I have to power cycle it.

Wow those hubs look well thought out.

Anyone had any luck running NewPac & Moonlander 2 together?  I got a pi hooked to a usb hub & they both work fine alone but if I run NewPac miner it kills the Moonlander miner if it's already running or it reports no devices found if run after.  Errors make it seem USB ports are taken over.  For now I just moved my NewPac to a PC but have plenty of room on my hub so sure would live to be running them all together if possible.

I finally got around to testing more & come find out that in driver-btm-c5.h I had to change:


to


Before it'd actually USE the voltage set.  Logs would SAY it was setting/using the lower voltage but Watts read at the wall didn't change much if at all until I changed that.  So far the best I've found is 710 at 200Mhz gives 1200+ GH/s for only ~140 Watts per card which is MUCH better than the same speed at 235 Watts per card before. Saving 95 watts per card at 200mhz!

Keep in mind my goal in testing was to try & get the power usage as low as possible yet be reliable & not overly concerned with the hash speed thus running at 200 mhz.  1200 GHS is pretty respectable for 1 card using 140 watts.  I should be able to get 3600 for ~420 Watts & very low heat & low/quiet fans.  (It's very quiet now at only 41C & 2000/2400 fan)  

Now I need to test at 710 but raise the speed as long as it's reliable & compare the watts per GHS.  Test with all 3 cards again as well but I was interested in lowering power usage thus only using 1 card.

Well i use fixed frequency not autotune. That's one reason I didn't edit in the same section as you. In other words I use section where volts are set by frequency not by hash rate. At least that's how I interpret the code.

OH!! You changed in completely different area than me.. I changed the "working voltage" section..  I'll have to check out what's different in that section you edited it in. Thanks

Odd wonder why you see more of a decrease.  Can you share the code or snippet or at least example line where it's changed? thx

OK that's cool but I have mine set to 780 & I'm not seeing as dramatic of change as you.. Maybe you're changing in different spot in the code?

Wow 300 watts reduction?!?  How low did you set the voltage?  I set mine to 780 as a test and while the temps run lower & fans are little slower/quieter I'm only seeing very minimal power savings at the wall for some reason..  As in at fixed 450 mhz frequency, 4 watts per card so ~16 watts less reading on my kill-a-watt:


(The typo is theirs in the code.. lol)

I got the fans tweaked exactly how i like them now!  Instead of the annoying way too fast or the ramping up & down over & over, I can basically now set a goal temperature & the fans auto-tune accordingly.  To me this makes a lot more sense than the nonsense they build into the antminers. Wow that code of theirs on github is a mess.

But yeah it'd be cool to know what you changed.

Thx
Bill