First - huge thanks to z3phyreo for porting my collection of quotes and links regarding the bitfury chip (a.k.a. The Documentation
)! It is now on the project's wiki page:https://github.com/nanofury/NanoFury/wiki/The-missing-bitfury-chip-documentation
I'm Working on a few ideas on increasing the hashing speed.
Quoting my translated docs: https://github.com/nanofury/NanoFury/wiki/The-missing-bitfury-chip-documentation#performance-testing-and-results
But I note on the IOREFF for Ver.7 that it is shown as 0V8(fine!!), but that it appears to be derived from the BUCK convertor (301F) rather than via a voltage divider & cap.
'Bitfury' seems to have stated that the IOREFF pin should be tied to 0V8, but if people start playing about with R2/R3 and the 'stupid' pencil mod, will this not impact the voltage that IOREFF sees potentially making it as high as 0v95?
'Bitfury' seems to have stated that the IOREFF pin should be tied to 0V8, but if people start playing about with R2/R3 and the 'stupid' pencil mod, will this not impact the voltage that IOREFF sees potentially making it as high as 0v95?
Well, bitfury's exact quote is: "IOREF - feed it with 0.9 V for standard signalling (better not take VDD but put resistive divider between GND and IOVDD) and some cap to remove pulsations." (I'm copy-pasting from my wiki: https://github.com/nanofury/NanoFury/wiki/The-missing-bitfury-chip-documentation#pinout-and-usage). In the first excel spreadsheet that he published he also said that "LOGIC 0 INPUT : INPUT < IOREF + 50 mV (+- 50%)" (there was actually a typo in the ">" sign) and vice versa.
As a result as long as the input voltage levels are 50mV above/below that IOREF reference voltage one you're good. Actually from what I've seen almost everyone uses the exact same trick - since VDD is about half of IOVDD anyways people just connect it straight there.
In my case - due to using resistor dividers for the SCK pin voltage on the SCK may drop to 1.25V. So - following the +50mV rule - as long as your VDD is below 1.2V you should be fine.
Practically speaking - going over 1V will probably be pointless. From the above quote - at such high speeds the chip uses quite a lot of power - approx 6W which is over twice the USB2.0 specs. Also, the voltage regulator is rated for up to 3A and that will be your second limitation for going that fast. Your main limitation however is due to the way how those LDOs work - unless you use a very expensive multi-phase regulator you will always have some minor voltage fluctuations, and for this one it is normal to have 20-50mV (and no matter how many filtering capacitors you add - you can never get <1mV fluctuations).
So from an academic point - can you do over 3GH with those chips - yes. From a practical point - it's pointless. Achieving that gain of 0.5-0.7GH will cost you as much as several other miners, so it's cheaper to just put one more chip/miner.
Also I notice that VUSB does not appear to be decoupled correctly (0uf22/0uf47)?
Can you clarify? There are 4 decoupling capacitors - C1 and C3 (100nF) and C2 and CF1 (22uF) (source: schematic)Next question…
Prior to the nano 50 miners meant 50 embedded SOC's
Since all the function of the SOC has now been offloaded to the miner software, how does that impact the % processor power required to support multiple miners?
I.E can a PI or other SOC (A10/A20)still carry the utilization 'load'?
RF
The amount of traffic per chip is very small - less than a kilobyte per second. That's certainly not a challenge for any desktop PC. I've had at some point 30+ USB miners running simultaneously on my PC and BFGMINER is using less than 1% CPU.Prior to the nano 50 miners meant 50 embedded SOC's
Since all the function of the SOC has now been offloaded to the miner software, how does that impact the % processor power required to support multiple miners?
I.E can a PI or other SOC (A10/A20)still carry the utilization 'load'?
RF
Raspberry PIs have already been show to work fine and are being used in Dave & Punin's standard mining solution and can easily handle 16 boards with 16 chips each (256 chips total).
