Shop OBEX P1 Docs P2 Docs Learn Events
RS232 19200 baud 8N1 — Parallax Forums

RS232 19200 baud 8N1

edited 2009-06-13 00:13 in Propeller 1
I am in a project in which I my Propeller needs to communicate with a data logger, which requires a specific signal.· I have attatched a spin file that I have been working on, but it needs help!· The code tries to transmit a signal generated from a potentiometer via ADC to the logger.· So far the logger does not read anything from the Propeller as the code currently is.
·
··· Below is an example generated from the manufacture of what is expected in the signal:
·
“ The data stream is standard RS232 at 19200,n,8,1. It consists of a number of short packets. Packets are sent on 10 ms ticks. Note that this does not mean that there is a packet sent every 10 ms tick – there is a pattern which repeats once a second to achieve the channel frequencies listed below, and there are some unused ticks where nothing is transmitted. Each packet consists of 5 bytes. The first byte is the channel number, the second is always A3H, the third and fourth are the channel value, high byte first. The fifth is the sum of the preceding four bytes.· EXAMPLE:
·
·· 0x01 0xA3 0x11 0x22 0x??
··· where :
· ·0x01 It the Channel Number
· ·0xA3 It is a prefixed value
·· 0x1122 It is a sensor value (16 bits) , High byte first ...
·· 0x?? It is the checksum , sum of previous 4 bytes (0x01 + 0xA3 + 0x11 + 0x22) ”
·
What is meant by "sensor value 16 bits, high byte first"?· Does that mean that for a signal of 1122 (counts), the fist two digits (11) are on to be contained in the 3rd part and the following two digits (22) in the 4th part?· How do I string the 5 parts together in packet which is 5 bytes in length every 10-ms?· What command would be best used to transmit the data?· I used 'FullDuplexSerial' in my test code.· But I really do not know if it is sending out the correct signal.· What ‘mode’ should be used?· Is ‘A3’ = 163 in HEX?· I have also included a signal to a 4-line LCD to troubleshoot.
Thanks in advance for any help in cleaning up this code!:
·
Michael

Comments

  • TimmooreTimmoore Posts: 1,031
    edited 2009-06-12 23:59
    Heres some comments
    1. The mode - depends on the data logger - whether the signals are inverted or not so can't tell
    2. 163 is A3 but $A3 is the hex way to put it

    3. LOOP at bottom on repeat is a bad idea the repeat is enough

    4. The serial protocol could be read a number of ways but my guess is binary on the wire not ascii hex of the numbers - see attached version
    5. The value is shown in hex so divide by 256 not 100

    Look the the changes I made in the attached version
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-06-13 00:13
    That looks a pretty standard sort of protocol. The hex can be confusing as there are different ways of writing hex eg 0xFF or 0FFH or $FF. They all mean 255 though, or in binary, 11111111.

    High byte first is similar to sending a decimal number 12345 and sending it in the order 1,2,3,4,5 rather than 5,4,3,2,1.

    0x1122 is hex for 1122 which is 4386 in decimal (Start/Programs/Accessories/Calculator and set calculator for Scientific. Then you can convert back and forth between hex, binary and decimal) Hex is convenient to write as you can split numbers up easily, eg 1122 is a two byte number that can range from 0 to 65535 (in decimal). If you knew the number was 4386 in decimal it would not be obvious what the bytes were. But in hex, you can say that the bytes are 0x11 and then 0x22. You can then split those up into nibbles, and then all you have to know is 0 to 15 in hex, which is 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. So the first nibble will be 1, which is 1 also in decimal and is 0001 in binary. The next nibble is also 1, so we can reconstruct the binary of that byte as 00010001.

    What you will get in practice is a byte 0 to 255 (decimal) and then another byte (0-255) decimal, and to recreate a number 0-65535 you multiply the first byte by 256 and then add it to the second byte. So you don't end up needing hex. The numbers in hex are 0x11 and 0x22 which in decimal are 17 and 34. So the number is 17*256+34 which equals 4386 above.

    Then you will have to do a checksum. It helps to get the math clear first before trying to code in spin or any other language.

    Post Edited (Dr_Acula (James Moxham)) : 6/13/2009 12:23:33 AM GMT
Sign In or Register to comment.