============================================================ Subject:PTB220 problems From: John Militzer Date: Thu, 04 Dec 2003 16:29:47 -0700 To: helpdesk at vaisala.com To Whom It May Concern, I have questions regarding problems encountered with our PTB220 barometers. Problems involve two things: 1) 2 barometers stopped working in the field when input battery voltage dropped below ~12.8. I haven't been able to reproduce this failure in the lab using a power supply. Perhaps a solar charge controller which can induce some noise on the DC supply may have been a factor. In both cases the barometers were polled: 1 on 232, 1 on 485 bus. 2) Most problems involve failure / lockup while on a RS485 bus. This happens to several barometers but not all; some work continuously for weeks on end. The failing units startup and work for awhile (minutes to hours) and then stop, sometimes recovering on it's own (usually hours later). There appears to be no significant difference between running 'seri 9600 N 8 1 F', and 'seri 9600 N 8 1 H' nor apparently any difference between old boards/software and newer models (some of each experience this problem). Initial Testing: - I have run a test with 9 barometers polled, 'send x' together on the RS485. They begin ok, but eventually all stop but 1 and I cannot 'open x' or anything until power cycle. I have noticed in a few units they did recover for awhile later. I have tried different topologies with RS485 termination on either/both ends with no significant difference: the results are the same. - I wanted to run the same test on paralleled sio (with txdiode) but discovered that I could only bus 2 at a time; adding a third barometer does not work. Questions: 1) Can I get a schematic of the main board and the RS485 HMP230RSB boards? 2) On the HMP230RSB you use an LTC491IN. I notice it has a fast slew for high band data comms, whereas the MAX489 has a slow slew for applications on a poorer-quality 485 bus. I suspect the bus is less than perfect and I'm wondering if you've had troubles with the 491's? On one sensor, the edge connector of the HMP230 had been improperly soldered and actually pulled out of the PCB when removing it from the main board. I repaired that problem. 3) Can you send me the current rev. software to upload into the barometers? Is it possible that may improve the situation? Note: our boards are old and are setup with: Output format "B1 " 4.2 P1 " " 3.1 T1 " " ERR #r #n Baud Parity Data Stop Dpx 9600 N 8 1 H Configuration 1 Linear adjustments OFF Multipoint adjustments ON Measurement mode NORMAL Sending mode POLL / CLOSE Pulse mode OFF SLOW LOW 0.0 Echo OFF s/n software ncar0001 1.01 ncar0002 1.01 ncar0003 1.01 low voltage field problem s0610001 1.04 s0610002 1.04 low voltage field problem s0610003 1.04 u4110001 3.05 u4110003 3.05 u4110004 3.05 Thanks for any help or advise you can offer. Sincerely, John Militzer Note re: 112177 (help request number assigned by vaisala)... 1) I finally discovered a barometer in the lab./power supply which stopped working below about 12.4vdc: sensor #U4110001 while running in bussed/485 communications. This was true although it was the only sensor on the 485 bus and I confirmed a power cycle didn't work, and varying the vdc up/down through 12.4 did result in it working and then not working. I tried the same test with only rs232 communications and it worked down to 10.9. And then i placed it back on a bus with the other sensors, lowered the voltage to 12 and for some reason it was working again. ============================================================ Subject:Re: Vaisala PTB220 RS485 question From: John Militzer Date: Thu, 11 Dec 2003 16:54:14 -0700 To: luigi.sepe at vaisala.com CC: John Militzer Hi Luigi, Thanks for the quick reply. Re delay: Yes in the tests I've done with PC directly to PTB chain, there is delay between polling. It amounts to about 1.1 seconds. At first I simply read back the proper # of expected characters but that did indeed cause havoc. After that i setup to read for 1 sec before continuing. so that's not the problem. Re termination: Your comment is a strong possibility: lifting R3 and R6 is very good information and interesting; i don't remember seeing this in the manual and that indeed may be the big factor. It never occurred to me before to look under the HMP230 for termination there. The test bus i'm using is short, maybe 5-6'. At the end is about 18" going to a connector with termination which i made for convenience to monitor the signals on a scope. I discovered I needed to setup term. at the B&B 232/485 converter as well and that appears slightly different than the signal when terminated on our data system. The field system bus is normally 10-15m with the PTB close to the end where another device and the terminated end is. I just setup to run another test after lifting R3/R6 and the first indication, including and especially the waveform on the scope is promising. Re cr: Another good idea, no i haven't been sending a pre-CR; and i'm doing that with the test i just began. I have seen quite clearly that any collision/contenion on the bus will halt the sensors until a power cycle is performed. I'm wondering if the newest version of software includes a watchdog function? Also did you happen to see the note that i have now observed at least 1 unit to stop when input vdc was <12.5? Thanks Much, John M. luigi.sepe at vaisala.com wrote: > Hello John, > > For your questions about the schematics and software updates I've > asked for help from our R&D group. In the meantime here are a couple > of thoughts about the RS485 communications. There should a delay when > there are a number of units are connected to same line. When asking > for readings from the transmitter, there needs to be some delay to > allow the transmitter to answer before the reading is asked from the > next transmitter. > > Also the line termination should be made correctly. If there is a > device at the end of the line then dynamic line termination is not > required. Resistors R3 and R6 should be removed from all the > transmitters except the one which is at the end of the bus (and also > from that one too if the line has dynamic line termination). When the > resistors are there, it may load the line too much. It might not matter > when there's one or two units installed to line but it might when > there's e.g. ten units. > Here's one more thing which is good to pay attention to: Always send a > carriage return character in FRONT of AND at the END of every command > line (for "synchronization"). > > If you have any questions or need any additional information, please let me know. > > Thanks, > Luigi > > ---------------------------------------------------------------------------- > *Luigi Sepe* > Technical Engineer > Vaisala Inc. > 100 Commerce Way > Woburn, Mass. 01801 > USA > Phone: > Direct: 781-933-4500 Ext. 247 > Tech Support Group: 1-800-408-9456 > Fax: 781-933-8029 > mailto:luigi.sepe at vaisala.com > http://www.vaisala.com > > ============================================================ Subject:RE: Vaisala PTB220 RS485 question From: luigi.sepe Date: Wed, 17 Dec 2003 18:53:17 +0200 To: militzer Hello John, Here are the answers I received from R&D: About the 12.5 volts problem: In the PTB220 component board there are two voltage regulation IC's. One regulates the supply voltage to 9 volts and the other one regulates that 9 volts to 5 volts. The CPU-hybrid is using the 5 volts. The problem might be that one of those regulations IC's is faulty or the CPU-hybrid is faulty. In the CPU-hybrid there should be some sort of watchdog IC which is checking the input voltage and if the 5 volts goes too much below the operation level, the CPU-hybrid goes into shutdown state. About the RS485 communication problem (this is tricky one) : The sending of the PTB220 is controlled with XON/XOFF (software handshaking) and now it seems that the PTB220 does not receive the SEND command correctly. For example, if the command is SEND 1 but the barometer gets SEND 1# or there are some other mark/marks missing, then, the barometer will not answer until it reaches that mark ( it might be the ) which tells the barometer to send data out. The PTB220 receives the command but when there are extra mark/marks or missing mark/marks in the command, it can not answer. The line probably stays open and then the other units will not answer until the PTB220's get RESET (power OFF/ON). Those extra marks or missing marks usually happen when using the RS485 serial line with the 9600 baud rate and there are several units on the same line. R&D recommends using a 4800 baud rate or use the command with ASCII characters to avoid the those extra / missing marks (personally I do not know anything about ASCII codes), Here is some information about that XON/XOFF software handshaking: The method of exchanging signals for data flow control between computers and data sets is called handshaking. The most popular and most often used handshaking variant is called XON/XOFF; it's done by software, while other methods are hardware-based. Two bytes that are not mapped to normal characters in the ASCII char set are called XON (Device Code1 (DC1), Ctrl-Q, ASCII 17) and XOFF (Device Code3 (DC3), Ctrl-S, ASCII 19). Whenever, either one of the sides wants to interrupt the data flow from the other (e.g. full buffers), it sends an XOFF Transmission Off. When its buffers have been purged again, it sends an XON Transmission On to signal that data can be sent again. With some implementations, this can be any character. XON/XOFF is of course limited to text transmission. It cannot be used with binary data since binary files tend to contain every single one of the 256 characters. That's why hardware handshaking is normally used with modems, while XON/XOFF is often used with printers and plotters and terminals. I hope that this helps. Luigi -----Original Message----- From: John Militzer Sent: Tuesday, December 16, 2003 3:47 PM To: luigi.sepe Subject: Re: Vaisala PTB220 RS485 question Hi Liugi, Did you get any input from the other tech. people regarding the other questions/issues I found with our PTB220's? As I mentioned, even with disabling the 485 termination, and adding the pre-CR, the array still locks up 'overnight' requiring a power cycle. Thanks, John M. luigi.sepe wrote: > Hello John, > > For your questions about the schematics and software updates I've > asked for help from our R&D group. In the meantime here are a > couple of thoughts about the RS485 communications. There should a > delay when there are a number of units are connected to same > line. When asking for readings from the transmitter, there needs > to be some delay to allow the transmitter to answer before the > reading is asked from the next transmitter.