Pages:
Author

Topic: [ANN] Introduction to DualMiner USB (could mine both BTC and LTC) - page 13. (Read 114622 times)

hero member
Activity: 770
Merit: 501
why is the price of these good, I can buy a r9270 x for 250 bux (give or take depending on where you buy) and get near 500 KH from it, 1x 250bux .... to equial power I would need 10x these @ near 100 bux each or $1000 bux worth...

how is 1000 buc vs 250 for the Same power anywhere near better value for my money .....
hero member
Activity: 574
Merit: 500
Mining for the hell of it.
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
How are you closing your previous pool connection? Pressing 'Q' or just closing the terminal/ctrl+c? I have noticed this but usually when improperly stopping cgminer. When this occurs I just power cycle the hubs/reboot the machine. You could try to make a script that reboots in between switching pools if you want it automated.

Which is better?  I use ctrl+c, thank you for the reply too and all the help.  I will try using Q and report back if that helped.
I recommend 'Q' to safely end the cgminer process before starting a new one. This should prevent DMs from not wanting to restart with another session. You can always run
Code:
ls /dev/ttyUSB*
to make sure that all of your DMs are connected before starting cgminer. Note that for each DM you will have a pair of ttyUSB's. For example with 2 DMs, ls /dev/ttyUSB* would look like /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3. So, if you have 10 DMs you should have /dev/ttyUSB0 to /dev/ttyUSB19 listed. Not shutting down cgminer properly can cause DMs to not show up in /dev/ttyUSB*, and therefore not register with cgminer when it is restarted.

your command to show if they are connected is off.
Code:
ls /dev/*USB*
that is the correct one.
They are both producing the same outputs for me on raspbian and ubuntu. Would there be any instance of the DMs not being assigned to a ttyUSB* where *USB* is necessary? Just curious if it's possible for them to register otherwise. If so, I will change my post to make it more accurate.
If so not to my knowlage. however usually anything that is plugged in via USB to the Raspberry pi will showup under /dev/*USB* .
newbie
Activity: 41
Merit: 0
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
How are you closing your previous pool connection? Pressing 'Q' or just closing the terminal/ctrl+c? I have noticed this but usually when improperly stopping cgminer. When this occurs I just power cycle the hubs/reboot the machine. You could try to make a script that reboots in between switching pools if you want it automated.

Which is better?  I use ctrl+c, thank you for the reply too and all the help.  I will try using Q and report back if that helped.
I recommend 'Q' to safely end the cgminer process before starting a new one. This should prevent DMs from not wanting to restart with another session. You can always run
Code:
ls /dev/ttyUSB*
to make sure that all of your DMs are connected before starting cgminer. Note that for each DM you will have a pair of ttyUSB's. For example with 2 DMs, ls /dev/ttyUSB* would look like /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3. So, if you have 10 DMs you should have /dev/ttyUSB0 to /dev/ttyUSB19 listed. Not shutting down cgminer properly can cause DMs to not show up in /dev/ttyUSB*, and therefore not register with cgminer when it is restarted.

your command to show if they are connected is off.
Code:
ls /dev/*USB*
that is the correct one.
They are both producing the same outputs for me on raspbian and ubuntu. Would there be any instance of the DMs not being assigned to a ttyUSB* where *USB* is necessary? Just curious if it's possible for them to register otherwise. If so, I will change my post to make it more accurate.
hero member
Activity: 574
Merit: 500
Mining for the hell of it.
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
How are you closing your previous pool connection? Pressing 'Q' or just closing the terminal/ctrl+c? I have noticed this but usually when improperly stopping cgminer. When this occurs I just power cycle the hubs/reboot the machine. You could try to make a script that reboots in between switching pools if you want it automated.

Which is better?  I use ctrl+c, thank you for the reply too and all the help.  I will try using Q and report back if that helped.
I recommend 'Q' to safely end the cgminer process before starting a new one. This should prevent DMs from not wanting to restart with another session. You can always run
Code:
ls /dev/ttyUSB*
to make sure that all of your DMs are connected before starting cgminer. Note that for each DM you will have a pair of ttyUSB's. For example with 2 DMs, ls /dev/ttyUSB* would look like /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3. So, if you have 10 DMs you should have /dev/ttyUSB0 to /dev/ttyUSB19 listed. Not shutting down cgminer properly can cause DMs to not show up in /dev/ttyUSB*, and therefore not register with cgminer when it is restarted.

your command to show if they are connected is off.
Code:
ls /dev/*USB*
that is the correct one.
legendary
Activity: 1288
Merit: 1004
I'm glad it is all set now.
I have days like that too.
 Grin

Have you tried moving the switch back to dual mode then back to LTC mode?
It almost looks like it is stuck in dual mode without the SHA-256 side registering.

It was still in dual miner lol, long day.
hero member
Activity: 574
Merit: 500
Mining for the hell of it.
Using cgminer i notice will get it stuck in dual mode BUT it will mine in LTC mode. (both lights will come on)

Direct Dowload
Torrent Download <- would recommend but will take a little while.

1)Plug in your miners into the Raspberry Pi.
2) Download Putty from here.
3) Get your Ip and put it in where its showing on mine. (ex:192.168.1.103)


4) Then hit open
5) Login to your Raspberry pi with the default username and pass. User: pi | Pass: raspberry
6) Type in this
Code:
sudo nano cgminer.conf


7) Change your pool url, user, and pass
8) Hold down CRTL button and press X. It will ask you if you want to save hit Y then Enter.
9) Then type this in.
Code:
sudo reboot
10) You are up and mining.

When want to do a reset for your dualminers on dual-mode just unplug the hub and plug it back in.
newbie
Activity: 41
Merit: 0
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
How are you closing your previous pool connection? Pressing 'Q' or just closing the terminal/ctrl+c? I have noticed this but usually when improperly stopping cgminer. When this occurs I just power cycle the hubs/reboot the machine. You could try to make a script that reboots in between switching pools if you want it automated.

Which is better?  I use ctrl+c, thank you for the reply too and all the help.  I will try using Q and report back if that helped.
I recommend 'Q' to safely end the cgminer process before starting a new one. This should prevent DMs from not wanting to restart with another session. You can always run
Code:
ls /dev/ttyUSB*
to make sure that all of your DMs are connected before starting cgminer. Note that for each DM you will have a pair of ttyUSB's. For example with 2 DMs, ls /dev/ttyUSB* would look like /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3. So, if you have 10 DMs you should have /dev/ttyUSB0 to /dev/ttyUSB19 listed. Not shutting down cgminer properly can cause DMs to not show up in /dev/ttyUSB*, and therefore not register with cgminer when it is restarted.
full member
Activity: 134
Merit: 100
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
How are you closing your previous pool connection? Pressing 'Q' or just closing the terminal/ctrl+c? I have noticed this but usually when improperly stopping cgminer. When this occurs I just power cycle the hubs/reboot the machine. You could try to make a script that reboots in between switching pools if you want it automated.

Which is better?  I use ctrl+c, thank you for the reply too and all the help.  I will try using Q and report back if that helped.
newbie
Activity: 41
Merit: 0
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
How are you closing your previous pool connection? Pressing 'Q' or just closing the terminal/ctrl+c? I have noticed this but usually when improperly stopping cgminer. When this occurs I just power cycle the hubs/reboot the machine. You could try to make a script that reboots in between switching pools if you want it automated.
full member
Activity: 134
Merit: 100
Last question, I swear.  Does anyone else that is running the dualminer-cgminer on linux have a problem when switching to a different pool, and when doing so lose a couple usb miners that will not connect.  For example I am running 16 dualminers, when I switch from pool A close cgminer, load pool B .sh file now only 12 of the dualminers show up.  So I have to unplug all of them from the hubs, run dmesg then plug them all back in, run dmesg now connect again and all 16 show up and start mining.  But when I decide to switch to another pool, not all 16 show up and I have to repeat the above step to get the all online again?
member
Activity: 94
Merit: 10
Have you tried moving the switch back to dual mode then back to LTC mode?
It almost looks like it is stuck in dual mode without the SHA-256 side registering.

It was still in dual miner lol, long day.
newbie
Activity: 41
Merit: 0
CruzCoins after step 9 do you need to leave the  pc on with the vnc//SSH running? The whole point for me to setup this is to not have th mega WATTS pc on 24/7. Hope you don't need it on Tongue
Good question. I updated the guide to reflect these concerns.
To answer your question: no you do not need to keep your pc on.
hero member
Activity: 662
Merit: 500
what command line options does the cgminer take and how do you set modes? I don't have a unit to test with, but I've compiled all three available backends (the old cgminer 3.1.1 and cpuminer, and the new cgminer 3.5 version) for Mac OS X - testers would be appreciated!

http://fabulouspanda.co.uk/blog/index.php?post/2014/02/27/Mining-with-Gridseed-ASICs-including-DualMiner-on-Mac-OS-X
full member
Activity: 134
Merit: 100
So I have another question?  I have a gridseed 5-chip unit and went and compiled and installed the new cpuminer for that hardware on my pi.  Earlier today I compiled and ran successfully the cgminer for dualminer.  Now after installing cpuminer when I go to run my .sh file for dualminer it says cgminer --scrypt unrecognized option.  Obviously the only thing I can think of that would have screwed it up was installing cpuminer.

Any ideas?

EDIT:  I figured it out, what happened was I installed dbartles cgminer from github and installed that and forgot that I did that after installing the dualminer cgminer.  So i just started again with a fresh image of rabisian and re-installed the dualminer cgminer, and the new cpuminer for the gridseed 5 chip.  Both are now hashing away thanks to the help from this forum.   
legendary
Activity: 1288
Merit: 1004
Have you tried moving the switch back to dual mode then back to LTC mode?
It almost looks like it is stuck in dual mode without the SHA-256 side registering.




I got a small rig to test with 2 units and both are set to litecoin only, yet one stays on 40ish Kh/s the other the right number 70Kh/s. Anyone have any ideas?

member
Activity: 94
Merit: 10


I got a small rig to test with 2 units and both are set to litecoin only, yet one stays on 40ish Kh/s the other the right number 70Kh/s. Anyone have any ideas?
newbie
Activity: 41
Merit: 0
Can someone please post a rpi image for everyone?  I will offer a .025btc bounty.
Hi, I have an rpi image created for you that is already configured and will happily collect bounty. However, I recommend that people make the build themselves following the guide. If I create an image for you and you run it, you have no way of know that I did nothing malicious and hid it in the image. If you build it yourself you can sha1sum your original image and get packages for yourself. Again, I'll happily collect but I wouldn't run unknown custom pre-built images on your money printing device ;p
hero member
Activity: 574
Merit: 500
Mining for the hell of it.
Can someone please post a rpi image for everyone?  I will offer a .025btc bounty.

Of a ready to mine setup? or just of the raspbian?

Ill make a image of the iso that will be ready to rock. I will also include instructions on changing your pool info .
Basically change your pool info and reboot it and it will be ready to go with auto boot mining.
member
Activity: 65
Merit: 10
is there a windows version of cgminer yet or should we keep running the GUI?
hero member
Activity: 756
Merit: 500
Can someone please post a rpi image for everyone?  I will offer a .025btc bounty.
Pages:
Jump to: