Jump to content

Keno

Members
  • Posts

    8
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Keno reacted to xwalter in WiringOP sudo su with orange pi plus 2   
    I solve this issue in this way .
    In Netbeans , right click over the project and I add a new link to this library
    /usr/lib/libwiringPi.so The files .so (shared object) are dinamic library such as the .dll in windows .
    Now Netbeans compile well . To run the project I have to run Netbeans as sudo from the terminal 
    Otherwise I get an error in runtime 
    WiringPiSetup Must be root ( Did you forget sudo ?) The WiringPiSetup() is a function to set up the board .
    I'm trying to do this ... I create a bash file 
    #! /bin/bash sudo /usr/bin/gdb $* and I link to this file in Netbeans "Debugger Command" under properties , but it doesn't run , it runs just if I am sudo ....ufffff 
    But anyway now I'm able to program my orangepi plus 2 in  C/C++ by using Netbeans .Tomorroq I will connect some led's and resistors to see if true or not 
  2. Like
    Keno reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    I know the PHP5 branch is EOL. First objective was to get it running at all. Initially it did not run at all on Armbian due to the fact that the software assumed it was running on a Raspberry Pi. I guess PHP7 will be the next challenge. Will ask the owner of Kerberos.io.... And of course do some fiddling myself...
  3. Like
    Keno reacted to tkaiser in Kerberos.io video surveillance installation on Armbian   
    Sorry, but it's exactly the other way around. Using PHP5 in 2017 is an absolute no-go: 
    http://php.net/supported-versions.php https://wiki.debian.org/PHP#Available_versions I will not reference the Ubuntu PPA where you can get horribly outdated PHP5 Better try to get this stuff running with PHP7 instead and update instructions later.
  4. Like
    Keno reacted to lanefu in [559] - GPIO Support for H2/H3 boards with a unified WiringPI library in a neat little package   
    ill have to dig through my notes to show you.... at this point im uninspired to persue wiringOP because it just has so much junk in it. I see why werecat threw a fit on the orangepi forums a while back. 
    so ill slowly start chasing the python route. someone forked pya20 specifally for the zero.... i updated the first post of this thread and added it as a resource. i did a quick test with onboard led and it seemed to work
     
    anyway i think pursuing an autodetecting pya20.gpio fork is the most straightforward path.
     
    Tapatalk thinks its important to tell you im using tapatalk from a phone.
  5. Like
    Keno reacted to RagnerBG in Kerberos.io video surveillance installation on Armbian   
    Oh, i missed that. I guess i have to try build it, instead of installing the .deb.
  6. Like
    Keno reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    Hi Ragner,
     
    Like mentioned in the 1st post: it's intended for Debian Jessie. Did not test it on Ubuntu.... A clean install is always recommended when you start with such things...
  7. Like
    Keno reacted to RagnerBG in Kerberos.io video surveillance installation on Armbian   
    Can't run kerberosio in Armbian Xenial 5.25 i installed everything from the instructions:
    kerberosio: error while loading shared libraries: libavcodec.so.56: cannot open shared object file: No such file or directory but it is there:
    libavcodec-ffmpeg.so.56 => /usr/lib/arm-linux-gnueabihf/libavcodec-ffmpeg.so.56 (0xb5e75000) I am not sure what this mean:
    ~$ sudo ldconfig -v | grep libavcodec.so /sbin/ldconfig.real: Path `/lib/arm-linux-gnueabihf' given more than once /sbin/ldconfig.real: Path `/usr/lib/arm-linux-gnueabihf' given more than once /sbin/ldconfig.real: /lib/arm-linux-gnueabihf/ld-2.23.so is the dynamic linker, ignoring libavcodec-ffmpeg.so.56 -> libavcodec.so ffmpeg is from standard repos:
    ffmpeg version 2.8.10-0ubuntu0.16.04.1 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.4.0 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 20160609 configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Maybe i have to compile it from source. I miss vdpau and libx265 for example. Or to try to install libavcodec from ubuntu-restricted-extras/libavcodec-extra?
  8. Like
    Keno reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    Hi Tom,
     
    Please hold your horses. A new version is on the way and will be released on a short notice. The author of Kerberosio has implemented some steps to see if the code runs on a Raspberry Pi. If not (when running e.g. Armbian) the libraries and Raspberry Pi Cam are skipped automatically. Compiling will even be easier: the only difference for Armbian is that the libraries for compiling OpenCV are needed. I have prepared a special Armbian page that will be put on the Kerberos.io site.
     
    Also video recording is implemented now, and a new privacy feature that blacks out areas that e.g. may not be filmed due to privacy regulations. I have the beta already up and running on Armbian.
     
    Then about your camera: it seems like you have another problem. It should show up when typing lsusb anyway, regardless if you have loaded gc2035 / vge_v4l2 or not. I have the same problem with my Orange Pi plus: I suspect the connector of my board, since I already tried 3 camera's. It worked in the past... Therefore I bought a Logitech C270: not expensive (available under 20 Euro) and works out of the box: no module loading necessary. UVC is loaded automatically. Resolution is up to 1280x960 at 5 fps.
     
    Furthermore weird that you get conflicts: did you start with a fresh install? I've compiled on 3 different boards with fresh Armbian installations yesterday evening... A working image is on it's way: as soon as it is released by the owner of Kerberos.io... But as usual: it's ready when it's done, and it is done when it's ready!
     
    However, you can try a Raspberry Pi 3 image. Instructions can be found on the website of Kerberos.io (link). This is how I started, and should run if you install libav-tools and the Raspberry Pi libraries. Note that this version does not record video yet.
  9. Like
    Keno reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    UPDATE 11-FEB-2017: Version 2.2.0 is released: now including video recording in stead of only images and also a privacy option to black out areas that may not be filmed.
    UPDATE 09-FEB-2017: Version 2.2.1 is released: memory leak(s) fixed and in some cases video stopped recording. This should be fixed now. Download via this page.
     
    Kerberos.io (link) is a relative new video surveillance program focusing mainly on the Raspberry Pi. In collaboration with the owner of the github project I managed to get it working on my Orange Pi Plus and PCDuino3 nano using Armbian (Debian Jessie) and a Logitech UVC compatible USB webcam. It consists of 2 modules: the Machinery module and Web module. The machinery module was very Raspberry Pi specific, but is now updated and can also run with very little extra effort on Armbian. The Web module runs without any modification.
     
    Follow the instructions below and you should be able to install or compile it. Kerberos.io is very fast and has a modern interface. Furthermore it is (IMHO) a very nice alternative for zoneminder and motion.It also provides a videostream on a webpage.
     
    Follow the instructions below and share your comments, ideas etc.
     
    Method 1 (easy) - Install on Armbian Debian Jessie.
    Follow the instructions on the dedicated Armbian page (link). Here you will find an Armbian precompiled .deb armhf package. Further installation / configuration options can be found on the Kerberios.io webpages.
     
    Method 2 (advanced) - Compiling the machinery and web module on Armbian Debian Jessie.
    Install the following packages: sudo apt-get install pkg-config libavcodec-dev libavformat-dev libswscale-dev
    Follow the instructions on this page (link). Further installation / configuration options can be found on the Kerberios.io webpages.
     
     
    In all cases: please note that you must alter the camera configuration: default it comes with the Raspberry Pi camera that you probably won't have!
  10. Like
    Keno reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    I think it will run on 512 mb without problems, especially if you install a non-desktop version. My OPI+ runs with desktop version of Armbian and Kerberos.io and Motion together using approx 350 MB of RAM.
     
    I still have to test if the .deb file + RPI libraries work. I guess it will, but am not sure. Compiling is quite easy and makes sure it will work.
     
    I will have a look if I can post the libraries here: they are only needed for compiling and running, but are actually not used because there is no such thing as a raspicam under Armbian. But please give me some time. I will try to have a look in the weekend.
  11. Like
    Keno reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    My orangepi camera is not working anymore: the connector is defective I think. However: to my humble knowledge the orange pi camera is functioning as an ordinary USB camera: therefore if you install the program as described (make sure you define the 'USBCamera' in the config file) and select an existing resolution of the OPI cam I guess that it should work.
  12. Like
    Keno reacted to msev in Kerberos.io video surveillance installation on Armbian   
    This is awesome! So if I copy those files for rpi-cam first i could use the .deb from the website? Which one, for Rpi3 or Rpi2?  Could you perhaps host the needed rpi camera files somewhere?
     
    What do you think hardware-vise, would a 512mb Ram H3 orange take it? Or is 1gb required?
  13. Like
    Keno got a reaction from slinde in Motioneye (OPI)   
    There have been several disjointed tutorials on making a raspberrypi or orangepi into a surveillance camera. So I threw this together to maybe help someone out there with any issues.
    I used the orangepipc+ but any orangepi board should work as long as it has the basics, internet connectivity, storage, and a camera. (I highly suggest heatsinks as well)
     
    any feedback or enhancements to this tutorial are greatly appreciated.
     
    ------------------------------------------------------------------
    ORANGEPI IPCAMERA
    ------------------------------------------------------------------
      su root   apt-get update apt-get upgrade apt-get install wget https://github.com/ccrisan/motioneye/wiki/precompiled/ffmpeg_3.1.1-1_armhf.deb dpkg -i ffmpeg_3.1.1-1_armhf.deb   apt-get remove libavcodec-extra-56 libavformat56 libavresample2 libavutil54   apt-get install python-pip python-dev curl libssl-dev libcurl4-openssl-dev libjpeg-dev libx264-142 libavcodec56 libavformat56 libmysqlclient18 libswscale3 libpq5   wget https://github.com/Motion-Project/motion/releases/download/release-4.0.1/pi_jessie_motion_4.0.1-1_armhf.deb dpkg -i pi_jessie_motion_4.0.1-1_armhf.deb   pip install motioneye mkdir -p /etc/motioneye cp /usr/local/share/motioneye/extra/motioneye.conf.sample /etc/motioneye/motioneye.conf   mkdir -p /var/lib/motioneye   cp /usr/local/share/motioneye/extra/motioneye.systemd-unit-local /etc/systemd/system/motioneye.service systemctl daemon-reload systemctl enable motioneye systemctl start motioneye   sudo modprobe gc2035 sudo modprobe vfe_v4l2   systemctl restart motioneye Accessing The Frontend
    After having successfully followed the installation instructions, the motionEye server should be running on your system and listening on port 8765. Fire up your favorite web browser and visit the following URL (replacing [your_ip] with... well, your system's IP address):
    http://[your_ip]:8765/
    Use admin with empty password when prompted for credentials. For further details on how to configure motionEye, see Configuration.
     
    ------------------------------------------------------------------
    FOR UPDATES;
    ------------------------------------------------------------------
     
    pip install motioneye --upgrade
    systemctl restart motioneye
     
     
     sudo nano /etc/motioneye/motioneye.conf
    ctrl+x then y (nano)
     
    Modifiy the motion.config file to turnoff localhost;
    stream_localhost off
     
    change the port to 80 from 8765 if desired by; 
     
    systemctl enable motion
    systemctl start motion
     
     
    Tutorial sources;
    https://github.com/ccrisan/motioneye/wiki/Install-On-Raspbian
    http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=941 
    http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1988  (some resources for motion)
    http://www.cnx-software.com/2015/09/26/how-to-use-orange-pi-camera-in-linux-with-motion/(VERY OLD)
     
    WIP tutorial, I want to add a version with facial recognition using openface and a version using ALPR (automatic license plate recognition, as the orangepi systems can have 2GB of ram)
     
    Update 1 09/30/16;
    seems there is a issue with motioneye and being unable to find the csi camera. I'm trying to find a work around, any help is appreciated.
    Update 2 11/05/2016
    Updated motioneye installation
    added information on motion and basic setup (incomplete)
    the editor seems to be breaking my wget addresses
    I forgot to add the login information and frontend... *DOH*
  14. Like
    Keno got a reaction from B.K.O. in Motioneye (OPI)   
    There have been several disjointed tutorials on making a raspberrypi or orangepi into a surveillance camera. So I threw this together to maybe help someone out there with any issues.
    I used the orangepipc+ but any orangepi board should work as long as it has the basics, internet connectivity, storage, and a camera. (I highly suggest heatsinks as well)
     
    any feedback or enhancements to this tutorial are greatly appreciated.
     
    ------------------------------------------------------------------
    ORANGEPI IPCAMERA
    ------------------------------------------------------------------
      su root   apt-get update apt-get upgrade apt-get install wget https://github.com/ccrisan/motioneye/wiki/precompiled/ffmpeg_3.1.1-1_armhf.deb dpkg -i ffmpeg_3.1.1-1_armhf.deb   apt-get remove libavcodec-extra-56 libavformat56 libavresample2 libavutil54   apt-get install python-pip python-dev curl libssl-dev libcurl4-openssl-dev libjpeg-dev libx264-142 libavcodec56 libavformat56 libmysqlclient18 libswscale3 libpq5   wget https://github.com/Motion-Project/motion/releases/download/release-4.0.1/pi_jessie_motion_4.0.1-1_armhf.deb dpkg -i pi_jessie_motion_4.0.1-1_armhf.deb   pip install motioneye mkdir -p /etc/motioneye cp /usr/local/share/motioneye/extra/motioneye.conf.sample /etc/motioneye/motioneye.conf   mkdir -p /var/lib/motioneye   cp /usr/local/share/motioneye/extra/motioneye.systemd-unit-local /etc/systemd/system/motioneye.service systemctl daemon-reload systemctl enable motioneye systemctl start motioneye   sudo modprobe gc2035 sudo modprobe vfe_v4l2   systemctl restart motioneye Accessing The Frontend
    After having successfully followed the installation instructions, the motionEye server should be running on your system and listening on port 8765. Fire up your favorite web browser and visit the following URL (replacing [your_ip] with... well, your system's IP address):
    http://[your_ip]:8765/
    Use admin with empty password when prompted for credentials. For further details on how to configure motionEye, see Configuration.
     
    ------------------------------------------------------------------
    FOR UPDATES;
    ------------------------------------------------------------------
     
    pip install motioneye --upgrade
    systemctl restart motioneye
     
     
     sudo nano /etc/motioneye/motioneye.conf
    ctrl+x then y (nano)
     
    Modifiy the motion.config file to turnoff localhost;
    stream_localhost off
     
    change the port to 80 from 8765 if desired by; 
     
    systemctl enable motion
    systemctl start motion
     
     
    Tutorial sources;
    https://github.com/ccrisan/motioneye/wiki/Install-On-Raspbian
    http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=941 
    http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1988  (some resources for motion)
    http://www.cnx-software.com/2015/09/26/how-to-use-orange-pi-camera-in-linux-with-motion/(VERY OLD)
     
    WIP tutorial, I want to add a version with facial recognition using openface and a version using ALPR (automatic license plate recognition, as the orangepi systems can have 2GB of ram)
     
    Update 1 09/30/16;
    seems there is a issue with motioneye and being unable to find the csi camera. I'm trying to find a work around, any help is appreciated.
    Update 2 11/05/2016
    Updated motioneye installation
    added information on motion and basic setup (incomplete)
    the editor seems to be breaking my wget addresses
    I forgot to add the login information and frontend... *DOH*
  15. Like
    Keno reacted to tkaiser in H3 devices as NAS   
    Me not any more
     
    The problem with A20 is that sequential SATA performance is still unbalanced (45/200 MB/s write/read under best conditions -- read as overclocked CPU and DRAM), that the same applies to Gbit Ethernet performance (here the read performance sucks so unfortunately in this direction network is the bottleneck) so that we end up here with the following situation if we're talking about NAS:
    Client --> NAS: slow SATA write performance is the bottleneck NAS --> Client: slow GbE read performance is the bottleneck With H3 single disk access over USB 2.0 is the bottleneck (accessing data on disk that is not already cached will be limited to ~32 MB/s NAS throughput with legacy kernel, write performance to the NAS depends mostly on available DRAM and buffer settings/useage of the filesharing daemon in question). By switching to mainline kernel soon we're able to get close to 38/39 MB/s when UASP capable disk enclosures are used. And if disk performance really is an issue RAID-0 could be an option. I just created one on 3.4.112 without any tuning using 2 cheap crappy external 2.5" disks that also use crappy USB-to-SATA brudges, just by executing mdadm / mkfs.ext4 without using my brain:
    iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 6529 7440 6561 6320 934 2006 102400 16 15845 16920 16380 16963 2995 8821 102400 512 29908 30385 30048 30786 23447 30493 102400 1024 55131 56964 53047 57078 36459 54178 102400 16384 62542 62603 62128 63343 62864 61185 Now we're able to write/read to/from our H3 NAS already with ~60MB/s. And when using UASP capable disk enclosures and mainline kernel RAID-0 performance will increase even more (+75 MB/s since single disk access gets close to 39MB/s).
     
    With mainline kernel we can also use btrfs and transparent filesystem compression so files that are able to be compressed 1:2 will then be read/written with 78MB/s instead of 39MB/s. Also with mainline kernel we can combine 3 USB disks in a way that sequential performance is twice the USB2 bandwidth while getting a fully redundant setup by combining RAID-0 with RAID-1 (mdraid + btrfs' own RAID implementation). This works even with disks of different size since when partitioning intelligently (using stripes of a specific size and combining striping/mirroring) you get a fully redundant disk setup showing doubled performance and 50 percent of the added capacity of all individual disks -- But that's stuff for another article I prepare for being released after the first H3 vanilla Armbian OS images
     
    I always talked about sequential transfer speeds above (since that's the most important parameter for normal NAS useage). Let's have a look at random IO: here the current situation clearly sucks with H3 compared to A20. Since with legacy kernel we can only use USB2.0 BOT mode (slower sequential transfer speeds and especially way slower when it's about random IO compared to UAS) while A20 here shows native SATA 2.0 capabilities (native command queueing and stuff like that). Therefore accessing many small files in random fashion on a SSD A20 might be ten times faster than H3 (or even more depending on the USB-to-SATA bridge used between H3 and the disk in an USB disk enclosure).
     
    Again: this might change with mainline kernel and an UASP capable disk enclosure since then also random IO over USB gets way faster. So always check which SATA bridge chip is used inside an enclosure. And BTW: That's the really great thing when we're talking about H3 for NAS useage: Since switching to mainline kernel (when UASP capable disk enclosures are in use!) increases disk access performance automagically for free (and when you use Armbian it's just a simple switch to exchange legacy kernel with vanilla).
     
    Further readings:
    http://linux-sunxi.org/Sunxi_devices_as_NAS http://linux-sunxi.org/USB/UAS http://linux-sunxi.org/SATA https://olimex.wordpress.com/2015/07/09/allwinner-did-it-again-new-quad-core-powerful-chip-pin-to-pin-compatible-with-a10-and-a20/#comments
  16. Like
    Keno reacted to tkaiser in H3 devices as NAS   
    The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM).
        I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive)   Low end   3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951   They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.   Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).   Power requirements when adding Ethernet using this dongle: Plugging in the dongle without network cable attached: +700mW Connecting network cable to USB dongle (GbE!): another +400mW GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection)   I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks):     Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination   High end   Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here).   You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less)     What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days)   Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time.   And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer.   Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.
  17. Like
    Keno reacted to rodolfo in Security Alert for Allwinner sun8i (H3/A83T/H8)   
    Censorship is ALWAYS wrong. No matter how much you disagree with someone's opinion, the right to voice an opinion is crucial in any civilized discourse. In a weak and decadent world only "nice" people are tolerated, while the dedicated and ambitious ones who actually get things done and are ready to stand up for a cause are loathed.
  18. Like
    Keno reacted to tkaiser in OV5640 camera with Orange Pi   
    Nope, another LeMakerr forum user gave me SSH access to his Banana Pi with camera connected. I got AF working after LeMaker released a fixed driver but resolution/framerates were poor.
     
    What you experienced with SinoVoip is unfortunately pretty normal. They simply don't give a shit about correct informations (maybe they still not even get the idea why such things would matter). You never know if something they write in their forums, in their gitbook 'documentation' or on Aliexpress is correct or just the usual 'copy&paste gone wrong' they're famous for.
     
    Until this is resolved I wouldn't think about ordering anything from them. Apart from that IMO A83T devices are pretty uninteresting and the M3 being the worst one (due to the many design flaws that this board shows)
     
    UPDATE: You can't believe SinoVoip a single word. See here please for another example.
  19. Like
    Keno reacted to @lex in OV5640 camera with Orange Pi   
    I have made some simple tests with OV5640 on another board (guitar), still waiting for NanoPI M1 (OPI clone) with 5MP module.
     
    I can confirm that OV5640 module (and the driver for this board) works pretty nice and you can get 5MP (2592x1944) at ~5 fps framerate  and quality is similar (a bit better i would say) to 1600x1200 (gc2035).
     
    * 1280x720 can be rendered at ~17 fps and i can say by observation i has a sharp image (good quality), and the sharpest image i can get is 1600x1200 but at low framerate (~ 4 fps), i think this can be used for taking photos with high quality, while 480x640 and 1280x720 are good candidates for video streams.
     
    * AF works with 640x480 only on my simple tests, need to check the Android source code to see which parameters are used to get AF working on HD (1280x720) since kernel is the same.
     
    * Armbian will(is) support(ting) guitar (can i say this?),
     
    If AW driver sucks we can try to improve it based on Actions code. AW OV5640 code has a lot of more window size to choose suggesting a lower quality image, i may be wrong!
    I have read the 'Sitheek' post and hope we don't need to fix any code specially the sunxi-vfe code.
     
    If the AW OV5640 driver code works as Actions driver code it will be really nice and NanoPi M1, SinoVoip M2+ (M3?) can benefit from this and we can push Steven to design a 5MP module.
  20. Like
    Keno reacted to tkaiser in OV5640 camera with Orange Pi   
    Guitar is supported but forget about M3 (SinoVoip produced a new camera module based on a different OmniVision chip for M3 and showed a strange demo video with 320x240 pixel size where you could see already artefacts). And thanks for the updates regarding OV5640 -- good to hear that it's not that bad any more
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines