Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 66. (Read 435369 times)

that is the ugliest switch i have ever seen!~...

Search Cablez he makes switches that look clean

Danny

I picked-up one of these.  It is a bit easier on your Power Supply by  placing a small load on the 3.3 volt rail to stabilize it.

http://www.ebay.com/itm/251029201991?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

you can simply short the green and any black wire on a PSU to turn it on
a steel paperclip or bare piece of wire will do the trick
like this:

ok cool, so what is the recommended way to power on the psu?  Are people mainly going to have these plugged into pc's?

edit:
ok I got a few psu's laying around but I am unsure how to power on the power supplies without a host pc, what I'd like to do is have a nexus 7 or netbook run cgminer, how do I switch the power supply on? is there a switch I can buy for this?

I don't think the errors are in USB data but I could be wrong on that. The low level serial engine is supposed to be taking care of error checking. From what I know it sends a NAK to say it detected an error and the host re-sends.

I think the issue is noise on the USB GND polluting the K16 GND. I say this because I scoped some pretty bad noise on the ALL the power rails including GND, and that goes away when it's connected to the RasPi along with the errors. So my thoughts right now are that a ferrite bead on each USB signal and GND will filter that noise. Also, according to the Full Speed spec the cable shield is supposed to be connected directly to the GND plane, but it's unclear if that's part of the problem or the bead from signal GND will clear that up or if the shield needs a bead or should just be disconnected.

No. If the power is on at the connector then it's on for the board. IF you wanted to switch power for each board individually you would need to put switches in the power line to the board. Which is not much different than if I had pins to short as you'd need a switch for that, except it could be momentary rather than on/off.

The firmware allows for disabling the clock, thus disabling hashing, which cuts power use to very low, which would be like an idle mode.

is there pins to short to turn the klondike K16 on?  How will these be switched on after plugging into a psu?

You could always add some error checking to ProcessIo if all your errors are coming from communicating with cgminer.

The Klondike doesn't draw power from the USB port at all. And definitely USB 2.0 on my notebook. It's old but not that old USB hubs have ferrite beads or EMI/ESD chips. I noticed with the hub on my notebook it is less error rate but not as low as the RasPi. Using the RasPi is also very low when direct connected without hub, but there are no beads or chip there so I assume the SoC controller there has decent filtering, plus it probably just has a lot less noise on it.

---
The EMI/ESD chips are a bit hard to decipher. They're either USB 1.1 and have termination included, or they're 2.0 and not clear on whether they're suitable for Full Speed (1.1) mode. I don't want termination in the chip as the PIC already does that, and it could get conflicted. I'd go with the EMI2121 chip as it has filtering and ESD protection and is tiny, 2.2mm, but I want to be sure it's suitable for Full Speed signalling. They only indicate High Speed in the data sheet. The alternative is to just put 3 ferrite beads D+,D-,GND.

Are those usb ports on the notebook black or blue  usb 1 or 2 ?  notebook and usb and pc hubs all power the 5 volt usb differently, then there are the powered hubs ,    I really think that's a power regulation  issue vs  EMI issue .    Try a powered hub  instead and see if your result changes.

Thanks for the offer. It's mostly the time that is an issue.

**** NEW FLASH ****
I was busy with other commitments most of today, but I'm just getting back to it.
Here's an interesting data point:

If I hook up my USB via a cheap pocket hub to my notebook the error rate drops right off to < 1% (short test so far). So there's a quick fix for those wanting to see if the USB noise is causing the error issues.

My guess is that the hub has correct EMI filtering beads on it's connections and acts as the filter we need.

Looking at this now - EMI2121
http://www.onsemi.com/pub_link/Collateral/EMI2121MT-D.PDF

If you don't find anything suitable on that mainboard and think I can be of assistance again, let me know: http://www.maritex.com.pl/pl/shop/products/ggid/15955

Some people have been struggling with getting cgminer and klondike working on RasPi. Here are the steps I used that worked. This assumes you create a Rasbian server boot SD card, and that you can get it to boot, start networking either with LAN or Wifi, and login with ssh.

sudo apt-get update
sudo apt-get install autoconf  libtool libncurses-dev yasm curl libcurl4-openssl-dev pkg-config libusb-1.0

git clone https://github.com/bkkcoins/cgminer-klondike

cd cgminer-klondike
./autogen.sh --enable-klondike

make

./cgminer 2>>cgminer.log

(add -D if you want lots of debugging info during testing)

You can edit ~/.cgminer/cgminer.conf and add a klondike-options item or use the cmd line.

yes (hopefully) the idle buck regulator do the noise.
You can try to hookup a small load (resistor, 50-100mA) to the regulator.

The 5V is n/c anyway.

Good idea on mainboard - I do have an old ASUS P4 board here I can hack up. I'll check that out today. Right now I have to go into town for something, so it'll be a few hours.

Both buck regs are mounted but only one side is used. You're thinking the unused one, not under load is putting out RFI to the other. I'll be adding more chips to the 2nd bank soon. The 600kHz noise isn't much anyway - just small blips compared to the noise I was getting from USB.

remove the shield of the usb cable.
only let red (5V), black( GND), white and green (data) go to the board.
the at least the ground-loop is cut off.

ferrite bead: perhaps you have a old mainboard lay around?

600khz buk reg: do you have mounted both asic bukregs? but only use 1 for the asics and the other one is "idle"

Yes, I noticed that this type of core on the cable helped with big RF surges like when the fridge or FL light nearby turned on, which caused resets, and when scoped shows up as huge flashes on power line, but did not help with error rates and repetitive smaller noise.

The beads above go in the circuit, in series between connector pin and current traces. It may be easier to use a cuttoff USB cable and wire them on the end and then solder to tiny conn. traces. I did that on my first prototype board (but without beads).

FYI, I use a USB line with a ferrite bead on it like this


I guess this is a different ferrite bead which isn't connected to any line as shown in this picutre

This ferrite bead has no help. I will test yours when I have them in hand.

Once the klondike driver is pulled back into the cgminer repo, it will be available by just compiling with klondike enabled. After that it is auto detect and plug and play. You can add cmd line or conf file options to specify clock rate and temperture / fan details.

For now you would build using my fork http://github.com/bkkcoins/cgminer-klondike

Thank you for sharing. I have some ideas for others to test to improve the error rate. I am quite certain now that it is related to USB induced noise. The PIC docs indicate that no external parts are needed but it seems that not enough or incorrect conditioning is done internally in the chip. Chaoztc also suggested checking the USB GND, and I think he may be spot on with that.

I scoped my board connected to the RasPi instead of my notebook and the 1.2V core is much cleaner now. It does not have the 100Hz/100kHz/100MHz noise I posted about earlie, and only shows 600hKz buck reg pulses. I'm thinking that noise came in from the notebook via USB and by adding some ferrite beads there we may be able to improve noise enough to improve substantially. In my case with the RasPi it has run overnight in exactly the same location, same PSU but has 109 errors for 16243 hash, or 0.6%.

I don't have access to ferrite beads here. Not in a timely fashion. I'd suggest 3 things to test.

1. add a 0.1uF cap next to PIC on VCC-GND to improve decoupling because I think the one that is there is not enough. This I will test myself this morning to see if inadequate decoupling is causing data glitches in the PIC.

2. pull the USB conn off board and test with 3 ferrite beads. Use a 120 ohm on the D+ D- lines, and a 220 ohm on the GND connection USB GND to board GND. The specific parts are:

BLM18BB121SN1D  120 ohm, 200mA
BLM21PG221SN1D  220 ohm,  2A

It may be enough to add just the GND one if the PIC has internal conditioning. So try that first. I noticed that my noise problem was on the GND plane as well.

3. scope the power before and after. Obviously if this makes a big difference then I'll need to get it into the revised board, which means moving the PIC slightly - though I think the pending revision for QFN pkg is small enough to fit with beads.

@bkkoins:
regarding the signal trace with inverters:
better place a capacitor near at each gate

the "new" signal looks good, pic spec states:
rx input pin have to be stable 10ns before falling clock and 15ns after falling clock.