[ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 7.

mjgraham

full member

Activity: 188

Merit: 100

Well I did that and it detects two chips and hashed at .2 gh/s I noticed it drew .2A , since I made this board my self and used conductive silver epoxy for the vias the had failed where I attached the gnd connection since I was measuring from the wire it was ok but on the board it was .4v of course when I fixed that now I run cgminer and it finds two chips and says that thread 0 is disabled. draws 1.7 A now at least

mjgraham

full member

Activity: 188

Merit: 100

Quote from: KNK on November 26, 2013, 10:17:12 AM

Quote from: mjgraham on November 26, 2013, 09:20:31 AM

The level shifter I am using 74AVC4T24 is (hard)wired two bits one direction and two the other.

And ... you need Active Low OE for it - use my fork and in tm_i2c.c enable the line

Code:

#define BF_OE_ACTIVE_LOW

You didn't say where is your OE connected, but you should define it in bf_bank_gpio[] in the same file, also in bitfury-config.h you need to change

Code:

#define BITFURY_MAXBANKS 1

to

Code:

#define BITFURY_MAXBANKS 2

so the GPIO's are used.

0.75A is not enough - you need at least 2A there

Humm I see that there is more to it that I was thinking, I would have thought all the reading I have done .. any way, the !OEs are tied to ground to be always on, as for the current that is all it was drawing at that voltage, first power on was .1 after running the spitest-D went to ~.75

KNK

hero member

Activity: 692

Merit: 502

Quote from: mjgraham on November 26, 2013, 09:20:31 AM

The level shifter I am using 74AVC4T24 is (hard)wired two bits one direction and two the other.

And ... you need Active Low OE for it - use my fork and in tm_i2c.c enable the line

Code:

#define BF_OE_ACTIVE_LOW

You didn't say where is your OE connected, but you should define it in bf_bank_gpio[] in the same file, also in bitfury-config.h you need to change

Code:

#define BITFURY_MAXBANKS 1

to

Code:

#define BITFURY_MAXBANKS 2

so the GPIO's are used.

0.75A is not enough - you need at least 2A there

mjgraham

full member

Activity: 188

Merit: 100

Yes I have determined that there are a lot of forks out there, I guess if I had been on from the start I would have understood more about this. I have tried two , legkodymov is the first one, and OpenGland I think. the first one just flashed the screen the second one acted like it detected it but sat there with 0 h/s. The level shifter I am using 74AVC4T24 is (hard)wired two bits one direction and two the other. Pins 19 and 23 go as outputs from the pi to BF and pin 21 as an input to the pi. Another thing is the current when I started was 0.8v @ 0.75A as I kept tinkering it was down to 0.35A after a while. I guess what I need to know is that does the spitest-D indicate that is does work to some degree, I have some other chips but I don't want to start just putting them on there yet. Also does there need to be any kind of termination on the last chip, I have hard talk of it at times but see a lot of single designs that don't have any.
thanks

KNK

hero member

Activity: 692

Merit: 502

Quote from: mjgraham on November 25, 2013, 07:30:26 PM

However when i build the cgminer fork with the --enable-bitfury and try to run it it does not detect any chips

Which fork, what kind of level shifters and options defined in bitfury-config.h ?
If BITFURY_MUX_OE is defined (for example) it won't detect the chips with a normal level shifter and GPIO for selects
Your level shifter may require active low instead of active high for OE, which you define in tm_i2c.c if you use my fork

mjgraham

full member

Activity: 188

Merit: 100

First off I want to say thanks for any help, second I feel kind of dumb asking for help after all the reading I have done. What I have is a raspi to a level shifter to a quad board I built with one chip on it. I have tested the spi loopback thought the level shifter and that is good and using spitest-D 1 5000000 gives me 12~13 solutions and when I put a 2 in the chip I get nothing like I expect. However when i build the cgminer fork with the --enable-bitfury and try to run it it does not detect any chips and drops out at first I could not tell the screen just flashed had to put -T on there. Just any ideas would be helpful.
thanks
Jarrid Graham

aauer1

member

Activity: 110

Merit: 10

Thanks!

vs3

hero member

Activity: 622

Merit: 500

Quote from: aauer1 on November 21, 2013, 07:18:54 AM

Hello,

I'm looking for the detailed package specification. Is the QFN48 package conform to some JEDEC standard? If it is, can someone add the JEDEC code here?

Otherwise, has anybody a drawing of the package with dimensioning? I would like to know the following parameters:
- length, width and height of the overall package
- pitch
- nominal width and length of the 48 pins
- width and length of the bottom ground pad

Thank you very much,
Andreas

I think those two quotes will answer your questions:

Quote from: bitfury on February 07, 2013, 10:19:48 AM

Finally die dimensions chosen: 3.8x3.8mm
Package: QFN48
Performance: 3.3 GH/s _rated performance_, about 7 GH/s maximum
Power consumption: 1 W at _rated_ performance @ 0.6 V, 6 W _maximum_ performance @ 1.0 V.
Thermal characteristics of package: 2 K / W junction-to-pcb and 34 K / W junction-to-ambient.

Quote from: ermak72 on July 17, 2013, 11:28:29 AM

Quote from: Dexter770221 on July 17, 2013, 07:57:24 AM

Someone can give me dimensions of thermal pad? And what material is used (copper?).

QFN48 7x7, 0.5P Copper Alloy and Plating

That document in the link has also all the physical dimensions, pads, etc.
The bitfury library in my project was based on that document. From what I can tell - it seems to be good

aauer1

member

Activity: 110

Merit: 10

Hello,

I'm looking for the detailed package specification. Is the QFN48 package conform to some JEDEC standard? If it is, can someone add the JEDEC code here?

Otherwise, has anybody a drawing of the package with dimensioning? I would like to know the following parameters:
- length, width and height of the overall package
- pitch
- nominal width and length of the 48 pins
- width and length of the bottom ground pad

Thank you very much,
Andreas

goodney

member

Activity: 102

Merit: 10

Quote from: gingernuts on November 20, 2013, 07:21:22 PM

I'll give the cgminer fork a go. It doesn't seem the most reliable at detecting my small string of chips though, perhaps I need to play with the SPI code as I only have a few chips hooked up.

Do you have INCLK grounded? I didn't at first but once I did it made a huge difference.

-a[g

gingernuts

member

Activity: 89

Merit: 10

Quote from: goodney on November 18, 2013, 02:17:22 PM

Quote from: gingernuts on November 15, 2013, 08:31:30 PM

So, which is the best S/W to use with Bitfury chips - chainminer or the cgminer fork?

Cheers.

Two things. One, you're not allowed in my lab ;-p Two: I get better results with the cgminer fork.

Good luck! And be nice to your RPi's. On the other hand, I think they just announced that 2M RPi's have been sold, so they're not exactly scarce.

-a[g

That's fair enough - but I am getting pretty good at surface-mount rework now!

I'll give the cgminer fork a go. It doesn't seem the most reliable at detecting my small string of chips though, perhaps I need to play with the SPI code as I only have a few chips hooked up.

goodney

member

Activity: 102

Merit: 10

Quote from: KNK on November 19, 2013, 05:45:28 PM

Quote from: goodney on November 19, 2013, 05:25:30 PM

I looked at the code that calculates these values, but it hurts my head to look at. Can someone give me a summary?

It's backward calculated hashrate ... because we don't have the actual number for it nor for the frequency they are calculated from the time it takes to scan a full range of nonces, but of course it also depend on the delay it takes to measure it and that's why it shows different values on Win and Mac - scheduler delays and sleep times accuracy.

Quote

There also seems to be some timing based voodoo for talking to the chip that is based on sleeping for 100ms between SPI transfers. Can someone explain how this plays into the hash rate and the number of shares found?

It affects the calculated stats values precision but not the actual hashrate (IMHO) - it takes over a second to scan a range of nonces and 100ms sleep does not affect it in any way, just gives some time for the CPU to prepare more work and process results before the next scan. If you increase it too much, you may miss a share (if more than 15 are found after the previous check) and if reduced too much will increase the CPU load and even bring the hashrate down, because of the absence of 'fresh work' in time.

Thanks KNK! Just the information I need. Given this information I think I need to verify that my OSX-ified process-time and wall-clock time routines are returning good numbers (because of course OS X doesn't have clock_gettime()).

-a[g

KNK

hero member

Activity: 692

Merit: 502

Quote from: goodney on November 19, 2013, 05:25:30 PM

I looked at the code that calculates these values, but it hurts my head to look at. Can someone give me a summary?

It's backward calculated hashrate ... because we don't have the actual number for it nor for the frequency they are calculated from the time it takes to scan a full range of nonces, but of course it also depend on the delay it takes to measure it and that's why it shows different values on Win and Mac - scheduler delays and sleep times accuracy.

Quote

There also seems to be some timing based voodoo for talking to the chip that is based on sleeping for 100ms between SPI transfers. Can someone explain how this plays into the hash rate and the number of shares found?

It affects the calculated stats values precision but not the actual hashrate (IMHO) - it takes over a second to scan a range of nonces and 100ms sleep does not affect it in any way, just gives some time for the CPU to prepare more work and process results before the next scan. If you increase it too much, you may miss a share (if more than 15 are found after the previous check) and if reduced too much will increase the CPU load and even bring the hashrate down, because of the absence of 'fresh work' in time.

goodney

member

Activity: 102

Merit: 10

Here is another shot of my dev board. Cool thing to note here is that the SPI is being handled by a FTDI MPSSE based USB chip. No microcontoller required! It is kind of messy, but the KNK cgminer fork only required changes to a couple of source files.

Everything seems to work, however I have a couple of questions I hope the other developers on here can answer:

What drives the total hash rate of the BitFury chip? When connected to the RPi the board averages 2.0GH/s long term, which when it is connected to my Mac it averages around 1.6-1.7 GH/s.

The short stats message also differs between the RPi and my Mac version. On the RPi it reports ~180MHz with a target hash rate of 2.1GH/s or so. On the Mac it reports around 140MHz with 1.75 GH/s. I looked at the code that calculates these values, but it hurts my head to look at. Can someone give me a summary? I've also played around with the clock bits, but this doesn't seem to do much.

There also seems to be some timing based voodoo for talking to the chip that is based on sleeping for 100ms between SPI transfers. Can someone explain how this plays into the hash rate and the number of shares found?

Thanks!

-a[g

cxboyminer

hero member

Activity: 896

Merit: 500

oh... that's disappointing...

bee7

hero member

Activity: 574

Merit: 523

Quote from: cxboyminer on November 18, 2013, 02:52:11 PM

I am very interested in being a beta tester for this chip. i can speak chinese (very well, from Hong Kong) and hopefully this will help.

The beta testing is over long time ago.

cxboyminer

hero member

Activity: 896

Merit: 500

I am very interested in being a beta tester for this chip. i can speak chinese (very well, from Hong Kong) and hopefully this will help.

goodney

member

Activity: 102

Merit: 10

Quote from: gingernuts on November 15, 2013, 08:31:30 PM

So, which is the best S/W to use with Bitfury chips - chainminer or the cgminer fork?

Cheers.

Two things. One, you're not allowed in my lab ;-p Two: I get better results with the cgminer fork.

Good luck! And be nice to your RPi's. On the other hand, I think they just announced that 2M RPi's have been sold, so they're not exactly scarce.

-a[g

gingernuts

member

Activity: 89

Merit: 10

Well, I think I may have broken a record by killing two rpi's in two days!

I switched to having the rpi power the 3.3v logic on my board, and fried the pi's 3.3v regulator Roll Eyes

On the upside, I did get it hashing for a while before I shorted killed the rpi - and I can probably replace the regulator and reanimate it...

So, which is the best S/W to use with Bitfury chips - chainminer or the cgminer fork?

Cheers.

KNK

hero member

Activity: 692

Merit: 502

Quote from: gingernuts on November 08, 2013, 04:36:00 AM

Does your small board even have solder-resist? I'm very impressed if you managed to put the QFN's down without it!

I don't have so steady hands (can be seen from the LS soldering), so a friend have helped with the chips actually.
No, it doesn't have solder mask, but most of the pins are power and they are shorted anyway, so starting from there to hold the chip in place is the way he did it.

Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 7. (Read 176671 times)