HashFast BabyJet users thread - page 34.

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: joshv06 on February 05, 2014, 11:39:07 PM

I am here working at the DataCenter working on the BJ's. I have 12, want to put 2/case.

Where do I plug the motherboard power for the 2nd BJ into on the Power supply?

There is one port labeled "MB" on the power supply. It is already taken by the first BJ.

Thanks

On the BJ, there should be 2 sets of PCI-E cables coming out of the PSU, and one 5-pin control cable. One of the sets of the PCI-E cables along with the 5-pin connector are already connected to the existing (top) board. The other set is zip-tied up by the PSU.

You'll need a chaining cable (16 pin ribbon) and the screws/standoffs to add 2 boards to one BJ.

Once you have that, simply mount the second board, connect the chaining cable from the top to the bottom board (using the 2 closest 16 pin connectors), MOVE the 5-pin cable to the second board, and then connect the spare set of PCI-E cables to the new lower board.

-Phil

legendroute

newbie

Activity: 19

Merit: 0

Quote from: HF-Engineer on February 05, 2014, 11:29:58 PM

Quote from: -ck on February 05, 2014, 11:18:10 PM

Quote from: targetalk on February 05, 2014, 09:54:40 PM

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root.

Thanks Con. The RPI is set up to run cgminer as the user "minepeon". By default it is correctly set for this, no changes to UDEV or permissions.

Targetalk: If you are compiling your own version, you need to be sure you have enabled the HashFast driver support before compiling:

Code:

./configure --enable-hashfast

You should not need to do anything else if you have correctly run the autogen script.

Of course none of this is needed if you use the default version we supply. We will be sending out Con's latest as soon as everything is finalized and tested.

-Phil

Hi Phil,
Yes, I compiled cgminer with --enable-hashfast on my xubuntu. It can detect HF device but can not enable the device, that's why I think it's permission issue.

joshv06

hero member

Activity: 991

Merit: 500

I am here working at the DataCenter working on the BJ's. I have 12, want to put 2/case.

Where do I plug the motherboard power for the 2nd BJ into on the Power supply?

There is one port labeled "MB" on the power supply. It is already taken by the first BJ.

Any Immediate help is greatly appreciated.

Thanks

Gyrsur

legendary

Activity: 2856

Merit: 1520

Bitcoin Legal Tender Countries: 2 of 206

watching

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: -ck on February 05, 2014, 11:18:10 PM

Quote from: targetalk on February 05, 2014, 09:54:40 PM

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root.

Thanks Con. The RPI is set up to run cgminer as the user "minepeon". By default it is correctly set for this, no changes to UDEV or permissions.

Targetalk: If you are compiling your own version, you need to be sure you have enabled the HashFast driver support before compiling:

Code:

./configure --enable-hashfast

You should not need to do anything else if you have correctly run the autogen script.

Of course none of this is needed if you use the default version we supply. We will be sending out Con's latest as soon as everything is finalized and tested.

-Phil

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: targetalk on February 05, 2014, 09:54:40 PM

Quote from: -ck on February 05, 2014, 12:37:31 AM

Quote from: legendroute on February 05, 2014, 12:03:23 AM

Quote from: legendroute on February 04, 2014, 11:44:08 PM

[Suspicious link removed]

Thank you for you help minternj. I downloaded 3.12.0 and it looks can see the device, but still gave an error:
[2014-02-04 22:49:28] USB all: found 3 devices - listing known devices
.USB dev 0: Bus 2 Device 127 ID: 297c:0001
** dev 0: Failed to open, err -3
[2014-02-04 22:49:28] 1 known USB devices

Read the fine document called ASIC-README included with cgminer.

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root.

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: legendroute on February 05, 2014, 11:04:05 PM

Also Phil, I have two more questions:
1. I can see some errors in cgminer out put, how to fix them?
[image snipped]
As you can see the hardware error is keep going up, is this normal?
Also the first line of the scroll-able zone there is an error message:
HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
How to fix it?

2. Second, with default configuration, from cgminer's interface I can see the hash rate is always around 400GH/s. But from pool statistics average is only between 320 to 380. How to explain that? Can I say my BJ does not perform as described in specification?
Thanks you!
[image snipped]

In both these cases, we hope the new firmware will help correct these issues. It's absolutely normal to have some hardware errors. We have fixed the source of some of these in the upcoming firmware. Con Kolivas is also working with us to make many improvements in cgminer, so we will release both together as soon as we can.

You should be able to get about 400Gh/s at the pool (average) though you might have to clock to 600mhz to get it at present.

My test system at http://setup.hashfast.com/rpi/ is running at 600, it's got a bunch of errors, but as you can see from the pool stats on Eligius it's cruising along at about 428Gh/s for the 12 hour average:
http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87Ahd

The longer timeframe stats on Eligius tend to be more accurate and useful. The stuff under 3 hours is hit-or-miss.

-Phil

freddyfarnsworth

full member

Activity: 238

Merit: 100

Quote from: HF-Engineer on February 05, 2014, 10:44:34 PM

Anyone else getting forum errors? Can't seem to reply to existing threads. Seems like the SQL DB is corrupt or something.

-Phil

Yup. it was last night however for me.

legendroute

newbie

Activity: 19

Merit: 0

Quote from: HF-Engineer on February 05, 2014, 03:02:58 AM

Quote from: legendroute on February 05, 2014, 02:27:18 AM

Hi Phil,
It seems that it is the issue of the SD card you shipped. I replaced that card with my sandisk which is working now.
I think the SD card you provided is too thin so that the pins do not contact properly in the slot in the RB Pi. My sandisk card is much thicker and after I plug it in, I can feel solid contact. Anyway, thank you for your help. I can see it's hashing at 415G/s but for your default BTC address, will switch to my address and see. Grin

Awesome, Glad to hear it! Is the original SD card we shipped actually a "no name" Micro SD inside an adapter with the Raspberry Pi logo on it? We got those specifically because they are "official" RPI cards, so they'd be the most likely to work well, but it's turning out that they stink. We'll test some different ones for the next batch.

BTW, any time you build a new image, the first time it boots, it makes a new bitcoin wallet (viewable on the "wallet" page of the web UI), and begins mining with that wallet. Be sure if it made any BTC that you don't forget to collect it! If you make a backup from the settings page, the wallet is also backed up and restored. If you want to change to a new wallet or mining username, that's done on the "pools" page of the web UI. If you ever restore from a previous backup, it puts all your original settings in, so it's a good idea to make a backup once you get things dialed in like you want. (In case an SD card dies or something.)

-Phil

Also Phil, I have two more questions:
1. I can see some errors in cgminer out put, how to fix them?
http://i.imgur.com/eG8L8XV.png
As you can see the hardware error is keep going up, is this normal?
Also the first line of the scroll-able zone there is an error message:
HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
How to fix it?

2. Second, with default configuration, from cgminer's interface I can see the hash rate is always around 400GH/s. But from pool statistics average is only between 320 to 380. How to explain that? Can I say my BJ does not perform as described in specification?
Thanks you!
http://i.imgur.com/CaBvWqB.png

HF-Engineer

newbie

Activity: 28

Merit: 0

,

Quote from: kenpofighta on February 05, 2014, 12:25:50 PM

I was getting great performance when my 3 BJ's arrived. At least on two of them, there was one that seemed a bit flakey and seems to be getting worse. All 3 seem to be getting worse. One of them keeps shutting down and restarting grabbing a new ID each time. I posted a small capture from my monitor so that maybe if others have had this and fixed it they can help. This one that is flaky was delivered in poor condition, all but one screw was sliding around the inside of the box and 4 risers that prop the board up were also floating around. I though the board was damaged and it may be. Worst assembly I have ever seen and I used to build PC's. That point is mute if they all work but they don't.

Here is what I need help answering.
1. How do I get back to my 400+ GH performance. All three of these were pushing +-420GH.
2. Worse case scenario is how do I raise the clock speed to get up to the 400GH range? I was promised by Erin at Hashfast that it would not void the warranty but the delivery paperwork stated otherwise. I will have to deal with that warranty issue separately, I know.
3. I seem to be getting huge error rates, I think it is on the flaky board but not 100% sure that is the only place. 70% to 80% errors are common. Elgius reports I am only getting 900 to 950 GH/s AVG with 3 boards and I should be getting closer to 1200. Not good for profits. Any help would be appreciated. I hate to try and send a board back under warranty since I might be stuck for months. I still am waiting on my 3 upgrades, I would hat to be down to 2 processors if I can avoid it.

Sorry about the loose parts. The problem wasn't bad assembly, it was the parts coming loose during shipping. They are using threadlock now to stop that problem. It's unlikely your boards are damaged if they are hashing on all 4 die, which sounds like they are.

What are your die temps and voltages? (if you run the "hf" version of cgminer it reports all dies/voltages)

Since your unit obviously had quite a ride during shipping, I'd look at each die temp and see if there is a discrepancy. You might need to take the cooler head off, re-grease the thermal interface, and re-tighten the cooler. Apparently some of those earlier orders that had loose standoffs have a high chance of having a loose cooler.

Also, what hash clock speed are you using? Have you tired other speeds?

-Phil

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: legendroute on February 05, 2014, 10:12:21 PM

Hi Phil,
Yes the defective SD card is the default RB Pi card with the log on it. I can not say it's the card's issue because it works fine on my computer, I think it just does not fit well with the slot in the Pi. But the fix is definitely use a thicker card.

I don't really understand the collection from the default wallet? Do you mean there is a default wallet created on the Raspberry Pi and there could be BTC already generated during the test? In my case cause I have never get original card boot successfully, and just created new card from downloaded image, does that mean I lost the original wallet already? And I also don't understand how to use that wallet and transfer the BTC out? Is there a wallet application on RB Pi? Or I just recover this wallet on another computer using the key pare? Thanks!

This is why I always ask people to make a backup.

Yes, a new wallet is generated the first time each new image is booted on the RPI. It then begins mining with that wallet, it's yours to keep. We test all BJ's at the factory like that, and some machines end up mining overnight, so there's sometimes a good bit of coin in there! I absolutely hate "orphaning" any BTC regardless of amount, as it's forever lost.

See if you can get that old card to boot, even if you have to take the case off the RPI and hold down the card. We've yet to see that particular problem. Maybe it's just a bent contact on your RPI's socket? A closer inspection may reveal why.

If you can get it to boot, the wallet is visible on the "Wallet" page from the web interface, and if you make a backup from the settings page, it will contain the wallet.

-Phil

HF-Engineer

newbie

Activity: 28

Merit: 0

Anyone else getting forum errors? Can't seem to reply to existing threads. Seems like the SQL DB is corrupt or something.

-Phil

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: NiteShdw on February 05, 2014, 01:32:23 PM

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143). However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

That's in the new firmware that's coming soon. Sorry, until we complete testing we cannot release it. I'll say it again; Until the new firmware comes out, you're best bet is to run 3.9.0hf2 that I've posted here.

-Phil

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: phreakk on February 05, 2014, 11:50:07 AM

Quote from: HF-Engineer on February 05, 2014, 12:56:04 AM

Here's the source code: http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz
(MD5: fdef15ae73b180deef74bc51df482eb0)

-Phil

Any Windows binaries available?

Sorry, we don't officially support windows as a platform. I don't run it either, so I can't even unofficially help you out. Maybe someone here you trust can compile it for you?

I firmly believe the RPI is a better platform your average windows machine, and the monitoring and remote capabilities MinePeon brings is nice to have. I can pull up my miner on my phone and get text messages if it ever goes down. (has yet to happen unless I unplug it!)

-Phil

HF-Engineer

newbie

Activity: 28

Merit: 0

Quote from: Morblias on February 05, 2014, 10:46:42 AM

Quote from: HF-Engineer on February 05, 2014, 12:56:04 AM

If you use our RPI image as configured, you will have a reliable mining system and will get updates as they are made available. Here's my personal system mining away: http://setup.hashfast.com/rpi/

-Phil

Just curious, what core clock are you running this at? I ran mine at default (550) for a day and it got about 400GH/s, 0.37% rejects, and 1.83% errors and showed 360GH/s on eligius. Overnight I started it at 560 and it shows 412GH/s, 0.36% rejects, and 9.26% errors with 388GH/s showing on eligius. Should I be worried about 9.26% error rate? They run at 80C/80C/70C/72C right now.

It's running at 600. You can see that it's not totally stable at that speed, it gets the "work watchdog restart" often, but overall the hashrate is higher because it resumes hashing almost immediately if it stops. MinePeon's stats page looks silly, but that matters is the pool's reported hashrate which you can see here:
http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87Ahd

Only worry about the error rate if it starts to lower your overall rate.

-Phil

legendroute

newbie

Activity: 19

Merit: 0

Quote from: HF-Engineer on February 05, 2014, 03:02:58 AM

Quote from: legendroute on February 05, 2014, 02:27:18 AM

Hi Phil,
It seems that it is the issue of the SD card you shipped. I replaced that card with my sandisk which is working now.
I think the SD card you provided is too thin so that the pins do not contact properly in the slot in the RB Pi. My sandisk card is much thicker and after I plug it in, I can feel solid contact. Anyway, thank you for your help. I can see it's hashing at 415G/s but for your default BTC address, will switch to my address and see. Grin

Awesome, Glad to hear it! Is the original SD card we shipped actually a "no name" Micro SD inside an adapter with the Raspberry Pi logo on it? We got those specifically because they are "official" RPI cards, so they'd be the most likely to work well, but it's turning out that they stink. We'll test some different ones for the next batch.

BTW, any time you build a new image, the first time it boots, it makes a new bitcoin wallet (viewable on the "wallet" page of the web UI), and begins mining with that wallet. Be sure if it made any BTC that you don't forget to collect it! If you make a backup from the settings page, the wallet is also backed up and restored. If you want to change to a new wallet or mining username, that's done on the "pools" page of the web UI. If you ever restore from a previous backup, it puts all your original settings in, so it's a good idea to make a backup once you get things dialed in like you want. (In case an SD card dies or something.)

-Phil

Hi Phil,
Yes the defective SD card is the default RB Pi card with the log on it. I can not say it's the card's issue because it works fine on my computer, I think it just does not fit well with the slot in the Pi. But the fix is definitely use a thicker card.

I don't really understand the collection from the default wallet? Do you mean there is a default wallet created on the Raspberry Pi and there could be BTC already generated during the test? In my case cause I have never get original card boot successfully, and just created new card from downloaded image, does that mean I lost the original wallet already? And I also don't understand how to use that wallet and transfer the BTC out? Is there a wallet application on RB Pi? Or I just recover this wallet on another computer using the key pare? Thanks!

targetalk

newbie

Activity: 1

Merit: 0

Quote from: -ck on February 05, 2014, 12:37:31 AM

Quote from: legendroute on February 05, 2014, 12:03:23 AM

Quote from: legendroute on February 04, 2014, 11:44:08 PM

[Suspicious link removed]

Thank you for you help minternj. I downloaded 3.12.0 and it looks can see the device, but still gave an error:
[2014-02-04 22:49:28] USB all: found 3 devices - listing known devices
.USB dev 0: Bus 2 Device 127 ID: 297c:0001
** dev 0: Failed to open, err -3
[2014-02-04 22:49:28] 1 known USB devices

Read the fine document called ASIC-README included with cgminer.

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: starsoccer9 on February 05, 2014, 06:45:20 PM

Quote from: -ck on February 05, 2014, 06:27:36 PM

Quote from: NiteShdw on February 05, 2014, 01:32:23 PM

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143). However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

The code in git master needs new firmware which is not out yet.

2 quick questions,

1. is it possible to just disable cgminer from seeing other hardware, for example BFL. I tried the only allowing usb device 1 or something but I have no way of figuring out which device is what number.

2. is there anyway to see each cores temp in windows like on the RPI?

1. Read section on --usb in the README eg --usb HFA:1,BAS:0
2. Via the RPC API stats command which has busloads of information.
eg:
java API stats

Code:

[STATS8] =>
(
   [STATS] => 8
   [ID] => HFS3
   [Elapsed] => 45661
   [Calls] => 0
   [Wait] => 0.000000
   [Max] => 0.000000
   [Min] => 99999999.000000
   [asic count] => 12
   [core count] => 96
   [firmware rev] => 0.3
   [hardware rev] => 1.1
   [serial number] => 0xc10cfe86
   [hash clockrate] => 604
   [inflight target] => 2300
   [sequence modulus] => 8192
   [fan percent] => 56
   [rx preambles] => 2
   [rx rcv byte err] => 0
   [rx bad hcrc] => 0
   [tx attempts] => 0
   [tx packets] => 0
   [tx incompletes] => 0
   [tx ep stalled] => 0
   [tx disconnect] => 0
   [tx suspend] => 0
   [max tx buf] => 0
   [max rx buf] => 0
   [Core] => 0
   [hash clockrate] => 615
   [die temperature] => 79.300781
   [board temperature] => 65.489990
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 1
   [hash clockrate] => 615
   [die temperature] => 73.968750
   [board temperature] => 65.895256
   [core voltage] => 0: 0.80
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 2
   [hash clockrate] => 615
   [die temperature] => 79.242188
   [board temperature] => 64.298401
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 3
   [hash clockrate] => 615
   [die temperature] => 81.234375
   [board temperature] => 63.523308
   [core voltage] => 0: 0.78
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 5364
   [stats overrun] => 21
   [Core] => 4
   [hash clockrate] => 615
   [die temperature] => 83.871094
   [board temperature] => 75.037781
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 5
   [hash clockrate] => 615
   [die temperature] => 80.414062
   [board temperature] => 74.524971
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 6
   [hash clockrate] => 615
   [die temperature] => 80.589844
   [board temperature] => 69.744179
   [core voltage] => 0: 0.78
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 7
   [hash clockrate] => 615
   [die temperature] => 87.503906
   [board temperature] => 73.768532
   [core voltage] => 0: 0.78
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 8
   [hash clockrate] => 615
   [die temperature] => 78.070312
   [board temperature] => 66.304733
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 9
   [hash clockrate] => 615
   [die temperature] => 76.429688
   [board temperature] => 69.297256
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 10
   [hash clockrate] => 615
   [die temperature] => 78.070312
   [board temperature] => 68.855446
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 11
   [hash clockrate] => 615
   [die temperature] => 75.375000
   [board temperature] => 72.299377
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [raw hashcount] => 54752187254833152
   [calc hashcount] => 50974458467488978
   [no matching work] => 675
   [resets] => 0
   [USB Pipe] => 0
   [USB Delay] => r0 0.000000 w0 0.000000
   [USB tmo] => 13598514 0
)

starsoccer9

legendary

Activity: 1630

Merit: 1000

Quote from: -ck on February 05, 2014, 06:27:36 PM

Quote from: NiteShdw on February 05, 2014, 01:32:23 PM

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143). However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

The code in git master needs new firmware which is not out yet.

2 quick questions,

1. is it possible to just disable cgminer from seeing other hardware, for example BFL. I tried the only allowing usb device 1 or something but I have no way of figuring out which device is what number.

2. is there anyway to see each cores temp in windows like on the RPI?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: NiteShdw on February 05, 2014, 01:32:23 PM

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143). However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

The code in git master needs new firmware which is not out yet.

Topic: HashFast BabyJet users thread - page 34. (Read 68982 times)