Go Down

Topic: Serial comms problems talking to external device - strange values (Read 2153 times) previous topic - next topic

dan86

Hi guys, new to the forum here!

Just to note, I have searched the forums and Google but not found any answers for my issues.. I will try and give as much information as possible about my problem, but please forgive me if some parts are vague, this project is my dissertation at university and I am working with a device where I am obliged to maintain a certain level of non-disclosure.

Ok, so on to my problem :)

I am trying to communicate between my Arduino Mega 1280's Serial3 pins and the aforementioned device's UART. The device has a Maxim 3223CAP chip built in and I have checked with a multimeter on the UART to make sure I am dealing with TTL voltage levels, I am. I have also checked the auto shutdown configuration of the Maxim chip and it is forced on currently so there should be no problems with it being in shutdown mode.

From an Arduino digital pin I drive a pin on the external device from low to high which triggers a reset. When the device resets it should send a 32 byte notification confirming the completion of the reset. Using the Serial.read and Serial.println commands I do receive a response from the device, however the values I receive are not correct. I am however positive that the device is sending the correct response as I have plugged it into the serial port on my PC and received the correct response in a piece of software called 232Analyzer. I have also wired it simultaneously to the PC and Arduino so I can monitor the data in 232Analyzer and the Arduino serial monitor (using different com ports), I still get the same result.

I have also checked all the grounds are fine and all my connections are strong (soldered to pins).

The specified setup information for my device is: Baud rate - 115200, byte size - 8 bit,  no parity, stop bit - 1 and no flow control.
The 232Analyzer program setup is: Baud rate: 115200bps; Parity: None; Data bit: 8; Stop bit: 1;  Handshaking: None

I have read that the default Arduino settings are as above (aside from setting baud rate).

Interestingly I only receive 31 bytes back not 32 bytes as expected and from examing the order of the data and where I would expect a succession of one value, it it is the first byte that is always missing.

It also seems that where I should receive multiple values of 0x00 I get 0xFF, however elsewhere where I should get 0xFF I get 0x01. Also a value that should increase 0,1,2,3 etc with each message starts on 0xFD and goes to 0xF5, 0xED, 0xE5 and so on in this fashion, which if you look at as decimal decreases by 8 every time.

I really am unsure where to go from here, so if anyone has any ideas please share them, it will be very much appreciated.

Thanks! Dan

Code: [Select]
 
byte resp;
 
  void setup()
 
{

  Serial.begin(115200);
  Serial3.begin(115200);

  // set pin 35 as an output
    pinMode (35, OUTPUT);
  // set pin 35 low
    digitalWrite(35, LOW);
  // wait 100ms
    delay(100);
  // set pin 35 high
    digitalWrite(35, HIGH);   
   
  // flush serial
 
  Serial3.flush();
  Serial.flush();
 
  // wait 2 seconds (this is required by the device for boot up time)
   delay(2000);
   
}

void loop() {
 
  // if serial data is available run readresp function
 
    if (Serial3.available()){
    readresp();
}
}

  // Read response function

void readresp(){
 
  resp=Serial3.read();
  Serial.println(resp, HEX);
  } 



PaulS

The Serial.flush() function dumps any data in the receive buffer. Since the receive buffer is created when the Serial.begin method is called, the buffer has only 100 milliseconds to receive data from the sensor, which you say takes 2 seconds to boot up.

It hardly seems necessary to be flushing the buffers.

The art of getting good answers lies in asking good questions.

AWOL

Are you quite sure you haven't got an inversion going on here?

graynomad

Quote
0x00 I get 0xFF

Sounds like inversion, and that might explain missing the first characters as well. The strange values may also be explained this way because your receiver would be out of sync with the transmitter.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

dan86

Thanks for your replies guys

@PaulS
Quote
It hardly seems necessary to be flushing the buffers.


Thanks for the input Paul, I had added this in purely to make absolutely sure nothing was in the buffer as the device sends a message every 700ms to notify that it is active, however you're right it is not really necessary.



Quote
Are you quite sure you haven't got an inversion going on here?


Quote
Sounds like inversion, and that might explain missing the first characters as well. The strange values may also be explained this way because your receiver would be out of sync with the transmitter.


@Graynomad & AWOL

This thought had crossed my mind, however I was not sure as you've noticed not all values are the inverse. I have looked at the Max3223CAP datasheet and it does mention inversion
Quote
The MAX3221/MAX3223/MAX3243's receivers convert RS-232 signals to CMOS-logic output levels. All receivers have one inverting three-state output.
... So this looks like it is inversion, I have also put the multimeter on the device's UART TX pin where I get a negative TTL voltage.

Any thoughts on how to do deal with this? I'm guessing I will need to source an inverter or put one together (something like: http://www.play-hookey.com/digital/experiments/ttl_inverter.html )

Cheers, Dan

graynomad

I think NewSoftSerial can handle inverted data, not sure about 115200 bps though. You would still need to level shift though.

You're only receiving from this gadget right?

You could level shift and invert with a transistor and 2 resistors (and maybe a diode to stop the -ve Vs).

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

dan86

Quote
I think NewSoftSerial can handle inverted data, not sure about 115200 bps though. You would still need to level shift though.

You're only receiving from this gadget right?

You could level shift and invert with a transistor and 2 resistors (and maybe a diode to stop the -ve Vs).


I did try NewSoftSerial to see if it made any difference, it didn't seem to like 115200 bps though, it dropped a fair few values. I didn't try it's inverting feature though, will give that a go now. Currently I am only receiving from the device but I will need to transmit serial data to it as well, so I wonder if I would need to put an inverter on the TX pin as well, I would have thought the Max3223 would be ok with receiving normal TTL values. The data sheet is here incase anyone could take a look, maybe make more sense of it than me! http://datasheets.maxim-ic.com/en/ds/MAX3221-MAX3243.pdf


graynomad

Do not put this +-5v signal directly into the Ardiuno!
Rob Gray aka the GRAYnomad www.robgray.com

graynomad

#8
Mar 14, 2011, 02:22 pm Last Edit: Mar 14, 2011, 02:34 pm by Graynomad Reason: 1
So the gadget is producing a +-5v signal.

If you use a hardware UART you have to invert, no choice.

If you use NSS and the invert features works then

receiving
A diode and an external pull down resistor should do.

transmitting
Using nothing might work, many 232 receives will operate with a single-ended input. But it might not as well.

If it doesn't work then you need to generate a - voltage, in which case you may as well use a MAX232-style chip and be done with it.

If this is a commercial project I would recommend adding a MAX232 or similar. If you're just playing around then try it without anything on the transmitter.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

dan86

Thanks for your help with this Graynomad, it was a strange one which I didn't manage to completely work out, the voltage out of the UART was -ve but was supposed to be TTL, it did toggle from 0 to -5v. Anyhow I found another pin on the board which I can use which has +ve TTL. I made my connections and am now talking back and forth :) Now just trying to solve more device specific problems.

Go Up