We are doing some FCC testing of our Electron device, and we are failing the tests at a few frequencies that seem to be correlated to the Electron’s clock. Specifically, these frequencies are: 147 MHz, 175 MHz, 198 MHz, 240 MHz and 257 MHz.
Some background: we have a PCB the Electron mounts to that is relatively simple FCC-wise, as it has no other intentional radiators and no other noisy components other than possibly our switching regulator. Also, this is one of a few leads we are chasing down for not passing these tests – we plan to adjust a bunch of other things the next time we go in.
Next time we go in, we plan to put Electron in deep sleep, to eliminate this as a possibility, but in the meantime, we’d like to play with the Electron’s internal clock speed to see if we can adjust these peaks.
So my questions are:
- Has anyone experienced a similar issue? Anyone else gone through FCC unintentional radiator testing with Electron?
- Are there any consequences of changing clock speeds that may be unintended? Like modem communication goes haywire?
- I plan to adjust clock speeds by editing this file.
- Is this the right place to adjust clock speed?
- Is there an API, like through a STARTUP() macro that might be a better place to do this?
Thanks in advance for any input!
In technical terms the case plays a role
I guess you mean MHz and not mHz, since mhz is unknow to me, right?
I’ve updated the post to reflect MHz, thanks for the input. Sorry to confuse you with this.
It’s fairly unlikely that a 26MHz crystal oscillator will give you any of those frequencies; none of them are harmonics of this. As the STM32 has no external memory buses, there are generally also no externally driven pins that will leak a relative of the internal 120MHz PLL either (though obviously 240MHz is a bit suspicious).
The noise could be coming from the cellular module though, as that has other clocks inside it, but usually they’re pretty quiet (as harmonics often land in the cellular band which would impede operation).
What makes you think the noise is coming from the electron? Can you remove the cellular module from the testing by powering it down? Usually in cases like this you keep adjusting things and seeing how the spectrum changes to narrow down the source of the issue.
Is your board 4 layer?
I’m curious how much this FCC testing is costing you guys?
Thanks for the input.
Our board is 2 layer.
On our next trip in, we will definitely be shutting down the cellular modem. That is on our list of test procedures, and it very well may be the main culprit. Right now, though I am looking to other avenues as well.
I only think it could be coming from the Electron, because each of those peaks I labeled above (with the exception of 257 MHz) fit into the following pattern:
146MHz could be 120MHz + 1 * 26MHz
174MHz could be 120MHz + 2 * 26MHz
198MHz could be 120MHz + 3 * 26MHz
240MHz is the VCO freq.
My understanding of the Electron’s operating frequency is: the Electron’s crystal is 26 MHz, which then gets divided by 26 to 1 MHz, which is then fed into the PLL multiplier of 240, and then divided by 2 to the uC’s operating frequency of 120 MHz. Is that correct?
Anyway, I am ultimately looking to understand what the effects of changing the operating frequency of the Electron might be. Specifically:
- Has anyone operated an Electron at a different frequency?
- Would modifying this file accomplish my goals to modify frequency for testing?
- Any specific problems that might come out of modifying Electron operating frequency?
@RWB, PM me if you’d like info on who we are using.
The PLL does work like that yes, but it’s on-die and at a low amplitude (it runs at the core voltage which is ~1.2v). Many imp-based products have been through approvals and the first 2 generations used STM32F205’s at 120MHz but nobody has ever failed on a PLL harmonic (or PLL+xtal).
In many many visits to EMC labs I’ve never seen emissions-limits-busting peaks from mixed frequencies.
You can very easily change the PLL setup on the STM32, but this then has knock-on impacts on the AHB and APB bus frequencies, which means things like baud rate divisors have to be recalculated. Even if this moves the peaks, they’re still likely to be the same amplitude, so you’ve only proved where they are coming from, not got any closer to shipping.
If I were you, I’d make my board 4 layer, with a good solid ground and power plane, and retest. This is pretty cheap, gives you a cleaner board layout, and will absolutely improve your EMI performance. Getting 2 layer boards through EMI tests, especially when you have power hungry digital components on them (like a cellular baseband) is not easy… it’s generally much cheaper to pay the 4 layer tax.
@rickkas7 anyone from the engineering team with some good inputs?
Thanks for the input @hfiennes, very helpful.
One more question: in this thread you say “…you’ll still have to do FCC 15b for unintentional radiator, but you can do this with the radio part turned off.”
Can you point to a source for that quote? I see it in the Taoglass PDF you linked to, but I can’t seem to find it anywhere else.
And the follow up question would be – if we pass the testing with the modem off, and fail with the modem on, what are the implications?
See slide 14 here: https://transition.fcc.gov/oet/ea/presentations/files/oct09/ModularTransmittersReview_%20Oct09_JD_TH.pdf
- Your device has a transmitter that has modular approval
- There are no other transmitters in the product (see other notes in deck about combining multiple modules)
- You label the final product with the modular approval ID
“Except for RF exposure and radiated power and/or radiated emissions, additional equip. auth. not needed”
So you’ll still need to meet SAR regs (if the product is used anywhere near a human body), and still do radiated emissions testing (ie part 15B), but you don’t need additional equipment authorization.
You will certainly fail 15B if you have ANY transmissions, because you’ll exceed the unintentional radiator limits… because you have a transmitter.
If you have bad harmonics from non-transmitting parts of the modular transmitter then you probably fall foul of the “Original module test data represents same characteristics in final product” note on that slide - ie you’ve made the original module behave worse than the test data suggested - and you know this, as you’ve done testing so you can’t exactly plead ignorance.
From what I can see, Particle are not actually testing STM32+cell (someone correct me if I’m wrong?) but rather just quoting the modular approval of the uBlox module. If that’s the case, it’s quite possible that the Electron might fail 15B from the STM32, which implies that the modular approval is not applicable.
When you next go to the lab, can you take another particle-supplied board (eg asset tracker?) and see what the emissions there look like? You won’t be able to improve over what the actual Electron emits by itself…
It looks to me, from this report, that Particle did testing on the Electron itself. There is not a chart for the frequencies I am concerned with, but they do post some values. Is this what you mean @hfiennes?
There is still something wrong at the FCC’s site when you follow the link they have to FCC ID: XPYSARAU260 under https://docs.particle.io/guide/how-to-build-a-product/certification/#fcc, though, so I am not 100% sure that the above report is the final.
Yes, that test does show it working (without a host board), at least at 1900MHz - though given that Hong Kong doesn’t have 1900MHz networks that I’m aware of (only 850/900/2100) I’m not sure what it was talking to. HK does have an 850 band which should have worked with the U260 though.
Yes, the XPYSARAU260 modular cert refers to just the uBlox module.
Sorry, I made a mistake when saying our board is 2 layer – its a 4 layer with solid ground and power planes.
What do you mean by “the XPYSARAU260 modular cert refers to just the uBlox module”? Do you mean that Particle did not do Part 15 Subpart B for the Electron, they just used the modular cert from uBlox?
Ah ok, so you already have the 4 layer magic
Yes, the FCC ID refers to the uBlox module. However, the test report you linked to refers to the entire Electron. This is really a question for Particle obviously!
@will, can you comment on this thread? Some questions that seem to be up for debate:
- How does the report I linked to above tie to the FCC ID “XPYSARAU260”?
- Further, why does this link show documents for the Photon?
- Has Particle ever done FCC testing or any other intentional or unintentional radiator testing with the Electron on a host board? If so, do you have information you can share?
The Electron leverages the FCC ID of the u-blox module. This simply means that we leverage the existing module tests already completed by u-blox when certifying the Electron as a finished design that is compliant with and builds on the original certification from u-blox.
Customers integrating the Electron into their end products similarly would complete a verification of certification, instead of an from-scratch original certification, that leverages the same FCC ID from u-blox. The design and emission behaviors of the Electron itself has been verified to comply with all FCC standards.
We have not directly completed any additional FCC certifications with the Electron on a host board, although we have completed EMI and EMC testing of the Electron integrated into an end product without complication or issue.
What version of the Electron hardware are you completing FCC testing with? There should be a version indicator on the physical PCB.
Thanks for the response @will,
I cannot tell what Electron version we are using. The electron is soldered onto our test board. It has blue writing on it, so its pretty new. Another electron from the same batch that I have handy looks similar and is v020.
We went back to the emissions testing lab, and it seems our first test was not setup well. Wiring from within the chamber to the outside was leaking some emissions into the chamber, which pushed us above our limit at 170 MHz. The end result is that we seem to pass the Class A tests with a pretty good margin.
With that said, we did do some digging into where some of the peaks were coming from, even if under limits. I’m posting the results here just for others’ information:
- Our peak at ~170 MHz reappeared, if at a lower level, when the Electron was charging the LiPo. It went away when Electron was not charging and reappeared when Electron started charging again. This would might be an issue for us if we were going for Class B.
- Our peaks at 200 - 270 MHz were lessened but they existed in basically all of our test setups, except in the setup where the Electron was not powered (we can switch power to Electron on our PCB). 230 MHz to 245 MHz seemed to be worst for us.
- I did not end up changing the Electron’s clock speed
If you have the box that the electron is shipped with, I think it has a barcode somewhere.
This electron came in a pack of 50, and I am not sure I still have the shipping materials.