Bridging ISM radio and wifi for lunch money

The ESP8266 has taken the maker community by storm and the hype is well deserved. Before the ESP we had the HopeRF ISM radio RFM12 and its successor RFM69. So is the ESP8266 an RFM69 killer? I would say no. Hell no even 🙂 The RFM69 is still very well suited for certain applications and the ESP8266 will not run for 2+ years on a set of AA batteries. The two can however play nicely together as a low cost ISM/wifi bridge. I did a custom PCB for this in the shape of a somewhat large USB stick, dubbed “Espism”.

 

Currently it works as an ISM sniffer posting the received packets on the MQTT topic espism-<macaddr>. Packets are posted in hex followed by the RSSI value:

espism-5ccf7f147cd Hello from 172.16.3.120
espism-5ccf7f147cd 016340630001000000c375b642[-27]
espism-5ccf7f147cd 630180[-57]

A set of four LEDs indicate received packets. Well three LEDs as I made a mistake on the ground plane. The MQTT server IP and RFM69 network information is hard coded into the binary.

I ported Andreas Heßling’s STM32 RFM driver to the lovely ESP Open RTOS, my swiss army knife for ESP8266 development. The type-A right angle 90 degreee USB connector and 3x6x2.5mm push button can be found for little money on eBay. The push button currently serves no purpose but the plan is to perform a “master reset” of the device using this button. The rest of the BOM consists of 0603 resistors and capacitors, an LM1117 3.3V regulator and a SOT23 P-mosfet for driving the 0603 LEDs. Oh, and the ESP12F talking to an RFM69CW. The BOM should add up to about the price of lunch.

Code and schematics on Github as always.

13 thoughts on “Bridging ISM radio and wifi for lunch money

  1. Pingback: Two Great Radios Taste Great Together | Hackaday

  2. Pingback: Two Great Radios Taste Great Together | BH

  3. Pingback: Bridging ISM radio and wifi for lunch money - Electronics-Lab

  4. Pingback: RFM69 WIFI Gateway | Tinkerman

  5. emmanuel

    Great work there.

    I’ve installed ESP Open RTOS.
    Everything is OK, the /esp-open-rtos/examples/mqtt_client is working fine.

    However, when I compile the mqtt_sniffer, I’ve got error messages such as :

    john@linux:~/espism/mqtt_sniffer$ make
    CC /home/john/espism/mqtt_sniffer/mqtt_sniffer.c
    /home/john/espism/mqtt_sniffer/mqtt_sniffer.c:205:26: error: unknown type name ‘MQTTClient’
    static bool mqtt_publish(MQTTClient client, char *topic, char *message)

    /home/john/espism/mqtt_sniffer/mqtt_sniffer.c: In function ‘mqtt_task’:
    /home/john/espism/mqtt_sniffer/mqtt_sniffer.c:224:20: error: storage size of ‘network’ isn’t known
    struct Network network;

    I think I’m missing something obsvious there.

    Any clue ?

    Cheers.

      1. emmanuel

        Changes are done.
        Working like a charm !

        At a first look, using ESP Open RTOS seems adressing my initial concern : I was initially using Arduino framework. As mqtt_send seems to be blocking & my broker in on the Internet, I was loosing incoming RFM69 packets.
        Now I’m not loosing anymore packet.
        However, this improvement could be also the result of a today better internet connexion / latency (vs yesterday)

        In not really familiar with RTOS : but looking at the code (task, queue, etc), I can imagine the send_mqtt non blocking.
        Is this correct ?

        From the code I did increase #define PUB_QUEUE_DEPTH (10), as initially I got some Publish queue overflow.

        I tried to create a pull request, wihtout chance (I need to understand why). Mean time could I sent you the changes/file by email ?

        Cheers.

        1. Johan

          Nice! I have pushed an update to Github. Which send_mqtt do you mean? There should be no lost packets as there is one task, rx_task, that receives RFM data and pushes the packets to a queue that is handled by mqtt_task. Please note the implementation lacks a few things, eg. rfm69_receive is called in a busy loop. Ideally, the rx_task should block on a semaphore signaled from an interrupt handler when the RFM69 receives a packet. Always room for improvement 🙂

          1. emmanuel

            >Which send_mqtt do you mean?
            I’m refering to my initial trial with ESP+Arduino Framework (with PubSub lib). I was loosing packet.

            This is why I’ve switched to ESP Open RTOS. As you said there should be no lost packets.

          2. Johan

            Ahaa, I see. I thought you had found an issue in my code. If you do, feel free to create a ticket on GitHub. The current setup is fast enough to capture the ACKs from the gateway which is useful.

Leave a Comment

Your email address will not be published.

*
*