• Content Count

  • Joined

  • Last visited

About zeekoe

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For those who like to monitor temperature. Connect SDA & SCL to pins 3 and 5, connect 3.3V and GND. Connect all address wires of the DS1621 to ground. # sudo apt install i2c-tools # echo ds1621 0x48 >/sys/class/i2c-adapter/i2c-1/new_device# cat /sys/devices/platform/ff140000.i2c/i2c-1/1-0048/hwmon/hwmon0/temp1_input Optional, use lm-sensors: # sudo apt install lm-sensors # sensors Optional, temperature logging: Create a file logtemp.sh with the following contents: #!/bin/bash echo "`date +%Y-%m-%dT%R`;`cat /sys/devices/platform/ff140000.i2c/i2c-1/1-0048/hwmon/hwmo
  2. Recently, my sound stopped working, perhaps after an update. After some searching I found out that for me, the card order had been changed. flac -d file.flac -o - |aplay -D hw:1,2 confirmed me on that. So where you read hw:0,2 before in this thread it should become hw:1,2. That is, if your aplay -l output is like this: **** List of PLAYBACK Hardware Devices **** card 0: rockchiptinkerc [rockchip,tinker-codec], device 0: ff890000.i2s-i2s-hifi i2s-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: OnBoard [USB Audio OnBoard], device 0: USB Audio [USB Audio] Subd
  3. Thanks a lot for checking. I did some (hardware) measurements, all seemed well. Then tried just another time, having reconnected everything, and... it all seems to work now. :-? Really don't know why. Sorry for all the fuss... (Now on to wrestling with jackd to get input and output to work simultaneously, will report the settings back when I get it, won't be tonight...) edit: jackd settings found. Can't seem to set them like this in qjackctl, but can set them manually in .jackdrc: ~$ cat .jackdrc /usr/bin/jackd -v -dalsa -Chw:OnBoard,1 -Phw:OnBoard,2 -p2048 -n4 the -p
  4. Downloaded what I think is the latest nightly with mainline: papier@tinkerboard:~$ uname -a Linux tinkerboard 4.19.12-rockchip #5.67.181227 SMP PREEMPT Thu Dec 27 02:25:07 CET 2018 armv7l GNU/Linux papier@tinkerboard:~$ arecord -l I think at first opening of audacity I saw an onboard D2, but I didn't see it ever after. Same results: D0 silence, D1 mild noise independent of the input. I did see spikes however when turning on/off the (70's/80's) stereo set nearby. Does it help if I upload a new armbianmonitor output?
  5. Thanks. That would mean a full install right, not like switching channels and apt upgrading? Maybe I can try later this week. If I can find a spare SD somewhere (really, I don't have that much of them laying around :))
  6. Sorry, clicked them away once and now I don't know what was there. http://teune.email/armbianmonitor.txt That's with mainline kernel BTW. Edit: I just tried switching, but the docs point me here where I just see two repos. I can see a linux-u-boot-tinkerboard-next package which may or may not do the trick, and armbian-config just seems to let me switch kernel versions, not mainline to next and vice versa. Could it help me trying to switch to next? If so, is there a place with slightly more documentation on how to do it?
  7. And another sound related question from me: does anyone have the input working? I have: * Silence on onboard D0 * mild noise on onboard D1 All unrelated to what I do on the input. If I don't ground the input (I connected a 6,5mm jack to it; one of my use cases is a guitar looper), I get 50Hz noise on my audio out. Capture 0 and Capture 1 volume on alsamixer don't seem to have effect on that. The fact that I need to ground the input, gives me the feeling that "something" is working. I also tried with a regular TRRS head set to check if my weird setup is the problem, s
  8. @Solskogen could you tell what you tried? Did you e.g. read my post of August 24 (click "Reveal contents").
  9. https://github.com/bitbank2/ArmbianIO/pull/14 Note that there's still a bug somewhere: after exactly 38 codes received, I get nothing through in the JAVA method. The poller is still running though; I get "Code timeout" messages every three seconds (from C) and "Tick" messages every second (from the JAVA main sleep thread). This translates generally to: after 38 times of executing the call back after creating it, it doesn't execute the callback anymore. I tried removing & re-adding the callback periodically, and in that case the callback is executed again. Does anyone know
  10. Great, thanks. I'll need to take a little time to polish it a bit and then I'll create the pull request
  11. Thanks for this wonderful lib! I attached a TSOP34838 to my Tinker Board, and am using ArmbianIO to decode the IR signals. At first in JAVA. This worked better than I thought. However to get the signal when it's done sending (and not ~87 ms later) I needed to change the C library. Apart from that, I think it's more stable under heavier load. My initial try is here: https://github.com/bitbank2/ArmbianIO/compare/master...zeekoe:master @Larry Bank Is this a direction you'd like to go with the library, or do you like to keep it more light-weight? If it is, I can clean up
  12. Thanks. About the solution, isn't the main problem the missing manual configuration? (the load-module module-alsa-sink device=hw:0,2 sink_name=tinker_output part)? That's not there after a clean install.
  13. Woohoo! On 4.14.52-rockchip (mainline) I got it working immediately with this fix! A small tweak; instead of rebooting, killing pulseaudio worked for me. Note that on the "debian server" image pulseaudio isn't installed by default. pulseaudio -k mplayer <some song> Now let's go replacing my old bulky media server with my fancy new tinker board
  14. Well supported in mainline, that's what I like to hear, thanks. As for audio, does that also mean the 3.5mm jack? It surprises me reading the other thread about audio. I might take the plunge, this board deserves a broader user base.
  15. Hi all, For some time I've been following development. I think of buying a Tinker board. My wishes: - Being able to act as a web server (e.g. Apache/PHP) + do some scripting - Use the GPIO's (root mode no problem) - Decent audio out (no audiophile quality needed, but RPi is too bad for my purpose) - Long term software support that's as open as possible Especially the latest reason is where my doubts are. Of course no guarantees can be made, but what would be the odds of Armbian (or a fork) supporting this board in, say, 5 years? I don't really trust