Vecow EIC-1000 in an industrial Edge AI computer powered by Rockchip RK3399 hexa-core Cortex-A72/A53 processor with 9V to 55VDC wide-range supply input, an operating temperature range of 0°C to 70°C, and designed for digital signage, factory automation, smart retail, and other AIoT/Industry 4.0 applications.
The fanless mini PC is equipped with 2 GB DDR3 SDRAM and 32GB eMMC flash, offers 4K video output via HDMI, Gigabit Ethernet, USB 3.0/2.0, and RS232/RS485 serial ports, and more.
Vecow EIC-1000 specifications:
- SoC- Rockchip RK3399 hexa-core Arm processor with dual-core Arm Cortex-A72 @ 2.0 GHz, quad-core Cortex-A53 @ 1.6GHz, Arm Mali-T860MP4 GPU
- System Memory – 1GB or 2GB DDR3L 1066MHz SDRAM
- Storage – 32GB eMMC flash, MicroSD card socket
- Video Output – HDMI 2.0 output up to 4Kp60
- Video
- Encoder – Up to 1080p30 H.264/MVC/VP8
- Decoder
- Up to 4Kp60 H.264/H.265 10-bit, VP9
- Up to 1080p60 MPEG-4/MPEG-2/VP8
- Audio – 3.5mm headphone and microphone jacks,
- Networking
- Gigabit Ethernet RJ45 port
- Optional mPCIe module for WiFi & BLuetooth plus 2x antennas
- USB – 1x USB 3.1 Type A, 1x USB 2.0 Type A
- Serial – 2x RS-232/422/485 DB9 ports
- Expansion – Half-size Mini PCIe socket for PCIe card
- Misc – Power & Reset buttons
- Power Supply – 9V to 55V DC via 3-pin terminal block with V+, V-, Frame Ground
- Dimensions – 136 x 110 x 46.8mm
- Weight – 400 grams
- Temperature Range – Operating: 0°C to 70°C; storage: -40°C to 85°C
- Humidity – 5% to 95% Humidity, non-condensing
- Shock – IEC 60068-2-27
- Vibration – IEC 60068-2-64
- EMC – CE, FCC, EN50155, EN50121-3-2
The mini PC supports wall-mounting, and optional DIN Rail mounting through an additional kit. Vecow EIC-1000 can run either Android 7.1 or Debian 9.0 (Linux), which are older versions of the operating systems, but that’s probably because the processor was announced in 2016, and the company decided to rely on SDKs provided by Rockchip.
As a quick note, mainline Linux does support most of RK3399/RK3399K features, but the status matrix on Rockchip’s open-source website shows incomplete HDMI support and a complete lack of GPU and VPU support. But I’m not quite sure the table is up to date, as the recent Debian 11 release specifically added the Panfrost open-source GPU driver for Arm Mali-T860 and various other Mali graphics processors.
The press release we’ve received by email does not provide availability nor pricing information about Vecow EIC-1000 RK3399-based industrial computer. Further details may be found on the product page.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I think they made a mistake regarding the 1.8 GHz for A53, because the regular max freq is supposed to be 1.4/1.5 for A53 (1.6 on the RK3399K), while most RK3399 are easily overclockable, 1.8 GHz on A53 isn’t stable in general. And I really doubt they’re running a digital signage machine at such unstable conditions with no valid reasons.
I’d say that software support should be reconsidered as debian 9 is less than 1 year to EOL and android 7 is eol for a long time now
End of life, but none safety critical signage software etc may well continue to run satisfactory ( if no Bluetooth in use ?? ). It not like a must update for fashion, Android phone ( there maybe other security problems admittedly ).
> I’d say that software support should be reconsidered
There is obviously no software support to expect when they list these outdated OS versions. It also means they ship with an early/ancient 4.4 kernel lacking tons of security fixes. At least from this perspective it doesn’t matter that 4.4 has its projected EOL in 5 months 🙂
Will these boards not benefit from the Linux work for other RK3399 board makers, Friendlyelec, Khadas, Radax etc
Or is specific board support more complicated? Nvidia Shield has enjoyed long software support, but has no RK3399 as it uses Nvidia SoC. But Nvidia shows longterm support can be done, if the parent company bothers.
The problem is very simple, Xinese hardware manufacturers don’t care about software. You can buy their chips, or not. Unless you buy a 100k chips or more, don’t expect any support. I thought RK was different than AW, after having had meetings in person with both companies, but alas, they’re all the same.
When you see their totally broken image flashing software that bricked my two StationPC-M2, and for which they still provide no spec nor source code, no doubt they’ve never understood anything about software!
Can you return them under warranty ?
If not, publish the experience on a website write up or video post, help warn others. Then send manufacturer the link ???
I managed to unbrick one of them by accident (flashing garbage) but that didn’t work for the other one. I’ve had several weeks discussions with their support who sent me even some debugging images showing that the internal eMMC had disappeared. If I had had only one device I would have sworn it died, but seeing this happen on two made me think about a software issue. In the end they exchanged it and analysed it, to figure that the eMMC image was apparently flashed to the NOR by the shitty rockchip crap tools that never work correctly, and that the SoC is confused on boot by what it finds there. The joke is that the NOR is not recognized by u-boot nor linux so you can’t flash it once booted form SD… The device is really awesome but you must absolutely not try to flash it yourself until the tools are fixed (if ever… rockchip…) because it’s 100% guaranteed you’ll brick it. Better insist so that they do it themselves at the factory. I really hesitated ordering another one to replace my backup server (4G RAM, M2, USB3, GigE…), but after this disastrous experience caused by rockchip’s amateurism regarding flashing procedures, I’m really worried about risking to brick another one by accident in the future. So mine stays in my computer bag for random devs and tests, and will turn to e-waste once it refuses to boot. Sad story of one of the most awesome small devices of the last decade that is plagued by horribly misdesigned and bogus flashing tools 🙁 Due to this I really doubt I’ll ever buy an RK3588 once it’s released.
Could they design a jumper between the NOR and the sbc copper tracks, to stop it being flashed unless the jumper is bridged ?
It’s purely a software issue. The windows version of the flashing tool offers the option. However once tested in a VM it couldn’t see any flash and would time out… No, really, rockchip needs to pull their fingers out of their ass, fire all their software team and hire people who really want to work, who will deliver working flashing tools with sources and protocol specs so that when you get a segfault during flashing (I did), users can at least have a look and try to fix the problem… There’s no other way around. It’s the only vendor left that causes trouble to install images on their hardware. There used to be AW with the FEX crap a long time ago but these days are over (as well as their products).
> There used to be AW with the FEX crap a long time ago
You’re talking about FEL which actually worked like a charm (no need for Windows, it worked with almost every OS out there, see https://github.com/ThomasKaiser/sunxi-armbian-flasher-osx for example.
FEX was their proprietary device-tree predecessor.
Oh you must be right, the two were available at the same time! But I remember having had to replug the original hard drive into my netbook to boot it under windows and discover their tool reguarly didn’t finish (I consider that when the progress bar stays at 99% over night it will never finish). It had to be retried many times to randomly work. Regardless, in my opinion the best way to distribute an OS is via a regularly partioned bootable device (SD, USB, etc) as is done on any standard machine in fact. Todays bootroms are functional enough to be able to do that and there is zero excuse for forcing users to go through complex and unreliable steps for this.