Go Down

Topic: Minor "noise" with NewSoftSerial (Read 2944 times) previous topic - next topic

Daniel Bolgheroni

Quote
Is it the same "noise" each time?


No, but most often appears "Q", "Y", ")" and "Ã". A little test I made:

Code: [Select]

dbolgheroni@mob-compaq:~$ sudo tip -38400 /dev/ttyU0
connected
TCCino v0.1
Sending command to reset ELM327... ATZ sent.
> gv
QÃYÃ)Ã12.3V


> gv
GÃÃÃ12.3V


> gv
QÃYÃ)Ã12.3V


> gv
ÃYÃ
   12.3V


> gv
QÃYÃ)Ã12.3V


>
dbolgheroni@mob-compaq:~$ sudo tip -38400 /dev/ttyU0


Quote
If so, perhaps it isn't "noise" at all. Perhaps there is some significance to the values, but not as characters.


You are right, but why don't I get these characters using an UART, e.g. a hardware serial of Mega2560?

PaulS

Quote
You are right, but why don't I get these characters using an UART, e.g. a hardware serial of Mega2560?

I don't know that I'm right. I would still like to see that the individual bytes look like, using
Code: [Select]
Serial.print("Byte: ");
Serial.println(t, DEC);


I see that you set pinMode for the NewSoftSerial pin, AFTER telling NewSoftSerial about the pin. I wouldn't think this advisable.

I also see that you use Serial.flush(). This throws away any data in the input buffer that has not been read yet. Rarely is this a good idea.

Code: [Select]
   if (t >= ' ')
     cmdrx[i++] = t;

It might be necessary, based on the results of printing t as a DEC value, to expand the if statement to exclude characters on the other end of the ASCII table, too.

Daniel Bolgheroni

Quote
I see that you set pinMode for the NewSoftSerial pin, AFTER telling NewSoftSerial about the pin. I wouldn't think this advisable.


This is there because it was suggested this pin would need an pullup resistor. This can be made by software (ATmega328 have internal 20k pullup resistors) and by hardware. But it doesn't change anything since the code is commented.

http://www.arduino.cc/en/Tutorial/DigitalPins

Quote
I also see that you use Serial.flush(). This throws away any data in the input buffer that has not been read yet. Rarely is this a good idea.


What I have is this:

Code: [Select]

computer <--> Arduino* <--> *OBD-II serial cable <--> OBD-II complaint car

* the Arduino to OBD-II cable is the one using NewSoftSerial

Maybe the Serial.flush() you're mentioning are the one in loop(). I'm cleaning Serial AFTER I read a command from the computer, and after all the input needed was received, e.g. the function getvoltage() already reached the prompt from OBD-II cable; at this point I know the cable connected to the car won't send anything until I ask again with a new command.

Thank you.

mikalhart

#18
Nov 24, 2010, 01:23 am Last Edit: Nov 24, 2010, 01:25 am by mikalhart Reason: 1
Daniel,

When you perform the identical test using the hardware serial port, is the command string, i.e. "atrv" echoed back from the serial device?  If so, my theory is that the "noise" you are seeing is this command string being corrupted.

And Paul is correct; you should not touch any pins whose control you have turned over to NewSoftSerial (or any other library, I would think).

Mikal

Daniel Bolgheroni

Quote
When you perform the identical test using the hardware serial port, is the command string, i.e. "atrv" echoed back from the serial device?  If so, my theory is that the "noise" you are seeing is this command string being corrupted.


Yes! That's a detail I forgot to mention. In this case, I get this:

Code: [Select]

>ATRV
ATRV
11.7V

>


But I didn't understand how can the OBD cable get fine what I send through NewSoftSerial, .e.g. the ATRV command, return the expected value and JUST corrupt the echoed command.

I would like to understand. I'm not the kind of person who just leave things half-made. And I really want to make this NewSoftSerial works right, even if it's working with Mega2560.

Quote
And Paul is correct; you should not touch any pins whose control you have turned over to NewSoftSerial (or any other library, I would think).


Yes, I agree, but was just an attempt. This is why I commented out after seeing it doesn't work. I will remove it anyway, to avoid confusion.

Thank you again.

mikalhart

Ok, I think I can solve this mystery.  I'm making a couple of assumptions here, but I think it will pan out.

Software-based serial solutions are necessarily half duplex.  Because TX and RX require 100% of the processor, you cannot receive a byte while you are already transmitting one.

What I think is happening here is that the serial device on the other end echoes the command characters back immediately.  Byte 0 is echoed back, but because byte 1 is already being transmitted, part of it is lost.

The data itself is not corrupted because it is not generated until after the entire transmission ends.

Many serial devices have commands to disable echoing.  (I seem to remember the old modems I used to hack used ATE0.)

I think the solution is to either disable echo, or, alternatively, instead of

ASERIAL.println("atrv");

try sending the characters one at a time and wait for the echo before proceeding.

Mikal

Coding Badly


...or, if you can, turn off the echo.

Daniel Bolgheroni

Thank you for all the replies. Turning the echo off just worked!

The command to disable echo is, indeed, ATE0. I think it's a default command for most serial devices.

Go Up