I was pretty sure the devs didn't use any armv7 specific instructions so it should work - just tested the binary on a pi model b and it works fine.

Regarding the static build it would be the easiest way to run dmd on most arm boxes - even kodi can run a node despite it doesn't let you install libraries.

I can guarantee it will work fine. However a static build would have been better

Yep, I run an old raspberry pi model b for my staking wallet and its fine

The diamond kernel is exactly the same as the normal groestl kernel, the only difference is how to generate the merkle root when submitting work to stratum. Try if it works on the getwork port on danbis pool, they probably forgot to handle this when using the diamond kernel.

The initial reward is diff * 8 and decreasing with every block found. Actually it isn't linear so the reward won't halve every year but be 8 * diff / number_of_years_passed.

I want to link my Bitcointalk name with BTCJam's. Verification code: 6bf4dd7c-c8e9-4e62-86d6-e6e05f725007

Actually the gridseed version of cgminer sets bit30 low for 250/400/450mhz, and high for 500mhz and above just as they specified it in the docs.

You just add it to the gridseed options: --gridseed-options baud=115200,freq=850,per_chip_stats=1

My version also has it as I forked from the original repo, so you can use either one to check it out.

We have a few units where only a single chip holds the other 4 back, so I'll brobably also include per-chip settings in the near future. You can verify this by adding Andareed's per_chip_stats feature to the options, running cgminer from ssh and maximize the window so you'll see the stats at the end of the line for each device. HW errors are displayed between brackets for each chip:

GSD 0: 8D74488A4949  900 MHz | 382.0K/381.9Kh/s | A:344128 R: 256 HW:64 WU: 1.3/m N: 303[62] 264[1] 310 238 284[1]

All right, the new frequency table is:

700, 706, 713, 719, 725, 731, 738, 744, 750, 756, 763, 769, 775, 781, 788, 794, 800, 813, 825, 838, 850, 863, 875, 888, 900, 913, 925, 938, 950, 963, 975, 988, 1000, 1013, 1025, 1038, 1050, 1063, 1075, 1088, 1100, 1113, 1125, 1138, 1150, 1163, 1175, 1188, 1200

Ah I know what the problem is.. I removed everything under 800Mhz since our units were fine over that. I'll put the 700..800Mhz range back an send you a PM when it's done.

You'll need a tiny bit of airflow, most people report the devices are unstable when they get hand warm. Replace the factory heat pads with quality ones or solder the fan to 5V from USB.

If anyone interested I've modified Andareed's version of cgminer a bit to let you better finetune the gridseed units. There's a big variance in the resistors they used as voltage references so every unit has a different maximum frequency they can run at.

https://github.com/girnyau/cgminer-gc3355

New frequency table: 800, 813, 825, 838, 850, 863, 875, 888, 900, 913, 925, 938, 950, 963, 975, 988, 1000, 1013, 1025, 1038, 1050, 1063, 1075, 1088, 1100, 1113, 1125, 1138, 1150, 1163, 1175, 1188, 1200

You won't need the ghz ones however unless highly overvolted

You can also define a base frequency as usual, then set per device frequencies by the units' serial number if you want:

--gridseed-options freq=888 --gridseed-freq 8D74488A4949=900,8D96227B5449=900,8D7357785355=875

Factory units running since ~48 hours without any hw mods but the fans desoldered:

 cgminer version 3.7.2 - Started: [2014-03-16 13:23:19]
--------------------------------------------------------------------------------
 (5s):1.891M (avg):1.888Mh/s | A:3357360  R:4832  HW:228  WU:10.5/m
 ST: 2  SS: 0  NB: 950  LW: 34253  GF: 2  RF: 0
 Connected to litecoinpool.org diff 256 with stratum as user composeit.gridseed
 Block: 3a0bf6f9...  Diff:5.16K  Started: [22:08:37]  Best share: 18.8M
--------------------------------------------------------------------------------
 *P*ool management *S*ettings *D*isplay options *Q*uit
 GSD 0: 8D74488A4949  900 MHz | 382.0K/381.9Kh/s | A:653120 R:2176 HW:204
 GSD 1: 8D7135A35355  888 MHz | 376.9K/376.8Kh/s | A:670592 R:1152 HW:  6
 GSD 2: 8D96227B5449  900 MHz | 382.0K/381.9Kh/s | A:675936 R: 800 HW:  5
 GSD 3: 6D9323805251  888 MHz | 376.9K/376.8Kh/s | A:677392 R: 352 HW:  3
 GSD 4: 8D7357785355  875 MHz | 371.4K/371.3Kh/s | A:680320 R: 352 HW: 10
--------------------------------------------------------------------------------

Cheers

Hi all,

I've got the set I ordered last sunday delivered in less than 72 hours - of course free of any additional taxes since I'm in the EU.

Thanks again Alex

DHL picked mine up last friday, and it got delivered yesterday. I'm in the EU and the package passed customs in about an hour, the miner is working fine.

Thanks Michael

It's because both cgminer and cpuminer set frequencies based on predefined init messages, and they've only made a few of those. These are the frequencies supported by cpuminer:

static const char *str_frequency[] = {
"250", "400", "450", "500", "550", "600",
"650", "675", "700", "750", "800", "850", "900",
NULL
};

FYI the TL-WR703N is a wireless router, so if you can get root access you can connect it directly to an AP

I'll try to remake the lightningasic firmware, unfortunately I don't have too much time to deal with it right now. If anybody wants the original and the lightningasic versions of rootfs to play with let me know. A few things probably have to be removed from the default install to get some extra space. LA also removed all of the wireless drivers.

worldlybedouin add --dual to the commandline of minerd and skip freq

No, it's not. Download the miners gridseed published a few days ago, and compile them (github.com/gridseed/usb-miner/software). To get dual mode you have to use the same parameters the controller does. When you start them like that cgminer submits both btc and ltc work to the cores, but it uses cpuminer to get ltc work from the pool. cgminer and cpuminer communicate with each other in udp packets to handle dual mode.

Guys keep in mind the controller doesn't actually show the hashrate of the devices. It uses a similar algorythm pools use to compute your hashrate based on the number and difficulty of shares the device submitted. The more lucky a device has been in the actual interval the more hashrate it will show.

To know their actual performance compared to GPUs we should run one of each on the same network, on the same pool, and draw a graph of how many diffiulty 1 shares they submitted a minute. When I finally get my units I'll do that, and also make a few other graphs like their temperature in ltc mode without a fan, performance at different clockrates etc.