Yup I'd be interested as well.  Still have my 2 R606's and 4 newpacs running and have been for the most part trouble free. One pod had a fan die in it but was easy enough for me to rig up a couple of fans to it.

you can also do the command lsusb and should see something as follows:


Then in your bash / script if you want to split them out, as in my case above, I would do:


In this example out of the 4 newpacs and 2 R606's I have running, only 2 newpacs and 1 R606 is pointed at a Digibyte coin.    In the --usb portion of the script, 1:4 in my example is reference Bus 001 Device 004 which is one of my R606's.    In your case if I wanted my newpacs to point at a specific pool or sha256 coin then specify the usb addresses for the newpacs and plug that into your script.  Then play around with the R606 on different pools.  Then you won't have to worry about resetting the newpacs each time as now you are only referencing the R606's.

You may see different results when doing the lsusb though since on a desktop.  I have mine running off a Raspberry Pi 4 and they are all on one Bus lane.  On a desktop you may have all the newpacs on Bus 1 and may see the R606's on Bus 2 or Bus 4 etc.  It'll be easy to figure out and code accordingly.


Not sure of the difference between the Pi 3b and b+ models.  I have detailed instructions though on setting up the newpacs on a Raspberry Pi 3b+ on page 28 of this thread.  I have not spent much time with these devices on Windows as I ran into stability issues once I tried, went the Raspberry Pi route and never looked back.   One thing to note though, if you are only going to run 1 - 4 newpacs, then a Raspberry Pi 3b+ will be fine.  If you plan on getting more than that or any R606 then you will need to get minimum Raspberry Pi 4.  As the 3 series ran everything off one bus lane (processes, devices, internet etc) which created bottlenecks.

My suggestions since the Pi's are easy enough, reinstall Raspbian on that device, and follow the steps on page 28 for setting up the newpac  on a raspberry device and see if this resolves the issue for you.

Thanks, didn't think about the tuning.  That did the trick.  It fails on 6 however 5 and below it works great.   Appreciate it.

I was at 441 on the nvidia driver.  Updated to 442.74  and same issue.  Does not hash and states critical issue and restarts the miner.   I can use this card on any other mining software, claymore 15 on coins that'll allow due to dag size (callisto, Ether-1 as examples) without any problem.  I can use T-Rex on Ravencoin again no problem.  Card works great.  However if I use Cryptodredge it'll bomb out every time.  So now with everything updated just leads me to thinking something in the mining software.  Since the 1650 Super is fairly new and not many people using the card.

I've had a chance to run this over my rig and it'll work on all old and modern Nvidia cards except for the 1650 Super.  It only gives a GPU Critical Error message and restarts the miner.  Works fine on all other cards ranging from a 750 ti, 1050ti, 1660ti, 1070 and RTX 2080.  Just the 1650 Super fails. 

Since this GPU is still relatively new, has it not been coded for yet?  I am currently running the latest version 23.0

might give that a try.  It's a new one just shipped from futurebit directly so possibly the voltage is wrong.  All the others work fine.  Just managed to isolate it to one.


** Edit **
I believe it is a voltage issue.  It must have been set too low from the developer on this one stick.  All the others works fine and will hit the target 600 Mhz speed and will overclock to 700 without having to change voltages just fine.   This one stick I'm having trouble with on the other hand 540 Mhz is the highest it'll go.  It still does the Asic restarts but not as common as before.  If I want it to run perfect with no restarts, 480 Mhz is the most stable.


** Edit 2 lol **
Ok voltage was the issue.  When comparing this unit  against the others as well as the pictures on the first page, the core pot was not turned with the flat end pointing down.  I turned it clockwise to match and it's now hashing 4.2Mh at 700Mhz without a single restart.   Thanks for the help.

I have been having on/off problems with the additional moonlanders so swapped out the hub.  I have now 2 gekkoscience hubs that are powered off a HP Server 1200 PSU.  Each slot is 3a power.  So more than enough power to run 4 of these sticks.  And for testing sake I even broke it down to just 2 per hub since I have 2 hubs and still having this reoccurring problem in this screen shot here --->  https://ibb.co/zPWXtj5

Where the asic device will just stop hashing and attempt to restart.  If I run these on prohashing pool it's worse.  3 of them will constantly reset.  Right now on this current pool mining Mooncoin only MLD0 is getting reset quite often.  Any ideas what could cause this?  As power issue is ruled out.  I've also ran these at 644, 686 and 700 Mhz all with same results.  So I am stumped why one continues to reset.

Here is 2nd screen shot where it's starting to occur more frequent.  https://ibb.co/99mfq0r


Any ideas?

You running this in windows?  Linux?  Raspberry Pi?    If you are on linux / Raspberry Pi then you need to use sudo before your .sh file.    So if you created a script as example start_miner.sh  then on command line you will need to do sudo ./start_miner.sh

The usb hub is a GekkoScience 7 port hub, 3a per port so more than enough power for these little things.  As I have another one of these hubs powering my newpacs and R606's.   These moonlanders worked on the same machine, the only difference is that I did a fresh windows 10 install onto a M.2 SSD instead of the 1TB Hard Drive that I originally had on this box.    I'm reinstalling again as I noticed issues with the 210x drivers and couldn't get them uninstalled/reinstalled.   Since this drive was fresh to begin with, figured wouldn't hurt resetting everything again


** Edit **
Oddly enough it still does it even after fresh install.  Without even plugging the moonlanders or the hub up to the system yet, just run the start_moonlander bat file first as a test, the first thing that pops up is the error "Failed to sanity check in lowl-vcom.c windows_usb_get_string():508"

Then after a few seconds the message waiting on devices appears which I was expecting that message since I haven't plugged them in yet.   This is running on a AsRock H110 pro BTC+ motherboard.   Just odd it was originally working and now it's giving these sanity errors.  If it keeps up I'll loose my own sanity

I've now moved it to another gpu mining rig. Same setup and it's working fine on that one, no errors.  So that's where it'll stay

Any ideas on this error:


I reinstalled windows 10 on my Gpu rig, and nothing has changed since I installed this earlier this week. But now receiving this Failed sanity check.  The miner appears to be still hashing on after I give it a few minutes.   I uninstalled the 210x driver, reinstalled it, still same results.  Once it starts hashing (700Mhz averaging 3.9Mh/s.   And while mining it'll come up often.

Any ideas on how to correct this?

I've been off site for a while and catching up.    Instead of reboot commands have you tried  shutdown -r 03:00 as an example instead?      In this example it will shutdown and reboot the system at 3 in the morning and you can change the time to whatever you want.  If you did a -r 10 as example it'll reboot in 10 minutes.  If you want it later in the evening shutdown -r 18:00 as example.  You may be able to run this in the same script as the miner (haven't tested) or run as a separate script and have it in Cron.

*** Edit ***

Ok tested and this will work:


In the above script it will reboot at 3am just as a basic generic example.  And since you are doing OS updates you may want to run that in a separate script.  This example is a different miner but logic is the same.  Possibly putting the shutdown command in it instead of the mining script.

Well finally got around to fully testing this.  Still unsure why it's now messing up.   These two moonlanders I have ran originally on a Raspberry Pi 3 and later Pi 4 without issue.  About 6 months 24/7 on a Pi 3.   I'm assuming since there have been some forced updates on the Raspberry Pi 4 kernel that it's possibly causing the Segmentation Fault errors?  I have 3 pi's and have tested on all 3 of them.  I've reloaded Raspbian and went lite, full buster and NOOBS editions, same results.  It might run now for an hour or sometimes up to 8 hours but the miner eventually crashes with a Segmentation Fault.  Sadly I am unable to find any prior release copies of Raspbian.  The oldest copy I have is Noobs Version 3.2 that was released in July 2019.  So I've only be able to back date my OS to that point with these tests.

I've now loaded them on my personal Windows 10 rig.  They are running for now.  I'll see if they will remain stable and if so I'll then just attach them to one of my GPU mining rigs (with powered usb hub).    I'm assuming the links on the first page of this thread are still valid for the bfgminer software?  So there hasn't been any updates since 2017?   Just wanting to make sure I am using the right miner.

It's not a CPU issue from what I can see.  Right now I have TeamRedMiner running on all 6 GPU's mining Chukwa.  It's using less than 2% of the cpu usage.   When I split the rig and put in my prior example, 5  Rx 470's on Ethash Algo mining Callisto, and put the 6th Rx 470 on Chukwa mining Turtle coin, the above posting screenshots are the errors I get.   Several posts up on my original I show the task manager window open.  CPU load at that point was only 0.3%

Ok different set of errors when running TeamRedMiner for both Ethash and Chukwa mining together.  I have one session pulling the first 5 GPU's on Callisto.   I have the 6th GPU on Turtlecoin. 

First error.  I have the Ethash portion running first and then start up the chukwa miner.  Screen shot of error: https://ibb.co/mzgh8Mm

The chukwa miner would never progress, just sat at that screen.  However on the ethash portion one by one each card went into dead status.


So next tried firing up chukwa first.  Then Ethash.  And here is that result:  https://ibb.co/VD2qgw6

Thanks, I'll get that setup today and let you know.

Think I figured out the issue along with some help  Seems memory could be the problem.  This rig only has 8gb of Ram.  When I increase page filing to 65,000 I saw good improvements.  Instead of the other 5 GPU's all being below 5Mh/s now it's only 1.


*Edit*
Scratch that.  Thought the page file might have fixed it however getting same results as I let it run :/

Not having any high CPU usage though.  I've taken a few screen shots for reference.

This screen shot is with 5 of the 6 gpu's mining Callisto and getting their proper hash rates.  https://ibb.co/MGCfJrD

This screen shot is when I launch TeamRedMiner using the 6th gpu to mine turtle coin and the affects it's having on my other miner. https://ibb.co/vmcgZGG

You can see where out of the 5 GPU's mining Callisto, one of them remains at 30 Mh/s, the other 4 all drop below 5Mh/s and I can't figure out what's causing it.  Only occurs with TeamRedMiner running on turtlecoin.   

This screen shot is of task manager with the apps details.   https://ibb.co/BP4Cbqv

Good evening.  I've made the switch on my AMD rig over to using TeamRedMiner but have a question.  I am mining turtlecoin / Chukwa  and on this rig I only want 1 gpu mining this algo, not the entire rig.  If I do the following in my bat file  (windows 10)



This sort of works as it'll select GPU 5 and mine with it.  However the problem I then have is my other gpus on a ethash algo are only getting 1.8 Mh/s.  The Rig is a 6 GPU RX 470 rig.  However when I kill TeamRedMiner then the hashrates on ethash jumps back up to 30Mh/s.  Somehow the miner is interfering with the other GPU's. And not sure if I missed a step in my bat file.    I am using TeamRedMiner v0.6.1

Suggestions?

Appreciate the help.

Thanks I'll try rebuilding it.  Haven't done any updates to that unit since everything has been working.  I also run several Newpacs and R606's also on the same pi 4.   I'll rebuild it into a new directory and see if that resolves the issue.  I have another Pi 4 that's currently not being used, may give it a try on it as well.  Just to rule out if something is a bit off on the rig it's currently running or not.

Thanks for the assist

Any fixes for the:

Haven't seen any responses.  Just curious as now I have both miners just collecting dust, removed them completely out of my rig.  As it's getting segmentation faults on every pool.  Ran both on a Ubuntu and raspberry pi systems.  It's been running flawlessly for months 24/7 on my raspberry Pi until just recently.  Not sure why they are failing now unless this is a problem with the moon lander itself?