Jump to content

Search the Community

Showing results for tags 'tutorial'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Categories

  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. This weekend I was revising and testing the OV5640 for some A64 boards. To enable the Camera (OV5640) on NanoPi A64 for the mainline kernel you have to update the following: * DT * GPIO-I2C Here is the excerpt : Kernel config: CONFIG_I2C_GPIO=m CONFIG_VIDEO_OV5640=m CONFIG_VIDEO_SUN6I_CSI=m
  2. I need a suggestion for a samba server (guess that is what it is called). I have an 8 TB external powered HD, and need a device that I can attach it to, so I can "see" it on the network. I had it attached to the USB 3 port on my Asus router, but it had issues, because the router did not support the 8 TB HD. I now have it connected to one of my microPCs (Tronsmart Ara X5) USB 3 ports, but I am only gettting a max of 12 MBs speed. I would like an inexpensive board that will support that drive and is easy to set up as a samba server..... thanks.
  3. Mini tutorial I am putting here some notes for posterity In the current version of armbian (testing H6) I use X11 / Xorg only reaches 1024x768, but my display reaches 1440x900. To add this new resolution to the list of Settings/Display you have to give these commands: # xrandr --listmonitors (this command serves to see what it's called, the hdmi output) # cvt 1440 900 (output: # 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync ) # xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync # xrandr --addmode HDMI-1 1440x900_60.00 # xrandr --output HDMI-1 --mode 1440x900_60.00 If it works then modify Xorg with: # sudo mcedit /etc/X11/xorg.conf.d/40-monitor.conf Section "Monitor" Identifier "HDMI-1" Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync Option "PreferredMode" "1440x900" EndSection # reboot
  4. hello dear all, I've been using the lm-sensors tool for years now - first time in Ubuntu and now i want to use it in Manjaro - my actually fav system LM-Sensors - it does a lot: It monitors CPU temperature, the fan speeds, and - additionally - also the motherboard voltages that could be measured. After using it for some time in Ubuntu - my previous fav-linux.i now want to use some advanced uses of lm-sensors - i have heard that we can use it in combination with some graphical interfaces to interact with it. first i have to do the Installation: step one: Install lm-sensors, then run it with no options to see what it does: $ sensors coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +47.0°C (high = +90.0°C, crit = +120.0°C) Core 0: +45.0°C (high = +90.0°C, crit = +120.0°C) Core 1: +47.0°C (high = +90.0°C, crit = +120.0°C) Core 2: +44.0°C (high = +90.0°C, crit = +120.0°C) Core 3: +46.0°C (high = +90.0°C, crit = +120.0°C) This is on an Ubuntu PC. My Manjaro system installs it a bit different i think - and afterwards i have to take care for the configuration, on older systems - (note 10 years ago i used Ubuntu) i have followed another setup: then i go ahead: Run sensors-detect to set it up to detect the sensors and the temp of the CPU. in the past i have learned that the safest method and way to do a setup and basic configuration of lm-sensors is to accept all of the defaults by: $ sudo sensors-detect # sensors-detect revision xyz (2019-01-30 12:00:33 +0200) and.... after getting the first scan - we can the setup in modify /etc/modules: but how to go ahead now.... how to combine it the get the advanced features - and graphical output!?
  5. I made a hardware setup guide for the Pine64 Clusterboard. It's over on their forums: https://forum.pine64.org/showthread.php?tid=7077 Long and short is that it's a $99 motherboard that can accommodate 7x $30 compute modules.
  6. It's *amazing* what you can find reading the Armbian documentation! I dig the shell, even old-school in a virtual terminal or minimal server type setup. Normally that means going through some squinty-eyed hoops to get the Terminus console font installed with larger sizes in the first place on large monitors. Wait - what's this? sudo dpkg-reconfigure console-setup I did this in a virtual terminal, and allowed setup to pick the right character set for me. Then I blasted the framebuffer with the largest Terminus font size allowed. Perfection! Not a big deal to most, but having this be part of the standard distribution image made my day. Soooo easy. thanks!
  7. You may have seen discussions around the forum regarding work being done by @adafruit using circuit python with Armbian, but I wanted to make sure this nice write-up had proper visibility. https://learn.adafruit.com/circuitpython-on-orangepi-linux/initial-setup
  8. For those of you who're interested in running a CMS on Armbian I've a small tutorial how to get django CMS working. If you're not interested in the 'story' just want a step by step installation guide, scroll to the end of this post, there you find it. Story: Following their installation guide it fails during creation of a django project with 'djangocms -f -p . mysite'. The error looks something like: After a brief google search I found that other also had similar problems. It seemed that pillow is the problem while the whole installation failed. Unfortunately pip pillow also failed, and this one helped me to install pillow. After installation of libpq-dev python-dev libjpeg8-dev, pillow could be installed without any issues and 'djangocms -f -p . mysite' too. Starting the CMS with 'python manage.py runserver' worked too but unfortunately wasn't accessible over local network (since all of my armbian devices are running headless, I need access over network to the CMS). Inspired by a next google result, I found out that I should run the CMS on the SBCs network IP not on localhost by using 'python manage.py runserver 192.168.0.44:8000'. Which led in a next error. ... DisallowedHost: Invalid HTTP_HOST header: '192.168.x.xx:8000'. You may need to add u'192.168.x.xx' to ALLOWED_HOSTS. Some housekeeping in the settings.py and restart of the CMS led than to a working system. # SECURITY WARNING: don't run with debug turned on in production! DEBUG = True ALLOWED_HOSTS = ['192.168.x:xx'] Lessons learned: Even if you're not a dev and your background is limited, it is possible to get something like this CMS to work if you're able to use google. By reading through google results and have a look on the output errors during installation you learn much more about your project/SBC than just following the step by step procedure I'll show at the end of this post. The 'tarzan approach' - Tarzan/me swings from tree/error to tree/error holding on to elastic lianas/error logs works but it makes sense to repeat this installation after get a straight forward approach for the next time you'll use it. Step by step procedure: Installing package dependencies sudo apt-get install libpq-dev python-dev virtualenv libjpeg8-dev Make your virtualenv folder for all your CMS projects (since django cms is capable to run multiple cms at once it might make sense to have a 'parent folder' where all of them are placed): mkdir CMS --> cd CMS Create and activate a virtual env: virtualenv env --> source env/bin/activate Update pip: pip install --upgrade pip Use the django CMS installer: pip install djangocms-installer Create a new directory to work in: mkdir tutorial-project --> cd tutorial-project Run it to create a new Django project: djangocms -f -p . mysite Setup for access via LAN: nano mysite/settings.py --> ALLOWED_HOSTS = ['192.168.x:xx'] (IP of yor SBC) Start up the runserver: python manage.py runserver 192.168.x.xx:8000 Your CMS will be accessible via browser on your SBCs IP port 8000. Tested on: OPi 0: ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i Odroid HC1: ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.9.46-odroidxu4
  9. I like it to anounce some messages/informations via TTS ( T(text)T(o)(S)peech) . Normally I use espeak with a litte better sounding mbrola-voice (No. 6 german). But on Android you could buy - for cheap againt the PC-version - some better voices. Like my favourite german Voice "Julia" from Acapela. So I always wanted to use this voice for the informations. I did found a "server"-app for android which takes a UDP/HTTP-request to play a given string via the default TTS on the android-device (or a .MP3 stored in the memory of the android-device). Its named Home24-MediaPlayer - and can be found at (isnt anymore in the Google PlayStore for me - only the Home24-App for Smartphone or Tablet): http://www.home-24.net/index.php?page=sites/home.php&app=media http://www.home-24.net/app/Home24-MediaPlayer.apk You could give the android-device the request via HTTP or UDP from your armbian-commandline or shell-script: # HTTP samples curl http://192.168.6.12:50000/tts='This is a Test' 1>/dev/null 2>/dev/null wget http://192.168.6.12:50000/tts='This is a Test' 1>/dev/null 2>/dev/null wget http://192.168.6.12:50000/track=MySong.mp3 1>/dev/null 2>/dev/null # UDP samples echo 'tts=This is a Test'|nc -w 0 -u 192.168.6.12 50002 echo 'track=MySong.mp3'|nc -w 0 -u 192.168.6.12 50002 The Message could combine many commands in one line (also in HTTP/UDP): track=Alarm.mp3|tts=Alarm|sms=0150123456&message=Alarm see also the Wiki for the Home24-MediaPlayer: http://www.home-24.net/wiki/index.php?title=Home24-MediaPlayer On my Smartphone it also does work, but when the screen and the device goes to sleep it wouldnt work anymore. So I did think about a device without a battery and did try a Orange Pi PC (H3) with H3Droid, but this was too slow for me - because the OPi PC always did work on the SD-Card (dont know if my card was too slow). I was hoping getting a better performance with the OPi PC because of the 1GB of Ram. [EDIT] ========================================================================= It was the card After the Minix NEO X5 - which did work without problems. I did gave the OPi PC a second chance with a brandnew 32GB Sandisk EVO. With this new card the access is now MUCH snappier I installed Acaplea's Julia and the Home24-MediaPlayer and its sounds - for me - a little bit better than the Minix NEO 5. PS: old card seems to be a Fake-SONY Class 10 card (or very old and used) ========================================================================= Now I will try a "old" Android-TVBox: Mini NEO X5 ( Dual Core RK3066 Cortex A9 1.6GHz , 1GB Ram / 16GB Flash). Does any one know another Android-App with a function like this?
  10. I stopped tinkering for a while but https://magicmirror.builders/ perked my interest and been grinning at such a simple project and generally think its really great. I think they have made some odd options as the server and electron browser have been lumped together which is a really strange choice for absolutely no advantage. The server does need restarts and would seem far more often than you would expect and the use of electron means armv7l only which is a shame for the 0/1 owners. You can install using chromium and you certainly don't need the load of a desktop?! Dunno been wondering. I wanted to use a zero as love that tiny footprint and price and there are loads tutorials out there that seem to have much more than necessary and electron is chromium in a java wrapper with reduced architecture offerings so why no support? But hey. Not that bothered about that but why the have made the server and browser monolithic as a server restart now causes a cool device to display a desktop and even why desktop on a mirror has me scratching my head. https://github.com/StuartIanNaylor/MagicMirror-Install-Guide-Raspberry-0-to-3 if anything it will present a different take on the install as for some reason they depart from vanilla and I actually think it works better. Shame there isn't a Banana pi zero image or is there as loving that form factor. I do know it gets hot as hell but just tinkering by a tiny mind with tiny boards. PS if there is something near working give us a shout with Armbian and BPIZ
  11. Not much of a tutorial, but it is something that often needs some googling and head scratching. This is how I got my particular modem working, your mileage may vary. Step 1) Get a modem that will work. I got a Huawei E397u LTE/UMTS/GSM modem. It's Cricket branded, but I'm on Google Fi, it will work with my data SIM. Step 2) Plug it in and see that it doesn't work. Step 3a) apt update Step 3b) apt upgrade Step 4) Install usb-modeswitcher Step 4, optional part 2) install modem-manager, modem-manager-gui (for general playing around) Step 5) unplug/replug the USB modem, see that it should magically have a different VID:PID when you type lsusb. You should also have some ttyUSB's, and you can check out modem details in the modem-manager-gui Step 6) set up network connection via the network dropdown at the top right of the desktop. You will need APN information for your carrier. I put in modem-manager so I could debug. It will cause issues if you do certain things with it while connected. My modem was $15, Ebay has them. https://www.ebay.com/itm/BRAND-NEW-Unlocked-Cricket-Huawei-E397-E397u-53-4G-LTE-Mobile-Broadband-Modem/262898110276 So does amazon.
  12. hi all, as documented here, i did some minor experiments with small heatsinks on an orange pi one sbc (allwinner H3) among the things i used a small matrix multiplication program which multiplies a 1000x1000 matrix single precision floating point matrix main.cpp the command to build is c++ -O2 -std=gnu++11 -pthread -o mat main.cpp then run ./mat the last documented results on an orange pi one H3 running at 1.2ghz is 2389.49Mflops ~ 2.39Gflops the sources attached is 'optimised', the means of optimization is unrolling of the innermost loop to take advantage of platforms that could do quad sp fp simultaneous execute i think those neon enabled platforms would be able to do that. the other optimization is that it spawn off 4 threads so that it could utilise 4 simultaneous threads for the matrix multiplication could try to run this and let us know what is the 'mflops' you get on your sbc? what is the sbc , the soc and the frequency it is running at? note that this is not necessarily the most optimised for your sbc / soc the parameters you could try to tune includes the THREADS_NUMBER for the number of concurrent threads in the source code in addition those who have more powerful soc could try to unroll the loops further, e.g. try to compile with additional options like -funroll-loops or even -funroll-all-loops you could also manually update the codes e.g. to double the set of manually unrolled codes in the loop so that it become 8 sets of computations instead of 4, but you would need to review the codes such as using MATRIX_SIZE/8; i+= 8 in in the loop if you unroll the loop into 8 sets of variables, you'd need to update the summation after the loop as well result.elements[row][col] = r1+r2+r3+r4; to add the other r variables that you unrolled into the original 'unoptimised' codes can be found in references in the original post. strictly speaking this is not really a good test of computational prowess unlike those of linpack etc. linpack actually solves a matrix, and this is purely a square matrix multiply. in addition, this does not explicitly use neon etc and those usage depends on the compiler optimization (i think gcc / g++ has a build in vectorizer, hence you may like to experiment with the options) but nevertheless seeing mflops, gflops is fun, mflops, gflops is also normally a function of the frequency the core executes at, hence you could try to overclock your soc to get more gflops
  13. There is no official sdcard image but the attached script will create a image for the OrangePi Zero/R1. It uses daily generated files from Debian daily-images and considered testing/unstable. SDcard image creation: You will need basic Linux/Debian and dosfs utils. No su/root needed. Run the script to generate sdcard image for writing to sdcard. Optionally, if you want ssh network-console access, add preseed.cfg to same directory as script. See attached preseed.cfg and example-preseed.txt . Basic installation: Once the installer is started, it runs completely in RAM and no longer needs files from the sdcard. You can delete all partitions on the sdcard and install Debian. Guided partitioning is recommended. When using ssh network-console installer, allow time for the installer to download files before logging in using ssh installer@IPAddress. Basic SDcard image script guide: Two parts are needed, the device-specific firmware.img.gz and partition.img.gz. Concatenate both to get full sdcard image. There is no firmware for the Zero/R1 but can easily be created by using gen-hd-image and extracted u-boot binary from deb file. For more info, see attached opz-sd-gen.sh script and wiki.debian.org. Notice: Posted for anyone interested in testing and experimental purposes. opz-sd-gen.sh preseed.cfg Edit: To use buster u-boot version instead of stretch, edit script with: sed -i 's/^UBOOTDEB.*/UBOOTDEB="u-boot-sunxi_2018.05+dfsg-1_armhf.deb"/' opz-sd-gen.sh
  14. (disclaimer) No itention to make a Frankendebian (https://wiki.debian.org/DontBreakDebian) but ubuntu package "zram-config" works perfectly. I tested it for two weeks in a: Orange PI Zero 512MB Armbian Stretch 5.40 4.14.18, Orange PI PC2 Armbian Stretch 5.40 4.14.18, AMD Sempron microserver Debian Stretch 9.4 4.9.0-6-amd64. A short tutorial: 1. Download zram-config package (it's a universal package, it does not matter the architecture in use) wget http://de.archive.ubuntu.com/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb 2. Install it sudo dpkg -i zram-config_0.5_all.deb 3. Remove the installer rm zram-config_0.5_all.deb 4. Check vm.swappiness cat /proc/sys/vm/swappiness (must be 60, default) 5. If not (i.e. "cat /proc/sys/vm/swappiness" return "1" ) change it to "60" sudo nano /etc/sysctl.conf and add "vm.swappiness=60" at the end of file ... and reboot 6. check zRAM service sudo zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo 437,8M 5,2M 1,4M 1,9M 2 [SWAP] /dev/zram1 lzo 437,8M 5,2M 1,4M 1,9M 2 [SWAP] 7. (optional) change lzo compression to lz4 sudo nano /usr/bin/init-zram-swapping # initialize the devices for i in $(seq ${NRDEVICES}); do DEVNUMBER=$((i - 1)) echo $mem > /sys/block/zram${DEVNUMBER}/disksize mkswap /dev/zram${DEVNUMBER} swapon -p 5 /dev/zram${DEVNUMBER} done to... # initialize the devices for i in $(seq ${NRDEVICES}); do DEVNUMBER=$((i - 1)) echo lz4 > /sys/block/zram${DEVNUMBER}/comp_algorithm echo $mem > /sys/block/zram${DEVNUMBER}/disksize mkswap /dev/zram${DEVNUMBER} swapon -p 5 /dev/zram${DEVNUMBER} done 8. restart the service sudo systemctl restart zram-config.service 9. check new compression algorithm sudo zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 437,8M 5,2M 1,4M 1,9M 2 [SWAP] /dev/zram1 lz4 437,8M 5,2M 1,4M 1,9M 2 [SWAP] 10. check the zRAM priority over file swap cat /proc/swaps zRAM devices must be at priority "5", swap file at "-1" or "-2" 11. finish :-)
  15. Orange Pi One PCB is designed to easy add almost all removed features from Orange Pi PC. Currently only RAM expansion is unprofitable. To add 2 removed USB ports just solder wires to solder points as shown below on the photo: Data lines for USB #3: points 1,2 Data lines for USB #2: points 3,4 Power can be taken directly from GPIO header or DC socket. OPiOne has no separate voltage regulators for USB ports like previous boards used to have. This way I want to solder mini WiFi dongle (after removing the case and USB port) directly to the PCB.
  16. 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!
  17. Hi there, this very short tutorial is a solution when you need to backup/clone/save as small *.img file as possible of your whole fully bootable system (e.g. you have 8GB card but you want to make smaller system image for 2GB card). And another reason why I created this tutorial - I need to burn the same image to many microsd cards. I am using Windows (yup, hate me know) and Debian in these steps: Put your microsd card to Windows machine and make image of card with Win32diskimager. If your card is e.g. 8GB, you get *.img file with the same size (my name backup.img). Now in linux maxine (in my case Debian virtual machine) we are going to work with backup.img file. Run these commands in terminal (if you are not root use sudo at the start of each line) modprobe loop losetup -f losetup /dev/loop0 backup.img partprobe /dev/loop0 Run gparted with this command and move slider of main partition to the left to make partition smaller (leave some space, e.g. I left 400MB free space) gparted /dev/loop0 Click on Apply once you are happy with it. We can unload loopback device now losetup -d /dev/loop0 With fdisk find out end of last block fdisk -l backup.img In my case last block is 3571711 so I run command truncate --size=$[(3571711+1)*512] backup.img Done! Size of your backup.img file should be now about 1.5GB. You can burn this new backup.img file to another (or the same) card/s now. In my case I dramatically reduced time needed for burning data to many many cards (it saves hours/days when you need to burn a lot of microsd cards). Enjoy! P.S. this can be done also with just Debian, so no need for Windows, in this case you just need to make first step with backup.img with linux command (e.g. dd). And of course you can set up a script on your newly burned card to expand system partition to the whole microsd size during first boot, if needed.
  18. I use the OrangePi Zero. But it is similar to other model. It's very simple: 1) use the mainline 4.11.x kernel 2) enable the uart1 and pps-gpio in /boot/armbianEnv.txt like this : overlays=uart1 pps-gpio param_pps_pin=PA7 3) edit /etc/default/gpsd to use ttyS1 as gps device # Devices gpsd should collect to at boot time. # They need to be read/writeable, either by user gpsd or the group dialout. DEVICES="/dev/ttyS1" # Other options you want to pass to gpsd GPSD_OPTIONS="-G -n " 4) If you use ntpd, edit /etc/ntpd.conf like this: # GPS Serial data reference server 127.127.28.0 minpoll 4 maxpoll 4 prefer fudge 127.127.28.0 time1 0.135 refid GPS server 127.127.22.0 maxpoll 4 # ATOM(PPS) fudge 127.127.22.0 flag3 1 # enable PPS API 5) Or if you prefer crony rather than ntp, install chrony instead of ntp, edit /etc/chrony/chrony.conf , add this to end of it: refclock SHM 0 refid GPS precision 1e-1 offset 0.134 delay 0.2 noselect refclock PPS /dev/pps0 lock GPS 6) connect GPS module to UART1 GPS Zero --------------------- TXD UART1_RX PIN10 RXD UART1_TX PIN8 PPS IO-1 PIN12 7) use ntpq -p or chrony sources. to check it.
  19. overlay examples: GPIO keys Mainline Linux OrangePi gpio-keys.dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; fragment@0 { target = <&pio>; __overlay__ { gpio_keys: gpio_keys { pins = "PA7","PA8","PA9","PA10","PA21"; function = "gpio_in"; bias-pull-up; }; }; }; fragment@1 { target-path = "/"; __overlay__ { gpio-keys-user { compatible = "gpio-keys"; pinctrl-names = "default"; pinctrl-0 = <&gpio_keys>; g-keys_up { label = "GPIO KEY_UP"; linux,code = <103>; /* KEY_UP, see /usr/include/linux/input-event-codes.h */ gpios = <&pio 0 7 1>; /* PA7 GPIO_ACTIVE_LOW */ }; g-keys_down { label = "GPIO KEY_DOWN"; linux,code = <108>; /* KEY_DOWN, see /usr/include/linux/input-event-codes.h */ gpios = <&pio 0 8 1>; /* PA8 GPIO_ACTIVE_LOW */ }; g-keys_left { label = "GPIO KEY_LEFT"; linux,code = <105>; /* KEY_LEFT, see /usr/include/linux/input-event-codes.h */ gpios = <&pio 0 9 1>; /* PA9 GPIO_ACTIVE_LOW */ }; g-keys_right { label = "GPIO KEY_RIGHT"; linux,code = <106>; /* KEY_RIGHT, see /usr/include/linux/input-event-codes.h */ gpios = <&pio 0 10 1>; /* PA10 GPIO_ACTIVE_LOW */ }; g-keys_enter { label = "GPIO KEY_ENTER"; linux,code = <28>; /* KEY_ENTER, see /usr/include/linux/input-event-codes.h */ gpios = <&pio 0 21 1>; /* PA21 GPIO_ACTIVE_LOW */ }; }; }; }; }; https://github.com/ua3nbw-cf/gpio-keys
  20. We included in Armbian a small utility called h3disp. If called without arguments it displays just a usage information: tk@orangepipc:~$ sudo h3disp [sudo] password for tk: Usage: h3disp [-h/-H] -m [video mode] [-d] [-c [0-2]] ############################################################################ This is a tool to set the display resolution of your Orange Pi by patching script.bin. In case you use an HDMI-to-DVI converter please use the -d switch. The resolution can be set using the -m switch. The following resolutions are currently supported: 480i use "-m 480i" or "-m 0" 576i use "-m 576i" or "-m 1" 480p use "-m 480p" or "-m 2" 576p use "-m 576p" or "-m 3" 720p50 use "-m 720p50" or "-m 4" 720p60 use "-m 720p60" or "-m 5" 1080i50 use "-m 1080i50" or "-m 6" 1080i60 use "-m 1080i60" or "-m 7" 1080p24 use "-m 1080p24" or "-m 8" 1080p50 use "-m 1080p50" or "-m 9" 1080p60 use "-m 1080p60" or "-m 10" Two examples: 'h3disp -m 1080p60 -d' (1920x1080@60Hz DVI) 'h3disp -m 720i' (1280x720@30Hz HDMI) You can also specify the colour-range for your HDMI-display with the -c switch. The following values for -c are currently supported: 0 -- RGB range 16-255 (Default, use "-c 0") 1 -- RGB range 0-255 (Full range, use "-c 1") 2 -- RGB range 16-235 (Limited video, "-c 2") ############################################################################ This tool tries to patch script.bin (adjusts the display settings there) and requires a reboot afterwards. While it is not useable with vanilla kernel (script.bin doesn't play any role there and a display driver is also still not ready) it might be also useful for H3 users that rely on other OS images (Debian/Ubuntu based from Xunlong or from loboris). Our h3disp tries also to patch script.bin there with your settings so it should be useful for non Armbian users too BTW: It could also be used with Debian based Linux OS images for A83T/H8 (Cubietruck Plus, pcDuino8 Uno or Banana Pi M3) but unfortunately these vendors fail to provide OS images that use a patched u-boot version that could deal with script.bin. At least 'Team BPi' got it finally after being told since months where/how to copy&paste this stuff but since they only update their sources and provide no updates for their OS images, Banana Pi M3 customers are still lost In case you're an Android user you'll have to go the extra mile since the Android OS image for H3 Orange Pi's doesn't support script.bin. You could apply the changes h3disp offers to one of our provided fex files but have then to overwrite a few sectors on your SD card to get this stuff working (by choosing our fex files you could also 'patch' the Android image to run better on the Orange Pi One or get all USB ports and Ethernet on the other models and improve realiability and decrease SoC temperature)
  21. For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works. Hardware: OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation: First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/ with npm i node-red-dashboard If everything goes right you should have access to node-red via browser on port 1880: 192.168.1.xx:1880 and to the UI of dashboard: 192.168.1.xx:1880/ui/ Setting up everything: Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos): VCC -->3.3V Signal --> D4 GND -->GND Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...) For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager): PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker: The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data). Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing) We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture) To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo is provided "as is", without warranty etc.
  22. Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation. Hi All, I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room. Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together. However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as: No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing. I should also note that this guide on the terrible Orange PI forums, helped me with my issues. Step 1) Adjust /etc/lirc/hardware.conf Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf For Ubuntu Xenial (September 2017): The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = "" # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD="" For Debian Jessie (~year 2016): By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG. Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works: # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service As lirc is actually already running and installed in Armbian, do the following: root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work): user@orangepipc:~$ lsmod Module Size Used by mali_drm 2732 1 drm 178255 2 mali_drm mali 123208 0 ump 29379 3 mali sunxi_cir 1601 0 8189es 1076034 0 Step 3) Find out what '/dev/input/eventX' device is your IR receiver If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example: anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input ) Armbian has the 'evtest' program installed, point the IR remote (in my case a LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'. root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 152 (KEY_SCREENLOCK) Event type 4 (EV_MSC) Event code 4 (MSC_SCAN) Key repeat handling: Repeat type 20 (EV_REP) Repeat code 0 (REP_DELAY) Value 500 Repeat code 1 (REP_PERIOD) Value 125 Properties: Testing ... (interrupt to exit) Pressing the remote reveals events like: Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news. Step 5) Configure lirc to map IR input to key presses or events. Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys. There's plenty of information on how to use irrecord, command I used was: /etc/init.d/lirc stop ...to first stop the service, then: irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'. Step 6) Test with irw Now that I recorded my configuration file with irrecord: /etc/init.d/lirc start .. to start lird service again then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button: root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray! Step 7) Create a /etc/lirc/lircrc file to run commands sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player: # http://www.lirc.org/html/configure.html begin button = KEY_R prog = irexec config = mpv /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin button = KEY_W prog = irexec config = killall mpv & echo "SADFACE!" & end begin button = KEY_B prog = irexec config = mpv http://sj256.hnux.com & end You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command. So there you go, Rickrolling with a simple press of the red (KEY_R) button :-) Additional References: [Guide] Android + InfraRed (IR) + Kodi How to setup Remote Control for Linux
  23. Hello everyone, today I would like to show you how to compile CoovaChilli and Freeradius for a Wifi Hotspot with captive portal on an Orange Pi PC (or PC Plus). I'm writing this because I couldn't find anything related to this topic on the internet, so I wrote this not very detailed guide. wget https://raw.githubusercontent.com/ua3nbw/opihotspot/master/opihotspot_debian.sh chmod +x opihotspot_debian.sh ./opihotspot_debian.sh Russian version https://ua3nbw.ru/all/orangepi-coovachilli-and-freeradius-for-a-wifi-hotspot-with-capt/
  24. Hi All, After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were: Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio 1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example): [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time. Solution? Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start) There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today. So to fix, you need to type in the console: sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item. Press 'm' and you'll get the green 'OO', which means it's now active. Exit alsamixer, and when you're back at the console type: sudo alsactl store 0 ... to store you mixer settings. For your information, the mixer settings are stored to the file: /var/lib/alsa/asound.state ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file: control.9 { control.9 { iface MIXER iface MIXER name 'Audio lineout' name 'Audio lineout' value false | value true comment { comment { access 'read write' access 'read write' type BOOLEAN type BOOLEAN count 1 count 1 } } } } Step 2) Change the /etc/asound.conf file As you might or might not be aware, the default /etc/asound.conf file looks something like this: pcm.!default { type hw card 1 } ctl.!default { type hw card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job. However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this: pcm.!default { type plug slave.pcm "dmixer" } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.dmixer { type hw card 0 } ctl.!default { type hw card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this: # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards # https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default { type plug slave.pcm "duplicate" } ctl.!default { type hw card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer { type dmix ipc_key 1024 slave { #pcm "hw:0,0" # pcm "duplicate" pcm "hdmi-hw" # pcm "analog-hw" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.hdmi-dmixer { type hw card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer { type dmix ipc_key 2048 slave { #pcm "hw:0,0" # pcm "duplicate" # pcm "hdmi-hw" pcm "analog-hw" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.analog-dmixer { type hw card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate { type route slave.pcm { type multi slaves { a { pcm "analog-dmixer" channels 2 } h { pcm "hdmi-dmixer" channels 2 } } bindings [ { slave a channel 0 } { slave a channel 1 } { slave h channel 0 } { slave h channel 1 } ] } ttable [ [ 1 0 1 0 ] [ 0 1 0 1 ] ] } ctl.duplicate { type hw; card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw { type hw card 0 } pcm.hdmi-hw { type hw card 1 } There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines