Remote mic protocol - accessword uniqueness

I have been developing an app using the remote mic protocol and I recently began investigating the effect of changing the accessword on the Rx device relative to the fix one on the Tx device. I am noticing that it takes a relatively large difference in the Rx accessword in order for the Rx device not to connect to the Tx stream.

I’ve read through the RFFE section of the h/w reference manual, as well as studying the register definitions and the rm_pkt_hdl.c functions. From what I can tell, it appears that the PACKET_EXTRA_PATTERN_MAX_ERROR bitfield in register RF_REG0C should set the (I’m assuming) number of allowable bit errors in the over the air received PATTERN word vs that stored in the PATTERN register (aka, the RM accessword). The remote_MicLib sets that error number to 0, which I am assuming means the received PATTERN word must match identically with the accessword. I am not observing this behavior, as I can use many different Rx accesswords that are similar to the Tx accessword and the Rx link will be established.

I am hoping to be able to provision various devices and “pair” them with the same accessword; but I also want to ensure that additional devices with different accesswords are not affected.

Am I missing something here or must I select accesswords that are different by one another by some number of bits in order for them to not inadvertently link?

1 Like

Hi @mbianchi ,
For our remote mic protocol “pair”, there are 3 key parameters which can be used for TX/RX devices matching.

  1. hopping list. (like RM_HOPLIST).
  2. Accessword. (like app_env.rm_param.accessword )
  3. Modulation Index. (like app_env.rm_param.mod_idx)

You are right, you could take a relatively large difference in the Rx accessword in order for the Rx device not to connect to the Tx stream.
If you only have 1 or two bits difference, the sync word detection is a bit of hard to detect.
(Typical we use 3 errors for PACKET_EXTRA_PATTERN_MAX_ERROR. This means that it takes much less t time for detection)

Requirement:
“I am hoping to be able to provision various devices and “pair” them with the same accessword; but I also want to ensure that additional devices with different accesswords are not affected.”
Answer:

  1. You can use different 3 key parameters to build different groups. not only accessword.
  2. Use more bits difference for accessword for difference group.
2 Likes

Hi @larry.zhu ,

Thanks for this useful information - this explains a lot.

I have some additional questions/clarifications based on your response:

  1. Does PACKET_EXTRA_PATTERN_MAX_ERROR specify the number of bit errors allowed to qualify a PATTERN as a “match”? Is that value 0 - 3?
  2. What happens when the RX packet’s PATTERN does not match (i.e., there are > _PACKET_MAX_ERRORs detected)? Does the the RF_RXSTOP_IRQ not fire or instead is DESER_STATUS_DESER_FINISH bit not set? There is not any explanation about how not PATTERN matching is processed.
  3. You mentioned that typically you use a value of 3 for the _PACKET_MAX_ERROR register value, however the rm_pkt_hdl.c code sets that value to 0. I would expect that with it set to 0 that it would be hard for the RX device to ever connect if the accessword differs by a small amount, yet it does seem to connect fairly easily; that doesn’t seem to make sense.
  4. The modulation index (rm_env.mod_idx) is set to either BLE_MOD_IDX or BT_MOD_IDX. Does BLE_MOD_IDX configure it to be 0.5 and BT_MOD_IDX configure it to be 0.32? The Firmware Reference doc mentions these two mod index values, so if what I have stated is true and I am using only RSL10 devices for TX and RX, then it seems like I should always use BLE_MOD_IDX for better performance.
  5. Does increasing the PREAMBLE length from 1 to maybe 2 or 3 bytes help the overall performance, perhaps reducing the error rate of the following PATTERN word? Adding an extra byte or 2 to the packet seems worthwhile if it does improve things at all.

Thanks again for your help here.

1 Like

Hi @mbianchi ,
Q1: Yes. I think it is correct.
The value can be used for maximum number of bits that does not need to match the sync word.
It is up to the user to choose its best configuration.
a. If a packet is sent randomly and it has to be sure that the packet is detected, then accepting 3 errors can be suitable; this means that the false positives are acceptable.
b. However if missing a packet sometimes is accepted then 0 errors can be set.

Q2: If the pattern error is detected, the whole package is ignore. Treat it like noise. There is no interrupt.
when RXSTOP_IRQHandler is fired?
when the FSM stops the Rx mode, independently of the fact that a packet has been received or not.
IRQ_RXSTOP could be generated for any receiving packet with crc correct, crc error, and packet length error.

Q3: As I explained in Q1, it is set to 0, it should be fully matched. If there is noise, it is hard to keep sync.

Q4: No. BLE_MOD_IDX (0.5) is for standard BLE. BT_MOD_IDX (0.32) is for our remote mic protocol (RMP).
When you use RMP, it is better to use 0.32. this can reduce a lot of BLE signal noise.

Q5: Since there is no detection for preamble, I don’t think increasing Preamble byte can have better performance. We already have used CRC for packet. Increase extra bytes to packet? I don’t think it can improve it.

1 Like

Hi @larry.zhu ,

Thanks for your quick answers! I think I now have a good idea of how I should configure the product to optimize TX/RX connection and also to ensure “non-paired” devices don’t connect to incorrect TX devices.

2 Likes