I was at a client's place, trying to connect a humidity and temperature sensor to our equipment.
The sensor has a RS485 interface, and the manual says the default speed is 4800,7E1.
The pink wire is RS485-A and the grey wire is RS485-B.
I connected it to a Moxa Nport 5230-T, and configured the port settings. This is what the sensor had to say:
I had similar results when using a USB RS422/RS485 adapter on my laptop too.
The sensor emits that junk a second or so on power up. There is also more junk transmitted every 1 minute after that. It is obviously trying to tell us something.
It is likely the speed OR data bits OR parity OR stop bits OR wiring is wrong. But which one is it? Or it could be a combination of multiple things being wrong.
Trying to guess the correct values would be like looking for a needle in a hay stack. After an hour I gave up, and asked the client if I could borrow their sensor. They agreed, and I brought it home to give it a darn good thrashing troubleshoot. I planned to hook it up to my oscilloscope to see if I could figure out the settings with it. So far I've only used the oscilloscope to monitor Pulse Width Modulation (PWM) signals, so this would be an interesting experience.
First, Check Your Tools!
Before doing any work, I wanted some confidence that my USB RS422/RS485 adapter was working. I dug around the house and found a Moxa TCC-100 RS232 to RS422/485 converter which I connected to my PC serial port (/dev/ttyS0). I also plugged in the USB RS422/RS485 adapter (/dev/ttyUSB0).
I wired it up for RS422 mode first, which is 4-wire full duplex. The TCC-100 Moxa DIP switches were set ON-ON-OFF. The USB adapter had no switches to select RS422 or RS485 mode:
In two different terminals, I opened minicom, and typed stuff, and they appeared in the other terminal window:
I also tried disconnecting the GND cable, and it still worked fine. I also tried it with a laptop running off battery at one end, and my desktop at the other, and again, it was fine.
Next I switched to two wire RS485 mode (OFF-OFF-OFF on the TCC-100):
This worked too. I tried holding down a key on both terminals, and there was an occasional junk character in the stream. 2-wire RS485 is half-duplex, which means only one side can transmit at any time. I'm not sure what the auto-repeat rate on the keyboard is, but occasionally there is a collision and so junk is received.
So it looks like my USB RS422/RS485 adapter and TCC-100 are working fine.
Connecting to the Oscilloscope
First I connected the Oscilloscope to the Moxa, to get a feel of it's signals.
CH1 was connected to RX+(B)(Data+), and the probe ground connected to SGND.
CH3 was connected to RX-(A)(Data-), and the probe ground connected to SGND.
I typed an ASCII "U" which is binary 01010101 and has the most single bit transitions.
On idle, CH1/RX+(B)(DATA+) was measured at +5V, and when representing a signal, it dipped down close to 0V.
On idle, CH3/RX-(A)(DATA-) was measured at close to 0V, and when representing a signal, it jumps up to 5V.
I went into the oscilloscope's Trigger menu, and set it to trigger on a falling edge of CH1, with the trigger level set to 2.5V. I then got the oscilloscope to do a SINGLE capture:
Using the oscilloscope's horizontal cursors, I marked the width of a single bit. The BX-BY value was 8.800 usec, with a 1/[dX] of 113.6kHz. This is pretty close to the 115,200 bps I had set the serial port speed to. So it is possible to determine the bit rate in this way.
I also tested the oscilloscope's Decoder (Math -> Decode1)function. There is only one for RS232, not RS485. RS485's signals are inverted from RS232s. However, if we just analyze the negative side of the signal, it should be identical to the RS232 signal. And here it is decoding the "U" that I typed:
I now had enough confidence to start taking a look at the sensor output.
Analyzing the Sensor
I connected the oscilloscope as follows:
Interestingly, both the sensor's RS-485-B (brown) and RS-485-A (pink) idled at 0V (unlike the Moxa which kept its RX+(B)(DATA+) idling at 5V).
I set the trigger and SINGLE capture mode, and powered on the sensor. Here's the "initial message".
It should be noted that when sending a message, the sensor would raise its voltages on either line as needed. I'm not sure if the moxa or sensor is doing the right thing, but the sensor will save power when not transmitting anything.
The "high" is around 3.52V. I zoomed in on the smallest bit transition, and applied the cursor:
A single bit has a width of 832.0 us and a 1/[dX] of 1.202kHz ... so the sensor is transmitting at 1200 bps !
I applied the oscilloscope's decoder, setting the baud rate to 1200:
And there you go, we have what appears to be the start of a message, with the sensor's model number.
Reading the Sensor Data
Next I connected the sensor to the Moxa as follows:
I set the terminal program on the PC to 1200,8N1, and powered up the sensor. The oscilloscope can still see the data ...
... but the PC receives junk.
On a hunch, I reversed the pink and lines:
This inverts the bits:
And we have data!
Configuring the Sensor
Now that we have established communications, we can finally see what the sensor was set up as. For this I referred to the commands in the sensor manual.
Since the sensor was obviously transmitting data without being polled, it is probably configured with SMODE=RUN. To get out of this mode, I typed "S" followed by ENTER. This exits "RUN" mode, and the sensor is now able to receive commands again.
At this point I needed to enable "Local Echo" in my terminal program to see what I was sending to the sensor. I confirmed the sensor was in command mode by typing in "send" and it responded with a data sample.
I entered the "seri" command which outputs the serial settings, and true enough, it was set to "1200 N 8 1". also checked the "form" and "INTV" outputs.
In the end, I decided to leave it as it is, except to set "INTV 10 " to get more frequent output.
And that's that!
It was an interesting exercise as not only did I get to solve the sensor settings issue, but also learned a bit more on how to use the oscilloscope in the process.