I bought a ~$20 RC quadcopter earlier this year. It has an onboard camera that streams live video to a smartphone app by broadcasting it’s own wireless network that you then connect to. Surprise! It sucked. But I saw that the onboard camera was it’s own module connected to the quad only by three wires. There were also clearly labeled test points for SWD and Tx/Rx signals. I decided give this thing a shot to see if I could learn what makes it tick.
First step was to connect my JTAG programmer to the exposed SWD signals and see if I can dump the camera’s firmware. Say hello to Kyle.
The chip ended up being read protected. Turns out this toy wireless camera has better security that many modern wireless routers.
Were I to RTFM I may be able to get around this, but I decided to focus on the Tx and Rx pins first. The only UART to USB device that I have an an arduino uno that I borrow the FTDI Tx/Rx pins from.
The first part of this was easy enough. Open a terminal and use Screen to watch for a signal on /dev/ttyACM0. At 115200 baud I was met with a few lines that looked like status messages during a boot process and then gibberish, so the chip is switching to a different baud rate after it boots.
This was where things got interesting, as I quickly learned that none of the ‘normal’ baud rates were being used. This is uncharted territory for me.
I started by just screwing around with my scope’s decode features that I had never used up to now. After blindly scrolling for a bit, I used the Single feature of my scope to capture some amount of data being transferred at this mysterious baud rate. Once sufficiently zoomed in I was able to measure the length of time that it took for a single bit of data to be transmitted at 1.100us. My calculator says that a 1.100us long ‘1’ correlates to 909090 baud, so I stuck 909000 into the RS-232 decoder and . . .
Voila! Scrolling through this data it turned out to be some kind of device status including things like FPS and memory available.
Getting a live feed of this data on my PC hasn’t been nearly as simple. From what I have read so far, it seems that using non-standard baud rates in linux isn’t natively supported at all. Specifying 909000 baud in something like Screen only outputs garbled characters, which made me suspect that the specified baud rate wasn’t being honored. I saw some information about baud rate aliasing that may allow me to get around it but I haven’t given that an honest go yet.
This is where I need to consult the elders. Could this be a limitation of the arduino FTDI chip? Is there some user-friendly way to force custom baud rates that isn’t as destructive feeling as aliasing? I’m using ubuntu for this project but I can spin up a VM of whatever if there is a good solution to be found elsewhere.
Is there a particular standalone USB to Serial device that that is better suited to this task? I’m always glad to have an excuse for a new tool.
Edited for spelling and brain cramps.