tao

Is this running legacy (and not mainline)? Also I noticed that the desktop video was shot on a banana pi m2 plus but the video title lists an orange pi. Have you run fb graphics for any significant amount of time on an orange pi? I ask because I've been getting errors (ktask timeout) after running a fb load on an orange pi zero.

Has anyone actually soldered onto these points to get the extra usb ports? I couldn't even see the points clearly without a magnifier so it's clearly out of my league. Love the idea, but a hobbyist has got to know their limitations.

I saw an indegoo campaign for the LicheePi Zero and was wondering if it'll be a useful board or chock-full-o-problems. It only has 64mbram, but may be useful if used in specific iot projects. I don't think it's available for purchase yet, but it may be soon. I would be interested in getting the add-on wifi component and driving a 2.4" tft lcd with this board.

I might have misrepresented the problem by naming the message printed on the console (ALSA). I suspect the problem might be related to fbftft. Looking at issues such as https://github.com/notro/fbtft/issues/413 If that's the case, it may be hard to fix running with the legacy kernel.

echo 0 > /proc/sys/kernel/hung_task_timeout_secs reduces the number of log messages, but the program still hangs. Not sure pygame is generating an ALSA error.

Are you running the graphical windows environment (X windows) on this display and you need to customize it to make it usable, or are you using the display as a text console and you'd like to get more text on the screen?

I have an orange pi one running armbian 5.25 with a 2.4" ili9341 TF LCD initialized with "modprobe fbtft_device custom name=fb_ili9341 gpios=reset:198,dc:199 speed=16000000 rotate=90 busnum=0". Most of the time, after running a pygame program for about 25 minutes I get the error below. Then, often about 10 minutes after the error message the program freezes. ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred I've seen the same thing happen with several programs. The program below usually creates the error. Running the same program on raspbian generates no errors so I don't think it's the code itself, but something in the environment. Here's dmesg info from the fb modprobe to just after the program freezes

I'd like to say that I appreciate the contributed work. It's easily overlooked and taken for granted, but it shouldn't. By the work of many others I get the opportunity to play with new, inexpensive, and fun alternatives to the rpi. And that is a hoot. I shop and buy new orange pis and neo pis with the confidence that armbian will work. And in those cases where there are issues I can ask my question here and not be mocked and shamed. For all the work, and for the forum to lean ... Thank you.

To clarify -- the Orange Pi Zero Plus 2 which has AP6212 for WiFi is much better than the WiFi on the Orange Pi Zero (which is bad even for us with low expectations). Would it be fair to say it will be good? Or would it be more accurate to say it'll be acceptable? If wifi is okay/good this is a nice looking board since it'll have wifi, Bluetooth, 8GB EMMC flash, and 512 MB RAM for ~ 19 USD. The csi camera interface is nice too but so far I haven't seen many good cameras that are compatible with the oranges (I really wish I could use my rpi cams on my oranges!).

Please keep adding workaround as you find them. I have a neo but have not done much with it. These tidbits will help me when I get back to it.

I found the wifi on the orange pi zero to be as bad as mentioned in various places in this forum. My needs and expectations were really low too. I was disappointed, I love the zero, except for it's wifi performance. I finally wound up sticking a usb dongle on the darn thing. Not what I wanted, but it works "okay". I'm glad I found armbian. It's a great distribution and lets me experiment with devices in all shapes, sizes, and cost. And I get it for free! Yeah, I wish the zero's wifi might work better, or work at all in your case, but hell, I love what these folks have done. And that leads me to my point -- the wifi on the zero is crap. Been said many times. I find it hard to consider the software a "major problem" when it doesn't have decent hardware to work with. Maybe you should leave a note on the Orange Pi forum asking them to improve their wifi hardware. I'm pretty sure the armbian crewe would make a decent wifi component live up to it's potential.

Oh, too bad. I'll have to move on to my next project now. For some reason I thought this was pretty cool idea. Thank you for verifying.

You're absolutely correct! USB-WiFi is quick, reliable, and well-proven. This is only for fun and learning.

I want to use an ESP-12F to add wireless to my NanoPi Neo, but I don't think the Neo has broken out all the connections I'd need. Hackaday desctibes how to interface a Raspberry Pi B+ to an ESP-12F (https://hackaday.io/project/8678/instructions), but the Neo seems to lack some of the required pins. I like this idea since I've liked the performance and ability of every esp8266 system I've used. Their wifi network is solid, and they're low cost. Is this a lost cause or is it possible? Or perhaps this is a dumb idea? I'm not sure how well it'll perform vs a usb wifi modules, but the idea has captured my imagination.

I suspect there might be issues with the startup configuration. I found this http://www.catb.org/gpsd/troubleshooting.html when googling; it has a good section on troubleshooting startup issues. You might need to create some startup files, but the link includes the required details.

To see permissions type 'ls -al /dev | grep ttyS2' in a term window. After thinking about this, I'm not sure if this is contributing to your problem, but I mentioned it since it caused me problems about 10 years ago with gpsd. In those days there were two things that frequently contributed to startup problems; permissions, and not fully defined paths for executables (scripts on boot don't benefit from your shell environment, so they have to be told the location of executables. don't assume it's location is obvious or automatic). Last time I looked, gpsd logged a lot of information, so look at the log files for clues. Reboot your system and then look at the gpsd entries in syslog and messages that have a timestamp associated with the reboot. grep -i gpsd /var/log/syslog and grep -i gpsd /var/log/messages -- there should be entries for gpsd that will help identify the problem.

What are the permissions on /dev/ttyS2?

I'd like to pretend the following didn't happen, but it's important to admit when responsible for dumb things. You hit it on the mark. I didn't make the radio number unique. Changed the following value for each radio, and now they communicate like champs. /********** User Config *********/ // Assign a unique identifier for this node, 0 or 1 bool radioNumber = 0; Thank you for your help. I'm completely new to the RF24 world so I've spent a lot of time messing around. I hope to make a network of sensors and wanted to use my orange pi one as the gateway. And this was the first step.

I have two identical setups, both on my desk. I'm not sure what you mean by registers dumps, but in case that data is included in the details printed by gettingstarted I've included that information below. orange pi one #1 (rx mode) ./gettingstarted RF24/examples/GettingStarted/ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xe7e7e7e7e7 0xc2c2c2c2c2 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0xe7e7e7e7e7 RX_PW_P0-6 = 0x00 0x00 0x00 0x00 0x00 0x00 EN_AA = 0x3fE N_RXADDR = 0x03 RF_CH = 0x4c RF_SETUP = 0x01 CONFIG = 0x0e DYNPD/FEATURE = 0x00 0x00Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bitsPA Power = PA_MIN ************ Role Setup *********** Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit) >0 Role: Pong Back, awaiting transmission orange pi one #2 (tx mode) ./gettingstarted RF24/examples/GettingStarted/ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0x65646f4e32 0x65646f4e31 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0x65646f4e32 RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00 EN_AA = 0x3f EN_RXADDR = 0x02 RF_CH = 0x4c RF_SETUP = 0x01 CONFIG = 0x0e DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bitsPA Power = PA_MIN ************ Role Setup *********** Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit) >1 Role: Ping Out, starting transmission Now sending... failed. Failed, response timed out. Now sending... failed. Failed, response timed out.

I added a 0.1uF cap across VCC and GND on the top of the nrf24l01. I also added code to lower the transmit power right after radio.begin. // Setup and configure rf radio radio.begin(); radio.setPALevel(RF24_PA_MIN); Selecting 1 for ping_out with gettingstarted still fails: Now sending... failed. Failed, response timed out. Now sending... failed. Failed, response timed out. I've attached a picture of the soldered cap across VCC and GNC on top of the nrf24l01. I know ... I was a liberal arts major and have been working to improve my soldering skills bit by bit but I have a lot of room for improvement.

Great ideas. I'll try that tonight and report to the forum the results.

I'm trying to get an nrf24l01 radio to work on my Orange Pi One but have not been successful. I'll document what I've done here. If you spot an error, please let me know. Start with fresh Armbian_5.20_Orangepione_Debian_jessie_3.4.112 image. Then apt-date update and apt-get upgrade. Attached nrf24l01 like this (pictures of header and radio are attached for verification); nrf24l01 color opo pin opo fn 1 GND blk 25 ground 2 VCC red 17 3v3 3 CE org 29 PA7 4 CSN ylw 24 CS0 (SPI-CE0) 5 SCK grn 23 SCLK 6 MOSI blu 19 MOSI 7 MISO mag 21 MISO 8 IRQ n/c git clone https://github.com/TMRh20/RF24 cd RF24 ./configure make make install cd examples_linux edit gettingstarted.cpp comment line 49 RF24 radio(22,0); add line 70 RF24 radio(7,0); diff gettingstarted.cpp gettingstarted.cpp.orig 49c49 < // RF24 radio(22,0); --- > RF24 radio(22,0); 70d69 < RF24 radio(7,0); make gettingstarted run gettingstarted ./gettingstarted ./gettingstartedRF24/examples/GettingStarted/ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0x65646f4e32 0x65646f4e31 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0x65646f4e32 RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00 EN_AA = 0x3f EN_RXADDR = 0x02 RF_CH = 0x4c RF_SETUP = 0x07 CONFIG = 0x0e DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_MAX ************ Role Setup *********** Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit) >1 Role: Ping Out, starting transmission Now sending...failed. Failed, response timed out. Now sending...failed. Failed, response timed out. Now sending...failed. Failed, response timed out. I'm certain I'm making a fundamental error but I cannot see it yet. The initial details printed by the program make me think it's found the radio and can interact, but it stays in a sending...failed loop until stopped. The armbianmonitor -u for the system is http://sprunge.us/QVhS

It sounds like you might have it behaving the way you want, so all is well. But, if it happens again I go with the suggestion already mentioned before and look at the entire arp cache (arp -a). If there's an unusual entry affecting behavior you might be able to delete it with arp -d. Also, I'm a strong opponent of network manager. Damn thing is a nuisance and keeps resetting things I manually set like resolv.conf.

That's a cool project. I didn't see reference to the screen you used. Is it obvious and I missed it? If so, I apologize. If not, then what is it? Thanks for the pointer. My going in position is to use legacy and let the other mature a little more. I'll be having enough problems with my code to worry about the operating system. I'd like to jump up from legacy asap, but not prematurely. And if anyone has experience with specific displays, good and bad, please let me know. I would hate buying and working on a screen that has proved to be a dead-end for someone else. Send me a private message if you don't want to post in public, but I prefer a post here so everyone can benefit from the experience.

Looking for recommended LCD screens for NanoPi Neo and Orange Pi Zero. I have some IoT ideas I want to explore. Does not have to be touch, and I'm pretty flexible on screen size. Actually, would like a couple of different screen sizes but bigger than an 128x64 OLED (I have that). Must be color. At least 320x240, preferably something 320x480. I just got two Orange Pi Zero systems today and want to create a couple of IoT devices along with the two NanoPi Neo systems I got recently. Performance does NOT have to be ideal, just reasonable (not going to game on it or watch action movies). The Zero means HDMI is not an option; given that, what interface is best - SPI? Cost is a factor, I would like to be, shall we say, frugal? But I don't mind paying more for the first item from amazon that I could have in hand quickly with additional orders from aliexpress (I can get a lot of development time in with one system while aliexpress puts other items in the slow delivery queue). I'd like to use python, but could use C. I'm mainly interested in a smart approach; a path in which I can search for answers and solve problems with time and effort. It would help if I used an established or reliable library for development. I'll have enough problems with my own code to worry about the libraries. So, please, tell me what has worked for you. What have you done that you would avoid like the plague now. If it were you, what would you do? I'd really like any suggestions or war stories. If you can be constructive, I want to hear it.