arox

Members
  • Content Count

    319
  • Joined

  • Last visited

About arox

  • Rank
    Embedded member

Profile Information

  • Location
    France
  • Interests
    IoT

Recent Profile Visitors

1938 profile views
  1. Basically in 99.99% use case you can configure wifi with wpa_passphrase <your-ssid> <your-passphrase> | wpa_supplicant -B -i wlan0 -c /dev/stdin ifconfig wlan0 <your-ip> netmask <your-netmask> route add default gw <your-router-address> echo "nameserver 8.8.8.8" > /etc/resolv.conf in some old very-deprecated rc startup file. And remove nm ifup zeroconf dhcpd ... and other "wonderfull dynamic modern" automatic bug generators ...
  2. The board is gone to the bin ... I already try 4.4.180. Last, I tryed ayufan strech version from pine.org links : constant reboot ! Very frustrating ! From now on, never anyone of those buggy hardware anymore : raspberry or espressif. Thanks and bye at everybody !
  3. Armbian_5.88_Rock64_Debian_stretch_default_4.4.180.7z Armbian_5.75_Rock64_Debian_stretch_default_4.4.174.7z LibreELEC-RK3328.arm-9.1.001-rock64.img.gz Armbian_5.88_Rock64_Ubuntu_bionic_default_4.4.180.7z Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182.7z The last one "seemed" a bit more stable but freezed and needed reset for rebooting and finally it crashed with mundane stack dump. One symptom is that after a crash, or just a shutdown, the board enter an endless loop of panic at startup - needs reset? or cool down? or unplug/discharge? I even cannot find a safe method to restart the board !
  4. Hello, I received a Rock64 board 2G two days ago and suffered the most impressive failure ever : panic, freeze, failed restart, segfault ... I tried all I was able 2 think off : 3 different PSU, 3 SD card and an USB drive, 3 armbian version (and the last from yesterday) and an openelec image ... Someone got an idea - an old kernel ? - or should I consider the board defective and throw it away ? The board was sold by "ameridroid" and is labeled :ROCK64_V2.0 2017-0713 (Quite old no ...)
  5. Well, I recently "repaired" my digital camera by cleaning contacts with methylated spirit (alcohol). Next time I got a problem on a SBC, I'll try that first ... (And solder if I can !) And anyway only buy connectors with golden contact anymore !
  6. try : DISPLAY=:0 /usr/bin/vlc /home/orangepi/video.mp4
  7. I can decode HTSP from tvheadend with vlc on a pi zero at 1280x1024 but need something more powerfull for 1920x1080. (PI3B+ do the job so I think a PI3A+ would do). Can you give me some advice for small device that can do it ? Do you think a Rock64 could transcode DVD mpeg2 to h264 on the fly ?
  8. I never manage to have g_ether working with mainline kernel on H3 device. Last time, I thought I had it working with FA distro ... but only one end was receiving packets. So my nanopi -air is on the shelf and I use pi zero W (s).
  9. May come for bad addr to name resolution. Check your resolver.
  10. Maybe @igor could have a look because I think no external usb sound card can run ?
  11. Try : zcat /proc/config.gz | grep -i USB_AUDIO If you dont see CONFIG_SND_USB_AUDIO=m then I think you may need to recompile the kernel ...
  12. Can you see (lsmod) the kernel module 'snd_usb_audio'. (Try modprobe if not)
  13. I understand you use a bench or enterprise PSU with high amperage, voltage regulation and security ... So why should you be bothered by an 1,2 m USB cable ? Cant you use another cable, short and with big wires ? What I always asked myself is the resistivity of the contacts on micro USB and how much it can change from one plug to another or over time. I spent the day trying to fix my old audio amp and speakers (more than 20 years) : the potentimoeters are dead, the resistivity change with the charge (or when I adjust them) and so the sound is horrible. Imagine what happend to your board if some crappy contact do the same when the processor demand a power burst ! The response is that the board can crash anytime but more probably when doing heavy computation or accessing disk or network ...
  14. try : hciconfig hci0 up hcitool dev or hciconfig hci0 reset hciconfig hci0 up hcitool dev or ps -ef | grep hciattach if not present, respawn hciattach process (check command line after boot) then re-up hci0 there should be a gpio for hard reset but it depends on uboot, DT and kernel version ... How to restart bluetoothd depends on system and version. You may need to re-up hci0 after restarting bluetoothd and handle hciattach yourself before starting bluetoothd : because it is hardware dependant, it is always a dirty tweak in startup scripts ... You should provide some information about SBC, ap6212 rev, Armbian version, Bluez version, firmware version (downloaded by hciattach) ... So somebody may perhaps help ...
  15. I suppose that some manufacturer spare money by not registring an address. Nanopi air should anyway have one. For my part, what I donnot understand is the 115200 in hciattach command : AP62XX is a serial module, and all BT traffic is routed in HCI over serial communication link. So how could someone reach 3 Mb/s of data rate over a 115200 b/s line ?!?. I always change this for 1500000. Otherwise an a2dp link drop packets for example. Another funny thing is the usage of 11:xx...etc or 43:xx...etc addresses. By default the system load a BNEP module, but dont try to configure a NAP acces point with that : it will try to use the address as an ethernet address in BNEP emulation - and fail with bad reporting because an address with an even first byte is illegal for Ethernet. I use a Nanopi neo 4.14.14 kernel with btusb dongle to create ppp/rfcomm links. I previously used a Nanopi air or a BPIM2+ 3.4.17 kernel for BNEP links. With nanopis or bpi I crash the kernel every other day. So did you achieve some stability with that ? Anyway, with BR/EDR mode and bluez, I need to reset the controller periodicaly because it became anable to create basic link (ACL) after some time when forming multiple piconet. So I also experiment with BLE. I tested Bluepy - wich can handle "central" (but not peripheral) role in python. But I doubt to achieve stability and low latency in connected mode. So I am now developping my own trivial mesh protocol by advertising/scanning transmission with gatt/paypal in golang on RPI (and chip with some tweak in scan report demux) ... I didnt try bleno/noble. It seems to shunt BLUEZ insane routing through dbus/xml unstable/undocumented messaging API (as do also gatt/paypal) and handle itself the HCI interface. I am not sure about the difference in socket interface in both implementation ? I am not sure of the role of 4343A0.hcd or so files downloaded by hciattach. If this is the firmware for BT controller, there certainly is a lot of bugs in this and we need more robust version ?