CC1101 Sending more than 63 bytes with FIFO

[Crsarmv7l]

Branching a topic from here: #842 (reply in thread)
and here: #842 (reply in thread)

After a bit of work last night, I was able to send (and verify via rx on a different computer,) 97 bytes via the FIFO (granted I was trying to send 100 bytes so still a lot of work to be done).

Key points and settings for what I currently did:

• Fixed packet length must be set to the total number of bytes you wish to send (max is 255 per CC1101 data sheet and TI DN500).
• Fill the FIFO with the max number of bytes it can hold (63).
• Repeatedly check the TXBYTES register to check the number of bytes in the FIFO
• Add bytes to the FIFO as space is made available to load them, up to the Fixed packet length

Downsides:
I am doing this in the simplest way possible. Hammering TXBYES with SPI transactions and plopping bytes in one by one with SPI. I was using a 2 kbaud Datarate for TX which is relatively slow, and the FIFO still ran dry before the last 3 bytes made it in. Once the FIFO runs out the packet is done.

Ti DN500 also discusses interrupt usage which is clearly needed and what is present in the Stream examples. The Link2 example provided by Ti uses the interrupt by setting FIFO_THR and configuring IOCFG2 to assert/de-assert. Pretty complex which is why I started with the simplest possible form via SPI.

I'll see what I can do with interrupts, but at least now I know it is possible.

[jgromes]

@Crsarmv7l If you're interested, I can push my work-in-progress files into a new branch here. Like I said before, it doesn't work and I'm not sure why, but maybe it will be useful to you.

[Crsarmv7l]

Sure, absolutely! That would be great thank you

That's why I made this topic, maybe you have an "AH HA!" moment or maybe you see something I miss as I fiddle with this.

If it is very similar to the SX127x stream example it might be simple, because with that chip you wait till the buffer is empty to refill which you can't do with the CC1101. As soon as the buffer is empty, tx stops and remaining bytes are ignored (where my 3 missing bytes went in my experiment).

I'm not the best programmer but I am gonna get this working.

[jgromes]

OK, I pushed it here: https://github.com/jgromes/RadioLib/tree/cc1101-stream

Good luck ;)

[Crsarmv7l]

Thanks I'm sure I will need luck 🤣

[Crsarmv7l]

Some very interesting results from playing around with fifo refills.
(All tests were simple 0xAA, 0xAA, etc at 100 total bytes... I have yet to verify actual data integrity.)

• First I tried reading TXBYTES and then writing to the TXFIFO with predictable results. No idea how my first post here I got such a high throughput. I may have been confusing hex values with bytes (it was late lol). I tried again and out of 100 bytes I was getting maybe 66 bytes through...at 2 Kbaud.

• Then I figured the FIFO will outrun the SPI transactions anyway, and you have to start txing prior to refilling. To be on the safe side I wrote bytes 1 by 1 until the end of the packet and did the initial fill at 64 bytes.

That actually worked pretty decently, netting about 82-89 bytes out of 100 attempted, testing with 2 Kbaud and 8 Kbaud. Kinda jank though and wont be consistent. Plus I wonder if it was 82-89 bytes in order (Could be bytes 1-64, then some random ones) . No data integrity test.

I also messed with the SPI freq which improved things a bit, but also inverted the signals at some point. A rxed signal would be AAAAAAAAAAAAAA555555555555555555 or even alternate back and forth. This idea was borne from Table 22 SPI Interface Timing Requirements on page 30 of the datasheet.

• Just now I worked ISR's into CC1101.cpp. I like this idea because it would allow people to try to send bytes <= 255 limit and could return how many bytes were actually sent. It is also seamless. If the packet length is too long, return an error. If it fits in the FIFO, it just uses the FIFO. If longer than the FIFO but less than 256 bytes, it tries to send it, without the end user having to set up ISR's etc.

Still need to set up fills and burst writes, but to start with:

I set up GDO2 as follows for the interrupt (triggers a flag func with volatile bool)
SPIsetRegValue(RADIOLIB_CC1101_REG_FIFOTHR, 0x0E, 3, 0); (trigger at 5 bytes remaining per page 72 of datasheet)
SPIsetRegValue(RADIOLIB_CC1101_REG_IOCFG2, 0x02, 5, 0); (per table 62 of the datasheet)

Just to test it was triggering correctly, I loaded up the FIFO fully with 64 bytes and read TXBYTES before strobing TX. It showed 64 bytes. Sent tx, and once the interrupt triggered read TXBYTES repeatedly. It showed 4, 4, 3, 3, 2, 2, 1, 1, 0, 0 !!!!! WOOOO triggering where it should.

These readings are a bit misleading as my SPI Freq is currently set at 5500000 which is a lot faster than default. I need to run the tests again at normal Radiolib SPI speed as between the read start and read end, a byte was sent. With that kind of stat on normal spi freq it would give a decent compensation factor.

More tests required but a decent path forward (The correct way would probably be DMA, as even with the ISR and trying to compensate for the SPI transaction there is no way the FIFO doesn't outrun me.... but DMA is way out of my wheelhouse.)

[Crsarmv7l]

😮‍💨

Just found a stupid mistake I made that renders everything I tried inaccurate.

In a for loop transferring from the main buffer to a smaller buffer used for burst write I was using my position in the main buffer (txPos) in the transfer reference with txPos++ instead of i + txPos.

After the burst write I was setting txPos = txPos + small buffer, so it was all being incremented twice. I fixed the above. Don't want to change where we are in the main buffer until after the burst write, and I allow the small buffer to be filled with a gate that stops another fill until after the ISR asserts and the burst is written.

I wonder if this issue was present in my other versions.... I still like the interrupts better.

Fixed and try again later...

[jgromes]

This sentence pretty much sums up my experience with the CC1101 ;) Try to do something -> it almost works -> find a stupid mistake -> start over. I'm fairly certain you can get it done though :)

EDIT: BTW, have you taken a look at how other modules (e.g. SX127x) implement the stream mode? From what I understood about the CC1101, ithe behavior should be similar, basically filling up the FIFO to some level, then triggering an interrupt to refill.

[Crsarmv7l]

That is what I am doing, triggering an interrupt when the FIFO needs to be refilled. I need to set up another interrupt for when the FIFO is above the threshold. Just blindly setting the flag to false assuming the buffer is full, while it still continues to empty as it is being filled is not cutting it I think.

I have another function that returns byte arrays and the size of the arrays, so it took me a bit to get down to the bare spiTransfer and get it working. No point doing the memcopy and other stuff with SPIwriteRegisterBurst that is recreating what I already have.

Which also means I am happy to share if I get it worked out....but probably not something you want in the repo given how messy and very specific it is.

My current attempts result in between 85-93 bytes being sent out of 100. Still no point checking integrity until I can reliably get the full amount.

I had assumed I was underfilling the FIFO, but maybe I am overfilling it? An interrupt would certainly help me figure out which one at least.

Basically in peudo code:

while (position in the packet < signal length) {
    while(interrupt) {

        Start spiTransfer code;

        for (i = position in packet; i< signal length; i++) {
               if (interrupt ==false) {
                   break;
               }
               else  {
                     spiTransfer with burst reg and data[position in packet ++]
                }
         }
         End spiTransfer code;
    }
}

FIFO is full at the start, and the interrupt = false, so I am just circling the first while loop waiting. As soon as fifo falls below the threshold, interrupt = true. Dropping into the second while loop. It starts the spi transaction, then iterates through the bytes I already created sending and incrementing the position counter (which can break the first while loop). Breaking out of the for loop if the rising edge triggers the fifo is above the threshold. If fifo is full end the transaction, and circle the first while loop. It should fall out gracefully at the end of the packet as well.

Thats the idea anyway. Just wrote the second interrupt, haven't had a chance to test yet.

[Crsarmv7l]

Kinda throwing in the towel.

Set up an interrupt for FIFO_THR and an interrupt for FIFO Full. Best throughput I could get was 97 bytes, which would be fantastic if it was consistent. But it wasn't. I would typically get between 80 -93 bytes.

The sx1276 looks like a really good substitute but also appear to be register access and not stream. Seems like the stream chips don't have OOK.

I'll have to make do with 64 bytes

[Crsarmv7l]

On the other hand... there is this repo https://github.com/hideakitai/ESP32DMASPI

Might be worth a try, but I don't have high hopes on my ability to integrate it, if it can even work with Radiolib.

[jgromes]

I'm not convinced the SPI is the bottleneck here - you mentioned testing at 2 kbaud with 5.5 MHz SPI, transmitting one byte over the air takes 4 ms while sending it over the SPI takes 1.46 us, there should be plenty of time.

[Crsarmv7l]

I'm not convinced the SPI is the bottleneck here - you mentioned testing at 2 kbaud with 5.5 MHz SPI, transmitting one byte over the air takes 4 ms while sending it over the SPI takes 1.46 us, there should be plenty of time.

These recent test were at 8 Kbaud. You are usually right though. I had been testing with my actual ino which has a bunch of loops that get blocked by flags. That may be hanging things up.

I can write up a simple POC sketch and see how that does

[Crsarmv7l]

Guh @jgromes was right again. With a simple sketch at 8 Kbaud and my modifications to the CC1101 lib, the first two signals were 99.5 byte throughput and 98 bytes throughput out of 100 bytes.

Sigh. That means there is some issue with my multiple loops that is preventing the refills.

[Crsarmv7l]

Getting there now about 96 - 98.5 bytes out of 100 are making it through.

Got a couple ideas to try now that I know it isn't an issue filling. Might be able to drop to a single interrupt too.