Need a chip to modify a serial command. Where do I start?

[programmergeek]

I have a project I want to do and I am not sure what hardware I need or what I need to get started. These chips might be overkill but if someone can provide some inpur that would be great.
I need to make a black box to modify a serial string. Iam looking at string of 4 digits and the baud rate is 9600.
that outputs will be the same askey II serial string but I need to prefixthat string with a letter to be able to tell where string is comingfrom.

Example:
Input askeyII = 1234 Output askey = A1234
Input = 2345 Output = A2345

I wrote Patallax looking at the Stamp2 Microcontroller Module and they seemed to think the propeller might be betterbecause of the speed was better. I know little about these but Ithink both are overkill, I need to make several of these little boxes.

Thanks ahead of time for your input.

[Duane Degn]

The Propeller might be overkill but it would be cheaper than using a Basic Stamp.

How many serial lines does this "black box" connect with.

I do something similar in my lab. I have information coming from different equipment and a Prop reads all the data in and formats it nicely with a prefix.

This isn't very hard to do.

Is the serial connection RS-232?

Duane

[programmergeek]

Yes it is a command issued by a keypad the keypad uses a series of wires that basically get wired to a phone type plug but it is a serial connection rs232, I think it only uses 2 wire. The connection is unimportant I can figure out a couple of plugs.
This is the keypad
http://www.homeauto.com/products/consolestouchscreens/outdoorkeypad.asp

The keypad outputs an askey II string the trouble is we have no idea what keypad it comes from so I want to put a idenifer in frount of the string such as a letter. so I have a little black box behind each keypad.

Any help on what hardware to get that is the cheapest and the code would be a huge help This is my fors microcontroller.

Feel free to email me
jason@programmergeek.com

Sounds like the same thing. If

[Mike Green]

Your duplicate thread in the Stamp forum has been deleted. It's against forum rules to post duplicate threads in multiple forums.

A Propeller would be a better choice than a Stamp because the Stamp can only do one thing at a time. If it's transmitting serial data, it can't receive serial data and will ignore any sent to it. The Propeller can receive and send at the same time and, if wanted, can modify the received data before handing it over to the transmitting cog.

[Duane Degn]

Yes it is a command issued by a keypad the keypad uses a series of wires that basically get wired to a phone type plug but it is a serial connection rs232, I think it only uses 2 wire.

It was unclear from the documentation (from the site you linked to) how the information is coming from the keypad.

It looks like there is a 12V line.

A brown wire which connects with a green wire, which connects to an "Armed" location on the back of a controller box.

I don't see information (other than baud) on what the two "serial" wires are.

They could be a TTL, RS-232, RS-485 or some other protocol.

Do you have a unit that you could test with an oscilloscope to see what the voltages are on the lines?

The type of signal will determine if you'll need additional chips to allow the keypad to communicate with the Propeller.

As far as hardware goes, I'd suggest a Propeller Proto Board. A QuickStart board is also an option.

If you need to add additional components to interface with the serial connections, you'd probably be better off with the Prop Proto Board.

Do you know if the keypads transmit some sort of terminating character? Many of my devices end a transmission with ASCII 10 and 13 (new line and carriage return). This will be important when it comes time to write the software.

The Prop can handle many serial connections at once. Especially limited to a 9600 baud. 24 incoming lines could be monitored with six cogs leaving two extra to for modifying data and sending data out on a different line (one cog would probably be enough for this).

How many of these keypads do you want to monitor?

Does the serial line coming out of the device need to match the protocol of the incoming data?

Duane

[HollyMinkowski]

I'd use a Tiny88 because it's cheap and would work OK for this.
But a Prop will certainly do it also..plus you can get lots of help
here on the forum if you use a Prop.

You need to be able to see the serial data...a scope or analyzer
of some kind will help. You can do it without monitoring the data
but it's always easier to see the data stream.

The voltages of the signals are important and you may need to
convert them, there are cheap chips made just for that purpose.
MAXIM (the chip company not the magazine :-)

[Duane Degn]

Jason,

As I mentioned in a previous post, it would be good to know what kind of control characters the keypads output.

When I was testing software to combine serial lines in my lab, I had one Propeller board generating simulated output from the various instruments.

I would good to have list of possible data steams from the keypads.

For example here is the data I used.

DAT
  analyticalBalanceFakeOutput1  byte "+  123.4567  g ", 13, 10, 0
  analyticalBalanceFakeOutput2  byte "+   10.0006  g ", 13, 10, 0
  analyticalBalanceFakeOutput3  byte "+    0.0000  g ", 13, 10, 0
  largeBalanceFakeOutput1       byte "Total         ", 10, 13,{
                                    }"Net  0000.00 g", 10, 13,{
                                    }"PCS   000000  ", 10, 13, 0
  largeBalanceFakeOutput2       byte "Total         ", 10, 13,{
                                    }"Net  1234.55 g", 10, 13,{
                                    }"PCS   000000  ", 10, 13, 0
  largeBalanceFakeOutput3       byte "Total         ", 10, 13,{
                                    }"Net  0543.25 g", 10, 13,{
                                    }"PCS   000000  ", 10, 13, 0
  spectrometerFakeOutput0       byte "450NM  1999. A", 13, 10, 0
  spectrometerFakeOutput1       byte "450NM   .234 A", 13, 10, 0
  spectrometerFakeOutput2       byte "450NM  -.000 A", 13, 10, 0
  spectrometerFakeOutput3       byte "450NM   .000 A", 13, 10, 0
  spectrometerFakeOutput4       byte "420NM  1.110 A", 13, 10, 0
  spectrometerFakeOutput5       byte "450NM  -00.4 T", 13, 10, 0
  spectrometerFakeOutput6       byte "450NM  125.2 T", 13, 10, 0
  spectrometerFakeOutput7       byte "450NM   00.0 T", 13, 10, 0
  spectrometerFakeOutput8       byte "450NM  1999. C", 13, 10, 0
  spectrometerFakeOutput9       byte "450NM   0.42 C", 13, 10, 0
  spectrometerFakeOutputA       byte "450NM   2.10 F", 13, 10, 0
  barcodeFakeOutput1            byte "GB123", 13, 0
  barcodeFakeOutput2            byte "C002", 13, 0
  barcodeFakeOutput3            byte "V014", 13, 0

Alternatively the program could ignore all control characters and just use the pound sign ("#") as an end of message marker. I believe from the link you provide the pound sign is to be pressed at the end of a code entry.

Do you want the retransmitted data to have any special headers or end character(s)?

@Other forum members, Jason has offered to pay me a consulting fee for my help. He has generously agreed to have the solution discussed on the forum in hopes it will help others with similar projects. This why answers are more detailed than normal.

Duane

[Duane Degn]

Jason,

I doubt I'll have internet access for the next few days.

I thought I'd share what I've come up with so far.

MergePad is a program that combines up to seven data streams into one. A letter is added to the beginning of each data set indicating which keypad it is from. The letters are A-G. If the program sends and error message or some other message that isn't from the keypads, it uses "?" as a prefix.

The program uses the same terminating character as the documentation "#".

I've also attached PadSimulator. A program to test the MergePad program.

I haven 't tested the program as thoroughly as I'd like to. I'll do some extra testing when I have some time.

Duane

[Duane Degn]

Jason,

I've done some more testing. I think the MergePad program is working.

I added some tests to the PadSimulator program.

The first test just outputs simulated button presses on four lines, one line at a time.

Here's the Spin code.

Tbug(string(13, "Simple Test"))
  Tbug(string(13, "Four data sets from four pads."))
  waitcnt(clkfreq * 1 + cnt)
 
  repeat outputIndex from 0 to 3
    Tbug(string(13, "Output from pad"))
    TbugTx(prefixList[outputIndex])
    Tbug(string(" = "))
    localIndex := @padFakeOutput01 + (outputIndex * _KeyPressBufferSize)
    repeat
      TbugTx(byte[localIndex])' Send data to terminal window  
      Tx(outputIndex, byte[localIndex]) ' Send data to black box
    while byte[localIndex++] <> _EndOfMessagePad '"#"
    waitcnt(clkfreq * 1 + cnt) 
  Tbug(string(13, "End of ", 34, "Four data sets from four pads", 34, " Test.", 13))

The statements

    Tbug(string(13, "Output from pad"))
    TbugTx(prefixList[outputIndex])

are used to identify which serial line the data is being transmitted on. This identifier is only sent to the terminal window for debugging. It is not included in the transmission.

The array "prefixList" is located in the DAT section.

prefixList              byte "ABCDEFG", _BlackBoxMessagePrefix

The output to the terminal window from this section of code is:

Simple Test
Four data sets from four pads.
Output from padA = 1111#
Output from padB = 2222#
Output from padC = 3333#
Output from padD = 4444#
End of "Four data sets from four pads" Test.

The output from the Propeller listening to all seven serial lines is:

A1111#
B2222#
C3333#
D4444#

I added a carriage return after the end of message character (#) to make it easier to view in the terminal window.

Here's the section of code in MergePad that outputs the data (and adds a carriage return).

PUB MonitorPads | localIndex, localSize, endRxFlag, localErrorFlag, localComIndex
  repeat     
    repeat localComIndex from _PadA to _Output
      if rxFlag[localComIndex] <> oldRxFlag[localComIndex]
        localSize := FlushBuffer(localComIndex)
        if localSize > 0
          Com1.tx(_Output - _SerialPortGroupSize, prefixList[localComIndex])
          localIndex := 0
          repeat localSize
            Com1.tx(_Output - _SerialPortGroupSize, tempBuffer[localIndex++])
 
        ' Carriage return added to make terminal window easier to read.
        ' Remove once finished debugging.    
        TbugTx(13)

The above code is the heart of the MergePad program. The serial drivers watch of the end of message characters so this loop just monitors the appropriate rxFlag element to see if a new message has been received. (I personally think this is pretty cool.)

Another test performed by the PadSimulator program is simulating key-presses to all the pads at once. The key-presses of each pad are kept separate. Once an end of message character is received by the MergePad program the entire set of key-presses in displayed (with appropriate prefix).

Here's the test code.

  Tbug(string(13, "New test.  Interleave input from "))
  TbugDec(_Output)  
  Tbug(string(" pads."))
  Tbug(string(13, "All "))
  TbugDec(_Output)  
  Tbug(string(" serial lines will be used at once."))
  Tbug(string(13, "The Black Box will keep the data from each keypad separate."))
  Tbug(string(13, "All the characters received on an individual line will be transmitted"))
  Tbug(string(13, "from the Black Box after an end of message character is"))
  Tbug(string(13, "received on the individual line. "))
  characterIndex := 0
  repeat localIndex from 0 to _Output
    doneFlag[localIndex] := 0
 
  localIndex := @padFakeOutput01  
  repeat while doneFlag[_Output] < _Output
    doneFlag[_Output] := 0 ' use to count keypads that are done          
    repeat outputIndex from 0 to _PadG
      if doneFlag[outputIndex] == 0 ' if zero then this pad hasn't reached end of message character                     
        waitcnt(clkfreq / 2 + cnt) ' keep things slow enough to watch. 
        Tbug(string(13, "Output from pad"))
        TbugTx(prefixList[outputIndex])
        Tbug(string(" = ")) 
        TbugTx(byte[localIndex + (outputIndex * _KeyPressBufferSize)])' Send data to terminal window  
        Tx(outputIndex, byte[localIndex + (outputIndex * _KeyPressBufferSize)]) ' Send data to black box
        if byte[localIndex + (outputIndex * _KeyPressBufferSize)] == _EndOfMessagePad '"#"
          doneFlag[outputIndex] := 1
      else
        doneFlag[_Output]++ ' add up keypads that are done.
    localIndex++  ' increment to next character in each keypad string.   
    waitcnt(clkfreq * 2 + cnt) ' keep things slow enough to watch.
  Tbug(string(13, "End of interleave test."))
  Tbug(string(13, "Hopefull the ", 34, "Black Box", 34, " kept the individual"))
  Tbug(string(13, "keypad data separate."))

Here's what is displayed on the terminal window from the PadSimulator Prop.

New test.  Interleave input from 7 pads.
All 7 serial lines will be used at once.
The Black Box will keep the data from each keypad separate.
All the characters received on an individual line will be transmitted
from the Black Box after an end of message character is
received on the individual line.
Output from padA = 1
Output from padB = 2
Output from padC = 3
Output from padD = 4
Output from padE = 9
Output from padF = 0
Output from padG = 1
Output from padA = 1
Output from padB = 2
Output from padC = 3
Output from padD = 4
Output from padE = 9
Output from padF = 0
Output from padG = 2
Output from padA = 1
Output from padB = 2
Output from padC = 3
Output from padD = 4
Output from padE = 9
Output from padF = 0
Output from padG = 3
Output from padA = 1
Output from padB = 2
Output from padC = 3
Output from padD = 4
Output from padE = 9
Output from padF = 0
Output from padG = 4
Output from padA = #
Output from padB = #
Output from padC = #
Output from padD = #
Output from padE = #
Output from padF = #
Output from padG = 5
Output from padG = 6
Output from padG = 7
Output from padG = 8
Output from padG = 9
Output from padG = 0
Output from padG = #
End of interleave test.
Hopefull the "Black Box" kept the individual
keypad data separate.

As you can see, the PadSimulator is displaying each character as it is transmitted. It is also indicating which serial line is is using by adding the padX statement.

Here's what is displayed by the MergePad program.

A1111#
B2222#
C3333#
D4444#
E9999#
F0000#
G1234567890#

Here's the corresponding data contained in the DAT section.

padFakeOutput01         byte "1111#", 0[15] 
padFakeOutput02         byte "2222#", 0[15] 
padFakeOutput03         byte "3333#", 0[15] 
padFakeOutput04         byte "4444#", 0[15] 
padFakeOutput05         byte "9999#", 0[15] 
padFakeOutput06         byte "0000#", 0[15] 
padFakeOutput07         byte "1234567890#", 0[9]

The above test was performed at a leisurely pace so the data could be easily watched.

The same test is again performed without the delays.

The last test uses the data in the array "sequence" to determine which serial line to use.

sequence                byte "CBAGFEDBBAAEEDDFFGGCC", 0
'' sequence is a list of keypads to simulate.  The program
'' uses this list with the data below to generate simulated
'' input from keypads.
 
'' Each padFakeOutputXX array should have exactly _KeyPressBufferSize
'' members.  If the keypad data is less than _KeyPressBufferSize
'' characters long, then add zeros to pad the array so it is exactly
'' _KeyPressBufferSize characters long.
                             '          1111111111
                             '01234567890123456789
padFakeOutput00         byte "123*4567#", 0[11] 
padFakeOutput01         byte "1111#", 0[15] 
padFakeOutput02         byte "2222#", 0[15] 
padFakeOutput03         byte "3333#", 0[15] 
padFakeOutput04         byte "4444#", 0[15] 
padFakeOutput05         byte "9999#", 0[15] 
padFakeOutput06         byte "0000#", 0[15] 
padFakeOutput07         byte "1234567890#", 0[9] 
padFakeOutput08         byte "4321#", 0[15] 
                             '          1111111111
                             '01234567890123456789
padFakeOutput09         byte "987*654*3210#", 0[7]

The data in the "padFakeOutputXX" is used to generated the simulated key-presses.

I've attached the achives of both programs.

It is still important to determine the hardware you will need to interface the keypads to the Propeller.

One possible problem would be if someone entered a very long series of key-presses without using the end of message character. Each serial line has a 512 byte rx buffer. Key-presses will like be lost if the buffer is filled without an end of message character being received.

Duane