Removing" \r\n" from" Serial2 input

Hello,
Like many others I an new, I am not a programmer and really do not find it easy no matter how much I read.
I really would appreciate some help with a small part of my program.
I am using an Arduino Mega
Currently I have a Geiger connected to Serial2 and am using the following snipped to read from that port:

    // Now listen on the second port
    while (Serial2.available()) {
      char inChar = (char)Serial1.read();

      // Tried all manner of things here!

      Serial.print(inChar);
      logfile.print(inChar);  
    }

The count data from the Geiger is ASCII and each piece ends with "\r\n".

I have tried many things to remove these hidden characters but the snippet wither crashes, fails to compile because I'm trying to use something like remove or replace which I understand are string operators.

At the moment I am writing Date, Time, Serial1, Serial2

Serial2 contains its own \r\n which I use but I cannot remove those codes from Serial1 which is breaking up my line:

Initializing SD card...
Logging to: LOG00023.CSV
2018/6/12,10:20:22,20
2018/6/12,10:20:23,20
21
2018/6/12,10:20:24,20
21
2018/6/12,10:20:25,19
21
2018/6/12,10:20:26,19
21

So I have:
Date,Time(one second increments), Serial1\r\n
Serail2
Date,Time(one second increments), Serial1 \r\n
Serail2
Date,Time(one second increments), Serial1 \r\n
Serail2

What I need is:
Date, Time(one second increments), Serial1, Serial2
Date, Time(one second increments), Serial1, Serial2
Date, Time(one second increments), Serial1, Serial2

Some pointers or assistance would be most helpful.

Regards

Martin

Suppose that I was handing you candy bars or rocks. You are not supposed to eat the rocks.

Would YOU have any problem determining that what I handed you was a rock vs. a candy bar?

What would you do with the rocks?

Have a look at the examples in Serial Input Basics - simple reliable ways to receive data.

if you use the second example then only the '\r' will be saved and you know it will always be the last character so if you overwrite the '\r' with a '\0' it will shorten the cstring and eliminate the CR

...R

Robin2:
Have a look at the examples in Serial Input Basics - simple reliable ways to receive data.

if you use the second example then only the '\r' will be saved and you know it will always be the last character so if you overwrite the '\r' with a '\0' it will shorten the cstring and eliminate the CR

...R

Hi Robin.
Thanks for getting back to me.
Try as I might... I just don't see it.
I cannot see the connection between my problem and the example you directed me to. Earlier PaulS most helpfully asked if I would notice the difference rocks and candy bars. I obviously do not.
I don't understand the logic of the example nor how may be inserted into my code.
The problem is mine... I know that... I am simply so poor at coding.

Earlier PaulS most helpfully asked if I would notice the difference rocks and candy bars. I obviously do not.

if(object != rock && object != pebble)
{
   eatCandyBar();
}

Now, in your case the object is inChar, and the rock is the '\n' and pebble is the '\n'.

moorem:
Hi Robin.
Thanks for getting back to me.
Try as I might... I just don't see it.
I cannot see the connection between my problem and the example you directed me to.

You say the data being received ends with \r\n.

If you use the second example in Serial Input Basics it treats the \n as the end-marker and it does not include it in the saved message. Consequently the last item in the saved message will be the \r.

You can find the length of the saved message with strlen() and when you know the length you can identify the final character (the \r) and over-write it. Something like this

byte mesgLen = strlen(receivedChars);
receivedChars[mesgLen - 1] = '\0';

...R

PaulS:

if(object != rock && object != pebble)

{
  eatCandyBar();
}




Now, in your case the object is inChar, and the rock is the '\n' and pebble is the '\n'.

So that works out as:

if(inChar != '\n' && inChar != '\n');

Which seems to be repeating itself.

In plain language that is:
If (inChar is not equal to '\n\ and inChar is not equal to '\n');

Doesn't make sense to me. No wonder I'm so bad at this.

moorem:
So that works out as:

if(inChar != '\n' && inChar != '\n');

I suspect you have already figured out that @PaulS made a small type typo and should have said

Now, in your case the object is inChar, and the rock is the '\r' and pebble is the '\n'.

...R

EDIT to correct my own typo :slight_smile:

Robin2:
I suspect you have already figured out that @PaulS made a small type and should have said
...R

I did indeed.... nonetheless I am most grateful for the pointers and understanding from both Paul and yourself.

I used to teach engineering (I'm in my golden years now) and I applaud the patience that others freely demonstrate in these forums... it is teaching and a noble thing to freely be involved in.

I'm not having a great time with this and may seek paid assistance through the forum.

Robin2 and PaulS are suggesting two different ways to deal with the \r\n.

PaulS suggest "don't eat them". Robin2 suggests to use his methods to eat them, but don't use them. To be precise, his algorithm will only eat the \r not the \n.

Robin2's Serial Input Basics methods are rock solid and very useful in all sorts of serial reading situations. I think you are indeed better off pulling in the entire message and processing it when complete, instead of printing and logging each char as it arrives. Follow the example of read with end marker where \n is the end marker. The \n is not added to the received characters by his reading algorithm

Robin2 has given very clear advice on how to remove the remaining \r.

I used to teach engineering (I'm in my golden years now) and I applaud the patience that others freely demonstrate in these forums... it is teaching and a noble thing to freely be involved in.
I'm not having a great time with this and may seek paid assistance through the forum.

You can do this! I am convinced that Robin2's tutorial and methods will get you there.

cattledog:
You can do this! I am convinced that Robin2's tutorial and methods will get you there.

You were right.

I did indeed persevere with the coding. You were right about Robin2's tutorial posting. Like any good tutor the direction was better in providing a long-term gain than just providing an instant answer.

My thanks to Robin2 and Pauls for their guidance.

Regards,

Martin