Teensy 3.5 Serial Woes

Status
Not open for further replies.

Deadsilly

New member
Hi All,

I am currently working on what I initially thought was a simple project reading data from the RS232 port of a pH meter with a Teensy 3.5. The meter sends data at time intervals over RS232. The hardware setup for this on the teensy is via a TTL to RS232 converter from here, a RS232 gender charger (I checked pin to pin connection with a multimeter) and the code is attached.

Code:
void setup() {
  Serial.begin(9600);
        Serial1.begin(9600, SERIAL_8N1);
        delay(100);
}
void loop() {

 String B;
 char A;
if (Serial1.available()>0){
   while (Serial1.available()>0){
    delay(20);
    A = Serial1.read();
    B += A;
   }
   Serial.print("UART received: ");
   Serial.println(B);
}
}

The pH meter is set to a baud of 9600 and the manual for it reports it needs, 8-bit data bits, 1 stop bit with no parity and XON/XOFF protocol. I can communicate to the teensy from a putty terminal (putty -->USB to RS232 converter --> RS232 to TTL --> Teensy), I can receive from the pH meter (pH --> RS323 to USB --> Putty) but I cannot get anything from the pH meter to the teensy. The common denominator in all of this is the RS323 to USB converter/ putty makes it work and the gender bender breaks it. I have checked the RS232 gender changer with a multimeter and it is just a connector and does not swap pins from what I can see. This leaves me to think that I am not quite understanding serial communication needed with the XON/XOFF protocol. I can however get putty to receive data even when I set the Flow control to off.

What I have done so far:
1. Shorted pins 1,6 and 4 together and pins 7 and 8
2. Figured out the pH meter has three pins connected back at the box (GND, TX and RX) (then realised 1 was not needed)
3. Investigated Serial1.write(17) and Serial1.write(19)

Any help appreciated.

Regards,
Deadsilly
 

Attachments

  • teensy_serial1.ino
    319 bytes · Views: 57
That is a 5V device - not enough detail there to see if it can run in 3.3V mode. That won't hurt the T_3.5 on digital pins, but having it see 3.3V from Teensy Tx as HIGH needs to be checked.

Wow XON/XOFF is decades ago … it requires monitoring of Rx for the XOFF char and pausing transmission until RX gets an XON byte when sending data to the device. The Teensy should have no issue buffering incoming with regular reading.
Software Handshaking Characters
Character Integer Value Description
Xon 17 Resume data transmission.
Xoff 19 Pause data transmission.

The Teeny just needs to connect GND to GND and then end up with the Teensy Rx crossed to device Tx and Teensy Tx crossed to the device Rx. If no output to the device is made than the Tx is not needed - perhaps that is what " (then realised 1 was not needed) " was suggesting?

Was this done on the device side of the RS-232 ? : " Shorted pins 1,6 and 4 together and pins 7 and 8 "
> The linked device PDF shows only this to connect?
Pin No Connection
2 Receive RS232 Data
3 Transmit RS232 Data
5 Ground

This code is small enough to be include in the CODE # within the post - changed to a 5 second while() wait for Serial USB to come online to assure no output is missed - that code looks to be enough to start showing any received data:
Code:
void setup() {
  Serial.begin(9600);
  Serial1.begin(9600, SERIAL_8N1);
  while ( !Serial && millis() < 5000 );
}

void loop() {
 String B;
 char A;
  if (Serial1.available()>0) {
     while (Serial1.available()>0){
      delay(20);
      A = Serial1.read();
      B += A;
     }
     Serial.print("UART received: ");
     Serial.println(B);
  }
}
 
make sure they have common grounds, testing from a PC though, the USB cable is already grounded to the PC so that will work for sure, but you need a ground from teensy to your device if you want them to talk
 
Hi Defragster,

Thank you very much for the additional ideas.

That is a 5V device - not enough detail there to see if it can run in 3.3V mode. That won't hurt the T_3.5 on digital pins, but having it see 3.3V from Teensy Tx as HIGH needs to be checked.

It does but to be sure I inserted a level shifter and still no dice. I also can get two way communication between the teensy and putty via serial.

Wow XON/XOFF is decades ago … The Teensy should have no issue buffering incoming with regular reading.

I know very old and does not really apply in this case as the teensy will keep up. Due to the use of the old protocols I am wondering if there is a particular AK/NAK it is waiting for to get it talking.

If no output to the device is made than the Tx is not needed - perhaps that is what " (then realised 1 was not needed) " was suggesting? Was this done on the device side of the RS-232 ? : " Shorted pins 1,6 and 4 together and pins 7 and 8

I was initially thinking that a the pH meter was using hardware handshakes so looped (pins 1,4 and 6 and pins 7 and 8 ) these together to get a false ready signal. I found out that there is only three wires coming from the pH meter to its RS232 being GND, TX and RX.

Thanks for the updated code but there were no hidden bytes.

Regards,
Deadsilly
 
Do you have a DC voltmeter? Can you measure the voltages on pins 2, 3 and 5 of the RS232 connector, with the meter's negative wire connected to Teensy's GND pin?
 
I'm going to guess you'll probably see -5V to -12V on pin 2, maybe around 0.25 volts on pin 3, and of course pin 5 should be very close to 0 since it's GND.

When working properly, both pins 2 and 3 should have -5V to -12V when the cables are plugged together. You should only get a low voltage on pin 3 if the pH meter is disconnected.

But what almost always happens with these 9 pin RS232 projects involving a gender changer is you end up with the Transmit signals from each side connected together. Many of those gender changers connect the signals straight through, so pin 2 on one side connects to pin 2 on the other side, pin 3 on one side connects to pin 3 on the other side. That's dead wrong when both sides are trying to transmit on pin 2 and trying to receive on pin 3. What's almost always needed when connecting RS232 of the same gender is a "null modem" cable which swaps pins 2 and 3.

This is really easy to see with a voltmeter, because RS232 drives a transmit signal with -5 to -12V when idle. Usually an unconnected receive pin (or a receive pin connected to another receive pin) will "float" around 0 to 0.5V. When the cables are mated, you should see both of the data signal voltages on pins 2 and 3 with your voltmeter. Understanding these voltages makes it easy to see when you have the common problem of transmit connected to transmit and receive connected to receive.

Also between the converter and Teesny, make sure you connect TX to Teensy's RX1 and RX to Teensy's TX1. The voltages won't help much on the TTL level signals side. But if you really need to check which is transmit and which is receive, measure the voltage with and without a 1K resistor to GND. Usually a transmit output will have minimal change with the 1K load, but a receive pin will usually get pulled close to 0 volts by the resistor.
 
Dear Paul,

Thank you very much....

Do you have a DC voltmeter? Can you measure the voltages on pins 2, 3 and 5 of the RS232 connector, with the meter's negative wire connected to Teensy's GND pin?

Now why O why did I not think to perform this fundamental test of the protocol......

Pin 2 --> GND = -5.74V
Pin 3 --> GND = 0 V when connected to a real RS232 which it talks to it goes to -9 V

The pH meter has 0V on pins 2 and 3 compared to the ground pin (on the pH meter) but talks when there the device connecting has -9V present on pins 2 and 3.

Do you know what voltage the MAX323 chip forces TX and RX to?

Again thanks Paul for pointing out the obvious.

Regards,
Deadsilly
 
Do you know what voltage the MAX323 chip forces TX and RX to?

Maybe you mean MAX232?

The genuine (expensive) MAX232 from Maxim and a workalike from ST that we used long ago on the 8051 dev board (before Teensy) would put out about -9V to -10V when powered by 5V.

You could expect a similar chip running from 3.3V to output about -6V.

I believe Maxim and others make similar chips with a special low power feature where it shuts down the charge pump when the receive pin isn't driven.
 
Status
Not open for further replies.
Back
Top