• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map






Posts posted by zeekoe

  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:

    echo "`date +%Y-%m-%dT%R`;`cat /sys/devices/platform/ff140000.i2c/i2c-1/1-0048/hwmon/hwmon0/temp1_input`" >>/home/USER/temp


    Add an entry to /etc/crontab:

    0  *    * * *   USER /home/USER/logtemp.sh

    And restart cron or your box for logging every hour.


    Thanks to https://www.electronicsfaq.com/2013/08/ds1621-with-raspberry-piarchlinuxarm.html

    Hope it's useful for someone!

  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]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 1: OnBoard [USB Audio OnBoard], device 1: USB Audio [USB Audio #1]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 1: OnBoard [USB Audio OnBoard], device 2: USB Audio [USB Audio #2]
      Subdevices: 1/1
      Subdevice #0: subdevice #0

    Hope that helps for someone else. :)

  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 and -n are trial-and-errored to prevent xruns
    • The headphone jack input is on subdevice OnBoard,1 and the headphone jack output is on subdevice OnBoard,2


    This is for ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.14.70-rockchip

  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


    **** List of CAPTURE Hardware Devices ****
    card 0: OnBoard [USB Audio OnBoard], device 0: USB Audio [USB Audio]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: OnBoard [USB Audio OnBoard], device 1: USB Audio [USB Audio #1]
      Subdevices: 1/1
      Subdevice #0: subdevice #0


    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. Sorry, clicked them away once and now I don't know what was there.


    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?

  6. 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, same: silence on D0, mild noise on D1.


    Note that I checked D0 and D1 with audacity over ALSA over SSH. Audacity also had a "default" that did record something. Even with no microphone connected. Then I discovered it recorded the microphone of the laptop on which I run audacity. Still I think D0 and D1 *are* from the tinker board, because when running audacity on the laptop itself (not over SSH) all other inputs are completely different.


    Does anyone have sound in working? I think it worked before, the first time I checked it, with the TRRS head set. But I'm not sure. Maybe I was too rough on the TRRS connector of the tinker board? It looks very OK though. I'm puzzled.

  7. 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 why this is? I don't think I changed anything to the C code that could've caused this. But my C isn't very wonderful.

  8. 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:



    @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 stuff a bit. An option would be putting the variable timeout mechanism inside the callback, and the decoding mechanism outside.

    Note that it currently supports at least one specific remote with 800/1600 microsecond codes and 90 ms wait time. I plan to extend it for another remote I have with 600/1200 microsecond codes. Both seem to be RC5 (-ish).


    edit: aha, I knew I read about manual IR decoding for NEC codes somewhere, just didn't remember it was here and written by you :blink:. Well, I took a slightly different approach, making use of the interrupt thingy and it seems to work reasonably reliable. Let me know what you think of it. But if you didn't go that way, perhaps I would need to move on to a hard-polling mechanism too, if I want perfect reception...

  9. On 8/28/2018 at 5:33 AM, TonyMac32 said:



    I didn't know it wasn't working out of the box, I've fixed the issue in the scripts and aded a udev rule: 



    That rule keeps you from getting the "USB analog stereo" or whatever sink/source, where pulseaudio probes the device after it's been manually loaded.


    Thanks for the (inadvertent) heads up, and for the kudos.  :)

    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.

  10. Edited by Tido
    added spoiler



    On 1/14/2018 at 8:30 PM, TonyMac32 said:

    I have a few other things I'm playing with, however I wanted to post a quick "for experimentation only" post:


    This is at your own risk, I take no responsibility for your ears or audio equipment.  I would highly recommend testing this on a small speaker at low gain until we build some confidence. I have had good luck with an experimental 4.4 kernel (Rockchip-curated one, lots of bugs still) and will start trying to flip a few more switches on support wise.  One of those is obviously sound.  


    Tinker Board sound (to the jack) comes from a largely undocumented realtek USB codec, ALC4040, USB ID 481A.  It has a group of subdevices,  I assume for multi-channel use.  Now, for some reason, device 0,0 is NOT the headphone jack.  Device 0,2 is.  PulseAudio's hardware discovery only seems to log the first one, leaving the others untouched and unselectable.

    tony@tinkerboard:/etc/pulse$ aplay -l
    **** List of PLAYBACK Hardware Devices ****
    card 0: Audio [USB Audio], device 0: USB Audio [USB Audio]
      Subdevices: 0/1
      Subdevice #0: subdevice #0
    card 0: Audio [USB Audio], device 1: USB Audio [USB Audio #1]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: Audio [USB Audio], device 2: USB Audio [USB Audio #2]
      Subdevices: 0/1
      Subdevice #0: subdevice #0
    card 1: rockchipminiarm [rockchip,miniarm-codec], device 0: ff890000.i2s-i2s-hifi i2s-hifi-0 []
      Subdevices: 0/1
      Subdevice #0: subdevice #0

    So, time to do things "the wrong way" (If anyone knows how to do it the "right way" let me know, I'm just making it work for now.  I would assume figuring out how to make PA enumerate it properly is the right answer, that's not what I'm doing here.)


    tony@tinkerboard:~$ cd /etc/pulse
    tony@tinkerboard:/etc/pulse$ sudo nano default.pa

    find the section that looks like

    ### Load audio drivers statically
    ### (it's probably better to not load these drivers manually, but instead
    ### use module-udev-detect -- see below -- for doing this automatically)
    #load-module module-alsa-sink
    #load-module module-alsa-source device=hw:1,0
    #load-module module-oss device="/dev/dsp" sink_name=output source_name=input
    #load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=inp$
    #load-module module-null-sink
    #load-module module-pipe-sink

    Then add to that section:

    load-module module-alsa-sink device=hw:0,2 sink_name=tinker_output

    and save.


    Now reboot for best results.  You should see another "USB Audio" device, select it as your sink if it's not already selected.  I haven't bothered making it the default device as yet.


    Now, for the warnings:


        I fully believe this to be a Rockchip problem, not an ASUS or Tinkerboard problem, but in the past when I've tested this I would, upon playing certain source material, get absolute garbage out of the output.  Very loud and terrifying garbage.  There have been a lot of changes to the clock system over the last year with Rockchip, assignments and improvements, so it is possible this has been remedied, so I am testing it again.



    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 ;)

  11. 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.

  12. 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 ASUS' OS for this. Spending some time to configure stuff (like the audio now, as I understand) is no problem for me. What do you guys think?