It looks like MR3420 use 3.3V and not TTL (5V) logic. You should be able to adapt this to other arm cards but beware that serial ports are ttyAMAx on raspbian and generaly ttySx on other systems.
If you need to cross TTL and 3.3V logic, have also a look at level shifters in :
http://elinux.org/RPi_GPIO_Interface_Circuits
Now be prepared to have occasionally strange effects in some case as it sometimes prevent to do a full hardware reset (that means that if your system crash, you may have to unplug serial connection). You should make some test if you want to use that remotely with an unattended system.
If you want the fan to stop the simplest way seems to supply it from an USB port.
But I think passive cooling is much more suited to that kind of device.
I agree with tkaiser on the fact that H3 is not well suited to number crunching.
Being interested in SDR I had a chance to compare it with a miniPC based on Intel Z8300
On the other hand it is better in UHD video decoding but my best results were with Android
For cooling those chips using thermal pads between the board and a metal plate is a good idea too.
It seems they were not designed to facilitate the use of any kind of radiator .
Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
Mainline kernel:
The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from kernel.org. For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far.
In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public)
BSP kernel:
So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices).
Allwinner's 1st BSP kernel variant:
Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on phoronix.com for various H3 based Orange Pi boards)
Loboris' kernel:
The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking.
Yann Dirrson's fork:
When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis.
1st Armbian legacy kernel:
Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings)
Alwinner's 2nd BSP kernel variant:
When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes.
2nd Armbian legacy kernel:
So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot.
Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default(currently exactly 112 rather large patches that add support for various hardware, new features, many fixes)
The SinoVoip experience:
While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board.
Further improvements:
In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards)
Summary:
Now a short overview about kernel situation combined with thermal/performance settings:
Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores
Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example)
Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores
Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings
Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)
Pin 2/4 are 5V and 6 is GND so it can only work when using 2 or 4 together with 6 (or any of the other GND pins). Then regarding temperatures, heatsink and fan it's easy:
H3 is a SoC made for OTT boxes, designed to being cramped into tiny enclosures with crappy thermal design. It's maximum working temperature by specs is 125°C -- Armbian starts to throttle way earlier so you're always save. This chip is designed to operate in a thermal range where touching it with a finger will hurt for sure (but it's a SoC and not a part of your body so relax and don't care ) Thermal readouts when using Armbian are off by approx. 10°-15°C. This is just the comparison of running Armbian when booting with Allwinner's u-boot 2011.09 vs. using mainline u-boot which is our default. So expect the real temperatures to be 10°-15°C above Our throttling settings take care of this and provide enough safety headroom. Since throttling works you neither need a heatsink nor a fan (but then you've to expect that your board will run slower under constant full load) Adding a heatsink is useful if you plan to constantly operate your device under full load conditions since it avoids throttling or throttling starts later Adding just a fan (without heatsink) is never useful since even cheap heatsinks perform better than just a fan Adding an annoying fan to a heatsink is neither necessary nor useful as long as you use Armbian default settings (when you use OS images from Xunlong or loboris or others based on that then it's a different story). Still: since throttling prevents overheating you or let's better say the SoC is safe. A fan is only necessary if you want to do number crunching (then you chose the wrong device anyway) or do consumption/performance measurements like me
Different heatsinks perform differently. The one you chose is unfortunately low price, low profile and low performance (tested the same on Pine64 just to remove it after an hour and throw it away) Heatsinks will always help a lot with heat dissipation but they work the better the more airflow is possible around. Use heatsinks with large spaces between the fins if you want to make use of convection, if the distance between fins is too small you would need additional airflow
That being said: Your temperature readouts are perfect having in mind that they are 15°C more in reality (H3 can cope with that, it's not a human being, it's just a chip designed to operate at high temperature in hot environments -- rated at up to 70°C ambient temperature!). You don't need the fan, try to remove it and see whether the additional airflow already helps. If that does not help then remove the whole enclosure and choose one with more space above the SoC.
You can use 'sudo armbianmonitor' with either the -m switch to get instant CLI based monitoring while -r will install RPi-Monitor. And by lurking through H3 forums you find many RPi-Monitor graphs that will show that there's nothing to care of as long as it's about SoC temperature. Our settings (voltage settings and thermal definitions) always protect you.
