RAK12500 outputs to UART1 can't use RAK13002 UART

[billr (Bill Richards)]

Is there any way of stopping this behaviour?

We want to set up hard wired comms with the RAK4631 via UART1, however we have found that when the RAK12500 is installed it floods UART1 with GPS data.

Further, I have one board writing to Serial1 we connect a TTL converter to Serial1 and can see the data which is being written to it.

We then connected that board’s TX to another board via a RAK13002 … using Serial, Serial1, or Serial2 do not appear connected to either UART0 or UART1 on that board

[beegee (Bernd Giesecke)]

Did you try my_gnss.setUART1Output(0);

The function has three options:

const uint8_t COM_TYPE_UBX = (1 << 0);
const uint8_t COM_TYPE_NMEA = (1 << 1);
const uint8_t COM_TYPE_RTCM3 = (1 << 5);

Maybe 0 stops the output.

[billr (Bill Richards)]

I will give that a go immediately … I never considerd trying any other value than those presented in the enumeration

[billr (Bill Richards)]

Sadly @beegee that does not have the desired effect

On another issue

this board has Tx1 (Serial1) connected to Rx0 (Serial2).

The messages being sent to Serial1 are

  char x_OSANA[] = "$OSANA,01,+00308,+00538,-99999,-99999,04487,00002,00002,00003,0000,00000";
  char x_OSSWO[] = "$OSSWO,01,Q,123,003.78,M,00";
  char x_OSVSB[] = "$OSVSB,01,12535,12543,12545,00000,-00033,+00083,-00033";
  char x_OSGP1[] = "$OSGP1,01,0111.46394,N,10347.42926,E,09,20.428";

This routine is used to read the data from Serial2 (which is the input for the output from Serial1) …

  bool messageIsComplete = false;
  if(Serial2.available() > 0 && !messageIsComplete)
  {
    char c;
    Serial2.readBytes(&c, 1);
    
    if(c != '$')
    {
      x_RXData[message_index] = c;
      ++message_index;
    }
    else
    {
      messageIsComplete = true;
    }
  }

  // we've got the whole message, so send it.
  if(messageIsComplete)
  {
    // send it
    Serial.println(x_RXData);
    // clear buffer
    memset(x_RXData, char(0), 1024);
    x_RXData[0] = '$';
    // reset index
    message_index = 1;
  }
  

but it never yields any result; however on another board (on your side of the world at the moment) it works as expected -I can actually check the routine working locally by swapping the reading from Serial2 to Serial1 because I have a GPS module attached which, as we discovered recently, floods Serial1 with GPS data and this routine correctly outputs all of those data.

The only difference between those two boards is that my board (which doesn’t work as expected) has the RAK4631 core and the other board (which does work as expected) has the RAK4631(L) core.

[beegee (Bernd Giesecke)]

Hi @billr
There was a bug in the BSP, did you update to V1.0.1?
If on PlatformIO, I have to check if the fix is implemented in the RAK_PATCH already.

Or manually path the variant.h:

/*
 * Serial interfaces
 */
// TXD1 RXD1 on Base Board
#define PIN_SERIAL1_RX (15)
#define PIN_SERIAL1_TX (16)

// TXD0 RXD0 on Base Board
#define PIN_SERIAL2_RX (19)
#define PIN_SERIAL2_TX (20)

[beegee (Bernd Giesecke)]

@billr
You can use the RAK12500 as well in Slot C on the bottom of the RAK5005-O, that slot has the I2C, but doesn’t have the RXD/TXD connected.

[billr (Bill Richards)]

I did not realise there was an update/bug-fix for the BSP, I’ll grab that and give it a whirl.

@beegee

You can use the RAK12500 as well in Slot C on the bottom of the RAK5005-O, that slot has the I2C, but doesn’t have the RXD/TXD connected.

This is good news too.

Thanks @beegee

[billr (Bill Richards)]

@beegee

// TXD0 RXD0 on Base Board
#define PIN_SERIAL2_RX (19)
#define PIN_SERIAL2_TX (20)

This was it my friend. I had previously applied the RAK_PATCH, so I think it’s safe to say that the fix has not been implemented there.