Hope RFM12B Wireless Module to RFM69W/HW Upgrade Path
Thanks to a post from John Beale on this forum, became aware of the recent work of LowPowerLab’s Felix Rusu.
After visiting Felix’s site and reading of his escapades in using the Hope RFM69W Wireless module and the
Arduino library he had written, I thought there would probabaly be some interest in cobbling a bit of generic
hardware together, that would enable an Arduino clone etc. to be retrofitted/upgraded from a RFM12B to RFM69W/HW.
The most obvious difference between the modules is that the RFM69W/HW is a 16 pin device while the RFM12B is a
14 pin module, so the module footprint difference is pretty minimal. 2mm headers have been used in the design
again, so as to not have to deal with possible module damage, if the modules require desoldering at some stage.
Have a read of the Hope RFM69W/HW datasheet, to read about the enhancements it offers.
Am attaching the Eagle files and a couple of photos of the Arduino footprint RFM69W/HW pcb.
|Hope RFM modules.jpg (267 KB) Hope RFM modules.jpg||RFM12B and RFM69H/HW module pcb|
|RFM69HW v1.0.sch (308 KB) RFM69HW v1.0.sch||RFM69H/HW eagle schematic|
|RFM69HW v1.0.brd (457 KB) RFM69HW v1.0.brd||RFM69H/HW eagle board|
|Img_3944b.jpg (320 KB) Img_3944b.jpg||RFM12B and RFM69HW modules on pcb|
|Img_3941b.jpg (208 KB) Img_3941b.jpg||RFM69HW module on pcb|
When you attached the helical antenna, was the PCB trace to the SMA connector actually disconnected? If not, it will act as a stub radiator in parallel with the desired antenna and unfortunately upset the tuning.
Thanks for the comment, very valid point. Desoldered the 0.1 inch header pin and removed it from the top-side of Moteino R4
board, then soldered the the helical antenna in it’s place but obviously on the bottom-side of the Moteino R4 board. Then
just plugged Moteino R4 board back into RFM69HW v1.0 board. Please see previous post, " while the wire coil antenna attached
directly to Moteino ANT pad and physically isolated from the 2cm run ". Am really looking forward to see how john k2ox goes
with his announcement of his intention to work on a patch antenna design, over at the LowPowerLab community.
Happy New Year
“Anyway, don’t be surprised to see a v1.1, anytime soon.” This is a quote from a previous post and it’s just popped into reality…
no, nothing to do with virtual particles!
Redesigned and rebuilt the v1.1 after not being too happy with the v1.0 attempt. Contrary to what I said earlier, decided to stay with that very small SC70 LTC3525-3.3 chip, as it has great energy harvesting capabilities. I really wanted to run this thing from 1xAA NiMH, 1.2V battery and have it trickle-charged by a 2V photovoltiac cell. Also added that BSH203, high side series PFET and a 1N4148 diode. The FET is used to turn the wireless module on and off, as the module can stall the MCU if the ramp-up voltage is too low, due to heavy current draw from the wireless module. Diode added so BSH203 is turned on when flashing the MCU. Thanks to jcw of JeeLabs for this little bit of magic.
Didn’t want to cut tracks on the Moteino R4 pcb to implement this, so ended up just running a wire from the FET drain to the RFM69HW 3.3V pad(pin 8) and removing that header pin from the socketed wireless module. If you don’t want to socket the wireless module and just solder it directly to the Moteino R4 pcb, once again attach the FET drain wire to the RFM69HW 3.3V pad but make sure you add an insulator, some electrical tape or the like, before soldering.
In the v1.0 design, only brought-out six pins to the pcb pin-header but in v1.1, thought why not bring out the extra two the MCU package gives you. Remember that A6 and A7 are analogue pins ONLY! and can’t be used for general I/O.
The Brown-out detection voltage for the Moteino R4 efuse, 2.7V default (0xFD / 0x05) had to be changed to 1.8V (0xFE / 0x06), as when measuring the Vcc, saw it drop to as low as 2.2 volts on occasions.
Have tested this unit successfully today, running from a single 1.2V NiMH battery, with a DHT22 relative humidity/temperature sensor and a Cadmium Sulphide LDR to measure the di-urnal light level. The NiMH battery boosted output voltage is also logged.
Am attaching the Eagle files for the v1.1 pcb, several photos of the project, the “tested” Arduino .ino and a time-stamped screen-dump of data.
Hope this information will be of help to others who might be considering or working on a similar project.
|Moteino BOOST v1.1sch.zip (62.8 KB) Moteino BOOST v1.1sch.zip||eagle schematic|
|Moteino BOOST v1.1brd.zip (16.9 KB) Moteino BOOST v1.1brd.zip||eagle pcb|
|Moteino_DHT22e1_05012014.zip (1.94 KB) Moteino_DHT22e1_05012014.zip||arduino sketch|
|DHT22LDR test 05012014.zip (50.8 KB) DHT22LDR test 05012014.zip||screen capture|
|Img_4218a.zip (357 KB) Img_4218a.zip||v1.1 pcb bottom side|
|Img_4226a.zip (232 KB) Img_4226a.zip||base station Kit Ten/RFM69HW and SD/RTC shields|
|Img_4229a.zip (285 KB) Img_4229a.zip||Moteino R4, pinheader and red 3.3V wire clearly visible|
|Img_4235a.zip (265 KB) Img_4235a.zip||better view of red 3.3V wire|
|Img_4228a.zip (539 KB) Img_4228a.zip||R4 with RH-temp/LDR/batt/pv attached|
Thanx for the update plutonomore!
Is there any reason to use the rather expensive LTC3525 instead of the cheaper (€1-€2) TPS61200 or even cheaper (€0,50) MPC1640 series boost converters?
Had a look at the spec sheets for both the Texas Instruments, TPS61200 and the Microchip, MCP1640.
The SOT23 package for the MCP1640 and an Element 14 price of around AUS \$0.635, in ten off quantities
looks pretty attractive to me. Two extra resistors required for 5V/3.3V output selection but will
have to buy some of these chips with my next order and try them out … thanks for the tip Of
course, if successful this will probably mean yet another version of the Moteino BOOST board.
Previous post contained a sketch for the DHT22 temperature/humidity sensor. Attached is a zipped sketch
for the DS18B20 temperature sensor,(maximum of four) when connected to the Moteino R4 and RFM69HW.
Since you were good enough to put me on to the Microchip MCP1640 Boost Regulator, you might find the
following of some interest. Just finished testing the Moteino Boost v1.2. This uses the MCP1640 chip
(AUS \$0.64) as opposed to the LTC3525-3.3 chip (AUS \$7.19) … massive price difference and the MCP1640
is a SOT23-6(yes, small) compared to the LTC3525 SC70-6(even smaller) package. Had to cram a couple of
extra resistors on to the pcb but cost savings worth the effort. Also the 3.3V (BSH203 source) supply
to the Hope RFM69HW module has been re-worked from previous version.
Am attaching the Eagle schematic and pcb files, some photos of the completed board and another tested
sketch for a Moteino R4 with DHT22 temperature/humidity sensor, LDR and battery level monitor. This
sketch drops using the D9 LED for visual indication.
Finally happy with this ATMEGA328P/RFM69HW combination and will deploy it as a replacement for it’s “quirky”
ATTINY84V/RFM12B predecessor. Hope those contemplating a similar project will find this helpful.
|Moteino BOOST v1.2 sch.zip (54.9 KB) Moteino BOOST v1.2 sch.zip||Eagle schematic|
|Moteino BOOST v1.2 brd.zip (14.5 KB) Moteino BOOST v1.2 brd.zip||Eagle board|
|Img_4251a.zip (247 KB) Img_4251a.zip||pcb top|
|Img_4252a.zip (313 KB) Img_4252a.zip||pcb bottom|
|Img_4256a.zip (328 KB) Img_4256a.zip||pcb/Moteino R4/Hope RFM69HW|
|Moteino_DHT22e1_10012014.zip (2.14 KB) Moteino_DHT22e1_10012014.zip||"tested" DHT22/LDR/Battery monitor sketch|
|Img_4256a.jpg (337 KB) Img_4256a.jpg|
|img_4256a_M.jpg (75.3 KB) img_4256a_M.jpg|
Nice work plutonomore! Glad this one works too!
Do you see any range improvements compared to the RFM12B?
From my personal experience with the RFM12B units, I was having difficulty with lost signal at certain areas in our three
storey, ferro-concrete townhouse. Since I have been using the RFM69HW at full power, all areas in our townhouse get good
signal coverage. Please note, I realise there are many variables which determine wireless signal coverage and every situation
is unique, so I can only make comment concerning my own situation. The RSSI feature of the RFM69’s is really handy for
determining the best positioning and orientation for the sensor nodes, with the RFM12B, you were left guessing. Am attaching
a link which details some other’s experience with the RFM69’s, which you might find of interest.
Nice range improvemenst for the HW version. The W will have less range of course, but still better - as I understand - then the RFM12b.
I guess the JeeNode will have the CW version?
Have decided on a final design for a Moteino R4 (Atmega328P)/RFM69HW sensor node. Just finished testing latest and final iteration
of this thing. Have called this board, Moteino Shield v1.0. After fiddling with previous designs incorporating boost regulators
decided to keep things really simple and just use a 9 Volt battery to drive this thing. For my application this approach seems to be
the best option and minimises both parts and complexity. This design provides a standard Moteino R4 with a reset button, an ICSP
connector, a SMA aerial adapter, an eight analogue channel edge connector and a resistive divider to measure the battery voltage.
The resistive divider is configured by jumper (JP3) to either be grounded or pulled low by PD7 (digital pin 7).
The test sensor unit collects and wirelessly transmits five channels of analogue data to a central gateway receiver. The data in the test
unit consists of the Vcc, battery voltage, LDR (di-urnal light trace), DHT22 temperature and relative humdity. Please see the screen dump
attachment. Have included a few pictures, Eagle files, timestamped screen capture and a “tested” demo sketch.
Once again, hope this information is of help to others, who might be contemplating attempting a similar project.
|fig(i).zip (167 KB) fig(i).zip||pcb top view|
|fig(ii).zip (226 KB) fig(ii).zip||pcb bottom view|
|fig(iii).zip (408 KB) fig(iii).zip||completed sensor assembly|
|fig(iv).zip (28.5 KB) fig(iv).zip||eagle schematic|
|fig(v).zip (12.5 KB) fig(v).zip||eagle board|
|fig(vi).zip (25.3 KB) fig(vi).zip||timestamped screen capture|
|fig(vii).zip (1.95 KB) fig(vii).zip||remote sensor demo sketch|
|Img_4282a.jpg (168 KB) Img_4282a.jpg|
|Img_4282Ma.jpg (49 KB) Img_4282Ma.jpg|
|Img_4282Ma.jpg (49 KB) Img_4282Ma.jpg|
|Img_4282Ma.jpg (8.43 KB) Img_4282Ma.jpg|
You achieve amazing stuff with home etched boards. I wonder how many members you have in your RFMxx family?
> You achieve amazing stuff with home etched boards. I wonder how many members you have in your RFMxx family?
You almost caught me again. I was flabbergasted reading the notification mail, then read the message on this board, and thought I lost my ability to read, but NO, you really wrote ‘stiff’ in the first place ;-)
> You achieve amazing stiff with home etched boards. I wonder how many member you have in your RFMxx family.
You do this on purpose, yes?
What are you on @Mars?
Still in detox since Oct 6, 2013 ;-)
Have been running the Moteino Shield v1.0, logging Vcc, battery voltage, LDR (di-urnal cycle), DHT 22 temperature and humidity successfully since
my last post. In v1.0 the voltage divider is grounded by an I/O pin when the MCU wakes from sleep to transmit the battery voltage. The problem
with this arrangement is that there is “ALWAYS” current leaking through the voltage divider via the MCU I/O pin. In sleep mode the current draw due
to the voltage divider was measured as 11uA. To increase battery life, I wanted to find a method of being able to reduce the current draw during sleep
to nano ampere levels, at the very least. After exploring several dead-ends and many hours of frustration, found a method which does just that.
It involves using a transistor/PFET combination to pretty much completely cut the current draw through the voltage divider during sleep. Am attaching
a couple of photos of the Moteino Shield v1.2 board, Eagle schematic and pcb files and a “tested” demo sketch. Don’t ask what happened with the Moteino
Anyway, hope this information is of use to those contemplating a similar project.
|Moteino Shield v1.2 top.jpg (67.4 KB) Moteino Shield v1.2 top.jpg||photo of top of pcb|
|Moteino Shield v1.2 bottom.jpg (89.8 KB) Moteino Shield v1.2 bottom.jpg||photo of bottom of pcb|
|Moteino SHIELD v1.2.zip (30.9 KB) Moteino SHIELD v1.2.zip||Eagle schematic and board files|
|Moteino_DHT22e1_10022014.zip (2.09 KB) Moteino_DHT22e1_10022014.zip||Arduino demo sketch|
|Moteino_Shield_v1.2_top.jpg (70.7 KB) Moteino_Shield_v1.2_top.jpg|
|Moteino_Shield_v1.2_bottom.jpg (94.5 KB) Moteino_Shield_v1.2_bottom.jpg|
You could eliminate the BC547 (and it’s leakage current, not insignificant at high temps) with this circuit.
Once again, thanks for your comment and circuit . At this time of year we often get temperatures in the high thirties and low forties.
Have measured the actual current draw under these conditions and the MCU total current consumption remains at a rock solid 15uA.
Yes, I know it should be possible to get this down to something like 4uA but it’s “a work in progress” and these things take time. Even
with the current setup, I’m pretty sure I can get something like a year’s operation out of a single 9V battery … which is plenty good
enough for me.
As a matter of fact I mentioned in my previous post the Moteino v1.1 board, well this used the JeeLab’s circuit you just supplied. Really
wanted to be able to control the state of the I/O pin rather than rely on a pulsed output.
I can’t see the ‘pulsed’ circuit in the posted V1.1 .sch file - but the .sch and .brd are not synch’d, so maybe I’m looking in the wrong place?
I’m curious about why you rejected the ‘pulse’ method for the current design.
I’m not surprised you couldn’t see the ‘pulsed circuit’ in the posted V1.1 .sch file because I haven’t posted the V1.1 .sch. The schematic I
posted in my previous post was V1.2 .sch. Also, not surprised that you might be curious as to why I opted for the current design as opposed
to the ‘pulse method’. I was just going to treat the V1.1 design as a case of “well there’s a couple of hours of my life I’d rather have back” and
move on being content with learning a few things along the way but since you have shown some interest in my little V1.1 adventures, I’ll try
to clear up your queries.
I built the V1.1 and tested it. The voltage divider current draw when the MCU was in sleep mode was 15uA, the same as for the V1.2 design.
I made a few febble/unsuccessful attempts to incorporate the V1.1 circuit into my existing “tested” sketch. Essentially the pulsed nature of the
circuit presented timing problems for incorporation into that particular sketch. After several hours, decided it was probably a better bet to use
a setup that enabled just driving the I/O divider select pin high to select the voltage divider and drive it low to deselect the voltage divider.
This was easy to incorporate into the existing “tested” sketch, as compared to no luck with the ‘pulsed’ regime … took about a minute!
Anyway, am attaching a couple of photos of the Moteino Shield V1.1 (please note the ‘pulsed’ components, C1 [0.1uF] and R5[10k] in the
first photo). Also attaching the Eagle schematic (yes, V1.1 sch) and pcb files. Once again, thanks for your interest.
PS It would be really nice to be able to edit attachments
Thanks for the back story, Alles Klar! The ‘pulse’ method is a bit finicky on timing, I suspect R5 is too small, 470KΩ would make sampling easier.
When you are chasing those uA’s ….. ;
) you could probably get a better path to the RF connector by surrounding the ANT trace with groundplane flood (a refinement would be to size the trace width and clearance knowing the board material dielectric constant). There is not much that can be done about the header pin effect, apart from taking that second pin position as ‘RF Gnd’ since it tracks parallel in the plastic (yukky at RF !) casing.
Just a further comment on the PCB family design
The issue is that the RF connector forces a 50ohm impedance between feed line and ground that is a significant portion of a wavelength ‘along the antenna’. But the characteristic impedance at that point is far from 50Ω. The discontinuity will generate a poor SWR - mapping to reduced range and beads of sweat on the brow of the PA stage.
It would be interesting to hook up a Vector Impedance Analyzer at the RF connector and the module ANT pin. Drool Time
> PS: It would be really nice to be able to edit attachments
Can’t you delete and re-upload when it’s your own posting ?
Yes, you are probably correct, just after writing the previous post and having another look at that “tested” sketch, it occurred to me that if a R5 value
of 680k (approx 78mS pulse) or 820k (approx 95 mS pulse), the v1.1 iteration could probably be finessed. Will try it when I get a chance. As for the
antenna issue, even with this “non ideal” arrangement, signal strength (as shown by the RSSI readout) is good enough to get excellent wireless coverage
of our three storey townhouse, using a RFM69HW module, at full power. This certainly couldn’t be said for it’s RFM12B predecessor. As far as I’m
concerned, " if it ain’t broke, don’t try to fix it". Yes, it would be interesting to hook up that nice little toy but suspect I might have a pretty hard time
convincing my wife to part with 28 grand for one … I could be wrong … who am I trying to kid, not a chance!
When posting, can edit attachments by deletion and re-uploading but as far as attachment editing is concerned when I have tried editing attachments
from a previous post, the attachments aren’t shown, so can’t delete them. Have you tried this yourself?
It will be interesting what life you get from the RFM69HW - a tad edgy to run at full power with a mismatched antenna. Maybe the combination of duty cycle and probably conservative specs is ok - it might be a good idea to report the previous internal temperature value in the packet next time you are tweaking that code.
As for editing past posts - perhaps the anti-Orwellian tendencies of Redmine. If it is a major blooper, let me know what you want replacing, for my pains as a Forum admin, I have super powers enabled …
Well the bad news is, substituting 470k, 560k, 680k, 820k resistors for the original 10k resistor still resulted in incoherent output. Can’t waste any more
time on this, so am just going to use the v1.2 Moteino shield, which works fine and besides too many other things I want to play with.
I mentioned in a previous post that have been running RFM69HW modules at full power for a couple of months now and as yet have not noticed any adverse
heating effects. The two small wireless module power amp chips don’t even feel warm to the touch. Not a bad suggestion to modify the sketch to include
reporting of wireless module temperature. Intend to implement this some time in the near future … thanks for the tip! Will certainly keep you posted if any
of the RFM69HW modules decide to die prematurely, as I’m sure this will be of interest to other users and would-be users.
As for the attachment editing , thanks for the “blooper” offer but it’s probably better to save your super powers for more pressing tasks. C’est la vie!
> The two small wireless module power amp chips….
FYI those chips are:
- An antenna switch that moves the antenna feed between the RX input and the TX boost output of the RF chip (neat ha!)
- Probably an LDO for the TX_PA power feed. The lower voltage operating limit is raised when running at full power, suggesting a ~Vcesat in series with the Vdd rail.
My concern is the sweaty stuff is happening on the same tiny silicon die as for the non-H variant, not externally where heat dissipation wouldn’t be a problem. Would be good to get the chip die temperature logged if you have time.
The absolute value is all over the shop on a chip by chip basis, but the slope (20mV/ºC) is fundamentally as good as most of the temperature sensors out there. So calibrating with a well rested chip at ambient can provide a single correction offset value, and then you are good to go.
The limiting factor for accuracy is that the PA circuits and analog area are likely to be on opposite corners of the die, so all sorts of deltas there from temperature gradients as heat gets generated in one corner, then conducts (quite poorly) across the rest of the die and out through the pad/bonding wires to the lead frame.
Here is an illustration of how steep those gradients get on a more complex, larger die.