Im getting the same exact results with cgminer an glasswalkers bitstream. I suppose this is the point where I  need to learn how to compile crainsmoreworker... there isnt a windows build out there, right ?

The dip switch settings were posted a page or two back by Yohan. I believe Switch3 needs to be off, all other on, to program. For "normal operation" it's ALL switches in the "ON" position.

As for that error, I hadn't seen that error on mine. It sounds like a baudrate isn't being specified. If it isn't defaulting one, use 57600 for it, that's the rate this bitstream talks at.

Check that and let me know. If that still causes an error, take a screenshot of exactly what the web UI looks like when you get the error (ie: what stage of the UI this error gets thrown, upon clicking new worker, when filling in the form, when saving the worker, or whatever).

If you are using the new controller check the new dip switches usage.

Yohan - What about the bitstream that goes along with the controller update?

Cairnsmore controller for Glasswalker2 build is noe available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. This is only for the Glasswalker build and won't work with any other bitstream. Currently only properly supporting 3 FPGAs with 4th running very poorly. Expect a U of about 7.5 from what we have seen and power usage less than 30W.

We will look at other options but we don't really want to do that in a hurry unless we can't solve the CGminer? issues. To do so could open up a pile more of support issues to deal with and that would slow progress on all the new things we are working on and want to bring for you all to use. I think we will try CGminer 3.5.0 first and see where that takes us.

Uh, what does that statement actually mean, please?

There are four FPGAs on the board. Are you getting 10.4 U (cgminer U) per board? Or are you getting 2.6 U per board? Or some other permutation?

Yohan,

you're using an "old" version of cgminer, please build one of the lastest 2.4.x or even 2.5.0 (I'm not sure 2.5.0 is as stable as 2.4.x) but 2.4.3 as a minimum version.

See also https://bitcointalk.org/index.php?topic=78239.msg968533#msg968533

I'm using 2.4.3 (though on linux and with not so many boards) and I've never had the problem you're reporting.

spiccioli

Twin_test bitstream running settings on the swiches not indicated in the picture worked for me.

Ok we don't know if this will fully fixes all problems because as yet we don't setups here that show the same problems some of you have and that is why we need work on each problem individually. We do need each board that you have a problem with to be reported to the bitcoin support email with the full circumstances. Not everyone on the team has the time to wade through the forum and they don't unless they stop work on new features or support work so that means problems can be missed. I will try to patch the gaps but I also have a limit in what I can find time to do. It's much better if the information arrives at the correct place and several people get to see it. It also acts as a log we can go back through then also.

Ok what we do know is that this build appears to improve the clocking at 100MHz i.e. that used for the Twin build. We do have some more tests to check this out and that is why it is beta. What we don't know is whether the clocking is the problem failure of the golden nonce test. I wasn't aware of that issue and that is much more likely to be a setup, software or firmware issue. We think that the FPGA DCMs lose lock sometimes and we already have fixes for this also in the working FPGA end which will be available in our own bitstream design that we can't do to the Twin which basically isn't our design.

We also think a few rigs may be suffering from power surge issues particularly at start up. This a problem in several parts including the host power supply quality, wiring quality, and even the Cairnsmore1 itself. This might explain some of the USBs not enumerating but there are also other possibilities for that including faulty USB cables that we did have a few problem ones of. Rev 1.2 has power startup sequencing so that we power each of the 4 power sections in a sequence over 4 seconds and that switch on sequence will be very obvious when you power the boards. This softens the surge on the board and we will extend this rig wide when the up/down becomes functional. One the things that is different with Cairnsmore1 is that there are several large rigs using Cairnsmore1 the size of which have not been seen before in Bitcoin mining. These bring new design challenges in things like power and cooling and we have designed Cairnsmore1 to cope with these extra challenges. Cairnsmore2 when we do that will take the concept to a much bigger level again.

We have also phased on board clocks in the new controller build to reduce "beat" cycles on the power supply. Every FPGA doing exactly the same thing at the same time is a very good way to cause beat surges on the PSU so if we can move those slightly apart then that is good thing to do and make life easier for the power supply.



Wrong For the Controller I don't thing you need to change dip switches from normal settings but I will check that.

Look in document xc3s50an_loader_v1.1.bit that is in the zip for the 1.1 update for the dip switch settings.

An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.

We will do some more testing and work on the controller this week and there may be further updates.

Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.

Can you send as much information into the bitcoin support email so that everyone relevant gets to see the problem. Outside what's already been mentioned on the forum, and thanks to all that have already forwarded into our support, we have not had any reports like this come in. So as yet we don't have a big statistical base to work on. We also haven't had a faulty unit arrive back to us yet to analyse. One I think is on it's way. So bear with us for a few days whilst we get enough information to give us a clue where to look. Probably the first thing to do is to try and create a model setup as similar to Zefir's as we can. We do think there is more than one aspect here and elements of software and firmware are probably the main place to look. However we can't rule out a hardware failure so that also needs to be part of the analysis. From what we have seen here on the line USB failures are very low and all down real identifable things like solder shorts.

You are nearly in Canada if I pulled up the right record. If I am wrong let me know. Hopefully we can get it there for Tuesday.

But let's work out what the problem is. No point being frustrated if we can do something about it. It might be that you have a board that has a real fault. It is very unusual for one of our standard boards to fail in the field having been though one of our tests. I think it's about 2-3 boards in the last 9 years but it's still always a possibility.

We are still at the stage of being bit of rough and ready in terms of documentation, software and bitstreams and we will do our best to get you all past that bit as fast as we can. Hopefully this coming week will see the next major step forward and we will meet at least some of the expectations out there.

I am nearly finshed the document that will hopefully make this simplier for Windows users and that will have dip switch settings. 90% of that will still be useful to you as a Linux user so you could try and follow that. It some be available tonight or early tomorrow. I will have some more dip switch setting pictures that I am doing for that now and I will try and post those here shortly as a short term help.

Ok I think we should send you out another unit pre-loaded with the twin bitstream and latest controller for you to try and we will retest your existing unit. It's more likely to be a software issue than hardware but let's eliminate as much as we can by the hardware re-test.

Yep! And it's working