03-26-2021, 06:59 AM
(This post was last modified: 03-26-2021, 07:00 AM by dsimic.
Edit Reason: Word choice
)
(03-22-2021, 12:19 PM)barray Wrote: Ha! I'm sure some of the production is still more manual than you would hope, especially given the production numbers we're talking about...
An interesting fact is that the Rock64 v3 SBC has a bodged component on the underside of its PCB, which looks like a hand-soldered SMD transistor. That must have been a last-minute fix to the board schematic, and some additional manual labor has been selected instead of fixing the board layout.
(03-22-2021, 12:19 PM)barray Wrote: (Confused Pikachu face) Okay, will be interested when you have more details to reveal
It's a cryptographic device, and as such it's preferable to be "Made in Europe" instead of "Made in China". That's why I've opted for the "homemade" approach.
(03-22-2021, 12:19 PM)barray Wrote: I think offloading this problem to somebody like JLPCB is quite viable anyway, especially if you source the parts and send them to them - it could end up being quite low cost too. I suppose the only time it's not such a great option is when you are working on something you are trying to keep under-wraps, like a commercial project.
IIRC, JLCPCB provides an option to even source the required components itself, through their usual supply channels. Some additional design details must be submitted, a few additional rules must be followed, and the BOM must comply to the parts selection available through the supply channels provided by JLCPCB.
It would be a good option to have someone do the entire manufacturing process, once the sales volume reaches a certain point. However, please keep in mind that it would require the testing of assembled devices to be offloaded too, which usually ends up as one big mess, requiring a staff member to be in contact with the manufacturer almost on a daily basis.
With all that in mind, the offloading would be, IMHO, a viable option only when/if the sales volume of the storage device outgrows the "handmade" approach.
(03-22-2021, 12:19 PM)barray Wrote: I think you should actually look to make some money anyway, even if it just sits in a pot. You're going to need some float cash to expand operations and deal with random crap, like parcels going missing or things like this.
I agree, some money has to be made, for a few reasons. First, there will be refunds due to lost packages, "it doesn't work" complaints, and who knows what else. Second, I simply cannot do everything myself, and the other person handling the communication with the customers, shipping of the devices, etc. surely wouldn't be enthustiastic enough to work for free. Third, I eat quite a lot of food, which certainly isn't free.
(03-22-2021, 12:19 PM)barray Wrote: In other news, some interesting numbers for eMMc vs SD in the PienPhone (and likely all other A64 devices): https://xnux.eu/log/#032 In theory we just need to beat these numbers in order for our solution to be viable, which seems quite possible.
IMHO, beating an A1-rated Micro SD card should be good enough for the device in form of a "hat" for one of the BL602 boards. However, I'd say that a commercially viable device would need to equal or beat an average low-cost USB 3.0 flash drive.
(03-23-2021, 04:37 AM)barray Wrote:(03-22-2021, 06:20 PM)LazLong Wrote: Enjoying your spitballing and hope it evolves into a successful product.
I think we have a viable path forwards, we just need input from Pine.
Speaking of the above-mentioned cryptographic device, I actually managed to reach Pine64 around the time before the pandemic started. Unfortunately, they didn't find the device to be commercially viable and were not interested in manufacturing it.
Also, somewhere on the forum I came across a discussion about having Pine64 to start manufacturing some kind of a device (unfortunately, I cannot recall all of the details). Basically, the response from Pine64 was something like "bring the device to the commercially viable level on your own, and then we'll talk".
Quite frankly, we're probably on our own anyway.