The Problem
Recently, Aqara released the FP1, a 60GHz mmWave radar presence sensor. Unlike regular PIR, a mmWave sensor can detect micro-movements, like breathing, to know if someone is in the room but stationary. At the time, however, they were out of stock or not available with shipping to the US. There are two frequencies that these sensors are typically available with, 60GHz and 24GHz. There are more options available for 24GHz like this one from DFRobot and this one from seeed studio. The 60Ghz sensor I found was this one, also from Seeed Studio.
When I received the sensor, I hooked it up to my FT232 and tried reading with the settings listed in the documentation from Seeed Studio. 
The problem was that none of the data I was getting matched the structure defined in the datasheet. Either the protocol structure information or the serial baud rate was incorrect. For serial connections the baud rate can be arbitrary but both sides need to match. While not necessarily security related, UART connections are standard and identifying the pinout and settings needed to connect with them is one component of hardware security research.
The Brute Force Way
There are realistically only several commonly used rates used as listed by Wikipedia. You likely could just brute force the rate by hand. An interesting tool I came across was EXPLIoT, a security testing framework for IoT. One of the modules is a handy automated baud rate scanning tool. After following the simple wiki pages on installation and usage this is the output of running the tool against this sensor. 
Note that it didn’t positively identify what rate it was. That is due to the fact that it is looking for ASCII. This sensor isn’t sending any ASCII data, but if you are working with some sort of console this would work great. This method would work best in the majority of cases. However, if the data isn’t ASCII and you can’t tell if the data is right, one of the following methods may work better.
The Windows Driver Way
We just looked at the easiest method, but by why stop there. We can also use the sample program that Seeed Studio provided to determine the baud rate. Unfortunately, the Portmon Sysinternals tool doesn’t work on Windows 10 64bit. I identified an alternative program that would allow monitoring the serial device driver activity. The program has a free trial that worked adequately.
After starting monitoring and using the sample program to connect to the device we see the IOCTL_SERIAL_SET_BAUD_RATE request with the baud rate of 115200.
The Logic Analyzer Way
In most cases you won’t have a program like the above so another method is to use a logic analyzer to determine the baud rate. There are a wide range of logic analyzers. The most common are the Salaea which, as of this post, run from $480 to $1,400. There are also some clones of the Salaea device like this one. You can even use the clone with the Salaea Logic software or PulseView, an interface for sigrok. You will want to hook up channel 0 and 1 to rx and tx and ground to ground on the sensor. With Logic you can shift and click to create a measurement range over one of the pulses. It will show the width which should be the baud rate. From the image you can see it is close to the 115200 baud rate.
There is even an extension called Baud rate estimater. All you need to do is open the extensions window on the right side and click install.
Create the measurement window as before and it will have an additional field called fbaud. In this case it is slightly higher than the 115200 rate.
With most serial communication typically using only a handful of rates, this was all a bit excessive. It was fun figuring out the multiple ways and hopefully was insightful. It could turn out to be useful on the off chance that a device isn’t using one of the common baud rates.