Another FIFO Refill topic

[Crsarmv7l]

I'll leave this one open and contain my FIFO madness to it.

Below you will find a sketch that is nearly there with the following settings:
5 Mhz SPI
God mode (only because I wanted to leave CC1101.cpp / .h alone while testing but still had to bypass the 63 byte limit).

Notes: The below usually returns between 94 bytes and 98.5 bytes when rxed. I had attempted to use ISR's for both FIFO low and FIFO full, but we care more about empty space in the FIFO than if it is full or not, and this method seems most consistent with txed signals.

If you RX some of these signals you will get some that are perfect "AAAAAAAAA" and some that bitshift "AAAAA55555." I don't think it is the FIFO running empty, but who knows.

I apologize for the ping @jgromes, but I think with your additional insight we might be able to get this across the finish line, even if it is a sliding scale of amount of bytes able to txed (eg higher baud lower max bytes).

#include <RadioLib.h>

CC1101 radio = new Module(6, 16, RADIOLIB_NC, 17);

byte tx[] = {0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
             0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
             0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
             0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
             0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
             0xAA, 0xAA, 0xAA, 0xAA, 0xAA
            };

uint8_t txlen = 100;

volatile bool lowfifo = false;

void IRAM_ATTR setFlag(void) {
  lowfifo = true;
}

Module* mod = radio.getMod();

void setup() {
  Serial.begin(115200);
  while (!Serial) {};

  int state = radio.begin();
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.print(F("CC1101 Failed: Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.setFrequency(433.92);
  if (state == RADIOLIB_ERR_NONE) {
    Serial.println(F("Set Freq: 433.92"));
  }
  else {
    Serial.print(F("Freq Failed, Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.setOOK(true);
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.print(F("Modulation Failed, Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.setBitRate(8.00);
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.print(F("Datarate Failed, Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.setRxBandwidth(270);
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.print(F("Bandwidth Failed, Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.setOutputPower(10);
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.print(F("Set Power Failed, Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.setPromiscuousMode(true);
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.print(F("Promiscuous Failed, Code "));
    Serial.println(state);
    while (true);
  }
  state = radio.fixedPacketLengthMode(txlen);
  if (!state == RADIOLIB_ERR_NONE) {
    Serial.println (F("Error Setting Fixed Packet Length"));
    Serial.println(state);
    while (true);
  }
}

void loop() {
  Serial.println("Sending large signal");
  
  radio.standby();

  // flush Tx FIFO
  radio.SPIsendCommand(RADIOLIB_CC1101_CMD_FLUSH_TX);

  lowfifo = false;

  // set FIFO_THR to interrupt when fifo is low
  radio.SPIsetRegValue(RADIOLIB_CC1101_REG_FIFOTHR, 0x0E, 3, 0);

  // set GDO2 mapping
  radio.SPIsetRegValue(0x00, 0x02, 5, 0);

  // write initial burst to tx buffer, completely fill it
  radio.SPIwriteRegisterBurst(0x3F, tx, size_t (64));

  uint8_t bytessent = 64;
  uint8_t bytestowrite = 0;

  radio.setPacketSentAction(setFlag);

  radio.SPIsendCommand(0x35);   //strobe tx

  uint8_t fifo = 5; //lowfifo triggers on 5 bytes remaining, so use 5 for the first refill calc, and update this value as we go
  while (bytessent < txlen) {
    if (lowfifo) {
      bytestowrite = min((uint8_t) txlen - bytessent, 64 - fifo);
      radio.SPIwriteRegisterBurst(0x3F, tx + bytessent, bytestowrite);
      fifo = radio.SPIgetRegValue(RADIOLIB_CC1101_REG_TXBYTES, 6, 0);
      bytessent += bytestowrite;
    }
  }

  Serial.print(F("Transmitted: "));
  for (uint8_t i = 0; i < txlen; i++) {
    Serial.print(tx[i], HEX);
  }
  Serial.println();

  //wait for fifo empty
  while (radio.SPIgetRegValue(RADIOLIB_CC1101_REG_TXBYTES, 6, 0) != 0) {};

  radio.standby();
  radio.SPIsendCommand(RADIOLIB_CC1101_CMD_FLUSH_TX);

  delay(10000);

}

[jgromes]

Hmm, I don't see anything immediately obvious that could cause those bitshifts - how are receiving the signal? With another CC1101 or some SDR?

[Crsarmv7l]

Hmm, I don't see anything immediately obvious that could cause those bitshifts - how are receiving the signal? With another CC1101 or some SDR?

An rtlsdr and URH to record. The bitshift is driving me batty because it is entirely random.

I have made a few changes since this sketch, xtaskcreate with a high priority, because why not (shouldn't matter in this example). I also inserted radio.clearPacketSentAction(); in the setFlag ISR function because in this the ISR is only triggered once and this can be fully refilled with the rest of the bytes. Neither really helped at all. I also attempted setting FIFOTHR higher at 0x0D (9 bytes remaining in FIFO).

The really frustrating part is I cant see why it is happening. For instance with one test, the bit shift happened at ~49 bytes... The initial FIFO fill was 64 bytes. With 15bytes left in the buffer, my refills aren't occurring at that point, but there is a transition from AAA to 5555.

The only possible thing that I can think of, is the CC1101 SPI requirements for gaps between the header/cmd and the data being 100ns...but it still doesn't really make sense.

[Crsarmv7l]

On the upside byte throughput is really good now...

[Crsarmv7l]

Looking around it seems there are a couple posts in a variety of forums regarding unexpected delays in the esp32-S2 spi transfers. I have a few things I can try related to that and I think I have an ESP32-S3 sitting around somewhere that I can throw in my socketed test board to try as well.

[jgromes]

I'll see if I can get your code up and running on my RPi-based test setup.

[Crsarmv7l]

Thanks. Tried a lot of stuff so far: all different SPI speeds, blocking interrupts after my interrupt is triggered (noInterrupts() in arduino), inverting GDO2, switching to GDO0 for the interrupt, inverting the GDOx assert, setting the FIFOTHR much higher for more time to fill (20+ bytes remaining in FIFO), xtasks with high priority. Always the same result.

Scoured the Ti forums and the DN's, but haven't come up with a reason.

I assume fixedPacketLengthMode sets both PKTCTRL0 LENGTH_CONFIG and PKTLEN registers, but I am gonna take that macro out and set those registers myself as well.

I also think tonight I am going to re-implement the SPIwriteRegBurst in the sketch. See if those have any effect.

I hesitate to say it is a hw issue because normal tx only filling the fifo and strobing tx works as expected. I am sure once I get it I am going to let out a big "GUH." Just gotta get there.

[jgromes]

So I tried running your code posted above with no modification to upstream RadioLib CC1101 driver (except for changing maximum pacekt length to 255 to get past radio.fixedPacketLengthMode(txlen);, and it seems like it's working reliably, no bitflips in the signal whatsoever, it always transmits 98 bytes.

I disabled OOK mode and pushed frequency deviation to 40 kHz so that I could get clear decodes from URH, but I don't think either one should be a factor for you.

[Crsarmv7l]

Hmm. Thank you for testing. Maybe a hardware issue..

I just soldered the header pins on my ESP32-S3 today. So I think I am going to do the following:

 1. I must have done something to radiolib in my past tinkering in order to get past fixed packet length gates, so I will grab it fresh, and manually set the lengths and test on my current hardware.
 2. Test again on the ESP32-S3

After that maybe test on some of my larger ESP's.

Assuming all of those generate the same output, there can be only two possible options for an issue:
1. Either something is going on with my PCB,
2. Or it is my usage of the QT py SCL pin for CS, RX pin for GDO, or A1 pin for
GDO2.
Would be weird if it was the pins though since Adafruit says all of them can be used for digital. I can test with a breadboard to see if it's the PCB which would also be weird, since its just traces.

[Crsarmv7l]

Tested with fresh Radiolib on my test board with QT py ESP32 S2 - Problem persists
Tested with a QT py ESP32S3 on my test board - Problem perists
Broke out a breadboard with both QT py ESP32S2 and QT py ESP32S3 - Problem persists
Tried a number of different pinouts for CS, GDO0 and GDO2 -Problem persists (no surprise there, those shouldn't be causing an issue)

With all of the above I am going to go ahead and say I don't think it is my PCB, nor my pin selection. Both ESP32S2 and ESP32S3 are Adafruit QT py boards, perhaps an issue with power/noise? Not quite sure how I could check/mitigate. MOSI is right next to the 3v pin.

I will test a full size feather board...but I really need something small.

I suppose it could also be an issue with the ebyte cc1101's (two different ones were tested)

[Crsarmv7l]

What board is that? I am getting to the point where I just want something that works

[jgromes]

My development setup is a Raspberry Pi 3B+ with a bunch of jumper cables connecting its GPIO header to a breadboard, on which I have the various RF modules, CC1101 in this case. It's a rather simple setup, with zero care taken to isolate signals and power, so I would be sceptical about noise or cross-talk being the root cause. But I admit it is slowly getting into hair-pulling territory ...

[Crsarmv7l]

Looks like @phretor has implemented FIFO refills in RFquack's fork of Radiolib. He is doing it by polling the TX_BYTES register
https://github.com/rfquack/RadioLib/blob/aa8330cf571a40241cde30e9f4cb710244d27495/src/modules/CC1101/CC1101.cpp

I find this piece interesting as well in https://github.com/rfquack/RFQuack/blob/master/src/radio/RFQCC1101.h
I am grasping at straws, but the comment/code of noise triggering CS is worth exploring. CS being triggered after tx starts would not effect a 64byte tx where the FIFO is filled prior to strobing tx, but would effect refills. Noise, might account for my issues with FIFO refills above.
I am getting hopeful when I shouldn't.

[Crsarmv7l]

At this point I would be happy to send you hardware to play with. Or if you happen to be in Germany, I will be in the country in October.

…

On Mon, Jul 1, 2024, 11:57 AM Jan Gromeš ***@***.***> wrote: My development setup is a Raspberry Pi 3B+ with a bunch of jumper cables connecting its GPIO header to a breadboard, on which I have the various RF modules, CC1101 in this case. It's a rather simple setup, with zero care taken to isolate signals and power, so I would be sceptical about noise or cross-talk being the root cause. But I admit it is slowly getting into hair-pulling territory ... — Reply to this email directly, view it on GitHub <#1138 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AULD4G4IINJTVVTCWT454STZKF36BAVCNFSM6AAAAABJ23RB2SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSMRXGMZTA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Crsarmv7l]

Went for a bit of a different test this time, with 0x80, 0x91, 0xA2 repeating, this was also a straight implementation from RFquack of refills.. you can see from the signals there are segments of 0x80, 0x91, 0x80, 0x91 which it turns out was correct. My copy paste was a bit off, and that is actually what I had in the signal.

First two signals are fantastic, great throughput and matches exactly.

Third signal...again off

Fourth signal, back to perfect

[Crsarmv7l]

After some tweaking in URH 3rd signal looks a lot better but there is still an issue there

[Crsarmv7l]

Seems like a significant improvement even if still not perfect. The only major difference I can see between what RFQuack did and my OG one is RFquack left this

and I did not use that above. Instead I went with the IRQ for FIFO thr

[Crsarmv7l]

Also notice with the 3rd signal with the issue 3 bytes missing and:

[jgromes]

I will try to replicate this on one of my ESP32 boards. Could you post a complete sketch that I could use, including the SPI configuration? I feel like this is really close to being complete, it would be a shame for all that time to go to waste.

[Crsarmv7l]

I'm at the inlaws, but yes once I get back I'll put up all src exactly as I have them.

It will be cc1101.h, cc1101.cpp and the sketch. SPI settings are default.

[Crsarmv7l]

@jgromes

Hardware Tested:
Adafruit QT Py ESP32-S2

• SCK = 36
• MISO/GDO1 = 37
• MOSI = 35
• CS = SCL (6)
• GDO0 = RX (16)
• GDO2 = A1 (17)

Adafruit QT Py ESP32-S3

• Same pinout as QT Py ESP32-S2

Adafruit Feather ESP32-S3

• SCK = 36
• MISO/GDO1 = 37
• MOSI = 35
• CS = 5
• GDO0 = 11
• GDO2 = 13

All ESP32's used in socketed boards (also tested in breadboards with other pinouts) one was directly soldered into the PCB with the CC1101. All ESP32's exhibited the exact same behavior.

Radiolib SPI Settings: 2000000, MSB, SPI_MODE0 (Included build opt attached)

Test sketch and CC1101 files attached
- test_ino.txt = test.ino
- CC1101_h.txt = CC1101.h
- CC1101_cpp.txt = CC1101.cpp
- BuildOpt_h.txt = BuildOpt.h (no changes, but included anyway)
- Double read of TXBYTES as described in SWRZ020E CC1101 Silicon Errata page 6 in starttransmit function, as well as refill

Decode Settings:

Hardware:

• rtlsdr

• URH
  Settings/Procedure:

  • Gain set at 10 due to close proximity of CC1101 transmitter
  • 280 Ksps (at 8Kbaud that gives a nice 35 samples/symbol for analysis, and keeps file size smaller)
  • URH recording started, then ESP32/CC1101 plugged in and Serial Monitor opened to start TX
  • Minor noise correction as necessary (not much noise during my testings so max was ~0.01)

test_ino.txt
CC1101_h.txt
CC1101_cpp.txt
BuildOpt_h.txt

[Crsarmv7l]

Maybe byte alignment is playing a role. I might play around with packing.

[Crsarmv7l]

I realized how stupid the above was. If it was byte alignment none of them would come out correctly.

This seems to be working well though, every single one is perfect.

I used FSTXON then checked the MARCSTATE until it left 0x12 before filling the fifo and strobing tx. At the end of the signal I am repeatedly checking MARCSTATE until it enters Idle (end check maybe not needed, I just want to be sure the fifo is empty)

Need to do more long term testing, but the above and another test I did both came out great, and the bitshift I was seeing was 1 in 4 typically.

[jgromes]

That looks like a very good progress! Unfortunately I did not yet have time to test your code on my ESP32, sorry about that.

I also wanted to point out that it worked well for me on Raspberry which is a 64-bit platform, so bit widths/alignment/packing is unlikely the culprit.

[Crsarmv7l]

All good, and yeah I realized the alignment wasn't a good idea once I actually kinda thought it through. I am still trying to find good documentation on why the above is working/how exactly it works.

My best guess is turning the freq synth on before tx allows the RC Oscillator to settle out. A bit inversion I guess could be caused by jumping straight from idle to tx without the clock settling and then tossing even more bytes into the FIFO as it empties. Maybe?

Need to test a lot more and make sure it continues to be accurate. I also need to look in SCAL and MCSM0.FS_AUTOCAL=1, because calibrating is never a bad thing but I am not sure if the current default is autocalibrate or not.

[Crsarmv7l]

Sigh. Much less incidence of bitshift, but it is still there. 13 signals one of which is shifted.

Probably just going to use it as is and ensure I have 4-5 repeats. A majority should be accurate based the (now) low prevalence of the bitshift

[Crsarmv7l]

Still can't leave this alone 🤣 . Think I found some interesting tidbits. Here are the ones I can currently confirm:

• MCSM0.FS_AUTOCAL is set to 1 by default in radiolib as the MARCSTATE reflects calibration when FSTXON is strobed
  • As AUTOCAL is enabled, Calibration is done when going from IDLE to TX or RX (page 52 of the data sheet)

    • Should probably check the MARC State to verify Calibration is complete and completed correctly. Pg 58 of the datasheet:

         "If calibration is performed each time before time before entering active mode (RX or TX)......As an alternative the user can 
          read register FSCAL1. The PLL is in lock if the register content is different from 0x3F... The PLL must be recalibrated until 
          PLL lock is achieved if the PLL does not lock the first time."
          
         "If the calibration is not performed each time before entering active mode (RX or TX) the user should program register
          IOCFGx.GDOx_CFG to 0x0A to check that the PLL is in lock before receiving/transmitting
          data."
      

    • Figure 13 page 28 (also fig 25 page 50) of the CC1101 datasheet have a best practice of going through FSTXON before TX

    • Strobing SCAL and waiting for completion also seems to help before each transmission which is supported by the above "calibration...... performed each time before entering active mode (RX or TX) "

Need to do some more testing tomorrow, but here are my suspicions:

• Notice on my URH screen captures the signal amplitudes vary even though my output power is constant and my rtl-sdr gain is constant.
• Also notice your signal amplitudes are consistently the same height
• I have errors, you don't

Based on that, and page 58 Section 22.1 which states "The VCO characteristics vary with temperature
and supply voltage changes...." I think my issue is supply voltage to the CC1101. Every test I have powered the ESP32 via USB from my laptop computer. Even the breadboard tests were the same computer and USB port. The CC1101 is connected to the 3v3 rail of the ESP32 so it is also being powered by the computer USB.

• Calibration was taking place with FSTXON and with my SCAL which as stated above can somewhat compensate for supply voltage changes (the caps on the boards likely also help). I think my issues are caused by a sudden supply voltage drop. (not quite sure how to fix that).
• So far I have tested with no repeats, and only single transmissions, (try and prevent extra power draw) and thus far after 20 tests I have yet to have a single bitshift and I have perfect byte throughput when using 4Mhz SPI (same results when using 2Mhz SPI). For me anyway 100bytes = 800 bits / 255bytes =2040 bits, more than enough for me to build in signal repeats on a single CC1101 transmission. I just hope it continues to be accurate through more testing.

[jgromes]

Supply voltage stability could definitely be a factor, in my tests I have powered it from the Raspberry Pi 3.3V source, which is most likely a lot harder power source than the LDO on ESP32.

[Crsarmv7l]

I have implemented quite a bit of the calibrations and checks the datasheet supports if you would like a PR

[jgromes]

Definitely! I would be very glad to add those, especially after all the testing you have done, great job on that!

[Crsarmv7l]

Cool. Provided my further extended testing goes well, I also think FIFO refills are ready to go.

The way I see it:

• We have identified it works fully for you
• I have identified a likely reason for the problem I am seeing (that is why I have kept at this, I didn't know why)
  • I have mitigations in place that lower the instances of that potential issue to very usable levels (1 bad signal out of 13 repeats is very usable). And so far* single transmissions have no issues.

[Crsarmv7l]

Mine was a power issue. Put on a 100 uf cap and tried 40 straight transmissions, and a 6.5Mhz SPI speed with a gap between transmissions, no errors.

I needed a gap because it is an electrolytic capacitor, and as a result isn't super fast to refill. So looks like if I want to do what I want to do I will need to revise my PCB to include some power smoothing

[jgromes]

That's great news, thanks for letting me know! As I mentioned previously, it would be great to have this in the upstream, so a PR will be most definitely accepted ;)

[Crsarmv7l]

Absolutely going to happen. Might take a bit though, a lot going on in my life, I need to make sure all my code is clean. People may also have issues if like me, they are powering the whole thing through a computer USB

[jgromes]

I don't know what you're currently going through, but much as this issue, I am completely confident you will make it :)

People may also have issues if like me, they are powering the whole thing through a computer USB

We can put a note/warning in the appropriate example for that. It is actually a bit strange that this issue did not appear for you in packet mode (I assume).

[Crsarmv7l]

Ah its nothing bad, just hectic since my family is moving halfway around the world, and doing all the prep.

This TX method is using packet mode (the FIFO), or are you referring to my RX with sync serial? If the RX, I believe I have seen the results of this there. I end up getting a random "signal" it is fairly consistent in content though so I can id it pretty readily. I had assumed it was background noise.

Wanted to get TX and RX pieces working before I went further, but I will probably write a simple decoder and see how what I assumed was noise will effect it. A friend who knows hardware far better than my frankly zero hw knowledge has been helping with some new schematics with much better decoupling caps, usb noise filters etc and is basically an ESP32 + adapter board all in one for drop in cc1101.

[Crsarmv7l]

0.1uf (100nf) ceramic cap for filtering/droop is working very well. Still need to keep testing as ESP32-S2 is running at 160Mhz and I have SPI at 4Mhz. Will keep working up till it gets unstable, and I might also try a slightly bigger but still small ceramic cap (maybe 0.15uf or 0.22uf).

Hardware is not my favorite, probably because I don't know much if anything about it. Still learning experience.

[Crsarmv7l]

Still more testing going on + moving.

Got a couple more slightly different variation PCBs coming. A variety of caps, a through test suit designed with a python frontend for consistency and things are narrowing down. I expect I will upstream by the end of Dec at the latest.

If someone is familiar with DMA that would be the effective/efficient way to fill/refill the FIFO