• Content Count

  • Joined

  • Last visited

Everything posted by jscax

  1. Hello, I have OPI0 with Ubuntu 20.04.1 LTS with Linux 5.8.6-sunxi and I would like to set 240 MHz as minimum frequency. cpufreq-info shows that available steps starts at 480 MHz but on older kernel 240 MHz and 120 MHz were available too. I also tried to "force" 240 and 120 by editing /etc/default/cpufrequtils but no go. Lower reachable frequency is 480 MHz and what I see are a bit CPU higher temperatures. cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0:
  2. yes, it's a UPD6121 and I gave up about making it work with different protocol than NEC. I bought a double led with transistor ( https://www.aliexpress.com/item/Free-Shipping-electronic-building-blocks-Two-way-infrared-transmitter-module-IR-Transmitter-for-arduino/1972945414.html ) which allows me to just turn on/off the LED by changing high/low PIN and I succeded transmitting what I need. Note again: you need a double led with transistor to success I went for a very low level solution, similar to the one posted by nopnop2002 here above. I just save ON/OFF pul
  3. Pardon my huge ignorance. I think I'm not understanding the whole context Armbian vs OrangePI. OrangePI is selling PiZero Plus with bluetooth hardware built-in but is not delivering the driver to make it works, correct? This: https://github.com/orangepi-xunlong/OrangePiH5_kernel/tree/master/drivers/bluetooth is not something useful, correct? I'd like to have BT working. I bought OPI0+ for BT feature which I was missing on OPI0 and I did not consider that it shouldn't work. Can you please point me the direction to have BT working on
  4. I would use it for a temperature + humidity sensor
  5. I can't make bluetooth work on my OPi0+ Is it a known bug? Am I doing it wrong? thank you
  6. So an update came into apt upgrade and it updated max freq config file too (/etc/default/cpufrequtils). Welcome to ARMBIAN 5.53.180722 nightly Ubuntu 16.04.5 LTS 4.17.9-sunxi After the update max frequency was restored at the original default value MAX_SPEED 1200MHz and I was barely able to boot again my OPI0. I went through several boot attempts, then after leaving it turned off for 30 minutes I was able to boot again and change back the MAX_SPEED to 960MHz. From my experience 1200MHz frequency is the offending cause of the random OPI0 freezes. And I had
  7. ok now limiting CPU @ 960MHz Do you have a link for the DRAM thing? I think I'm a little bit out of the know... where can I keep me updated with armbian news? I think there's a lot I'm missing thank you
  8. it's not completely impossible to spot something on logs written before a kernel panic, that's my experience, but this time there's no trace. log2ram should not be my friend in this case. how does it work? it logs in ram, then a kernel panic occurs and puff... logs are gone because no one wrote them on sd? On the power supply side: I'm not using micro usb. I have a 15W PSU (and I'm using like 3 watts) connected with GPIO pins directely. I'll have a chance to use another power supply in a few days and will see if that's the issue.
  9. Sadly it crashed again after like 16 hours of uptime with the new kernel. In my case it must be on 24h/7d Attaching the armbianmonitor -u file I think it has something to do with logrotation/cron/log2ram something But I can't spot anything from logs. Now it crashed at 12PM and had to force reboot, which succeded at 12:31 thank you armbianlog.txt
  10. uname -r 4.17.6-sunxi Mmh now the CPU seems stuck at 1200MHz. Frequency scaling is not working anymore. armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 22:18:48: 1200MHz 0.65 22% 7% 13% 0% 1% 0% 47.1°C 0/8 22:18:53: 1200MHz 0.60 0% 0% 0% 0% 0% 0% 46.2°C 0/8 22:18:58: 1200MHz 0.55 0% 0% 0% 0% 0% 0% 46.1°C 0/8 cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVER
  11. It happened again and I can't find a pattern nor a cause. armbianmonitor -u share too much informations, attached a manually cleaned (I hope) version. 2018_07_04_armbianmonitor.txt There's something strange at the beginning of the attached report about wrong SD partitioning. I don't know if this has something to do with the crash. In this crash event I had to try to boot again 2 times, then at the 3d attempt it succeded. During the failing attempts I had to pull out 5V to force shutdown of the OPI0. The OPI0 is powered by an oversized 15W PSU and I
  12. it's happening again. there's something in rsyslog configuration which crash the Orange Pi Zero! I can see there's a new rule which writes on /var/log/syslog all ufw (firewall) catch: :msg,contains,"[UFW " /var/log/ufw.log I don't know if this make things worse but the issue here is that I'd like to get rid of this bad crash. After this crash I have to reboot several times, and I can do it only manually, removing +5V from the board. log2ram seems to be disasbled Can anyone help? This is having a bad impact tha
  13. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=134971#p898539 maybe I found the solution commenting out last 4 lines from /etc/rsyslog.d/50-default.conf, those last 4: # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole then service rsyslog restart Let's see if the issue will shows again
  14. So I have an OPI0 perfectly running then suddenly it freezes. All I can find on /var/log/syslog Jul 1 10:35:10 localhost CRON[1553]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Jul 1 10:36:08 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul 1 10:36:38 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Jul 1 10:37:07 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul 1 10:37:37 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ] Jul 1 10:38:07 localhost rsyslogd-2007: action 'action 10' suspended,
  15. Is it possible to import this dtoverlay? pwm-ir-tx overlay https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/pwm-ir-tx-overlay.dts and/or maybe this one? gpio-ir-tx overlay https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/gpio-ir-tx-overlay.dts
  16. The MCU programming way seems very hard for me https://wiki.libreelec.tv/infrared_remotes Here they talk about overlay enabling. That should be a great implementation, I don't know if this is possible in armbian. But it's all about receiving, I want to send. This: http://www.piddlerintheroot.com/ir-blaster-lirc/ seems very promising, do you see any cons vs my OPI Zero? Is OPI Zero capable of switching GPIO so fast? I hope so
  17. Yeah, YS-IRTM is working ok using the OPI Zero UART (thanks armbian ), now I can control my TV. The problem is that YS-IRTM works with NEC protocol only. I actually need to control a Samsung AC unit which uses Samsung protocol. YS-IRTM ==> https://www.aliexpress.com/item/5V-IR-Infrared-Remote-Decoder-Encoding-Transmitter-Receiver-Wireless-Module-IR-Decoder-Module/32528109291.html http://www.datasheetcatalog.com/info_redirect/datasheet/nec/UPD6122G-002.pdf.shtml => UPD6121 ====> NEC only Differences between IR remote protocols:
  18. Is there a way to use PWM or a GPIO pin roughly connected with an infrared LED to transmit IR bits with different protocols NEC, but also Samsung and so on? I tried YS-IRTM module via UART but it works with NEC protocol only, afaik. I need the Samsung protocol. I thought there should have been a library for that, but I can't find it or it doesn't exist. thank you (OPI Zero)
  19. Now the audio loops no matter alsa mixer settings and no matter I'm using it in single channel only. This is from my dmesg [ 12.083950] sun4i-codec 1c22c00.codec: ASoC: /soc/codec-analog@01f015c0 not registered [ 12.083967] sun4i-codec 1c22c00.codec: Failed to register our card [ 12.101011] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok 4.14.18-sunxi Orange Pi Zero v1.4
  20. My findings so far (some of the previous findings are wrong): - Audio will work on one channel only. No matter whether is LINEOUTR or LINEOUTL connected, but OPI0 is allowing only one channel alone, otherwise the board will crash horribly. The green status light glows a little bit then turn off and the board reboots. Seems like a bad short circuit or something. I tested LINEOUTR and LINEOUTL alone and both are working. So there's something wrong in the stereo configuration. - Audio loops were caused by bad settings on the alsamixer. Now I'm able to start playback in
  21. audio is continuing to work using only one channel. The audio will enter in loop when more than one ssh instance is created. If I create first ssh instance then start the music and leave this alone there's no problem. If I then connect with a second ssh I have audio loop. [update] from the attached imaged seems like we need some electronics to make this work? correct? I'm using a PAM8403
  22. I have the same issue but I'm not resolving. I'm not connecting left and right negative toghether. If I understood correctely and that was the issue there. I've negatives from speakers (left/right) connected separately on their negative. I've enabled analog-codec I can see the audio card but can't play sound but noise and then crash when attempt to start to play. [update] It works connecting the "LINEOUTL" pin only! Connecting even the LINEOUTR channel results in a kernel panic and reboot when you attempt to play something. Has anyone gon
  23. it's a super easy/normal uart communication and it just works following the datasheet protocol specification
  24. ok, the uart layeroverlay should be a good point to start with thank you