Worst case you need to ensure that chip is not broken. If you have the second sample available you could double check.
Yes, I have a second sample, and I'm planning to assemble another board. That way I can test the boards separately, but also link them in a chain, and see if the behaviour changes. |
|
|
|
Please double check: - keep RESETn low for a second, then at RESETn=1 wait for another second before you send the first command
- connect SDI_L to SDO_L to close the SPI chain
From here I would guess SDI_L and SDO_L are not connected, leaving the SPI chain open. With that, all broadcast commands fail - among others the chip can not finalize its chip enumeration, thus responds only to 0xa00 - which btw. is an illegal command, since READ_REG is addressed to individual chips and not defined for broadcast. Let me know if you need further help. SDI_L/SDO_L was my first thought as well, but I double checked, and they are connected. I tried a continuity tester, but I also with the scope I see identical waveforms on both pins. I also used a 1 sec reset and 1 sec pause. The READ_REG for broadcast seems to work, though. The results make sense. - 0x0100 (BIST_START) is a one-shot command: enumeration works only once after HW-reset, subsequent calls return 0 for chip count
Actually, after a HW-reset I get 0x0000, and subsequent calls return 0xFFFF. I was wondering, has anybody else ever tried a single chip before ? |
|
|
|
3) Command Sequence After a HW-reset as described above issue the following command sequence stages: a) initialize chain - RESET_BCAST: send 0x0400, poll for 0x0400 response
- BIST_START_BCAST: send 0x0100, poll for 0x01nn, where nn is the number of chips found in chain
- BIST_FIX_BCAST: send 0x0300, poll for 0x0300
I have a single A1 chip on a board. When I send 0x0400 I get the 0x0400 response, but when I send 0x0100, I get 0x0100 0x0000 back. Any idea ? If I continue with 0x0300 command, and 0x0A01, I read 0x0A01 back, followed by 0xFFFF. If I send 0x0A00, then I get 0x1A00, and the correct register value. |
|
|
|
Those are all low power devices though. These things use way more power than most USB devices. Remember the Pi was built as a cheap device for educational purposes and is not a fully fledged computer. If power concern is an issue why not look at buying an old lenovo think pad off of ebay and using that as a host? you can pick them up for not much more then a pi and a USB 3 port going to USB 2 ports on the thinkpad would work.
The bi*fury only starts to use power when the miner sends some work (at least with new firmware), so it should still be detected when it's plugged in. |
|
|
|
Tried alot of different software for the raspberry, both raspbian and pidora, with verious versions of both cgminer and bfgminer. None of them even detects the bi*fury's
Is there anything in /var/log/messages that shows up when you plug them in ? Does your raspberry board work with other USB devices, like a memory stick ? Can you use usbmon ( https://www.kernel.org/doc/Documentation/usb/usbmon.txt) to make a USB trace when you plug in a bi*fury device ? |
|
|
|
Anyone know what these use as a temperature sensor? and if there is a way to trick it back to normal range(i suspect my DOA was returned with a tricked temp sensor)?
The temperature sensor is a 330 Ohm (nominal value at 25C) NTC resistor, located between the 2 bitfury chips and big black inductor. It's a 0603 component, slightly larger than the 0402 caps around the bitfurys.  |
|
|
|
Tried Oscillator bits, but the only thing that changes is the temp getting higher, should it not get more speed?
Higher values get you a higher clock rate, but also increases the hardware error rate, so higher clock settings may not result in increased overall hashing speed. The error rate is usually quite low at clock setting 54 and lower, and increases dramatically for higher settings. Of course, there's always individual variation in chips, so it's worth a try to play with this. Don't be surprised if the default setting is already optimal, though. |
|
|
|
I asked cscape about that he said he got no news from you ! can you explain me what is going on with my miners?
I can confirm that I have not gotten any e-mail since Nov 20 2013. Just in case there's an e-mail issue, go ahead and post the log in the forum. |
|
|
|
I have had it hooked up and it just seems to hang right before it attempts to join a pool. No pool info or anything is displayed. It just gets to the part where it displays my local IP,s and does not add the pool IP info. Whereas when I join a pool that I can join it just connects no problem.
Please post/PM the log. Another thing I have noticed is that when I tried to join one today it kept adding my user name to the end of the server URL in the web interface after I would hit the set pools button.
Can you show exactly what's happening ? The firmware does not do anything with the URL, so I have no idea what's going on. |
|
|
|
I am having some issues with only being able to connect my miners to a few servers. For some reason they will not connect to certain servers. Such as multipools, ispace and others.
They probably use unsupported stratum commands. If you hook up USB debug cable, the firmware should tell you if it receives something it doesn't understand. Depending on what it is, I may be able to add it. It would have been nice if the most widely used bitcoin mining protocol had a specification... |
|
|
|
I think this is the best bang for the buck you can get out of bitfury chips in a USB stick form factor.
Yes, that was the idea. Total BOM cost is about $4, excluding bitfury ASICs. |
|
|
|
|
You may also get a pop-up asking for username/password to get access to web interface. That can be disabled by typing "user *" in the terminal window.
|
|
|
|
|
If windows doesn't see the removable disk, there's no harm done. You can pull the device out, and plug it back in, to use it normally with the old firmware.
Only when you delete/replace the firmware and something goes wrong there, it may not start up properly. But even in that case, using the tweezer trick again takes you back to the removable disk, and you can try again.
For Mac/Linux users, please read back a few posts in this thread.
|
|
|
|
Ok thanks! i hope the bi*Fury is alright. i order a usb fan right now. i did not know it would be this warm without doing mining.
The latest firmware is smarter, and will only power up the chips when it has received some recent data from the miner software. It will also power down the chips again when the miner software stops, or when the board gets too hot. You can get firmware upgrades here: http://c-scape.nl/bi-fury/ |
|
|
|
I see, then there is little hope for the S-HASH to work with P2pool.
Currently I will stick with Eligius but fallback to HHTT to see how it works.
Thanks for the help!
Another problem with p2pool is the fast block times, and the fact that the bitfury chips don't have an option to cancel the job they've started. This means that it would be impossible to avoid large percentage of stale blocks. |
|
|
|
"Response from pool too long" problem also sometimes happens with Eligius,
I guess it is due to large generation transactions for payout?
Correct. Because all stratum decoding is handled by small microcontroller, with just a few kilobytes of memory, it can be a problem sometimes. The theoretical requirement could be a few megabytes, so there's just no way it can be modified to handle all circumstances. Most other pools have much smaller requirements, because they only have a simple transaction to their own wallet. |
|
|
|
|
I don't mind if 0.1.10 gets posted, but I had some problems with 0.1.8 and 0.1.9 sometimes bricking the board. I think the bug has been found and fixed in 0.1.10, but I'm still concerned about this happening again. As far as hashing performance, there's absolutely no change between 0.1.10 and older. The only noticable improvement for end users is the better backup pool logic, and slightly larger memory for stratum decoding.
If your board is running stable on an old version, I would not recommend upgrading.
|
|
|
|
|
Sounds like a hardware problem. Can you tell if all chips are getting hot ?
|
|
|
|
|
Show Posts
