Something of production update in that we expect to fullfill most September delivery promises that were reconfirmed within the next 2 weeks. Do keep a lookout for emails from Enterpoint saying that your board/s are available as numbers reconfirmed are very close to what we are planning to make this month.

Anything left over once all these pre-orders are shipping will appear as general stock in our webshop and once these have all gone there will be possible lead time on new boards. I will update the thread once more information is available on boards left after the pre-order completes and how we stand on delivery on Spartan-6 silicon to make more. Generally Spartan-6 silicon is going on longer lead time that it was previously and this will limit how fast we can react to any new orders.

We are aiming for October as a general availability again but I can't be precise at the moment of what date in October. A lot depends on how fast we satisfy our existing pre-order list and we are working our way though those orders now. It also depends on supplies of FPGA and other components. What we are aiming to do from October is to have some level of stock boards but if we get large purchases we will have short periods where boards are on some sort of lead time as we manufacture another batch.

We are still basically processing in order but we are ahead currently. What we are doing now is really to check that we have the right amount of Spartan-6 silicon. As we are getting towards the end of the pre-orders it is a bit like how airlines fill seats. They overbook seats on the basis some peipole won't show for the flight. We underbuy silicon on the basis some orders will drop out. So to avoid customer dissappointment we need to check now if we have enough silicon. The lead times to get extra Spartan-6 silicon are about 6 weeks ands we are already marginal on timing to get that in and build boards in September. This does mean we could be late on the last 100 boards or so if people tell us last minute they do want their order and everyone wants their entire order. Whilst we can carry a small risk of potentially overbuying a small amount of Spartan-6 100 boards worth would be a serious cashflow issue at best and it could be a lot worse for our business.

So before the end of the week we will decide on how much Spartan-6 silicon we need to buy and place orders accordingly. If we don't get responses from customers on the email that went out then we will assume they are not going ahead. We won't wipe their order but if they come back late then their order might be late as we will give priority to the people who actually responded.

We will be asking more people this week for payment. Our production numbers are only about 20-50% of a normal month currently so bigger orders like ebereon's can take most of a weeks production in one hit. The next 2 weeks are likely to be worse as there is a big public holiday here on Monday and many people take holidays that week or even the next one. We are very down on staff numbers over those 2 weeks.

You first problem is the connector size is all wrong. The length may also affect results as well. Also IDE ribbons use a strange double wire setup which tends not work in anything else.

It's possible to make these things and that is probably better but unless you have the right kit results can be patchy. There many hairless engineers around as the result of trying to make up ribbon cables.

Controller Rev 1.5 is now available on the support page. Programmer is fixed and it offers the dualling up of 2 boards onto 1 USB cable.

The biggest problem we have with choosing an exchange is that there is virtually no exchange of any size that hasn't had some sort of problem either with security or time to pay out going by forum postings. This partly of why we won't take large payments directly in Bitcoins as yet and our aim initially will be to convert to GBP/USD as fast as we can on receiving Bitcoins as a risk reduction strategy. In time that might be able to change because we are not operating on a wafer thin margin, as we are currently, or maybe even some of our suppliers take Bitcoins that mitigates the conversion risk a little. The latter I think is probably a few years away so basically we are left with the currency conversion risk that we have to manage.

The other side of taking this mitigation is that by say converting funds every day we could have very high bank transfer fees on a foreign based exchange e.g. MTgox. MTgox would be the logical place for exchange based on volume but when we looked for the sort of information we look for as general business due diligence it's either not available or simple somewhere we don't know where to look for MTgox. I can say the same about a lot of exchanges. Ther are a lot nice looking websites with very little information about the owners of them.

Overall we can see that Bitcoin is a good thing and there is a lot of nice things in it. From a business perspective the biggest issue is the lack of traceability. Again on the forum there are enough arguements about people having sent Bitcoins and the other side saying they didn't get them for us to be cautious. If we have missed something there do tell us. We are still learning about Bitcoins and things surrounding Bitcoins so there may be something here we don't know.

Many of these sorts of problems with dissappear as Bitcoin gets bigger. At the moment it's a chicken and egg situation in that Bitcoin needs more conventional businesses to take Bitcoins but conversely they either won't, or will only in limited way as we do, because other companies that trade with them don't and they have the same exchange rate risk we have.

On the second option we are open to people using other exchanges and sending us the money that way but the transfer fees are always going to have to be paid. If the exchange is UK and possibly EU based (using SEPA) it will probably be viable for smaller amounts. What we don't want to do is running a lot of accounts wih different exchanges ourselves as that is a huge admin issue.

Using merchant services like BitPay is a possibility but we simply are not ready to do that yet. We can run live currency conversion on our USD and Euro pricing that runs on our existing webshop but we don't because it is an administration nightmare because we have to account for everything in GBP to our taxation authorities. We simplify that by usually only changing USD/Euro exchange pricing conversion rates every 1-3 months and sometiimes longer. Doing the same in Bitcoins simply won't work unless we put a huge risk margin on Bitcoins which I am sure none of you want.

That's a fairly much seems to be on the worst end of most peoples estimates but everyone has their own numbers. I can only say we don't think it will be anything like that but we could be wrong. Of course if *** actually deliver that 3.5GH/s rate, the price is $149, it actually appears in October in numbers maybe it will be that. I'm not going to try and disagree on something I can at best only guess at. There are still more questions than answers here but only waiting for October and maybe a lot longer will you find out. And when we get there maybe one set of followers will say "I told you so". We will carry on delivering what we promised as best we can and make a better evaluation in October of what return can be had. Remember the GPU rigs have a 5-10X power usage for the similar hashing levels to CM1 rig so by your numbers how many GPU miners will be left by say December. I doubt many if *** are successful.

State of the Nation Time


I have not done one of these for a while so probably time to do one now.

Bitstreams as you all probably know are being done by Glasswalker amd Makomk and we are doing our best to keep up with them to test and support them as much as we can. Our own bitstream development isn't stopped altogether but as these guys are doing so well it is better we put as much of our available resource into supporting them as best we can.

Shipments are going fairly smoothly and about half of September's promised deliveries have been shipped already. We will be asking for the balance to confirm during this coming week as we have to decide both on how much extra silicon to buy and if we can accept any more orders in the near term. Obviously a lot of you if the later shipment promise customers are debating whether you want to go ahead because of ***. If you are uncertain it is better for us that you tell us sooner that later. It does hurt us if we get left with a lot of silicon or boards that are not wanted for whatever reason and if we lose money on this project we won't be doing anything for Bitcoin in the future.

If *** actual produce what they promise it will change the bitcoin market somewhat but not necessarily so much that a CM1 board isn't viable still. There is much more to this that just hashing rates. It may change the return period but my guess is that it will still make a profit. Personnally I still don't think *** have done their own customers much good which is very silly and no good to anyone. I also think the real people to suffer will be GPU miners. GPUs miners banking on good resale values of GPUs might be very dissappointed as well in the next few months. My crystal ball shows resale values dropping through the floor for GPUs if *** are successful.

Some of you are asking how much we have lost to *** and it's difficult to be totally accurate as we are still getting new orders. We always expected a certain amount of drop off anyway with a pre-order system. People do change their mind over a couple of months. I'd probably say 25% as a rough number which sounds a lot but even after that we are still running at x5 the numbers of orders we expected when we started this project. The project has given us a few cashflow issues but that has been managed. We have done projects bigger than this before and that experience has been invaluable in coping with the demand and what goes with that.

Going back to the technical we are now understand the CM1 pretty well and the fixes that the successful bitstreams use are working well with that. Remembering that we are learning about Bitcoin as we go we have learned a lot in the last 16 weeks since we announced the CM1 concept and started the design and manufacture of this product. We believe the "noise" issues that have to worked around in the bitstreams are 80% down to the Spartan-6 packaging which something that we can't do anything about. This 80% is peculiar to the way that hashing causes very large current surges. The 20% part that we can change in PCB design will be incorporated into what we do next as a Bitcoin mining product. The whole "noise" subject is a combination of factors and is not simply one thing or another. It is a combination of various things. On the difference between the early pre 0051 boards and the later post 0050 boards and we think the difference is actually very small and that the better pre-0051 are as good as the lower to mid performance boards post 0050 boards. It's a tolerance band overlap. We also seem now to have bitstreams that can make the worst pre-0051 boards work. We have a "very bad" board working here now as a test platform to help prove out things.

We are getting very stable performance now out of production boards and all production boards get test mined for 1 or 2 days before they ship. Nobody should see an underperforming board now unless there is something peculiar to there setup. We can't cover all possibilities of software, network, or mining pool in our testing but unless a board meets our internal performance marker it doesn't ship to a customer.

During September we will try improve documentation on the various aspects of CM1.

For the future we are looking at what we might do as products for Bitcoin mining and we slowly putting together concepts and seeing what we might do with those. We won't release any information on these until at least October for obvious reasons. We will evaluate if they can compete with *** solutions and if we can compete they will probably be announced. If not some of those ideas will appear in our other product areas and won't be wasted time.

We have been trialling Bitcoin payments for a few weeks and we are ready to start accepting payment this way in a limited fashion. Our biggest concern now in this is that transactions can't be traced as such and we don't want to get into "I sent money" and we say we didn't get it syndrome so we will limit direct taking of Bitcoins to less than GBP £1k equivalent. For the existing pre-order price we will also add a risk/conversion margin of 15% based on Intersango rates. Once we have more experience of this method we may revise the limits or margins but that is what we will offer for now.

There is a second way that Bitcoins can be used to pay us and this way came out of our investigations into using Bitcoins. This method uses Intersango as Bitcoin conversion, other exchanges may be able to do this as well, but Intersango is UK based as that is an advantage in this method. It works on the basis that the customer themselves hold a GBP/Bitcoin account/s at Intersango and convert Bitcoins into GBP. Once in GBP a transfer to our GBP bank account can be done on smaller amounts in less than one banking day and probably 3 days on larger amounts. We are awaiting confirmation of the "faster payments" limit for the 1 day process but we have already done up to several hundred pounds so far as a trial and that works well. The money transfer from Intersango to us should be fully traceable as it is simply a conventional UK bank transfer. Charges for the bank transfer we believe as follows £0-100 -0 £0.20, £100-200 - £1.00, £200+ - free. You can all argue about whether the Intersango converstion rates are competitive and the same for ther commission but we have not found them them to be too bad in what we have done ourselves. We may also ask you add a marker in this sort of transfer and that will simply be a variation in the number of pennies you pay us so we will vary the amount by £0.01 to £0.99. This means we unlikely to get identical payments that we can't 100% determine from whom they came from. All we see is it's from "Intersango" when it arrives in our bank account. We will be interested to how all of you get on with this method. We think this hybrid payment system is very straight forward and provides the tracability that avoid disagreements about whether payments have actually been made.
 
As far as we can tell, and it's a lot more we can find on some exchange operations, Intersango has been good in it's dealings with customers. If you have any experience on that, good or bad, we would be interested in the feedback. This is still an area that we are learning about. The advantage with Intersango being in the UK we do understand what reglatory and business norms apply to businesses operating in our particular backyard.

I will try and get some pictures for which way to connect as that might be part of the problem. You also have to use SWITCH4 set to master on the board with USB and slave for the second board. Otherwise it don't work.

We think Rev 1.5 is ok and programmer is fixed but we will do a little more testing with it before we release that formally.


Depending what Controller version you have the details may vary a little but for most versions SWITCH3 set to "off" during programming of the array FPGAs/SPI Flash is usually recommended. SWITCH8 at "on" (default) for using the internal programmer. Remember to put SWITCH3 back to "on" when finished programming. It's always best to power cycle the board before programming as sometimes FPGAs get hung up in strange states.

Windows7 isn't usually a problem. We run it here on most machines and that is what we using in the main. I think Webpack version is restriced to 32bit install but that should be ok under 64bit with compatibility settings. I'll try an install on a clean machine if I can find one.

Apologies for the inconvenience and we will try and not make the same mistake again. We do know now what the issue is simple 2 '1's instead of 'z' in a logic function that drives i/os back to the FT4232.

There are a range of cables available to program with. Parallel port types are very cheap but obviously have a problem that not many people have a parallel port. We do one at £15 (+vat if applies) called Prog2 but there are many other others. For a USB solution we offer out Prog3 at £50. Cheaper solutions at one of our competitors http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,395&Cat=5 and Chinese clones as well. You can generally find the Chinese clones in Ebay.

There is also a possibility of reprogramming a Cairnsmore1 Controller from another Cairnsmore1 (suitable updated) and by connecting headers up to up and down to down using standard up/down ribbons. We will have a look at that. If it is viable it might take us a couple of days to sort that out. An extension of this technique might allow us to a cheap recovery module for the Controller and we are looking at that as well but that will take a few weeks to design and make.

We just checked and we can do a Controller update, using SPIprog here from the Controller for Glasswalker2 but it does need very specific DIP switch settings. The main ones to have are SWITCH3 = off, SWITCH6 = on. I think some switch settings changed around about when we did this one and that might be part of the problem here. It is different to what we did in Rev 1.3.

There is definately is a problem for Rev 1.4 so don't use it.

There is another possibility and that is to acquire a programming cable that will work with Xilinx ISE tools. Webpack versions of ISE are free, will run under Linux, and whilst they won't build for a LX150 Spartan they I believe will allow programming on these devices and certainly will for the XC3S50AN used for the controller. Some details http://www.xilinx.com/support/download/index.htm. There are several options for cables that will work with this software including our Prog2 (cheap parallel port cable) and Prog3 (dearer). Digilent, Xliinx and various Chinese clones are available as well. Don't ask me if the Chinese ones work. I have never tried them. 

This one is really for bigger rigs at the moment. It's main benefit is a reduction in the number of USB ports used and hence hubs needed to get all of this going. It does not reduce the number of com ports.

The next stage is basically an extension of Icarus pairs and we might look at say having 16 FPGAs work together over 4 boards on a single com. That reduces both the number of com ports and USB leads and will probably make life more simple for rig setup. It's possible that some performance may be gained this way as well but we will have to see on that.

Rev 1.4 of the Controller is now available.

Dip switches as follows:

Linux programming for the Controller is a problem in that every solution we have looked at involves a paid license. I'm told there is a problem with the FTDI drivers for Linux in that unlike Windows the VCP and V2XX drivers can't coexist in most cases. However there is a documentation contracdiction and small possibility coexistance because we have a customised PID and this restriction this might not apply. At the moment we don't have much engineering resources available to do anything on this and it's unlikely we will make progress until September. 

SW1 is only a reset to the FPGA logic as you say. The USB reset pin is directly related to power so there isn't a path available currently.

On Spartan-6s generally there is no good way to sense temperature. There are temperature sensors in the board next to each FPGA but the way these work is they need a bitstream design that will support them. I don't believe any are in public domain as yet although Glasswalker I believe is looking at that. Even working these sensors will have a large degree of inaccuracy over the die temperature of the Spartan-6 and of limited use. The most important thing in the cooling solution is to know when a fan is not operating and we have that covered already. With the fan running we normally see the heatsink at only 5-10 degrees C above ambient temperature. We expect the S6 die to be at 45 degrees C above the heatsink temperature when running the full 12A core current available and about 35 degress C running something about 10A which is about the maximum of Makomk or Glasswalker bitstreams currently. It's nearly impossible to verify these numbers on a board without major chip surgery and even then you are changing the environment for testing.

We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok. The main feature of this build is the first usage of the up/down cabling and it is a very simple implementation that we have done to use it. With Rev 1.4 you have the option to pair up boards to use a single USB interface. On the Master board all 4 com ports are used to support 4 pairs of FPGA 2 pairs on the Master and 2 pairs on the Slave.  So long and short of it is that you get to use half the USB cables that you needed previously.

If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.

We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.

We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.

We are also closing the general pre-order now with the general intention that it will become a stocked item from October onwards. Large orders will possibly still have a lead time and also tend to clean out available stock so it won't always be immediately available.

July Order Close Out

A few of you, on a July delivery promise, have not responded to emails saying boards are available. In order that we can delivery ASAP to customers waiting for boards we are about to close down the July order list. We will wipe anything remaining that we have the July list on Monday so you will lose that order place unless we have heard from you either to reschedule the order or to pay for it. So if you think you have been missed do check your spam box and/or contact us if you still want your order.

Ok I will try and get more info on this on Monday but as usual I would recommend you send an email into the bitcoin.support email as a backup so that all of the team see what problems you have.