Sigh. My boards originally "shipped" Oct 22 and I'm still waiting for them.

My order number is TXFEZVMAV

I've received a lot of apologies and promises but still have not received anything I have paid for.

What do I need to do to actually receive what I've paid for?

How about those of us who have already had their orders manufactured?

I've been told a lot of things about fixing the shipping problem but as of yet I still don't have my boards. There have been too many broken promises.

(Order TXFEZVMAV)

Nope. I was one of the people who had their order stuck with speedy for a while.

I did receive an email saying "Message from a client from TechnoBitour order is picked up by speedy" which I certainly hope is a translation issue since the very last thing I want is for my order to still be shipped by speedy.

I'm waiting on 11 HEX16A boards. It's been almost 2 months now since they shipped. I got caught up in the speedy.bg nonsense. I have been given a few shipping dates since then.

Last message I received said I would he would check on Saturday and follow up. No follow up as of a couple of days later.

I've seen lots of promises, but little action lately

Is there any update on this? It's taking a long time to get my boards delivered to me.

Order reference TXFEZVMAV.

Thanks!

Will you being doing this for all shipments currently stuck with speedy.bg?

I received an email saying I need to provide a proforma invoice, but my boards are for personal use. I'm at a loss of what to do now.

Any update on order TXFEZVMAV?

Two weeks ago I received an update saying the chips had been received and my order should ship out the week afterwards. It's been a week since it was supposed to ship and nothing else has happened. The order still says "Payment accepted".

Are direct shares being considered for those in the US?

Thanks for pointing me to that.

I pulled out my trusty multimeter and confirmed that the fuses appear to be dead. Now I just need to find a comparable fuse that I can order.

Any chance anyone happens to know a part number for that fuse?

The plugs are keyed differently, but the BitBurner XX boards (at least the ones I have) used connectors that are keyed to allow both types of plugs. I'm not sure why burnin decided to use these parts instead of the ones keyed only for the correct PCI-e power connector.

Aside from how it happened, it did and now I'm trying to figure out how to fix my boards

I received 6 boards recently and 4 of them have been working fantastically.

Two aren't working so well. After some troubleshooting I figured out that I plugged in the 8-pin CPU power instead of the 6/8-pin PCIe power. 

Looking at pinouts, the 12v and ground pins are swapped on the two meaning I powered up two of my boards with 12v and ground lines swapped.

I'm hoping I've managed to blow a relatively simple to replace component and I get these boards working. I can't seem to find any schematics so I can try to narrow down what components are most likely to be failed.

Have any schematics been released yet for the BitBurner XX?

I'm interested, obviously depending on the details when they are released

Same here. I've requested a refund for my 1st gen chips. I plan on getting 2nd gen chips and hopefully the parts you have can still be used for that.

Sent 5 BTC. Tx ID 44c514a1b06251387de4ff78b43b4981f4141a11b9f3e56c69fc68c68b24fb97

I was able to successfully place my order in the shopping cart and then pay for it, but the items still show up in my cart and no order shows up in my history.

It looks like something went wrong in the checkout process.

Is this a known problem?

Thanks for the hard work ryepdx. Not that I'm wishing chip deliveries to be delayed, but it looks like there will be some time before some of our orders arrive. Hopefully that means you'll get the opportunity to build your hard earned miners

Can you elaborate on the $0.00/kwh electricity cost? Is the 3% intended to cover the costs of electricity?

This is what I was saying about trying to map streams (serial data) onto a bulk pipe. When reading, you never know how much data the device is going to send (ie you never know how much you *need* to read).

It could be less than you're expecting (because you read in the middle of the USB device reading data from the serial port)
It could be exactly what you're expecting (yay!)
It could be more than you're expecting (because you weren't reading data quickly enough and more data arrived at the USB device, etc)

Since there's no way to reliably predict how much data the device is going to send (and thusly how much you can safely read), you need to read in multiples of the packet size. This will ensure you read all of the data the device is going to send you but also ensure you don't run into overflow errors during the read.

It's one of the annoying things about USB. It's too simple and it requires the programmer to jump through hoops.

You can read a little more information here:

http://libusb.sourceforge.net/api-1.0/packetoverflow.html


Writes shouldn't be a problem since USB devices will generally accept whatever you give them.

The other option is to avoid libusb and just use the kernel driver. It handles all of this stuff for you and should be easier to use.

Mapping of stream data onto a USB bulk pipe can be kind of awkward. Bulk pipes send packets of a fixed size (the descriptors document the size of the maximum size).

USB is host driven, so the communication with the device is always polled (on the wire at least) by the host. Effectively the device asks the device "do you have any data for this pipe?". The device then sends data. This can be anything up to the maximum packet size and there is no negotiation between the host and the device on how much the device is expecting.

If the device wants to send more data than the host is expecting, then it results in a babble error and this can ultimately end up in a device reset.

Reads that are larger than the maximum packet size for that pipe will be split into multiple packets of the maximum packet size with the last packet being equal to or less than the maximum packet size. (ie 150 byte read = 64 byte read + 64 byte read + 22 byte read).

This packet framing can be a problem with serial devices because you often don't know how much data is pending on the device side, or you're trying to read a subset of the data pending on the device side (because you're trying to read just enough data that you need for now).

For these serial devices, you should always read a multiple of the maximum packet size. If a device sends less, this is called a short read. Usually this is fine and how the protocol expects devices to operate (but this can be treated as an error too).

One last note about reads that are a multiple of the packet size. In that case, an extra 0-byte read will need to happen to ensure the proper framing occurs (ie data has 192 bytes to send, the host should read 256 bytes, which end up on the wire as 4 64-byte reads, with the last read being a 0-byte short read).

The kernel USB serial driver handles all of this framing for you, but it's certainly possible to handle this using libusb as well.

I'd suggest just always doing a large read (4096 bytes?) that is always a multiple of the device packet size and putting the data you read into an internal buffer. Then pull data off that buffer as you need it.

Also, libusb does support asynchronous transfers. You can place a read on a bulk pipe and you can be notified when the read finishes. The API could probably be easier to use in this case.