VCO Tuning at 27MHz

@alex.klassen

  1. How close do the frequency’s need to get to communicate?

The transmitter and receiver need set to same frequency. The frequency error would be compensated by AFC.

  1. Is there a more accurate way to determine the lock besides carrier wave.

Please be more specific in this question.

  1. Anything you can recommend to get more consistent frequency’s between devices?

I am not sure this question. Do you mean communicate between 2 devices. If so, you can use tho of our DVK-2 boards with add on AX5043 and start to communicate between MASTER & SLAVE.

I mean if I get two AXM0343 devices and put them on a PCB with the same parts (with tolerances of 2% or less), they will transmit at different frequency’s. One will transmit at like 27.17MHz and the other will be 27.10 or 27.26. I have had to go in and manually adjust the VCOI register to adjust the frequency because I don’t believe the code is doing it properly.

Also I have noticed that the AXM0F343 does not seem to receive as well at lower frequency’s like 27MHz in comparison to its predecessors such as the AXM0243 or the AX5043. I would like to know if that is something to do with the chip or the software.

@alex.klassen

27 MHz has been set and tested as you can follow up topic this thread:


Also I have noticed that the AXM0F343 does not seem to receive as well at lower frequency’s like 27MHz in comparison to its predecessors such as the AXM0243 or the AX5043. I would like to know if that is something to do with the chip or the software.

I am checking this within our internal team and get back with some info on this as well.

Yes I know about that thread where the guy was able to get the AX5043 to operate at 27 MHz. Every post I send it seems I get sent back to the same old threads and told to reference the data sheet. Let me try to be more clear.

  1. I am using the AXM0F343 which is a slightly different chip.
  2. I have compared the quality of the AXM0F343 at 27MHz with the AX5043 and the AX243, and the AXM0F343 seems to lack the sensitivity and consistency the AX5043 and AX243 have.
  3. The issue isn’t getting one AXM0F343 to lock at low frequencies. I have seen it lock at frequencies lower than 27MHz and still function. The issue is getting multiple AXM0F343 devices to lock at the same low frequency within a few Hz.
  4. I know I have the right external inductor to reach the proper frequency range.
  5. I am pretty confident that it is a software issue. That somthing isn’t being calculated or ranged properly. Yes, I did call the ranging function multiple times and no it did not fix the issue.

@alex.klassen

We do not 27MHz boards on hand at this moment.
Would it be possible to provide pair of populated boards, with 27Mhz matching network you are using , for us to check functionality based on forum link?

Please let me know,
Martin

@alex.klassen

1 - In looking at the AXM0F343 datasheet we can read on page 26, the following

"The AXM0F343 is normally operated with an external TCXO, which is required by most narrow−band regulation with a tolerance of 0.5 ppm to 1.5 ppm depending on the
regulation."

With 0.5 - 1.5 ppm, When using the following equation to convert ppm to frequency variation

We get a Freq Variation = +/- 40 Hz,

So that is theoretically the freq variation tolerance for the signal to go through.
Empirical data showed me that the freq variation at 915 Mhz was no higher than 70 Hz.

The answer to the question is the : Freq Variation @ 27 Mhz = +/- 40 Hz

2 - The analysis of the problem is locking up on the freq variation; while that is important for signal transmission; it is not the only factor to evaluate the signal . It is important to check the following factors

  • Power Stability
  • Spectral Mask
  • EVM
  • Signal Integrity
  • In-band Spurious emissions

All of the above could be factoring into the problem you are having.

Are you asking me to submit a list of parts and a complete schematic to see where the issue is, or physically send you two of our PCB’s so you can physically see the issue.

@alex.klassen

I was asking for two of your PCB’s so we can physically see the issue.
In addition list of parts and a complete schematic as well.

I need to get the green light from my department head first, but in the meantime if you could email me the specifics so I know where to send the package and to whom that would be great. TY

@alex.klassen

Please let me check details.

@alex.klassen
If you can please quickly do a sanity check on the section that was shared above that would be ideal prior to sending boards.
It is important to check the following factors

Power Stability
Spectral Mask
EVM
**Signal Integrity**
In-band Spurious emissions

All of the above could be factoring into the problem you are having.

Testing was done on both the AXM0343 and the 243. The results below are from the testing from the 343, It did not perform as well as the 243 under the same tests. Meaning the AXM0343 had issues locking at 27MHz and it cuts out at a lower RSSI. Also sorry about the glare in some of the photos.

Power Stability

  • This was powered with a 3V source from a switching variable power supply. Here is a link to the power supply we used. The power was monitored and measured for dips using an oscilloscope. The measured voltage varied from 3-3.26V. The switching from the power supply is very low and infrequent. Other supplies, drivers, and 3.3 regulators have been tested with the device and the same issues at 27MHz occur.

EVM & Spectral Mask

  • I do not currently have the proper equipment to check the EVM, and I am a little unsure how you would like me to check the spectral mask.

Spurious emissions

  • I have believe I have seen some spurious emissions, but they only occurred in one of the devices. Why they occurred I could not say, again, its the same hardware just a different AXM0343 chip. Therefore I can only conclude its the chip. Below are a few photos that will show kind of what I saw.


This was the First AXM0343 Which locked at the programed frequency of 27.17MHz. As you can see there was some noise in the room, and two spikes that occurred at 27.117MHz and 27.22 MHz. This was the first occurrence of spurs I have noticed across multiple devices, and again the issues I have involve more than the two examples I am sharing in this post.


This is what happened when the same code was uploaded on the second AXM0343 device. As you can see It not only was it off but lots of spurs. I had to adjust the the some of the PLL values in the program to get it to lock properly.

This photo is the second AXM0343 after the program was adjusted. As you can see this one is much tighter and no spurious emissions.

The AXM0243 never had these issues. No changes in the code generated by the utility tool was required. I think the AXM0343 is not locking causing the program to not function properly at low frequency’s. As for the RSSI I’m not sure where that issue would be, however I’m confident its not a power stability problem. I don’t know why the first device had a few spurious emissions, but they were not frequent or constant and I didn’t see them at all on the second device. I’ve had enough issues and inconsistency’s with these chips at low frequency’s to know that something isn’t functioning right and if you guys could take a look that would be great.

@alex.klassen

Power Stability This was powered with a 3V source from a switching variable power supply. Here is a link to the power supply we used. The power was monitored and measured for dips using an oscilloscope. The measured voltage varied from 3-3.26V. The switching from the power supply is very low and infrequent. Other supplies, drivers, and 3.3 regulators have been tested with the device and the same issues at 27MHz occur.

Power Stability
What was meant by power stability is the Tx Output Power stability in dBm measured by a power meter. It has to be stable with variation not exceeding +/- 2 dBm
The measurement of the output power can also be done with the spectrum analyzer or IQX, it should look like the following :

image

EVM & Spectral Mask

There is a utility added to some of the Spectrum Analyzer that allows it, its under “Measure”

Spurious emissions

Has the Spectrum Analyzer been put on “Max Hold”.

From the pictures attached it reflects that one of the boards is a lot noisier than the other.

It seems the Sensitivity issue follow the board that has the Spurious emissions. Its seems that is where the problem is. Is there a pattern to this behavior that we can characterize, how many boards do you have in hands that are showing the sensitivity issue ?

Please try to do the following:

  • Put the SA on MAX Hold and probe the board in sections to see if there is any component /XTAL/CLK that would be originating these spurs.

I don’t think the real issue is coming across. Or getting lost in translation. Can I please get a video meeting or a phone call to explain the issue to someone in real time. This issue is one of many that I have been trying to get answers to for months.

The power stability is not the issue.

As for how many boards do we have that have this issue, all AXM0F343 PCB’s. All the other prototypes we made using the older chip AXM0F243 didn’t have this problem. Why would just this device and not the older one have this problem?

I have been told that the people at OnSemi, by the people at OnSemi, have done very little testing of this device at 27MHz. I also know that you don’t have any boards on hand. Is it possible that something got added or changed between the AXM0F343 and the 243 that resulted in the device being less sensitive/accurate at low frequencies?

I have encountered similar problems in other bands before, I suggest that “Table 69. PLLLOOP, PLLLOOPBOOST” be configured as “External Filter Pin”, so that you can measure the DC voltage in FILT Pin to determine the VCO locking situation, the voltage control voltage range is 0 to 1.8V. If it is the only channel, the voltage is 1.8/2=0.9 is ideal; voltage close to 0V or 1.8V is not good, VCO is not easy to lock, especially when the ambient temperature changes.

2 Likes

Thank you so much, that lock definitely was part of the issue in terms of the sensitivity. Now comes the problem of consistency.

One of my devices locks at a PLLLOOP value of 0x84 and the other at 0X8D. I can find a value where they are all close, but I begin to loose consistency drastically.

I connected the output of my external filter to the GPADC (pin 37) and tied the other pin 38 to ground according to the data sheet and the App Notes. However it looks like it uses the VCO Cal Config which doesn’t work at low frequency’s.

Do you know if the feedback loop is used without the VCO Cal Config?

Any advice to automate the locking within the programing or do I just got to pick the best value and suffer the sensitivity loss?

Hello
I’m glad to communicate with you to learn
You mentioned the consistency problem description, I think the root cause of the problem or VCO is not locked, or may not be stable enough, if the carrier frequency error is too much beyond the ppm accuracy range given by TCXO, then you can be sure that the VCO is not locked, we suggest you use Internal Loop Filter, which is a good choice. In addition you can appropriately reduce the external inductor and connect small capacitors in parallel to the inductor to adjust the VCO frequency range. One problem is that your operating frequency point is near 27MHz, which is close to the minimum limit, you can try to increase the operating frequency point in the lab first to check whether the external circuit is stable?
When the VCO is locked, PLLLOOP value has a difference I think is normal, but should be a small change, because the VCO access to the external inductor may have different parameter errors.

Before we went to 27MHz, we started at 40MHz. We didn’t have this issue at 40MHz for a long time, then one day we did. I suppose its possible that board capacitance played a part, but I dismissed it when the 243 worked without a problem. It just seems as though the inductors all want to lock at different values that could be as much as 1MHz difference. I tried to tighten the tolorances as much as possible but it didn’t help.

For the record the TCXO we are using is 16.368MHz crystal. So it could be modeled closely to the 16MHz design used in the 5043 examples.

However your probably right, as when we use the internal filter we still get the loss of sensitivity. Only issue is if we decrease the inductance by 20nH it locks to high. I don’t like the idea of adding extra capacitors as its can add more tolerance but I guess I don’t really have an option.

I don’t suppose you have any better method than just soldering capacitors and guessing and checking?
What do you suggest best method for determining the lock? Just using the external filter with the default PLLLOOP (0x80) value and adjusting the carrier frequency till it has the perfect lock?

Hello
As you said, I really don’t have a better way to solve this problem. Like you I also encountered the same situation, before this I used AX5043, AX5243, and AXM0F243 chips respectively, AX5243 and AXM0F243 used without the problem of VCO not locking. When using AX5043 also appeared not easy to lock, initially I suspected PCB Layout problems, and tried to use different brands of inductors, but the consistency is still not good.
I’m sure the locking is different from yours, maybe your method is more efficient. My method is to measure the Vctrl (VCO Control voltage), if it is out of lock, the voltage is 1.8V, you can determine the external inductor value is large; when the voltage is 0V, you can determine the inductor value is small. vctrl voltage control internal varactor diodes to adjust the oscillation frequency, in the VCO discrete device circuit LC match is not good, not easy to oscillate is also very easy to appear, so I added capacitors in parallel.
If you find a good solution, please let me know, thank you!

2 Likes

Awesome thanks for the re-assurance, I have spent many hours looking for possible solutions.

I’m wandering if you might be able to help me with another issue. Just running some of the examples available at lower frequency’s sometimes causes the device to get stuck in a loop. I think its getting stuck in the interrupt handler. It has happened when re-programing or more often under Brown Out conditions. I think its getting stuck in the Hard Fault handler, more specifically GPIO_Exception_handler(). Theory is that it is that it is referencing the wrong clock on start up (TCXO). I know you were asking about it in a separate post. Is this something you have seen before?