[ATmega128RFA1] How to maximize wireless range?

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been designing a prototipe with an ATmega128RFA1 chip and in the latest wireless communication tests I've done I'm able to separate two nodes between 4 to 8 meters before starting losing communication and/or getting CRC errors.

I've been checking the LQI which stays almost always at max value (doesn't drop below 0xFB even when losing packets) and the ED level (which is around 0x10 when at a couple of meters away, that's a low value isn't it?).

Right now I'm using a ceramic antenna, but if necessary, I'm willing to change it and use an U.FL or RP-SMA connector and an external antenna. Would that give me a better range?

The µC is working in basic mode.

I'm attaching an image of the RF part of two prototipes.
I realized there's too little ground on both boards, and the distance between the balun and the µC is too long, would that shorten the possible range on my boards?

I also made a couple of tests with the ATmega128RFA1 evaluation kits, getting similar range (which is too close)

Attachment(s): 

Last Edited: Fri. Oct 16, 2015 - 12:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thin long traces going to the balun are very bad for radio performance. They will not have a matched impedance. You need to have bigger ground plane and remove all the digital components from the RF path.

I'm not sure if radio performance of this kit was ever evaluated. Electrically it is equivalent to RCB128RFA1, but layout is very different. Have a look at design files for RCB128RFA1.

How do you measure ED level?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thenks for answering.

alexru wrote:
Thin long traces going to the balun are very bad for radio performance. They will not have a matched impedance. You need to have bigger ground plane and remove all the digital components from the RF path.

I'm not sure if radio performance of this kit was ever evaluated. Electrically it is equivalent to RCB128RFA1, but layout is very different. Have a look at design files for RCB128RFA1.

How do you measure ED level?

My problem is that I have strict size limitations on the final product. I guess I'll have to reorganize the whole thing and put the balun right next to the µC.
About the ground plane, how much bigger? Is there a standard minimum size/shape? Haven't found anything about it.

The Energy Detection level is calculated automatically in the mega128RFA1, I just read a register.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I've been rearranging the board to comply with what the balun datasheet says. I'm attaching an image of the new board.
I reorganized the wholes board, left a ground layer on the bottom, bigger groung on top and lots of vias, balun really close to the µC. Also made the 'wire' connecting the antenna and the balun wider to achieve a 50ohm impedance (according to several calculators online, ~3mm).

Is it correct now?
(Or is it only just 'less bad' than before?)

I'm evaluating in using an external antenna, do I have to have the same considerations for the balun (ground layers and vias)?
I was thinking in using a U.ML connector, should it be as close as possible to the balun?

I'm planning in connecting either a Taoglas antenna or a RP-SMA connector plus an external antenna.

Any comments?
Anything to fix in this?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That looks much better. But why TST pin goes to the other layer? It should be connected to AVSS, which is right next to it, or to the exposed pad.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
That looks much better. But why TST pin goes to the other layer? It should be connected to AVSS, which is right next to it, or to the exposed pad.

Indeed, for some reason it stuck from a previous design and assumed that pin had to have a resistor before ground.

How about using an U.ML connector and replacing the antenna?
Should I still keep the big ground layers?
Or could I go and shrink the whole board?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm attaching the new layout including the u.fl connector (and fixed the tst pin)

Could I shorten the board or should I better leave that 'bigger' ground plane?
I was thinking in putting the connector the closest possible (but then, I don't have room for the 1.5pF cap).

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no need for big ground plane with external antennas.

This design looks OK to me.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, after building the board, the results are worse than using the ceramic antenna with bad/long-slim traces.

 

I programmed the atmega with a software that boradcasts a random frame every 4 seconds and answers with this same random frame whenever it receives a message (the idea is to have the µc receiving data all the time).

Everytime a packet is received, the atmega checks the CRC and prints, through the serial port, the CRC value, the rssi value (-90+3*(RSSI-1)) and the ED level (-90 + ED).

 

Using the 'bad' board as a receiver (see attachment), I get:

using the 'bad board' as emitter: @13cm apart --> RSSI: -55~-43, ED: -54~-42

                                              @100cm apart --> RSSI: ~-70, ED: -69~-68 (plus some CRC errors)

 

using the 'new board' as emitter: @13cm apart --> RSSI: -52~-48, ED: -51~-49

                                              @100cm apart --> RSSI: ~-73~-70, ED: -73~-69 (plus some CRC errors)

 

On the 'new board' I've been using the extarnal antennas from Taoglas FXP75, FXP70 and some standard RP-SMA antenna using a ufl to RP-SMA connector, having similar results.

 

Now, am I evaluating the received data in some incorrect form or what?

Can't understand why, after "fixing" the rf design of the board, am having the same (or very similar) range than before.

 

Ideas?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand. Two posts above there is a link to "New layout", which shows a very tight RF layout. In this message there are attachments with long traces.

 

Can you make a closeup picture of your final board assembled?

 

Your RSSI values look OK, check LQI as well, it will show the problem better.

 

Also, what stack/software do you use?

 

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

I don't understand. Two posts above there is a link to "New layout", which shows a very tight RF layout. In this message there are attachments with long traces.

 

Can you make a closeup picture of your final board assembled?

 

Your RSSI values look OK, check LQI as well, it will show the problem better.

 

Also, what stack/software do you use?

 

 

Two posts above was/is the corrected version. That is the "new layout" which uses an external antenna and ¿should? work better.

That is the latest version.

For a closeup, I guess I'll nedd a good camera (so I could take a macro shot), is that what you need? A macro image of the real board?

 

According to LQI, it stays on 255 always with all boards/antennas, so can't use it to compare.

I'm pretty sure I have lots of wifi interference, but that wouldn't explain the unchanged performance between boards (I somehow 'feel' like the new board is performing worse than the old one).

 

About stack/software, I'm "manually" building the 802.15.4 frame, putting the transceiver in PLL_ON state ('transfer state') and start the transfer toggling the start bit.

 

Last Edited: Wed. Oct 8, 2014 - 09:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a picture should be sufficient. All I want to see is quality of soldering, flux residue and all this sort of stuff.

 

OK, so you have very good LQI, very good RSSI. I'd start looking at software problems. Try running proven software, like LwMesh on your board first.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

Just a picture should be sufficient. All I want to see is quality of soldering, flux residue and all this sort of stuff.

 

OK, so you have very good LQI, very good RSSI. I'd start looking at software problems. Try running proven software, like LwMesh on your board first.

 

Let's see if these work.

 

I definitely have to learn to take macro photos.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just found a difference in the radio part between boards.

The "old" pcb uses the balun TDK HHM 1517 which has a unbalanced/balanced impedance of 50 / 50 ohm.

The "new" pcb uses the balun Johanson 2450BL15B200 which has an unbalanced/balance impedance of 50 / 200 Ohm.

 

Now, the ATmega128RFA1 datasheet (rev F) in page 500 says that

Quote:
 The 50Ω single-ended RF input is transformed to the 100Ω differential RF port impedance using Balun B1.
So I'm guessing the unbalanced/balanced impedance should be 50 / 100 Ohm. In fact, one of the recommended baluns', the Wurth 748421245 has 50/100ohm unbalanced/balanced impedance, the "problem" is that the other recommended balun, the Johanson 2450FBL0001, has an unbalanced/balanced impedance of
Quote:
50/ Impedance match to AT86RF230/231 and ATmega128RFA1
and according to this, it has a 50/50 ohm impedance (thought I don't trust that webpage that much).

 

So, after this "long" post, is that error in impedance that much of a deal?

If so, the correct balun is in fact one that has a 50/100 ohm unbalanced/balanced impedance, right?

Is there any theory why the 50/50 ohm balun should work better than the 50/200 ohm one? or should they both have bad performance? or just regular performance? or just not optimal performance?

 

I'll check the LW Mesh now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It must be 50 / 100 if you use generic balun. Johanson actually measured output stages of Atmel radios and designed a balun specifically matched to those radios. But it will be close to 100 Ohm.

 

To achieve the best performance, use Johanson part, but if you can't get that for some reason, any balun with 50 / 100 Ohm impedance should work.

 

Such a big impedance mismatch should be a problem. I'm not sure why LQI is 255 in your case.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

It must be 50 / 100 if you use generic balun. Johanson actually measured output stages of Atmel radios and designed a balun specifically matched to those radios. But it will be close to 100 Ohm.

 

To achieve the best performance, use Johanson part, but if you can't get that for some reason, any balun with 50 / 100 Ohm impedance should work.

 

Such a big impedance mismatch should be a problem. I'm not sure why LQI is 255 in your case.

 

I'll change the baluns and let you know.

Lucily I have a couple 50/100 around to test (and I gues I can dismantle from some older boards which do have 50/100, don't know the reason why the new bought batch was 50/200 or 50/50).

I'll check with LWMesh to test RSSI/LQI and compare.

 

I'll let you know when/if I find anything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should look at the actual data in the receive buffer. A short but strong interference pulse can alter a single bit up to a string of bytes and cause the CRC error. But the LQI and RSSI can remain high because they are measured during a short period at the start of reception. Also turn off your transmitters and monitor the average and peak rssi on each channel. Maybe you can find one with lower noise.

Last Edited: Thu. Oct 9, 2014 - 06:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Changed the baluns for some 50/100 ones, I'm getting better numbers, but still low (~-54 for ED @<1m, ~-87 @ ~8m with some lost packets.)

LQI stays at max value, sometimes it lowers to 244, but that's it.

 

 

 

dak664 wrote:

You should look at the actual data in the receive buffer. A short but strong interference pulse can alter a single bit up to a string of bytes and cause the CRC error. But the LQI and RSSI can remain high because they are measured during a short period at the start of reception. Also turn off your transmitters and monitor the average and peak rssi on each channel. Maybe you can find one with lower noise.

I'm sorry but I don't get it.

What's the point on checking the data if i'm already getting a CRC error?

Also don't understand, what would it mean to turn off the transmitters?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you test two boards of the same design against each other? Or you have some reference platform? Crystal frequency offset is known to cause problems, but if two boards are the same, it should not matter.

 

Checking the frame payload may help to learn what kind of errors do you get. But I would not expect to gather a whole lot of information from that.

 

What do you use for antenna?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
Do you test two boards of the same design against each other? Or you have some reference platform? Crystal frequency offset is known to cause problems, but if two boards are the same, it should not matter.
I am using two cases:
- Using one 'old' pcb board as receiver for both 'new' and 'old' board.
- Using one 'new' pbc board as receiver for both 'new' and 'old' board.

I don't have a working board yet to have as a reference design.

After changing the balun to the 50/100 one on the new boards, I'm having better reception and better range, but still low values.

alexru wrote:
Checking the frame payload may help to learn what kind of errors do you get. But I would not expect to gather a whole lot of information from that.
The errors I'm having (or rather, those I can detect) are either CRC errors, for which I'm not checking the frame, (what for?) and missing frames, for which I cannot cheack the frame.
alexru wrote:
What do you use for antenna?

About the antenna, I'm using the same that I mentioned in a previous post:
tglaria wrote:
On the 'new board' I've been using the extarnal antennas from Taoglas FXP75, FXP70 and some standard SMA antenna using a ufl to SMA connector, having similar results.
The SMA antenna I'm using came from some other devices I have around here which operates on the same 2.4GHz band (It was from a Jennic JN5148 microcontroller, 802.15.4).

Last Edited: Fri. Oct 10, 2014 - 12:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have a spectrum analyzer available?  The RFExplorer is fantastic and cheap (http://rfexplorer.com).  It is really hard to tell if you have an interference problem without external tools.  A nearby Wifi router than is very busy can easily make an 802.15.4 radio almost unusable.  

Is your transmit power set to maximum?

 

Is your power supply clean?  Analog circuits don't like noisy power.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bluefire211 wrote:
Do you have a spectrum analyzer available?  The RFExplorer is fantastic and cheap (http://rfexplorer.com).

No, I don't.

I guess I should be getting one somehow.

bluefire211 wrote:
It is really hard to tell if you have an interference problem without external tools.  A nearby Wifi router than is very busy can easily make an 802.15.4 radio almost unusable.
I'm in the middle of an office building with wifi signals around, I know, but that shouldn't make my nodes to lose frames under 10 meters, should they?

bluefire211 wrote:

Is your transmit power set to maximum?

It's the ATmega128RFA1 default value, so, as far as I know, yes, it is at its maximum value.

bluefire211 wrote:
Is your power supply clean?  Analog circuits don't like noisy power.

I'm using LiPo battery to power the nodes, I don't think I can get a cleaner power supply.

 

Also is preferable to not add voltage regulator because of current and space limitations (I'm already at the limits with my design).

 

Now that I think about it, I'm powering the microcontroller outside of its maximum voltage value. I'm using 4.2V max to power it (which is 3.6V max according to it's specifications).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Considering that the suppy voltage is at 4.2V max (instead of the 3.6V maximum value written in the datasheet), could this damage the microcontroller?

Maybe the radio/transceiver part?

 

the final version, should be able to operate with 3.7V power supply (directly connected to a battery).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tglaria wrote:
Now that I think about it, I'm powering the microcontroller outside of its maximum voltage value. I'm using 4.2V max to power it (which is 3.6V max according to it's specifications).

 

I'm not even going to try to diagnose this further unless you power your board from a stable 3.3v power supply.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A CRC error simply means that one or more bits in the receive buffer is wrong, but looking at the contents of the buffer tells a lot more.  If you send ABCDEFG and receive ABCXEFG then you know some brief interference or fade occurred but if you receive QRRGAD then the signal to noise is terrible. Use non-extended mode so packets with CRC errors are not ignored, and that will also drop any address filtering should there happen to be some nearby 802.15.4 device that is continuously strobing on the same channel but a different PAN.

 

That radio can also be used as a spectrum analyzer by scanning the RSSI across channels for a minute or so, then doing an ASCII plot of the peak and average RSSI.  Somewhere in the old forum are examples of that.  Note the ED and LQI features are calculated on the RF chips right after the start of frame is detected, so nterference during the SOF means no frame detection, thus reported LQIs will be statistically concentrated in the periods between pulsed interference.

 

And i accidentally operated that chip at 4.2, as i recall the radio did not work so well and the MCU stopped working altogether after about 5 minutes. But no long term damage as far as i could tell.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just don't use hardware with unknown RF performance to do "spectrum analyzer" measurements. You will never know if it is your hardware is faulty, or there is indeed a lot of interference.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tglaria wrote:

 

I'm in the middle of an office building with wifi signals around, I know, but that shouldn't make my nodes to lose frames under 10 meters, should they?

 

 

It absolutely can.

 

 

tglaria wrote:

 

I'm using LiPo battery to power the nodes, I don't think I can get a cleaner power supply.

 

Also is preferable to not add voltage regulator because of current and space limitations (I'm already at the limits with my design).

 

Now that I think about it, I'm powering the microcontroller outside of its maximum voltage value. I'm using 4.2V max to power it (which is 3.6V max according to it's specifications).

 

 

You've nuked your chip.  Throw it away, put a 3.3 volt regulator on it, and test again.  The max (and min) spec is there to give you some headroom because no 3.3 volt supply is exactly 3.3 volts, and you get some load and line variance as well.  Even if you run at 3.6 volts, you would be asking for reliability problems down the road.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

 

tglaria wrote:

Now that I think about it, I'm powering the microcontroller outside of its maximum voltage value. I'm using 4.2V max to power it (which is 3.6V max according to it's specifications).

I'm not even going to try to diagnose this further unless you power your board from a stable 3.3v power supply.

 

As soon as I realized this I started using a 3.3V regulated power source fo testing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

 

tglaria wrote:

Now that I think about it, I'm powering the microcontroller outside of its maximum voltage value. I'm using 4.2V max to power it (which is 3.6V max according to it's specifications).

I'm not even going to try to diagnose this further unless you power your board from a stable 3.3v power supply.

 

As soon as I realized this I started using a 3.3V regulated power source fo testing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bluefire211 wrote:

tglaria wrote:

I'm in the middle of an office building with wifi signals around, I know, but that shouldn't make my nodes to lose frames under 10 meters, should they?

It absolutely can.

Quote:
I've checked the wifi channels.

The wifi n°1 channel isn't beeing used.

So the 802.15.4 channel n°11, is 'free' from wifi interference.

bluefire211 wrote:
tglaria wrote:

I'm using LiPo battery to power the nodes, I don't think I can get a cleaner power supply.

 

Also is preferable to not add voltage regulator because of current and space limitations (I'm already at the limits with my design).

 

Now that I think about it, I'm powering the microcontroller outside of its maximum voltage value. I'm using 4.2V max to power it (which is 3.6V max according to it's specifications).

You've nuked your chip.  Throw it away, put a 3.3 volt regulator on it, and test again.  The max (and min) spec is there to give you some headroom because no 3.3 volt supply is exactly 3.3 volts, and you get some load and line variance as well.  Even if you run at 3.6 volts, you would be asking for reliability problems down the road.

All the next test will be done with a regulated 3.3V power supply and a new chip.

I've powered some prototipes with 5V to check the maximum voltage value, and none of them were (apparently) damaged.

Still, I'm not using those for these tests.

 

Now, according to what you're telling me, I can't expect the microcontroller to work properly using a 3.6V battery?

And definitely should not use a battery with a 3.7 maximum voltage?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is impossible to tell if they were damaged or not. The damage here is gradual, the fact that chip did not blow up says nothing.

 

I would only operate this chip at 3.3v. I don't know if it will work at 3.6v or not, I have no statistics on this, I've never seen anyone do this in production devices.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

It is impossible to tell if they were damaged or not. The damage here is gradual, the fact that chip did not blow up says nothing.

 

I would only operate this chip at 3.3v. I don't know if it will work at 3.6v or not, I have no statistics on this, I've never seen anyone do this in production devices.

Got it.

I'll keep doing some range tests.

 

I'll have to evaluate if these work using 3.6V battery without regulator, but for now I'll keep it.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

3.6 volts is the maximum.  That means Atmel tested the part at 3.6 volts and it passed their tests (and since we don't know what those tests are, we have to take their word for it).  You can certainly use 3.6 volts, but if you do, you have absolutely no margin for error.  What is the tolerance on the regulator?  Line and load variation?  Temperature variation?

 

If you want a reliable product, you want to give yourself as much headroom as you can.  This part is spec'd at 3.6 volts so you have a 10% margin over the nominal 3.3 volts that most people use.  Hopefully the components in your power supply only reduce that margin by 5% or so, leaving you with another 5% for anything you didn't plan for.

 

Note that if you want to run unregulated off batteries, you can use two alkalines in series.  You won't get the full capacity since the batteries will be dead at 1.6 volts and the part minimum is 1.8 volts.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bluefire211 wrote:

3.6 volts is the maximum.  That means Atmel tested the part at 3.6 volts and it passed their tests (and since we don't know what those tests are, we have to take their word for it).  You can certainly use 3.6 volts, but if you do, you have absolutely no margin for error.  What is the tolerance on the regulator?  Line and load variation?  Temperature variation?

 

If you want a reliable product, you want to give yourself as much headroom as you can.  This part is spec'd at 3.6 volts so you have a 10% margin over the nominal 3.3 volts that most people use.  Hopefully the components in your power supply only reduce that margin by 5% or so, leaving you with another 5% for anything you didn't plan for.

 

Note that if you want to run unregulated off batteries, you can use two alkalines in series.  You won't get the full capacity since the batteries will be dead at 1.6 volts and the part minimum is 1.8 volts.

I have strict space limitations and big lifetime requirements, can't afford to use alkalines.

 

I found some voltage regulators with (theorically) 1µA quiscent current, that shouldn't lower my battery lifetime too much so I could use a 3.3V node IF I manage somehow to squeeze it in my device.