Wondering if anyone knows the maximum power output of the P1 module in mW’s? I’m trying to determine when the SAR testing can be excluded.
Using this information as a basis to start with:
http://www.lairdtech.com/brandworld/library/FCC%20-%20Part%202.1093%20RF%20Exposure%20Report%20-%20BT900.pdf
The datasheet doesn’t actually say, which is a bit strange (it just says “avail on request” so I guess you have to ask?)
Typically the max power output of the 43362 wifi chip in the P1 is ~17.5dBm when in CCK modes (beyond that the EVM goes down badly). For SAR you need to add the best (worst?) case antenna gain too; the antenna gain is also not specified in the P1 datasheet, but let’s assume it’s +1dBm.
That gives 18.5dBm max output power. To translate that into milliwatts, it’s 10^(18.5/10) = 70.79mW, which is over the 25mW level for SAR exclusion.
It’s possible to turn this down with a custom nvram file, at which point you’d likely remove or reduce the OFDM backoffs for 11g/n too (the nvram file specifies maximum CCK mode power, ie 11b, and 11g/n powers are specifed as 0.5dB backoffs from this value in order for the more complex modulations to stay within EVM limits - but with a lower 11b power there’s no need to have such large backoffs).
@hfiennes, wow thanks for the explanation! I’ll need another few days and a few coffees to understand it all.
@hfiennes, Can you please check out the below post? I am basically wondering if I combined a P1 and Bluz on the same PCB but only one radio was operating at a time (WiFI on and Bluz off or WiFi off and Bluz on). Would this have to be re-certified as an intentional radiator?
Thanks for any input.
If you have multiple radios on board, you cannot use modular approval. The FCC is pretty clear on that aspect. You will need to do your own intentional emitter testing including running both radios concurrently.
Whether or not your application actually has both radios active at once is immaterial… this is just like duty cycles; you can say all you want that your duty cycle is something tiny, but if the chip is capable of a higher cycle, then the test houses will want to test the thing the hardware is actually capable of.
You’ll also want to orient the antennas orthogonally to reduce coupling as much as possible. A wifi radio close to a bluetooth radio can damage the receiver chain of the bluetooth if there’s too much coupling - look at the maximum input level for the BT device and remember both are tuned to 2.4GHz!
@hfiennes, unfortunately that’s what I was thinking would be the answer. ;(. Thanks for the explanation.
did design the photon to expose the BT co-existence pins, whether they are supported in the current software load, or tested is another matter.
That obviously won’t help with the damage that @hfiennes mentions, but it can help by avoiding de-sense & retries because one radio is squawking while the other knows it needs to listen.
Put them as far apart as possible, and oriented to reduce coupling as much as possible; and yes - you’re looking down both barrels of a re-cert (along with test code to force all the combinations of Tx/Rx), I’m afraid.
That’s was I was really wanting to avoid, but we’re working on a plan B approach to avoid all the testing.
Basically we’ll have a separate module with just the Bluetooth and this module will be connected to the main board via a long USB cable. The main module will communicate then through the USB.
If these are both shipped in the same product, then that’s still a full approval required. The product still has two radios; modular approval is one approved emitter per product.
I’m afraid you can’t get round it that easily. If the second module was user installed (ie did not ship connected) then you may have a case for this, but if it’s in the same box and purchased at the same time it’s rather a gray area.