Hi Everyone!

Great news! Our OpenMV Cam RT Prototypes work and we've been able to verify most of the circuits for the new system. We'll be doing one more sample production run of a small number of units with our contract manufacturer now to verify we've got everything right before we start our mass production run. These new sample units will also incorporate a bunch of low-risk changes.

Anyway! Please checkout the video below of the OpenMV Cam RT operating!

Here are some highlights of what's working that we've tested so far:

1. The USB-C connector is working great and USB is running at 480 Mb/s!
2. Battery Charging is operational! It will charge an attached battery at 100mA/s automatically while your OpenMV Cam RT has power and then keep your OpenMV Cam RT running when power is removed!
3. The Ideal Diode Circuit on the board allows you to power the camera from VIN/USB at the same time and it will automatically choose the source with the highest voltage. Best of all, it has no voltage drop power loss.
4. SDRAM is operational at 166MHz @ 16-bits.
5. QSPI Flash is operational at 133MHz @ 4-bits.
6. SD Card is operational.
7. The Camera Bus is operational at 80 MHz @ 8-bits.
8. SWD is operational for debugging! Note that the OpenMV Cam RT is our first OpenMV Cam where you can debug it using professional tools - like with a SEGGER J-Link!
9. Ethernet is operational at 100Mb/s with the new PoE Shield (which also provides power successfully)!
10. WiFi and Bluetooth* are operational.

And finally! For low power mode, we've confirmed that we are able to achieve 125uA of current draw when completely shutdown. While this is more than what we thought, we should be able to lower this drastically on Rev 2 of the design.

Rev 2 Improvements

Now, for behind the scenes. What are we improving?

1. When I designed the battery charger circuit it only chargers from USB. This was an oversight, so, we're changing around the system so you can charge an attached battery from VIN or USB.
2. In addition to this we are raising the amount of current your OpenMV Cam is allowed to draw from USB/VIN to 1.5A so you can use our new PIR Shield which has high power white/infrared LEDs without risk of browning out.
3. We used two 1mm by 1mm components on the board. While they are small and can save space... they also can be put on backwards. So, we're going to be swapping them out for larger devices since we have board space.
4. Battery Status (and even charging status along with VIN/USB power source status) will be available to the processor so you can adjust your behavior when running on a battery.
5. Regarding the low power issues, we're moving to a new 3.3V regulator for the low-power domain that draws 1uA versus 29uA. We also identified an issue with three level shifter circuits on the boards that were causing a massive amount of leakage current. So, with these changes we hope to get the low-power mode current draw to ~25uA from 125uA.
6. The LED we are using is EXTREMELY energy efficient. It's bright with only 330uA of power. On our prototypes we are giving the LEDs 15mA of power which makes them blinding!
7. A Button on the camera so you can finally easily trigger it to do something.
8. And finally, we are making both headers 2x8 so that we can future proof the board design along with breaking out an I/O pin for you to be able to recover the board if it's bricked (like the BOOT0 pin on the OpenMV Cam H7).

And of-course. There are many more changes. However, these are all small. The biggest lesson we discovered with the RT1060 was the need for a DQS pin on the SDRAM and QSPI Flash.

Basically, in-order to read data from SDRAM/FLASH at high speeds the processor has to route a read-strobe from inside the chip, to outside the chip, to back inside the chip in-order to simulate a delay such that the read of data on the data bus happens in the middle of the bit period. Most processors... do this internally without requiring you to waste an I/O pin (two in this case) by reading the data on the negative clock edge. However, the RT1060 is unique in this way.

Because of this requirement the second QSPI Flash on our prototypes is not functional. The DQS pin necessary to get the first QSPI Flash operating at high speed is located on the CS pin of the second flash. For SDRAM the DQS pin overlapped with the FSIN pin on the camera which we were able disconnect to get the SDRAM operating.

Finally, the last serious issue was that bluetooth was not given RTS/CTS pins for it's UART which make high baud rates impossible. However, conveniently, on removing the second QSPI Flash we were able to free up the necessary I/O pins for fixing bluetooth support, the new empty DQS pins, the FSIN pin having to be moved, support for status from the battery charger system, and the new user button!

Anyway, you can find the new schematic for Rev 2 of the system here!

Regarding how we are handling removing the second QSPI Flash. Well, it turns out it is not needed. We had added it so that the main program could execute in place from the first QSPI Flash and allow the second to be writable without disturbing the main program. However, it turns out that we can actually store the firmware and embedded disk drive on one flash chip without any issues.

For Folks Who Ordered the Sample Units

Given the above breaking changes that we need to do for Rev 2 we're just going to increase the number of samples we make with our contract manufacturer of the Rev 2 design and we will provide those to the few folks who wanted to test out samples. While the Rev 1 units do work it will not be possible for us to support them firmware wise.

As for a timeline on the Rev 2 board design. We hope to send it out by the beginning of next month and get it back in the beginning of July. Assuming everything works and we've got all the bugs out we'll start production and hopefully start shipping at the end of August and/or beginning of September.

In the mean-time you can pre-order the OpenMV Cam RT now! More than half of the production run has already sold out. The specs on the product page have been updated per what we expect for R2.

That's all folks!