Another Radio Module For IoT Fun – EMW3162

The availability of cheap radio modules is making them ubiquitous in an increasing number of projects that we have been seeing recently. The usual go-to solution is using any one of the several modules based on the ESP8266 device. [Willem] wrote in to share with us his experiences with another radio module – the EMW3162 from MXChip, which at $10 isn’t as cheap as the ESP8266 modules, but is a more capable, power packed, device.

The EMW3162 (PDF datasheet) is a low-power embedded WiFi module with integrated wireless LAN, and a STM32F205 Cortex-M3 microcontroller that runs a “self-hosted” WiFi networking library and software application stack. The microcontroller has 1M flash, 128k RAM and runs at 120MHz. And since MXChip is a Broadcom partner, they are allowed to use the WICED_SDK.

The on-board ARM M3 means all kinds of useful interfaces are available: UART, SPI, I2C, ADC, DAC, PWM, TIMERS, GPIO, and a JTAG flash interface. The good news could be on the power consumption figures – the module is touted to be low-power, and the data sheet shows 7mA when connected to an access point but with no data transfer. When transmitting at 20kbps, the current draw is about 24mA, which goes up to 320mA at 11Mbps.

[Willem] has his EMW3162_WICED repository up on Github, but also take a look at the MXChips MICO (Mico-controller based Internet Connectivity Operation System) repository. At the moment, he has it working using Linux, with a gnu gcc compiler and a JLINK JTAG programmer. He also has the WICED SDK working and has a WiFi AP with an on-board 120MHz arm chip. It would be interesting to hear about other users’ experiences with this radio module. Do let us know in the comments below!

 

24 thoughts on “Another Radio Module For IoT Fun – EMW3162

  1. I have one forgotten in my parts bin for quite a few months now. I did not pay any attention to it since I started to use the ESP8266.
    This one is a lot more tailored towards low power, battery operated things, the ESP not so much.
    With a non-obscure and powerful, yet reasonable low power micro, i could see this as a replacement in most of my projects where I still use a separate micro.

  2. for remote sensors I would rather have something with a 900mhz link. It should carry farther and use less power than wifi. Of course a emw3162 or ESP8266 could be used as a bridge between a 900mhz network and wifi with no problem.
    You just do not need the speed of wifi for a garage door or thermostat.

    1. That is absolutely true, plus wifi will have a lot of overhead compared to some dedicated protocol.
      But let’s not forget the attractiveness of this: it works with something already in your house. If this thing can really sleep and be woken up by a pin change within 8uA (ESP needs 310u for this) than you can actually build a garage door sensor with a battery life of years from AAs. There is no more need for a gateway, which people would perceive as more complicated, and it is a lower entry price point.
      Now, if you start monitoring things that change faster and more often, you will have trouble getting good life out of wifi sensors.

      1. the TI CC1101 is very popular, also available in modules on ebay. Alternative modules that are popular, from hope: RFM12 was very appreciated and now the newer RFM69 kind of brings the best of sub ghz. I think at hobby level there is nothing as popular as the 2.4GHz NRF24l01 (mostly clones).

        1. Thanks for the +1 guys!
          IMHO if WiFi were really so great for IoT, The Moteino Framework would run on WiFi. However weighing all the requirements of wireless control and actuation, WiFi quickly is out of the question.

  3. Ooh. I would probably want wifi turned off most of the time, but having a real processor with all the peripheral stuff would be sweet. It makes me think a little of a next-generation Synapse module — I wonder if you could port MicroPython or something similar to it.

  4. If the power specs for the EMW3162 are correct (the PDF link is broken) it will be a good choice. – Not sure what 20Kbps actually means on a wifi module, but I will check it out anyway.

    The ESP8266 has a few problems for battery operated devices (as I’ve discovered in my hack-a-day project)

    Firstly the crazy initial start up current which is only for a few milliseconds but can be 300mA+ and cause brown-outs on itself or other parts of the circuit if your not careful with PSU and battery design.

    Secondly it says in the ESP8266 spec (and still does as of march 2015) that it can wake up and send a packet in 2mS, which is clearly crap as the best I’ve ever seen anyone achieve even since V0.95 firmware (when the power management API was properly enabled) is 2 seconds, I can just get under 5 seconds for power-on ->send ->receive -> power off which is just tolerable on my hand-held device.

    Dont get me wrong, for $3 the ESP8266 its still a bargain, especially if not running on batteries, but as mentioned before for low data rate/battery use it is best using sub Ghz which can wake up and send in a few milliseconds. The only difference is you will need some sort of broker program if you need to interface it/isolate it from the internet . +1 for the RFM69 in this regard as they can be had for $5 if you look hard enough

    I’m going to be experimenting with the new LORA modules as soon as they arrive these can achieve super-low power or long range (miles not meters) again more expensive than the ESP8266, I paid $8 per module.

    Lots of good stuff on this if you trawl google.

    1. With whatever factory firmware they came I could do less than a second from power on till reading the website counter, with this little experiment: http://www.electrobob.com/esp8266-tests/
      With some limitations: the thing had to have been shutdown for short enough time that the router did not de-allocate the IP(i am not sure static helps) and 2: the firmware was using delays(no interpretation of response except final number) and I shrank everything as much as possible. Of couse, it did not work all the time.
      I think the 2ms is for one of the standby modes, where the module was previously connected to the AP and then put to standby, while it remembers the config. I have not tried this.

      What LORA are you using?

      1. With static IP I can get it down to 3 seconds but the network admin at the site I intend to use them wont allow this :-( Maybe I should try a few different versions of the firmware as 1 second would be sweet!

        The LORA modules are the Dorji DRF1278 modules which are 17mm square and which use the SX1278 chip. I also have the DRF1278DM which use the same chip and a serial interface which I will try and get working as the server node.

        I’m guessing LORA will be my project for the Mark 2 version of my terminal – After I get the mark 1 running 100% of course.

        Nice little project by the way.

        1. Thanks! Speaking of it, it seems i never updated with the results: it managed 800+ hours without losing internet connection. I shut it down during the winter holidays, so it could have gone more.

          I like the DRF1278 module, nice sensitivity compared to RFM69.

    2. To add to above now the link is fixed. The power requirements seem no different to the ESP8266, averages are quoted but peaks are same as ESP module.

      WiFi is not really the best way to go for IOT IMHO :-)

      1. The power requirements are really different than the ESP. Here are a few highlights:
        -it can consume just 8uA while being awaken by RTC or pin change. The ESP needs 70uA to be awaken by RTC and 300uA if you want to wake up on pin change. That is huge.
        -it has duty cycled RX, consuming just 7mA, while the ESP needs to be in full on RX with 90mA all the time.

        I think wifi is the best for any IOT that is not battery powered and it is sometimes a reasonable solution for battery powered stuff.

Leave a Reply to lwatcdr (@lwatcdr)Cancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.