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.
Pingback: Two Great Radios Taste Great Together | Hackaday
Pingback: Two Great Radios Taste Great Together | BH
What’s your data rate?
Good question, I haven’t checked but that should be either in the RFM data sheet or in the register settings.
You may be able to use iPerf3 as well to determine the actual rate and also get see if it’s changing.
Pingback: Bridging ISM radio and wifi for lunch money - Electronics-Lab
Pingback: RFM69 WIFI Gateway | Tinkerman
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.
Thanks! I had actually forgotten that the MQTT related functions in ESP Open RTOS have been renamed. Eg MQTTClient is now called mqtt_client, please refer to https://github.com/SuperHouse/esp-open-rtos/blob/master/extras/paho_mqtt_c/MQTTClient.h
I will fix the naming in my repo when I find the time. Feel free to change yourself and create a pull request 🙂
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.
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 🙂
>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.
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.