0

High PER at 2Mbps

micka gravatar image

asked 2017-11-20 06:47:23 +0100

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?

edit retag flag offensive close delete report spam

Comments

Two things. Could be how you are doing the PER measurement? Which code are you using?

Also, could just be local WiFi traffic stomping on the Bluetooth signals. The narrow 1Mbps signals sit pretty well in between wifi channels but not so with 2Mbps signals. Try moving all the wifi stuff far away or turning them off. Also make sure you don't have a smartphone/tablet with you.

AmbystomaLabs ( 2017-11-20 14:36:06 +0100 )editconvert to answer

1 answer

Sort by » oldest newest most voted
0
micka gravatar image

answered 2017-11-20 18:17:45 +0100

Nope, no WiFi or anything else... Spectrum is almost empty here... the same difference regardless of what channel I'm using....

And at that distance, if anything would affect the reception to a large extent it would probably be receiver saturation in that case.... But it that case, why such a difference between 1Mbps and 2Mbps...

edit flag offensive delete publish link more

Comments

BLE is FSK so IMD in the receiver shouldn't be an issue. What software are you using to measure PER?

Also is highly dependent on how you load the channel, hence the software question. The raw rate is 2Mbps but does not include all the BLE overhead. So actual rate is less. If you just try to shove 2Mbps through the pipe you will always see a high packet loss due to the overhead.

AmbystomaLabs ( 2017-11-20 18:40:30 +0100 )editconvert to answer

Here is some more info on the expected throughput: http://infocenter.nordicsemi.com/inde...

AmbystomaLabs ( 2017-11-20 19:03:35 +0100 )editconvert to answer

Expected throughput is irrelevant in this topic... This has simply nothing to do with throughput at all actually...

I donated know what's confusing with the question... And where did BLE overhead come in to the question?

Let me clarify the question again so that we please could leave throughput and BLE overhead out of it since it's irrelevant... I'm not even using the soft device... And throughput and packet error rate is two completely different things, even though PER can influence the throughput...

Michael ( 2017-11-20 19:33:06 +0100 )editconvert to answer
  1. Prerequisite: no (or at least extremely low levels (approx -100 dBm noise floor)) external RF, no WiFi, no nothing (I live in the middle of nowhere).
  2. Node A is set up in nRF proprietary mode to listen on a channel, lets call it F.
  3. Node A is set up to restart RX again immediately after a received packet.
  4. Node B is set up in nRF proprietary mode with the same channel, F.
  5. Node B is set up to transmit a packet (approx 60 bytes of payload) every 100ms.
  6. Node A increases a reception pointer for each received packet.
  7. After 1000 transmitted packets (so after 100 seconds) node B stops transmitting
  8. 150 seconds (to have some margin) after the first received packet Node A will print its received packet counter

If using 1Mbps the counter is always in the range 999-1000, if using 2Mbps it's always in the range 700-800 ...(more)

Michael ( 2017-11-20 19:34:09 +0100 )editconvert to answer

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 ...(more)

AmbystomaLabs ( 2017-11-20 21:28:39 +0100 )editconvert to answer

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...

Michael ( 2017-11-20 22:00:42 +0100 )editconvert to answer

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.

AmbystomaLabs ( 2017-11-20 22:11:35 +0100 )editconvert to answer

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....

Michael ( 2017-11-20 22:15:09 +0100 )editconvert to answer

Ok, so the summary: 250kbps NRF: 0% loss, 1Mbps NRF: 0% loss, 2Mbps NRF: ~20% loss, 1Mbps BLE: 0% loss, 2Mbps BLE: ~20% loss

Will try replacing the boards tomorrow, just to exclude the possibility that there is some power issues.... I also tried lowing the output power, with same result... So lowering the TX power to -16dBm did nothing (still 0% loss at 1Mbps, and still high loss rate at 2Mbps).

Michael ( 2017-11-20 22:54:18 +0100 )editconvert to answer

If you wish, post your code and I will be happy to try it out first thing tomorrow.

AmbystomaLabs ( 2017-11-20 22:57:12 +0100 )editconvert to answer

Hi, did you try the new boards yet? Any updates?

Martin Børs-Lind ( 2017-11-23 16:31:40 +0100 )editconvert to answer

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools

1 follower

Stats

Asked: 2017-11-20 06:47:23 +0100

Seen: 68 times

Last updated: nov. 20