CC1101 Configuration for direct mode (CC1101::directMode)

[supcik]

Hello,

Thank you for your great library. I would like to use your library with a CC1101 in "direct mode" and I don't understand the following lines : (src/modules/CC1101/CC1101.cpp, lines 901-903)

// set GDO0 and GDO2 mapping
int16_t state = SPIsetRegValue(CC1101_REG_IOCFG0, CC1101_GDOX_SERIAL_CLOCK , 5, 0);
state |= SPIsetRegValue(CC1101_REG_IOCFG2, CC1101_GDOX_SERIAL_DATA_SYNC , 5, 0);

As far as I understand, those lines configure GDO0 as clock and GDO2 as data. But according to TI data sheet (https://www.ti.com/lit/ds/symlink/cc1101.pdf) and according to the experiments that I did with SmartRF Studio, it should be the opposite.

Chapter 11.2 (General Control and Status Pins) of the data sheet says :
"In the synchronous and asynchronous serial modes, the GDO0 pin is used as a serial TX data input pin while in transmit mode."

Chapter 27.2 (Synchronous Serial Operation) of the data sheet says :
"Data input (TX data) is on the GDO0 pin. This pin will automatically be configured as an input when TX is active."

So if I understand the data sheet correctly, GDO0 should be for the data, and we could use GDO2 for the clock. Can you please explain why you did the opposite and how I am supposed to use GDO0 and GDO2 with your configuration ?

Thank you in advance for your reply.

Best regards,

-- Jacques

[jgromes]

My understanding from the datasheet was that the mapping of GDOx pins was quite flexible - see Table 41, page 62. Checking with an oscilloscope, I can clearly see clock on GDO0 and data on GDO2 when in direct mode. Swapping them on the lines you mentioned has the expected effect - data being on GDO0 and clock on GDO2.

From my point of view, there doesn't seem to be preference, and I'm not sure why some parts of the datasheet suggest otherwise.

[supcik]

Thank you for your quick reply.

This constraint on GDO0 seems only to be required for sending. If we want to receive signals, then we can choose whatever we want. Did you try this configuration for sending as well ?

[jgromes]

Again, the GDOx mapping table seems to suggest it doesn't matter, but I will admit I haven't tested synchronous mode transmission, so I don't know for a fact. There's not even any sort of API in RadioLib for it; the transmitDirect() method is only used to generate unmodulated carrier for use in ham modes like RTTY.

[supcik]

Are you interested in a contribution from me ? I could make some tests and also extend the interface with methods to send the data in direct mode.

[jgromes]

Do you have a specific use-case in mind? I gnerally accept contributions if there's a real application. Also, it would have to be written in such a way that other sub-GHz FSK modules (SX127x, RF69 etc.) can also support it - similar do receiveDirect().

[supcik]

I don't have a specific use case in mind. I studied the CC1101 data-sheet and I thought that this direct mode could be interesting to try. Furthermore, I do not have access to other chips, so I will work on a forked repository and keep the changes locally.
Anyhow, thank you very much for your messages and for your very quick support.

[habub]

Hello @supcik,
I know this issue is old, but still open.
Did you ever make progress for direct mode (async) transmit?

[Qwerty4byte]

I am also looking for some code examples for Asynchronous mode, if you have any progress, could you please share with me, much appreciation in advance.