gounthar

OK, after some research I managed to find and configure a USB video grabber for my OrangePi PC Plus.
 
I'm building a audio center for my car using OrangePi. And I decided to install a cheap reversing camera from ebay in my car, which supplies composite analog video output.
I want to display the reversing cam stream on also on my OPi audio center display, so I needed an analog video grabber.
 
I have ordered exactly this one from ebay:
EasyCap DC60 USB Video Capture Card Adapter with ChipSet UTV 007 for Win 7 8 10
 
It's very important to let it have UTV 007 chipset surely,  attention, there are many copies with different chipsets. What I read other chipsets won't work.
I installed the driver from this link:
usbtv
 
After driver installation, you should see something like this:
# lsusb Bus 003 Device 005: ID 1b71:3002 Fushicai USBTV007 Video Grabber [EasyCAP] And check if the device could be used as a capture device:
# v4l2-ctl --all Driver Info (not using libv4l2): Driver name : usbtv Card type : usbtv Bus info : usb-sunxi-ehci-1.6 Driver version: 3.4.113 Capabilities : 0x05000001 Video Capture Read/Write Streaming Priority: 2 Video input : 0 (Composite: ok) Video Standard = 0x0000f900 PAL-M/60 NTSC-M/M-JP/443/M-KR Format Video Capture: Width/Height : 720/480 Pixel Format : 'YUYV' Field : Interlaced Bytes per Line : 1440 Size Image : 691200 Colorspace : SMPTE 170M Transfer Function : Default YCbCr Encoding : Default Quantization : Default  
This seems very good.
After that using mplayer I can see the captured video stream perfectly on my HDMI display with 800x480 resolution. 
You need to supply the proper options for mplayer. I wanted to see the stream on the framebuffer, since I don't use X window. This command works for me:
mplayer tv:// -tv driver=v4l2:norm=PAL-M:width=720:height=480:outfmt=yuy2:device=/dev/video0:input=0 -vf flip -vf expand=800:480:40:0 -vo fbdev:/dev/fb0 Change the video filter -vf options (flip, expand) according to your display resolution and needs (if needed at all).
The stream is playing perfectly, without any single frame dropped.
 
There is one important thing. Always connect the USB grabber to the OrangePi using a USB hub! The device is taking 330 mA which is too much for the OPi, without USB hub the OPi USB supply voltage drops down to 4.3 V. 
I'm planning to order and try this cable also: Delock Cable USB 3.0 type A male + USB type A male > USB 3.0 type A female, I hope with this one I can just supply an external 5V DC power to the dongle, without using a hub.
 

As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
 
Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
 
However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
 
So this is a step-by step guide on how to make everything work:
 
0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
 
>> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
Hold the ffmpeg packages, so they don't get upgraded:  
$ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
Restart the service:
$ sudo service emby-server restart  
Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
 
 

 
And that's it!
 
As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
 
Enjoy! And please, share your experiences and comments here.

Sounds good...  When/If pics happen - top/bottom of the board, thermal solution, take a close look at WiFi (should be a system on module, if you can note the vendor/model there), and mass storage... also look for UART pads, as this is key - if you can get into uBoot, that's a good thing...
 
I suspect that whatever they're doing, it's going to be super cost optimized... at the sub-$30USD price, including an IR Remote, HDMI cable, AC adapter, and of course the shipping box -- Sunveil must have done lot of work to reduce any additional BOM costs to keep some profit on the product.
 
In past experience with AllWinnner Android boxes, ADB is there, and fairly open, at least on Android 4.x - this one runs Android 7* (Nougat) so all bets are off - just note that there might be some security items with the BSP that you can take advantage of to get root for spelunking of the OS in general... First shot would be -- If Google's PlayStore is enabled within the stock Android on that box, one might consider getting "Termux" (it's free) and dig around a bit - it's sandboxed, but one can still get some decent info about the environment it runs in...
 
* bit surprised with Nougat support, but hey, it's current enough...
 
Anyways - to check the kernel/etc - go into Kodi, and there, you should be able to confirm the android and kernel versions...
 
Best case - might be a good alternative for the OrangePI Plus 2E...
 
 

Ok, will do... with a very bad stupidphone.

I received the box tonight. I will test it under Android this week-end, and afterwards, lets the butchery begin.

smart!   the connector the user normally only touches once (HDMI, Network, Powering) is on the back-side and connectors which are touched more often (USB) are on the front (assuming IR is normally on the front side). A bit risky but IMO interesting is to throw out the microSD slot. It may solve a bunch of those support questions which end normally here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ (at least the SD related ones ) and 12MB SPI flash is more than enough.  IMO an important 'what if' question:
What if I mess up the bootloader and brick it? I'm not familiar with enough with Amlogic SoCs, are they 'failsave' to unbrick SPI once it's messed up (e.g. something like RKs recovery tools?). I've a talent in messing up u-boot, luckily this only happened on SD-card (of fail-save sunxi) yet, where it wasn't much an issue. I probably pledge for a 1gb version if there are still some left for 19$ when I'm back at home..  Not that I'm interested in Kodi on Linux stuff, still a mystery to me why people want Kodi on Linux (anyway, I don't need to understand everything)..  But I appreciate your contribution towards mainline support for hardware accelerated video en/decoding and it could be a cute little IoT end-node for systems where you can't trust that your device doesn't magically disappears (others would call it someone steals your stuff). At least potential confidential information of this node is not in the wrong hands as soon as they cut power. A cute little toy to get a feeling for PXE related stuff. 

I received the box tonight. I will test it under Android this week-end, and afterwards, lets the butchery begin.

Some SBCs for which Armbian images are available (supported, wip or csc) can be powered via USB-C. Depending on its implementation, some pitfalls must be considered. This short tutorial should give you an overview. 
 
'Dumb mode':
The USB-C connector is used similar to the microUSB connectors in previous SBCs. Means that the pitfalls must be considered when you choose a charger and cable. See the following thread for some background:
Additionally, those boards may be problematic with PD compatible chargers. Without a proper PD implementation those PSUs will only deliver up to 900mA at 5V (4.5W). In case you have a board which isn't PD compliant you should go for a PSU without PD implementation aka 'dumb PSU'. Voltage drop from cable and voltage drop of the PSU at hight load itself must be kept in mind similar to microUSB powered boards!
SBCs which don't support PD (also boards not supported in any form by Armbian):
Vim Vim2 NanoPi M4 NanoPi NEO4 Orange Pi 4  
PD mode (power detection):
With a proper PD implementation, a PD capable PSU can deliver 'more juice' on demand. It's also possible to deliver power at higher voltage (between 5V and 20V). See graphic (12V is missing here):

(source: https://www.digikey.ch/en/articles/techzone/2017/mar/designing-in-usb-type-c-and-using-power-delivery-for-rapid-charging)
To ensure proper powering you should go for a PD compliant PSU. See documentation of your board to see which PD modes are supported within your SBC. Boards known to support PD-Mode:
ROC-RK3399-PC (Renegade Elite)
 
Board:

not really. The tinker can work with RPi cameras e.g. OV5647 and IMX219 as long they've the same pinout (sold as 'RPi compatible') but the kernel must be fixed first.. go through:
and
 
firefly compatibles (not my field cause I don't own it and never spent much attention to it) but there was someone who digged into the OV13850 during ISP1 development:
https://github.com/rockchip-linux/kernel/issues/33
https://github.com/rockchip-linux/kernel/issues/112
https://www.bountysource.com/issues/48831243-rockchip-isp1-driver
 
I had in mind that they got it finally working but no idea where that post is... 
 
I assume this one as compatible.. but that's up to you to clarify it before you buy one..  
https://www.amazon.com/OV13850-Camera-Module-Firefly-RK3288-Optional/dp/B06XBMNH77
 
For the tinker:
https://github.com/chwe17/build/blob/rockchip-default/config/kernel/linux-rockchip-default.config back then 'worked' but for sure the patch series and a bunch of other stuff will be broken now.. go through:
https://github.com/chwe17/build/commit/c26f02b65e6ac1c697b48d7677d1f178017f3994 to get an idea... I somehow lost the interest back then.. 

The only board with a RPi 'compatible' CSI is to my knowledge the tinker... Some RK3399 boards do also have CSI ports but I'm not sure if they've the same pin-out (had in mind that they've mostly a 'firefly' compatible which differs from the 'rpi' compatible). Just check it properly before you choose one.  

Latest RK3399 arrival in the lab. For now just some q&d photographs:
 



 
@wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!
 
A quick preliminary specifications list:
RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed  

Please be very careful with these wordings. M.2 is not mSATA. M.2 is just a mechanical connector able to transport a bunch of different protocols. In case you have no other device suited for an M.2 SATA SSD you might want to have a look at https://jeyi.aliexpress.com/store/group/USB3-0-USB3-1-Type-C-Series/710516_511630295.html for external USB3 enclosures (to get a bulky but ultra fast 'USB pendrive'). But since a 'generic' 60 GB SSD will perform crappy anyway and you talked about Amazon the best you could do is to return such a thing right now.

That's amazing. Now I want to Cascade login to as many as possible. #SBCeption

Sent from my Pixel using Tapatalk

Now FriendlyARM has a wiki page for NEO4.

Just a little bit list, more detail would be done on wiki soon.
1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
 
Both have:
1. PCIe x2 pin-out
2. eMMC module connector
3. GigE port.
4. TypeC is for power supply and OTG.
5. HDMI-A & MicroSD slot.
6. Big CNC heat sink, with two side 1/4 screw hole

testing  testing  testing..  
You need:
a github account a bit of time a SBC armbian supports git clone https://github.com/armbian/testings cd testings ./createreport.sh you don't even need to fork the repo in the browser, we'll do it for you from command line..  Same for the PR, everything is done from console.
 
is back now even for google users... 

If I would have a running windows machine at the moment..  I would test it...  but thanks to @hjc I may copy it partly in the starter..
updated.. I guess there was an u too much in uniq.. But this one should be correct now.
grep "g_serial" * | awk -F. '{print $1}' | uniq  
If you think the average armbian user doesn't know the console you set the bars low  Calling it a serial console is IMO questionable,  serial drivers are loaded a way earlier in the kernel than g_serial. Whenever possible, we should force people to use a real UART-USB adapter and g_serial should only be 'promoted' if the user doen't have a adapter. 

It works great on Windows Server 2016 (so probably Windows 10, too). Now I'm playing with my NanoPi on the desktop workstation in my office.
 

 
It's easy to use, run devmgmt.msc, find the serial device, then go with putty.

Well, if this article is meant to be something for an average Armbian user you should IMO elaborate a bit on what a serial console is and how it's possible over an USB cable. Also not looking at this from the Windows perspective (ignoring +90% of our users?) makes the whole attempt more or less useless. And then I don't understand how you built the list of affected boards (since those the feature has been implemented for are all missing: the inexpensive and headless H2+/H3 boards)

Right ! I've more than 10 around : some FT232, some CH340, some PL2303 and some CP2102 ...

that's not a solution, that's a workaround.. and IMO a shitty one due to wifi for the OPi zero can be.... uncool 
If it would be my board, I would prefer to have this fixed befor wifi might quit in the future.. Just as a first one 'sudo armbianmonitor -u' can be helpful
 
see comment at the download page:
 
USB gadget mode can be something to test.. And as @martinayotte mentions everytime, and I second that: spending 1-2$ for an USB to UART adapter is it worth when working with SBCs.

Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).
 
Prerequisites:
We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:
on debian a like systems:
sudo apt-get install picocom from arch community repo:
https://www.archlinux.org/packages/community/x86_64/picocom/
 
on fedora systems:
yum install picocom on Mac OS X:
brew install picocom on Widows we use PuTTY:
 
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
 
UART USB Adapter:
There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102
Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  
You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:
GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 
Linux:
[256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0
Windows:
for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8)
Something like the picture in USB Gadget Mode part of the tutorial should show up)
 
Armbians default settings are (expect some RK devices):
For Picocom:
picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices:
picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY:
You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

 
OS X:
TBD
should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&amp;t=841 as an example with minicom.
 
Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 
 
USB Gadget Mode
Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):
 
install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up:  [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters  
connect to it via picocom (in this case 'picocom /dev/ttyACM0'):  chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  
I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  
For Windows:
run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8):
(even the tutorial is for arduinos, it should be similar for every 'COM device')
 
Currently boards with USB gadget mode:
bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3  
The silly approach
For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard
For those loving text more than videos:
SSH to your SBC sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2  
 

See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

 
 

Try pre configuring the image and network with a static IP before boot
 
There is a simple script in dev that will do that here: https://github.com/botfap/armbian-image-config
 
git clone https://github.com/botfap/armbian-image-config.git cd armbian-image-config For Ethernet:
sudo ./armbian-image-config armbian-image.img e|ethenet [dhcp|static] [ipaddr mask] [gw] [dns] e.g. sudo ./armbian-image-config armbian-image.img ethernet static 10.0.0.50 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan  
For Wifi:
sudo ./armbian-image-config armbian-image.img w|wifi [dhcp|static] ssid key [ipaddr mask] [gw] [dns] [search] e.g. sudo ./armbian-image-config armbian-image.img wifi static MyWifiAP MySecret 10.0.0.51 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan  
Obviously replace armbian-image.img with the path and name or your Armbian image file. Then write that file back to SD Card

Can you try setting the connection details and IP address manually in your image before boot? Does it still not connect?
 
If your device has been randomizing mac addresses, then your DHCP pool may have run out of addresses, even though it doesn't list them as used
 
If you run tcpdump on the dhcp box can you see any DHCP negotiation traffic?

nope it can be either accessed via USB-UART adapter (that's what those 3 pins near to RJ45 are for.. Or with armbian via USB gadget mode. 
 
yep
 
hmm that sounds strange.. But with your previous armbian it worked properly on the same router via DHCP?