Disable Fine Grain Sequencing

I’ve had issues disabling the fine grain sequencing using dwt_setfinegraintxseq from the source code release for the DW3000 API. When I sent the command to disable, the sequencing was still happening. After looking in the DW3000 user manual, I found the magic value used to enable 0x4d28874 on page 224. I then matched this up with the PMSC_TXFINESEQ_ENABLE define in the source code. The corresponding define for PMSC_TXFINESEQ_DISABLE used to disable is 0x0d20874. There are no bit definitions for the register, and this value is not mentioned. On a hunch, I decided to try 0, and now the fine grain sequencing has stopped, and am able to transmit and recieve without failure. Prior I was able to receive the preamble, sfd and PHR, but was failing with the data packet on a Receiver Reed Solomon Frame Sync Loss. Can someone advise of the correct value to send to disable or confirm if 0 is the correct value? Thanks!

further research and comparison between the DW1000 and DW3000 user manuals…
DW1000 specifies the following

and DW3000 specifies

I have confirmed that writing a 0 on the DW3000 turns the fine grain sequencing off. Would like to get confirmation from factory on this

Hi @tmcgilvary,

Fine Grain Sequencing should not be disabled except for test modes like Continous Wave transmission.
The main reason to disable it for test mode is to be able to transmit frames in back-to-back mode(i.e no gaps between frames). If you would do that for the normal operation, that would result in increased current consumption.

Kind regards,

I am using a PA and LNA with my design, and according to the API guide, the fine grain sequencing is supposed to be disabled.(page 45 of DW3xxx software api guide) Additionally, I confirmed that when enabled, the preamble, SFD and PHR all get transmitted sucesfully, but the data fails, Looking at the LNA/PA swtich signal on the scope shows that during the data portion, there is alot of toggling of the signal used to swtich the tx/rx paths when enabled. When I disabled using the undocumented value of 0, the data portiion was then recevied correctly(toggling dissapeared). It would be nice to have further documentation on this feature and also to confirm that it is used in some design implementations. Thanks

Hi @tmcgilvary,

There was a bug related to your problem. When you disable fine grain sequencing by using the dwt_setfinegrainseq(0), the following register value should be used.

#define PMSC_TXFINESEQ_DISABLE 0x0d20010

However, it wasn’t the case for the driver that you have and this issue will be fixed in the next release of the SW. Therefore, the documentation regarding enabling external PA and disabling TX fine-grain sequencing does not require a change.

Moreover, the main reason for disabling TX power sequencing is that most of the PAs on the market are not responsive enough to follow our internal TX gain blocks. Therefore, we need to enable it even if the overall current consumption is increased. Otherwise, the GPIO will be turned off, especially during the DATA portion of the frame which would cause some issues in transmitted signal integrity.

Kind regards,

Hi @Emre_Ozbas_Qorvo
Thank you,

Would like to confirm though… You mention “Therefore, we need to enable it even if the overall current consumption is increased” I think we need to disable.

Also I confirmed the behaviour with the PA not responsive enough when enabled, and the data portion not making it through. See my first comment in thread.


Yes, you’re right. I meant that we need to disable fine-grain sequencing.

I am using the the source code for deca_device.c and therefore can change the value for PMSC_TXFINESEQ_DISABLE.

However, Qorvo is not releasing the source code anymore and the existing SDK has the wrong value. This implies that it is impossible to use GPIO5 to control the RF path because the sequencing will be occuring during the data portion of the frame.

The reason I post is that we are using the QM33120WDK1 eval with the nordic SDK and getting ready to test with RF eval boards. Using the QM33120WDK1 because of the SMA connectors. In analysing the changes, I realized I may have to port to my code to use the STM32F processor eval board. Would prefer to use the Nordic stuff since we are only testing the RF amplifiers.