Expected PER while using DTM and 2 nRF-dev boards

RE: Expected PER while using DTM and 2 nRF-dev boards

endnode — Wed, 24 May 2017 12:34:02 GMT

Oh you are right, there are heavy changes in version 2.2.1 (2016-11)! Now it seems to me that BLE device might belong to "Category 3 equipment" (???) but I don't understand Tables 6/7/8 to be honest so hard to help how they imagine this test according to this new proposal. It looks to me like still under review, do you expect this being demanded for conformance in EU any time soon?

RE: Expected PER while using DTM and 2 nRF-dev boards

user123 — Wed, 24 May 2017 12:24:27 GMT

Im reading 2016-11 and to me it looks a bit different but I might be wrong

RE: Expected PER while using DTM and 2 nRF-dev boards

user123 — Wed, 24 May 2017 12:19:13 GMT

Hmm thats interesting. I will have to take a further look into that

RE: Expected PER while using DTM and 2 nRF-dev boards

endnode — Wed, 24 May 2017 12:18:17 GMT

Are you talking about "Receiver Blocking" part (section 4.3.1.12) of ETSI TS 300 328 (v1.9.1 from 2015-02)? It seems not applicable to BLE devices (or at least that's how I interpret " Applicability" section "In addition, this requirement does not apply for equipment with a maximum declared RF Output power level of less than 10 dBm e.i.r.p. or for equipment when operating in a mode where the RF Output power is less than 10 dBm e.i.r.p."). Am I missing something?

RE: Expected PER while using DTM and 2 nRF-dev boards

user123 — Wed, 24 May 2017 12:08:13 GMT

Well the test is done because of new RED requirements. So all new units needs to be approved by a blocking test specified in ETSI 300 328.

During the test no antennas are connected so there will be a coaxcable connecting the two units

RE: Expected PER while using DTM and 2 nRF-dev boards

endnode — Wed, 24 May 2017 12:01:51 GMT

Well that's not how DTM works. Receiver in DTM always checks integrity of PDU (there is 24-bit CRC as per BT LE packet definition) and then data length + content (there are 3 patterns available in DTM by specification). Any error means packet is logged as lost, however you have no idea what went wrong. To be honest that's how BLE and pretty much any radio works: once you receive something which doesn't match basic expectation for structure (such as preamble and integrity checksum) then you can hardly say if it was complete noise or just some part of the message got corrupted. From this perspective I don't understand what do you want to test...

RE: Expected PER while using DTM and 2 nRF-dev boards

user123 — Wed, 24 May 2017 11:56:26 GMT

I see ! Well what I actually want to do is a blocking test. So I want to send x amount of bytes and see how many bytes are lost.

RE: Expected PER while using DTM and 2 nRF-dev boards

endnode — Wed, 24 May 2017 11:26:15 GMT

Number of Tx packets is distinguished from timing between divided by 0.625ms, which can be precise if you have very good timing signalling. Note that DTM Tx commands are kind of "low cost" option, normally you should purchase one of these 10-100k USD radio synthesizers/analyzers which will tell you precisely how many packets were sent/received;) To your problem with 40B PDU length (is this what you are trying to do?): if you run DTM according to BT SIG spec v4.0/4.1 then it supports only PDU lengths 0-37B so you are out of range (DTM command is most probably ignored by the FW and so you get 100% packet loss because there is nothing transmitted/received).

RE: Expected PER while using DTM and 2 nRF-dev boards

user123 — Wed, 24 May 2017 09:02:52 GMT

So it's not possible to see the number of Tx messages sent in any way ? Also if I increase the length from 35 to 40 I suddenly get 100% error rate

RE: Expected PER while using DTM and 2 nRF-dev boards

endnode — Wed, 24 May 2017 08:35:28 GMT

And this is correct until you go down to -30/-40dBm Tx Power or start to shield/obstruct some unit (or move it dozens meters away). Note that if you are using Nordic examples (Python script) you have already several packets as systematic error so depedning on your statistic you can have 100% reliable link but still report 1-5% PER (note that DTM only reports number of received packets on Rx side but not number of issued packets on Tx side, that's done by timing and if you are using slow UART and some other middleware - such as any PC with serial driver and OS running - then you are way in millisecond range of delays/inaccuracy while DTM packets are using 0.625ms timing).