On Tue, May 10, 2011 at 6:43 AM, Andreas Bean <[email protected]> wrote:
> Andrey, > > I have seen that two CF cards can be put inside the cam. > With this setup, does the cam achive the max write speed of 10Mbyte/sek? > Whats the maximum supported size? > Andreas, Maximal sustained rate that the camera can record is 16MB/s, limited by ETRAX on-chip IDE controller. With the CF cards there is another issue ( described in http://www.linuxdevices.com/articles/AT5102023409.html ) - most CF cards report DMA operation, while they actually do not have it - it is caused by a bug in the controller chip made by Silicon Motion. In most applications they can safely hide that bug (falsely report DMA) because it does support UDMA, and UDMA implementation has a bug in ETRAX. When the new CF card (not yet tried and "blacklisted") is connected to the camera, camera reads the device ID information and assume tries to use it in DMA mode, and it fails. It is possible to put this make/model into blacklist (as we did with many cards) so the software will access it only in PIO mode, but that will be both slow and eat up CPU resources, influencing other applications. So far we use just Sandisk Extreme III series of CF cards that are known to support DMA mode. > > Btw, I have read the development blog. It's very interesting for me, > since we have build a panoramic camera too, as you know probably. > I tried the leveling and image stabilization a couple of month ago, > unsuccesseful. > We tried two different IMU units and several filter algorithms for the > image stabilization. None of the worked satisfactory, actually. > We are working now with Analog Devices ADIS16375 IMU, the new FPGA code (I'll release it after when finish testing) supports logging of the IMU data at high rate that IMU can provide (>2 Ksamples/sec) combined with the serial GPS data (5-10Hz), supporting optional precise GPS timing pulse (otherwise using the beginning of the NMEA sentence for time-stamping). The same FPGA module also accepts accepts/logs external input (i.e. odometer/pedometer pulses) and inter-camera synchronization (to precisely match local time with that of a master camera). All the data for these four channels is buffered and transferred to the system memory over the DMA channel without additional load on the camera CPU - with the ADIS-16375 running at the full rate (2.4Ksamoples/sec) and the record size fixed to 64 bytes/sample (other logged sources have much lower bandwidth) it is up to 160KB/sec of position/orientation raw data to be recorded - still much less than the images. We do not plan to run any image stabilization algorithms in the camera - as the data bandwidth is manageable, we will do that in the post-processing where it is easier to experiment with different filtering algorithms. But we do not have that software yet, so we'll definitely appreciate help in this area - as soon as we'll have the real data recorded, we'll post it. Andrey > > Andreas > > _______________________________________________ > Support-list mailing list > [email protected] > http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com > >
_______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
