cancel
Showing results for 
Search instead for 
Did you mean: 

Wi-Fi Bluetooth for Linux

Strider
New Contributor II

Hello,

First the problem: We constantly have an unexpected peak on 3.618 GHz (for channel 1) during the official RF testing of -37dBm while the limit is -47 dBm.

We are using a Raspberry PI Compute Module 3+ with a CYW43438 Wi-Fi module in our product, and this product has to be FCC complaint. 

Now we already have obtained the MFG test firmware for the CYW43438 as well as the WL utility. We also created FCC scripts which will put the chip in all the necessary FCC test modes (802.11b/g/n) in transmit and receive. Here a two examples of those scripts (maybe we do something wrong in these scripts)

# ------------------------------------------------------------
# Transmit 802.11b 5.5 Mbs on channel 1 with a power of 20 dBm
# ------------------------------------------------------------

wl down
wl country ALL
wl band b
wl chanspec -c 1 -b 2 -w 20 -s 0
wl mpc 0
wl ampdu 0
wl bi 65000
wl frameburst 1
wl rateset 54b
wl txant 0
wl antdiv 0
wl 2g_rate -r 5.5 -b 20
wl phy_watchdog 0
wl disassoc
wl up
wl phy_forcecal 1
wl phy_txpwrctrl 1
wl txpwr1 20
wl scansuppress 1
wl pkteng_start 00:11:22:33:44:55 tx 100 1024 0

# ------------------------------------------------------------
# Receive 802.11b on channel 1 with a power of 20 dBm
# ------------------------------------------------------------

wl down
wl country ALL
wl band b
wl chanspec -c 1 -b 2 -w 20 -s 0
wl mpc 0
wl bi 65000
wl frameburst 1
wl 2g_rate -r 5.5 -b 20
wl phy_watchdog 0
wl disassoc
wl up
wl phy_forcecal 1
wl phy_txpwrctrl 1
wl txpwr1 20
wl scansuppress 1
wl pkteng_start 00:11:22:33:44:55 rx

We already tried turning off all major (and even minor) other components on our product to check if they might be the issue, but so far no luck.

As soon as we execute wl down the peak is gone, and executing the wl up command will bring back the peak. This is why we ask on this forum, in the hope someone knows what is going on.

I included a screenshot of the peak in the attachments.

Note: the screenshot was made with our own equipment hence the difference in the dBm strength.

0 Likes
25 Replies
Strider
New Contributor II

We figured out that enabling the MPC (minimum power consumption) solves the issue. But now our question is should it be disabled for the FCC tests or can it stay on?

Fix change: wl mpc 0      ->       wl mpc 1

0 Likes
raks_99
Moderator
Moderator

Hi Strider,

Ideally, mpc(minimum power consumption) should be disabled with mpc 0 during the tests. What power levels do you observe in the 2.4G frequency?

 

0 Likes
Strider
New Contributor II

Thank you for your reply.

Yes, that is what we thought. I attached two screenshots of the test results. The transmit one is good, you can see the 2.4GHz transmit signal, and you can see the 3.6GHz signal below the limit.

But the receive mode one obviously has no transmit signal on 2.4GHz, and now (because the limit is lower) the 3.6GHz peak is above the limit by around 13 dBm.

We changed everything around our receive script, but only wl mpc 1 seems to help, but when this is enabled we can no longer start the packet engine with: wl pkteng_start 00:11:22:33:44:55 rx 

This is our current receive mode:

# ------------------------------------------------------------
# Receive 802.11b on channel 1 with a power of 20 dBm
# ------------------------------------------------------------

wl down
wl mpc 0
wl phy_watchdog 0
wl band b
wl country ALL
wl band b
wl channel 1
wl band b
wl up
wl 2g_rate -r 5.5 -b 20
wl phy_forcecal 1
wl scansuppress 1
wl pkteng_start 00:11:22:33:44:55 rx

But this will still give the peak at 3.618 GHz

We are also currently busy trying to test without our product, so a stand alone Compute Module 3+ directly connected with the CYW43438.

0 Likes
raks_99
Moderator
Moderator

Hi Strider,

Are you using a Murata module? What does your setup look like when you are doing the receive test? For receive testing are you using a WLAN packet generator to generate the packets?

0 Likes
Strider
New Contributor II

Yes we are using a Murata module. And even before we start to generate packets we already see the peak on 3.618 GHz. We are testing with our own product which contains this module, but because we also have a RFID and Wireless Charging chips within this product at a short distance from each other (less then 20cm) the Wi-Fi chip has to be retested. The only thing different is that we changed the default drivers with the MFG firmware and added the WL utility. 

We already get the peak after the following 3 commands:
wl down
wl mpc 0
wl up

Note: we disable all other components within our product, like RFID, Wireless Charging, Touchscreen, HDMI etc...

So we expect that it is not interference of an other component.

0 Likes
raks_99
Moderator
Moderator

Strider, so you only observed this in the mfg firmware and In the production firmware, you do not see the 3.6G signal after running the three commands? Can you share the mfg firmware version you are using? FW version can be obtained by running 'wl ver'.

0 Likes
Strider
New Contributor II

Thanks again for your response,

Unfortunately we also see this in our production firmware which is version:
Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f

Our MFG firmware version is:
Apr 27 2017 03:05:04 version 7.45.98.18 (r664830 WLTEST) FWID 01-ad1b7958

We also tested this MFG firmware on a official Raspberry PI 3 Model B (which also has a 43438 Wi-Fi chip, but from Broadcom) and we also see the peak, but the peak is 30 dBm lower, which would pass the RF test (see below).

Raspberry PI 3 Model B peak is around -105 dBm (measured on the chip). 

Raspberry PI 3 Model B (RF Test).png

Our product which uses the CYW43438 has a peak of -75 dBM (measured on the chip).

Screenshot (3.618 GHz) (1).png

We are still thinking that some kind of other component might be strengthen this peak in our device. But we don't know for sure.

If you have more up to date firmware than we would gladly test that out.

0 Likes
raks_99
Moderator
Moderator

This spurious emission might be due to the PLL output since that is also of 3.618Ghz frequency. Let me check internally for possible ways to suppress this output. I'll get back on this. 

Thanks.

0 Likes
Strider
New Contributor II

Thank you for trying to help us out.

We're looking forward to hear about your results.
In the mean time we will also continue to investigate and try to lower this output peak, if we manage to find out what causes this increase in dBm we will inform you as well.

0 Likes
raks_99
Moderator
Moderator

Hi, I have attached the latest FW version 7.45.98.118. Can you check if this is any better in suppressing the spur emissions? 

0 Likes
Strider
New Contributor II

Thank you,

We will try this out. Unfortunatly due to my holiday I can not test this out myself, so I forwarded this to a colleague of mine who will also keep track of this forum post. I hope he will/can update you on the results

Strider
New Contributor II

We did some quick tests with your updated firmware, and the results look very promising. We do sometimes see the peak, but very low (see image below).

Firmware:
Mar 30 2021 01:12:21 version 7.45.98.118 (7d96287 CY) FWID 01-32059766

Our next question is: do you have the MFG version of this firmware as well? Because as this looks very good, we can not execute all commands with this firmware. So we can't put the chip in specific transfer and receive modes.

New Firmware Test.png

0 Likes
raks_99
Moderator
Moderator

Yes, MFG version is available, but I am not allowed to share it with the public community here, do you have access to the cypress salesforce mycases system so that you can create a case? Or you can also request this through Murata.

0 Likes
Strider
New Contributor II

I'm not familiar with these kind of requests, but I think I created a mycase about this issue.
See mycase (00655580) if anymore information is needed, then please let me know.

raks_99
Moderator
Moderator

Thanks, I shared the firmware with you in the case.

0 Likes
Strider
New Contributor II

Thank you very much!

We are going to perform further tests and report back the results here.

0 Likes
raks_99
Moderator
Moderator

Sure, please do let me know.

0 Likes
Niek1
New Contributor

Hello raks_99,

I am the colleague of Strider and I have tested the new firmware. We can still see the peak just like before. I also noticed that the peak does not shift depending on the channel. Hopefully this helps a bit since I am not sure where the peak is coming from.

 

0 Likes
raks_99
Moderator
Moderator

Hi Stephen,

Is this Murata Type 1LD module? With the latest firmware, what is the power level you observed at 3.618Ghz, and what is the max limit that is allowed to pass the tests? 

Also, I have attached the latest clm blob file in the zip package, can check if this blob has any effect on the spurious output?

 

0 Likes
Niek1
New Contributor

Thanks again for your response!

 

We indeed have the Murata Type 1LD module. With the latest firmware the power level is exactly the same as in the screenshot above (-76.48 dBm). We are currently 10 dBm above the limit and wish to reduce the peak with 15 dBm to have some margin. So we would like to get to around -90 dBm.

 

I tried your new blob file but this had no result. The peak is still visible with the same power level (-76.48 dBm)

0 Likes
Strider
New Contributor II

This fix is only for receive mode, because the limits of transmit mode are higher we do not need to enable the MPC.

We only enable the MPC in receive mode.

0 Likes
Roy_Shyu
Employee

Hi Strider,

1. Would you like this product to be FCC compliant or CE or both?
From your screenshots, they are based on EN 300-328 limits, not FCC.

2. From your information and screenshots, the spurious emission should happen at RX mode.
But FCC does not have any specific limit for RX spurious emission.

3. Do you get those measurements at EMC chamber? or in your own engineering lab?

4. Do you get those measurements by air mode or conducted?

5. Please change this command:
wl txpwr1 20 --> wl txpwr1 -o -d 20

6. There is not any wl command to shrink such RX spurious emission.

7. Please use mpc=0 to test EMC items.

 

ROY

0 Likes
Niek1
New Contributor

Hello Roy,

This product has to be FCC and CE compliant. The screenshot are from our own measurement setup. The values visible in the screenshots are different from the values measured in the EMC chamber, this doesn't matter for us, since we only check if the peak decreases with the desired 15dBm during our own measurements.

From the official EMC chamber measurements done in RX mode channel 1 (see image below) we can conclude that the peak is 10dBm above the limit. 

Stephen_0-1629113938197.png

 

Al the measurements are done by air mode.

We indeed use mpc = 0 for testing.

Setting wl txpwr1 -o -d 20 did not help unfortunately. 

0 Likes
harelTur
New Contributor II

Hi 

I use this MCU and I have a problem.

When  I use commanda


..\wl%target% --serial %comport% down
timeout 5
..\wl%target% --serial %comport% mpc 0
..\wl%target% --serial %comport% phy_watchdog 0
..\wl%target% --serial %comport% country ALL
..\wl%target% --serial %comport% band b
..\wl%target% --serial %comport% up
..\wl%target% --serial %comport% scansuppress 1
..\wl%target% --serial %comport% 2g_rate -r 54 -b 20
..\wl%target% --serial %comport% channel 1
..\wl%target% --serial %comport% phy_forcecal 1
..\wl%target% --serial %comport% txpwr1 -o -q 52

..\wl%target% --serial %comport% pkteng_start 00:11:22:33:44:55 tx 20 1024 0


pause

 

 

after the cmd: pkteng_start 00:11:22:33:44:55 tx 20 1024 0

I think that the transmit not stop, and due to my current measure I see that the current increase to 11 mA for short time tnd than return to 4 ms .

 

What the problem? I need to continuly with the transmituntil I send stop command.

 

 

0 Likes
raks_99
Moderator
Moderator

Hi Harel,

This issue seems different than the one currently being discussed here. Can you create a separate thread for it?

Thanks,

 

0 Likes