Hi,
Scenario:
Two nRF52832DK boards on a table, approx 20 cm from each other, +4dBm output power.
Payload length is ~60bytes.
Running at 1Mbps gives me less than 0.1% PER, running at 2Mbps gives about 25% PER. (everything else kept identical)
Is this expected, or is there something at play here?
If using 1Mbps the counter is always in the range 999-1000, if using 2Mbps it's always in the range 700-800. This is regardless of what channel F I'm running on.
Sorry I referenced throughput. Most people test PER in respect to throughput. This is a requirement during ETSI testing and often is brought up in this forum.
What you are describing then is really lost packets and not PER since you are counting the number of received packets and not a ratio of CRC good vs. CRC bad packets. With your test setup it would be impossible to tell the difference between packet not sent, packet sent but not received (ie, lost) and packet received but bad and CRC error. You should improve the robustness of your test method by including counters on both ends and not just assuming the timing works out. Also on the receiver you should catalog CRC good vs. CRC bad events.
Another thought is in the mode you are testing you can do BLE2Mbps and Nordic Proprietary 2Mbps. The options show up in the enumerations for the mode register. There are minor differences in the gaussian indices for the GFSK and I believe that is it. It would be interesting if there was a difference.
Finally, even though you are convinced it is RF quiet in your local you should try outside of the ISM band just to be sure. The nRF52 operates from 2360 to 2500 MHz.
There are a lot of discussions on PER testing on this blog. Here are some good links: devzone.nordicsemi.com/.../ And a link to DTM PER testing: infocenter.nordicsemi.com/index.jsp
Please post back your final conclusion on the issue. It would be interesting to know what caused the problem.
In EN 300 328, that is relevant for me, there is no requirement on throughput... In what standard is throughput a requirement to test, I've not came across it so far? Receiver blocking is a requirement in several standards, but then you don't need to measure throughput...
I know that I'm sending a 1000 packets, since that's what my software do, and my Rohde&Schwarz spectrum analyser in zero span tell me so as well... It also tells me that I really don't have anything else going on here (unless I start anything to do so) in the ISM band. Obviously it does not tell me though if the nRF for some reason just likes to throw out garbage every 4th or so packet when configured for 2Mbps.
I'll try to see if there is any difference between the two 2 Mbps modes...
Hmmm, I'll take your word on EN 300 328 for now. When I used to do WiFi compliance we had to load up the channel and then test for blocking/desense. I haven't had to do this test for BLE.
Yeah, if you are counting the packets in zero span then I think you have covered that they are going out but as you said some may be garbage.
A quick sanity check that should be easy is a lot of people reference using off the shelf BLE sniffers ( or sniffer apps on BLE devices ) that are designed to report total packets and packet errors. This could be a quick and easy way to verify that the packets going out are clean.
Ah ok... Yeah, that might be something for the standards with wider signals perhaps... I was just a bit curious since I have never ran into the throughput tests - just the PER for receiver blocking (and the hopping with full load etc - but mainly for spurious emissions, not for actual throughput tests...
About to test the different modes now....
