Bad Data on Serial Port

Projects Programming
1

I am connecting a Texas Instruments EVM430-AFE253S to an Arduino Mega, to read power on a high voltage line. The wiring diagram is attached.

According to the datasheet on page 17, the unit should be outputting 12 bytes of data, every ~66 mS.
The first byte should be always be 0x68, and the 11th byte should always be 0x00.

The serial format is 9600 bps, No parity, 8 data bit, 1 stop bit.

When I read the serial port on the Arduino, this is what I receive:

29,6A,EB,E7,1,0,9B,80,CF,CD,0, 
29,2A,FD,E9,1,0,3B,80,D6,D, 
29,EA,EB,E7,1,0,33,E8,A1,0, 
29,EA,FD,EB,1,0,3C,80,DC,B7, 
29,EA,FD,E7,1,0,36,80,9A,39,0, 
29,2A,EB,E7,1,0,34,80,98,9, 
29,AA,FD,E7,1,0,9D,80,A7,C9, 
29,2A,EB,E9,1,0,2E,80,93,69,0, 
29,6A,EB,E9,1,0,2C,80,FC,3B, 
29,2A,EB,EB,1,0,27,80,C7,D3,0, 
29,EA,FD,E7,1,0,11,0,9E,FF,0, 
29,2A,FD,E9,1,0,8,9C,31,0, 
29,AA,F5,E7,1,0,23,5D,B5,0, 
29,6A,F5,E7,1,0,8B,A8,13,0, 
29,2A,F5,E5,1,0,1C,0,57,8B,0, 
29,AA,EA,E7,1,0,91,B9,95,0, 
29,2A,EA,E7,1,0,CB,8D,95, 
29,EA,FD,E9,1,0,31,80,F3,B7,0, 
29,6A,FD,E7,1,0,2C,80,E2,51,0, 
29,AA,FA,E9,1,0,19,2D,19,0, 
29,2A,FD,E5,1,0,C8,57,C1, 
29,AA,FD,E5,1,0,C8,49,A3, 
29,2A,EA,E5,1,0,1A,A5,99,0, 
29,AA,EA,E9,1,0,90,27,81,0, 
29,EA,EA,E7,1,0,2C,80,E3,DD,0, 
29,2A,F5,E7,1,0,95,80,E2,89,0, 
29,EA,EA,E7,1,0,98,80,F2,83,0, 
29,6A,FD,E7,1,0,8D,5D,BF, 
29,6A,FA,E7,1,0,8A,A3,D1,0, 
29,AA,FA,E7,1,0,10,0,F3,59,0, 
29,2A,FD,E5,1,0,8E,5C,77, 
29,6A,FD,E7,1,0,8D,AE,C1, 
29,6A,FD,E7,1,0,2C,80,E3,FF,0, 
29,6A,FD,EB,1,0,2F,80,FE,69,0, 
29,AA,FA,E9,1,0,24,80,E0,F3, 
29,AA,FA,E9,1,0,88,3C,2B,0, 
29,AA,FA,E7,1,0,17,0,FA,F9, 
29,2A,FD,E9,1,0,46,D7,A9, 
29,6A,FD,E7,1,0,45,D3,8F, 
29,AA,FD,E7,1,0,15,0,4B,67, 
29,EA,FA,E7,1,0,90,DB,1B,0, 
29,2A,FD,E7,1,0,29,80,FC,33, 
29,6A,FD,E7,1,0,26,80,C0,8F, 
29,AA,FD,E9,1,0,92,80,85,5B,0, 
29,2A,EA,E7,1,0,34,80,CD,2D, 
29,AA,EA,E7,1,0,A0,80,F5,15,0, 
29,6A,F5,E7,1,0,D2,7D,4B, 
29,2A,F5,E7,1,0,53,C0,C0,37, 
29,2A,F5,E7,1,0,A6,40,C2,EB, 
29,2A,F5,E9,1,0,42,80,DB,25, 
29,EA,F5,E5,1,0,43,80,AD,73,0, 
29,2A,F5,E7,1,0,34,7C,F3,0, 
29,AA,FD,E7,1,0,D2,BE,A1, 
29,EA,FA,E7,1,0,A5,40,C1,5,0, 
29,AA,FA,E7,1,0,A3,80,FB,C5,0, 
29,AA,FD,E7,1,0,67,AA,C1, 
29,2A,F5,E7,1,0,CD,38,B7,0, 
29,AA,F5,E9,1,0,CB,28,7B, 
29,EA,F5,E9,1,0,CC,38,E7,0, 
29,2A,F5,E7,1,0,CF,4D,3D,0, 
29,EA,F5,E9,1,0,51,1,22,BF, 
29,EA,F5,E7,1,0,34,77,B7, 
29,AA,F5,E7,1,0,A4,80,EE,79, 
29,EA,F5,E7,1,0,4E,1,82,27,0, 
29,2A,F5,E7,1,0,A9,C0,FC,4B,0,

I connected an oscilloscope to the serial and ground pins (see other attached picture).
Using the on-board serial decoder, I read 68,5B,35,00,0B,FF,FF,A2,01,51,00,48.
Over multiple reads, the first and 11th byte remain constant (0x68 & 0x00 respectively).

Why am I getting completely different data?
Why am I not getting 12 bytes each time?

void setup()
{
	unsigned long PowerOnTime = millis();
	uint16_t i,j,k;

	uint8_t temp,temp2,data[100];
		
	Serial1.begin(9600);
	Serial2.begin(9600);

	Serial.begin(115200);
	Serial.println(micros());

	temp2 = 0;
	while(1)
	{
		while(Serial2.available())
		{ 
			data[temp2++] = Serial2.read();
			PowerOnTime = millis();
		}
		if((temp2 > 30) || ((millis() - PowerOnTime) > 40)) 
		{
			for(i = 0; i < temp2; i++)
			{
				Serial.print(data[i], HEX);
				Serial.print(",");
			}
			temp2 = 0;
			Serial.println(" ");
			PowerOnTime = millis();
		}
	}
}

Power Measurement Schematic (Correct 2).png
Power Measurement Schematic (Correct 2).png1698×794 11.6 KB

0321191043c_resized.jpg
0321191043c_resized.jpg2328×1310 935 KB

2

There should be no reason to use millis()
Just read 12 bytes then stop and start over again.

3

Is that serial signal inverted? As standard UART signal is HIGH on idle.

4

pittengerj:
The first byte should be always be 0x68, and the 11th byte should always be 0x00.

So you are receive a sentence that starts with a 0x68 and ends with a 0x00.

You'd want to code so that as you receive a 'random' set of data coming from the serial line and not record any data received till a 0x68 is received and you'd want to save the incoming data till you get a 0x00 where you'd then send that data to a parser for further processing and allow your data receiver to continue receiving serial data.

I use a < to denote the beginning of my serial sentences and a > to denote the end of my serial sentences and the data instruction and data is sent in between those delimiters.

I use something like this which I, orginally wrote for a Arduino Uno but has morphed as I moved from a Uno, to a Mega, to a Due, to a STM32, to a ESP32. So just ignore the ESP32 code and you should be able to see how I am ignoring data till a < is received. How the data is collected till a > is received and then where the data is sent to the parser for processing. This code would easily adapt to your listed sentence start and stop characters.

void fReceiveSerial_LIDAR( void * parameters  )
{
  bool BeginSentence = false;
  sSerial.reserve ( StringBufferSize300 );
  char OneChar;
  for ( ;; )
  {
    EventBits_t xbit = xEventGroupWaitBits (eg, evtReceiveSerial_LIDAR, pdTRUE, pdTRUE, portMAX_DELAY);
    if ( LIDARSerial.available() >= 1 )
    {
      while ( LIDARSerial.available() )
      {
        OneChar = LIDARSerial.read();
        if ( BeginSentence )
        {
          if ( OneChar == '>')
          {
            if ( xSemaphoreTake( sema_ParseLIDAR_ReceivedSerial, xSemaphoreTicksToWait10 ) == pdTRUE )
            {
              xQueueOverwrite( xQ_LIDAR_Display_INFO, ( void * ) &sSerial );
              xEventGroupSetBits( eg, evtParseLIDAR_ReceivedSerial );
              //
            }
            BeginSentence = false;
            break;
          }
          sSerial.concat ( OneChar );
        }
        else
        {
          if ( OneChar == '<' )
          {
            sSerial = ""; // clear string buffer
            BeginSentence = true; // found begining of sentence
          }
        }
      } //  while ( LIDARSerial.available() )
    } //if ( LIDARSerial.available() >= 1 )
    xSemaphoreGive( sema_ReceiveSerial_LIDAR );
    //            Serial.print( "fReceiveSerial_LIDAR " );
    //        Serial.print(uxTaskGetStackHighWaterMark( NULL ));
    //            Serial.println();
    //        Serial.flush();
  }
  vTaskDelete( NULL );
} //void fParseSerial( void * parameters  )

Note, I do not save the < and > as part of the received sentence as their only use is to serve as start/stop thingies.

ETA: This line: if ( LIDARSerial.available() >= 1 ), for a Uno and a MEGA you'd want to change it to if ( LIDARSerial.available() >= 0 ). I found the Due, STM32, and the ESP32 to work more realibly with the if ( LIDARSerial.available() >= 1 ).

5

Is that serial signal inverted? As standard UART signal is HIGH on idle.

Yes, the UART signals are inverted, according to the original RS-323 standard. The transmission is also LSB first.
The scope shows HHHLHLLH for 0x68.

The schematic for the TI board shows an isolated RS-232 output. It is designed for RS-323 voltage levels (+/- 3 to +/-15), with a logic one represented as a negative voltage. Since the circuit defines its voltage levels from pins 3, 4, 5 & 7, the output becomes logic one = 0V and logic zero = 5V.

I don't think the Arduino library allows for logic inversion or endianness changes. Those I can do with a lookup table.

There should be no reason to use millis()
Just read 12 bytes then stop and start over again.

I originally structured the test code to simply repeat back (on Serial) what it read from Serial2. I was not getting correct data, so I restructured it. The current structure will gather, then dump the data, to make sure I'm not missing any data from processing overhead.

So you are receive a sentence that starts with a 0x68 and ends with a 0x00.

No, the 12th byte is a CRC byte. The 11th byte is currently "not implemented" and therefore currently always 0x00. But since it is "not implemented" rather than specified as always 0x00, it is not a suitable framing byte, as it may change without notice in later hardware releases.

Once I am actually receiving all the bytes, I will add to my code to do better parsing and CRC calculations. I stripped the code down to a minimum, just to debug the serial data reading.

6

Is that serial signal inverted? As standard UART signal is HIGH on idle.

Actually, it just hit me. The inverted signal is causing the start bit to not be recognized properly!
I believe adding an inverter will fix the issue.

7

Yes, inverted signalling was the issue!

I added a logic inverter and everything works as expected.

Thank you