If it is more easy then do it :-)
Maybe anyone could wrote personal efficiency algorithm in external include file.
Say me how send you this information
Thanks
Well, if we're using SPI, maybe just repeatedly shift 5555<16-bit length><data> and define data some way? |
|
|
|
Hi Luke
The goal is set the device for have the best value mW@GHash (in other words best performance)
For do this I need to measure power and I already do it, but I need also to know hash rate and change number of bit.
In summary I need two function:
1 - receive hash rate
2- set bit number
I have free pin on MCP2210 and of course free pin on micro 1 pin with inaccurate timing is not sufficient for communications AFAIK. Also, you need to define "hash rate" - there is no good way to measure instantaneous valid-result hashrate, so we'd probably need to coordinate when the averaging is reset etc. It seems to me it would make more sense to feedback the voltage/current information into BFGMiner and do the logic there? |
|
|
|
Hi Luke
I use MCP2210 because it have great stability.
I use micro only for extra caratteristic like current, voltage and temperature measurement.
Have you possibility to send information and get information to-from micro?
This could be a new cool feature for your already good bfgminer.
With GHash value and current measurement by hall sensor I could calculare performance GHash/Watt and show information by led meter.
Since I'm almost ready to send PCB please reply me soon for decide if connect and where connect this new communication channel.
After have decided the communication pin, you could develop this caratteristic in all calm and in a while I could produce pcb.
Thanks "lightworker" Luke.
Giuseppe
What does the micro do with the information? If the mining chip is itself controlled by BFGMiner, it can also control the clocking? Afraid I'm missing part of the big picture here, and I can't really give good advice without understanding what the actual goals/design are. SPI might be bitbangable for micro comms, but maybe using a chipselect would work better for that? |
|
|
|
DITTO!! So what driver do I load for the R-Boxes then? I'm sure I have to switch it back to the standard windows driver instead of the Zadig driver I have had to run them under with CGminer. Or is there a specific one I need to download and install for the R-Boxes? The R-BOX uses the same cp2102 driver needed for Block Erupters. I would develop a firmware that measure performance.
For do it I need to know GHash value, hardware errors ecc.
Since on mpc2210 there are free GPIO ports, I would ask you if is possible send the above information by this way. Think it like a read information / set command ( for example set bit number) directly from device.
For example GPIOa = rx GPIOb = tx (uart). I think you would have a hard time getting accurate timing over GPIO, even moreso via mpc2210. But if you're putting logic in a microcontroller, why use a mcp2210 at all? |
|
|
|
Hi Luke
Is possible for a micro connected on free pin of mcp2210 read bfgminer information that appeare on screen?
Thanks
What? |
|
|
|
If you ran cgminer, ensure /dev/ttyUSB0 actually exists - rebooting usually works. Otherwise, please pastebin the output from: bfgminer -S rockminer:all -d? -D Curiouser and curiouser. It seems like it knows rockminer devices are there but doesn't detect them as as devices? http://pastebin.com/E50PvhGwLooks more like a power issue to me. I might have other issues going on though because bfgminer also crashed thusly when I tried to launch it again. /opt/minepeon/bin/bfgminer: symbol lookup error: /opt/minepeon/bin/bfgminer: undefined symbol: blkmk_append_coinbase_safe2 Maybe I screwed something up when compiling it. I'll try again when I get home troubleshooting through SSH makes me antsy. I'm not sure how MinePeon sets up libblkmaker, but you can probably compile using --with-system-libblkmaker to use its version. |
|
|
|
+1 same commands as cgminer? No, BFGMiner has a standard interface for all drivers. So something like: bfgminer -S rockminer:all --set rockminer:clock=290 Edit: Also note that if you were using cgminer, you had to use Zadig, which breaks the official drivers. You will need to undo this (and restore the original driver) before BFGMiner will work. Has anyone gotten this working properly on Raspberry pi? -S rockminer:all doesn't work, going into device manager and saying "rockminer:/dev/ttyUSB0" doesn't work either. If you ran cgminer, ensure /dev/ttyUSB0 actually exists - rebooting usually works. Otherwise, please pastebin the output from: bfgminer -S rockminer:all -d? -D |
|
|
|
+1 same commands as cgminer? No, BFGMiner has a standard interface for all drivers. So something like: bfgminer -S rockminer:all --set rockminer:clock=290 Edit: Also note that if you were using cgminer, you had to use Zadig, which breaks the official drivers. You will need to undo this (and restore the original driver) before BFGMiner will work. |
|
|
|
Got 4.2.0 compiled and working on Rasberry Pi (Arch/Minepeon)
it wasn't able to detect the R-BOX's though. Is this a thing where I have to program the chips on the miners to identify themselves properly?
R-BOXs so far have shipped with the CP2102 EEPROM unprogrammed, same problem as the Block Erupters had. You can manually probe them with -S of course, or use cp210x-program to configure them. I made a template EEPROM firmware for them: http://luke.dashjr.org/tmp/code/eeprom-content.RBOX.hexUse it like: ./cp210x-program -w -F eeprom-content.RBOX.hex --set-product-string='R-BOX miner' --set-serial-number=somethingunique |
|
|
|
I'm glad to see people are actually verifying the PGP signatures, but before you report that my key expired, please update your copy from the keyserver, as I updated the expiration date already  |
|
|
|
NEW VERSION 4.2.0, JUNE 11 2014Human readable changelog:- rockminer: New driver for ROCKMINER R-BOX.
Full changelog:- Upgraded Windows libmicrohttpd from 0.9.35 to 0.9.38_pre33603
- SGW: Workaround BE Cube bugs with new libmicrohttpd by forcing HTTP 1.0 response
- rockminer: Increase hw error count for problems
- rockminer: Autodetect with "R-BOX miner" or "RX-BOX miner" product strings
- rockminer: Support for seeing and setting clock frequency in Manage TUI
- rockminer: Include clock frequency in RPC processor status
- rockminer: Support for setting clock frequency
- rockminer: Workaround lost tasks by resending them
- rockminer: Support for temperature sensors
- rockminer: Debug messages
- Bugfix: rockminer: Initialise rockminer_chip_data
- Bugfix: rockminer: Ensure work actually exists before testing against it
- rockminer: Mine at 270 MHz
- rockminer: Implement mining (at 200 MHz)
- DevAPI: Move device_proc_by_id out of bifury driver, since it is generically useful
- rockminer: Detection code for new driver
- bfg_socket wrapper to ensure sockets are close-on-exec
- set_cloexec_socket: Explicitly cast SOCKET to HANDLE
|
|
|
|
whats the maximum hashrate a Raspberry Pi can handle? I'm running 8 Chilis (30GHash each) and the whole things feels quite sluggish - i am using a Raspberry Pi 256 Model B version. is it worth overclocking or adding additional cooling?
Depends on the devices. Low-overhead drivers: antminer, bifury, bigpic, bitforce, cairnsmore, dualminer, erupter, getwork, hashfast, icarus, rockminer, twinfury, stratum High-overhead drivers: bfsb, bfx, littlefury, metabank, nanofury, x6500 Note that some devices, even if low-overhead, may have hardware issues with RPi's broken USB bus, though... |
|
|
|
rockxie, can you take a look at this thread: https://bitcointalk.org/index.php?topic=250326.0could you overwrite the generic values with RockMiner and RBOX/RXBOX, so that driver handling can be more precise? Some people are having issues with the whole driver replacement step. Also, there would be no way to distinguish rbox vs rxbox on a system in device manager etc... Luke-Jr can probably help with answering a question you might have regarding this. FWIW, this is basically the finishing touch needed to release BFGMiner 4.2 with RockMiner support: What should/will the USB Product string descriptor read? Maybe "R-BOX miner 32G", "RX-BOX miner 1.2T", etc? |
|
|
|
Is there any plans in the future to open up the ability to manually choose a minimum difficulty/worksize settings?
I don't think so, there's not really a valid use case for this. Mainline Eloipool already does support miners specifying a requested difficulty, and that might make it onto Eligius eventually. |
|
|
|
Luke-Jr, there are many current altcoins deserving of the same fate.
Great, have fun. I don't have time for scammers and their nonsense. |
|
|
|
Anyone interested in designing a Cube Block Erupter retro-fit?
now we're talking!!! there's a large market for this and the earlier blades too, since the power boards are out there. if people could buy replacement blades for either platform, they would. and if they could replace one at a time that would be phenomenal as well. Slightly related to this, is there perhaps the possibility of open sourcing some or all of the Cube's information? It would be nice for someone to try to debug the TCP stack and figure out how to make it work correctly |
|
|
|
Hi,Luke. are there any api docs about Eloipool?  There's no API, so no. |
|
|
|
Hopefully there are enough non-idiots mining still who know to ignore garbage like this. |
|
|
|
Any chance the chips might be open source too? Yes. But there are no written plans in the near term yet. Also it's much harder than making a piece of software open source, because the whole flow to generate GDS has tons of manual operations and very fab and technology node specific. Please don't do this in the near future  Why not? Open source mining chips benefit the community the best, I think? Or am I missing something? |
|
|
|
|
Show Posts
