Testing RX of CC2564 (not packed based)

Hi,

I hope the below post will answer your question.

http://e2e.ti.com/support/low_power_rf/f/660/t/311144.aspx 

Thanks, that clears up the mystery about these commands. 

But is there a command to test the RX part of the chip or the RX performance in any way?

Hi,

I am not sure, If I got you right.

But HCI_VS_DRPb_Tester_Con_RX  is the command used for RX testing. But the intention of this test is to put the device in receive mode. It is mainly used for current consumption measurements. 

If you want to test the through put on receiving side, you can use the SPP profile and receive data and check.

Currently the SPP is not working and i am trying to debug this problem. As I now have a module that is able to TX at the correct frequency (see my other thread), I want to test if the RX direction is working. Because of this, i am looking for a command or so to activate the RX path and get some information like received power or so.

But it seems like there is no such option?

Hi,

I think you can try the Packet TX/RX, and read the results using http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#HCI_VS_DRP_Read_BER_Meter_Result_.280xFD13.29

What is the host processes you are using?

are you using Bluetopia?  what is the problem you are facing with the SPP demo? 

>I think you can try the Packet TX/RX, and read the results using http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#HCI_VS_DRP_Read_BER_Meter_Result_.280xFD13.29

I will try this, and present you the results as soon as possible.

I am using a LPC1115 cortex m0 processor, so no MSP430. So I am not using the Bluetopia stack, as it's license requires the use of a MSP430 processor if I'm right.

When trying to send the command i geht the following behaviour:

Starting BER Rx Test
TX: 01 8B FD 11 4E 00 00 E5 10 00 20 00 CD 34 01 00 05 00 53 01 01

RX: 04 0E 04 01 8B FD 00

Sending receive BER results cmd:
TX: 01 AE FD 00

RX: 04 0E 44 01 AE FD 0C 80 44 18 00 E1 48 18 00 00 01 01 02 01 02 02 03 01 02 02 03 02 03 03 04 01 02 02 03 02 03 03 04 02 03 03 04 03 04 04 05 01 02 02 03 02 03 03 04 02 03 03 04 03 04 04 05 02 03 03 04 03 04 00 00

So starting the test mode seems to work, but reading the results gives me an 0x0C error (Command Disallowed)

What is wrong here?

Hi,

I did not see the below command execution I hope you are doing On the 1st device

http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#HCI_VS_DRPb_Tester_Packet_TX_RX_.280xFD85.29

From the spec 

My test setup is the following:

1. device:

Load init script --> invoke HCI_VS_DRPb_Tester_Packet_TX_RX (0xFD85)

2. device:

load init script --> invoke HCI_VS_DRPb_BER_Meter_Start (0xFD8B) --> wait for response --> wait 2 seconds --> HCI_VS_DRP_Read_BER_Meter_Result (0xFD13)

And now i see that somehow i got the wrong opcode for the HCI_VS_DRP_Read_BER_Meter_Result (0xFD13) command. Now i get a valid respone, but the result does not look too good:

RX: 04 0E 0F 01 13 FD 00 00 00 00 00 00 00 00 00 00 00 00

(Yes, the first module is running, and I see the frequency in the 2.4GHz band analyzer)

So I think the second board is severely damaged? I can't explain why this is happening

Ok after changing the BT-Adress and increasing the number of packets which should be received I get at least something:

Receiving 10 packets, modules close to each other:
00 01 09 00 F0 69 00 00 00 00 00 00
00 01 02 00 F0 69 00 00 00 00 00 00

modules 5 meters apart and a wall inbetween:
00 01 02 00 F0 69 00 00 C1 00 00 00
00 01 03 00 F0 69 00 00 15 0A 00 00

Does not look too bad, but why am I only receiving 2 or 3 packets, and on time even 9? What went wrong here?
 Why am I loosing packets even when there are no erroneous bits in the first example?

Hi,

Please try delay between “HCI_VS_DRPb_BER_Meter_Start” and “HCI_VS_DRP_Read_BER_Meter_Result” and see if it helps.

See here http://processors.wiki.ti.com/index.php/CC256x_Production_Line_Testing_Guide