 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
The feedback on our rev2 engineering chips has been positive so we're ready to go into sales of production chips. Our first production batch is rolling off the line as I write this. These are going to be TESTED CHIPS. I should receive the first batch in the coming week, so be ready to grab some GH at amazing prices!! DIY FTW! 3.85GH/s already achieved, how much will you be able so squeeze out? I see you have trays of rev2 chips on the site now - are the chips in those the tested ones? |
|
|
|
+1 to the excellent service  Is there any chance we'll see bare chips back on sale any time soon? Can anyone tell me what spacers I should use to keep boards with heatsinks apart - I was thinking ~15mm non-conductive... |
|
|
|
Happy New Year bump!  Any sign of cheap chips coming our way in Europe any time soon? There is talk on the US Bitfury thread of $5/chip for Feb delivery... |
|
|
|
Bump - it's all gone very quiet on here  Punin - I hope you and your team get a good break over Christmas, but I also really hope you'll be back with bucket loads of chips for sale in the new year! |
|
|
|
I think that BTC price will crash before those new H boards show in shop.
850 euros pricing is ridiculous.
If I were you punin, I would be ashamed to talk about those prices in public.
Have some integrity. it doesnt matter who is setting that price policy - use your own brain.
I don't know where all this hostility/sense of entitlement comes from - if you had the skills to roll your own ASICs would you be giving them away? BTC hardware may be a seller's market, but it is still a market. If no buyers like the prices, the sellers will drop them. If it just so happens that someone building a 500TH mine has more buying power than you, you can either winge, or find enough like minded souls for a 750TH group buy... |
|
|
|
|
I for one appreciate the job you've been doing punin - nobody has to offer to sell us this bespoke technology after all...
Have all the new chips gone onto boards, or do you think you'll have loose chips available again?
|
|
|
|
Guys, is a level converter essential or is it optional when connecting to a rPI? Thanks
I'm pretty sure it is essential! The rpi's I/O use 3.3v, the Bitfury chips will not like that (i.e. die horribly), as they're meant for 1.8v I/O... I would also be very wary of power-sequencing issues if you are not powering your rpi from your rig - I had a try at using opto-isolators to separate the rpi and miner power domains, but my optos were way too slow for the SPI. Now my board supplies the pi with 5v directly. |
|
|
|
Just wanted to thank everyone for the help, this is what the rig looks like. 8.5 GH/s  I'm loving that! You're also beating my 8-chip setup which seems to peak at 9GH/s and then rapidly dip to ~3 on chainminer. For some reason, I get 4,5 or 7 chips detected, depending on the direction the wind's blowing If I thought I could get my hands on some more chips, I'd be tempted to respin my board with a way to take dodgy chips out of the SPI chain... Did anyone ever get a QFN ZIF-socket and build a chip tester? |
|
|
|
Thanks - I downloaded the rpi image and had a play with spitest-D
Has anyone else seen their chips go into a mode where the in_miso pin starts oscillating very slowly - e.g. about 1Hz, even when the SPI clock isn't running?
My guess is that the MISO pin keeps showing the last bit that you read (or the one after that). In the case of normal miner operation, that would be the register that indicates the job it is working on, which toggles between 1 and 0 every 2^22 clock cycles. Cheers c-scape, that makes sense! |
|
|
|
|
Thanks - I downloaded the rpi image and had a play with spitest-D
Has anyone else seen their chips go into a mode where the in_miso pin (i.e. the output of the chain back to the rpi) starts oscillating very slowly - e.g. about 1Hz, even when the SPI clock isn't running?
|
|
|
|
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
Where did you get that version of spitest from that takes command-line options? Can you post a link please? |
|
|
|
Actually, I'd like some comments from you...
- Would you like a USB miner or are you happy with standalone RasPi controlled unit?
- Do you feel modular design is important, or would you prefer a nice tidy box?
- What about form factor: free or rack?
- What dB level are you comfortable with?
- Internal custom PSU or ATX?
Standalone with ethernet - doesn't need to be a rpi, I don't want to have to manage a load more linux boxes, any <10Euro micro that can talk to a Stratum proxy will do. Probably nice-tidy box or board on heatsink. Free Noise level - about the same as a PC if possible External PSU And I think these things need to start at 50-100GH/s - the network's moved on from 10GH/s being a load! |
|
|
|
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. |
|
|
|
|
If your new board design isn't quite right, could you please at least consider shipping some trays of chips while you get your in house design debugged?
|
|
|
|
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  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. |
|
|
|
Loving the use of strip-board - you must be a glutton for punishment!  It takes 2 weeks to wait a for a board ... just to find out you've messed something I've made a small board for just the chip with caps - the rest is easy to be put even on a strip-bard and this way i could also swap the chips at will and test the differences between them. Now I am (almost) sure the prototype will work as expected Does your small board even have solder-resist? I'm very impressed if you managed to put the QFN's down without it! |
|
|
|
That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board. Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup I would have liked to have c-scape in my design review to say 'you don't want to do it like that!'  That seems like a short coming or bug in the CPLD. A CPLD with 3.3V tolerant I/O shouldn't care what the state of the pins are when it powers up... which CPLD did you use? which is why I picked to go with the KISS Principle - a few resistors, one transistor and that's all - very very few things to go wrong Well, I was going for the more-integration => less to go wrong side of the KISS principle, seems your version was more successful this time round! |
|
|
|
As promised:  It is not possible to get a good focus with a mobile, but this  is the level shifter, not a death bug on my desk Loving the use of strip-board - you must be a glutton for punishment! |
|
|
|
That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board. Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup I would have liked to have c-scape in my design review to say 'you don't want to do it like that!' That seems like a short coming or bug in the CPLD. A CPLD with 3.3V tolerant I/O shouldn't care what the state of the pins are when it powers up... which CPLD did you use? Yeah, I'm a bit surprised they're so easy to damage... I'm using a Xilinx xc2c64 - once I've swapped this dead one out, I'll make sure I take the 3.3v feed from the rpi. |
|
|
|
cscape is of course 100% right, but hey, I work on these things late at night after the kids are asleep... so level shifters: if one is good, then two must be better. Also, you could make an argument that when driving board-to-board 3.3V has a better noise margin than 1.8V.
That was my plan with the CPLD - 1.8v I/O within each board, 3.3v between them and the controller board. Unfortunately I didn't think through the implications of powering the rpi independently of the 3.3v to the board during bring up - I wanted to be able to measure the board's 3.3v draw. Unfortunately if you power the rpi up before the board, you send 3.3v into an unpowered I/O pin on the CPLD and the chip goes into latchup I would have liked to have c-scape in my design review to say 'you don't want to do it like that!' |
|
|
|
|
