← Older revision Revision as of 03:04, 12 November 2015 (One intermediate revision not shown)Line 4: Line 4: 10393 is the system board of Elphel NC393 series camera. It will also replace [[10353|10353 board]] in [[Elphel_Eyesis4Pi|Eyesis4pi]] and other Elphel multi-sensor cameras. It has the same physical dimensions as 10353 and may be used as an upgrade to the previous camera modules. 10393 is the system board of Elphel NC393 series camera. It will also replace [[10353|10353 board]] in [[Elphel_Eyesis4Pi|Eyesis4pi]] and other Elphel multi-sensor cameras. It has the same physical dimensions as 10353 and may be used as an upgrade to the previous camera modules. -This camera system board is designed to simultaneously support multiple sensors - both with legacy parallel interface (it is directly compatible with [[10338|10338 Sensor board]] and [[10359|10359 Sensor multiplexer board]]) and with new high-speed serial interface (up to 8 lanes + clock per each port). Sensor ports of the 10393 can be combined to interface larger/higher speed sensors, interface supply voltage is programmable in the range of 1.35V to 2.8V. All the sensor port interface signals are routed directly to the FPGA pads (22 I/O signals on each of the 4 flex cable connectors) , so the same ports can be uses for other purposes, for example to control the motors or interface IMU of the quadcopter.+This camera system board is designed to simultaneously support multiple sensors - both with legacy parallel interface (it is directly compatible with [[10338|10338 Sensor board]] and [[10359|10359 Sensor multiplexer board]]) and with new high-speed serial interface (up to 8 lanes + clock per each port), such as [[10398 | 10398 14MPix SFE]]. Sensor ports of the 10393 can be combined to interface larger/higher speed sensors, interface supply voltage is programmable in the range of 1.35V to 2.8V. All the sensor port interface signals are routed directly to the FPGA pads (22 I/O signals on each of the 4 flex cable connectors) , so the same ports can be uses for other purposes, for example to control the motors or interface IMU of the quadcopter. Block diagram below shows major parts and I/O ports of the 10393 board. Left edge of the diagram corresponds to the sensor connections, right one - to the camera back panel with external connectors, top and bottom contain inter-board connections: Block diagram below shows major parts and I/O ports of the 10393 board. Left edge of the diagram corresponds to the sensor connections, right one - to the camera back panel with external connectors, top and bottom contain inter-board connections: Andrey.filippov

← Older revision Revision as of 03:02, 12 November 2015 (One intermediate revision not shown)Line 1: Line 1: ==10398== ==10398== -[[Image:10398.png | frame|[[Media:10398.pdf|10398 Circuit Diagram, Parts List]] <br/> [[Media:10398_gerber.tar.gz|10398 Gerber files]]]]+[[Image:10398_top.png| thumb | 374px| 10398 board, top view]]  +[[Image:10398_bottom.png| thumb | 374px| 10398 board, bottom view]]  +   +10398 board is a 14MPix sensor front end (SFE) designed to work with [[10393]] camera system board. It has the same physical dimensions and the same optical format (1/2.3") as a 5MPix SFE [[10338D]].  +   +The 14MPix (4608H x 3288V, 1.4μm x1.4 μm) image sensor used is On Semiconductor (former Aptina) [http://www.onsemi.com/pub_link/Collateral/MT9F002-D.PDF |MT9F002]. This sensor (and 10398 SFE) uses 4-lane HiSPi serial interface running at 700 Mpbs/lane and is capable of running at 13.7 fps at full resolution (12bpp mode), or 60fps at 2304x1296 (1080p + 20% EIS). Other combinations of resolution/frame rate are possible.  +   +10398 SFE uses the same 30-pin flex cable connector for control (I²C, extra GPIO), differential data output (4-lane HiSPi+clock) and 3.3V power (additional 2.8V analog and 1.8V digital are generated on board). Short connections can use general purpose flex jumpers (30 conductors, 0.5mm pitch) or Elphel flex cables manufactured for the parallel interface sensors, longer connections require controlled-impedance flex cables with 100Ω differential lines.  +   +[[Media:10398.jpeg|10398 Circuit Diagram, Parts List]] <br/> [[Media:10398_gerber.tar.gz|10398 Gerber files]] Andrey.filippov

uploaded "[[File:10398.jpeg]]"

Andrey.filippov

Created page with "==10398== 10398 Circuit Diagram, Parts List <br/> 10398 Gerber files]]"

New page

==10398==
[[Image:10398.png | frame|[[Media:10398.pdf|10398 Circuit Diagram, Parts List]] <br/> [[Media:10398_gerber.tar.gz|10398 Gerber files]]]] Andrey.filippov

uploaded "[[File:10398.png]]"

Andrey.filippov

uploaded "[[File:10398 bottom.png]]"

Andrey.filippov

uploaded a new version of "[[File:10393 bottom.jpeg]]"

Oleg

All the PCBs for the new camera: 10393, 10389 and 10385 are modified to rev “A”, we already received the new boards from the factory and now are waiting for the first production batch to be build. The PCB changes are minor, just moving connectors away from the board edge to simplify mechanical design and improve thermal contact of the heat sink plate to the camera body. Additionally the 10389A got m2 connector instead of the mSATA to accommodate modern SSD.

While waiting for the production we designed a new sensor board (10398) that has exactly the same dimensions, same image sensor format as the current 10338E and so it is compatible with the hardware for the calibrated sensor front ends we use in photogrammetric cameras. The difference is that this MT9F002 is a 14 MPix device and has high-speed serial interface instead of the legacy parallel one. We expect to get the new boards and the sensors next week and will immediately start working with this new hardware.

In preparation for the faster sensors I started to work on the FPGA code to make it ready for the new devices. We planned to use modern sensors with the serial interfaces from the very beginning of the new camera design, so the hardware accommodates up to 8 differential data lanes plus a clock pair in addition to the I²C and several control signals. One obviously required part is the support for Aptina HiSPi (High Speed Serial Pixel) interface that in case of MT9F002 uses 4 differential data lanes, each running at 660 Mbps – in 12-bit mode that corresponds to 220 MPix/s. Until we’ll get the actual sensors I could only simulate receiving of the HiSPi data using the sensor model written ourselves following the interface documentation. I’ll need yet to make sure I understood the documentation correctly and the sensor will produce output similar to what we modeled.

The sensor interface is not the only piece of the code that needed changes, I also had to increase significantly the bandwidth of the FPGA signal processing and to modify the I²C sequencer to support 2-byte register addresses.

Data that FPGA receives from the sensor passes through the several clock domains until it is stored in the system memory as a sequence of compressed JPEG/JP4 frames:

• Sensor data in each channel enters FPGA at a pixel clock rate, and subsequently passes through vignetting correction/scaling module, gamma conversion module and histogram calculation modules. This chain output is buffered before crossing to the memory clock domain.
• Multichannel DDR3 memory controller records sensor data in line-scan order and later retrieves it in overlapping (for JPEG) or non-overlapping (for JP4) square tiles.
• Data tiles retrieved from the external DDR3 memory are sent to the compressor clock domain to be processed with JPEG algorithm. In color JPEG mode compressor bandwidth has to be 1.5 higher than the pixel rate, as for 4:2:0 encoding each 16×16 pixels macroblock generate 6 of the 8×8 image blocks – 4 for Y (intensity) and 2 – for color components. In JP4 mode when the de-mosaic algorithm runs on the host computer the compressor clock rate equals the pixel rate.
• Last clock domain is 150MHz used by the AXI interface that operates in 64-bit parallel mode and transfers the compressed data to the system memory.

Two of these domains used double clock rate for some of the processing stages – histograms calculation in the pixel clock domain and Huffman encoder/bit stuffer in the compressor. In the previous NC353 camera pixel clock rate was 96MHz (192 MHz for double rate) and compressor rate was 80MHz (160MHz for double rate). The sensor/compressor clock rates difference reflects the fact that the sensor data output is not uniform (it pauses during inactive lines) and the compressor can process the frame at a steady rate.

MT9F002 image sensor has the output pixel rate of 220MPix/s with the average (over the full frame) rate of 198MPix/s. Using double rate clocks (440MHz for the sensor channel and 400MHz for the compressor) would be rather difficult on Zynq, so I needed first to eliminate such clocks in the design. It was possible to implement and test this modification with the existing sensor, and now it is done – four of the camera compressors each run at 250 MHz (even on “-1″, or “slow” speed grade silicon) making it total of 1GPix/sec. It does not need to have 4 separate sensors running simultaneously – a single high speed imager can provide data for all 4 compressors, each processing every 4-th frame as each image is processed independently.

At this time the memory controller will be a bottleneck when running all four MT9F002 sensors simultaneously as it currently provides only 1600MB/s bandwidth that may be marginally sufficient for four MT9F002 sensor channels and 4 compressor channels each requiring 200MB/s (bandwidth overhead is just a few percent). I am sure it will be possible to optimize the memory controller code to run at higher rate to match the compressors. We already identified which parts of the memory controller need to be modified to support 1.5x clock increase to the total of 2400MB/s. And as the production NC393 camera will have higher speed grade SoC there will be an extra 20% performance increase for the same code. That will provide bandwidth sufficient not just to run 4 sensors at full speed and compress the output data, but to do some other image manipulation at the same time.

Compared to the previous Elphel NC353 camera the new NC393 prototype already is tested to have 12x higher compressor bandwidth (4 channels instead of one and 250MPix/s instead of 80MPix/s), we plan to have the actual sensor with a full data processing chain results soon.

← Older revision Revision as of 19:58, 3 November 2015 Line 2: Line 2: [[Image:10338d.jpeg|frame|[[Media:10338d.jpeg|10338 board, rev D and E]]]] [[Image:10338d.jpeg|frame|[[Media:10338d.jpeg|10338 board, rev D and E]]]] [[Image:10338bd.png|frame|[[Media:10338d.pdf|10338D Circuit Diagram, PCB layout]] <br/> [[Media:10338d_gerber.tar.gz|10338 rev D Gerber files]]]] [[Image:10338bd.png|frame|[[Media:10338d.pdf|10338D Circuit Diagram, PCB layout]] <br/> [[Media:10338d_gerber.tar.gz|10338 rev D Gerber files]]]] -10338D is a modification of the earlier [[10338]] board designed to interface Aptina (before Micron) MT9P031/MT9P001 5MPix (2592x1944) sensor  to [[353|Elphel Model 353/363 Cameras]]. This board has smaller physical size (15mm x 28mm) to fit in multisensor panoramic setups.+10338D/10338E is a modification of the earlier [[10338]] board designed to interface Aptina (before Micron) MT9P031/MT9P001/MT9P006 5MPix (2592x1944) sensor  to [[353|Elphel Model 353 Cameras]]. This board has smaller physical size (15mm x 28mm) to fit in multisensor panoramic setups. Connectors: Connectors: * 30-pin flex cable connector (J1) for data and power. * 30-pin flex cable connector (J1) for data and power. Andrey.filippov

Blanked the page

← Older revision Revision as of 09:53, 29 October 2015 Line 1: Line 1: -Jeff Leach  -*leach17 at gmail.com  -  -"There can be only one!"  Saint17

Robotic customer support fails while pretending to be an outsourced human. Last week I searched with Google for Elphel and I got a wrong spelled name, wrong address and a wrong phone number.

Google search for Elphel

A week ago I tried Google Search for our company (usually I only check recent results using last week or last 3 days search) and noticed that on the first result page there is a Street View of my private residence, my home address pointing to a business with the name “El Phel, Inc”.

Yes, when we first registered Elphel in 2001 we used our home address, and even the first $30K check from Google for development of the Google Books camera came to this address, but it was never “El Phel, Inc.” Later wire transfers with payments to us for Google Books cameras as well as Street View ones were coming to a different address – 1405 W. 2200 S., Suite 205, West Valley City, Utah 84119. In 2012 we moved to the new building at 1455 W. 2200 S. as the old place was not big enough for the panoramic camera calibration.

I was not happy to see my house showing as the top result when searching for Elphel, it is both breach of my family privacy and it is making harm to Elphel business. Personally I would not consider a 14-year old company with international customer base a serious one if it is just a one-man home-based business. Sure you can get the similar Street View results for Google itself but it would not come out when you search for “Google”. Neither it would return wrongly spelled business name like “Goo & Gel, Inc.” and a phone number that belongs to a Baptist church in Lehi, Utah (update: they changed the phone number to the one of Elphel).

Google original location

Honestly there was some of our fault too, I’ve seen “El Phel” in a local Yellow Pages, but as we do not have a local business I did not pay attention to that – Google was always good at providing relevant information in the search results, extracting actual contact information from the company “Contacts” page directly.

Noticing that Google had lost its edge in providing search results (Bing and Yahoo show relevant data), I first contacted Yellow Pages and asked them to correct information as there is no “El Phel, Inc.” at my home address and that I’m not selling any X-Ray equipment there. They did it very promptly and the probable source of the Google misinformation (“probable” as Google does not provide any links to the source) was gone for good.

I waited for 24 hours hoping that Google will correct the information automatically (post on Elphel blog appears in Google search results in 10 – 19 seconds after I press “Publish” button). Nothing happened – same “El Phel, Inc.” in our house.

So I tried to contact Google. As Google did not provide source of the search result, I tried to follow recommendations to correct information on the map. And the first step was to log in with Google account, since I could not find a way how to contact Google without such account. Yes, I do have one – I used Gmail when Google was our customer, and when I later switched to other provider (I prefer to use only one service per company, and I selected to use Google Search) I did not delete the Gmail account. I found my password and was able to log in.

First I tried to select “Place doesn’t exist” (There is no such company as “El Phel, Inc.” with invalid phone number, and there is no business at my home address).

Auto confirmation came immediately:
From: Google Maps <noreply-maps-issues@google.com>
Date: Wed, Sep 23, 2015 at 9:55 AM
Subject: Thanks for the edit to El Phel Inc
To: еlphеl@gmаil.cоm
Maps
Thank you
Your edit is being reviewed. Thanks for sharing your knowledge of El Phel Inc.
El Phel Inc
3200 Elmer St, Magna, UT, United States
Your edit
Place doesn't exist
Edited on Sep 23, 2015 · In review
Keep exploring,
The Google Maps team
© 2015 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
You've received this confirmation email to update you about your editing activities on Google Maps.

But nothing happened. Two days later I tried with different option (there was no place to provide text entry)
Your edit
Place is private

No results either.

Then I tried to follow the other link after the inappropriate search result – “Are you the business owner?” (I’m not at owner of the non-existing business, but I am an owner of my house). And yes, I had to use my Gmail account again. There were several options how I prefer to be contacted – I selected “by phone”, and shortly after a female-voiced robot called. I do not have a habit of talking to robots, so I did not listen what it said waiting for keywords like: “press 0 to talk to a representative” or “Please stay on the line…”, but it never said anything like this and immediately hang up.

Second time I selected email contact, but it seems to me that the email conversation was with some kind of Google Eliza. This was the first email:

From : local-help@google.com
To : andrey@elphel.com
Subject : RE: [7-2344000008781] Google Local Help
Date : Thu, 24 Sep 2015 22:48:47 -0700
Add Label
Hi,
Greetings from Google.
After investigating, i found that here is an existing page on Google (El Phel Inc-3200 S Elmer St Magna, UT 84044) which according to your email is incorrect information.
Apologies for the inconvenience andrey, however as i can see that you have created a page for El Phel Inc, hence i would first request you to delete the Business page if you aren't running any Business. Also you can report a problem for incorrect information on Maps,Here is an article that would provide you further clarity on how to report a problem or fix the map.
In case you have any questions feel free to reply back on the same email address and i would get back to you.
Regards,
Rohit
Google My Business Support.

This robot tried to mimic a kids language (without capitalizing “I” and the first letter of my name), and the level of understanding the matter was below that of a human (it was Google, not me who created that page, I just wanted it to be removed).

I replied as I thought it still might be a human, just tired and overwhelmed by so many privacy-related requests they receive (the email came well after hours in United States).

From : andrey <andrey@elphel.com>
To : local-help@google.com
Subject : RE: [7-2344000008781] Google Local Help
Date : Fri, 25 Sep 2015 00:16:21 -0700
Hello Rohit,
I never created such page. I just tried different ways to contact Google to remove this embarrassing link. I did click on "Are you the business owner" (I am the owner of this residence at 3200 S Elmer St Magna, UT 84044) as I hoped that when I'll get the confirmation postcard I'll be able to reply that there is no business at this residential address).
I did try link "how to report a problem or fix the map", but I could not find a relevant method to remove a search result that does not reference external page as a source, and assigns my home residence to the search results of the company, that has a different (than listed) name, is located in a different city (West Valley City, 84119, not in Magna, 84044), and has a different phone number.
So please, can you remove that incorrect information?
Andrey Filippov

Nothing happened either, then on Sunday night (local time) came another email from “Rohit”:

From : local-help@google.com
To : andrey@elphel.com
Subject : RE: [7-2344000008781] Google Local Help
Date : Sun, 27 Sep 2015 18:11:44 -0700
Hi,
Greetings from Google.
I am working on your Business pages and would let you know once get any update.
Please reply back on the same email address in case of any concerns.
Regards,
Rohit
Google My Business Support

You may notice that it had the same ticket number, so the sender had all the previous information when replying. For any human capable of using just Google Search it would be not more than 15-30 seconds to find out that their information is incorrect and either remove it completely (as I asked) or replace with some relevant one.

And there is another detail that troubles me. Looking at the time/days when the “Google My Business Support” emails came, and the name “Rohit” it may look like it came from India. While testing a non-human communications Google might hope that correspondents would more likely attribute some inconsistencies in the generated emails to the cultural differences and miss actual software flaws. Does Google count on us being somewhat racists?

Following provided links I was not able to get any response from a human representative, only two robots (phone and email) contacted me. I hope that this post will work better and help to cure this breach of my family privacy and end harm this invalid information provided by a so respected Internet search company causes to the business. I realize that robots will take over more and more of our activities (and we are helping that to happen ourselves), but maybe this process sometimes goes too fast?

← Older revision Revision as of 02:16, 26 September 2015 (9 intermediate revisions not shown)Line 1: Line 1: -More info to be added, starting with [[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]]+[[Image:10393_top_sm.png|frame|[[Media:10393_top.jpeg|10393 board, top view]]]]  +[[Image:10393_bottom_sm.png|frame|[[Media:10393_bottom.jpeg|10393 board, bottom view]]]]  +[[Image:10393_bd.png|frame|[[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]]&nbsp;&nbsp;&nbsp;&nbsp; [[Media:10393_gerber.tar.gz|10353 Gerber files]]]]  +10393 is the system board of Elphel NC393 series camera. It will also replace [[10353|10353 board]] in [[Elphel_Eyesis4Pi|Eyesis4pi]] and other Elphel multi-sensor cameras. It has the same physical dimensions as 10353 and may be used as an upgrade to the previous camera modules.  +   +This camera system board is designed to simultaneously support multiple sensors - both with legacy parallel interface (it is directly compatible with [[10338|10338 Sensor board]] and [[10359|10359 Sensor multiplexer board]]) and with new high-speed serial interface (up to 8 lanes + clock per each port). Sensor ports of the 10393 can be combined to interface larger/higher speed sensors, interface supply voltage is programmable in the range of 1.35V to 2.8V. All the sensor port interface signals are routed directly to the FPGA pads (22 I/O signals on each of the 4 flex cable connectors) , so the same ports can be uses for other purposes, for example to control the motors or interface IMU of the quadcopter.  +   +Block diagram below shows major parts and I/O ports of the 10393 board. Left edge of the diagram corresponds to the sensor connections, right one - to the camera back panel with external connectors, top and bottom contain inter-board connections:  +* The system is built around Xilinx Zynq 7030 SoC that combines a dual-core ARM processor, a rich set of the standard peripherals and FPGA on the same chip. This combination provides high bandwidth connection between the processors and the FPGA fabric.  +* 4 identical sensor ports are 30-conductor 0.5mm pitch flex cable connectors, compatible with the earlier Elphel products. These connectors are split into two pairs, so they are closest to one short edge of the board - two on each side. Combined with an external multiplexer boards (at the expense of proportionally lower frame rate) each 10393 can work with up to 16 sensors (12 with the existing [[10359|10359 board]]).  +* 500MB of the dedicated DDR3 memory chip is connected directly to the FPGA portion of the SoC, with the 16-channel image-optimized controller it provides efficient access to the memory for simultaneous image acquisition, compression and image processing. We plan to implement such functionality as real-time image de-warping and correlation of images from multiple sensors for the 3d data extraction.  +* 1GB of DDR3 memory (2 chips providing 32-bit data bus) is uses as a system RAM for the processor subsystem.  +* 500MB of NAND flash provide program storage.  +* Persistent program storage is expandable with the micro-SD cards (not easy to see on the photo as the slot is hidden under the network connector). This interface provides bootable memory, so it is always possible to restore the camera functionality even if the system NAND will be accidentally flashed with corrupted image.  +* Largest visible component on the board is the RJ45 connector for the Gigabit Ethernet, containing all the required magnetics (transformers) that are compatible with the PoE application. The peculiar shape of the board near connector is designed that it can be used with the hardware of the sealed RJ45 connectors.  +* On the other side of the PCB under the RJ45 connector is the micro-USB connector type B (device) that can be used to implement a system console for camera software development. Additionally the USB-to-serial converter in on the 10393 board has GPIO functionality, it makes it possible to remotely reset/reboot the camera as well to as select the boot source (on the board NAND flash or external memory card). It also allows to build a fail-safe autonomous system with a camera reset-over-USB generated by a different master.  +* 10353 uses 3.3VDC as a primary power source. All other voltages required by the SoC and other subsystems are generated from this primary 3.3 by the "Secondary power module" that includes fixed and adjustable by the software (over i2c bus) voltages, some voltages (such as sensor power) can be programmatically turned on or off. Primary 3.3VDC are provided by a separate [[10385|10385 power supply board]] that can be shut down by the software and awaken by an alarm signal from the clock/calendar.  +* Clock/calendar uses a super-capacitor (large black cylinder on the bottom view photo) to provide power when the camera is turned off. This allows camera to be used to record time-lapse images during extended periods with only a battery, possibly combined with a small solar panel.  +* Extension port uses a high-density 40-pin connector to interface a [[10389|10389 Extension board]]. It provides USB (host) signals, SATA channel, system i2c and GPIO signals from the FPGA. Extension board provides:  +** SSD mass storage in m.2 SATA form-factor (up to 2260 - 22mm x 60mm).  +** USB host (micro-A) external connector.  +** eSATA/USB combo connector that can be used to connect USB flash drives, external HDD/SDD (powered externally or by USB 5.0V power) and host computer for high-speed data transfer (SATA3.0 - 6GHz)form the internal SSD storage.  +** Inter-camera external synchronization connector (2.5mm audio type).  +** Inter-camera module synchronization with a 4-conductor flex cables.  +** Two of the 10-conductor flex cable ports that carry 3.3VDC, 5.0VDC, USB, i2c and GPIO, compatible with existing [[103695|103695 IMU adapter]] and [[103696|103696 GPS adapter]] boards. Andrey.filippov

← Older revision Revision as of 01:41, 26 September 2015 (3 intermediate revisions not shown)Line 1: Line 1: -More info to be added, starting with [[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]]+[[Image:10393_top_sm.png|frame|[[Media:10393_top.jpeg|10393 board, top view]]]]  +[[Image:10393_bottom_sm.png|frame|[[Media:10393_bottom.jpeg|10393 board, bottom view]]]]  +[[Image:10393_bd.png|frame|[[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]]&nbsp;&nbsp;&nbsp;&nbsp; [[Media:10393_gerber.tar.gz|10353 Gerber files]]]]  +10393 is the system board of Elphel NC393 series camera. It will also replace [[10353|10353 board]] in [[Elphel_Eyesis4Pi|Eyesis4pi] and other Elphel multi-sensor cameras. It has the same physical dimensions as 10353 and may be used as an upgrade to the previous camera modules.  +   +This camera system board is designed to simultaneously support multiple sensors - both with legacy parallel interface (it is directly compatible with [[10338|10338 Sensor board]] and [[10359|10359 Sensor multiplexer board]]) and with new high-speed serial interface (up to 8 lanes + clock per each port). Sensor ports of the 10393 can be combined to interface larger/higher speed sensors, interface supply voltage is programmable in the range of 1.35V to 2.8V. All the sensor port interface signals are routed directly to the FPGA pads (22 I/O signals on each of the 4 flex cable connectors) , so the same ports can be uses for other purposes, for example to control the motors or interface IMU of the quadcopter.  +   +Block diagram below shows major parts and I/O ports of the 10393 board. Left edge of the diagram corresponds to the sensor connections, right one - to the camera back panel with external connectors, top and bottom contain inter-board connections:  +* The system is built around Xilinx Zync SoC that combines a dual-core ARM processor, a rich set of the standard peripherals and FPGA on the same chip. This combination provides high bandwidth connection between the processors and the FPGA fabric.  +* 4 identical sensor ports are 30-conductor 0.5mm pitch flex cable connectors, compatible with the earlier Elphel products. These connectors are split into two pairs, so they are closest to one short edge of the board - two on each side. Combined with an external multiplexer boards (at the expense of proportionally lower frame rate) each 10393 can work with up to 16 sensors (12 with the existing [[10359|10359 board]]).  +* 500MB of the dedicated DDR3 memory chip is connected directly to the FPGA portion of the SoC, with the 16-channel image-optimized controller it provides efficient access to the memory for simultaneous image acquisition, compression and image processing. We plan to implement such functionality as real-time image de-warping and correlation of images from multiple sensors for the 3d data extraction.  +* 1GB of DDR3 memory (2 chips providing 32-bit data bus) is uses as a system RAM for the Processor subsystem.  +* 500MB of NAND flash provide program storage.  +* Persistent program storage is expandable with the micro-SD cards (not easy to see on the photo as the slot is hidden under the network connector). This interface provides bootable memory, so it is always possible to restore the camera functionality even if the system NAND will be accidentally flashed with corrupted image.  +* Largest visible component on the board is the RJ45 connector for the Gigabit Ethernet, containing all the required magnetics (transformers) that are compatible with the PoE application. The peculiar shape of the board near connector is designed that it can be used with the hardware of the sealed RJ45 connectors.  +* On the other side of the PCB under the RJ45 connector is the micro-USB connector type B (device) that can be used to implement a system console for camera software development. Additionally the USB-to-serial converter in on the 10393 board has GPIO functionality, it makes it possible to remotely reset/reboot the camera as well to as select the boot source (on the board NAND flash or external memory card). It also allows to build a fail-safe autonomous system with a camera reset-over-USB generated by a different master. Andrey.filippov

← Older revision Revision as of 00:14, 26 September 2015 Line 1: Line 1: -More info to be added, starting with [[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]]+[[Image:10393_top_sm.png|frame|[[Media:10393_top.jpeg|10393 board, top view]]]]  +[[Image:10393_bottom_sm.png|frame|[[Media:10393_bottom.jpeg|10393 board, bottom view]]]]  +[[Image:10393_bd.png|frame|[[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]]&nbsp;&nbsp;&nbsp;&nbsp; [[Media:10393_gerber.tar.gz|10353 Gerber files]]]] Andrey.filippov

uploaded "[[File:10393 gerber.tar.gz]]"

Andrey.filippov

uploaded "[[File:10393 bottom sm.png]]"

Andrey.filippov

Setup:

← Older revision Revision as of 02:40, 25 September 2015 (4 intermediate revisions not shown)Line 25: Line 25: * '''uramdisk.image.gz''' - applications * '''uramdisk.image.gz''' - applications Copy them on the micro SD card > run '''boot''' once in the u-boot command line. Copy them on the micro SD card > run '''boot''' once in the u-boot command line.  +  +  +==<font color="blue">Boot options</font>==  +a. Unpack the root file system image to RAM at boot time.  +  +Check u-boot config file.  +  +Keep '''uramdisk.image.gz''' along with other files on FAT partition.  +  +b. Keep the root file system on EXT2(EXT3,etc.) partition of SD card.  +  +Create '''uEnv.txt''' on FAT partition. ''uEnv.txt'':  + uenv_boot=fatload mmc 0 0x3F00000 ${kernel_image} && fatload mmc 0 0x3E00000 ${devicetree_image} && bootm 0x3F00000 - 0x3E00000  + uenvcmd=run uenv_boot  +  +Devicetree needs to be recompiled with changes in ''bootargs''-line:  +  +for ext2:  + root=/dev/mmcblk0p2  +for ram:  + root=/dev/ram ==<font color="blue">Setup</font>== ==<font color="blue">Setup</font>== Line 34: Line 55:   cd poky; git checkout 50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b   cd poky; git checkout 50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b         -  git clone -b dora https://github.com/openembedded/meta-oe.git meta-oe+  git clone -b dora https://github.com/openembedded/meta-oe.git meta-oe    + #'''has changed to git clone -b fido https://github.com/openembedded/meta-openembedded?!!!!!!!!''')   cd meta-oe; git checkout ee173678383683e972c7d4d6f0ef5790bfa50274; cd ..   cd meta-oe; git checkout ee173678383683e972c7d4d6f0ef5790bfa50274; cd ..         Line 138: Line 160: ====Notes==== ====Notes==== <font size='2'> <font size='2'>  +* Select root file system format in the recipe:  + IMAGE_FSTYPES = "tar.gz" * Current packages: * Current packages: -  ''elphel393.bb'':+  ''core-image-elphel393.bb'':   IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"   IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}" * Also works: * Also works: -  ''elphel393.bb'':+  ''core-image-elphel393.bb'':   IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"   IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"   IMAGE_INSTALL_append = "python-core"   IMAGE_INSTALL_append = "python-core" Line 334: Line 358:   Regards,   Regards,   Nathan   Nathan  +  +==<font color="blue">Some links</font>==  +* http://picozed.org/content/microzed-how-boot-sd-card  +* http://zedboard.org/content/cannot-use-sd-card-partition-root-filesystem  +* http://architechboards-microzed.readthedocs.org/en/latest/quick.html  +* http://architechboards-microzed.readthedocs.org/en/latest/board.html  +  +1. u-boot environment variables:  +print all:  + ~: printenv  +  +setenv examples:  + ~: setenv modeboot "run uenvboot"  + ~: setenv uenvboot "fatload mmc 0 0x3000000 uEnv.txt && env import -t 0x3000000 $filesize && run uenv_boot"  +  +2. Unpack image into SD card ext2 partition:  +  +sudo tar -xzf core-image-minimal-dev-microzed.tar.gz -C /media/rootfs/ Oleg

10393 with 4 image sensors

Finally all the parts of the NC393 prototype are tested and we now can make the circuit diagram, parts list and PCB layout of this board public. About the half of the board components were tested immediately when the prototype was built – it was almost two years ago – those tests did not require any FPGA code, just the initial software that was mostly already available from the distributions for the other boards based on the same Xilinx Zynq SoC. The only missing parts were the GPL-licensed initial bootloader and a few device drivers.

Implementation of the 16-channel DDR3 memory controller

Getting to the next part – testing of the FPGA-controlled DDR3 memory took us longer: the overall concept and the physical layer were implemented in June 2014, timing calibration software and application modules for image image recording and retrieval were implemented in the spring of 2015.

Initial image acquisition and compression

When the memory was proved operational what remained untested on the board were the sensor connections and the high speed serial links for SATA. I decided not to make any temporary modules just to check the sensor physical connections but to port the complete functionality of the image acquisition, processing and compression of the existing NC353 camera (just at a higher clock rate and multiple channels instead of a single one) and then test the physical operation together with all the code.

Sensor acquisition channels: From the sensor interface to the video memory buffer

The image acquisition code was ported (or re-written) in June, 2015. This code includes:

• Sensor physical interface – currently for the existing 10338 12-bit parallel sensor front ends, with provisions for the up to 8-lanes + clock high speed serial sensors to be added. It is also planned to bond together multiple sensor channels to interface single large/high speed sensor
• Data and clock synchronization, flexible phase adjustment to recover image data and frame format for different camera configurations, including sensor multiplexers such as the 10359 board
• Correction of the lens vignetting and fine-step scaling of the pixel values, individual for each of the multiplexed sensors and color channel
• Programmable gamma-conversion of the image data
• Writing image data to the DDR3 image buffer memory using one or several frame buffers per channel, both 8bpp and 16bpp (raw image data, bypassing gamma-conversion) formats are supported
• Calculation of the histograms, individual for each color component and multiplexed sensor
• Histograms multiplexer and AXI interface to automatically transfer histogram data to the system memory
• I²c sequencer controls image sensors over i²c interface by applying software-provided register changes when the designated frame starts, commands can be scheduled up to 14 frames in advance
• Command frame sequencer (one per each sensor channel) schedules and applies system register writes (such as to control compressors) synchronously to the sensors frames, commands can be scheduled up to 14 frames in advance

JPEG/JP4 compression functionality

Image compressors get the input data from the external video buffer memory organized as 16×16 pixel macroblocks, in the case of color JPEG images larger overlapping tiles of 18×18 (or 20×20) pixels are needed to interpolate “missing” colors from the input Bayer mosaic input. As all the data goes through the buffer there is no strict requirement to have the same number of compressor and image acquisition modules, but the initial implementation uses 1:1 ratio and there are 4 identical compressor modules instantiated in the design. The compressor output data is multiplexed between the channels and then transferred to the system memory using 1 or 2 of Xilinx Zynq AXI HP interfaces.

This portion of the code is also based on the earlier design used in the existing NC353 camera (some modules are reusing code from as early as 2002), the new part of the code was dealing with a flexible memory access, older cameras firmware used hard-wired 20×20 pixel tiles format. Current code contains four identical compressor channels providing JPEG/JP4 compression of the data stored in the dedicated DDR3 video buffer memory and then transferring result to the system memory circular buffers over one or two of the Xilinx Zynq four AXI HP channels. Other camera applications that use sensor data for realtime processing rather than transferring all the image data to the host may reduce number of the compressors. It is also possible to use multiple compressors to work on a single high resolution/high frame rate sensor data stream.

Single compressor channel contains:

• Macroblock buffer interface requests 32×18 or 32×16 pixel tiles from the memory and provides 18×18 overlapping macroblocks for JPEG or 16×16 non-overlapping macroblocks for JP4 using 4KB memory buffer. This buffer eliminates the need to re-read horizontally overlapping pixels when processing consecutive macroblocks
• Pixel buffer interface retrieves data from the memory buffer providing sequential pixel stream of 18×18 (16×16) each macroblock
• Color conversion module selects one of the sub-modules : csconvert18a, csconvert_mono, csconvert_jp4 or csconvertjp4_diff to convert possibly overlapping Bayer mosaic tiles to a sequence of 8×8 blocks for 2-d DCT transform
• Average value extractor calculates average value in each 8×8 block, subtracts it before DCT and restores after – that reduces data width in DCT processing module
• xdct393 performs 2-d DCT for each 8×8 pixel block
• Quantizer re-orders each block DCT components from the scan-line to zigzag sequence and quantizes them using software-calculated and loaded tables. This is the only lossy stage of the JPEG algorithm, when the compression quality is set to 100% all the coefficients are set to 1 and the conversion is lossless
• Focus sharpness module accumulates amount of high-frequency components to estimate image sharpness over specified window to facilitate (auto) focusing. It also allows to replace on-the-fly average block value of the image with amount of the high frequency components in the same blog, providing visual indication of the focus sharpness
• RLL encoder converts the continuous 64 samples/per block data stream in to RLL-encoded data bursts
• Huffman encoder uses software-generated tables to provide additional lossless compression of the RLL-encoded data. This module (together with the next one) runs and double pixel clock rate and has an input FIFO between the clock domains
• Bit stuffer consolidates variable length codes coming out from the Huffman encoder into fixed-width words, escaping each 0xff byte (these bytes have special meaning in JPEG stream) by inserting 0×00 right after it. It additionally provides image timestamp and length in bytes after the end of the compressed data before padding the data to multiple of 32-byte chunks, this metadata has fixed offset before the 32-byte aligned data end
• Compressor output FIFO converts 16-bit wide data from the bit stuffer module received at a double compressor clock rate (currently 200MHz) and provides 64-bit wide output at the maximal clock rate (150MHz) for AXI HP port of Xilinx Zynq, it also provides buffering when several compressor channels share the same AXI HP channel

Another module – 4:1 compressor multiplexer is shared between multiple compressor channels. It is possible (defined by Verilog parameters) to use either single multiplexer with one AXI HP port (SAXIHP1) and 4 compressor inputs (4:1), or two of these modules interfacing two AXI HP channels (SAXIHP1 and SAXIHP2), reducing number of concurrent inputs of each multiplexer to just 2 (2 × 2:1). Multiplexers use fair arbitration policy and consolidate AXI bursts to full 16×64bits when possible. Status registers provide image data pointers for last write and last frame start, each as sent to AXI and after confirmation using AXI write response channel.

Porting remaining FPGA functionality to the new camera

Additional modules where ported to complete the existing NC353 functionality:

• Camera real time clock that provides current time with 1 microsecond resolution to various modules. It has accumulator-based correction circuitry to compensate for crystal oscillator frequency variations
• Inter-camera synchronization module generates and/or receives synchronization signals between multiple camera modules or other devices. When used between the cameras, each synchronization pulse has a timestamp information attached in a serialized form, so multiple synchronized cameras have all the simultaneous images metadata contain the same time code generated by the “master” camera
• Event logger records data from multiple sources, such as GPS, IMU, image acquisition events and external signal channel (like a vehicle wheel rotation sensor)

Simulating the full codebase

All that code was written (either new or modified from the existing NC353 FPGA project by the end of July, 2015 and then the most fun began. First I used the proven NC353 code to simulate (using Icarus Verilog + GtkWave) with the same input data as the one provided to the new x393 code, following the signal chains and making sure that each checkpoint data matched. That was especially useful when debugging JPEG compressor, as the intermediate data is difficult to follow. When I was developing the first JPEG compressor in 2002 I had to save output data from the various processing stages and compare it to the software compression output of the same image data from the similar stages. Having working implementation helped a lot and in 3 weeks I was able to match the output from all the processing stages described above except the event logger that I did not verify yet.

Testing the hardware

Then it was the time for translating the Verilog test fixture code to the Python programs running on the target hardware extending the code developed earlier for the memory controller. The code is able to parse Verilog parameter definition files – that simplified synchronization of the Verilog and Python code. It would be nice to use something like Cocotb in the future and completely get rid of the Verilog to Python manual translation.

As I am designing code for the reconfigurable FPGA (not for ASIC) my usual strategy is not to get high simulation coverage, but to simulate to a “barely working” stage, then use the actual hardware (that runs tens of millions times faster than the simulator), detect the problems and then try to achieve the same condition with the simulation. But when I just started to run the hardware I realized that there is too little I can get about the current state of the hardware. Remembering about the mess of the temporary debug code I had in the previous projects and the inability of the synthesis tool to directly access the qualified names of the signals inside sub-modules, I implemented rather simple debug infrastructure that uses a single register ring (like a simplified JTAG) through all the modules to debug and a matching Python code that allows access to individual bit fields of the ring. Design includes a single debug_master and debug_slave modules in each of the design module instances that needs debugging (and the modules above – up to the top one). By the time the camera was able to generate correct images the total debug ring consisted of almost a hundred of the 32-bit registers, when I later disabled this debug functionality by commenting out a single `define DEBUB_RING macro it recovered almost 5% of the device slices. The program output looks like:
x393 +0.001s--> print_debug 0x38 0x3e
038.00: compressors393_i.jp_channel0_i.debug_fifo_in [32] = 0x6e280 (451200)
039.00: compressors393_i.jp_channel0_i.debug_fifo_out [28] = 0x1b8a0 (112800)
039.1c: compressors393_i.jp_channel0_i.dbg_block_mem_ra [ 3] = 0x3 (3)
039.1f: compressors393_i.jp_channel0_i.dbg_comp_lastinmbo [ 1] = 0x1 (1)
03a.00: compressors393_i.jp_channel0_i.pages_requested [16] = 0x26c2 (9922)
03a.10: compressors393_i.jp_channel0_i.pages_got [16] = 0x26c2 (9922)
03b.00: compressors393_i.jp_channel0_i.pre_start_cntr [16] = 0x4c92 (19602)
03b.10: compressors393_i.jp_channel0_i.pre_end_cntr [16] = 0x4c92 (19602)
03c.00: compressors393_i.jp_channel0_i.page_requests [16] = 0x4c92 (19602)
03c.10: compressors393_i.jp_channel0_i.pages_needed [16] = 0x26c2 (9922)
03d.00: compressors393_i.jp_channel0_i.dbg_stb_cntr [16] = 0xcb6c (52076)
03d.10: compressors393_i.jp_channel0_i.dbg_zds_cntr [16] = 0xcb6c (52076)
03e.00: compressors393_i.jp_channel0_i.dbg_block_mem_wa [ 3] = 0x4 (4)
03e.03: compressors393_i.jp_channel0_i.dbg_block_mem_wa_save [ 3] = 0x0 (0)

Acquiring the first images

All the problems I encountered while trying to make hardware work turned out to be reproducible (but no always easy) with the simulation and the next 3 weeks I was eliminating then one by one. When I’ve got to the 51-st version of the FPGA bitstream file (there were several more when I forgot to increment version number) camera started to produce consistently valid JPEG files.

First 4-sensor image acquired with NC393 camera

At that point I replaced a single sensor front end with no lens attached (just half of the input sensor window was covered with a tape to produce a blurry shadow in the images) with four complete SFE with lenses simultaneously using a piece of Eyesis4π hardware to point the individual sensors at the 45° angles (in portrait mode) covering 180°×60° FOV combined – it resulted in the images shown above. Sensor color gains are not calibrated (so there is visible color mismatch) and the images are not stitched together (just placed side-by-side) but i consider it to be a significant milestone in the NC393 camera development.

SATA controller status

Almost at the same time Alexey who is working on SATA controller for the camera achieved an important milestone too. His code running in Xilinx Zynq was able to negotiate and establish link with an mSATA SSD connected to the NC393 prototype. There is still a fair amount of design work ahead until we’ll be able to use this controller with the camera, but at least the hardware operation of this part of the design is verified now too.

What is next

Having all the hardware on the 10393 verified we are now able to implement minor improvements and corrections to the 3 existing boards of the NC393 camera:

• 10393 itself
• 10389 – extension board with mSATA SSD, eSATA/USB combo connector, micro-USB and synchronization I/O
• 10385 – power supply board

And then make the first batch of the new cameras that will be available for other developers and customers.
We also plane to make a new sensor board with On Semiconductor (former Aptina, former Micron) MT9F002 – 14MPix sensor with the same 1/2.3″ image format as the MT9F006 used with the current NC353 cameras. This 12-bit sensor will allow us to try multi-lane high speed serial interface keeping the same physical dimension of the sensor board and use the same lenses as we use now.

Changed link to current repository at GitHub

← Older revision Revision as of 05:35, 17 September 2015 Line 1: Line 1: ==Decription== ==Decription== -[https://sourceforge.net/p/elphel/ezynq Ezynq] project is started to create a bootloader for systems based on the Xilinx Zynq SoC without the inconvenience of the non-free tools and/or files. The goal is not just to "free" the code, but to provide users with the higher degree of flexibility in fine-tuning of the configuration parameters.+[https://github.com/Elphel/ezynq Ezynq] project is started to create a bootloader for systems based on the Xilinx Zynq SoC without the inconvenience of the non-free tools and/or files. The goal is not just to "free" the code, but to provide users with the higher degree of flexibility in fine-tuning of the configuration parameters. ====="Free" the code part===== ====="Free" the code part===== Line 6: Line 6: * FSBL is under Xilinx's copyright * FSBL is under Xilinx's copyright * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license. * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license. -  ==Supported boards== ==Supported boards== Andrey.filippov

Created page with "More info to be added, starting with 10393 Circuit Diagram, Parts List, PCB layout"

New page

More info to be added, starting with [[Media:10393.pdf|10393 Circuit Diagram, Parts List, PCB layout]] Andrey.filippov