pfeerick

@prahjister Have you set up Avahi on that image? Just wondering if something like http://octoprint.local would work with your image, making IP addresses not necessary? Otherwise it's probably either setting a fixed address on your router, using (sudo) nmtui to configure the connection (assuming network manager is managing the connection) or some ugly /etc/network/interfaces edits.

@Yuan I can't say I'd agree with that voltage... I think it's a little too high. 5.3v is the highest I generally go at the power supply. Keeping in mine the USB spec tolerances of 4.75V-5-25V, so if the 5v rail is also providing the USB voltage (and it often does), you're in danger of pushing a higher voltage than what devices are expecting, unless you get enough of a voltage sag over the leads. Whether that is enough to blow up a USB device when you plug it in, I couldn't say as I haven't tested every device under the sun. However, I would expect it to shorten the live of some devices. What I would recommend is also measuring the voltage at the device, both with no load, and when the CPU is loaded, and making sure the voltage doesn't fall below 5.00v minimum, maybe even 5.10v, depending what it shoots back up to when not loaded.

That was what I was proposing... sort of. I fully understand due to different board configurations and architectures that board specific methodologies are too varied and complex, assuming all the information needed is exposed. I was thinking the cpuburn type task, coupled with a token, so that say if the system does that sort of power on b0rkage that after a couple of cycles it could let up and basically tell you your power system is broken. Because end-less boot loops aren't user friendly either. Part of the the change in thinking that is needed here is acceptance of the fact that a lot of people won't read the documentation, no matter how well it is written, unless they are forced to (or just plain want to). So making the system itself as robust as possible to the most common of issues should be a major goal. Those more technically inclined of us don't need that, we can just look at it and diagnose the problem, or perform a few 'simple' tests. Not the average joe though. That is what I intend it to look like. I'm just in the process (when I have the time and desire to go back to the post and do a bit more) of collecting what appear to be the more to the point threads, and then the short piece for the top. As you say... not them vs me.

Done. I had been avoiding this as I didn't want to edit the original post (in the new split thread) which was the only way I know of to contextualise the thread on this forum system. However, I've done that, and the new thread is here. I think I've pulled all the more board specific posts out, leaving this thread to focus on the proposal.

Sorry about that, I only just caught up with the thread, so I didn't many to reply to that before now. Hm... first boot checks? Do some basic 'has the user used a crappy or faulty SD card, or using unreliable power (i.e our old favorite microUSB with a phone charger) at first boot, and basically say... if you continue past here, don't come near the forum or expect support? And have a reminder as part of the MOTD of this flawed configuration? If that essentially what you are proposing, I second that. But I'm not part of the inner circle, so my vote probably doesn't count for anything! And as far as information regarding SD card issues and power issues, I have started work on two posts which will probably be merged into one and used for an announcement at the top of the board pages as a 'basic troubleshooting' methodology. It'll be a few days before I finish it, and get it how I want it though. So you're not alone in thinking this needs fixing, and I am working on it.

Sounds nice in principle, but I'm with Zador... Christmas tree clutter, and just makes things more confusing to newcomers, who are the ones who are the ones most likely to post stuff in the wrong place. Enough moderators who pay attention (duly slapped by Igor and Thomas) make this a relative non-issue. But please keep the suggestions coming!

I can relate to that... give me a wall of text and I go to sleep... or go looking for a better guide. MORE PICTURES! I need to clean up the other thread and use links instead of those weird embedded forum link things... that makes a relatively short post look download scary.

@Igor I like! Make it into 'have you tried this yet - using good power, using good power, engaging brain' and 'if you haven't already read them, here are the docs' post, and basically sticky it? And how would that tutorials thingy work? Sort of another section of of the site, but for tutorials?

My apologies on that last point... I fully deserved that... I keep thinking that the misleadingly named GPU is actually the GPU, instead of just the 3D accelerator. I'll stop there though, as this is getting away from the OT. I just wanted to bite that bullet publicly!

You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die. It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that :-/

Only adding this as I did look at it and 'fixed' the problem, which was indeed simply wrong pattern match, due to how ubuntu's free formats things different of recent times. However, I do agree with tkaiser, it isn't really needed, as linux is supposed to use 'free' memory for caching... unused memory isn't wasted! I just didn't like the broken stats! in /etc/rpimonitor/template Modified swap.conf is like this. Modified memory.conf is like this. I also added more stuff to my Allwinner_A64.conf file, which may or may not be the right filename, I might have renamed that in the process of cleaning stuff up. I added the GPU temps since the health monitor was doing that. Still need to go back and pull the PMIC temp and battery stuff in, and then update my script. It'll happen sometime soon.

Woohoo! Nice to know it will that easy... my chinglish android eEMMC install might die a sudden death now and be reborn with linux... after a backup, of course! I still find the android OS handy for usage as dumb TV box! This is the pinout document for the rock64 - hopefully it's all correct! The boot sequence on the RK3328 is external eMMC, SPI Nor Flash, SPI Nand Flash(not fitted to rock64), external SDMMC card, USB (FEL/OTG). So unfortunately eMMC before SD I hate to ruin my uptime of 1 day, 4:16, 2 users, load average: 0.00, 0.00, 0.00, but needs must. I usually use the eMMC jumpter to boot from the SD instead of the eMMC, but I just unplugged the eMMC, removed the jumper, and tried a clean boot of the rock64, and it's up again, so I'm not sure what's going in with yours not booting when you have the eMMC removed and not booting from the microSD. This is with the 2GB model. As far as the partition layout, mine (running 0.2.0) is:

And you wonder why the user couldn't be faulted for plugging in a 12v 2A PSU into a product that has a 5v 700ma requirements :-P I smell lots of burning boards and refunds in the air! Confusion to be had all around. You'd think they'd know better now... tkaiser is not to be messed with... listen to him or all hell will break loose... :-P And it's not like you're doing it to for fun or are sadistically inclined (much!)... you're just trying to tell them how stupid a mistake they're making before they can fix it and are committed on the production run and the mere mortal users (like me) get to enjoy the lemon and whinge at you lazy developers! Back to the OT, my insignificant *vote* is hell no... let them suffer :-P I like the idea of the board, but not the companies tactics. Boycott them FWIW until they see sense.

BDR is an understatement. You were jumping up and down a bit there now 'Charles', but still, they shouldn't be publicly talking about this sort of stuff if they're not willing to put up the numbers and performance data. And as you said, calling it open source is just a bad joke on the community... open source is not just creating a new repo on GitHub! Sheesh! I'm glad I never bought into the whole Banana board thing now... I stuck with the Raspberry Pi for all it's faults, and then deliberately went to the Orange Pi Zero know its faults thanks to the sunxi and Armbian documentation because of it's size and price. I certainly won't be recommending this or any other Banana board after seeing their level of support and foresight in involving the community so they don't screw up yet another (potentially) good idea/design.

Oops! I didn't spot that one either! Sorry @chwe ... better move it before Igor decides to cut our pay!!!

yours is absolutely neat comparted to mine at the moment... pine64, orange pi zeros, rock64... arduinos, meters, parts boxes, heatsinks, nrf24L01 project boards, led matrixes... all strewn across two desks... plus a laptop or two and a tablet in there somewhere! :-O

@Bubba I didn't say that, but I won't argue differently either! Good 'ol Dunning-Kruger... you just can't argue with it without proving the point!

As per this post and the downloads section of the Armbian site, some boards have been moved to WIP (Work In Progress) or EOS (End of Support). The only specific H5s I'm aware of, the Orange Pi Zero 2+ H5 and the Orange Pi PC2 are both WIP boards (although from a second glance at the downloads page, it looks like all but the pinebook are H5 boards), so post this commit from 28 days ago, you'll need to set the EXPERT flag to YES in order to show WIP boards. This was done to reduce the number of support requests when people have self-built WIP board images or downloaded the nightlies and subsequently complained that it didn't work properly, which is exactly the reason why it is a WIP!!!

@TonyMac32 We're not that far away from mainline support already... at least the first digit is a 4 instead a 3!! The rockchip folks have stated that they are committed to open source, and are working towards mainline support, so fingers crossed it happens. Making this board the (if not the, then one of) the best best linux supported SBCs for 2017 and with a reasonable hardware set?

I don't have any issue with any of the points raised in this thread so far. So, my 2 cents (or is it 5 cents?): Forum restructure - yes, "I" think is needed, as current three levels are restrictive. So break it out to development and tutorials at the least. Before we head down the tutorials on the forum approach though, we really do need to nail down if we do tutorial stuff on the forum, or on a wiki. If we stick with a forum approach, we could probably replicate the 'technical support' categories, to sort them, and then just standardise a layout... first post is always the updated tutorial, second might be links to other resources, something like that... Moderator presence - we're here only to keep the peace, keep stuff organised, play wack-a-mole with spammers and that's basically it. I'm a bit confused as to the context of tkaisers 'invisible', but my take is basically what he said - clean up any silly formatting - i.e. not using code blocks, moving stuff to where it belongs, and a friendly PM to the poster to let them know how to do it in future. Other than that, we're just regular users, and as long as we don't do what happened in the other forum which we all know about, things will get on just great! As far as deleting a 'support request' that hasn't had a reply for say 2 weeks, I dunno... what happens if the OP comes back to it after three weeks? Unless we get a whole bunch of them, and things start getting out of hand... they can stay. Some sort of pined post outlining how to start a support request would be good. It will never solve the increasingly worse problem of "I'm an expert - Google told me so!", but it will at least get it through to some posters that details do matter. We are not clairvoyant. So if you don't give us the information, like I jokingly said in a recent post, I will assume that you need to tell the hamster in the hamster well to run faster, as I honestly believe your board is powered by a hamster wheel turbine due to the amount of information you have provided. (Who around doesn't remember the old adage of crap in, crap out??) As far as cooling down, if you're thinking of the current Orange PC thread... we're far from needing that. The OP is being a little dim, which is understandable, since he is frustrated. However, it hasn't devolved to a slinging match yet, so we're not even near needing a timeout yet! But the desire to slap a warning on some people is so hard to resist at times (you know what I mean... the "how thick can you be" ones) ... it would be so hilarious if the forum has a commenting system that only the moderators/admins could see attached to forum posts...

I meant to mention - have you thought of trying the reverse? You keep trying to ping your Orange Pi zero, which appears to be 192.168.1.40. What is the device at 192.168.1.1 you're trying to ping? Your router? your laptop? If it isn't, try pinging your laptops IP... if the Orange Pi Zero can't see it... then how do you expect to be able to ssh into your orange pi zero? One of the major problems here is that you only give us part of the information, and we have to guess the rest. We aren't clairvoyant... we don't know what testing and knowledge you do have. We're just ordinary guys and gals who want to help other people. Look at this image (which I googled) and see what voltage you think should be on pins 1 and 2 of the 13 pin header:

I personally think that 4.80v at the rpi header is too low, especially if the Orange Pi Zero was unloaded when you measured the voltage. As a comparison for you, I just ran up a freshly downloaded build of Armbian 5.30 Debian Jessie onto a not great, but reliable microSD (I know tkaiser will be spitting chips when I say this... Sandisk Class 10 8GB - the red and grey type - it's what I had handy - but I usually use tested Samsung EVO cards - as quality cards is important). I used a power supply set to 5.30v, and a known good quality 1m microUSB lead. I loaded it up, checked the voltage at pins 1 & 2 of the 13 pin header - 5.20v when the power supply had dropped to 5.29... still well above the danger levels. I then enabled the wifi, pinged google. It worked fine. I then disabled the WiFi, plugged in the ethernet (connected to a GbE router/modem, but since Orange Pi Zero is limited to 100Mb isn't really relavant), tried pinging google again, and it worked fine again. I rebooted, left the wifi off, and tested the ethernet. Again no problem. I then ran a stress -c 4 to see what the voltage at the headers was on the orange pi zero. measured 5.08v - so it was a good thing I started off with 5.30v wasn't it! Cable and voltage is important. Finally, the really test - would SSH work. In the mean time, I had run "sudo apt update && sudo apt upgrade" to upgrade the system to 5.31, so you'll see the warning message. But, I logged into to the ssh using 'ssh -l pfeerick 192.168.0.54' without any issue. So you see, there is something peculiar going on here... as we have conflicting reports of 5.30 Jessie not working... Igor tested it, and it worked. So does my set up. I'll test it on a second OPi Zero just for kicks, but I doubt it will play up. So we are left with it being hardware, either the board, the power, or the microSD. And power/microSD are the top two issues that people don't realise is the problem. So please forgive the more experience people here on the forum when they get testy... it's just they've seen it again, and again, and again... along with the "it can't be this" and the "it can't be that"... when it fact it can be and most often is. So where does this leave us? I'm not sure yet. But you can see.. it's not as cut and dry as "the image is broken"... because if the image was broken, I wouldn't be able to show you this (serial terminal in the background, ssh session in the foreground): Orange Pi Zero Armbian 5.30 Jessie (first boot, wifi enabled and checked then disabled, then ethernet enabled/checked): Orange Pi Zero Armbian Debian Jessie 5.30 second boot, wifi disabled, ethernet only:

lol... it wasn't needed, but is appreciated (I could have just used my super cow privileges and edited it you know! :-P )... Indeed. Knowledge is something we have learnt from the community around us, so it is only right that we shared it... we didn't 'create it from a vacuum' after all . And what's wrong with a good toilet sensor... although I'm not sure it makes sense to detect when toilet is running (sorry, couldn't resist). My use case is lest sophisticated atm... good 'ol weather logging... but if I get it running how I like it, then who knows... maybe it'll become a bit of home automation... turn on the lights, that sort of thing... Only good thing I got from mysensors so far was a link to a nice DIY atmega328 nrf sensor node board, with screw-header expansion option... was much neater than my breadboard to breadboard PCB version . That and from the same author, a nice nrf -> rpi header adapter module. I have yet to go near their abomination of a codebase (it can't be that bad, can it?) ... wish me luck!

Only other thing I can suggest is maybe the microSD is corrupt or faulty? (yes, clutching at straws with my limited knowledge ) If you can try re-writing the Armbian image using Etcher. And please keep in mind this warning from the download page: "All currently available OS images for H5 boards are experimental". I would be surprised if the images were that unstable that they wouldn't even boot, but the warning still stands... murky waters ahead! Other than that, I'll have to bow out and leave it for more experienced folks to chip in

Great posts @chwe! I have been meaning to get my OPi Zero up and running for MQTT duty, and this post pulls together both the ESP8266 and NRF24L01 stuff that I wanted to use with it! And now I have a reason to finally use node-rode... I didn't realise it would make that nice dashboard! Thanks!!!! And this link just cracked me up... nice! To call me an IoT expert is like someone call[ing] tkaiser a fan of micro USB powered SBCs.