NanoPI NEO / AIR

[idubnori]

Ralink MT7601U dongle (USB ID 148f:7601) does not work on the latest lagacy / 4.9 image?

 

I've made each image by manually, and tried it.

On legacy, kernel panic occured. On 4.9 (might a mainline),  dmesg said a failed.

Also, I tried this steps, but a kernel panic occured.

 

Does anyone have a same reproduction result or solution for it?

 

Thank you in advance for this great project

 

I've found out a build error on "/out/debug/compilation.log", while building a latest image for NanoPi NEO.

Is it related to this issue? 

Can't read file /home/pi/sources/mt7601/src/mcu/bin/MT7601.bin 

Makefile:330: recipe for target 'build_tools' failed

make: *** [build_tools] Error 255

make: *** Waiting for unfinished jobs....

/home/pi/sources/mt7601/src/os/linux/../../sta/sync.c: In function ‘PeerBeacon’:

/home/pi/sources/mt7601/src/os/linux/../../sta/sync.c:2182:12: warning: passing argument 8 of ‘StaAddMacTableEntry’ from incompatible pointer type [-Wincompatible-pointer-types]

            &ie_list,

            ^

In file included from /home/pi/sources/mt7601/src/include/rt_config.h:59:0,

                 from /home/pi/sources/mt7601/src/os/linux/../../sta/sync.c:28:

/home/pi/sources/mt7601/src/include/rtmp.h:7892:9: note: expected ‘IE_LISTS * {aka struct _IE_lists *}’ but argument is of type ‘BCN_IE_LIST ** {aka struct _bcn_ie_list **}’

 BOOLEAN StaAddMacTableEntry(


......

[Guillaume Faye]

Hello, i have a project to buy nanopi air, i read  previously post and see the flash emmc over usb/seriable cable.

But is it possible to boot nanopi from sd card and use after nand-sata-install script, like i do with my opipc+?

so is it possible to use nanopi air armbian image like with other board (opi......)?

[arox]

Hello, i have a project to buy nanopi air, i read  previously post and see the flash emmc over usb/seriable cable.

But is it possible to boot nanopi from sd card and use after nand-sata-install script, like i do with my opipc+?

so is it possible to use nanopi air armbian image like with other board (opi......)

 

Your system will boot from sd card (if you install the right image). The problem is just that you need to configure the network or know how to log in. (You can even boot from pre-installed FA system). You also could edit the sd card before boot if you know what you are doing.

 

The problem is simply that if you aren't familiar with a method : (install flash software, use a usb cable, edit config in text files ...), you will probably run into troubles. And then you will need to connect a serial console to see what happens. And with nanopi air, you need to solder 3 pins on board !

 

You already made a mistake : you don't use a "usb/serial" cable to flash but a usb cable with micro usb to usb-A. If you posses such a cable and are sure it can handle data (not just a power cable), then this is your solution : boot with install armbian image on SD card, cable plugged on usb-A on opipc+ and micro-usb on nanopi air. It will provide power as the nanopi air don't need more than 200 mA, the card will boot, you will be able to connect with "screen /dev/ttyAMA0" and configure wifi with nmtui - that will work only if you find an aerial (not provided by FA). And when you are satisfied with config, use nand-sata-install to transfer system on eMMC.

[Guillaume Faye]

Many thanks for your reply, soldering isn't a problem for me , but i have micro usb/ usbA cable to and i will test boot from sd and use nmtui (i have aerial).

[StuxNet]

I've been talking with Yuefi over at FriendlyArm and he has informed me that audio over bluetooth lacks hardware, and as result, software support on the NanoPi Neo Air. The only thing you can do with the bluetooth is transfer files. Effectively making the Bluetooth useless IMO. Since those speeds are agonizingly slow, especially when you have several more efficient methods of transferring files. WiFi, Samba, ProFTPd, SDCard, etc...

Maybe, I can see someone using/preferring the bluetooth to send small bits of info to another device that's acts as a switch in the I.O.T, which is probably what FA was getting at. However that implies you have another bluetooth transceiver in the chain (redundancy?) so again, this is something I would personally use WiFi for. Mainly, the way the board is being advertised and talked about makes it seem like it has bluetooth compatibility in the typical sense that you would expect (ie: speakers, headphones, etc...) but it doesn't. I just wanted that info to materialize somewhere. Here's Yuefi's quote:

 

 

 

Neither our hardware nor our software supports it.

The H3 chip supports it but our design doesn't.

 

Hardware wise you need to connect I2S to AP6212 and software wise you need to debug the driver

 

Best Regards

Yuefei

[arox]

I've been talking with Yuefi over at FriendlyArm and he has informed me that audio over bluetooth lacks hardware, and as result, software support on the NanoPi Neo Air. The only thing you can do with the bluetooth is transfer files. Effectively making the Bluetooth useless IMO. Since those speeds are agonizingly slow, especially when you have several more efficient methods of transferring files. WiFi, Samba, ProFTPd, SDCard, etc...

 

Maybe, I can see someone using/preferring the bluetooth to send small bits of info to another device that's acts as a switch in the I.O.T, which is probably what FA was getting at. However that implies you have another bluetooth transceiver in the chain (redundancy?) so again, this is something I would personally use WiFi for. Mainly, the way the board is being advertised and talked about makes it seem like it has bluetooth compatibility in the typical sense that you would expect (ie: speakers, headphones, etc...) but it doesn't. I just wanted that info to materialize somewhere. Here's Yuefi's quote:

 

?!?

 

I have 6 arm machines connected to net threw Bluetooth at Home and nanopi air is perhaps the one that works at best (once have connected an antenna). It is my a2dp audio server. (You simply need to check the serial speed of hciattach command in /etc/init.d/ap6212)

 

SFAIK, I2S on AP6212 is only there because the chip can also do FM radio reception)

 

"However that implies you have another bluetooth transceiver in the chain (redundancy?)" ?!?

 

With BT, you can transfer file with a special ftp-like protocol named obex. And you can also do ethernet emulation with BNEP. The first is peer to peer, the second can be use as wifi in ad-hoc or infrastructure - PANU/NAP or GN in BT terminology. The fact is that bluez is a mess (but if I say one tenth of what I think of bluez maintainers and the way the distribution providers handle the problem, I will be accused of scandalous developer bashing one more time).

 

So I think  PANU (ad-hoc or peer to peer mode) don't work or does not have support in bluez. But anyway who use ad-hoc mode in wifi ? If you want to do IP over BT, you set up an access point node - probably the same that you use for wifi as the boards use combined wifi bt chips. The access point create a BNEP interface that needs to be bridged with another interface - it is the standard definition of NAP profile. And you can have 7 nodes that do IP with your AP.

 

The only problem is that you don't have 2 bluez versions that works the same way, that it also depends on dbus and the forums are full of desperate people exchanging tips explaining to make modifications in config files that don't exist anymore for years ! You need to make dbus call to establish connection but if you don't use Gnome, you have to use python "test scripts" that are placed in a different directory on each distro or version.

 

Nevertheless, I use BT to connect my remote hosts : I can almost reach 1 Mb/s rate, but what is much more important is that the rate is steady thanks to frequency hop technology which use the full 2.5 G band and is much more immune to interference. I can "apt-get" with about the same speed with BT than with a Gigabit LAN connection. Of course, IP over bluetooth is quiet usable if you are using shell. If you use "experience impoving" technologies that transfer a lot of data for nothing, forget it.

 

P.S. very few people seems to have realized that BT hardware address prefix used by Ampak is not compatible with Ethernet. If you don't change it, the BNEP address will be configured with it, never be allowed to be uped, generate an obscure error message lost in dbus and the interface will be destroyed with a even more obscure message reported threw dbus and bluetoothd ...

[zador.blood.stained]

SFAIK, I2S on AP6212 is only there because the chip can also do FM radio reception)

AFAIK and according to specifications and datasheet, PCM/I2S can be used for BT audio or voice profiles too on these (AP6210/AP6212) modules.

[arox]

AFAIK and according to specifications and datasheet, PCM/I2S can be used for BT audio or voice profiles too on these (AP6210/AP6212) modules.

 

It can only make a sense to make a bluetooth a2dp sink - and you can purchase such a device for a quarter of the price of a nanopi neo. And forget about voice profile in current bluez version ...

[zador.blood.stained]

It can only make a sense to make a bluetooth a2dp sink - and you can purchase such a device for a quarter of the price of a nanopi neo. And forget about voice profile in current bluez version ...

Yeah, BT software situation is a mess, I'm just referring to hardware - i.e. on cubietruck I2S/PCM is wired from SoC to AP6210 module.

[StuxNet]

?!?

 

I have 6 arm machines connected to net threw Bluetooth at Home and nanopi air is perhaps the one that works at best (once have connected an antenna). It is my a2dp audio server. (You simply need to check the serial speed of hciattach command in /etc/init.d/ap6212)

 

SFAIK, I2S on AP6212 is only there because the chip can also do FM radio reception)

Thanks for the info on bluetooth transferring? Just to clarify, I'm not at all interested in using nano pi neo air as a bluetooth device for transferring files or IP over BT, partially because it's not my forte and I'll stick to what I know for now, but thanks nonetheless even if I don't understand most of it As for "?!?!?". Sure... for reasons mentioned previously, I'm just going off of my personal knowledge, preferences and am more than willing to admit that I'm not a novice but also don't know everything.

 

I'm fully aware of the AP Mode offered by the FA kernel and have my own custom setup using bash/python to turn AP Mode on/off depending on if a known wifi signal is in range. Anyways, that's besides the point. Honestly, I'm just trying to squeeze the most out of this little guy and a bluetooth A2DP audio server would be a nice addition. Like you mentioned you're currently using it as. If you'd be so kind, can you give me a little more info, in how to get that working?

 

~ Are you running Armbian or the FA kernel? I'm using FriendlyArm since last time I checked Armbian still (and likely wont) support the AP Mode offered by FA kernel. I assume you're running Armbian since `/etc/init.d/ap6212` doesn't exist in FA.

 

~ If your using it as a A2DP audio server on the FA kernel, FriendlyArm support is simply wrong in regards to audio over bluetooth?

~ Any tutorials or walkthroughs you can link me to? As far as getting my own A2DP audio server up and running?

 

Appreciate it.

[tkaiser]

Are you running Armbian or the FA kernel? I'm using FriendlyArm since last time I checked Armbian still (and likely wont) support the AP Mode offered by FA kernel.

What's wrong with op_mode=2 (when loading the module or maybe also accessible through sysfs)?

[tkaiser]

still trying to figure out whether there's a way for nm to connect to hidden ssid automatically

You can't hide a ssid. That's just fooling yourself.

[rjbrown99]

What's wrong with op_mode=2 (when loading the module or maybe also accessible through sysfs)?

 

One of my use cases, and why I'm interested in the 4.x kernel, is virtualizing the wifi NIC so it supports 2 virtual interfaces - one that acts as an AP and one that acts as a client. That way I could use an NPN Air as a portable travel router/firewall (my devices connect to the AP interface, the client interface connects to a hotel wifi for example). From my reading, the 3.x kernel with op_mode=2 is a 'driver-wide' setting, meaning everything is either in AP mode or it's not. Correct me if I'm off here.

 

One of my Bluetooth use cases was as a portable Amazon Echo, which would require Bluetooth audio to pair to an external speaker/mic. But if that's not supported in hardware I'm out of luck with that idea as well.

[arox]

One of my Bluetooth use cases was as a portable Amazon Echo, which would require Bluetooth audio to pair to an external speaker/mic. But if that's not supported in hardware I'm out of luck with that idea as well.

 

It is not a hardware problem : to connect a mic, you need HFP/HSP (the telephony profiles). With bluez5, developers simply remove support for it :

 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757731

 

So complain to debian (the "most stable distro" ... which accept regression in software and don't provide bluez4 package anymore. Or install gentoo :ph34r:       

[rjbrown99]

It is not a hardware problem : to connect a mic, you need HFP/HSP (the telephony profiles). With bluez5, developers simply remove support for it :

 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757731

 

So complain to debian (the "most stable distro" ... which accept regression in software and don't provide bluez4 package anymore. Or install gentoo :ph34r:     

 

Thanks for the reply. Quoting StuxNet above: "I've been talking with Yuefi over at FriendlyArm and he has informed me that audio over bluetooth lacks hardware, and as result, software support on the NanoPi Neo Air. The only thing you can do with the bluetooth is transfer files. "

 

If I understand that statement, the actual Bluetooth hardware itself on the NPN Air is not wired in such a way to have any BT audio support. Even if bluez supported HFP/HSP it still would not work on this particular device, correct?

[arox]

If I understand that statement, the actual Bluetooth hardware itself on the NPN Air is not wired in such a way to have any BT audio support. Even if bluez supported HFP/HSP it still would not work on this particular device, correct?

 

Well, maybe the ap6212 is able to handle SCO and audio profiles in firmware ? Don't know. But bluez should be able to handle the SCO layer (synchronous communication) in the kernel and the Telephony profile in user space.

 

http://i2.wp.com/opensourceforu.com/wp-content/uploads/2015/04/Figure-33.jpg

 

Simply, bluez developer seems to consider bluetooth as a dependency of Gnome and that other Gnome software should handle profiles. Everything has to be passed threw dbus and with bluez5 you cannot anymore use alsa to do a2dp (compressed stereo audio). If you read bugs.debian post in previous message, you should see reference to ofono which is a telephony interface subsystem. But I don't know anything about it - apart that pulseaudio complain about it ;)

 

But I have a gentoo with bluez4 on eMMC on my nanopi air and I bet (but never check) that alsa can still use telephony profile with old version of bluetoothd with a serial controller like ap6212.

[arox]

 

~ Are you running Armbian or the FA kernel? I'm using FriendlyArm since last time I checked Armbian still (and likely wont) support the AP Mode offered by FA kernel. I assume you're running Armbian since `/etc/init.d/ap6212` doesn't exist in FA.

 

~ If your using it as a A2DP audio server on the FA kernel, FriendlyArm support is simply wrong in regards to audio over bluetooth?

~ Any tutorials or walkthroughs you can link me to? As far as getting my own A2DP audio server up and running?

 

 

"Bluez must be one of the best kept secrets in Linux"

http://www.lightofdawn.org/blog/?viewDetailed=00031

 

So, if you cannot even find an hci0 controller (type "hcitool dev") after booting your system ... change your system and install Armbian ! (It is probably just a 'hciattach' command missing in boot scripts, but why would you try to use a distro if you need to rewrite everything ?)

 

I kept an RPI with old bluez4 and raspbian software and later installed a BPI m2+ with an external USB BT dongle because I thought bluez5 and/or the ap6212 couldn't work. I was wrong : bluez is simply such a mess that even the distro maintainers aren't able to handle it ! And wifi is about the same : as tkaiser said, you just need to pass a param to driver to enable ap mode.

 

So I can give you all the step I used to config BT on Armbian, but it can be useful only if you use the same armbian kernel and the same bluez/dbus/pulseaudio versions.

[StuxNet]

So, if you cannot even find an hci0 controller (type "hcitool dev") after booting your system ... change your system and install Armbian ! (It is probably just a 'hciattach' command missing in boot scripts, but why would you try to use a distro if you need to rewrite everything ?)

 

So I can give you all the step I used to config BT on Armbian, but it can be useful only if you use the same armbian kernel and the same bluez/dbus/pulseaudio versions.

 

Thanks again for the info. As for using a different distro, believe me, I reluctantly installed FriendlyArm only because I apparently misunderstood tkaiser when he said the following in regards to, what I thought was, AP Mode. But was actually just Wi-Fi in general.

 

(Regarding state of Wi-Fi in Armbian please see https://github.com/i.../lib/issues/558. (Nothing will ever improve)

 

 

Anyways, I'm not necessarily "rewriting everything" by using FA so much as customizing the AP Mode triggering, when I mentioned Python/Bash scripts. ie: When at work, turn into client, connect to work group/wifi. When in car/on the go, turn into AccessPoint so I can connect via smart phone/laptop. When at home, connect to home network, samba share, minidlna, etc...

 

It's worth mentioning that I did try to port their APMode on/off script (namely `turn-wifi-into-apmode.sh`) to Armbian by both transferring their binaries and drivers to the corresponding folders in armbian, that didn't work. So I then tried to edit the same script, to utilize armbian's binaries and drivers, again with no luck. Admittedly, I didn't spend as much time on the work around as I usually do but the effort did glean some knowledge. Between that, being reminded/corrected about the `opmode=2` suggestion, I'll take another stab at it and see what I can do. Also, FA does use `opmode=2` in their script, it obviously uses different binaries though. (`fw_bcm43438a0.bin`)

 

So I can give you all the step I used to config BT on Armbian, but it can be useful only if you use the same armbian kernel and the same bluez/dbus/pulseaudio versions.

 

 

Totally understandable, which is why I asked about the steps you went about using in addition to the specs/distro your actually running. So I can both try it on a whim and altered respective to FA and Armbian distros.

If I can get the little guy to switch between APMode and as a client using Armbian, I'll drop FA in a heart beat. Thanks yall.

 

[rjbrown99]

@StuxNet I'm trying to do something similar but using a different approach. What I really want to do is this:

https://wiki.archlinux.org/index.php/software_access_point

 

See the "Wireless client and software AP with a single Wi-Fi device" section. The challenge is the 3.x kernel driver in Armbian requires that op_mode=2 setting and from everything I see that setting is driver-wide. I am working under the assumption that the 4.x kernel driver is not limited like that, so it could run both client+AP from the same wifi device - except I have not yet been successful in booting a 4.x kernel as it lacks OTG support now for console access.

 

For me it's for use as a pocket travel router, for you it might make it easier to switch modes by just bringing up and down client or AP virtual interfaces. 

[arox]

Thanks again for the info. As for using a different distro, believe me, I reluctantly installed FriendlyArm only because I apparently misunderstood tkaiser when he said the following in regards to, what I thought was, AP Mode. But was actually just Wi-Fi in general.

 

 

Anyways, I'm not necessarily "rewriting everything" by using FA so much as customizing the AP Mode triggering, when I mentioned Python/Bash scripts. ie: When at work, turn into client, connect to work group/wifi. When in car/on the go, turn into AccessPoint so I can connect via smart phone/laptop. When at home, connect to home network, samba share, minidlna, etc...

 

It's worth mentioning that I did try to port their APMode on/off script (namely `turn-wifi-into-apmode.sh`) to Armbian by both transferring their binaries and drivers to the corresponding folders in armbian, that didn't work. So I then tried to edit the same script, to utilize armbian's binaries and drivers, again with no luck. Admittedly, I didn't spend as much time on the work around as I usually do but the effort did glean some knowledge. Between that, being reminded/corrected about the `opmode=2` suggestion, I'll take another stab at it and see what I can do. Also, FA does use `opmode=2` in their script, it obviously uses different binaries though. (`fw_bcm43438a0.bin`)

 

 

Totally understandable, which is why I asked about the steps you went about using in addition to the specs/distro your actually running. So I can both try it on a whim and altered respective to FA and Armbian distros.

If I can get the little guy to switch between APMode and as a client using Armbian, I'll drop FA in a heart beat. Thanks yall.

 

 

About "rewriting" : you generally just need a few lines to make the things run smoothly. With "modern distro" the problem is much more removing what is not needed or wanted. As an example in my current Armbian image, bluetooth if available after boot. You have nothing to do because armbian folks add an init service to configure the ap6212. But ... if you restart it by the init script or by systemctl, it don't work anymore.

 

Why ! because the init system is overly complicated and they forgot to tweak something to put interface up again in this case. That is what I mean by rewriting is a lost of time : if it does not work out of the box, don't try to debug others' software ! So just for initializing the ap6212, you need 5 lines but you have to either :

 

- use armbian where it works "almost" (nothing to do, just check the speed) and signal a bug in case of bluetooth restart.

- rewrite/reorganize yourself all FA distro with changes in systemd and perhaps udev/dbus/xxxmanager

- disable all services, managers, helpers that interfere with your own few needed lines of config and place this lines in /etc/rc.local.

 

If you want to automate and make dynamic configs ... good luck - especially with network configurations. I have such a funny config for alternate use of BNEP and USB networking if someone loves headaches ...

 

About the steps : you just need to install pulseaudio with some bluez modules. But then you will have a "gnome subsystem" unable to function as "server", as it is designed for a GUI and with a lot of bugs depending of audio devices, version of kernel/bluez/pulseaudio/dbus ...

 

You need to run pulseaudio in "system mode" and use workarounds. In graphical usage, people click and reset their device until it works - for a server, you need to know what may turn bad. I have a server for armbian with quirks for 3 devices that behave differently, quirks to handle fast deconnect/reconnect race conditions, and provide navigation in playlists with the control buttons with audio feedback. But ... I ported it on a C.H.I.P.  with different bluez version (and kernel and probably  other parts) and it bugs ... because the workarounds are specific.

 

Look here if you want an idea : https://forum.armbian.com/index.php/topic/2872-pulseaudio-status-in-armbian-h3/

 

And it is WIP because I still need to handle :

- case of a webradio stream playing nothing : why don't I hear anything (because it works but there is nothing to hear : silly)

- case of multiple connect attempt with 2 devices : pulseaudio cannot handle this, but I manage to have devices blocked by bluez and have to unpair purge and repair to unblock - when the system not simply crash       

- some pulseaudio specific problems ...

[StuxNet]

...as it lacks OTG support now for console access.

 

For me it's for use as a pocket travel router, for you it might make it easier to switch modes by just bringing up and down client or AP virtual interfaces. 

 

That's exactly how I currently have it setup. https://github.com/BiTinerary/PocketServerPi/blob/master/switchAPMode/switchAPMode.py. It just switches the virtual interface depending on if it can connect to a remote host. Nothing to complex.

 

As far as your current setup goes, currently you've been able to get AP Mode running using Armbian 3.X? Correct? If so, switching that is more/less as simple as using sysfs, like...?

echo '/somePathToFirmware/ap6212/firmware.bin op_mode=2' > /sysfs/sumthin.conf

And then in regards to not being able to boot Armbian 4.X, you mention it lacks OTG support for console access. Does a USB to UART adapter work? I think I remember you posting that you had issues using it in the past but can't remember the specifics. I'll get a couple of SD Cards burned with Armbian, along with my custom FA going on the eMMC over the weekend and swap between each of them. Testing the op-mode=2 and OTG port/UART, while running some stuff by my electrical engineering buddy and let you know if I have any luck in regards to OTG or the dual Client/AP support. 

[rjbrown99]

That's exactly how I currently have it setup. https://github.com/BiTinerary/PocketServerPi/blob/master/switchAPMode/switchAPMode.py. It just switches the virtual interface depending on if it can connect to a remote host. Nothing to complex.

 

As far as your current setup goes, currently you've been able to get AP Mode running using Armbian 3.X? Correct? If so, switching that is more/less as simple as using sysfs, like...?

echo '/somePathToFirmware/ap6212/firmware.bin op_mode=2' > /sysfs/sumthin.conf

And then in regards to not being able to boot Armbian 4.X, you mention it lacks OTG support for console access. Does a USB to UART adapter work? I think I remember you posting that you had issues using it in the past but can't remember the specifics. I'll get a couple of SD Cards burned with Armbian, along with my custom FA going on the eMMC over the weekend and swap between each of them. Testing the op-mode=2 and OTG port/UART, while running some stuff by my electrical engineering buddy and let you know if I have any luck in regards to OTG or the dual Client/AP support. 

 

I stopped with the 3.x kernel as I'm 1) fairly sure AP mode will work with op_mode=2, and 2) I really want 2 virtual NICs so I can simultaneously do one client interface and one AP interface at the same time. 

 

@tkaiser describes the 4.x issue, basically the kernel works but USB OTG patches are not included. If you solder the console pins to the board you can get console that way but I have not done that yet. My next move is likely to be to solder the console pins, try to boot the 4.x kernel, see if I can get wifi working, and if so I'll rebuild a new 4.x image with the OTG patches manually merged.

 

But the Bluetooth audio thing is another hurdle, I was expecting to also use this as a 'traveling Amazon Echo' and I'd need working Bluetooth mic+speakers to do that. My backup plan is to try all of this with an Orange Pi Zero which is currently on order.

[arox]

I stopped with the 3.x kernel as I'm 1) fairly sure AP mode will work with op_mode=2, and 2) I really want 2 virtual NICs so I can simultaneously do one client interface and one AP interface at the same time. 

 

@tkaiser describes the 4.x issue, basically the kernel works but USB OTG patches are not included. If you solder the console pins to the board you can get console that way but I have not done that yet. My next move is likely to be to solder the console pins, try to boot the 4.x kernel, see if I can get wifi working, and if so I'll rebuild a new 4.x image with the OTG patches manually merged.

 

But the Bluetooth audio thing is another hurdle, I was expecting to also use this as a 'traveling Amazon Echo' and I'd need working Bluetooth mic+speakers to do that. My backup plan is to try all of this with an Orange Pi Zero which is currently on order.

 

BTW, C.H.I.P use a 4.4.13 kernel with gadget drivers in the kernel (not as modules). And serial and ether can be used simultaneously.  I have no idea whereas processor type import (CHIP use R8) but I bet armbian developers will manage to have it working soon.

 

But with Orange PI Zero, you will need an external controller for bluetooth.

[rjbrown99]

I have a CHIP, it lacks an SD card slot which I also would like for storage of music. I'm really going for the one-device-to-do-it-all approach and the NPN Air is the closest one so far that meets the needs. OPi Zero has a USB slot so I could add an external BT adapter that is still pretty small, although it's bigger than the NPN Air.

[arox]

I have a CHIP, it lacks an SD card slot which I also would like for storage of music. I'm really going for the one-device-to-do-it-all approach and the NPN Air is the closest one so far that meets the needs. OPi Zero has a USB slot so I could add an external BT adapter that is still pretty small, although it's bigger than the NPN Air.

 

Yes, I like very much the NPN air for its compact size, its flat design, its eMMC. What frightens me on CHIP is the NAND and alien ubi fs. And I cannot flash it at this time : no chrome or chromium browser (can chromium run now on BPI M1 without killing tabs all the time ?), and my "legacy" intel/ubuntu/64bits for cross compiling is in the basement because of the noise - not handy for fel boot.

 

I use it for IoT with what works "out of the box" (well, already needed to recompile kernel 2 times to add modules). Its form factor can also have advantages and I don't need storage. BT works quiet good with internal antenna : I was surprised that it can still keep a link at 6m from AP enclosed in a metal box.

[StuxNet]

I went back recently to give Armbian another crack at my custom setup on the NPNA, however I noticed two things. One, the downloaded kernel version has gone backwards. I downloaded the available Armbian .img about a month ago, debian. The download info was, Armbian_5.24_Nanopiair_Debian_jessie_3.4.113. The one I downloaded today was Armbian_5.20_Nanopiair_Debian_jessie_3.4.112.

 

What's up with the latest version, being a previous release? I get bugs, revisions, more stable release etc... I'm just confused because of the second thing.

 

When I try connecting to a WiFi signal using  sudo nmtui, it says sudo: nmtui: command not found. Now, nmtui was available in the 3.4.113 version from a month ago. Why isn't it now? I'm pretty sure I'm not but am I just missing something here?

 

I could just use the older downloads that I know have nmtui installed since I still have copies of the .zip/.img's. I'm just more or less curious wassup.

 

 

In the meantime, why doesn't the following one liner work for manually editing/creating the wpa_supplicant file?

 

echo -e 'ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev\nupdate_config=1\nnetwork={\n\t ssid="YOUR-WIFI-ESSID"\n\t psk="YOUR-WIFI-PASSWORD"\n}' >> /etc/wpa_supplicant/wpa_supplicant.conf

 

[zador.blood.stained]

The download info was, Armbian_5.24_Nanopiair_Debian_jessie_3.4.113. 

It was a nightly build

 

The one I downloaded today was Armbian_5.20_Nanopiair_Debian_jessie_3.4.112.

And this is what is available on the download page by default, should be upgradable with apt-get to Armbian release 5.23

[Eirik Nydal]

can i connect a camera: gc2035 to nano pi air?

[Heath Coleman]

How do i enable i2c on the nano pi , running the 4.7 kernel

[Thomas Pfeiffer]

How do i enable i2c on the nano pi , running the 4.7 kernel

 

As far as i remember, i just had to install the i2c-tools (and made i2c available for python as well).

Unfortunately, not all my i2c devices were recognized properly. So i use Friendlyarm's Ubuntu, where i2c works fine. (I used the same breadboard for both Armbian and Ubuntu, so it was not a hardware issue.)

apt-get install i2c-tools -y
apt-get install python-smbus -y