pfeerick

Moderators
  • Content Count

    146
  • Joined

  • Last visited

Reputation Activity

  1. Like
    pfeerick reacted to tkaiser in ROCK64   
    This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540):
    random random kB reclen write rewrite read reread read write 102400 4 10794 14075 18413 14337 12084 13125 102400 16 38316 48250 58929 50123 33636 44383 102400 512 85148 113573 217972 226149 209220 229556 102400 1024 239054 254531 226798 261436 240226 213082 102400 16384 271696 291983 316979 323006 282067 292218 In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.
  2. Like
    pfeerick reacted to TonyMac32 in [Example] Support proposal for ROCK64   
    It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
     
    Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
     
    So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
     
    Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
     
    From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."
  3. Like
    pfeerick reacted to hmartin in [Example] Support proposal for ROCK64   
    Two things I want to bring up:
    "Trial period" is a great idea, and this is what I was getting at: During the "trial period" nightly/stable builds are not available. Anyone wanting to test out the board during the trial period has to build an image from git themselves. This prevents devs from being mobbed by people for support when there are still lingering issues. Forums suck for finding information, and no one ever uses the search feature. So, wiki software. MediaWiki is FOSS, but the syntax sucks. Confluence isn't FOSS, but it is free for Open Source projects, and they have a really excellent editor. I'm not affiliated with Atlassian in any way, I just think if you want a usable, low-friction wiki, Confluence would be a good choice. I realize since Confluence is not FOSS, this has some negative appeal in some corners. Also it's Java...   
     
     
    We tried this already with the Orange Pi Zero. It just ended up pissing off everyone who was working on it (including me). No user seems willing to accept our explanations about performance and what is feasible. They think because the manufacturer says "WiFi" it will do the same things as their $1,200 laptop with dual-band 3x3 802.11ac.
     
    Why should I sit here and take shit from people who expect perfect WiFi from a $9 SBC and pay nothing toward Armbian? Especially after we calmly explain what isn't possible, they say "well I was thinking about giving you money, but since you can't make magic unicorns out of thin air, forget it" Seriously?! Seriously?!!! No. Please go away.
  4. Like
    pfeerick reacted to tkaiser in [Example] Support proposal for ROCK64   
    No, this all is what I wanted to discuss here in the first place. The '[Example]' in the thread's title is there for a reason. Is Armbian willing and able to change some 'habits' or not? Is it possible that the inner circle allows other people to participate or not? Is the 'inner circle' aware how some stuff looks like from the outside (eg. taking decisions out of nowhere that should be result of a discussion process).
     
    But I'm really too tired to continue...
  5. Like
    pfeerick reacted to zador.blood.stained in [Example] Support proposal for ROCK64   
    Agree. Categories like "Recommended by Armbian for building a medium level NAS", "Recommended by Armbian for building a powerful router" or "Recommended by Armbian as a low cost IoT node" would be better - still suggesting users (that decided to check the software situation before buying the board) what to choose without creating false assumptions regarding product quality and support.
    Unfortunately even if we tag i.e. Orange Pi Zero as "Not a good choice for making a multimedia center" and "Not a good choice for making a wireless AP", it won't stop people from trying to use the board for exactly those use cases.
  6. Like
    pfeerick reacted to zador.blood.stained in WIP/EOS nightlies cleanup   
    Current situation with WIP/EOS boards:
    ➜ armbian % find lib/config/boards -name '*.wip' -o -name '*.eos' | xargs grep BETA_TARGET | grep -v '\"\"' lib/config/boards/orangepiprime.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiprime.wip:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc2.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc2.wip:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/lamobo-r1.eos:CLI_BETA_TARGET="xenial:next" lib/config/boards/nanopineo2.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepizeroplus2-h5.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiwin.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiwin.wip:DESKTOP_BETA_TARGET="xenial:dev" ➜ armbian % As proposed in the discussion thread, we should think about disabling prebuilt nightlies for configurations that we won't support, so I propose disabling them for all boards listed here.
     
    Current situation with "supported" boards:
    ➜ armbian % find lib/config/boards -name '*.conf' | xargs grep BETA_TARGET | grep -v '\"\"' lib/config/boards/orangepizero.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/miqi.conf:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/cubieboard2.conf:DESKTOP_BETA_TARGET="xenial:default,next" lib/config/boards/pine64.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pine64.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/odroidc1.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/cubox-i.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/cubox-i.conf:DESKTOP_BETA_TARGET="xenial:next" lib/config/boards/odroidxu4.conf:DESKTOP_BETA_TARGET="xenial:next" lib/config/boards/orangepilite.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pine64so.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pinebook-a64.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/orangepiplus2e.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/cubietruck.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/nanopineo.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/clearfogbase.conf:CLI_BETA_TARGET="xenial:default" lib/config/boards/orangepione.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/nanopiair.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/tinkerboard.conf:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/bananapi.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/orangepizeroplus2-h3.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/bananapim2plus.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/beelinkx2.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/orangepipcplus.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/clearfogpro.conf:CLI_BETA_TARGET="xenial:default" lib/config/boards/lime2.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/odroidc2.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/odroidc2.conf:DESKTOP_BETA_TARGET="xenial:next" ➜ armbian % In my opinion this is too much, so we should disable some nightlies fron this list too.
  7. Like
    pfeerick reacted to Igor in WIP/EOS nightlies cleanup   
    Yes, let's move all out and enable upon developers requests?
  8. Like
    pfeerick reacted to zador.blood.stained in Moderator duties   
    Small note to moderators:
    Sometimes when posting several duplicates of new post or thread may be created (with the same content and timestamp). Please don't blame the poster for this, simply hide or delete the dupes. Thanks.
  9. Like
    pfeerick reacted to Igor in Moderator duties   
    This function is (was) not enabled by default - just hover over the username -> "More options" -> "Flag as spamer" / "Warn user" . When flagging someone as spammer - posts are also hidden and AFAIK user info goes upstream to general spam database. Spammers busted on any IPB forum are blocked everywhere ... with one click. In reality there are some problems with this service - sometimes prevents humans to login - and it's currently disabled. I'll check again upon next major forum upgrade.
     

    Welcome on board  - this requirements above shell be updated but remained simple, unambiguous and understandable to everyone, not just to us. 

    I guess I will need to rewrite the text saying "rare" to "extremely rare" since forum crew expanded this quickly  Closing recruitment for this year or until someone decides to have enough of this.
  10. Like
    pfeerick reacted to martinayotte in Problems with Orange PC+   
    I'm quoting myself here from my previous post :
     
  11. Like
    pfeerick reacted to chwe in IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01   
    Added the -ings for you..
     
    The dashboard things came from a add-on. At the moment I'm a little bit annoyed from the mysensor stuff. So much of their sensor nodes are fix configured which makes it hard to me to understand, how their library work. My purposes for the hole IoT thing isn't that my opi recognizes when go to the toilet or other senseless homeautomatization stuff (senseless to me, if someone else needs this feel free to make a toilet node ). I want to use it in lab-automatization (mostly chemistry labs). So most of their predefined nodes are useless to me. Nevertheless, I'll start with things, where an error doesn't burn my labratory.
    IMO knowlege should be shared to give something back to the armbian community who makes it possible to me, even thinking about doing lab-automatization on an sbc. 
     
  12. Like
    pfeerick reacted to umiddelb in [Misc. / systemd removal] Removing systemd from Jessie   
    I've just managed to build Devuan/Aarch64 for the Odroid C2 using the traditional debootstrap (on an Ubuntu host) way, so I might be able to patch the armbian/build scripts in order to generate a Devuan image.
  13. Like
  14. Like
    pfeerick reacted to weyou in Random no booting issue on OrangePi PC2   
    Thank you.  I will try to change a new power supply.
     
    I was not intent to making multiple posts,  it was just an accident   Maybe my network issue, the edit page didn't have any response after my first clicking on the submit button.  So I clicked twice...  And I didn't find how to delete the duplicate one.
  15. Like
    pfeerick reacted to jcc in startup login prompt   
    Thanks ; it is working
    Regards
  16. Like
    pfeerick reacted to chwe in IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01   
    I also started to get the cheap nrf24l01 boards to work. when I followed this tutorial, I always get the error that something with the gpio was wrong.
    mysgw: Starting gateway... mysgw: Protocol version - 2.2.0-beta mysgw: MCO:BGN:INIT GW,CP=RNNG----,VER=2.2.0-beta mysgw: TSF:LRT:OK mysgw: TSM:INIT mysgw: TSF:WUR:MS=0 mysgw: Could not open /sys/class/gpio/gpio24/direction
    Using this configuration settings showed that the nrf24l01 should work on orange pi zero side:
    root@orangepizero:/home/opi/MySensors# ./configure --spi-spidev-device=/dev/spidev1.0 --my-transport=nrf24 --my-rf24-ce-pin=2 --my-rf24-cs-pin=13 --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 followed by make should give you something like this:
    The evening would show if I also get it to run on the sensor node side (don't have time at the moment).
  17. Like
    pfeerick reacted to chwe in IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01   
    For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.
    Hardware:
    OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation:
    First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
    Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto
    To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
    with npm i node-red-dashboard
    If everything goes right you should have access to node-red via browser on port 1880:
    192.168.1.xx:1880
    and to the UI of dashboard:
    192.168.1.xx:1880/ui/
    Setting up everything:
    Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos):
    VCC -->3.3V 
    Signal --> D4
    GND -->GND
    Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...)
    For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager):
    PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker:
    The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
    Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)
    We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). 
    Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)
    To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo  is provided "as is", without warranty etc.

  18. Like
    pfeerick reacted to StuxNet in Overscan on Orange Pi PC   
    You'll find that this community is still relatively small, imo. Some posts can go longer than 3 days without a response. Please keep duplicate questions to a minimum.

    That being said I've only tinkered with RetroOrangePi a couple times so I'm not gunna be the one to help you. The very (and I mean very) little knowledge I have tells me editing boot.cmd would be easiest. Don't quote me.
    I do remember having resolution issues on a 720p TV (Opi PC+) though and this thread helped me customize the settings for a fix. Good luck.
     
  19. Like
    pfeerick got a reaction from StuxNet in Random no booting issue on OrangePi PC2   
    I would suggest that you look at getting a different power supply, as mobile phone chargers are notorious for being unreliable for SBCs. They tend to either not provide their full current until the phone has *handshaked/negotiated* with the charger, are noisy, or drop their voltage they are loaded to below usable levels (as phone charging needs aren't that demanding). I would suggest you look at getting something like the white power supply (with interchangeable international plugs) for the raspberry pi. 
     
    Also, please refrain from making multiple posts... someone *will* reply eventually
  20. Like
    pfeerick reacted to tkaiser in Changing to Chromium   
    Nope, I was aware that 'sometimes in the future' there will be a new Armbian major release exchanging Firefox with Chromium. To my surprise it 'happened' few days ago, now we're at 5.30 and ship with a new default browser on new desktop images and a default config that is slightly more insecure than 'needed'.
     
    I was asking for opinions since our current 'style' of development (anyone with commit rights to Armbian repo does whatever he wants) is not that great IMO. I was waiting for something like 'yes, let's do it this or that way' to start working on it (changing kernel configs for the affected arm64 platforms, then testing). But then 5.30 happened without any announcement so there was not even an opportunity to check open issues that need to be fixed prior to release.
  21. Like
    pfeerick reacted to tkaiser in [Example] Support proposal for ROCK64   
    Absolutely! I would call this a show-stopper that can happen in early development situation and invalidates all 'in theory' considerations before. But IMO this shouldn't change a bit how we deal with board additions in the future.
     
    Please remember situation with OPi Zero: we (some from the inner circle) were excited, added the board, improved settings like crazy. Later we discovered unfortunate Wi-Fi power management settings, then Wi-Fi here being somewhat crappy anyway. If there would have been a rather clean 'board bring up' thread such findings would have been documented (adjusting post #1 in the respective thread), board support rating would have been adjusted and post #1 of the thread could act as something like a landing page for the specific device (moderators pushing newbies to this 'page' for example).
  22. Like
    pfeerick reacted to gnasch in [Example] Support proposal for ROCK64   
    Hi devs,
    you are complaining about support nightmare. Microsoft had it much worse, with all possible shitty hardware being introduced without drivers and users expecting it to be supported. Their anwer: "Certified for Windows Vista" with a nice icon to be printed on the sales page. Conditions for the hardware vendor to include the icon was defined by Microsoft.
     
    No hardware vendor will read the complaints in your forum. Armbian on the other side has quite the reputation. Do the same, define conditions for boards to be "Certified for Armbian" and push the vendors your way.
     
    best,
    gnasch
  23. Like
    pfeerick reacted to TonyMac32 in [Example] Support proposal for ROCK64   
    Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
     
    I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
     
     
  24. Like
    pfeerick reacted to Bubba in [Example] Support proposal for ROCK64   
    Watch out or the next thing we will have is.....
     
    "End-users talking to developers, manufacturers talking to consumers, dogs and cats living together, Mass Hysteria, human sacrifice"....
    ....Jonathan Peterson, Technical Consultant, IBM eBusiness Services
     
  25. Like
    pfeerick reacted to zador.blood.stained in Moderator duties   
    If it's an obvious spam - just use The Banhammer, full swing, straight to the head (aka "Flag as spammer" function). Sometimes spam is not obvious, but if content in question contains suspicious external links or just doesn't make any sense, you can just skip it and leave for somebody else to make a decision.
     
    I don't think we have any rules set up regarding signature and topic bumping.