Close
0%
0%

RPi WiFi

Fast RPi WiFi without USB

Similar projects worth following
WiFi on a Raspberry Pi using the HAT connector and an ESP8266. The goal of this project is to add WiFi to the Raspberry Pi Zero while keeping the USB port free for devices or OTG connection to another host.

The instructions below tell how to connect a $2 ESP-12F module to any Pi that takes HATs with a small amount of soldering, and how to get it working under Raspbian. There are KiCad projects in the sidebar for inspiration and a starting point for ESP8266 SDIO projects.

When the Raspberry Pi Zero was announced, a significant chunk of the hacker world dismissed it for having the same fatal flaw as the other Pis: only one USB host port for high speed I/O.

Network connectivity is a major reason that people base projects around a Pi or other embedded Linux board. The 2B and B+ both have onboard USB hubs providing 4 USB ports and an Ethernet interface, making it easy to connect to a wired network or add on a USB WiFi adapter. But the A+ and Zero do not have this luxury. You need an external hub to get the same functionality, which compromises the size advantage and makes for an unwieldy cable mess.

That's unfortunate, because other embedded Linux boards in similar form factors are at least $50 (Intel Edison). These often are designed for commercial products, and so have hacker-unfriendly interconnects that need a breakout board that drives the cost up even further. What's worse is that alternatives don't have the same online support community that Raspberry Pi has fostered.

What the Zero desperately needs is WiFi that doesn't involve the USB port.

SDIO and HATs

The BCM283x SoCs at the heart of every Pi has two MMC controllers. One of these connects to the SD card slot that the Pi boots and runs its OS from. The other has largely been ignored, but comes out on the HAT connector as alternate functions on GPIOs 22-27. Recent kernel and boot blob changes have enabled these pins to be mapped to the MMC controller that also supports SDIO devices.

SDIO started out as an extension of the SD spec to allow for cards that have functionality beyond flash storage. Some PDAs could be expanded to have WiFi or cameras through SDIO. Although smartphones killed the market for SDIO cards by integrating these common features, the bus still lives on as a bridge between SoCs and WiFi modules.

At the time of this writing, the rpi-4.2.y branch of the Raspberry Pi supports the SDIO interface on the HAT connector well. Simply build and install the kernel and edit /boot/config.txt to include the following line:

dtoverlay=sdio,poll_once=false

This enables SDIO on the HAT connector, and asks it to poll for SDIO cards past the initial driver probe at boot time (more on this later).

Enter the Eagle

In all the excitement over the Zero, I noticed a bunch of questions about using cheap ESP8266 modules as a WiFi bridge. Usually these threads were killed by someone by saying that the SPI interface would constrain the speed too much. Fortunately those questions jogged my memory a bit.

I remembered this blog post showing a decapped ESP8266, noting that in the corner is printed "ESP8089". The post mentioned that ESP8089 is another Espressif part, a commodity SPI and SDIO to WiFi chip. That got me thinking that, if the ESP8089 and ESP8266 are the same die, then there is a good chance that an ESP8266 module could work as an SDIO WiFi adapter on the Pi.

Espressif isn't helpful with ESP8089 documentation, but some Googling landed me at the center of the cheap Chinese tablet universe. That pointed me to a driver in a kernel tree for a specific Rockchip-based tablet that happens to have an ESP8089 adapter, as well as an attempt to break out an older version of the driver as a standalone module to use with ESP8089 in SPI mode.

So there's a driver, and possibly a physical interface between the Pi and ESP8266, but what about firmware?

The ESP8266 we're all familiar with normally boots from an off-chip SPI flash device, and can optionally boot code over the UART. The determination of how to boot (UART vs SPI) is done by GPIO strapping at power-on. Most ESP modules are set so that one pin alternates between booting from SPI flash or the UART. This lets the UART be used to download new firmware to the SPI flash when hooked to a PC and to run from flash when not. But the sparse ESP8266 documentation does mention a third SDIO boot mode, but there is no explanation of how to use it.

It turns out that SDIO boot is intended for the ESP8089. The driver contains a few firmware...

Read more »

esp-12f_hookup.svg

Hookup diagram for the ESP-12F

svg+xml - 64.02 kB - 02/23/2016 at 20:35

Download

  • 1 × ESP-12F WiFi module - ESP-12E will probably work
  • 1 × Raspberry Pi Any HAT compatible Pi: A+, B+, 2B, Zero
  • 6 × 33 ohm resistor
  • 1 × thing to stick the ESP-12F on perfboard, cardboard, a graham cracker, Pi Zero, etc.
  • 1 × 2x20 HAT Connector (optional) run of the mill dual row 100 mil 40 pin female header. or just solder to the Pi Zero

  • WiFi broken? Update your driver!

    ajlitt05/11/2017 at 02:58 0 comments

    Recently Raspbian switched to a 4.9 kernel from the 4.4 based kernel that's been the norm for a while. This breaks the esp8089 driver. If your esp8089 module no longer loads following an apt-get upgrade, this is likely the problem.

    Thankfully den4ix on github issued a pull request this morning that updates the APIs for 4.9. The fix is in the latest Debian DKMS package released this afternoon.

    To update the driver, download the new esp8089 DKMS package from github and install on top of the old package:

    wget https://github.com/al177/esp8089/releases/download/1.9.20170510/esp8089-dkms_1.9.20170510_all.deb
    sudo dpkg -i esp8089-dkms_1.9.20170510_all.deb

    Reboot after the package is installed to reload the esp8089 driver.

  • It's been fun

    ajlitt02/28/2017 at 15:27 3 comments

    Now that the Raspberry Pi Zero W is out, there's not much reason to use a WiFi Pants board. The Zero W is more compact, cheaper, and has out-of-the-box Raspbian support for WiFi. Also Bluetooth.

    If you need battery power for your Pi Zero project, please consider the amazing LiFePO4wered/Pi .

    Thanks to everyone who supported this project!

  • Licenses, longevity, lights

    ajlitt10/23/2016 at 04:01 0 comments

    It's been a while, huh?

    Much has happened over the last few weeks. The biggest news is that Espressif has agreed to allow their ESP8089 driver to be licensed under GPLv2 and the associated binary blob firmware to be put under the Apache license. Now the driver powering this project as well as many tablet devices can be submitted for inclusion in the Linux kernel. A few embedded Linux enthusiasts have stepped up to clean up the code and push it through the kernel patch submission process. Thanks to Jeroen@Espressif for getting the approvals, and the free-electrons folks, jwrdegeode, noahwilliamson, and icenowy for their ongoing work in making the driver kernel-ready.

    About two weeks ago I sold the last finished WiFi Pants kit in my inventory. I'm also running out of my long lead time components: PCBs, ESP modules, and the long stack through headers. I will be doing another run of kits which should be in stock in a couple of weeks, but after those are gone it's going to take a couple of months to build any more.

    Finally, I was lucky enough to participate in the first Hackaday TV hangout and talk for a few minutes about my project with Sophie Kravitz and Limor Fried and hear about some really neat Pi hacks. But while excitedly rambling on about my WiFi Pants project, I forgot to point out the demo I put together to show off the WiFi pants board's power supply. You can see it on the bench behind me in the video blinking away.

    Behold, the Access Point Sniffer Thing With LEDs in a Jelly Jar That I Haven't Considered Naming Until Right This Moment, or APSTWLJJTHCNURTM for short:

    It's a WS2812 LED strip in a jar that changes patterns depending on the number and strength of WiFi accesss points in the area. It uses a 60 LED WS2812 strip, WiFi Pants, a Pi Zero, 3 AAA NiMh batteries, a jam jar, a plastic tube from the packaging for a USB charger, plenty of clear packing tape, a few dabs of hot glue, and a WS2812 level shifter board made with junk box bits. Software is in Python using the rpi_ws281x library for talking to the LEDs and iw_parse to simplify the AP scan.

    Every second or so the Pi does a scan of the available networks. The networks are sorted by the signal strength and assigned an LED for each 4dB of signal strength. Each access point gets its own color by hashing the last 3 octets (the non-OUI portion) into hue and saturation. You can see at the bottom in the gif above that the LEDs towards the bottom of the jar are more uniformly colored and don't change much, while the APs that have weaker signals dance around with a larger variety of colors towards the top as they come in and out of range.

    Total time spent on this was about 5 hours. I figured that the string at full brightness plus the Pi and ESP8266 would push near the 2A limit of the boost converter, making it a good demo. However the LEDs at full power saturated my webcam to the point that the jar looked like it was filled with burning magnesium, so it's limited to 1/8 brightness. That's probably for the best, as the AAA batteries droop too much at full LED power to keep up with the 4A or so the converter pulls at its limits.

    Thanks HaD, Adafruit, Limor, Sophie, and all the other hackers for a fun hour of sharing projects!

  • Need Pants?

    ajlitt06/07/2016 at 19:34 3 comments

    I have a few WiFi Pants boards listed on Tindie. Have at 'em

  • Driver update

    ajlitt05/23/2016 at 15:52 3 comments

    Last night I checked in a change to the esp8089 driver that automates toggling the reset (CH_PD) on the ESP by GPIO. With this change ESP hacks based on the instructions here will automatically come up during boot without any scripting or external reset circuits. This also issues a reset on module unload which is needed so that the ESP is detected after a soft reboot (reboot on the command line, etc) and keeps the module from OOPSing when reloaded without a previous reset.

    The project instructions have been updated to reflect this change. If you previously added sysfs GPIO or module unload commands in your init scripts for the ESP (rc.local and otherwise) you'll need to take them out. The driver defaults to GPIO0 (ID_SD like the WiFI Pants uses), but you can pass the esp_reset_gpio module parameter with the GPIO number your board uses. This should be platform agnostic as long as the target has a kernel GPIO driver.

    The driver still isn't ideal since it must always be rebuilt every time the Pi kernel changes. On other Debian based systems this could be handled with dkms, but the Pi Foundation's non package based kernel scheme makes it difficult. Of course I have a build process to help with this, but that's dependent on a network connection and gets unpleasant on the Zero. One solution would be to build the driver against each Pi kernel release and index it by the kernel's commit hash (like rpi-source). If anyone has ideas for a cheap (or free) binary release hosting service I'd be open to setting up an automated build server.

    As for the WiFi Pants... I still have the first batch sitting on my desk. I wanted to get this driver change in to simplify initial setup, and still have some documentation to do. Keep an eye on the github wiki and on this project for details.

  • Production starts!

    ajlitt04/14/2016 at 06:04 4 comments

    Repeat 9x.

  • Testing the tester

    ajlitt04/10/2016 at 16:59 0 comments

    The test jig / bed of nails is coming along nicely. I OpenSCAD'd a mount and retention clips for the DUT, and with some filing and drilling out the PCB the DUT and pogo pins line up reliably and the DUT stays put. A choco-block terminal strip connects to the PSU and lets me clamp to the disposable DMM probes. The DMMs need test leads with an odd mini banana plug, so rather than trying to make custom cables I just clamp the probes in the terminals. They're used only for voltage measurement so this is fine. Some more drilling, standoffs, and a power jack for separate power to the Pi A+ round out the fixture.

    The output load is simply 8x 20 ohm power resistors in parallel for 0.4 ohms which gives 2A at 5V. They get a little toasty but don't seem to need active cooling.

    A few bugs to fix in the next couple of days:

    I'm seeing much higher voltage at the DUT for the input than at the fixture's DMM, so I'll try doing the Kelvin sense thing and run separate wires from the terminal block to the pogo pins for the input rail. Unfortunately there's only one pogo pin feeding the input to the DUT so I'm likely not going to see the actual voltage unless I redesign the PCB with a dedicated test pad for the input.

    Also, the regulator is getting excessively hot, moreso than when I've tested it on proto builds. Most of the heatsinking is done with vias to the ground flood on the back, and my design for the mounting frame has a solid fill behind the DUT except for where the pogo pins are. I'm currently reprinting this with much more area under the part exposed and a little vent towards one side in attempts to let the switcher cool naturally.

    The resistor load is working as planned, except it's just below the 2A point I want to test due to wire losses. So I might add another resistor in parallel to get closer to 2.25A which should make for sufficient testing margin. Easy enough since I've got a big bag of spares.

    I drilled holes for three standoffs to support the fixture, but realized I located the pogo pins too close to an edge for one of the corners. Need to find a dowel or something to hot glue there.

    I put a toggle switch from my junk bin on the board so I can shut off the Pi between DUTs, but the switch is flaky and cuts power at the slightest touch. It's shorted closed for now, but I'll eventually get a replacement.

    And a final mistake that should have been obvious: I am seeing lower throughput on WiFi than on my proto builds. I don't see this when using the same DUT carefully held on a Pi's header, so it's likely the fancy recycled perfboard I'm using with the ground plane restricting the signal. That's ok as long as I'm seeing consistent behavior between units.

  • Knife sharpening

    ajlitt04/07/2016 at 17:24 0 comments

    Now all the parts for my first small run of boards are sitting in a box on my bench, and I've built up a test board. This is what I plan to sell:

    The headers are shipped unsoldered to allow for different assembly options and to simplify packaging. Ignore the plastic spacer on the header, as it can be removed. I'm not in a place to stock a ton of different options, so if you want to mount this underneath a Zero you'll need to find a different header.

    Based on suggestions kindly offered by others, I'll be selling three kits: "full" with everything above, "basic" with only the WiFi populated on the PCB and including all the headers except the JST, and a bare PCB.

    Although I have materials in hand to crank out boards, I need one critical tool in place before production starts. I want these board kits to work once customers solder them together, so I'm working on a test jig for running the SDIO interface and power supply through their paces. After many years of getting along without a real bench supply, I invested in a nice Korad 30V 5A programmable linear that I can use with a pile of power resistors to run the 5V output to 2A at various input voltages, and to test the undervoltage lock-out. I also got a couple of cheap-o DMMs from Fry's over the weekend for a rough output voltage check, and some miscellaneous bits and pieces to put it together. I intend customers to use this board to run motors, LEDs, and other current sucking peripherals, so I want each board tested at load.

    Eventually I'll have a printed frame for the PCB and stand to take the load off the Pi underneath. I plan to have this working this weekend, and to start cranking out boards.

    I can't give any estimates when this will go on sale. March was exceptionally busy, and I've had little free time to work on this, and April is shaping up to be more of the same. But I'm making progress which I'll continue to share here.

    In the meantime, enjoy this picture of my messy bench:

  • Surprise boards

    ajlitt03/26/2016 at 21:26 4 comments

    Up until now I've been ordering OSHPark quick turn proto boards because they're cheap for very low volume. For the initial Pants run I went with Elecrow in China from the good reviews I've heard. I put in the order last week for 50 Pants boards with 3 day shipping to the US.

    DHL just notified me that I should expect them on Tuesday. But I'm totally unprepared. I don't have stencils, I'm missing some of the more expensive parts, I don't have a Tindie account set up yet, I haven't figured out shipping or packaging, I don't have a test jig built yet, and my bench is a mess! I don't know why, but I didn't expect 50 PCBs to be manufactured, shipped halfway across the world, and delivered in under 10 days!

    update - and here they are:

  • On the loss and renewal of focus

    ajlitt03/21/2016 at 05:08 0 comments

    (TL;DR: spent a few weeks on a tangent eating my own dogfood, finalized PCBs and ordered a bunch)

    Spring Break is always full of distractions for me. The kids are out of school, work slows down a bit, and South by Southwest takes over Austin, TX. A few weeks ago I got an email from @Sophi Kravitz asking if I might have any hacks I could bring for a panel she was giving at SXSW Create. Naturally I wanted to show off this project, but it hadn't occurred to me 'til then that I had built exactly zero projects using the WiFi Pants board.

    The board isn't that interesting by itself or on a headless Pi, so I wanted it to do something flashy. It needed to be battery-operated to show off the boost converter. So I turned to my junk bin for inspiration, and made a simple LED scroller with the LED matrix from Sparkfun's BadgerHack swag they gave out at last year's SXSW (thanks again!):

    I... uh... went a little crazy on this. I didn't expect the show-and-tell to be anything more than what it was: a short demo during the panel. But somewhere along the line I got it in my head that it needed to be a polished looking gadget and not a pile of boards and bodge wire.

    I spent a few late nights building the board stack and designing a 3D printed case. The Sparkfun LED array has mounting holes on 23mm centers, conveniently matching the Zero's screw holes, so I scrounged some washers, standoffs, and screws from my junk box and point-to-point soldered the array to end up with this:

    Initially I wanted to fit a small LiPo pouch in between the Zero and Pants board, but I ran into a few problems. I couldn't just go down to the local hobby shop and grab a battery for a nano quadcopter. I needed a protected cell to compensate for forgetting the UVLO (under voltage lock-out) programming resistors on the switcher on this board rev. Failing to have either cell protection or UVLO on the switcher could drain the battery too far and lead to surprise fires of the sort I'd like to avoid. Unfortunately there seemed to be a run on cells with the characteristics I wanted: reputable seller, fits in a 45x23x6mm volume, has protection, big enough for 1hr runtime (>=400mA), and fast enough shipping to get here in time. It seems that the sorts of batteries I wanted were all snatched up by hackers making one of the DIY Zero-based Gameboy projects.

    I ended up sticking a 3-AAA battery holder to the back of the case. I used 750mA NiMh cells which consistently give 2:15 runtime with the scroller running constantly. It wasn't as pretty as it would have been with a LiPo, but it worked and was likely safer. I had to make changes in the case model to make the battery connector accessible from the outside, but otherwise it worked well.

    The software is all Python. I could have done a C userspace daemon or kernel driver to make the display scanning smoother, but I didn't have time and figured a 1GHz CPU could handle it. It is multithreaded though, with the display scanner / scroller in its own thread that relies heavily on sleep() for timing, and the main loop and Twitter checker in the parent. There is a little flickering when the CPU is loaded, but it's not too distracting and only seems to show on feed updates.

    The case was modeled in OpenSCAD and printed in translucent gray (actually thermochromic "hypercolor" plastic) filament. The front of the case is .8mm thick, acting as a diffuser for the display. The thin front is a bit fragile, but it survived the demo. I did print and carry around a second copy the day of the demo though. The insides are lightly friction-fit to the screw heads on both sides of the body, and has stops inside to prevent putting stress on the protruding ESP-12F module antenna. A friction fit lid and hoop for attaching to a lanyard finishes it off.

    So this is great and all, and I hope some of the audience found it interesting, but what about making some boards available for sale? Last night I put in an order for 50 PCBs, and will get stencils and additional components...

    Read more »

View all 30 project logs

  • 1

    HARDWARE

    (WiFi Pants owners skip to SOFTWARE below)

    You'll need 6x 33 ohm resistors (either through-hole or SMT), some wire, and an ESP-12F module.

    Some variants of the ESP-12E should work as well, but there are some that do not have the GPIO9 and GPIO10 pins connected to the edge, and others that have a different pinout than listed here. From what I can tell there is only one variant of the ESP-12F (labeled "ESP-12-F QIO L4" on the back) so that is a safer bet. ESP-12F also has an onboard 10uF capacitor across the input supply, which saves you from having to add one yourself.

    You probably want something to mount the ESP-12F on. Perfboard is fine, as would be cardboard or just double-sided foam tape on the back of the Pi. No matter what you use, make sure that nothing is under the antenna or range will be greatly reduced. The ESP-12F LED is a good mark for the start of this keepout region.

    I use outdoor double-sided foam tape on my hand-built boards since it's tough but not hard to reposition, and raises the module enough to not short against the board. Creative application of hot glue or epoxy putty might work fine as well.

  • 2

    Make the connections between the ESP-12F or -12E and the Raspberry Pi HAT. Keep wires short as possible, and minimize the number of times they cross over each other. If you're using magnet wire or Kynar (standard issue blue wire) you might want to use a heavier gauge for the 3.3V and GND. Ideally the wire lengths of the 6 SDIO signals should be identical, but even a couple of inches of difference shouldn't matter. If you can, keep SD_CLK close to the average length of the other wires.

    The SDIO signals (names beginning "SD_") should have 33 ohm resistors in series (in between the Pi and ESP-12F connections). It may work with other slightly larger values, or with no resistor at all.

    If using 1-bit SDIO instead of 4-bit, omit D2 and D3. There's not much of a good reason for this though.

    A capacitor of 10uF or more may be needed between 3.3V and GND near the module, though a legit ESP-12F already has a 10uF supply cap onboard.

    Wire it like this:

    SDIO signalRPi HATESP-12F pin / signal
    ESP-03 pin / signal
    CLK15 / GPIO2214 / SCLKFlash pin 6 (CLK)
    CMD16 / GPIO239 / CS0Flash pin 1 (/CS)
    D018 / GPIO2410 / MISOFlash pin 2 (DO)
    D122 / GPIO2513 / MOSIFlash pin 5 (DI)
    D2 (optional for 1-bit)37 / GPIO2611 / GPIO9Flash pin 7 (HOLD)
    D3 (optional for 1-bit)13 / GPIO2712 / GPIO10
    Flash pin 3 (WP)
    -1 or 17 / 3.3V8 / VCCModule 1 / VCC
    -2, 4, 14, or 20 / GND15 / GNDModule 8 / GND
    -27 / ID_SD3 / CH_PDModule 13 / CH_PD

    Note that the CH_PD signal is connected to the ID_SD signal. This must be mapped as a GPIO (GPIO0) and switched to an output and driven low then switched to an input again before the driver is loaded in order to reset the module. This will be added in the near future in the driver.

    The ESP-03 column above is for people who want to use an ESP-03 module instead. This requires soldering to the pins of the SPI flash chip for some of the signals. The SPI flash may be desoldered first, or left in place.

  • 3

    SOFTWARE

    Start with a fresh Raspbian SD image of 2016-05-10 or later.

    A network connection to the Pi is required for the initial installation for Raspbian to fetch dependencies to build the driver module. This could be the onboard Ethernet of a model B Pi, a supported USB-Ethernet or USB-WiFi adapter, or the Pi Zero connected through another PC over USB.

View all 11 instructions

Enjoy this project?

Share

Discussions

Electronoob wrote 03/02/2017 at 21:50 point

I wish I had seen this project sooner, very nice work indeed. if you still have some boards left over for sale I wouldn't mind grabbing some from you.

  Are you sure? yes | no

f.hillhouse.jr wrote 01/31/2017 at 18:23 point

Very cool project!

I have connected an ESP-12F to a RPi Zero. I have finally had success and connected to my hotspot network. Should the blue LED function on the ESP-12F? It does turn on briefly at power-up but never again.

Thanks!

  Are you sure? yes | no

ajlitt wrote 01/31/2017 at 22:16 point

The blue LED only blinks when the ESP-12F firmware is loaded.  If you look in the driver there are functions to control the LED, but they're not exposed.

  Are you sure? yes | no

Arsenijs wrote 03/13/2017 at 16:42 point

What do you mean - not exposed?

  Are you sure? yes | no

Demon wrote 10/27/2016 at 10:24 point

Will this work for other ESP8266 boards? like the ESP-05?

  Are you sure? yes | no

ajlitt wrote 10/27/2016 at 13:59 point

It depends.

To my knowledge, only the ESP-12E and ESP-12F have the 6 SPI flash pins broken out.  So on other modules you'll have to solder to the SPI flash directly.

Also some modules have some of the necessary signals hardwired, like the ESP-01 which has some of the boot mode control pins wired directly to ground.  ESP-01 and some others would need you to desolder the ESP8266 to cut the trace to the ground slug to be able to get it into SDIO mode.

Among the modules I've tried, (ESP-12F, ESP-05, ESP201) the ESP-12F seems to have the best WiFi signal quality as well.

  Are you sure? yes | no

Demon wrote 10/27/2016 at 14:55 point

I personally own the ESP-05 so I was asking to see if it is a simple remove the flash chip and solder wires on to the places where the flash chip was. I bought an antenna for my esp-05. I really hope it works with ESP-05.

  Are you sure? yes | no

ajlitt wrote 10/27/2016 at 17:42 point

Unfortunately MTDO (pin 13) of the ESP-05 is tied to the ground slug as you can see in this board stackup:

(lower edge of the chip, 5th pad from the left)  In order for SDIO mode to work you would need to cut that trace, which means desoldering the chip.

ESP-12F is typically under $3 from the usual places on eBay, so I'd recommend saving your sanity and buying another.

  Are you sure? yes | no

Demon wrote 10/27/2016 at 20:53 point

Damn 

  Are you sure? yes | no

Demon wrote 10/30/2016 at 20:31 point

I just ordered a ESP 12F so it should be coming in the mail so I have 2 questions.

1. Is there anything special I need to the ESP 12F to get this to work?

2. Do you know if this will work on Kali Linux?

  Are you sure? yes | no

ajlitt wrote 10/31/2016 at 02:38 point

1) The instructions will work for any ESP8266 module that gives access to all 6 SDIO/SPI pins and does not pull any of the 3 boot mode select pins low.

2) I don't see why it wouldn't work in Kali.  I don't know if the Debian package will work out of the box, but if it doesn't you can always grab the module sources from Github and build it by hand.

  Are you sure? yes | no

rosco wrote 10/13/2016 at 18:54 point

Great work! Where is that design in your gallery coming from? it's beautiful, Is it available somewhere?


  Are you sure? yes | no

ajlitt wrote 10/13/2016 at 20:33 point

Thanks!  TI gets credit for that funky antenna design (read through the project logs for more).  Although the gold pattern looks pretty, it should be covered in solder mask to protect it from accidental shorts.

This image is of my esp_hat v0.1 board, my first attempt at an ESP8266 and my first try at routing RF.  I did create a v0.2 to put the antenna outside the Pi's outline for a better radiation pattern and to fix the missing solder mask over the antenna, but never built any up.

Anyway, you can get Kicad and Gerber files for the board above at https://github.com/al177/esp_hat/tree/v0.1_stencil .  The v0.2 tag has the newer board.  Both sets of Gerbers are ready to be sent to OSH Park and OSH Stencils for fab if you're interested in ordering any.

  Are you sure? yes | no

rosco wrote 10/13/2016 at 22:54 point

thanks! May I ask why you abandonned the idea of an ESP chip directly on the hat and instead now making your product with an ESP-12 module ?

  Are you sure? yes | no

ajlitt wrote 10/14/2016 at 00:41 point

Putting down an ESP8266 means more components, tighter routing, and the cost of certification and testing if i wanted to productize it.

The module is easier to solder, FCC certified, and in the low volumes I'm building these cheaper than the chip plus required discretes.

Additionally it's easier for others to integrate the module into their own projects.

  Are you sure? yes | no

Frederic LE GARREC wrote 09/25/2016 at 14:57 point

Hello, i got my ESP-12F. Difficult to solder on the needed pins, they are so small! The other pins are ok but we don't need them :(   i don't understand why they did it this way... 

Anyway, my question is: how important is it for the wires between the ESP and the RPi to be as short as possible? I am modifying a R2D2 toy requiring all available GPIOs, thus needed to use a 40pin cable (old IDE drive cable, does the job perfectly) to move all pins from RPi to a new circuit. Thus, i have to solder the ESP at the end of this 10cm IDE cable + required resistors + short wires.

Summary:

RPi 40pin <=> 40pin cable (10cm long) <=> new circuit <=> resistors <=> short wire (4 cm) <=> ESP pins

If it just reduces the bandwidth, that's ok i just need to trigger some node-red webservices via the wifi to activate the toy.

Will it also create pure connectivity issue?

  Are you sure? yes | no

ajlitt wrote 09/26/2016 at 15:43 point

The SDIO signals are about 40-50MHz.  Running 10cm of wire might not cause a problem if you are careful about termination, but I wouldn't chance it.  Your best bet would be to solder the ESP-12F to the back of the GPIO header using short wires and cut the traces in the ribbon cable that the ESP is using for SDIO to eliminate those 10cm long stubs.

The ESP8089 driver doesn't deal with unexpected bus errors well.  In my experience the most common symptom of a bad connection involves the driver OOPSing or a full-out kernel panic.

  Are you sure? yes | no

Frederic LE GARREC wrote 10/01/2016 at 14:17 point

Thank you so much for your answer. Indeed, set-up failed. I see it recognized in dmesg logs and then "SD removed". I just tried with clean Jessie install. It is better now. As many other people in this forum, i get this now:

***** EAGLE DRIVER VER:bdf5087c3deb*****

[   10.766787] ESP8089 reset via GPIO 0
[   10.975433] eagle_sdio_dummy: probe of mmc1:0001:1 failed with error -110
[   11.331726] mmc1: card 0001 removed
[   11.407005] mmc1: queuing unknown CIS tuple 0x01 (3 bytes)
[   11.418999] mmc1: queuing unknown CIS tuple 0x1a (5 bytes)
[   11.423017] mmc1: queuing unknown CIS tuple 0x1b (8 bytes)
[   11.426848] mmc1: queuing unknown CIS tuple 0x80 (1 bytes)
[   11.426972] mmc1: queuing unknown CIS tuple 0x81 (1 bytes)
[   11.427097] mmc1: queuing unknown CIS tuple 0x82 (1 bytes)
[   11.427164] mmc1: new high speed SDIO card at address 0001
[   11.427850] esp_sdio_dummy_probe enter
[   11.651314] esp_sdio_init power up OK
[   24.221218] resetting event timeout
[   24.221256] esp_init_all failed: -110
[   24.221289] first error exit

Which is not good but i get this too:

sudo cat /sys/kernel/debug/mmc1/ios
clock:          50000000 Hz
actual clock:   41666666 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

Which is good i think

Now i wonder why 2 for bus width and zero for signal voltage

I am using 22 ohms resistors, so i guess i now have to try by soldering the chip much closer to gpio than now as i am behind my IDE cable

  Are you sure? yes | no

ajlitt wrote 10/01/2016 at 18:31 point

The "first error exit" is often due to flaky SDIO connections.  Even though the mmc is reporting the link status as "up" it might not be stable enough to complete loading the firmware to the module.

  Are you sure? yes | no

Frederic LE GARREC wrote 10/22/2016 at 19:16 point

Hi, i managed to make it work, but i needed to start from fresh install with Jessie from end of May. Did not work on more a recent one. Now, i have low speed issue, and i think it is due to my long wiring. I will try with shorter one. Thx for your help.

  Are you sure? yes | no

ajlitt wrote 10/25/2016 at 23:53 point

Hey Frederic, I just did a fresh install with the updated 2016-09-23-raspbian-jessie-lite image and had no troubles getting the module to build and work.

  Are you sure? yes | no

Frederic LE GARREC wrote 10/27/2016 at 20:08 point

Ok... not fair :) I will thus try to get better speed with shorter wiring, and if successful i will try again on recent raspbian. Thx.

  Are you sure? yes | no

Cortburris wrote 09/13/2016 at 16:15 point

will there be an update now that the ESP32 is out?

  Are you sure? yes | no

ajlitt wrote 09/13/2016 at 17:36 point

I don't think there's an equivalent Linux driver for ESP32, so there's not much that I can do for that module.

  Are you sure? yes | no

BJ Black wrote 09/01/2016 at 10:04 point

Just got it working tonight with my Pi Zero and ESP-12F.  A few notes:

0. Man my soldering has gotten better.  Only minor casualties this time ;-)

1. I used kpartx and loopback-mounted the Raspbian image (and copied in qemu-user-static) to get build-essential, network-manager, dkms, and the deb installed via chroot.  Plus the fresher kernel and headers.  Then tossed it onto a fresh sd...  Much faster than trying to do all that on the pi itself.

2. Also used gwc2 + g_ether to use OTG for ssh'ing into my Pi (see https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadget).  IMHO, the only way to do this kind of dev :-)

3. I soldered the 33Ω resistors to the pi directly, then used cut jumper wires to the interconnect.  Surprisingly clean.  See https://picsart.com/i/210420138008201

4. Most convenient place to mount it was on top of the microsd slot with a cut-up 3M Command strip.

5. /sys/bus/sdio/* looks much better after the esp driver loads :-)

6. nmcli is easy enough to set up connections from the command line using NetworkManager (e.g. "nmcli dev wifi con 'myssid' password 'myssidpassword'").  On Raspbian, this'll require removing a few WLAN* entries from /etc/network/interfaces, though...

This first attempt will be an internet radio for my friend in the hospital (once I hook up the backup PWM pin to a filter+amp and a tiny speaker).  The trick will be to put in a monitor program to click the hospital WiFi captive portal's "I Accept" thingy automagically as needed...

Good luck to others trying this out.  It works great it you stick it out :-)

  Are you sure? yes | no

ajlitt wrote 09/13/2016 at 17:40 point

Nice job!  Keeping the USB open for gadget purposes was one of my main motivators on this project.  I'm still waiting for someone to make a pihole-on-a-stick with this setup.

  Are you sure? yes | no

Frederic LE GARREC wrote 08/13/2016 at 16:56 point

Hello, i ordered a ESP-12F to try this out. Your hack will save my project, as i am blocked from using a webcam on the pi zero while having wifi via usb. Anyway, you recommend 33 ohms resistors, and indicated you tried up to 200 ohms ones. I have only 22 ohms and 100 ohms and would like to avoid ordering new ones. Would the 22 ohms work?

  Are you sure? yes | no

ajlitt wrote 08/13/2016 at 16:59 point

22 ohm resistors will probably work well

  Are you sure? yes | no

mincepi wrote 08/03/2016 at 21:24 point

Thanks so much for your hard work. I was able to remix your project and optimize for low cost and small size: https://hackaday.io/project/12980-pi2wifi

One nitpick though: you can only use GPIOs for the reset signal that have default pullups, unless you modify the overlay to set a pullup. Your code outputs a zero, waits, and releases the GPIO, relying on the pullup to pull the reset line high. To fix this, you would have to output a 1, and not release the GPIO until module unload.

  Are you sure? yes | no

ajlitt wrote 08/03/2016 at 21:35 point

I like your minimalist approach.

The ESP has a pullup on the CH_PD signal, so there's none needed on the Pi end.

  Are you sure? yes | no

mincepi wrote 08/03/2016 at 23:10 point

The GPIO I selected was 19 (for routing reasons), and it has a pulldown by default, about 68K in value. Any idea what the value of the pullup is on the ESP?

  Are you sure? yes | no

ajlitt wrote 09/19/2016 at 18:31 point

I know it's over a month later, but I have some more insight into this.

ESP8266 is supposed to have some sort of pullup on CH_PD.  However it doesn't seem to be consistent.  I was working through the few boards in the WiFi Pants bone pile, trying to debug the ones where the ESP seems dead.  I noticed that CH_PD was hovering well below 3.3V when the Pi's GPIO (ID_SD) is tristate.  Forcing ID_SD high caused 2 of my 3 boards with failed ESPs to come to life.

Fortunately there's a spot between 3.3V and CH_PD nets that fits an 0603 3.9K resistor that seems to permanently fix these boards.  I'm not putting these into my inventory, but it's nice to have a couple more B-stock boards so that I can play with them.

  Are you sure? yes | no

OSH Lab wrote 05/24/2016 at 23:39 point

I forked the driver, updated it for the current 4.4.x kernel, and made a simple install script that builds the source with the driver and adds a startup script to run on boot that activates the module. If anyone wants a simplified instillation, you can get it here. http://oshlab.com/esp8266-raspberry-pi-gpio-wifi/

  Are you sure? yes | no

ajlitt wrote 05/25/2016 at 14:50 point

Looks good

You might want to add a step to install git first since it wasn't in Raspbian by default last I checked.  Alternatively you could tar up your release and add it as a project release in github and instruct users to use wget to grab from your releases page.

  Are you sure? yes | no

OSH Lab wrote 05/25/2016 at 15:16 point

Git comes with the latest full version of Raspbian, at least it seem so for me, but I have not tried it with Raspbian lite. I'll add it just in case. I would like to eventually make an image that I has the driver and perhaps symlinks the wpa_supplicant.conf to the boot portion of the image. That way, one could just install the image and add their wifi credentials, even from a windows pc, to the fat32 portion and connect to wifi so they can ssh in without having to hook it up to a network to install the wifi driver. I also really like the Linux gadgets on the usb port. I have been using it as a serial device. Of course, this makes it so you cannot use the usb port. (on the pi zero).

  Are you sure? yes | no

Peter W. Borders wrote 05/14/2016 at 18:59 point

Since this is also applicable to a full sized sd card slot has anyone tried using a Toshiba FLashAIr card? That is a combination storage and wifi card made for cameras. I know that someone got it working with a 3d printer control board that had an sd slot.

Also, did these boards ever go into production?

Pete

  Are you sure? yes | no

ajlitt wrote 05/16/2016 at 01:55 point

I don't see why not.

Like USB, Linux abstracts the host interface for SDIO so that the platform is irrelevant.  So if there's a FlashAir SDIO card driver for Linux then it should work.

The first batch of boards has been sitting on my shelf, ready to package up and put in the mail.  Storefront and documentation are still not done, so that's the holdup.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 05/16/2016 at 15:47 point

Have you considered Tindie?  It's been great for selling my #LiFePO4wered/USB, I think I've had many more sales than if I had tried to sell on my own website.

  Are you sure? yes | no

ajlitt wrote 05/25/2016 at 14:55 point

@Patrick Van Oosterwijck: I've been planning to sell on Tindie for a few months, I just haven't finished the rest of the collateral I want to go along with this product.

  Are you sure? yes | no

Armin wrote 04/22/2016 at 20:30 point

I nice project. I even liked it enough to use this idea in one of my own project (TimeArc).

I do have a question. You get the power for the ESP12-f from the +3.3V  of the raspberry pi zero. Is the power supply strong enough for this? Is it reliable? I am not sure how much the raspberry pi zero can deliver but I know the esp12-f can draw large peak currents.

Thanks!

  Are you sure? yes | no

ajlitt wrote 04/23/2016 at 04:21 point

Thanks!

The Zero has a buck mode switcher for 3.3V which should be good to about 1A.  Unlike the B+, the Zero does not need to power the USB hub/Ethernet combo chip from 3.3V, so there is additional margin to power external devices.  In addition, there's a 10uF cap on the WiFi Pants board and another inside the ESP-12F module to help with load spikes.

  Are you sure? yes | no

Jason Hermans wrote 04/13/2016 at 08:32 point

I believe you are going to get a lot of competition from this Kickstarter project https://www.kickstarter.com/projects/1991736672/iot-hat-for-raspberry-pi-a-must-have-for-pi-zero

  Are you sure? yes | no

ajlitt wrote 04/13/2016 at 13:39 point

Thanks for the heads-up.  I'm not worried about competition.  In fact I've wondered what took them so long.

For as well as the ESP8266 works as an SDIO WiFi adapter, it is still kind of a pain to use with the Pi.  The RedBearLabs board doesn't need a special driver compiled, and doesn't need an explicit reset after power-up.  They're also experienced in making and selling RF gadgets (I have one of their BLE Nano kits and really like it), and they have their supply chain, distribution, and manufacturing problems solved.

Meanwhile I have my test jig finished, and will bake my first production batch of boards tonight.  I think I'll be able to have a storefront up and boards to sell by the end of the month.  If you don't want to wait 'til their Kickstarter delivers in July or August, or if you want the 5V 2A boost converter, WiFi Pants might be for you.

  Are you sure? yes | no

Gijs van der Meijde wrote 04/05/2016 at 14:36 point

i actually have no experience with this whatsoever, i thought i could just hookup the sd card to the gpio of the raspberry, install a driver and see the SD card in my filesystem. But i dont know how to wire the sd card

  Are you sure? yes | no

davedarko wrote 04/05/2016 at 14:41 point

Ohh, you mean that way! Sorry, no idea. Just buying a usb SD card reader is not an option? they're so cheap...

  Are you sure? yes | no

Gijs van der Meijde wrote 04/05/2016 at 14:42 point

unfortunately, this is what everyone sais. But its not an option. I really need to read the SD via the GPIO

  Are you sure? yes | no

ajlitt wrote 04/05/2016 at 15:12 point

It should be relatively easy.

You should be able to follow the hardware instructions on this project, replacing the ESP-12F with a SD or microSD socket and wiring like-named SD_* pins on the socket to the Pi, and skip all the esp8089 driver stuff.  

Follow step 5 in the instructions, but replace "sdio" with "sdhost".  That should be all the software setup you need.  The SD card should appear as /dev/mmcblk1 if it works.

  Are you sure? yes | no

Gijs van der Meijde wrote 04/06/2016 at 07:27 point

Sounds perfect. One more question (i hope) a SD card does not have GPIO 9 and 10. I dont have to wire those at all then ?

  Are you sure? yes | no

ajlitt wrote 04/06/2016 at 21:15 point

@Gijs van der Meijde : ignore the "ESP*" columns, and use the "SDIO signal" column...

GPIO9 and GPIO10 on the ESP8266 are shared with the SD D2 and D3 signals of the SDIO interface, and you definitely want those for your SD card.

  Are you sure? yes | no

Gijs van der Meijde wrote 04/05/2016 at 14:26 point

Can anyone please tell me how to hookup an SD card to the SDIO pins. I just want to read/write a second SD card using the GPIO pins and i believe this device is capable of doing so. Unfortunately i cannot see how it works.

  Are you sure? yes | no

davedarko wrote 04/05/2016 at 14:31 point

Have you tried using the chip select on the sd cards for using them on the HSPI? or do you want to start the ESP from the SD card?

  Are you sure? yes | no

jarocks wrote 04/06/2016 at 20:13 point

You need an adapter which breaks out all the pins of the SDIO Bus (like this: https://www.sparkfun.com/products/12941).

I also have a couple extra SD Adapter boards from a project I was working on. If you were looking for something premade. 

  Are you sure? yes | no

davedarko wrote 03/29/2016 at 06:13 point

have you (or one of your followers) seen the pimoroni ESP hat yet? It seems like they use the serial connection for connection though.

  Are you sure? yes | no

ajlitt wrote 03/29/2016 at 07:35 point

Yes I have.  As they say on the page, it's an ESP8266 experimentation platform and not for use as a NIC.

It looks like it came out in late November, about the time the Zero was released and when I started working on this.

  Are you sure? yes | no

turne327 wrote 03/21/2016 at 16:49 point

Have you evaluated the antenna on this design? It looks like a copy/paste from Texas Instruments. Since your application differs from the TI reference design, it is likely that the antenna performance has changed or possibly tuned off of frequency.  If you provide me with a prototype board, I would be happy to impedance match and optimize the antenna for this project. 

  Are you sure? yes | no

ajlitt wrote 03/21/2016 at 16:54 point

Thanks for the offer!  The version with the TI appnote antenna has not been characterized since I ended up replacing the ESP8266 chip and support components with an FCC certified module with a built-in antenna.  Qualitatively my implementation of the antenna seems to work well, but I wouldn't be surprised if it needs adjustment.  I don't plan to make any more of that variety so I haven't planned to do proprer testing.

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 02:02 point

I must be doing something wrong... :)

I get this in syslog on the pi... (see below)  my esp8266 is an AI-THINKER version...  not sure how to tell much beyond that without pulling off the cover...

it pretty clearly looks like the module either doesn't initialize or it's putting garbage out...

it would be wonderful if one of you had an idea and pointed me in the right direction..

245.349490] mmc-bcm2835 20300000.mmc: no support for card's volts
[  245.349514] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.349552] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.349576] mmc1: error -22 whilst initialising MMC card
[  245.393883] mmc1: Controller never released inhibit bit(s).
[  245.409294] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.409328] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.420365] mmc1: Controller never released inhibit bit(s).


  Are you sure? yes | no

jacksonliam wrote 03/19/2016 at 13:03 point

I've seen this. try either unloading the driver (modprobe -r esp8089) and trigger a reset of the esp8266 or completely remove power from the Pi and module for a few seconds.

Also make sure the hardware connections are correct. Only the CS and clock pins need to be correct for the mmc driver to load.

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 16:24 point

I'm using a NodeMCU esp-12 dev kit breakout board which seems to have the right pins broken out.    I reverified pinout, but i'm still getting the same results.     the driver itself doesn't ever seem to load.

I don't need to flash anything specific onto the esp12 right?  the driver will take care of loading the right firmware.

  Are you sure? yes | no

jacksonliam wrote 03/19/2016 at 16:44 point

Which pins does the NodeMCU have pulled up/down by default? The ESP8266 needs to boot in SDIO mode but the NodeMCU probably has it hardwired to boot from the flash (GPIO15 pulled down IIRC). 

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 17:46 point

thanks for the pullup/down comment.  it seems obvious now that you say it... time to pull the 8266 off the board...

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 19:43 point

and... it works...   it doesn't often work upon boot, but a quick reset makes it work just fine...  recommendations on how to make it work on bootup?

  Are you sure? yes | no

ajlitt wrote 03/21/2016 at 16:57 point

What are you doing with CH_PD?  It should be pulsed low after power-up (or before loading the driver) to cause the chip to reset and kept high otherwise.

  Are you sure? yes | no

txdo.msk wrote 03/02/2016 at 22:45 point

agreed.  ajlitt, I want that board!  Good job, dude!

  Are you sure? yes | no

gir wrote 03/02/2016 at 17:18 point

Well deserved winner! congratulations. my project wouldn't be the same without yours!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates