The six days I checked many possibilities…
Finally, I find it is clock circuit problem.

This is clock sch from v0.5:

This is clock sch from v1.0a:

So do you find the problem?

I moved 27pF cap to other side of the crystal for the new version…I did not even notice that …(when I optimised the layout of the PCB, I changed some parts of schematic, then forgot to change this part back…)

This small careless problem caused the hole board unstable and the wifi not working. Such problem will never happen again.

Why this BUG is so critical?

Normally, hardware is stable and able to afford some problem, for example, if you remove two or three 0.1uF cap, it works normal.

But crystal problem is always a big problem.

If RT5350 is the heart of VoCore, the crystal(clock) is the heart of RT5350. It can not work with a buggy clock.

v0.5 circuit is a standard noise reduction circuit, the high frequent noises are block by the 300ohm, and direct to ground by the 27pF cap. But when I move 27pF cap to another side, this RC noise reduction circuit is broken, so clock noise will be very loud, so some chips are unstable. Wifi signal is 2.4GHz, that is from crystal clock(20MHz) x 120, the noise is even 120 times stronger than the chip, so the wifi is not working at all.

This morning I contact the factory, their repair team is very busy, we have to wait at least one week. And from WuTong, The alpha VoCores had shipped to China Post and I can not make them back to change any hardware, so the alpha contributor have to change this yourself. Really sorry for that problem, I will record a video or write a blog with detail to show how to make that.

For simple, it should be changed like this:

Good news 🙂
Finally I find the real problem…Thank you for everyone help!!!
I have fixed three boards, so I think 99% chance I get this bug.
It is very late day, I will public it tomorrow afternoon. Keep that as a secret for couple hours. 😀

And tomorrow daylight I need to contact the factory first, ask if they can fix the 300 pcs for me. If not, that will be a little trick for new hand of iron/hot air gun.

This indiegogo campaign makes me carries too much…For 2K more contributors, I can not afford any mistake. After this I will/must have a big rest. 😀 😀 😀

after I changed the power input to 3.2V, it works stable over 24 hours, during the time, I tested GPIO, works well. Wifi has signal and it is fair, but I can not connect to it from computer, just get some weird system log, looks like the hardware of wifi still have some problem.

root@OpenWrt:/# logread -f
Sat Jun 14 20:16:02 2014 daemon.info hostapd: wlan0: STA b8:f6:b2:1a:7b:ed IEEE 802.11: authenticated
Sat Jun 14 20:16:02 2014 daemon.info hostapd: wlan0: STA b8:f6:b2:1a:7b:ed IEEE 802.11: associated (aid 1)
Sat Jun 14 20:16:02 2014 daemon.info dnsmasq-dhcp[881]: DHCPREQUEST(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:02 2014 daemon.info dnsmasq-dhcp[881]: DHCPACK(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed Vongers-MBP
Sat Jun 14 20:16:03 2014 daemon.info dnsmasq-dhcp[881]: DHCPREQUEST(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:03 2014 daemon.info dnsmasq-dhcp[881]: DHCPACK(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed Vongers-MBP
Sat Jun 14 20:16:06 2014 daemon.info dnsmasq-dhcp[881]: DHCPREQUEST(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:06 2014 daemon.info dnsmasq-dhcp[881]: DHCPACK(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed Vongers-MBP
Sat Jun 14 20:16:10 2014 daemon.info dnsmasq-dhcp[881]: DHCPDISCOVER(br-lan) b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:10 2014 daemon.info dnsmasq-dhcp[881]: DHCPOFFER(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:12 2014 daemon.info dnsmasq-dhcp[881]: DHCPDISCOVER(br-lan) b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:12 2014 daemon.info dnsmasq-dhcp[881]: DHCPOFFER(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:14 2014 daemon.info dnsmasq-dhcp[881]: DHCPDISCOVER(br-lan) b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:14 2014 daemon.info dnsmasq-dhcp[881]: DHCPOFFER(br-lan) 192.168.1.103 b8:f6:b2:1a:7b:ed 
Sat Jun 14 20:16:15 2014 daemon.info hostapd: wlan0: STA b8:f6:b2:1a:7b:ed IEEE 802.11: disassociated
Sat Jun 14 20:16:16 2014 daemon.info hostapd: wlan0: STA b8:f6:b2:1a:7b:ed IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Some boards(about 40%) are not stable, I add 0402 154Kohm 1% and 0402 158Kohm 1% resistor to the package, so if your alpha board can not work well(boot up with system oops), please replace the 150Kohm on board to 154Kohm or 158Kohm, this is a dirty fix before we find the real problem.

And further alpha test/fix report I will public in the forum but not blog, that will be easier for us to discuss the problem. 🙂

Finger cross, hope I find the wifi problem soon…

Get the 300 pieces from factory:

The alpha version have tons of bugs, be happy to catch them 😀

From my first test, there are two main problems:

1. the board is not stable through 3.3V~6V port, many oops when system boot up, but through 3.3V pin(input set to 3.1V~3.2V), the system works normal.

2. From computer/phone we are able to find VoCore wifi hotpot, but after connect to it, it shows a warning, can not ssh to the board.

First problem, I think it is PCB problem or design problem. But the design is copied from v0.5(some wire changed, I must compare them. Never be too careful, specially on hardware), and v0.5 is normal. So high chance to be PCB problem. Might be crosstalk? From my simulation the max crosstalk is 84mV(3.0V, 1.0ns), in most situation the max allowed value should be 150mV.

Second problem, just no idea, might caused by first problem. Same firmware works well on v0.5 but not this one.

From the factory engineer, he said two points must be improved in next PCB version:

1. V-CUT border is too closed to each other, some pin hole might be broken after SMT.
2. V-CUT is not good for such small board, the copper is easy to be stretched when they cut it into pieces, so it will effect signal.

I thought there might be some small problem such as wifi signal in the alpha version but I never thought these problems are so big…None of that happens to my test version v0.3 or v0.5.

I am really sorry, I planed this version should be at least as good as v0.5… I will also ship a small gift to all the alpha tester(USB<=>TTL/UART device), hope your testers will be a little happier. 🙂

And the boards will be shipped in this week. I am so limited, please help me make it better, really appreciate!

It is a long time 🙂 Now I am able to upload something to my blog.
Jun.09, at ShenZhen.

Jun.10, shopping.(forget to take picture…)

Jun.11, factory.

It is much faster than my hand solder. 😀 VoCore alpha is only 300 pieces, so they plan to make them about Jun.12 night in three hours.

What is this? 🙂

And special thanks for ShenZhen TechSpace or I will have no chance to meet so many creativity people there.

Thank you for my friend Wu Tong at ShenZhen get this picture. 🙂

Hello, every reader, I made a simple forum for the coming alpha test by using bbPress.

Address is here: http://vonger.cn/?forum=vocore-alpha-test

Now I am on the new version of dock. It is the first time I find microSD is that big for VoCore Dock…

No free place…Where can I place you, tiny SD card? Maybe a SPI camera(if this thing exists) is a better choice. 😀

Any good idea? Please leave a comment.

This should be final version for alpha test. It might exist bug on hardware.

Download Link Here: VoCore.v1.0a.pcb

Garber File For Drill: garber.drill
Hope this will help you make the breakout board.

This one should be much better. Move GND from bottom right corner to bottom left corner…So GPIO14, GPIO15 will not fight, and cover one GND is not a big deal.

Looks like move a pin is petty easy… But it is not. 😀