Receiving/capturing RAW data

[betoled]

Hi,

Is it possible to capture RAW data send from a RF device ?
I have a RF keyboard that is sending signals at 868.85 MHz with GFSK modulation and I would like to receive them using an arduino and a RF transceiver. I have several... RFM69, SX1276, ...
The signal is strong and I am able to see it using SDR# and my Airspy mini.

All help will be appreciated.

[jgromes]

What exactly do you mean by "raw data"?

If it's raw IQ as for example SDR does, then no, you can't do that with a dedicated FSK transceiver chip like RF69 or SX127x.

If it's enough to get the data as a sequence of bits, then that's perfectly doable, assuming you have some information about the signal - like the frequency deviation and the bit rate at the very minimum.

What's the ultimate goal here, to decode communication from an RF keyboard using some FSK transceiver? If that's the case, I suggest using the SDR first to get as much information about the signal as possible. SDR programs like UniversalRadioHacker or gnuradio should be able to decode it, from that you can deduce the packet structure.

[jgromes]

1. RF69 can't set preamble length to 30 bits, it can only set whole bytes, so you have to use 24 or 32 bits.
2. You reset the module after configuring it - that will also wipe any configuration and set the default values. Don't reset it manually, it's already being reset in the begin() method.
3. RF69_FSK_GAUSSIAN_0_5 and RF69_DC_FREE_MANCHESTER are internal RF69-specific register values, they're not meant to be used in the public API. For that, there are the module-agnostic macros RADIOLIB_SHAPING_0_5 and RADIOLIB_ENCODING_MANCHESTER respectively. Also, is this something you read from the LE50 registers?
4. I don't think it's a good idea to be using String receive, unless the module is actually sending only ASCII text. Receiving into byte array seems like the smarter option here, unless the datasheet/user guide really says it sends only ASCII.

[betoled]

The reset and RF69_FSK_GAUSSIAN_0_5 and RF69_DC_FREE_MANCHESTER were for testing.
But it doesn't work when I leave them out either.
Changing the preamble length to 32 doesn't change anything.
I keep getting a timeout, but no data.

[jgromes]

You really need to know the sync word - it's a couple of bytes sent directly after the preamble, that's how the module recognizes the end of preamble and start of packet data. It will automatically discard any packets whose sync word doesn't match its own.

Also, it might be better to use interrupt receive, since with blocking receive, there's always a chance you will miss the packet between reception windows.

[betoled]

Most of the transmissions I capture with URH start with 11110110011011 (about 50% of the captured transmissions)
What do you think would be the preamble and what is the sync word ?

[jgromes]

Preamble should look like 10101010... - could you send me the recorded files, I can take a look.

[betoled]

Sure. But these are big files. How can I get them to you ? Wetransfer ? Which email address ? Op ma 1 feb. 2021 om 17:24 schreef Jan Gromeš <[email protected]>:

…

Preamble should look like 10101010... - could you send me the recorded files, I can take a look. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZQ6TRELGRDGQ6HNADDS43IVPANCNFSM4WWYEWIA> .

[betoled]

I have a few Dragino Lora shields that have the SX1276 module.
Can I use them with the Radiolib library to capture this signal ?

[betoled]

I've tried with the Dragino shield, and the sketch below, but no luck :-(

/*
   RadioLib SX127x Receive with Interrupts Example

   This example listens for LoRa transmissions and tries to
   receive them. Once a packet is received, an interrupt is
   triggered. To successfully receive data, the following
   settings have to be the same on both transmitter
   and receiver:
    - carrier frequency
    - bandwidth
    - spreading factor
    - coding rate
    - sync word

   Other modules from SX127x/RFM9x family can also be used.

   For default module settings, see the wiki page
   https://github.com/jgromes/RadioLib/wiki/Default-configuration#sx127xrfm9x---lora-modem

   For full API reference, see the GitHub Pages
   https://jgromes.github.io/RadioLib/
*/

// include the library
#include <RadioLib.h>

SX1276 radio = new Module(10, 2, 9, 3);

void setup() {
  Serial.begin(9600);

  Serial.print(F("[SX1278] Initializing ... "));
  int state = radio.beginFSK(868.85, 38.4, 20.0, 125.0, 10, 240, false);
  if (state == ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while (true);
  }

  uint8_t syncWord[] = {0x7a, 0x92};
  state = radio.setSyncWord(syncWord, 2);
  
  // set the function that will be called
  // when new packet is received
  radio.setDio0Action(setFlag);

  Serial.print(F("[SX1278] Starting to listen ... "));
  state = radio.startReceive();
  if (state == ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while (true);
  }

}

// flag to indicate that a packet was received
volatile bool receivedFlag = false;

// disable interrupt when it's not needed
volatile bool enableInterrupt = true;

// this function is called when a complete packet
// is received by the module
// IMPORTANT: this function MUST be 'void' type
//            and MUST NOT have any arguments!
void setFlag(void) {
  // check if the interrupt is enabled
  if(!enableInterrupt) {
    return;
  }

  // we got a packet, set the flag
  receivedFlag = true;
}

void loop() {
  // check if the flag is set
  if(receivedFlag) {
    // disable the interrupt service routine while
    // processing the data
    enableInterrupt = false;

    // reset flag
    receivedFlag = false;

    byte byteArr[8];
    int state = radio.readData(byteArr, 8);
    
    if (state == ERR_NONE) {
      // packet was successfully received
      Serial.println(F("[SX1278] Received packet!"));

      // print data of the packet
      Serial.print(F("[SX1278] Data:\t\t"));
      Serial.println(String((char*)byteArr));

      // print RSSI (Received Signal Strength Indicator)
      Serial.print(F("[SX1278] RSSI:\t\t"));
      Serial.print(radio.getRSSI());
      Serial.println(F(" dBm"));

      // print SNR (Signal-to-Noise Ratio)
      Serial.print(F("[SX1278] SNR:\t\t"));
      Serial.print(radio.getSNR());
      Serial.println(F(" dB"));

      // print frequency error
      Serial.print(F("[SX1278] Frequency error:\t"));
      Serial.print(radio.getFrequencyError());
      Serial.println(F(" Hz"));

    } else if (state == ERR_CRC_MISMATCH) {
      // packet was received, but is malformed
      Serial.println(F("[SX1278] CRC error!"));

    } else {
      // some other error occurred
      Serial.print(F("[SX1278] Failed, code "));
      Serial.println(state);

    }

    // put module back to listen mode
    radio.startReceive();

    // we're ready to receive more packets,
    // enable interrupt service routine
    enableInterrupt = true;
  }

}

[betoled]

Not all packages are the same size.
I've tested some more and noticed that some actions on the keyboard give bigger packages.

[betoled]

I connected a raspyberry pi to the sending module (LE50-868) and sent my own string.
When sending an alternating string of either "Test0" and "Test1" I got the result below when capturing this in URH

1101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101001111010100100100011000010101010101000110010101110011011101000011000101010101010101010101010100 [Pause: 3275312 samples]
1101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101001111010100100100011000010101010101000110010101110011011101000011000001010101010101010101010100 [Pause: 2987923 samples]

When I then look for the "Test0" value and substract this (and all that follows) I end up with this

1101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101001111010100100100011000010101

Removing the leading 1 and then trimming the first 240 bits (30 bytes) I end up with

101001111010100100100011000010101 or 14F524615 which does not feel correct to me as a syncword because of the length.

Any thoughts on how I can proceed from this ?
When running the sketch the serial monitor shows

[SX1278] Initializing ... success!
[SX1278] Starting to listen ... success!

But no messages are captured.

[jgromes]

Sending a known string is a very good idea indeed - since then we can search the captured data for it. However, from what you're describing, it looks like the captured data doesn't contain that (in hex Test0 shoud be 5465737430). In that case, some encoding is happening, maybe Manchester. URH can decode that too, check out the Analysis tab.

I think you will have to reverse-engineer the whole packet in URH before you try to capture it with SX1278.

[betoled]

The "Test0" string is clearly visible when looking for it binary format. So there is no encoding. But when I remove this from the binary sequence I would expect only the preamble and the syncword would remain. But then I get a syncword with 33 bits, which feels incorrect. Op wo 3 feb. 2021 21:01 schreef Jan Gromeš <[email protected]>:

…

Sending a known string is a very good idea indeed - since then we can search the captured data for it. However, from what you're describing, it looks like the captured data doesn't contain that (in hex Test0 shoud be 5465737430). In that case, some encoding is happening, maybe Manchester. URH can decode that too, check out the Analysis tab. I think you will have to reverse-engineer the whole packet in URH before you try to capture it with SX1278. — You are receiving this because you authored the thread. Reply to this email directly, view it on Gothic <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZUV6EQHP3TASAT6XBTS5GTSHANCNFSM4WWYEWIA> .

[jgromes]

Then we possibly incorrectly matched the start of sync word, so there's one extra bit at the beginning. Try to remove it, what's the hex data between preamble and the Test0 string?

[betoled]

When I take out the Test0 string, the following remains.

1101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101001111010100100100011000010101

I then take out the leading 1, because I think this has no meaning, and the remove the 240 bits of the preamble, this remains.

101001111010100100100011000010101 or 14F524615

[jgromes]

I think there might also be some post-amble bits - I noticed long sequencies of 0xaaaaa at the end of the packets you sent me. If that's the case, then the final 1010 bits are not a part of the sync word and it would only leave 14F52461

[betoled]

I remover all trailing data when I remover the data from my test string. The data I said is actually everything that was in front of my test string. But it looks strange to have a syncword like that. Am I correct to remove the very first '1' from the sequence? Every transmission I capture starts with '11' but the preamble should start with '10'. Op wo 3 feb. 2021 22:49 schreef Jan Gromeš <[email protected]>:

…

I think there might also be some post-amble bits - I noticed long sequencies of 0xaaaaa at the end of the packets you sent me. If that's the case, then the final 1010 bits are not a part of the sync word and it would only leave 14F52461 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZQBYOKHCCGW7GMCCSLS5HAGXANCNFSM4WWYEWIA> .

[betoled]

Today I tried to replicate the complete package using a Dragino with SX1276 module.
I've setup the sketch so it would send the same data as the keyboard does, but I get something different.
I would expect the data to start with a 240 bit preamble, but the preamble is only about 36 bits long.
Is this a bug ?

Below is my sketch (simplefied)

#include <RadioLib.h>

SX1276 radio = new Module(10, 2, 9, 3);

void setup() {
  Serial.begin(9600);

  Serial.print(F("[SX1278] Initializing ... "));
  int state = radio.beginFSK(868.85, 38.4, 20.0, 125.0, 10, 240, false);
}

void loop() {
  Serial.print(F("[SX1278] Transmitting packet ... "));
  int state = radio.transmit("Test0");

  delay(1000);
}

[jgromes]

The value for preamble length in SX127x::beginFSK() is actually in bytes, not bits - that's an oversight on my part, so try setting it to 30 instead of 240. Although it shoud be 240 bytes long in this case, I'm not sure why it isn't. I haven't tried FSK preambles this long before.

[betoled]

I've tried with 30 instead of 240, but that gives me the same result. I think there is something wrong in the code. Op do 4 feb. 2021 om 23:01 schreef Jan Gromeš <[email protected]>:

…

The value for preamble length in SX127x::beginFSK() is actually in bytes, not bits - that's an oversight on my part, so try setting it to 30 instead of 240. Although it shoud be 240 bytes long in this case, I'm not sure why it isn't. I haven't tried FSK preambles this long before. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZTRD7NUENXIHZKN2V3S5MKLNANCNFSM4WWYEWIA> .

[betoled]

Is it possible to receive the data regardless of the preamble and syncword ?
The sx1276 data-sheet shows registers to enable/disable preamble and syncword detection.

[jgromes]

I've tried with 30 instead of 240, but that gives me the same result.
I think there is something wrong in the code.

It's possible - SX127x datasheet isn't very clear on FSK preamble length configuration (bits vs bytes). I'll run my own tests and let you know.

The sx1276 data-sheet shows registers to enable/disable preamble and syncword detection.

The issue there is that disabling the preamble (or using a very short one) would make reception rather unreliable.

One more idea - are you using fixed or variable packet length mode? The default is variable length mode, which expects the first byte after sync word to be the length byte, which is most likely not your case. Try to enable fixed length mode with fixedPacketLengthMode(length).

[jgromes]

@betoled there was indeed a bug in the code, that caused the preamble length to be always set to 24 bits. It's been fixed now, so you should be able to use int state = radio.beginFSK(868.85, 38.4, 20.0, 125.0, 10, 240, false); to sue the 240 bit preamble.

[betoled]

I've downloaded the new code and tried again, but I'm still not able to receive the data. My test setup with one SX1276 sending test data with a 240 bits preamble, and another SX1276 receiving it does work. It looks like I'm not able to find the correct syncword. Any suggestions? Would implicit mode be an option to get the raw binary data ? And disabling CRC check ? If I can get the complete binary packet, that would be fine, I can go from there with my own code. Op vr 5 feb. 2021 om 23:30 schreef Jan Gromeš <[email protected]>:

…

I've tried with 30 instead of 240, but that gives me the same result. I think there is something wrong in the code. It's possible - SX127x datasheet isn't very clear on FSK preamble length configuration (bits vs bytes). I'll run my own tests and let you know. The sx1276 data-sheet shows registers to enable/disable preamble and syncword detection. The issue there is that disabling the preamble (or using a very short one) would make reception rather unreliable. One more idea - are you using fixed or variable packet length mode? The default is variable length mode, which expects the first byte after sync word to be the length byte, which is most likely not your case. Try to enable fixed length mode with fixedPacketLengthMode(length). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZQAJKMKXKBXLWASAKLS5RWQZANCNFSM4WWYEWIA> .

[jgromes]

Implicit mode only affects LoRa mode, not FSK. You should probably disable CRC (since we have no idea if the packets have it), but having it enabled won't prevent you form receiving the packets, it would just drop them after the CRC check fails.

Another way to debug this further would be to start checking values of the SX1276's IRQ register. That would at least tell us if it's able to receive the preamble.

Did you try the fixed packet length mode? And if so, what was the result?

[betoled]

Yes, I've tried with a fixed packet length, but that didn' change anything. Still nothing. I now also got a second remote keyboard. So I had them send the same command, and look for the difference. It was my idea that only the syncword would be the difference. Below is the result from URH in binary format. There is only a little difference, and looks like it's right before and right after the data. How and where do I check the values for the IRQ register ? Keyboard 1 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 10100111101010010010001100000100000000010010000 01 0011111101010010010001000010010100100101010110000001001000000011001100 11 01010101010101010101010101010101010101010101010100 Keyboard 2 101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 10100111101010010010001100000100000000010010000 10 0011111101010010010001000010010100100101010110000001001000000011001100 00 01010101010101010101010101010101010101010101010100 Op vr 12 feb. 2021 om 20:08 schreef Jan Gromeš <[email protected]>:

…

Implicit mode only affects LoRa mode, not FSK. You should probably disable CRC (since we have no idea if the packets have it), but having it enabled won't prevent you form receiving the packets, it would just drop them after the CRC check fails. Another way to debug this further would be to start checking values of the SX1276's IRQ register. That would at least tell us if it's able to receive the preamble. Did you try the fixed packet length mode? And if so, what was the result? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZXXQHNGWJINCXELBALS6V4EVANCNFSM4WWYEWIA> .

[betoled]

When reading the IRQ flags in de arduino loop function. They return 16600 until the sender sends a packet, then it changes to 16602.

[jgromes]

That's the interrupt that fires when a packet is received - so in fact the SX127x does receive the packet. Couple of things to check then:

1. The hardware setup and wiring. You need to have DIO0 connected to a digital pin, preferrably one that can do external interrupts. On Arduino Uno, that's pins D2 and D3.

2. The receiveing sketch. Are you using blocking receive or interrupt? I I would really suggest using interrupt here, the bit rate is high so the timeout in blocking receive will be very short.

[betoled]

I connected the DIO0 pin to D2 of the Arduino Uno, and I'm using the interrupt receive.But still the same, the receiveflag never gets set.

Here is my sketch simplified.

#include <RadioLib.h>

SX1276 radio = new Module(10, 2, 9, 3);
int prevIrq = 0;

void setup() {
  Serial.begin(9600);

  Serial.print(F("[SX1278] Initializing ... "));
  int state = radio.beginFSK(868.85, 38.4, 20.0, 125.0, 10,240, false);
  if (state == ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while (true);
  }

  radio.setDio0Action(setFlag);
  radio.disableAddressFiltering();
  radio.disableSyncWord();
  Serial.print(F("[SX1278] Starting to listen ... "));
  state = radio.startReceive();
  
  if (state == ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while (true);
  }

}
volatile bool receivedFlag = false;
volatile bool enableInterrupt = true;

void setFlag(void) {
  if(!enableInterrupt) {
    return;
  }

  receivedFlag = true;
}

void loop() {

  int irqs = radio.getIRQFlags();

  if (irqs != prevIrq) {
    Serial.println(String(irqs));
    prevIrq = irqs;
  }
  
  if(receivedFlag) {
    enableInterrupt = false;
    receivedFlag = false;

    byte byteArr[8];
    int state = radio.readData(byteArr, 8);
    
    if (state == ERR_NONE) {
      Serial.println(F("[SX1278] Received packet!"));

      Serial.print(F("[SX1278] Data:\t\t"));
      Serial.println(String((char*)byteArr));

      Serial.print(F("[SX1278] RSSI:\t\t"));
      Serial.print(radio.getRSSI());
      Serial.println(F(" dBm"));

      Serial.print(F("[SX1278] SNR:\t\t"));
      Serial.print(radio.getSNR());
      Serial.println(F(" dB"));

      Serial.print(F("[SX1278] Frequency error:\t"));
      Serial.print(radio.getFrequencyError());
      Serial.println(F(" Hz"));

    } else if (state == ERR_CRC_MISMATCH) {
      Serial.println(F("[SX1278] CRC error!"));

    } else {
      Serial.print(F("[SX1278] Failed, code "));
      Serial.println(state);
    }

    // put module back to listen mode
    radio.startReceive();

    // we're ready to receive more packets,
    // enable interrupt service routine
    enableInterrupt = true;
  }
}

[betoled]

How can I debug this further ?
I can see the IRQ changing, but the attached function is never called.
This is the IRQ output when it changes.

When I set the 'attachInterrupt' mode to 'CHANGE' the function is sometimes called, but without real data.

20:45:19.176 -> [SX1278] Initializing ... success!
20:45:19.229 -> [SX1278] Starting to listen ... success!
20:45:19.276 -> 16600
20:45:19.530 -> 16601
20:45:19.530 -> 217
20:45:19.530 -> 16400
20:45:19.530 -> 16600
20:45:29.129 -> 16601
20:45:29.176 -> 217
20:45:29.176 -> 16400
20:45:29.176 -> 16600
20:45:37.391 -> 16601
20:45:37.391 -> 217
20:45:37.438 -> 16400
20:45:37.438 -> 16600

[betoled]

For now I've given up with the SX1276.

I've tried with the RF69 and gotten somewhat further.
If I set 'PromiscuousMode' to true, I actually receive data that looks to be coming for my remote keyboard.

The data I get looks like this:
And this is what I would expect.

21:26:16.509 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820E6F[RF69] RSSI:		-63.00 dBm
21:26:21.129 -> [RF69] Received packet!
21:26:21.129 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9EA48C104827EA4884A4AB24099AAAAA7F2430020F81012772820EF9[RF69] RSSI:		-62.00 dBm
21:26:32.654 -> [RF69] Received packet!
21:26:32.654 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012662820EF8[RF69] RSSI:		-63.50 dBm
21:26:39.620 -> [RF69] Received packet!
21:26:39.620 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9EA48C104827EA4884A4AB24099AAAAA7F2430020F81012772820E6D[RF69] RSSI:		-62.50 dBm
21:26:44.178 -> [RF69] Received packet!
21:26:44.178 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012662820EF8[RF69] RSSI:		-62.00 dBm
21:26:48.765 -> [RF69] Received packet!
21:26:48.765 -> [RF69] Data:		555555555555555555555555555555555555555555AAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820E71[RF69] RSSI:		-67.50 dBm
21:26:51.106 -> [RF69] Received packet!
21:26:51.106 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820EF7[RF69] RSSI:		-63.00 dBm
21:26:55.699 -> [RF69] Received packet!
21:26:55.699 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820EF8[RF69] RSSI:		-63.00 dBm
21:27:00.354 -> [RF69] Received packet!
21:27:00.354 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F243002000202772820EF9[RF69] RSSI:		-62.50 dBm
21:27:02.628 -> [RF69] Received packet!
21:27:02.628 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9EA48C104827EA4884A4AB24099AAAAA7F2430020F81012772820E6D[RF69] RSSI:		-62.00 dBm
21:27:04.920 -> [RF69] Received packet!
21:27:04.920 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012662820E6F[RF69] RSSI:		-63.50 dBm
21:27:09.530 -> [RF69] Received packet!
21:27:09.530 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820EFA[RF69] RSSI:		-62.00 dBm
21:27:18.782 -> [RF69] Received packet!
21:27:18.782 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820E71[RF69] RSSI:		-62.00 dBm
21:27:21.060 -> [RF69] Received packet!
21:27:21.060 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA9221292AC9199AAAAA7F2430020F81012772820EFA[RF69] RSSI:		-52.50 dBm
21:27:21.545 -> [RF69] Received packet!
21:27:21.545 -> [RF69] Data:		AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7A92341209FA922131490A1899AAAAA7F2430020F81012772820EF7[RF69] RSSI:		-51.00 dBm

But when I do not set promiscuous mode, and I set preamble length to 24 bytes and disable syncword filtering, I receive nothing.

radio.setPreambleLength(24);
radio.disableSyncWordFiltering();

How can I get the data without have to set promiscuous mode ?

[jgromes]

Promiscuous mode will basically disable three things: preamble, sync word and CRC.

disableSyncWordFiltering() will disable sync word and preamble, so try swapping setPreambleLength and disableSyncWordFiltering.

[betoled]

This works :

radio.setCrcFiltering(false);
  radio.setPreambleLength(32);
  //radio.disableSyncWordFiltering();

  //7A923412
  //7A92341209FA9221
  uint8_t syncWord[] = { 0x7A, 0x92};
  radio.setSyncWord(syncWord, 2);

When I enable CRC, no data comes through.
The data I get when CRC is off, is not very consistant, except for the first part.
Could this be an antenna problem ?
This is what I get :

40129FA9221292AC090199AAAAAAAAAAAA8D4B21E1DED291B8493A336D4415A7EC4CC097A9C1C4F951FB6CF0FC73F3C115D001A020A2740E50
40129FA9221292AC090199AAAAAAAAAAAA826E51EB679E92637F99C9E7E7F126752D104F9DB5C63A9562412707F370020F810126D2820E52
40129FA9221292AC090199AAAAAAAAAAAA85C2A73FD7B39998CA39745B4EC59FFC9C88FD35C7B185DDB9C0D46156BA370020F810126B2820E52
40129FA9221292AC090199AAAAAAAAAAAA852C29E2496D7332A881D7F3A779B87F8C45FF90E916C1CEE8A877C8CF370020F810126B2820E50
40129FA9221292AC090199AAAAAAAAAAAA86FECE118724B1F3EF5E59AFAAFEF91F3983604AF35657D04A7EA2439115370020F810126B2820EAE
40129FA9221292AC090199AAAAAAAAAAAA9FBD33ECBCCAAD21479267F39CB30AD67BAADF8AC9804975F4689A5E9A370020F810126B2820EAE
40129FA9221292AC090199AAAAAAAAAAAA82D7A95BD3DFF17C45ED3B8B02F3F959343D01855FC57F37B2D9396C3370020F81012622820EAE
40129FA9221292AC090199AAAAAAAAAAAA83BC222A1D33615D75E13393D9C578CC318DC5C27D26C792A21F54313F90370020F810125F2820EAF
40129FA9221292AC090199AAAAAAAAAAAA83BECC27C8DD8FF4B952F34535B7234566C1F6ED20DBF3D73CEE47B3C2FE370020F810126B2820E51
40129FA9221292AC090199AAAAAAAAAAAA818F7F166F35B893B8F77BE4270A43E555D389DBA437E3A368E4847A3D370020F810126B2820EAF
40129FA9221292AC090199AAAAAAAAAAAA81B485E1E4FF55072387A469EB411BEADAFE67EF4AFC79CECBB69B096E9E7370020F810126B2820EB0
40129FA9221292AC090199AAAAAAAAAAAA8C42838437E096A0CD7F23DC6CAF19C64674D3AC4B5FBB5664F8A711EBC6370020F810126B2820E4E
40129FA9221292AC090199AAAAAAAAAAAA83566DABE1D1494DB9C66C55EDDB0D65B907FBB41F25D8DFCB519623FDC8E370020F810126B2820EAE
40129FA9221292AC090199AAAAAAAAAAAA831717A11DB1FC166B331B4B9DFFB63DFA0581F3FF7BC87FA61D150FAF3E370020F810126B2820E4E
40129FA9221292AC090199AAAAAAAAAAAA9BAAED8756F74BE5447F2DD7CFA106F95F03ACB8CE3DDCEA313371AF19ECF370020F810126B2820EB0
40129FA9221292AC090199AAAAAAAAAAAA83E8687A3DD3F54BCBA972267916943E67B97024D4DBC02F4CB2CDE12B4370020F810126B2820EAE
40129FA9221292AC090199AAAAAAAAAAAA87E4F95EA12B1D0F393579544384612D3588E191CF8715384CA4398A8630370020F810126B2820E50
40129FA9221292AC090199AAAAAAAAAAAA9DCA9FE6F9182DED71968FF502D1EFEF8B34D9A1567A526164A837E89370020F810126B2820E4E
40129FA9221292AC090199AAAAAAAAAAAA8DA2E8CFDA75879B3367B2643FFB30406479EFCB547EA9AC569268497D370020F810126B2820EAF
40129FA9221292AC090199AAAAAAAAAAAA81A6891335AFEFAEDCE94FD623CB010A8B4583B2248175A7861B2ED18B28370020F810126B2820E50
40129FA9221292AC090199AAAAAAAAAAAA8339F186AFE5144679B618FE67D8B9FCA6BD48DE5792B59AA907A9C5CE6EF370020F810126B2820E50

[jgromes]

I think it's because you're in variable packet length mode, so the part after the postamble is just noise. Try fixedPacketLengthMode(11) to set fixed packet lenggth mode for 11 bytes (based on the output above).

[betoled]

It seems to work now. With a fixed packetlength of 9, and as long as I disable CRC. When I do not disable CRC, I get nothing. Op di 16 feb. 2021 om 23:41 schreef Jan Gromeš <[email protected]>:

…

I think it's because you're in variable packet length mode, so the part after the postamble is just noise. Try fixedPacketLengthMode(11) to set fixed packet lenggth mode for 11 bytes (based on the output above). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZUIV6S7HRCOMNA42OLS7LYCBANCNFSM4WWYEWIA> .

[jgromes]

Glad you got it working! The CRC requirement is caused by the fact that RF69 will just silently drop packets if the CRC fails, IIRC.

[betoled]

Thank you very much for your help and patience !! You are a lifesaver... Op wo 17 feb. 2021 om 21:35 schreef Jan Gromeš <[email protected]>:

…

Glad you got it working! The CRC requirement is caused by the fact that RF69 will just silently drop packets if the CRC fails, IIRC. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#233 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6R6ZVWQPY4JCBLSRLLKKLS7QSBNANCNFSM4WWYEWIA> .