Capture FULL contents being transmitted over-the-air?

[K4KDR]

Any guidance appreciated on how to do what I'll explain below; searching online has not been productive - probably because I'm not asking the question very well.

This pertains to any protocol, not just LoRa or LoRaWAN. With a TON of help from people like the contributors to RadioLib, I have had great success now transmitting w/ various RF modules either attached to or built into a decent variety of microcontrollers.

Depending on the context, I use commands such as node.uplink, node.sendReceive, or radio.transmit.

Here is what I seek, please: As you all know, depending on the protocol, "more" is transmitted over-the-air than just my small payload. A 2-byte payload might result in 15, 18, 20 or more bytes actually transmitted depending on headers, To/From addresses, CRC, etc.

To date, I have ALWAYS used a separate receiver to confirm what I was actually transmitting over-the-air. Only then do you really know if you are transmitting what you 'think' you are transmitting.

What I really need, though, is a way to capture the FULL transmit contents locally on the microcontroller doing the transmitting. I'd like to save ALL of the outgoing bytes to an array, etc., at the same time (or INSTEAD OF) having those bytes sent on to the RF section to be transmitted.

Can anyone please share if there is a place in RadioLib or typical microcontroller (C++ ?) code where the FULL outgoing series of bytes can be captured in this way?

Many thanks!

-Scott, K4KDR

[jgromes]

In generic terms (regardless of the library or radio being used), there is no way to get the entire packet this way, and the reason is pretty simple - under normal circumstances, some parts of the packet will be added automatically by the radio module. Things like preamble, packet length or checksum are not usually programmed directly by the user, but calculated and then added by the radio module.

So the best you can get is the payload data, but not the additional stuff, unless the radio module has a function like a "dry run", sending the constructed packet to the host MCU instead of transmitting, which I haven't seen yet. Of course, the radio isn't magical - it contructs the packet based on the user inputs and configuration, so you can re-construct the packet by reading all the releveant configuration, but I don't think that's what you're after.

Getting the payload data will of course depend on the library, RadioLib dumps it when SPI debug is enabled (as it's just another SPI transaction).

[K4KDR]

Thanks for the reply!

After posting my question, I kept searching and when I saw the following, I did remember that when debug is enabled, you see the entire 'as-transmitted' packet in the serial output:

... at least, I 'think' that is the section of code that accomplishes that -- but I for sure recall seeing the ultimate over-the-air hex bytes in the debug output.

Is there any way to access that same content in the code so that those bytes can be saved to an array?

Thanks!

[StevenCellist]

Easiest solution is to add the following in LoRaWAN.h e.g. at line 869:

    uint8_t k4kdrLen = 0;
    uint8_t k4kdrMsg[RADIOLIB_STATIC_ARRAY_SIZE] = { 0 };

And in LoRaWAN.cpp at line 1118:

  this->k4kdrLen = uplinkMsgLen - RADIOLIB_LORAWAN_FHDR_LEN_START_OFFS;
  memcpy(this->k4kdrMsg, &uplinkMsg[RADIOLIB_LORAWAN_FHDR_LEN_START_OFFS], this->k4kdrLen);

Then after an uplink you can retrieve it from your code:

  Serial.print("[LoRaWAN] Sending uplink packet ... ");
	int state = node.uplink(payload, payLen, fPort, isConfirmed);
	if(state == RADIOLIB_ERR_NONE) {
		Serial.println(F("success!"));
	} else {
		Serial.print(F("failed, code "));
		Serial.println(state);
	}
  uint8_t array[RADIOLIB_STATIC_ARRAY_SIZE];
  memcpy(array, node.k4kdrMsg, node.k4kdrLen);

[K4KDR]

Thanks so much - I'll give it a try!!

[K4KDR]

Wanted to follow-up and confirm with huge thanks that your recommendation worked perfectly for me!

It may be worth noting that the code added to LoRaWAN.h, regardless of the exact line number, needs to be ABOVE this section:

#if !RADIOLIB_GODMODE
  private:
#endif

... the line numbers in my working file were slightly different, so the suggested "line 869" put that code below the 'RADIOLIB_GODMODE' section and therefore caused a 'private' error when compiling.

But otherwise, as you can see below from an over-the-air test, I now have local access (on the transmitting device) to the full transmitted payload!

[K4KDR]

... I'll also take the liberty of posting the 'print' code that I added. In contrast w/ the screen shot above, I've also included an extra 'zero' to be printed in front of those single-digit bytes so that the output looks more like proper HEX bytes

// print the array contents (i.e., transmitted bytes)
  Serial.println("Transmitted bytes:");
  for (int x = 0; x < node.k4kdrLen; x++)
    {
      if (array[x] < 10){
      Serial.print("0");
      Serial.print(array[x], HEX);
      Serial.print(" ");
      } else{
      Serial.print(array[x], HEX);
      Serial.print(" ");
      }
    }
  Serial.println("\n"); 

... and the new result:

[K4KDR]

I'm nowhere near 'done' (are you REALLY ever 'done'?), but wanted to share what I was trying to accomplish.

Using the long-standing LoRaWAN capabilities in RadioLib, of course it's no problem to assemble and transmit a valid, encrypted LoRaWAN packet using credentials setup on TTN, etc.

But now that I am able to access the raw hex bytes generated by a command like node.uplink, I was then able to use the new LR-FHSS capability enabled for LR11x0 modules to re-transmit that same LoRaWAN payload as LR-FHSS with radio.beginLRFHSS -and- radio.transmit !!

(... I can't account for that 'Time Out While Transmitting' error - as you can see on the waterfall it DID transmit)

... of course, the painful part is that I don't have any way to DECODE the LR-FHSS to confirm that it's valid. But it's a start and I'm please to have gotten this far. Thanks again!

[jgromes]

@K4KDR FYI I'm currently trying to get LR-FHSS working with SX126x. It can only transmit it, but that would at least give me a second device to test the reception on LR1110.

[jgromes]

@K4KDR FYI this issue should be fixed in e855636

[K4KDR]

Thanks, but I'm more confused than I normally am... looks like the only file changed was
src/modules/LR11x0/LR11x0.cpp ... is that file even utilized when the hardware selected is an sx126x?

From your comment on the commit, it looks like this has something to do with a 'time on air calculation'??

[jgromes]

Oops, sorry, I commented on the wrong thread ... what I meant was that I fixed the LR1110 LR-FHSS Tx timeout issue you've been seeing.

[K4KDR]

Thanks a million - that worked perfectly!

[K4KDR]

Great! Funny you should mention, because I did my initial setup for this 're-transmit LR-FHSS' scheme on the Pi-Pico/sx1262 combo until I realized that there WAS no LR-FHSS on the sx126x modules yet!

Thanks!!

[K4KDR]

Please say if you'd prefer for me to open a separate ISSUE or DISCUSSION item for this related question, but despite searching all through RadioLib, I was not able to understand how to increase (or disable) the TX Time-Out value.

LR-FHSS takes several seconds, depending on settings & payload length... much longer than most single LoRa packets. By chance could I throw in the towel and ask for direction on where I might be able to adjust that to eliminate the TX Time-Out error? Thanks!

[jgromes]

The timeout is just due to me being lazy and just using 5x the packet length divided by the nominal bit rate as the timeout instead calculating the time-on-air properly ;)

[MrSniffer]

The timeout is just due to me being lazy and just using 5x the packet length divided by the nominal bit rate as the timeout instead calculating the time-on-air properly ;)

On the SX1262, does the calculation support both SF 5 and SF 6 data rates? If not, how can I programmatically set the TX Timeout?

[jgromes]

@MrSniffer this thread is about the LR-FHSS modulation, not LoRa. Nevertheless, for LoRa, Tx timeout is calculated as 150% of the expected time-on-air and yes, all SFs are supported. The timeout itself is not available to be changed by the user when using the blocking transmit method.

[MrSniffer]

When using non-blocking startTransmit, where does one set the tx timeout? I see the startReceive timeout parameter, but not for startTransmit.

[jgromes]

@MrSniffer When using interrupt-driven transmit the timeout implementation is up to you. You start transmission, and if the radio does not signal Tx completion using interrupt within some time frame, you can reset it, send it to standby or whatever else you want to do.

However, this is very much off-topic in this discussion. If you neeed further assistance, please open up a new one. Thanks!

[K4KDR]

No problem! Last night I did find:

... but did not know how to use it.

[K4KDR]

Related question on the topic of LR-FHSS, if you can put up with ONE MORE....

Do you know the baud rate & framing that these LR-FHSS GMSK packets utilize? Absent any existing code (or affordable hardware) to decode these signals, I'd like to invest some time in trying to decode even a PORTION of the packets now that transmitting them from the LR1110 is working so well.

Thanks!

[jgromes]

As far as I can tell, the only public informations sources are:

1. AN1200.64 Application Note: LR-FHSS System Performance
2. LR1110/LR1120 User manual
3. Semtech's SX126x LR-FHSS demo on GitHub: https://github.com/LoRa-net/SWDM001

From those, the baud rate is stated to be 488.125 baud. For the other stuff like the framing, error coding etc. you have to do some digging - for example, the above mentioned demo contains the following diagram which shows how the encoding works :

/**************************** Build LR-FHSS Frame ***********************************************************
 *    Core of the LR-FHSS frame generator                                                                   *
 *                                                                                                           *
 * In |---------|  |-----|  |-----------------|  |-------|  |------------|  |----------------------|  Out    *
 **---|Whitening|--|CRC16|--|Outer Code + CRC8|--|Viterbi|--|Interleaving|--|Sync+header+crc Header|------   *
 *    |---------|  |-----|  |-----------------|--|-------|  |------------|  |----------------------|         *
 *                                                                                                           *
 ************************************************************************************************************/

For real investigations, SDR will be a way to go here.

[K4KDR]

Thanks - I'll dig into it!! I guess I was really (poorly) asking what modulation & framing RadioLib was using to transmit these LR-FHSS packets.

[jgromes]

There's really not much choice - the modulation, baud rate and framing format is all fixed. The only things that can be changed at the moment are the coding rate and bandwidth.

[K4KDR]

Ahh,, very good - thank you! I didn't know how much 'hands-on' manual manipulation you used to create LR-FHSS capability in RadioLib.

Just wanted to have as much info to work with as possible - thanks!