Getting different value in buffer than expected from Oscilloscope.

Should just post the data sheet link? https://www.robotshop.com/media/files/pdf2/rb-ben-03_2017-11-23-benewake-tfmini-micro-lidar-module-ip65-12-m-datasheet.pdf

and perhaps the data you see on the oscilloscope vs in memory? You know, the stuff that's material to your observation/assertion, and not on the wider internet already.

Different how? If you poll a byte at a time do you see the expected data form?

Using what STM32, board, etc?

Also the datasheet is outdated this is what i got from oscilloscopeso instead of getting 0x59 i am getting 0x9A and i am using NUCLEO-64.

Ok, so a pair of 0x59 bytes, no perceivable inter-symbol gap beyond the start/stop bits. Do you have coverage of the complete frame?

Computer receives what?

well i am not able to get full waveform so i reduced time scale

and this is what i am getting from buffer

0x59 = bit reversed 0x9a. Check your USART settings for MSB/LSB first.

You want the buffer as bytes not 16-bit words, you'd need words if you were using a 9-bit mode, but you shouldn't be here.

0x5959 is 22873

@Bob S​ standard UART serial is LSB first, don't think it is an option to do it anyway else on the STM32.

The first scope trace is START(0) 10011010 STOP(1), twice

At least on 32L4xx, there is a MSBFIRST bit in USARTx_CR2. Unless I missed it (possible), Divesh doesn't say WHICH Nucleo-64 so I don't know exactly which CPU he is using.

But I think you found the issue w/16-bit data. The sample data he posted shows 2 packets if you unwind the 16-bit data into bytes.

Hey guys i am using Nucleo-f303

Ok, table should still be an array of uint8_t not uint16_t