Author Topic: Range Issues with RFM69xxW on custom PCB  (Read 14901 times)

craigburden

  • NewMember
  • *
  • Posts: 13
Range Issues with RFM69xxW on custom PCB
« on: May 03, 2017, 02:54:00 AM »
Hey guys,

So I have been working on a project using the RFM69 series modules and I am experiencing very low range and I am having a lot of trouble with diagnosing exactly where the issue is sneaking in. I have designed boards for the RFM69W, RFM69HW and RFM69HCW and all of them are experiencing similar issues.

A little background before I get going with the process that lead to here, I am designing an upgraded device that should plug in to an existing system that I have developed using the MRF69XA (The RFM12b is a clone of this chip). Since the RFM69 is an upgrade to the RFM12b I figured it would be a great way to include far more functionality while maintaining backward compatibility with the existing system. The existing system uses the following settings from an RF stand point:

Centre frequency: 433.92MHz
Deviation: 165MHz
Bitrate: 26.5kbps

 I initially ordered four Moteinos, two RFM69HCW and two RFM69W versions (Thanks Felix!). I uploaded the TxRxBlinky example code from the LowPowerLabs Library and unsurprisingly it worked great, I had very impressive range fully covering two stories of my building. I then included the RFMregisters.h file in the main .ino file of the example and changed the centre frequency, deviation (RX bandwidth too of course) and bit rate to match the existing system. I then repeated the same test and saw similar results. I furthered that as a final functionality check by editing the example rather extensively to match the packet structure of the existing system in order to confirm backward compatibility and again it worked. I did forget to do a range test here due to over excitement.

So now I began to move to testing it on a custom PCB. I designed two boards as I mentioned before, such that they fit in my casing etc... the RFM module was placed directly where the MRF69XA and its balun used to sit. And notably I kept the same double sided large antenna pad. You can see screenshots of the RFM section of the board attached below. Next because I am using a very small and cheap PIC16LF18324 micro I needed to write some code, I used the LowPowerLabs library as a guide.

My code is very similar to that of the library however I am not getting the performance I expect.
I don't understand how outputting 100mW is giving me ~30m of range using a a coiled monopole antenna soldered to the pad seen in the attached images. Granted that range is in a building, it is far worse than my original range testing.

If someone could help me to diagnose this? I am wondering if it is an impedance matching issue given the big antenna pad and the proximity to GND/VCC pads on the module that is having a capacitive coupling effect? I've changed the LNA input impedance to try explore that. Could it be purely a fact of the high modulation ratio (~6, provided I calculated it correctly), I have played with the DAGC setting as the datasheet suggests that the "improved" algorithm is better for low modulation indexes. I can provide some code snippets if that would be helpful.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #1 on: May 03, 2017, 05:53:19 AM »
As a simple troubleshooting suggestion: what happens if 1.  you don't solder the module to the big giant pad and 2. you don't solder your antenna to the big giant pad either but instead 3. solder your antenna directly to the RFM69 module itself?  That's what I've been doing lately on most of my experimental nodes, and it works great.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #2 on: May 03, 2017, 06:04:48 AM »
Ah, I think I see the problem on the RFM69xW.  It appears you don't have any traces leading to either of the GND connections on the module.  I'm surprised it works at all.

[Edit: looks like the same non-grounding connection with your RFMHCW module as well.]

On the bright side, this should be easy for you to fix.   ;)

Sounds like you're doing interesting stuff.  Can you at least let us know what your system does?  It's always nice to hear a bit more from new posters rather than--more often than not--they post some narrow technical question and then disappear forever after it's answered without so much as a peep.
« Last Edit: May 03, 2017, 06:29:35 AM by WhiteHare »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Range Issues with RFM69xxW on custom PCB
« Reply #3 on: May 03, 2017, 07:38:40 AM »
FWIW - The GND may be part of the fill.

ChemE

  • Sr. Member
  • ****
  • Posts: 419
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #4 on: May 03, 2017, 08:09:27 AM »
It also looks like some of the traces are not running at 45 degree angles.  That won't break anything but from what I've read it is not best practice in case you want to improve your PCB skills.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #5 on: May 03, 2017, 08:51:41 AM »
FWIW - The GND may be part of the fill.

I bet you're right.  That would explain the narrow traces and all the seemingly unconnected via holes....

But why does he have via holes on his antenna pad?  I guess the pad is on both sides?  Why do that?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Range Issues with RFM69xxW on custom PCB
« Reply #6 on: May 03, 2017, 10:27:23 AM »
I bet you're right.  That would explain the narrow traces and all the seemingly unconnected via holes....
But why does he have via holes on his antenna pad?  I guess the pad is on both sides?  Why do that?
Probably on both sides. Maybe he can explain and fill in the blanks...

craigburden

  • NewMember
  • *
  • Posts: 13
Re: Range Issues with RFM69xxW on custom PCB
« Reply #7 on: May 03, 2017, 11:30:38 AM »
Thank you everyone for the speedy replies! I'm going to reply in order here:
As a simple troubleshooting suggestion: what happens if 1.  you don't solder the module to the big giant pad and 2. you don't solder your antenna to the big giant pad either but instead 3. solder your antenna directly to the RFM69 module itself?  That's what I've been doing lately on most of my experimental nodes, and it works great.

I tried that last week, I scratched out the trace leading to the large pad and the soldered the antenna directly to the module and I didn't see any considerable change. I have also tried scratching out the pad entirely to eliminate the capacitive effect it may be having and that hasn't seemed to make a difference. You can see a picture of that change below. What I must say though is that I haven't done a range test with the new scratched out pad, rather I have checked the peak output power on our spectrum analyser. I will range test tomorrow. May I ask what RF settings you are getting the success on? I am worried this may be a factor of the huge deviation.

Ah, I think I see the problem on the RFM69xW.  It appears you don't have any traces leading to either of the GND connections on the module.  I'm surprised it works at all.

[Edit: looks like the same non-grounding connection with your RFMHCW module as well.]

On the bright side, this should be easy for you to fix.   ;)

Sounds like you're doing interesting stuff.  Can you at least let us know what your system does?  It's always nice to hear a bit more from new posters rather than--more often than not--they post some narrow technical question and then disappear forever after it's answered without so much as a peep.

I'll answer all of the grounding questions here, yes all of the ground connections are made via a ground plane. Which explains the "unconnected vias". I didn't include the planes in the screenshot since it would make the layout a bit tricky to see.

In terms of the project, I am developing an updated version to a mesh networked fire detector for use in informal settlements. Our company is called Lumkani, you can find us here:  http://www.lumkani.com. The informal settlement setting is a nightmare for RF, I just came back from a day of RF testing with the RFM solution as it stands and we are seeing around 7m of patchy range. Which just isn't good enough and is far worse than the MRF49XA that we used before. Based on community reports we were expecting well over 100m in community and +300m open field. We are trying very hard to diagnose the issue because as it is, we are in a very tough place, in terms of our current time line. Hence I am seeking help from some RF wizards!

I bet you're right.  That would explain the narrow traces and all the seemingly unconnected via holes....

But why does he have via holes on his antenna pad?  I guess the pad is on both sides?  Why do that?

In terms on the antenna pad, I too question why it is like that! It is a legacy feature from our old device which was included a while back due to some manufacturing considerations with regard to conformal coating. I wasn't with Lumkani at the time but I am very open to changing that, provided the antenna pad remains on the back for the same manufacturing considerations. And to clarify, yes the pad is currently on both sides. However on the scratched off version I mentioned before I removed the bottom pad entirely and kept a small chunk of the top pad.

Would it be better to make a longer trace to the antenna pad that could be smaller and single sided and then perhaps ground stitch the ground plane around it?

I have also attached a picture of our antenna, it is a 50 Ohm antenna, is that what the balun expects? What sort of impedance conversion is it doing? Should the LNA impedance be left at 200? 

How likely is this to be a code issue? I can't think of a setting that would affect range so drastically...

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #8 on: May 03, 2017, 11:59:14 AM »
For troubleshooting, have you tried attaching just a straight piece of wire directly to the module's antenna pad?  Those work great, and  it might at least eliminate the question about whether your helical antenna (or other aspects) is a factor in this.
 
Have you confirmed with an oscilloscope that it's getting the expected voltage and drawing the expected current?  [Edit: if possible you want to measure right at the pins of the module, as there can be voltage drops on the way there.]

Almost always the problem is one or the other of those two things, and they're easy to check so you'd want to rule them out first.


[Edit:
Also, are these the same modules that you previously tested with success?  Occasionally on this forum someone buys modules for one frequency (e.g. 433Mhz) but actually gets another (e.g. 858Mhz).  Then, when they run their code, they report severe range issues.  You could substitute known good modules if there's any chance of that.

As for your coding, there are a lot of things that could be wrong that could cause range issues.  We could run down the list, but I think it might be faster to eliminate any chance of it being a simple hardware issue first.]
« Last Edit: May 03, 2017, 01:03:02 PM by WhiteHare »

john4444

  • Jr. Member
  • **
  • Posts: 71
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #9 on: May 03, 2017, 01:26:36 PM »
Hi Craigburden,
Let me reinforce WhiteHare's comments.
That antenna looks as if it might be troublesome. A straight wire of the proper length would eleminate that as an issue.
Also, DC grounds and RF grounds are often a problem in new/revised designs.
Check all grounds for RF issues keeping in mind that 400-MHz RF does not like to go around sharp corners.

Good luck
John AE5HQ

craigburden

  • NewMember
  • *
  • Posts: 13
Re: Range Issues with RFM69xxW on custom PCB
« Reply #10 on: May 04, 2017, 03:32:32 AM »
For troubleshooting, have you tried attaching just a straight piece of wire directly to the module's antenna pad?  Those work great, and  it might at least eliminate the question about whether your helical antenna (or other aspects) is a factor in this.
 
Have you confirmed with an oscilloscope that it's getting the expected voltage and drawing the expected current?  [Edit: if possible you want to measure right at the pins of the module, as there can be voltage drops on the way there.]

Almost always the problem is one or the other of those two things, and they're easy to check so you'd want to rule them out first.


[Edit:
Also, are these the same modules that you previously tested with success?  Occasionally on this forum someone buys modules for one frequency (e.g. 433Mhz) but actually gets another (e.g. 858Mhz).  Then, when they run their code, they report severe range issues.  You could substitute known good modules if there's any chance of that.

As for your coding, there are a lot of things that could be wrong that could cause range issues.  We could run down the list, but I think it might be faster to eliminate any chance of it being a simple hardware issue first.]

Thanks again for the help!

I haven't tried the whip antenna yet because it is not an option for our device as it needs to fit into our casing. But I will give it a go and get back to you!

I have measured voltage at the module pin and it was stable at 3.3v during transmission and receiving, I haven't measured current directly to the module but I have measured the current supply going to the device as a whole and it seemed within range for the module and the rest of the device overhead.

As I said before I removed the modules that I had tested briefly on the Moteinos, and placed them on my boards. Of course there is still a chance that I have the wrong modules, but I do have 7 modules total (2 HCW, 2 HW and 3 W), I have doubts that all of them are wrong. But this will be a symmetrical issue so if one is wrong I will perceive  effects on all of them. Is there any way to tell the variants apart? I imagine all that changes is the balun? I have checked a few times now to ensure I didn't blow off any of the balun on the modules I removed.

I am starting to think it may be a code issue based on my testing but we will have to explore this further!

Hi Craigburden,
Let me reinforce WhiteHare's comments.
That antenna looks as if it might be troublesome. A straight wire of the proper length would eleminate that as an issue.
Also, DC grounds and RF grounds are often a problem in new/revised designs.
Check all grounds for RF issues keeping in mind that 400-MHz RF does not like to go around sharp corners.

Good luck

I will try the wire antenna as a functional check but I will have to revert to that antenna as it needs to fit in the casing we use. It has been working great for the past few years with the MRF chip.

I will certainly be making changes to the board in the new revision to make it a little more RF friendly

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #11 on: May 04, 2017, 06:37:34 AM »
On the software front, it is lucky that you have working Moteino's to compare against.  As I understand it, the Moteino's worked great even at the lower baud rate that your product uses in the port.  Is that correct?  Then you ported the software over to a PIC cpu, and so now you want to explore whether the range issues may be a result of a fault in the software port.

Here's what I suggest:  Read and print all of the RFM69 register values from one of the working Moteino's after it has initialized and is working as expected.  Do the same for all of the RFM69 register values on your PIC port.  They should match.  If not, zero in on which registers differ, and that will lead you to the PIC code which is wrong.

If anyone else has a better plan, please jump in.

[Edit:  By the way, why did you prefer a PIC over an ATMEGA328p?  I've never tried the PIC.  Does the PIC have advantages? ]
« Last Edit: May 04, 2017, 07:23:12 AM by WhiteHare »

craigburden

  • NewMember
  • *
  • Posts: 13
Re: Range Issues with RFM69xxW on custom PCB
« Reply #12 on: May 05, 2017, 08:10:56 AM »
Unfortunately this is going to have to take a backseat for now as we have to go forward with other aspects of the design for now. But I will be back soon to answer all of the untested suggestions!

On the software front, it is lucky that you have working Moteino's to compare against.  As I understand it, the Moteino's worked great even at the lower baud rate that your product uses in the port.  Is that correct?  Then you ported the software over to a PIC cpu, and so now you want to explore whether the range issues may be a result of a fault in the software port.

Here's what I suggest:  Read and print all of the RFM69 register values from one of the working Moteino's after it has initialized and is working as expected.  Do the same for all of the RFM69 register values on your PIC port.  They should match.  If not, zero in on which registers differ, and that will lead you to the PIC code which is wrong.

If anyone else has a better plan, please jump in.

[Edit:  By the way, why did you prefer a PIC over an ATMEGA328p?  I've never tried the PIC.  Does the PIC have advantages? ]

This is a great suggestion, I will definitely do that.

In terms of the IC selection, the PIC was chosen for a host of reasons. Firstly, price, it is super cheap. Peripherals, it has a lot of very useful peripherals, some of which the 328 doesn't have. Pin count, we need 12 GPIO pins exactly and the PIC comes in a 14 pin package.
Just to name a few :). The PIC16LF18324/5/6 are great chips! They have a feature called PPS (Peripheral Pin Select) allowing any pin to be remapped to any peripheral input or output which makes PCB layout a breeze. It is quite a bit faster than that 328 too, the internal clock runs at 32MHz. Power is very good across the board and it has great power saving features like doze, ilde, sleep etc.

That is probably more of an answer than you were looking for but it basically comes down to it isn't too much or too little and it meets our extremely tight price budget. On that note you will find a post from me about laying out a SX1231H chip in future (The modules are far too expensive for us).

Thanks again for everything, I will try get stuck into this again near the end of next week after our heat testing :)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Range Issues with RFM69xxW on custom PCB
« Reply #13 on: May 06, 2017, 05:15:25 AM »
Looking forward to it!   :)

craigburden

  • NewMember
  • *
  • Posts: 13
Re: Range Issues with RFM69xxW on custom PCB
« Reply #14 on: June 05, 2017, 02:28:42 AM »
Hello again!

I am finally back! Sorry for the extended absence I had a lot of other work to get done for a deadline we had. Anyway I am back fully into this problem!

So some updates on my testing thus far.

Here's what I suggest:  Read and print all of the RFM69 register values from one of the working Moteino's after it has initialized and is working as expected.  Do the same for all of the RFM69 register values on your PIC port.  They should match.  If not, zero in on which registers differ, and that will lead you to the PIC code which is wrong.

I have done this now, I took the basic TxRxBlinky example and did a quick range test, then included RFM69registers.h so that I could adjust the centre frequency, deviation, bitrate and bandwidth. I then redid the range test to confirm comparable range. It was the same, if not slightly better! I then adjusted the code further to adopt the same packet structure that we use on our system. And again confirmed range, I did find a very slight decrease in range here, I suspect because of the larger packet size (9 bytes, excluding CRC and preamble). However the range was still very good, I can't tell you a range in meters but in our building I reached the same point I did with another transceiver where we were getting open field ranges of ~200m. I then ran through my PIC code one last time to ensure I hadn't done anything blatantly wrong. I dumped the register values from 0x00 to 0x71 on both devices, I can include these for you guys to see if you like (Both devices were using the RFM69W module). I noticed some minor differences namely in listen mode setup (Because it isn't used in the TxRxBlinky sketch) and weirdly enough I noticed some other registers had differing values however the bits that were set (On the Moteino) were in fact bits that according to the datasheet are not used. They are greyed out and are unwritable and claim to be read as 0, but I saw otherwise.

So despite the datasheet saying this is not an issue, I still saw significantly less range with our circuitry. Then just to confirm it wasn't a dud module I swapped the modules and saw the same performance. This obviously points toward a circuitry issue, or possibly an issue with my receive sequence? I streamlined the transmit cycle (I originally used the FIFONOTEMPTY trigger for transmission to start, meaning I needed to switch the transmitter on and off between every packet. This really slows things down. So I have moved to FIFOTHRES, I confirmed this function on the Moteino too.

In terms of circuitry, I have scratched off the top and bottom antenna pads that I suspected may be causing some capacitive coupling. As well as soldering the antenna directly to the antenna output of the module. You can see this in the picture attached. This brings be to another test I have been doing, placing a Moteino as a receiver which prints the packet it received as well as the RSSI. I then place the transmitting devices at a constant distance and observe the RSSI. I noticed (At a range of ~30cm) the Moteino had a RSSI of around -22 where as our device was in the order of -50, I'm not sure if that measure is in dBm... If so that is a HUGE difference, and I can assume that this is a symmetrical issue (Ie the receiver is also being attenuated some how). I have done a similar test using our spectrum analyser (Aligent E4404B) and seen a channel power difference of 10-15dB.

So I am going to try to run SPI wires from my device over to a Moteino with the 328p removed. This will allow me to configure the device using my PIC code while maintaining the Moteino layout. If I then see the full range I can be confident it is the layout.

Again thank you every one for all the help! I will update you once I have furthered my testing. I will obviously share anything I learn regarding the circuit layout!