arox

Members
  • Content Count

    313
  • Joined

  • Last visited


Reputation Activity

  1. Like
    arox reacted to nachoparker in Support of Raspberry Pi   
    Hi all,
     
    I wrote a blog post about some of the issues with the Raspberry Pi that you can find scattered around this and other forums. Hopefully it will save us time from repeating ourselves over and over again.
     
    As we know, people don't read the forums until it's too late.

    https://ownyourbits.com/2019/02/02/whats-wrong-with-the-raspberry-pi/
     
    Thanks tkaiser, I took a sample output from your vcgencmd script.
  2. Like
    arox reacted to tkaiser in What about Google Home   
    We're not talking about a development board that makes accessing the hardware and especially the boot process easy but a rather expensive surveillance device people buy for whatever bizarre reasons. The technical details are so f*cking boring that everyone who disassembles the spy tool to get access to this boring PCB IMO must be mad.  
     
    If someone wants to waste a lot of time please contribute to Armbian in a more sensible way instead of wasting your time on hardware not worth a look with a target audience (for Linux on this thing) that does not exist.
     
  3. Like
    arox got a reaction from Henrik Larsson in No bluetooth with AP6212a under 4.11 Mainline   
    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 ?
  4. Like
    arox reacted to Henrik Larsson in No bluetooth with AP6212a under 4.11 Mainline   
    I had the same problem with NanoPi Neo Air and bluetooth as mantabernd
     
    hciconfig -a  didn't show any device
    and hciattach timed out:
    hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 bcm43xx_init Initialization timed out.  
    The other replies here by Larry Bank and thc013 helped me solve it. 
     
    uname -a Linux nanopiair 4.14.52-sunxi #581 SMP Fri Jun 29 10:05:07 UTC 2018 armv7l armv7l armv7l GNU/Linux  
    I first used armbian-config to install BT support.
    Then I edited the /boot/armbianEnv.txt to add uart3 overlay and param_uart3_rtscts=1 to enable rts and cts.
    Since I was unsure if it was supposed to be uart1 or uart3 I looked at the schematic here and saw it was connected tu uart3: http://wiki.friendlyarm.com/wiki/images/9/98/NanoPi-NEO-Air-1608-Schematic.pdf
    My armbianEnv.txt:
    verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 param_uart3_rtscts=1 overlays=uart3 usbhost1 usbhost2 rootdev=UUID=91977eb8-39b7-4db4-ac8b-2eb075f6eef2 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    Then I edited /etc/default/ap6212 to change from ttyS1 to ttyS3:
    # # Default it is called to be uncertain wich MAC address the chipset has. # Therefore it is recommendable to set the MAC address manually. # This can be done by setting the variable MAC_ADDR with a chosen value. # If this variable is empty or not set the default 11:22:33:44:55:66 will be chosen. MAC_ADDR=43:29:B1:55:01:01 # PORT=ttyS3  
    After a restart I run these commands:
    # rfkill unblock all # echo "0" > /sys/class/rfkill/rfkill0/state # echo "1" > /sys/class/rfkill/rfkill0/state # echo " " > /dev/ttyS3 # devmem2 0x1f00060 b 1 # echo 205 > /sys/class/gpio/export # echo out > /sys/class/gpio/gpio205/direction # echo 0 > /sys/class/gpio/gpio205/value # echo 1 > /sys/class/gpio/gpio205/value # hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 # hciconfig hci0 up From the schematic I found that BT_RST_N is connected to GPIOG13. I didn't find any documentation (anyone know where it is?) saying which gpio number GPIOG13 maps to but I found that GPIOG11 maps to 203 ( http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air ).
     
    After running above commands hciconfig -a returns this:
    # hciconfig -a hci0: Type: Primary Bus: UART BD Address: 43:29:B1:55:01:01 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:983 acl:0 sco:0 events:46 errors:0 TX bytes:2719 acl:0 sco:0 commands:46 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'nanopiair' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x6a LMP Version: 4.0 (0x6) Subversion: 0x2209 Manufacturer: Broadcom Corporation (15)  
    The last step will be to add the script to /etc/init.d/ap6212-bluetooth (same as above but with the variables for port and mac_option) :
    rfkill unblock all echo "0" > /sys/class/rfkill/rfkill0/state echo "1" > /sys/class/rfkill/rfkill0/state echo " " > /dev/$PORT devmem2 0x1f00060 b 1 echo 205 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio205/direction echo 0 > /sys/class/gpio/gpio205/value echo 1 > /sys/class/gpio/gpio205/value sleep 0.1 hciattach /dev/$PORT bcm43xx 115200 flow bdaddr $MAC_OPTIONS hciconfig hci0 up  
  5. Like
    arox got a reaction from BreadLee in Problems with bluetooth on Armbian(Ubuntu 16.04 server)   
    You didn't tell what BT device you use and what usage you intend to do with BT.
     
    The BT chips on board (AP6212 for example) need an "hciattach" process - sometimes tricky with the init system. USB dongle need not.
     
    You probably will need a bluetoothd process (and check that it does not put your "hci0" device down). And then you will need the dbus running (and configured) -- even if BT is the only app needing that sort of thing on a "minimal system".
  6. Like
    arox reacted to TonyMac32 in Pi-factor cases   
    Had a little time to test this today, as expected, it's junk.  Being copper it moves heat quickly, having no real fins or the like it simply has nowhere to move it to.  It can handle "smoothing out" the heavy thermal loads, but it simply can't move enough heat.
  7. Like
    arox got a reaction from chwe in SD Card Clone does not work   
    If I understand well ... You fail to clone a Linux image with a Windows/Mac software and complain Linux is bad ?!?
     
    Linux is not user friendly very much (for beginners). It was from the start a unix derivative and a study project from a student. And SBC are not user friendly - and SBC other than RPI are even less. So what use complaining and why not instead buy a full Intel (tm) with Windows (tm) computer ?
     
    And if sofware for your SBC is not as good as expected, why not complain to the manufacturer which sell "development cards" and rely on "developper community" without helping them in return ?
  8. Like
    arox got a reaction from chwe in SD Card Clone does not work   
    If I understand well ... You fail to clone a Linux image with a Windows/Mac software and complain Linux is bad ?!?
     
    Linux is not user friendly very much (for beginners). It was from the start a unix derivative and a study project from a student. And SBC are not user friendly - and SBC other than RPI are even less. So what use complaining and why not instead buy a full Intel (tm) with Windows (tm) computer ?
     
    And if sofware for your SBC is not as good as expected, why not complain to the manufacturer which sell "development cards" and rely on "developper community" without helping them in return ?
  9. Like
    arox reacted to TonyMac32 in Banana Pi Zero   
    Right, my comment on eMMC is purely about reducing/removing interconnects, the primary failure point in most systems.  Speed is secondary in such embedded systems.  I would ideally use the SD card only for data storage, for instance data logging/etc.  
  10. Like
    arox reacted to tkaiser in Clone/backup bootable microsd card - make as small as possible image   
    Better use ddrescue for this (apt install gddrescue). Then to get an idea how much to shrink the partition one could mount /dev/loop0p1 (in case it's a single partition image -- better check /proc/partitions) and look at the output from 'df -k' then und umount the partition. And in case it's not about to create an image that gets burned directly after but to archive an image (compressed) then it's a good idea to mount the shrinked partition and zero out all empty space:
    dd if=/dev/zero of=/mnt/loop0p1/zeroes bs=1M || (sync ; rm /mnt/loop0p1/zeroes ; umount /mnt/loop0p1)  
     
    Why re-inventing the wheel? The way better alternative is /etc/init.d/resize2fs start. And cloning already existing installations is dangerous for a variety of reasons since you end up with same SSH keys on all devices and on some boards MAC addresses of Ethernet or Wi-Fi are stored in files below /etc (so you end up with duplicate MAC addresses in your network causing all sorts of 'funny' troubles).
     
    If anyone starts to think about cloning Armbian installations that were already booted (and ran /etc/init.d/firstrun therefore), it's strongly recommended to read and understand this script (except the useless do_firstrun_automated_user_configuration function). Since the best idea is to prepare the installation to clone in a way that on new boards both /etc/init.d/firstrun and /etc/init.d/resize2fs get started again (even if a full expand is not wanted, better shrink the partition before to an absolute minimum and use the documented tweaks to control resizing later)
  11. Like
    arox got a reaction from Jens Bauer in NAS on Banana Pi - need advice on power supply   
    I use a BPI M1 as file server. I use 2.5i disk because it doesn't need 12V, don't make noise, is less cumbersome ... and if I want better access time I use an SSD !
     
    So, in order to avoid problems, I power the disk directly, that is : not threw BPI and I power the BPI through the disk power connector. Soldering is not a problem : you can use screw terminals. But you need the connectors and be sure of your polarity !
     
    My experience with powering 5V boards and accessories is that you must avoid multiple connectors interfaces. Micro USB is not top, but USB-A is still worse and in fact there are very few connectors able to deliver peak power reliably on 5V. I use a PSUs with voltage adjustment capability and screw terminals and for a server, I use as little connectors as possible and I don't power accessories (USB or HDMI adapter) threw the board : only so were I able to solve stability problems.
     
    In fact, I have had so many problems that from now on I will only use soldering and screw terminals !
  12. Like
    arox reacted to tkaiser in New OPi Zero - Yet another high temperature issue...   
    Hmm... I fail to understand somehow. On OPiZ-3 temperature with thumb pressed on seems to decrease by 5°C from 63°C to 58°C (if it has been +60°C in reality the drop should be larger and it might hurt a bit). And on OPiZ-1 temp decreases from 44°C to 42°C while 'finger burns'?
     
    This 'thumb test' is always my first try to detect whether we're looking at numbers without meaning or not (over a year ago we had a situation with A20 boards reporting temperatures even below 0°C at an ambient temperature of ~25°C and when pressing the thumb on A20 temperature further decreased below 0°C which is a clear sign that these numbers are simply way off). So do OPiZ-2 and OPiZ-3 feel any different when you press your thumb on H3 there?
  13. Like
    arox reacted to tkaiser in New OPi Zero - Yet another high temperature issue...   
    Thumb test please: let 'armbianmonitor -m' run, then press your thumb for 15 seconds on H2+ and provide output from OPiZ-1 and OPiZ-3 (for both also 'armbianmonitor -u' output, at least '### cpuinfo' section!)
  14. Like
    arox reacted to Igor in Armbian / Debian vs Ubuntu - future versions?   
    Yes, we promote Ubuntu with a reason - Ubuntu Xenial has more recent and polished package base with less troubles than Debian Jessie. In desktop area we ran into enough troubles which lead to abandoning support for Debian desktop versions, while server remain fully supported. If there are no download options, you need to build it on your own.
     
    When Debian moves to Stretch, we plan to follow and situation will most likely turn in favour of Debian.
  15. Like
    arox reacted to martinayotte in AP6212 in Mainline   
    Now that I've done builds for NanoPiM1Plus2 and BananaPiM2Plus, along with the previous series OPiZeroPlus-H3/OPiZeroPlus-H5/OPiWin/OPiPrime, and that all of those boards has the same symptoms of missing AP6212 (+/- some have mmc-sdio appear, some not), I've continue my search for hints.
    To my discovery, I found the following quote in http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B
    I hope that is not true any more ...
  16. Like
    arox reacted to tkaiser in H3 board buyer's guide   
    H2+/H3/H5 boards overview (2017/03 update)
     
    Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
     
    I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
     
    While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
     
    CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
     
    In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
    NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
     
    NAS category (only due to Gigabit Ethernet available):
    Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
    NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
    Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
    The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!  
    And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
    Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur).  Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
     
    Hope that helps
     
    Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.
     
  17. Like
    arox reacted to jkajolin in DNS resolving   
    Just a note, on modern installations you don't ever manually configure the /etc/resolv.conf it is automatically maintained by other services. Plain openvpn installation don't do dns push lines unless you tweak them from the server side, the network manager plugin which is part of the gnome packages does this automatically while restarting whole networking.
     
    We have some amazon to datacenter bridges and even my soc installations are connected to datacenter network services by openvpn client. Most of the problems started when ubuntu started using network manager on desktop images but dns push routes took a lot off man hours to get them right. Currenlty I add manually the hostnames and don't rely on dns lookups.
     
  18. Like
    arox got a reaction from abramq in Have idea for nice project - but no one board is stable (loosing all my hope...)   
    In my experience, wifi has always be unreliable and a waste of power. I think there is some nonsense with wifi : you cannot have middle range and high bandwidth networks on an overcrowded frequency. What we need is what bluetooth should become : LE/AMP/mesh. LE stand for low energy : having the capacity to transmit small messages or rest in standby with very little power. AMP is the possibility to dynamically open a high bandwidth channel when needed. Mesh is the possibility to have a micro network of redundant nodes and links with short range / low power transmission, instead of interfering with others transmissions in wide areas as with wifi.
     
    Unfortunately, the specification for that has been more or less released. Which means that current implementation is a mess. In first versions, BT was supposed to be cheap (but reliable) technology for specific use cases ("profiles"). Now, adding LE/AMP/Mesh simply mean multiply complexity by 4.
     
    Nevertheless, at present you should be able to do wifi in ad hoc mode and use obex with bt ? I never tried wifi ad hoc and obex since bluez4. What are the problems ?
  19. Like
    arox reacted to Igor in Voltage Regulator 7805   
    LM2596 should be right for the job - it can cope with such loads and they are dirt cheap.
     
    https://www.aliexpress.com/wholesale?SearchText=LM2596
  20. Like
    arox reacted to Arda in [SOLVED] DNSCrypt doesn't work on Debian, but works on Ubuntu on Orange Pi Zero   
    Just saw your input, sorry I was at work. Today, I've tried both 1.9.2 and the 1.9.3 which are very recent versions released in this last 2 days, and I can confirm 1.9.3 fixed the issue on ARMBian Debian.
     
    The changelog has a line like this:
     
     
    I don't know if this was the reason, however one of the fixes pushed to release from 1.9.2 to 1.9.3 fixed it on ARMBian Debian (I wiped the SD card 2 times to double check).
     
    This thread can be marked as solved :-)
     
    Thanks for your time!
  21. Like
    arox got a reaction from KernelPanic in NanoPi NEO custom image boot error - failed to create pty   
    Do you have this in your kernel .config ?
     
    CONFIG_UNIX98_PTYS=y
  22. Like
    arox got a reaction from tkaiser in Banana Pi M2 Ultra   
    SINOVOIP which design Banana PI is a special case : it is the most distributed arm manufacturer. You (I in France) can purchase a board in many local sites. So their "costumers feedback" would be the best place to complain about the price, hardware and software bugs, and lack of support.
     
    The BPI M1 was worse the price, the other boards ... . So with the "m2 ultra", you just got a little more power for twice the price. Their marketing strategy and business model is not much encouraging to invest time or money both for users or for developers !
  23. Like
    arox got a reaction from rodolfo in do I need a display   
    I think response to broadcast ping may have been disable (for security reason ?). I didn't manage to use it for a long time.
     
    Please don't back up people that try to port "blue screen" technology on linux. I have seen the funniest things on network with appletalk 3 level physical/logical/service paradigm (access to wrong printer) and Microsoft abuse of layer 3 broadcast helpers (broadcast storm propagated threw the WAN). Microsoft programmers are not bad : bad choices are made upstream to offer functionality with little concern to security.
     
    Automatic configuration of address is of no use : you have to choose a unique name anyway. You could as well use a fixed well known local ip address and force user to change it a first connection - as it is done for root password.
  24. Like
    arox got a reaction from manuti in USB Bluetooth dongle for Orange Pi Lite / Zero   
    https://www.reichelt.de/Bluetooth/LOGILINK-BT0015A/3/index.html?ACTION=3&GROUPID=5844&ARTICLE=170030&OFFSET=16&SID=96WDwXhKwQATMAAHrYxKs8aa7eb3331164bb14def41b33191fbf3&LANGUAGE=EN
     
    I used this one this a RPI. I just have ported my a2dp server on bluez5/pulseaudio/nanopi air (internal BT chip)
     
    - compatibility depends on bluez (and btusb kernel module) and not on board or distro, if customers report it works with "linux" or "ubuntu", then you will be able to have it working.
    - better use a class I dongle if you want a good range - but you will anyway hardly reach more than a few meters because a2dp device are generally class II
    - even better use a nanopi air : with eMMC and internal BT chip, you get the same price than an $8 board with crappy SD card and crappy dongle. Without antenna (not provided) this board is unusable, but with an IPX cheap antenna you get as good a range than with class I dongle for that usage.
    - be aware that with bluez5, you need pulseaudio, you can only use one BT sink at a time and you need workarounds to handle bugs in (pulse, bluez, dbus), workarounds that may depend on device specific profile connection management.
  25. Like
    arox got a reaction from gnasch in Pulseaudio status in Armbian, H3   
    Well, I eventually got it working :
     
    - first I also forgot to signal I had change : "ControllerMode = bredr" in /etc/bluetooth/main.conf (not sure it is necessary)
    - second in /etc/init.d/ap6212-bluetooth, in hciattach command the serial speed is at 115200 and fex/uboot param don't seem to be relevant. I had to put it at 1500000, otherwise the daemon drops furiously samples.
    - and the major problem :
     
    The sink is by default connected to the headset profile at 8KHz mono (and it seems it doesn't work). You need to change it :
     
    - pactl set-card-profile <num> a2dp_sink
     
    <num> has to be retrieve with : pactl list cards (and it changes constantly !)
     
    But there is there also a bug : the next time the daemon will fail to reconnect the (recorded) profile and you will need to reset the "headset" profile, reconnect and reset a2dp : pactl set-card-profile <num> headset_head_unit + stop/start the device + pactl set-card-profile <num> a2dp_sink
     
    (The web is full of advises on people that explain that in normal mode with graphical interface, they need to alternate between profiles and restart the device before they can connect a2dp)
     
    I will now look if I manage to get the AVRCP profile connected threw uinput in order to read next/back commands.
     
    I end my comments here as it seems nobody is interested in BT on armbian.
     
    PS: second device, other problem ...
     
    It seems this one does not have his audio profile automatically connected. So if the device fail to be recognized by pulse or if it refuses to switch profile (with set-card-profile), try a connect <addr> with bluetoothctl ...
     
    PS2: workaround
     
    It seems profile selection bug is well knows (but not corrected in pulseaudio 8). After many tests, I think that the better solution is to NOT load the "module-card-restore" module. Otherwise, this module will reset the ad2p profile and bluez module fall in bugs and race conditions. So the workaround become :
    - disable module module-card-restore
    - monitor dbus events
    - on base [device] connection event, force connection by bluetoothctl connect, in order to connect audio profile (if device does not do that itself)
    - on audio [media] connection event, switch profile to a2dp
    - on [transport active] event start playback
     
    There are other bug that may need to be handled, but with the method described above, I can get a fast clean working server.
     
    Of course I think that this is only relevant for one version of (pulse, bluetooth, dbus)