Let me explain protocol.
...
SPI RESET sequence - rise MOSI and toggle SCK - that is treated as reset command and by default turns on chain of chips (i.e. all inputs are put to outputs OUT - chip is chaining)
Then - instructions for chaining accepted on bit-level
0 - is NOP - no instruction and ignored
100 - is 'break' chain - it is first broadcasted through whole chain and then - on final clock cycle chain is broken.
101 - establish asynchronous chain to next chip - all of SPI fill be forwarded to next chip in chain
110 - establish synchronous chain to next chip - the same as asynchronous but with additional registers for data - bits will be delayed by 2 in output! so give nop padding to frame of long chains
111 - DATA instruction
data instruction contains 1 byte that that has length in 32-bit words
and 16-bit address
I have a few questions - 1. Did the MOSI=1, SCK=1, SCK=0, MOSI=0 sequence change? By looking at bitfury's source code it seems to be happening in a different order: (presumes GPIO_10/MOSI is 0), (presumes GPIO_11/SCK is 0), SCK=1, (repeat 16 times MOSI=1, MOSI=0), SCK=0 or instead of : "SPI RESET sequence - rise MOSI and toggle SCK" do: "SPI RESET sequence - rise SCK and toggle MOSI" // Bit-banging reset, to reset more chips in chain - toggle for longer period... Each 3 reset cycles reset first chip in chain
void spi_reset(void)
{
int i;
INP_GPIO(10); OUT_GPIO(10);
INP_GPIO(11); OUT_GPIO(11);
GPIO_SET = 1 << 11; // Set SCK
for (i = 0; i < 16; i++) { // On standard settings this unoptimized code produces 1 Mhz freq.
GPIO_SET = 1 << 10;
...
GPIO_SET = 1 << 10;
GPIO_CLR = 1 << 10;
...
GPIO_CLR = 1 << 10;
}
GPIO_CLR = 1 << 10;
GPIO_CLR = 1 << 11;
2. SPI configuration - Does the chip read the MOSI data on SCK rising or falling edge? Judging from the code above it seems that while SCK is high MOSI shouldn't change, so it is likely on the rising edge - is that correct? Also, does the chip output date on the MISO on SCK falling edge? SCK : __________/----\_____________/------\____...
^ scan MOSI ^ scan MOSI
| | | |
| | | |
MOSI: <out bit 0>=======<out bit 1>===========<out bit 2>
| |
V data out on MISO V data out on MISO
MISO: ================x<bit 0>=============x<bit 1>x=====
3. SPI speed - is there a minimum speed? Can I clock the chip (SCK) at 10-50kHz? Or even lower? Also - what is the maximum speed? (or what is the fastest observed one - that anyone has successfully tested with?) 4. Does the piece of code below work because the 0x04 value (100 command) is preceded by a bunch of zeros? (e.g. chip is reading 000 and treating it as NOP)? void spi_emit_break(void) { spi_emit_buf("\x4", 1); }
void spi_emit_fsync(void) { spi_emit_buf("\x6", 1); }
EDIT: in the timing diagram above bit_0 should actually be bit_7 - from looking at the code it seems it is MSB first LSB last. Is that correct too? |
|
|
|
bkkcoins, it looks like the ceramic cap is sold out on digi, mouse etc. Since I'm making all my purchases on mouse (to save on shipment) can I use this is a replacement?
The only difference is that the operating temperature range is "- 55 C to + 85 C" instead of "- 55 C to + 125 C"
I think that's a pretty safe bet and all should work just fine. We know those ASICs will get hot (hence the +125C) but the board will likely never reach over 75C (even though the silicon inside the chip may get to 85) - it has a lot of surface to dissipate it. Alternatively - for general filter capacitors you can most likely just look the next value higher - instead of 0.47uF you could go with 0.51uF or 0.56uF or even higher. It is likely that a smaller value like 0.33uF will work just fine too .. a 0.1uF used to be the norm  But if you go with a smaller one that may affect things, so risk goes up a bit. If you're wondering what's the next value up or down - look up the E24 or E12 series (here is a nice list: http://www.logwell.com/tech/components/resistor_values.html ) |
|
|
|
I have purchased a bunch of chips as well as all other components to manufacture the Klondike. I was getting quotes from SMT shops locally (Houston) and they want to charge anywhere between $40k and $100k for producing 630 boards. However, for around $15K I can buy my own mini-SMT line here: http://www.alibaba.com/product-gs/832249626/Small_smt_assembly_line_smt_machine.htmlAny thoughts on whether that Alibaba setup can do the same thing the local SMT shops can do? Adam - I just sent you a PM with the contact details of an assembly house that we used a few years ago. They're located in the Los Angeles area and at that time did a very decent job and were very reasonable with the price (from what I remember - $6-8 per board for a 120-board run, with about 75-80 components/board, including PIC, transformer, a bunch of connectors, etc). |
|
|
|
|
cscape - are any schematics published/available anywhere? And/or PCB drawings? (even if that's just the H-Card)
And/or the specs and list of components? (e.g. what kind of filter capacitors, how many, where, etc)
I'm guessing you guys have already gone trough the pain of testing various components ... so any future designs won't have to discover again the hot water.
|
|
|
|
Hey! Everyone the Klondike Store is open for orders!
... But hey, I can autograph them.  YES YES YES YES YES YES!!! Can I have mine autographed? :-) First things first - I just managed to place an order! :-) (and somehow 144 people already ordered before me!?!) Aside from that - when I tried paying via paypal I got: Error Detected
Error Message
The seller accepts encrypted website payments only. You cannot pay the seller through un-encrypted buttons. Please contact your seller for more details.
so the PayPal stuff didn't work. I ended up paying via BTC. I tried making the url HTTPS but then some other web site showed up at your address. Not to mention that I had to add a security exception since the certificate didn't match. In case you are not interested in wasting a lot of money on HTTPS certificates - check this site for a free one: http://www.startssl.com/?app=40 |
|
|
|
New scope pr0n... with extra inverters, showing a 1 bit and two 0 bits. I think this was at 390 MHz. Shows fixed 50nS delay on clock trailing edge on input to PIC. Note this inverts data and clock so now the code is set for falling edge capture and no longer inverts RCREG upon read. https://i.imgur.com/NmZ6qQN.jpgBKK - That spike in the red line at -50nS (when the yellow goes down 1->0) - is that introduced by possibly too long probes? If not - that's 0.8V from peak to peak and I'm wondering if it introduces any other issues at higher frequencies ... My guess is that it could be either due to the red and yellow wires being too close, or most likely sneaking in via the power lines ... maybe some more decoupling capacitors? That's just an observation. If it doesn't cause any issues please disregard my note and let's stick with the K.I.S.S. principle edit: there is also that huge spike when it goes from 0 to 3V3 (4.4V peak when just the red switches, or 5V when both switch). Again - if it's not an issue - don't bother fixing it. |
|
|
|
Using google translate: the first quote: Recent TSMC's production capacity seems a bit tight.
The miners in stock on hand happy
the second: TSMC's production capacity is the butterfly wings I suspect "the butterfly wings" is an idiom - guessing by the previous quote it is probably to say that their free capacity has gone with the wind.. just a guess though. |
|
|
|
btceic, did you turn off javascript? The login page should not look like that. Make sure you have javascript turned on and if you get error messages where you see a URL shown double ( http://abchttp/://abc) then turn off broken plugins. Alternatively you can try a different browser if you have one installed and you don't want to deactivate plugins. There's a few plugins for Firefox and Chrome (maybe other browsers too) that are supposed to "enhance" webpages in various ways and break them instead. I just tested Yahoo login and it worked. If you still have issues, try the above and if it doesn't help use the contact page on the website to send a support request. yup - all working fine now. I guess I had messed up some of the yahoo/AOL logins - it was the AOL that was giving me a headache. I removed the AOL, logged in on AOL (they insisted that I update my profile), logged out, added the AOL profile on my bitminter, tested and all is good now. Thanks Doc! |
|
|
|
Nope, logging in with my google account works just fine!
btw I'm unable to login with a Yahoo account - it doesn't forward properly I think. Google is fine. |
|
|
|
Good point... Interest how did they do it...
Well ... it's not x-link The MR that had 8 SC Singles in it (that I got to play with for a night) were all single devices, not x-linked anywhere. Anyway went and got the AVR Dragon earlier today ... then put AVR Studio in a windows VM I'll sort out Linux some other time - since it's a 3 year old version of it - they stopped updating it in 2010  Compiled fine ... with 769 warnings  Took hell to do the Dragon Firmware update (VM problems) but did manage it finally. SC firmware update was simple (less than 2 minutes) Now runs at 8.0GH/s using default Freq 7 as with 1.2.5 firmware as a Single (used to be 5.4GH/s) I'll post again later ... details. <...> Unplug the AVR Dragon USB. Power off the Jalapeno. Remove the Jtag cable ... then plug the Jala back in as usual to go back to mining. Of course if you were running cgminer on a linux box, it will just hotplug back in when you plug it in Done. The default is frequency setting 7 - which is about 8.0GH/s on my Jalapeno. I get about 16 HW errors an hour - which suggests to me to not increase the frequency. P.S. If you screw up your Jalapeno doing this - sorry - not my fault Kano - THAT WAS ONE HELL OF A GREAT POST!!! WELL DONE! AND THANKS! Keep up the good news coming! |
|
|
|
I have a problem with my name coins . they were cashed out to vircurex a few hours ago and they seem to be missing it was about 1.8 nmc how do i trace it.
I think they're having some NMC wallet issues (or at least that part seems to be offline). When I tried creating a NMC wallet address I got: Error
The wallet is currently offline due to maintenance activities. Please try again later.
|
|
|
|
I think now is not the time for mission creep.
Get the board working as intended. Then revise for additional capabilities. There is nothing wrong with having different versions of the board IMO.
big +1 here +1 Let's get it up and working fine first. There will always be version 2, 3, etc. |
|
|
|
Pool down again. Nothing mining at least from what the front page says.
Never mind, you were right. There was a reason the stats fell out. Seems to have cleared up almost right away, though. Just saw that in one of my miners: [25/06/2013 14:22:52] Result: 624d24ec accepted
[25/06/2013 14:22:58] Result: e926a3c4 accepted
[25/06/2013 14:23:07] Result: 4cb98462 accepted
[25/06/2013 14:23:12] Result: ff28fb63 rejected
[25/06/2013 14:23:17] Disconnected from server
[25/06/2013 14:23:19] Result: 1a16deb8 rejected
[25/06/2013 14:23:20] Result: c3a1d293 rejected
[25/06/2013 14:23:21] Result: 0b67ae59 rejected
[25/06/2013 14:23:24] Result: d8b58b69 rejected
[25/06/2013 14:23:27] Result: 40974a9d rejected
[25/06/2013 14:23:31] Warning: work queue empty, miner is idle
[25/06/2013 14:23:31] Failed to connect, retrying...
[25/06/2013 14:23:46] Failed to connect, retrying...
[25/06/2013 14:24:01] Failed to connect, retrying...
[25/06/2013 14:24:16] Failed to connect, retrying...
[25/06/2013 14:24:31] Failed to connect, retrying...
[25/06/2013 14:24:46] Failed to connect, retrying...
[25/06/2013 14:25:01] Failed to connect, retrying...
[25/06/2013 14:25:17] Failed to connect, retrying...
[25/06/2013 14:25:32] Failed to connect, retrying...
[25/06/2013 14:25:47] Failed to connect, retrying...
[25/06/2013 14:26:02] Failed to connect, retrying...
[25/06/2013 14:26:21] Failed to connect, retrying...
[25/06/2013 14:26:31] Connected to server
[25/06/2013 14:26:32] LP: New work pushed
[25/06/2013 14:26:48] Result: f6806cbb accepted
[25/06/2013 14:27:37] Result: 259aef1f accepted
[25/06/2013 14:27:43] Result: 752cd5c6 accepted
[25/06/2013 14:28:36] LP: New work pushed
[25/06/2013 14:28:52] Result: 39f6acf8 accepted
[25/06/2013 14:29:02] Result: 9ff359ee accepted
[25/06/2013 14:29:11] Result: 89a76aea accepted
[25/06/2013 14:29:24] Result: e1c6af40 accepted
[25/06/2013 14:29:31] Result: d9085f6c accepted
[25/06/2013 14:29:34] Result: 15faf603 accepted
[25/06/2013 14:29:38] Result: f291dd54 accepted
edit: Times are Pacific (GMT-7) |
|
|
|
I don't want there to be only 1 and a monopoly but if there is only 1 and a monopoly, I want to be that 1 Not such a bad thing to have a seemingly ethical person as the monopoly if there must be a monopoly d: that's damn right I'd rather prefer no monopolies at all. |
|
|
|
Pool is down!
Just restarting the mining service.. it's a bit slow on the restart though - I will work to improve that. Doc - on the good side thanks for the prompt update. On the down side - this should've been announced BEFORE the fact and not AFTER the fact. Mi miners wasted over half an hour just idling ... (and now I'll be seriously considering a better backup pool scheme) And honestly - all of those restarts are just way too annoying and just make the whole pool look very unreliable. I'm trying to remember a case when the pool has worked fine and non-stop for consecutive 7 days... Oh and by the way - any ETA when the pool will be back up and operational? |
|
|
|
Damn slow $->btc conversion Is there any way to send you a check or US$ or (u.s.) bank transfer/deposit? And you convert it to whatever BTC rate happened to be when you get them, and I can pay the difference in BTC (+/- 1-2) when you're ready to ship? |
|
|
|
I don't like 18702 either  I guess I'm not the only one with this payout: 18702 2013-06-22 15:21:37 1:59:11 30464457 2472 0.00000033 242788 25.44442180 92 confirmations left |
|
|
|
.0027 to .00046.
Something very strange happening at this moment. All of a sudden the numbers in the user statistics pages look very odd. I think slush secretly moved to the DGM payout system. Sluuuuuuuuush, can you hear us?  This is something entirely different and I believe this is not so much an issue with the site but with the scoring algorithm See the full explanation here: https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002The below graph shows that this algorithm will occasionally have DRASTICALLY low payouts if you fall into the group that exists in those severe drop offs in the graph. You should also notice, if you look closely, there is a noticeable increase on payout for those that fall into the group right to the right of the drop-off. Basically, some people are getting overpaid and some underpaid for blocks. Slush fixes them a lot of the time, but not always. When your estimated payout drops to almost nothing, you are in that nasty trough in the graph. http://i53.tinypic.com/j91onp.jpgWhat I've seen Slush fix is when the scoring gets way off. (and as you mentioned - not always) From observations it appears that individual miner's shares are tracked by different servers (and thus separate databases). So when the round ends each of those separate databases would have to be combined. What I've noticed is that I caught on a few occasions the web site reporting partial results - as if some of the separate servers had not reported their data yet. So if I look at my number of shares I'd see just a fraction of the total number. And I suspect that was the issue that we had in the past - if during the round you disconnected/reconnected (even very briefly for 0.1sec) part of your shares would be on one server and another part on a different one. If at the end they don't get combined you'd get the missing shares issue. And that's what Slush had to manually fix (but that's my guess). So back to the question - it seems to be the reverse case - when you get extra points because just the database containing your shares made it to the server that combines everything, so as a result it distributed the BTC among fewer people (and every one of them got more than expected). The change that I've noticed recently is that everything is much more reliable and the various databases are much more consistent and (almost) always manage to combine the data. I think it's been more than a few weeks since we've had those severely underpaid (and for some overpaid) blocks. |
|
|
|
Something I noticed on another thread - Just got this emailed to me from Avalon. http://imgur.com/a/fqpMEFrom those pictures, any drop in network hash rate is only temporary. Notice the last image - has a decent picture of avalon's 10-chip board ... (that's in case if there is anything to be learned from it) |
|
|
|
|
Show Posts
