TTL Serial Device - 4ms pulse every 113ms when idle

JoeCreate

I have some a Fire Alarm Panel with a TTL Serial Printer output which I am interfacing to the Propeller.· I am receiving a pulse ~4ms in width every ~113ms (give or take 4ms).· This pulse causes Garbage to be received when using the FullDuplesSerial object (running at 2400, 7, E, 1).· After going through an rs232 level converter it appears as a 520us pulse and doesn't generate garbage on the rs232 output (I am·masking the 7 bits so the Data looks perfect via rs232).

Is this a common thing with TTL Serial Printer outputs maybe?· It's kinda a nice way to supervise the connection from the Printers point-of-view, and I'll think I'll use this pulse for that purpose, but I do need to filter it out to interpret the Real data properly.

Is there a quick fix·to make FullDuplexSerial ignore this pulse?· I know there is, but I'm not good at assembly yet to mess with it.

Mike Green

Is this pulse in addition to real serial data that you need back from the printer or are you completely ignoring the receive line from the printer? If you can completely ignore it, I believe you can specify a -1 for the receive pin (in FullDuplexSerial) and that will disable the receive side of things. Check the FullDuplexSerial documentation (in the source listing).

JoeCreate

I am only Receiving from the alarm panel (and not transmitting to it). When the panel is not actively sending any data, that's when I see that pulse. Otherwise it looks like regular serial data. Not sure if that pulse is mixed in while real data is being received, I expect Not since that would certainly corrupt the data. I think I need to be able to detect "no data" after a "start bit" since it appears fullduplexserial is detecting the start bit and accepting the next 9 bits. If I could determine that the next bit came 100ms or more after the start bit, then I know it's not real data.

Mike Green

There's no way to control FullDuplexSerial the way you want to do it. Since your Baud is fairly low, you could just write your own in Spin to do what you want (Spin can handle up to 19.2KBaud half-duplex). Have a look at Simple_Serial. I don't have a link to it and can't seem to attach it to this message, but you should be able to search for it. It's based on some serial routines by Chip and Phil Pilgrim.

Ariba

Perhaps you can use my SerialReceive.spin to solve your problem.
It has a 9 data-bit mode, so it should be possible to detect this 4ms pulses. (If bit 9 is High -> its a regular databyte, if Bit 9 is LOW -> its the longer pulse).
After detecting the pulse, you can wait until the end of the pulse and flush the receive buffer.

Andy

rokicki

What kind of garbage does it generate? Is it possible this is just code 127 or code 255 in serial?
I mean 4ms sounds a lot like 9 or 10 bit periods at 2400 baud, so it does sound like a real
intentional character (maybe heartbeat, as you describe). If so, can't you just filter out the
code that is received?

JoeCreate

The garbage I see is random, appears to be upper-ascii stuff (over 127, but I'll have to look closer to verify that), which I may just be able to filter out since I don't Expect to see any upper-ascii characters in this case.

FullDuplexSerial just takes 10 bits regardless of the timing so I think it sees 10 of these pulses and calls it a byte. Since the 113ms and 4ms is give-or-take a couple/few ms I can see why it doesn't produce exactly the same byte every time (I havent' studied a normal serial stream so this may not make sense).

I think I'll look at Ariba's SerialReceive.spin (Thanks) and I have the Simple_Serial.spin which I know I can modify, for some reason I wasn't thinking to use that one but that makes sense since it's only 2400 baud.