Close

First Pants

A project log for RPi WiFi

Fast RPi WiFi without USB

ajlittajlitt 01/30/2016 at 06:2712 Comments

The boards for the WiFi Pants came in the other day, and I hastily soldered one together. Due to my ineptitude in KiCad and PCB design in general, I spent most of last night debugging the board. Long story short: made solder mask clearance too wide, OSHPark left a slight registration error in the mask, bridges between pads and the ground plane happened, ended up frying a USB hub.

I got it working, but didn't have time to do much more than bandwidth testing. ~24Mbits up, ~30Mbits down to the reference router. I used @jacksonliam's script to take the ESP's flash out of quad mode, with some issues on the readback (more sometime later). Haven't touched audio yet. It'll probably be Monday night before I have a chance to get back to this.

In the meantime, enjoy some pictures:

I proto'd this with the header backwards, since I have only one Pi Zero and don't want to solder the stacking pins through on it yet. Extras are hard to come by.

How a Zero looks with Pants.

Pretend the header isn't there.

Discussions

David Lowe wrote 01/30/2016 at 21:57 point

This project has taken me in new directions, I've been busy learning to use Kicad for my own twist on this - thanks for the impetus! I'm putting parts on the reverse side wrt the Pants board so that it sits flat against the Zero (with drill holes co-located with the HDMI socket housing pins to allow this).

I'm so keen to see decent bitrates on the SDIO bus that I am contemplating tearing apart the mini-pc on which I'm typing this as it contains the module "Realtek RTL8723BS Wireless LAN 802.11n SDIO Network Adapter". On the Zero I get 25MB/s at 62.5MHz on SD cards, so 200Mbps WiFi should be attainable with the right module!

  Are you sure? yes | no

ajlitt wrote 02/01/2016 at 18:32 point

I'm glad to hear this has been inspiring!  This has been quite a learning experience for me as well.

I'm still debugging my boards at 62.5MHz.  In my limited testing yesterday one of my WiFi HAT (esp8266 direct on board) boards rigged for 1-bit SDIO and with smaller termination resistors worked at 62.5MHz.  I didn't record the benchmarks, but IIRC it was something like 25Mb/s up, 41Mb/s down.  Not bad for 1 bit SDIO!

Tonight I'm going to swap resistors on my other working WiFi HAT board with 100 ohm and see how 4 bit at 62.5 works.  I'm excited to see how far we can push this thing!

I did consider putting everything on the other side, but zero gap (no pun intended) isn't possible anyway since there are PTH pins for the expansion that would have to go through.  So I figure that sandwiching components between is tidier. 

From playing around with layout it seems the ESP-12F would route more cleanly to the Pi's SDIO pins if it were on the opposite side.  Though I have a new layout that maintains a solid ground plane for all 6 signals (4-bit SDIO).

  Are you sure? yes | no

David Lowe wrote 02/01/2016 at 21:53 point

The original Pi used  33ohm resistors to the SD card socket. I haven't been able to identify any on the Zero, maybe they're dispensed with?

I wired an SD Card slot on the back of the Zero in a hurry - no resistors. 62.5MHz OK with SD cards & the ESP-03 mounted on an SD.

My proposed board adds both SD card slot & ESP module on a 65x30 PCB. I figured SDIO must allow hot swapping, so arranged a crude scheme to disable the ESP when an SD Card is inserted.  Swapping out WiFi to storage is OK, but second insertion of the WiFi freezes the system, some digging to do there.

I don't understand your stated reason to disallow back to back PCB mounting. I'm planning to insert an insulating shim, & arrange for holes where the HDMI pins poke out. With a 0.8mm board I should be able to solder the expansion onto the back of the Zero even when a 40-pin header has already been installed.

  Are you sure? yes | no

ajlitt wrote 02/01/2016 at 22:53 point

@David Lowe The driver flips out if the ESP8266 isn't in bootloader mode upon initialization, and it doesn't cope with unexpected data.  Typically bus errors or loss of the ESP8266 while the driver is running will end up in a panic.  Hence the Pi UART breakout on all my boards.

I removed the platform-specific functions to turn off and on the SDIO power since they were intended for a Rockchip tablet, which prevents this from happening on Espressif's customers' platforms.  Adding similar functionality using the CHIP_EN GPIO has been on my todo list.

I guess I wasn't clear that I was talking about my own design.  My board uses a 10 pin PTH header for serial and audio, so unless I used an SMT box header I'd have to leave a gap between the two boards for the through hole stub.  Even with good diagonal cutters you can't make PTH pins perfectly flush.  If you didn't use any offboard connectors, then flush mounting would work.

  Are you sure? yes | no

David Lowe wrote 02/02/2016 at 07:37 point

@ajlitt I'm cutting power to the ESP when an SD card is inserted, so on re-insertion the ESP8266 itself is in the correct state. To avoid freezing the system I've found that a sudo modprobe -r esp8089 is required before re-inserting . We need a way of automatically unloading the unused kernel module for this to work seemlessly.

Ah, I now see your reasoning for not having flush mounted boards.

  Are you sure? yes | no

ajlitt wrote 02/02/2016 at 15:33 point

@David Lowe I don't know if Linux has a hotplug mechanism for SDIO, so no way to cleanly unload the module and go back into polling mode if the link dies.  Most PCIe drivers would similarly freak out.

I'm not an expert in systemd, but I imagine that's where you would want this to happen.  If your SD/SDIO switching scheme can be controlled through software, then you should write a systemd service to switch to the SD card and another to switch to the ESP.  Listing each other as Conflicts= in the [unit]s makes them mutually exclusive, so when the SD card service is started the ESP service is first stopped causing the *Stop options to run (where you can unload the esp8089 module and deassert CHIP_EN), and vice-versa when starting the ESP service.  From there you would do "systemctl start my_sd_card" to safely clean up after the ESP and switch over to the SD card, and "systemctl start my_sdio_wifi" to switch to the ESP.

  Are you sure? yes | no

David Lowe wrote 02/02/2016 at 16:55 point

SDIO hotplug appears to work fine. Until I get my board design done, I'm using an ESP-03 mounted on a micro-SD adapter. I can yank this from the SD card slot without a hiccup, the WiFi indicator on the Jessie desktop drops cleanly back to the no-network icon. Likewise insert a memory card, then pull it. I thought about a udev rule to unload the kernel module, looking into that.

@ajlitt that was harder than it should have been, but eventually I got a working udev rule:

ACTION=="remove", KERNEL=="wlan0", RUN+="/sbin/modprobe -r esp8089"

Whenever I try add further attributes to properly identify the esp8089, puzzlingly the udev rule stops working.

Maybe there are "proper" ways to fix this, but for now, sdio hotplug of the esp8089 is working well.

  Are you sure? yes | no

jacksonliam wrote 01/30/2016 at 08:43 point

Nice! mine are on the slow boat still, I didn't set any mask clearance so I hope I don't have any issues like that :-/

The performance is pretty much what I expected from this module, I guess their RF design just isn't that great, or perhaps tuned down for FCC? 

How come you used the Pi 3v3 supply? Did you rule it out as an issue? Do you think it could do with some more filtering or bulk capacitance? 

Glad the script was use useful, feel free to do a PR or just let me know what it was and I'll fix it. I've not tried the script on a virgin module yet! 

  Are you sure? yes | no

ajlitt wrote 02/01/2016 at 18:54 point

With fairly large pads like 0603 and 0.1" headers, I don't think the 0 clearance is going to hurt.  I think the extra clearance is to deal with minor mask misalignment on really fine stuff like BGAs.  I found a general guideline of 3 mil clearance, so my next board will be 0.08mm instead of the 0.2mm on the current spin.  Looking at the gerbers this is the difference between having the mask even with the edge of the ground plane keepout (0.2mm) and having the mask cover almost all of the keepout (0.08mm).

I'm actually impressed with the performance given the 1 bit 41.66MHz SDIO.  Tonight I'll be dorking with the scope and changing termination resistors in the hopes that I can crank it up to 62.5MHz.

I switched to the Pi 3.3V supply once I realized that nobody has any solid guidelines on the 3.3V HAT rail, and that the 50mA guideline comes from the old A/B Pis that have a chain of linear regulators going from 5v to 3.3V to core.  Newer Pis including the Zero use a buck converter for 3.3V and should have no problem pushing over 1A.  I'm trying to keep this cheap since it's hard to justify an accessory that costs significantly more than the thing it plugs into.  $15 for a WiFi HAT for a PI2 sounds reasonable, but ridiculous for a $5 Zero.

The 10uF seems to be enough for the ESP on the Pi's 3.3V, so that's what I'm sticking with.  

It also doesn't help that the boards I built with the 3.3V LDO onboard seem to make the switchers on the Pi (all 3 I've tried) squeal when the ESP is idle.  Certainly I didn't do something right wrt the input bypass on the LDO.  Maybe the ferrite bead on the 5V in wasn't such a good idea?

The script seems to have worked, but I'm still not sure why I couldn't read back.  Yet another thing I need to scope.  I really hope I can figure it out since your script is so simple to use.

  Are you sure? yes | no

jacksonliam wrote 02/01/2016 at 19:26 point

Good point about the 3v3 rail. 

In the script, you could try a longer sleep after the command, but I think 0.5 should be enough! It's possible the HOLD pin is being activated as soon as you disable the QE bit. There are commented out lines to enable pullups for hold and WP, so it's easy enough to try out! 

-=Edit=-

Oh yeah, forget that! You have HOLD tied to CS, as soon as you remove the QE bit you can't talk to the flash any more... That's why the read back fails! 

  Are you sure? yes | no

David Lowe wrote 02/01/2016 at 21:58 point

I ran some tests switching in & out a 10 ohm load on the 3V3 rail to simulate expected current draw of a WiFi module. The Zero had no problem helping that resistor sweat a little!

  Are you sure? yes | no

ajlitt wrote 02/01/2016 at 22:43 point

@jacksonliam I have a solder jumper between HOLD and /CS that's left open during programming.  It was open at the time.

  Are you sure? yes | no