Spurious signals when switching to/from transmit mode

[lixn_paulian]

Hi,

We have serious issues with a MK21D512 based transceiver: apparently the chip is generating spurious signals when switching to/from transmit mode. This leads to a substantial reduction in permissible power to achieve the FCC mandated adjacent channel attenuation as well as the Band-edge compliance. Our transceiver uses a FE + PA from Skyworks to achieve the 20 dBm output power. However, to eliminate other sources we measured the output of the bare-bone Freescale TWR-KW24D512 demo board, using the standard Freescale "Connectivity Test" software, with no amplifier (the board "as is"). Using continuous carrier modes (modulated or unmodulated) all parameters pass, however in PRBS9 mode where the transmitter switches on and off before and after each sequence sent, the issues are clearly visible. Attached are four snapshots that demonstrate the issue: first three are in PRBS mode at minimum (3) and paxiumum (31) power levels, and one image with a continuous modulated signal at maximum power. All images are taken with the spectrum analyser in Max Hold mode, after about 30 seconds of sampling the data.

Does anyone else found similar issues? Are there any solutions to this problem? Maybe with a different initialisation of one or more of the multitude modem registers in the chip?

Regards,

Lix

[zeshanyousaf]

Hello Juan,

Is "spurious signals" problem is also seen in the KW21Z?

Thanks.

[jc_pacheco]

Hello Zeshan, KW41Z and KW21Z share the same radio, so it should not present this behavior.

[dismirlian]

Hi William/NXP,

We have the same concern as Zeshan. We are evaluating the KW21Z for our next product, and I assume it has the same problem as the KW2xD.

It would be nice if NXP at least provided an explanation regarding the status of this issue... especially regarding that there is no errata sheet in the KW2x product page, and it's been 14 months (!!) since Mr. Lix Paulian pointed out the issue.

Specifically, we'd like to know:

- If the issue exists in the KW20Z product line, and the upcoming KW21Z.

- If the issue still exists in the latest revisions of the KW2x

- If there is a workaround to this problem

Please note that NXP advertises that the KW series has support for an external PA+LNA, but these statements are misleading because this functionality can't be used in practice! It seems only fair to us that NXP document this issue in an errata sheet, so we are at least warned that this problem exists before committing time and money to this ICs.

Thank you,

Diego.

[jc_pacheco]

Hello Diego,

We are currently investigating this, this issue seems to be more visible when using an external PA the standalone boards are FCC pre-qualified.

As described above, the "spurious signals" are being presented as switching transient that is just 10's of ns wide, only noticeable when using Continouos PRBS9 test and leaving the MAX Hold on the Spectrum Analyzer for more than 30 seconds.

KW+PA integration should be supported, we appreciate your feedback and will verify a more straight fwd way to demonstrate its implementation.

We tested that this issue is not present in KW41Z.

[zeshanyousaf]

Hi WIlliam,

Currently we are planning to use MKW2xD for Sensor application. Did the above mentioned problem got solved? If yes, what is the solution?

This problem can force us to switch to other SoC.

BR

Zeshan

[jc_pacheco]

Hello Zeshan,

We are currently investigating this, this issue seems to be visible when using an external PA. As described above, the "spurious signals" are being presented as switching transient that is just 10's of ns wide, only noticeable when using Continouos PRBS9 test and leaving the MAX Hold on the Spectrum Analyzer for more than 30 seconds.

We tested that this issue is not present in KW41Z.

[billpoole]

I have been looking at a transmitted signal today.

I also notice something similar in MAX-hold mode.

I then tuned the spec analyzer off 20 MHz and set it to zero span and I do see a switching transient that is just 10's of ns wide. Its not clear if this is created in the spectrum analyzer or part of the transmit signal, it appears as though the rising edge of the transmit signal is also very narrow/fast. So this could be a switching transient caused by fast rise time.

I am reviewing with others here to see if there is a registers setting or other provision to adjust the rise time or some other explanation for this issue.

I'll report back when I find something.

Bill Poole

Freescale Semiconductor

Connectivity and IoT Solutions, Microcontrollers

Applications Engineering

[lixn_paulian]

Hi Bill,

Thank you for the posting.

We also thought at first that this might be an artefact of the Spectrum Analyser, but the matter of fact is that the test house that tested our device for FCC compliance found the same issue and they classified our device as not compliant at the band edges. Basically what they said is that we can only use the device if the output power is set at 0 dBm for channels 11 and 26 and 6 dBm for channels 12 and 25. Channels 13 to 24 can be used at full power (in our case 15 dBm). And this is quite annoying as we've basically lost at least two channels.

Lix

[billpoole]

Sorry I don't have a positive update, I am reviewing this issue with others internally and comparing it to similar issues seen elsewhere.

There does not appear to be a register to control rise-time, however, one of our engineers suggested a test you may be able to perform would be to delay the PA turn on until after the TX rise time. This is likely of no help of the rise time of the PA is faster than that of the TX, or if PA is always on. If you are using TX_Switch to control the PA TX mode you may not be able to control the timing of that pin either. Depending on how much control your software has, you may be able to use a GPIO to control those pins. Another thing to try might be setting ANTX_HZ to 1 (Hi-Z that pin) prior to the start of the transmit pulse then 1us after the TX pulse starts have software set ANTX_HZ back to 0.

None of my EVBs have a PA so I cannot try to perform the above tests.

If I learn anything new I will provide more info.

Bill Poole

Freescale Semiconductor

Connectivity and IoT Solutions, Microcontrollers

Applications Engineering

[jasonchiang]

Hi Bill,

     I also have the similiar question like Lix described.  I just used KW20 EVB and load connectivity test code running with PRBS9 mode, CH26, Power set to 30, set max hold at spectrum analyzer. I got below test results. Any comment ?

[lixn_paulian]

Hello Bill,

Thank you for your suggestions.

We are indeed using the TX and RX Switch signals to control the FE (PA + LNA), therefore only your suggestion to switch the TX control pin to HI-Z is applicable. However, I assume this must be done somewhere deep in the Freescale libraries ( i.e. PHY) to be effective. Most difficult I guess would be to properly assess the moment in time "1 us after the TX pulse starts". Could you elaborate on this issue? We could try this work-around.

Regards,

Lix

[AngelC]

Dear Lix,

This is very strange since TWR-KW24D512 boards passed FCC certification. Could you please specify the board revision number you are using? We Would like to replicate the tests and double check there is not any issue.

Regards,

AngelC

[lixn_paulian]

Nobody has, or is affected by this issue? Before we start playing around with the modem registers in the slim hope we can improve the dynamic behaviour of the chip during switching to/from Tx mode, maybe someone else or someone from Freescale has already done this.

Lix

[AngelC]

Dear Lix,

My colleagues are working in some tests to confirm the issue you described.  They will post their findings in the next few days and help you further with it. I appreciate your patience.

Regards,

AngelC

[lixn_paulian]

Hi AngelC,

It seems your colleagues did not find anything, did they?

To be honest we don't know if this dynamic behaviour is normal for this kind of applications, and perhaps our testing house went over their attributions, or indeed there is a problem that would void an FCC certification.

[lixn_paulian]

Thank you, hope to hear soon from you.

[lixn_paulian]

Hi AngelC,

Our board has two labels: SCH-27845 Rev C and 700-27845 rev X4.

However, I have no doubts that the board itself is 100% FCC certifiable, because of its relative low power output. If you attach a 20 dB amplifier after the chip, then the spurii will be also amplified to such an extent that some parameters as e.g. Band-edge compliance will not pass (we use the Skyworks SE2436L, our goal was to reach at least +20dBm output). The net effect was that we are forced by the test house that did our testing to reduce the maximum power to +15 dBm and at the edge band channels (11, 12 and 25, 26) to +1, respectively +6 dBm. At least for these channels, it defeats the use of an amplifier! The problem is that the Band-edge compliance test specifies absolute values and not relative to the carrier level.

Please note that from the diagrams above the spurious signal levels are about 10dBm over the baseline (modulated or unmodulated continuous carrier). This is in fact the amount of power lost in in order to pass the FCC's Band edge compliance test.

Anyway, to evidence the issue is very simple, just hook the board to a spectrum analyser, switch it to PRBS9 transmit mode: you will see the occasional peaks jumping around the carrier. If you switch the spectrum analyser to hold mode, after 30 seconds or more you will see the baseline growing with about 10 dBm. This does not happen in TX continuous mode, both modulated or unmodulated. Clearly, the transmitter switches the internal PA too early (or too late when the T sequence is done), before the PLL is fully stabilised, or maybe there is a pulling effect on the PLL when the internal PA is switched on. Our hope was that Freescale knows about this issue and that there is maybe a modem register that can be tweaked to eliminate, or at least attenuate this effect. Otherwise we will have to look elsewhere to other competing solutions. It is rather disappointing as we have already invested quite some time and money in this project.

Lix