Keithely 2000 RS232 Framing Error

[NNNI]

I recently acquired a Keithely 2000 DMM (manufactured around 1997/1998) and wanted to try my hand at data logging. The GPIB port is out of reach for me, since I can't find the right connector locally and buying one is out of question because of the expense. I was sent an RS232 to USB converter cable, which I want to use.
The first test I did was connecting up the cable to my laptop running Windows 11. I used the Arduino serial monitor to connect up to the right COM port and send commands. I was able to successfully talk to the meter and send commands like :volt:dc:meas? and get readings back from the meter. I was also able to get readings from a Python script written to acquire data.
Now to do actual data logging, I didn't want to use the laptop since they have a tendency to randomly go into sleep mode and interrupt communication, and, of course, nothing needs to be said about Windows itself. I have a Raspberry Pi 4B running Raspbian which I decided to use. I connected the K2000 to one of the USB ports using the same cable I used with the laptop. I ran the same python script (only the COM port name was changed), but the meter gave me a +800 error - RS232 framing error detected. I installed the Arduino software on the Pi as well and tried to talk to the meter using the serial monitor the same way I had done on Windows, but no luck. I scoped the waveforms on the meter's RS232 level shifter IC output (to the meter), and noticed that on Rasbpian, there is an extra low bit added after each byte. I assumed this was the problem.
I hooked up a Pi Pico to act as a bridge (https://github.com/Noltari/pico-uart-bridge), and this time the waveforms looked satisfactory, but the meter still gave me the +800 error.
I've been trying to talk to this thing using the Pi 4B for days now, and I have run out of solutions . Would greatly appreciate help or advice.
Thanks, NNNI
P.S. Picture attached is of a scope waveform, white reference waveform is Raspbian, yellow is from Windows. :\n is invalid to the meter, but I transmitted only two bytes so it's easier to debug the timings.
P.P.S The meter's donor also tried the same thing with his K2000, and he gets the same error so at least it's reproducible.

[voltsandjolts]

If you want a logging program that is ready to use, try this.

[voltsandjolts]

I posted a simple python example here, it might help you.

[gamalot]

Have you checked the serial port settings? Such as parity bit and stop bits.

[Doctorandus_P]

Start by zooming in on the single bit width timing.
RS232 needs a fairly accurate timing. If the timing is more then 5% off then you already get communication errors (but a Keithley having faulty RS232 timing seems unlikely).

I do not now how accurate the timing of the raspi is.
In the past I've seen PCI cards for RS232 which had timing that was upto 3 percent off for regular baudrates, and that eats up almost all the error margin you have.

If your scope is any good it can also show you the start and stop bits in the decoding. If your scope does not do that, then get yourself an EUR10 Logic analyzer (Saleaeaea clone) and use it with Sigrok / Pulseview. I have both a Rigol scope (Older DS1052E) and a few of those EUR10 LA's, but I much prefer the LA for working with microcontrollers. It's a small unobtrusive box that fits somewhere on top of your project, and the bigger resolution of the PC monitor is also an advantage for working with an LA. You also have 8 channels so you can monitor both I2C, UART, and SPI in a project at the same time. Normally I only use the oscilloscope to check signal integrity (such as bus loading for I2C) and use Sigrok / Pulseview for the rest. With Pulseview you also have over 100 different decoders, much more then the handful of your scope. And it's an open source project and all 100 decoders are free.

[m k]

What is the direction of time?

You are sending 3A 0A but longest steady state is last.
It's more like 0A 3A from right to left.

[dietert1]

Baudrate is equal, but the white error transmission has two extra bits. Most likely unwanted parity bits (equal for 3A and 0A). Need to configure RS232 on the RPI as 8N1.

Regards, Dieter

[NNNI]

Thanks everyone for your suggestions. I've checked and double checked parameters and timings and they seem to be perfect.
The donor of the meter suggested trying to invert the TX and RX lines using an inverter for the Pi Pico bridge. That fix sounds promising, because I seem to have overlooked the fact that the level shifter (ADUM202) has inverting inputs and outputs. I'll try this and post an update.
Thanks,
NNNI

[NNNI]

So adding a 40106 inverter to and from the RX and TX lines on the pi pico bridge worked, can now talk to the meter just fine 

[tooki]

My guess is that the converter isn’t actually RS-232, but just UART. Real RS-232 uses -12V signaling, not +5V or +3.3V. I have a fake RS-232 adapter I got from eBay that looks correct (DB-9 port and everything) but lacks the level shifter, so doesn’t work properly on actual RS-232 devices.