@lex

$ 15.00 ?
That's a good price for what the board offers, mini HDMI, CSI port, 512 MB and Wifi&Bluetooth. Personally i would add a 8 GB eMMC and try to keep the price below $ 20.00. Once you boot from eMMC you will never want to boot from SD card again.
BTW, Have you considered Banana Pi M2M? no HDMI but there is a MIPI DSI port to connect LCD panel, and i can say the 5" LCD is the best LCD i have tested so far, unfortunately i have damaged the LCD some how while porting it to M64. They are short on supply another sample but Nora Lee is kindly sending me another one when they are ready so i can finish all the tests, i have not tested it to the exhaustion nor did any extensive testing but there is no problem with heat and Wifi&BT works as expected and the board has been a nice surprise.
 
I have no idea about the price and availability.
 
 
 

The panel driver seems to be  rda_panel_ili9806g_mcu.c .
It's not up to date with the latest Android,  maybe just the Timings...

This is for the GC2035 (OrangePi camera) sensor, you need OV5640 configuration, please read @lordofduct answer in this thread.

I was curious to see how Mainline kernel performs on GbE test against a Legacy kernel.
 
For the Armbian side i chose the nightly dev Armbian_5.27.170602_Orangepiwin_Ubuntu_xenial_dev_4.11.1_desktop.img  (Desktop) and for the Legacy i chose my own build with all  "Bells and whistles" (full Desktop, hdmi, camera, bt and wifi).
I did not optimized Armbian Mainline, just installed and run stock. For the Legacy i optimized as usual. If there is some optimization to do on Mainline side, i missed.
 
I have some observations about the board and results:
* Board is without Heat-sink,
* Legacy subsequent test got lower values, i suspect it runs hotter than Mainline, maybe due to HDMI, camera and BT enabled, drops about 30~50 MBits/sec,
* After Mainline installation, the next boot came without HDMI output, so i had to guess which IP was assigned without looking at router (OK, we know it is a development Image),
* Board act as a Server (iperf3 -s) and my ultra fast Duo core Intel box as a client.
* Both Image are build with gcc 6.3
 
Armbian Mainline kernel 4.11.1 results:
 
Legacy kernel 3.10.105 results:
 

running sudo while you are root is redundant, sudo (superuser do) is intended for normal users to run some commands as root to fix DNS issue add this to the file /etc/hosts 127.0.0.1 localhost 127.0.1.1 bpi-iot-ros-ai # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters for the eMMC i think there is a tool they call  bpi-copy as they state:  "support bpi-copy to write SD/eMMC with img.zip file" but as @martinayotte  already told your "dd" worked and you copied to eMMC.
 

Read: https://community.teamviewer.com/t5/Knowledge-Base/How-do-I-install-TeamViewer-on-my-Linux-distribution/ta-p/4351#toc-hId-850221972
 
You need ARM64 not armhf deb packages if there is one.
 
* i have not found teamviewer arm64, maybe you need to install some 32 bit support.

not sure i would work but try and cross your finger:
  sudo dpkg --add-architecture armhf sudo apt-get update sync sudo apt-get install libc6:armhf sync sudo reboot * update: you may need some other lib, just use package:armf when install * Update2: you may need also this: sudo apt-get install libstdc++6:armhf if some other 32 lib is required to run teamviewer, try: file teamviewer (the binary) to find more about.
   
 

Waiting for the IPX RF cable to arrive and see how it will boost the signal, 12dBi Omni wifi antenna, $6.75 (now $7.50) on AliExpress. Will try to reproduce same test and post here.
 
 

The results for nanoPi A64 - RTL8189es, 1 meter away,  just the monitor between board and the wireless router/modem. tested against my ultra dual core pentium:
*Update: no ehternet tune script this time!
 
iwconfig:
From the board:
 
The other direction:
 

NanoPi A64 has RealTek 8189ETV so i have ported it to 3.10.104 to see how it would performs on the A64 arena.
For the same distance, same antenna, no walls between i got the values below:
 
bpi-m64 AP6212 with BT enabled:  ~14 Mbits/sec nanopi a64 with RTL8189es:  ~16 Mbits/sec  
Unfortunately i don't have Wifi on my Pin64+ to compare with, but i realized it is very hard to get the same values (average values)  in different time of the day, for instance you get lower values during night.
 
RTL8189ETV seems to have better signal strength and better performance ( ~ 15% faster ) however i have had a hard time to authenticate with some of my wifi router.
 

Thanks @lex,
 
I currently only have headphones attached direct to my DAC (not even through a headphone amplifier) as the system is hooked up to a testbed at work
Thank you for the very interesting article!  I had rad a little about the problems of DSD, but haven't seen them presented in such an easily read way before.
 
My project, which started as an attempt to replace my ageing squeezebox touch, is turning (with the help of my colleague) into a potentially commercial venture. I say potentially, because we still have a lot of work to do and a lot of problems to solve, before we have a working prototype. For the moment, I just have pine screen on a stand, with basic touch-like functionality, running only slightly modified squeezelite/jivelite. The plan is to develop a new control interface and to make sure that we are passing through /or processing the original stream as authentically as possible.  That is the main reason for the interest in DSD, as format conversion is generally considered a bad thing, yet another conversion to PCM is best avoided.  The other reason is that if we ever plan to become commercial, we need to support as many DAC input technologies as possible, as some DACs only support native DSD, while some support DoP.
 
Some pics and very basic/poor video uploaded to my Google drive at  
https://drive.google.com/drive/folders/0B1XH4Yuu5-Nyc2luSEJzTTBmNEU
 
It doesn't give any impression of sound quality, but will show that the device exists and works (as far as it goes). 
 
There are various files in the lower folder, including a compressed, 32GB system image and there is also a folder containing kernels as I play with them.  The kernel in the image does not have the nrpacks fix applied.
 
Regarding kernel:
 
3.10 is a little early in terms of USB throughput (I have patched the Armbian kernel with an nrpacks fix from 3.13 described here), there have been significant changes to the alsa tree, especially regarding DSD. I'm not sure that any of this is sonically significant but it does mean that I am prevented from using some of the output options that are available in the latest squeezelite versions.
 
I wish I were up to doing the backporting work myself, but am not.  If anyone volunteers and needs a monkey for producing diffs or anything similarly dumb, I'd be happy to help and to test as far as my equipment allows.
 
The alternative is obviously to wait for the mainlining effort to catch up.  As of 4.10, I'm missing DSI (lcd) support, higer clock frequencies, IR and USB.. all pretty much show-stoppers, but I do know of and am vary grateful for the community working so hard to bring better mainline support to these allwinner chips., which represent fantastic hardware bang-for-the-buck, coupled with terrible driver support from the manufacturer.
 
 

As already done with other topics this will be the start of a new thread collecting more information over time.
 
Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here.
 
As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports:
 
RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1) Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi) RealTek RTL8723BS (used on Pine64+ and on CHIP for example) RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi)  
The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg.
 
Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance) Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals) Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run)  
So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible).
 
Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking).
 
Now the results:
 
NanoPi Air with el cheapo Xunlong aerial, AP6212 module, Kernel 3.4.113, no BT configured: 39 Mbits/sec and 188 retransmits on average. Full log: http://sprunge.us/aPXb
 
 
Pine64+ with same el cheapo Xunlong aerial, RTL8723BS module, Kernel 3.10.104, no BT configured: 39 Mbits/sec and 58 retransmits on average. Full log: http://sprunge.us/EffO
 
 
Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: http://sprunge.us/dWJV
 
 
ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: http://sprunge.us/Njhi
 
 
How to interpret the results?
 
The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead!  ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on) All 3 onboard Wi-Fi chips perform identical. This is due to single antenna 2.4 GHz Wi-Fi: 65Mbps bit rate resulting in ~40 Mbit/sec TCP/IP throughput with ideal/good/identical environmental conditions The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput  
Next steps:
 
Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set).
 
But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)

Just updated the kernel to 3.10.104 with the 'DIRTY COW' fix as promised i would do something.
 
Releasing an Image (dev Image) comes responsibilities, bpi-m64 users are not left alone.
I hope it works for you as it works for me. Have fun!
  
Good luck.
https://github.com/avafinger/bpi-m64-firmware#updating-kernel-to-310104

I have chosen to freeze on this version because there are some of my personal development stuff in there, it is not for production environment.
This vulnerability was fixed on Oct, 21 on Armbian and Oct, 22 on 3.10.104 (longsleep), maybe just timezone here but after i frozen to make my mods.
 
TBH, i have seen so many people running linux with 'root'  that makes 'Dirty COW' a kid in a kindergarten...
 
Anyway, you got me, shame on me, i will do something to fix the flaw.

If someone is interested i have compiled some TSLIB deb packages for the Pine64 Touch Screen to work without evdev driver or any other service behind.
 
Advantages:
 
* Easy to install (if you know how to edit xorg.conf)
* No service needed
* No calibration needed
 
Disadvantages:
 
* works on X11 only
 
Information and deb packages: 
https://github.com/avafinger/pine64-touchscreen Hope it can be useful.
 

Yes, i have the same legacy kernel for the Pine64 amd BPI-64. And most likely will work with NanoPi A64, that is what i will find out soon.

Well, it's simple enough, byte value at 0x28 is 0 if booted from MMC0 and 2 if booted from MMC2. You/we just need to find the right place to put this test in.
 
Edit: and I would prefer a hack like this over any other hacks since this has to be integrated with existing Pine64 support without complicating it too much.
Edit 2: I'm building a Pine64 image to see if this is executed during the boot process already
Edit 3: Default boot environment relies on this variable, so it should work OK

@Igor
I have not tested guvcview on NanoPi NEO Air, if i recall correctly, @mattday tested it on OPI headless and it crashed if the images size was larger than the desktop size area.
 
One thing to note:
* the driver has DEBUG enabled flooding with debugging messages, better disable it:
#define DEV_DBG_EN 0 // 1 - Debugging / 0 - Release
Also, vfe has some debugging/printing enabled, so better disable or clean the log from time to time.
 
For the Desktop user i would recommend:
* fswebcam compiled from source (https://github.com/avafinger/fswebcam), sorry @gravelrash, i haven't finished supporting  the deb package
* motion (stock version) or compiled from source
* cap-v4l2 with OpenCV help ( compiled from https://github.com/avafinger/cap-v4l2)- Contributors: @lvmc and @JulesThuillier.
* grabbing video with guvcview (compiled from source)
 
For the headless user i would recommend:
* fswebcam compiled from source (https://github.com/avafinger/fswebcam),
* motion (stock version) or compiled from source
* cap-v4l2 with OpenCV help ( compiled from https://github.com/avafinger/cap-v4l2)
* jmpeg-streamer compiled from source (****)
* ffmpeg with cedrus264. choose one the runs on your distro: https://github.com/avafinger?tab=repositories
 
(****)
To support JMPEG-streamer, we need this fix if you have not done it yet (credit goes to FA):
static enum v4l2_mbus_pixelcode try_yuv422_bus[] = { V4L2_MBUS_FMT_UYVY10_20X1, V4L2_MBUS_FMT_UYVY8_16X1, V4L2_MBUS_FMT_YUYV10_2X10, V4L2_MBUS_FMT_YVYU10_2X10, V4L2_MBUS_FMT_YUYV8_2X8, V4L2_MBUS_FMT_YVYU8_2X8, V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_VYUY8_2X8, V4L2_MBUS_FMT_YUYV10_1X20, V4L2_MBUS_FMT_YVYU10_1X20, V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_VYUY8_1X16, V4L2_MBUS_FMT_YUYV8_1X16, V4L2_MBUS_FMT_YVYU8_1X16, V4L2_MBUS_FMT_YUV8_1X24, };  
* Update:
Command line for the applications:
 
fswebcam:
fswebcam --Vflip 1 -r 1600x1200 -p YUV420P  cam640x480_2.jpg fswebcam --Hflip 1 -r 640x480 -p YUV420P  cam640x480_1.jpg fswebcam --exposure 4 -r 640x480 -p YUV420P  cam640x480_3.jpg ffmpeg-xxxx (where xxxx is the version you installed)
sudo ffmpeg-3.1.4 -f v4l2 -channel 0 -video_size 1024x768 -i /dev/video0 -pix_fmt nv12 -c:v cedrus264 test4_1024x768.mp4 Guvcview:
There is a Gui Menu where you can change the codec used to compress and save on the container, there is some command line to choose the codec also, but can't remember it right now

@Igor, @zador.blood.stained, @tkaiser, @lvmc,
 
We need to "patch" the enhanced OV5640 driver to activate AF, and load the "activator" module.
Will give more info ASAP.

ROFL... Really, i can't stop laughing.
 
 
Ok, serious now, i will try to answer.
 
* CAM500B works only on FriendlyArm M1/Neo Air boards AFAIK, no need to change anything. CAM500A needs to change logic level to work on M1/Neo Air.
 
* Orange Pi PC/One needs the extention, and you need the pins reversed (OV5640), you can either get a Banana Pi sensor (no need to reverse the pins with this sensor) or use this FPC cable (this might work).
 
* If your board is Banana Pi M2+,M64 you just need their sensor (OV5640).
 
This thread ended with general information about how to use OV5640 on OPI, FA and Banana Pi boards .
 
Thanks for the FPC/FFC cable tip.
 
* Update: Not sure the FFC reversed cable will work since you have to reverse the pins on the output connector!

In order to use the OV5640 you need the following:
 
* Change script.bin (/boot/script.bin) to use OV5640 in this section. Use bin2fex and fex2bin tools to edit and change this section. Search forum to get the correct OV5640 configuration.
* Edit /etc/modules and add the two lines:
ov5640 vfe_v4l2   Boot the board and check if you have: ls /dev/video and if the camera was recognized:
dmesg | grep OK CAM500B is on the way, as soon as i get this i post a basic Howto.

In order to use the OV5640 you need the following:
 
* Change script.bin (/boot/script.bin) to use OV5640 in this section. Use bin2fex and fex2bin tools to edit and change this section. Search forum to get the correct OV5640 configuration.
* Edit /etc/modules and add the two lines:
ov5640 vfe_v4l2   Boot the board and check if you have: ls /dev/video and if the camera was recognized:
dmesg | grep OK CAM500B is on the way, as soon as i get this i post a basic Howto.

In my case, Fast Ethernet works as usual and a very basic analysis on GbE issue suggest RX does not work most of the times. And i can't say it is a faulty chip or poor soldering even looking at it.

I have managed to build FFmpeg with Cedrus on Armbian and it seems working.
It would be nice to see some benchs and how would be the best use for this AW Encoder.
I have not much experience with FFmpeg.
 
You can test it:
https://github.com/avafinger/ffmpeg_cedrus264_H3
 
 
To grab video stream from the CMOS camera:
sudo ./ffmpeg -f v4l2 -channel 0 -video_size 640x480 -i /dev/video0 -pix_fmt nv12 -r 30 -b:v 64k -c:v cedrus264 test.mp4
 
 
 
 

I have now the correct firmware for the ov8865 sensor.
 
Here are the full resolutions samples. The shots were taken INDOOR, cloudy day with indirect natural light and artificial light as you can see reflected on LCD monitor.
I have put also some shots  (ov5640) from the improved ov5640 driver (A64) here. The shots (ov8865) were taken on A83T and There are slightly more light condition on the ov5640 day shot. Natural light makes far better quality, so it is not really fair to compare the day shots in this case (ov5640 vs ov8865). To be able to compare the day shots i would need a sunny day (no clouds) and a lux meter.
 
For the night, they have exact same light condition, so you can compare ov5640 vs ov8865.
 
The ov5640 sensor is AF and was not activated, and i am not sure if the OV8865 is AF (datasheet: "AF_VCC and AF_AGND is the power supply for auto focus related circuitry.
although AF_VCC is 2.8 ~ 3.3V, it is recommended to use 3.3V to have better auto focus performance.", but it was not activated also, may be if AF was 'on' it could improve focus on ov8865.
https://drive.google.com/file/d/0B7A7OPBC-aN7UjF6QzZxTlZNbE0/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7T2pKYlM3SENFWHM/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7RXo4UGJqRjM5c2c/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7bkJsaGp4UldROVk/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7VjlZVU02dkd1X2s/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7TzhDRndjRDBVNTQ/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7Y0gzWmdva3Bac00/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7V1FuQlNxeHhjOWc/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7MGJPR1lEUmEtamc/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7TW5LN0tFdkNvek0/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7N3hvZE9lbVZ0cHc/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7andkYnE5MEkybWs/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7NFh4bEFhcC1PNzA/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7bXBUZTh0RExCTU0/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7dWc3bXladEtvQWs/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7cHV5Q21CZUMtSjA/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7NE96Nk1mRXZDQ3c/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7RGdyQVJGUVdxQUU/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7TENlLTdhT192LVE/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7ZjhzOXc2cGxiMzg/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7Zkp1a1lkOU9ZclE/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7WUxvSXJrdjZ6S2s/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7UEN2MmNPVU9JaGs/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7eXV0cHZUdG5vVE0/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7MEZHQWVJWFEtZXc/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7R2ZBUzVQdFo5N1U/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7bEpxRUs1RFJPVzg/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7eWNXQzdrOFVza0E/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7SmJFbU1FRVBxY1U/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7ZFQwWElVYTllWXM/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7blRON0d5VFU1dG8/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7MWRlTW9lUnZaM28/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7OHFPRGlpV19oMms/view?usp=sharing https://drive.google.com/file/d/0B7A7OPBC-aN7VHI1VUhsRGZSVjg/view?usp=sharing You can see here that a bit more light can get a good shot:
https://drive.google.com/file/d/0B7A7OPBC-aN7d2NpeElHSEY4dUU/view?usp=sharing To conduct a good comparison test in day light condition i would need a lux meter and i don't have one.