Elphel Development Blog

Working on 10373 prototype assembly

There are several hundred of these to install…

Got the BGA chips installed on the 10373 prototype

Finally I received the 10373A PCB with BGA chips soldered. Still one (DDR3 for the video memory) is missing, we’ll install it later – anyway there is a lot to be done before I’ll need it. But that’s all what is soldered for me – I could not do it by hand. Hundreds of other components are waiting for me – I attached two of the model 353 cameras as microscopes and prepared to solder 0201 resistors and capacitors (0.3mm by 0.6mm) – I’ve never done it before. It may be stupid to try to do that manually, but it did work for me before to use a soldering iron after working with just virtual stuff on the computer. I believe it helps me to find some potential problems in the design while I take components one by one and think of them in different perspective than during the initial design.

And while I was waiting for the components and the board – I made some minor design upgrades to the existent camera – changed the layout of the sensor board to fit better multi-sensor applications (like panoramic video). The new board is just 15mm by 28mm (current 10338 is 32mm x 32mm), so using M12 (S-mount) lenses it is possible to shrink the size of the panoramic head so the distance between the outer elements of the opposite lenses is under 80mm – it is much smaller than similar high-res systems. That distance is important to reduce parallax – most noticable when the objects are close to the camera.

Elphel and Stanford Frankencamera

In September 2009 there were multiple publications about the Open Source Frankencamera developed at Stanford (Open-source camera could revolutionize digital photography). It is really nice to have more participants in the rather new area of the open hardware devices, we at Elphel are also excited about the possibilities of the hardware that users can accommodate to their needs without “jail-breaking” or otherwise modifying the firmware against the manufacturers’ intentions, often having to start over again after each firmware update (or hardware release) by the manufacturer, risking to “brick” their gadgets if something goes wrong in the process.

We believe that having the software and hardware designs “free” and “open” is the only sustainable way to deal with ever-increasing complexity of the designs. Model it after the human activity that proved to be capable of dealing with complex matters – modern science that replaced proprietary and secret knowledge of alchemy and like. This is why we applaud achievements in this area that we are working hard ourselves too.

It is important to have good cooperation in such development, sharing ideas, working together on common standards and API. As of today we are still in minority, traditional (proprietary) camera manufacturers are better organized, but the standards they develop are only sub-optimal for the open hardware.

There is no reference to Elphel (or other similar works) in the article itself, it appears in the Frequently asked questions about the Frankencamera. That page among other things compares their current Stanford OMAP-based version of the camera and Elphel prototype used during development:

That is correct, we do not have the viewfinder in Elphel cameras and it is not an omission – we try to focus on the core camera parts, leaving visualization to the off-the-shelf gadgets. We believe that others can create “mashups” with appropriate devices. There are many different applications that our users can think about customize our products themselves. In the model 373 we plan to have a second low-res output from the FPGA to simplify viewfinder functionality with low-power devices that fail to render the full resolution/frame rate camera output.

As for the latency – it is really small when using the appropriate video player. The in-camera latency is less than two frames (about 20 scanlines + 1000 pixels in the FPGA – from the sensor port to the compressed bitstream in the system memory buffer and one frame in the buffer before the frame is sent out). When using the MPlayer the host PC latency is also about just one frame that makes it possible to use the camera+PC in real time applications, like a replacement of a rear view mirror in Elphel mobile office

The article says that The imaging chip is taken from a Nokia N95 cell phone but it seems not to be complete. Yes, it may be (and likely is but I do not know for sure – N95 circuit diagram is not posted) the same imaging chip, but according to this posting the sensor front end board is really open source and you can download the documentation (released under GNU FDL license) from Elphel Wiki page

Update:Andrew, thank you for adding information to Frequently asked questions about the Frankencamera .
BTW – we were able to control Canon EOS lenses directly in our model 323C ("C" for "Canon"), we may still have some hardware around. And the code is at Sourceforge – lensraw.html , lensraw.c

10373 – Assembly 3-d Render

Spent couple days looking if the 10373 board layout can be connected as I hoped. There will be small board with 2 connectors on the back panel (103732) – micro USB and eSATA. In minimal configuration it will be a passive board with connectors only, but there should be some room to add USB hub and a couple internal 10-conductor flex cables for internal USB devices – same as on the 10369 board of the NC353L camera.

SATA and USB signals are split into separate connectors on the 10373 board – that allows to leave USB connected to the back panel adapter while connecting the SATA cable (with additional power) to the internal adapter for the SATA SSD. The image below shows both options, but actually 10373 has only one SATA port so only one SATA device can be connected.

While most functionality of the 10369 board is moved to the main 10373 there is no ports for the inter-camera synchronization – 10369 has 2 sets of oto-isolated synchronization ports – “external” with modular (like telephone) connector for frame-locking several individual cameras an “internal” (with flex cable connectors) for synchronizing multiple camera boards installed in the same enclosure. The synchronization will have to be handled by an extension board that has direct connection to the 18 FPGA I/O pins. The back panel will have holes (covered with plastic overlay when not used) for up to four 2.5mm TRS connectors (like small stereo audio ones). Unfortunately even small 2.5mm TRS plugs plastic bodies are rather large so 2 of them can fit only when connectors are diagonal.. Anyway – that part of the design is not finished yet, we’ll think of something.

Andrey

10373A – new functionality added

It seems that those additional parts did fit on the board. I still need to restore some power connections and the legend on the board (it is also getting to be a real challenge – the smallest letters have to use 0.125mm (5 mil) lines and there is very little space between the components. It will need some time, but it is definitely doable. This is how the board looks now (click on the image to get the full size):

So to the 10373 features I listed initially in my May, 18 post:

• TMS320DM6467 as the CPU
• Xilinx Spartan 6 FPGA
• 256 MiB NAND flash
• 256 MiB DDR2 system memory
• 256 MiB DDR3 dedicated FPGA memory
• 48V DC over Ethernet cable
• GigE
• USB 2.0 host
• ATA port (to be used with the SATA bridge on the 10369 or similar I/O board)
• USB 1.1 device with micro USB connector. It is connected to the CPU serial port to be used as a system console and alternative boot source

Few more can be added:

• Two sensor ports, each can accommodate existent sensor front ends that work with NC353L cameras. Both sensors will be able to operate at full resolution/speed in parallel.
• SATA port with the flex cable connector. The connector pinout is made so it is possible to use flexible cables (single-layer) , not just 2-layer cable or flex PCB to achieve 100 Ohm impedance for the high-speed differential pairs. On the other end of that cable there will be either eSATA connector on the back panel of the camera or an adapter for the 64GB SSD used in some EEE PC computers. As you can see on Elphel wiki these 64GB memory can easily fit inside the camera – so no more CF cards. Same with 1.8″ HDD – we can make an adapter from the same flex cable – it addition to SATA signals it has both 3.3VDC and 5VDC power.
• Another flex cable connector has USB 2.0 (host) signals, including 5V power and additional 3.3V and 4 GPIO signals from the FPGA. It is possible to put just micro USB connector adapter on the camera back panel (it is likely to be combined with the eSATA one to simplify mounting) or have a 4-port USB hub (similar to the one in the 10369 board) and additional flex-cable connectors for internal USB or I2C internal add-ons (i.e compass).
• Clock/calendar with a super-capacitor power backup, similar to the one in our current 10369A board, but with the additional function – 10373 makes use of the alarm of that clock (it can be set up to a week in the future). Alarm output is used to re-power the camera after it turned itself off (and it can now). DC-DC converters still consume several mA when turned off, but it will be possible to use the camera with a very small solar panel in the wilderness unattended – either periodically recording images to the internal memory or using USB cellular module (if the area has coverage) to upload the images.

And here is where I’m working on this board – 110.965W 40.65168N. It is raining most of the time – day and night, so I have more time to work.

10373 – working on the PCB layout 2

After finishing the 10373 layout I did not feel satisfied – some valuable parts of the PCB were left wasted. When I was just starting this project I new I’ll have to use more layers (now 8, previous designs – 4), smaller traces (0.075 mm – down from 0.1mm) and use buried and blind vias that I never did before. And I still was not sure if everything will fit on the same board size, I even had a plan B for the system memory – use just one x16 chip and have lower bandwidth, but both chips did fit nicely (they are visible as large vertical rectangles just above the center of the board). And when I just started placement, I noticed that several hundred of  huge 0402 resistors and capacitors will not actually fit around the chip with 0.4mm distnace between the pads. Each such resitor is longer than a millimiter, so I changed most of them (few do not exist in small package) to 0201 – that was better, just 0.6mm by 0.3mm. End everything did fit and some extra remained so I’m trying to put more of the useful components.

So I broke the layout, renamed the board to rev “A” (even as rev “0” was never build) and added few more connectors, ICs and other components and now I’m working on making the increased number of parts fit (some are still around the board, not yet placed). That huge supercapaitor on top (used for clock/calendar backup instead of a battery) will be placed over other components so it does not need that much empty space.

It will take me some time to fit everything, but it seems to be possible. And then the board will be really packed with no space wasted. And camera board – get more functionality even when no extension board will be installed.
Andrey

There will be two sensor ports on the 10373 board

After finishing the PCB layout of the 10373 board I noticed that it is very easy to add a second sensor board connector.

First of all – there is room for that connector – space wasted between the two tabs with mounting holes that we added at the request of our customer. And the connector nicely fits there.

Then – the bank 0 of the Spartan 6 FPGA has enough pins for 2 sensor ports (each port uses 22 I/O lines).

The 10373 board is expected to have 3-4 times higher processing speed than 10353 so using it with the current sensor boards would keep it under-loaded. For the newer (and faster) sensors I plan to use high speed serial transceivers of the Spartan chips as I wrote earlier, but the first revision will be compatible with the older sensors.

That second connector would cost just the price of the connector as I use free so far space on the board and unused pins on the FPGA. It can be used in multiple ways, such as:

1 – stereo cameras. It will be possible to incorporate code Oleg is working on now for automatic processing of the 3-d information – i.e. for autonomous vehicles. And having higher bandwidth of the system and network it will be possible to stream or record both of the stereo channels at the full resolution/frame rate sensor is capable of – it could be used for stereo cinema applications.

2 – panoramic applications with fewer number of complete camera modules, fewer network ports than needed currently when the 353 cameras are used.

3 – Day/night cameras with both color (with IR cutoff filter) and monochrome (without filter) sensors connected at the same time.

Andrey

Now it looks like this:

10373 – working on the PCB layout

I do not know why search engines love this 8-year old page – current camera model is 393. It’s PCB layout is also available in both Gerber and PDF form on this wiki page.

---

I’m working now on the 10373 PCB layout – there will be some minor cleanup and double-checking all the new components used, their mechanical dimensions and pinouts, but so far I was able to fit all the components to the same size PCB and route all the traces. Sure I had to use more layers – there are 8 now, including 4 dedicated to ground and power planes, there are now blind laser microvias between the the outer layers and the next ones, some buried vias and reduced traces widths.

And there is even some room left on the board – something to be added later in the next revision.

Andrey

Circuit design – 10373

It seems I finished the first pass of the 10373 circuit design – “first pass” as the design is likely to change somewhat during PCB layout stage. The challenging part turned out to be power management – TI DaVinci (at least in it’s current version as TMS320DM6467) is rather power-hungry, needs significantly more of it than the Axis ETRAX FS that was used in the NC353L camera, even as it it smaller in size  – and I’m really anxious to fit more stuff on the same size PCB as in the older cameras.

Sure enough that extra electrical power gives more badly needed computational power too and I wanted to have universal system board that can use the extra power when available but be able to survive (scaling down performance) when used in mobile applications. And I believe I did balance it properly and hope to make it through the PCB layout and fit increased number of components, but four layer PCB of the 303-313-323-333-353 cameras will have to go – number of layers will go up to (most likely) eight.

It may be a tradition or superstition – I am not going to post the circuit diagram until the hardware will be built and tested.  So far I can only list some of the features of the 10373 system board:

• TMS320DM6467 as the CPU
• Xilinx Spartan 6 FPGA
• 256 MiB NAND flash
• 256 MiB DDR2 system memory
• 256 MiB DDR3 dedicated FPGA memory
• 48V DC
• GigE
• USB 2.0 host
• ATA port (to be used with the SATA bridge on the 10369 or similar  I/O board)
• USB 1.1 device with micro USB connector. It is connected to the CPU serial port to be used as a system console and alternative boot source

Sensor interface in 373

I’m considering using Xilinx high speed Serial I/O – 4 of the GTP in XC6SLX45T in CSG324 package (15mm x 15mm) to interface the sensor boards – it can be very attractive to be able to migrate to higher performance sensors from the current Aptina 5MPix ones.  It would also enable higher bandwidth to the next version of the 10359 board – up to four of 3Gb/s channels, reduce EMI and enable longer cables.

The problem is that normally you need a large chip on the other (sensor) end capable of encoding data in a way compatible with the GTP – it would be an overkill for the simple CMOS sensor module. But it seems there is a way to use a tiny (5mm x 5mm) 3 – channel (plus clock – total 4) Texas Instruments SN65LVDS301 FlatLink(tm)3G that encodes 24 bit parallel data plus 3 sync signals into serial data. Maximal “pixel” rate – 65 MHz (not enough for MT9P031) but with additional register or better CPLD (like XC2C64A in CP56 6mm x 6mm package) it would be possible to double the pixel rate and add some scrambling to reduce disparity – not that critical as the data rate per pair would be only 480Mb/s. It seems that it would be possible to make GTP to accept that slow data rate, bond 4 channels (each still has to be able to recover it’s own clock) and use SN65LVDS301’s clock as a master in this bonding with a comma mask ox 10’b1111111111 and comma pattern of 10’b1111100000.

Most likely I’ll still use smaller XC6SLX25 (w/o “T”) first and use the bank that has GTP-s in 45T to connect the 30-pin parallel flex connector (compatible with the 10353 and the existent sensor boards) first, upgrading to high speed serial I/O in the next revision/model. that will be rather simple task as it will not require major PCB redesign – FPGA is side-by-side with the sensor connector, so those traces do not intersect with other ones.