0

I have posted several question regarding a similar problem, here and here but after thinking and troubleshooting over the weekend, I'd like to explore more possible cause, but lack the knowledge.

How should I check ion my current code is writing anything to the sensor I have connected via USB-RS232. Here is my code.

port = serial.Serial("/dev/ttyUSB0", baudrate=9600, timeout=20, bytesize=8, rtscts =1,dsrdtr=1)
f_w = open('/home/ryan/python_serial_output.txt','r+')
f_o = open('/home/ryan/python_serial_parse.txt','w')

port.send_break()
sys_reply = port.read(100000)
sys_reply_str = sys_reply.decode('cp437')
print(sys_reply_str)
sys_reply_str_haha = sys_reply_str.replace("\r","")
sys_reply_str_haha = sys_reply_str_haha.replace("\n","")
i = list(sys_reply_str_haha)
if str(i[-1]) == '>':
    port.reset_input_buffer()
    print("ip_b_reset")
    port.reset_output_buffer()
    print("op_b_reset")
    print(port.writable())      

    ip = 'CR1'
    ip_en = ip.encode('cp437')
    port.write(ip_en)
    read_syscheck = port.read(1000)
    read_syscheck_str = read_syscheck.decode('cp437')
    print(read_syscheck_str)

With the same decoding format I tried writing to the port and should receive back a reply 

 >CR1
 *[Parameters set to FACTORY defaults]*

Instead, I got

Sensor 2009
All rights reserved.
Firmware Version: 34.11     

>
ip_b_reset
op_b_reset
True    
CR1
7F7FD30000000030C6A87F9978B9302....

and that is why I conclude I might not be writing to the sensor.

PS: The data stream 7F7FD30000000030C6A87F9978B9302.... is always present and would appear when timed out. Hence I am unsure if this is the start of an actual reading? Or just a random readout.

Ryan Lee
  • 361
  • 1
  • 3
  • 10
  • It is EXTREMELY unlikely that your sensor is actually using utf-8 encoding for the data it returns. – jasonharper May 29 '17 at 04:38
  • @jasonharper Hi! After port.send_break, I did a read out of the console and everything came out as expected in legible text. That used the 'utf-8' encoding. Yet, just a few lines down the code, utf-8 caused problems, which is very strange. That is why I suspected the write port (or the timeouts configuration might be sending out rubbish data that would not be encoded to utf-8, triggering the error) Would you otherwise have a suggestion of a similar encoding? I'm inclined to used UTF-8 as it worked in the first instance of the readout. – Ryan Lee May 29 '17 at 04:45
  • @jasonharper I heeded your advice and am glad to say you were right! UTF is no the correct encoding method despite giving me results after sending the break. Decoding bia CP437 gives comprehensible data streams and legible input from the sensor. However, I am still not getting the response I need from the sensor after sending the CR1 command. Did I do the .write() function wrongly? – Ryan Lee May 29 '17 at 06:32
  • Are you sure that the `CR1` command doesn't need a carriage return and/or linefeed to terminate it? – jasonharper May 29 '17 at 14:39
  • @jasonharper Thanks for the tip. I have changed my input to "CR1\r\n" before encoding it to 'CP437' standard. However, I am still unable to get the reply I am expecting. – Ryan Lee May 30 '17 at 02:53

0 Answers0