Serial FT232 not receive 8bytes

[loginek0]

I FT232 module connected to the Raspberry Pi (with USB cable). I want to receive 8bytes (1 byte). On Windows, Terminal draws me correctly beats (eg. 00001011). In the following python script:

Code: Select all

#!/usr/bin/python

import serial
import binascii

ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=1)

while True:

str1 = ser.read(1)

if str1 == '':
    print ''
else:
    print bin(int(binascii.hexlify(str1),16))

returns only 2 bits at the end: 0b11111100 , 0b11111101 , 0b11111110 , 0b11111111

What am I doing wrong that draws me just 2bits at the end?

Below please find screen how to receive data on Windows:

And on Raspberry Pi:


I would like to get on the Raspberry Pi received data were the same.

[sprinkmeier]

This seems slight overkill:

Code: Select all

bin(int(binascii.hexlify(str1),16))

byte -> string -> number -> binary

This should work:

Code: Select all

# don't have a serial port handy, but this is a good source of bits
ser = open('/dev/urandom')
# read one byte, print its binary representation
print(bin(ord(ser.read(1))))

115,200 is reasonably fast for RS-232 serial and can have difficulty, epsecially on longer lines: http://tldp.org/HOWTO/Remote-Serial-Con ... tance.html
Can you drop the baud rate? might fix the problem

[loginek0]

Thanks for your reply. I've tried to read the data using a hex:

Code: Select all

str1.encode print("hex")

But, unfortunately, still are reimbursed a maximum of only 4 values: 'ff', 'fd', 'fc', 'fe'.
I took advantage of your way - unfortunately still the same (they are only returned values: 0b11111100, 0b11111101, 0b11111110, 0b11111111).
Adding:

Code: Select all

ser = open('/dev/urandom')

causes like suspending script and nothing works.

Changing the speed will not help, because my converter works to 115200 (and this speed runs on Windows - as seen in the screenshot attached in the first post).

[sprinkmeier]

Thanks for your reply. I've tried to read the data using a hex:

Code: Select all

str1.encode print("hex")

But, unfortunately, still are reimbursed a maximum of only 4 values: 'ff', 'fd', 'fc', 'fe'.
I took advantage of your way - unfortunately still the same (they are only returned values: 0b11111100, 0b11111101, 0b11111110, 0b11111111).
Adding:

Code: Select all

ser = open('/dev/urandom')

causes like suspending script and nothing works.

that's weird, urandom isn't supposed to block, especiually if you're just opening it.
Could you try

Code: Select all

$ hd < /dev/urandom | head

just to see what happens?

Changing the speed will not help, because my converter works to 115200 (and this speed runs on Windows - as seen in the screenshot attached in the first post).

The converter can probably work even faster, but it the cable has too much capacitance then you'll have problems.
Assuming the same hardware (cable, length, converter...) works on the windows though then baud rate shouldn't be the problem.

[loginek0]

Could you try

Code: Select all

$ hd < /dev/urandom | head

just to see what happens?

The following screen with responses:


These values are different each time after execution of this command.

The converter can probably work even faster, but it the cable has too much capacitance then you'll have problems.
Assuming the same hardware (cable, length, converter...) works on the windows though then baud rate shouldn't be the problem.

I checked the communication on ubuntu system (not on the Raspberry pi) - is working properly, as well as on windows. Unfortunately, the Raspberry Pi still are returned only four bytes.

[sprinkmeier]

Could you try

Code: Select all

$ hd < /dev/urandom | head

just to see what happens?

The following screen with responses:
These values are different each time after execution of this command.

That's expected :-)
urandom is a non-blocking source of random bytes, so if they'd been the same every time I'd have been worried :-)

Given that urandom seems to be working I'm not sure why opening it in a python program is causing the program to block.
weird...
You're not doing a 'read()' by any chance? that will read as much data as the device has available which, in the case of urandom, is approximately infinite...

The converter can probably work even faster, but it the cable has too much capacitance then you'll have problems.
Assuming the same hardware (cable, length, converter...) works on the windows though then baud rate shouldn't be the problem.

I checked the communication on ubuntu system (not on the Raspberry pi) - is working properly, as well as on windows. Unfortunately, the Raspberry Pi still are returned only four bytes.

same python code on Ubuntu works, but not on pi?
the plot thickens...

un-plug the dongle
run sudo dmesg -c to clean the kernel debug message buffer (*)
plug in the dongle
run dmesg again and post the output (text in CODE block is fine, no need for a screenshot)


(*) _NEVER_ run anything (especially with "sudo" in it) that you don't understand, unless it's from a trusted source (**)
(**) you can trust me. really!

[loginek0]

Given that urandom seems to be working I'm not sure why opening it in a python program is causing the program to block.
weird...
You're not doing a 'read()' by any chance? that will read as much data as the device has available which, in the case of urandom, is approximately infinite...

Perhaps I am in the wrong place I put this code. Please check whether current code is correct:

Code: Select all

 #!/usr/bin/python

import serial
import binascii

ser = serial.Serial('/dev/ttyUSB0', 115200, 8, 'N', 1, timeout=1)

while True:
    str1 = ser.read(1)

    if str1 == '':
        print ''
    else:
        ser = open('/dev/urandom')
        print(bin(ord(str1)))

After the code and sending the first bit - code loops and displays different values for example.

Code: Select all

0b11010001
0b101110
0b10011011
0b10001010
0b11011000
0b10100
0b1011000

Etc. although no longer send any data.

same python code on Ubuntu works, but not on pi?

At ubuntu tested in the gtkterm.

Reply from dmesg:

Code: Select all

[  357.520154] usb 1-1.3: USB disconnect, device number 6
[  357.538909] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  357.558853] ftdi_sio 1-1.3:1.0: device disconnected
[  366.976087] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
[  367.133468] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[  367.147899] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  367.163815] usb 1-1.3: Product: USB <-> Serial Cable
[  367.176050] usb 1-1.3: Manufacturer: FTDI
[  367.188540] usb 1-1.3: SerialNumber: FTYXA500
[  367.216560] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[  367.246314] usb 1-1.3: Detected FT232RL
[  367.270021] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0

[sprinkmeier]

Given that urandom seems to be working I'm not sure why opening it in a python program is causing the program to block.
weird...
You're not doing a 'read()' by any chance? that will read as much data as the device has available which, in the case of urandom, is approximately infinite...

Perhaps I am in the wrong place I put this code. Please check whether current code is correct:

Code: Select all

 #!/usr/bin/python

import serial
import binascii

ser = serial.Serial('/dev/ttyUSB0', 115200, 8, 'N', 1, timeout=1)

while True:
    str1 = ser.read(1)

    if str1 == '':
        print ''
    else:
        print(bin(ord(str1)))

I used the urandom line because I didn't have a serial port to play with.
the only thing relevant in my code snippet was the conversion/printing.
sorry about the confusion, but just take out the line altogether

After the code and sending the first bit - code loops and displays different values for example.

Code: Select all

0b11010001
0b101110
0b10011011
0b10001010
0b11011000
0b10100
0b1011000

Etc. although no longer send any data.

same python code on Ubuntu works, but not on pi?

At ubuntu tested in the gtkterm.

Reply from dmesg:

Code: Select all

[  357.520154] usb 1-1.3: USB disconnect, device number 6
[  357.538909] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  357.558853] ftdi_sio 1-1.3:1.0: device disconnected
[  366.976087] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
[  367.133468] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[  367.147899] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  367.163815] usb 1-1.3: Product: USB <-> Serial Cable
[  367.176050] usb 1-1.3: Manufacturer: FTDI
[  367.188540] usb 1-1.3: SerialNumber: FTYXA500
[  367.216560] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[  367.246314] usb 1-1.3: Detected FT232RL
[  367.270021] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0

That all looks fine to me, I was hoping for some error mesages or something to throw at $YOUR_FAVOURITE_SEARCH_ENGINE

[loginek0]

I was able to find a solution because of you! It turned out that the reason is ... that the device had been connected before starting the Raspberry Pi! If they Disconnect and reconnect only when the Raspberry Pi starts - values are returned well!
Maybe someone knows the cause of this? And how can I fix it? I do not want every time you re-connect the converter ..