0

I am attempting to use a USB to RS232 converter cable to read the signal coming out of a BioPhotometer and be able to automatically receive the results of readings from the machine rather than need to enter them from the display. As far as I can tell it is not designed to be used in this way, the port is meant for a printer. The device has the option "Printer" to be set as either "Serial" or "DPU-414". I have plugged the device into USB and read the output of both of these settings with the sample samples using

(stty raw; cat > [format]_format.log) </dev/ttyUSB0

The two outputs are here and here.

I've found a manual for the printer, and there is a table in there that refers to IBM characters, which I believe is the CP 437 character set. So I tried to read the file in python using:

with open('serial_format.log', 'r', encoding='cp437') as file:
    file_lines = [line for line in file]

I then noticed that reading every other character gives a sensible output for some lines:

for line in file_lines:
    print(line[1::2])

enter image description here

As can be seen, at 15:42 I made a blank measurement on the device, and then at 15:43 I made a measurement, which was sample #006 for the device, and this read 0.246A.

One of the difficulties is that I'm not sure what the output should look like, but the only information that I need is the time, sample number, and absorbance reading.

What are all the other characters? Is this an issue with the way that I'm reading the signal or with the way I'm decoding the file? Am I better off working with the "Serial" or "DPU-414" option.

EDIT:

Thanks to the help of Señor CMasMas I went back and had a look at the settings for the serial reading in the terminal. I realised that if I used screen /dev/ttyUSB0 9600 the output came through correctly. I have provided a hex dump here. Let me know if another format is more useful.

In addition, when I simply ran cat /dev/ttyUSB0 after this it continued to function. By using stty -F /dev/ttyUSB0 before and after running screen I am able to compare what settings have changed:

Before:

speed 9600 baud; line = 0;
-brkint -imaxbel

After:

speed 9600 baud; line = 0;
min = 100; time = 2;
-icrnl -imaxbel
-opost -onlcr
-isig -icanon -echo

Looking through the man page for stty, as I understand it a '-' in front of the option means that this option is not being used, so:

  • brkint -breaks cause an interrupt signal.
    • This is no longer there so that means breaks now cause an interrupt signal
  • icrnl -translate carriage return to newline
    • So carriage returns are no longer translated
  • opost -postprocess output
    • So output is no longer being postprocessed
  • onlcr -translate newline to carriage return-newline
    • So this is no longer happening
  • isig -enable interrupt, quit, and suspend special characters
    • These are no longer having an effect
  • icanon -enable special characters: erase, kill, werase, rprnt
    • So the special characters are no longer enabled
  • echo -echo input characters
    • So input characters are no longer being displayed

It seems strange to me that not having these options improves the output. Can anyone shed any light?

Noah Sprent
  • 133
  • 5
  • 1
    After reading the control language for the printer, and since you have no I/O specs on the BioPhotometer.. I myself would be focused on the DPU-414 at least initially. Neither of the files you posted look like serial IO to a mostly ASCII printer to me and that is what you should mostly see (along with esc seqs). Are you sure that that the baud rate and control flow are set correctly both on the meter and on the usb/serial adapter? Look [here](https://neurophysics.ucsd.edu/courses/physics_173_273/BioPhotometer_eppendorf_Manual_English.pdf) for control flow settings. – Señor CMasMas Aug 18 '21 at 17:58
  • Why not treat it as bytes instead of a string type and check what the actual data content looks like with [bytes.hex()](https://docs.python.org/3/library/stdtypes.html#bytes.hex) etc.? The amount of information will not increase even if you view the data that could not be converted to printable characters of CP437 as characters/strings. – kunif Aug 19 '21 at 01:51
  • Your `EDIT:` neglects to mention for which mode, "Serial" or "DPU-414", the instrument is configured. *"Let me know if another format is more useful"* -- That would be plain ASCII text. *"Can anyone shed any light?"* -- Looks like **screen** is simply using a "raw" (aka non-canonical or not "cooked") mode, which is typical for terminal emulation programs, see https://stackoverflow.com/questions/56757505/how-to-read-from-serial-port-like-picocom-on-linux/56765890#56765890 – sawdust Aug 23 '21 at 05:32
  • *"I realised that if I used `screen /dev/ttyUSB0 9600` the output came through correctly."* -- See https://stackoverflow.com/questions/45795607/serial-port-doesnt-work-properly-after-reboot-unless-i-execute-minicom – sawdust Aug 23 '21 at 05:50

0 Answers0