• Content count

  • Joined

  • Last visited

About chwe

Profile Information

  • Gender
  • Location
  1. Starting to work on lets call it the "dogafu" experiment (don't give a fuck about recommendations). This would combine my threads about powering & bad SD-Cards. Cause I want do something useful and not just crash armbian on a system, from which I know that it would happen, I decided to do not only stupid tasks on my OPi zero. I could just hammering the SD-Card with a webcam and motion until it crashes and write on this thread 'opi 0 with terrible setup crashes after x days'. But, nobody would read this thread cause it's not interesting for anyone. We know that this would happen and for those users who don't know, there's nothing of interest in this thread. Since thermal throttling on the opi zero seems to be a real issue and there's a lack of information, that the temperature readouts from the SoC are correct, I decided to connect a DS18b20 to the OPi0 and let it measure the temperature of the SoC. Everything was installed on ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i. Hooking up the DS18b20: First we edit the configuration file and uncomment the w1 modules with sudo nano /etc/modules-load.d/modules.conf and cause onewire does not work properly @240 MHz we had also to change MIN_SPEED to 480000 with: sudo nano /etc/default/cpufrequtils after a shutdown we can connect the DS18b20 on GPIO10 (Data, physical pin 26), VCC to one of the 3.3V (physical pin 1 or 17) and ground (physical pin 6,9,14,20 or 25) don't forget to have a 4.8kOhm resistor betwenn VCC and Data! If you want to have your data pin not on GPIO10 you have to modify the script.bin with bin2fex /boot/script.bin /tmp/orange.fex followed by nano /tmp/orange.fex and change the GPIO in the [w1_para] section (example for using of GPIO6 for DS18b20): sudo fex2bin /tmp/orange.fex /boot/script.bin and a reboot is needed to activate this settings. Im everything works correctly sudo armbianmonitor -m should show that the cpu frequency would not go below 480MHz (otherwise DS18b20 would not run smoothly). Go to cd /sys/bus/w1/devices/ we can see our sensor with ls. It should start with something like 28-XXXXXXXXXXX. cat 28-0517010cbeff/w1_slave should show our actual temperature. So the actual temperature in my room is 23.562°C (IMO forget about everything behind the °C, proper precise temperature measurement isn't trivial and needs calibration which is not possible without professional equipment). Send data to an other device: Cause this setup with bad powering & a corrupt SD card will brick and I do not want to lose the collected data, I decided to send all the data to a second, proper running, OPi 0 via mqtt. This will be done by some bash scripts and crontab (it would be possible to do this only with crontab, but cause I may use this scripts on other devices for other purposes it's easier to have them isolated). For this, I installed a mqqt client with sudo apt-get install mosquitto-clients. After installation, we test if the client can publish on an other device with: mosquitto_pub -h 192.168.x.xx -t test -m "everything works ;-)" (-h ip oft the mqtt broker, -t topic to publish -m msg.payload). On my second OPi 0 with node-red and mosquitto we should see that the message arrived (installation of node-red and mosquitto). (with #, we subscribe to every topic on the mosquitto broker) Bash script & crontab: IMO the easiest way to send data periodically is to generate a small bash script which includes all the tasks and then setup a crontab to start this bash script. The scritp was saved in /home/opi/scripts/ with nano scriptname the script was generated (It might be possible to do this tasks without a bash script but since I'll reuse parts of it i decided it's the lazy way to do it.): Cause cpu infos are only available as root, crontab must run under root privileges. Add a new crontab with sudo crontab -e (1 for edit with nano). This crontab will start our script every minute: Cause this script runs now with root privileges, this might be a security risk so make sure that no one has access to your OPi! Now it's time to set up everything in node-red to get our results visible. I added dashboard to node-red to have some nice UI templates (usage of node-red & how to set up can easily learned by google . FYI: This is an ongoing project. At the moment, everything runs on a reliable SD-Card and the DS18b20 is not properly mounted on the SoC (waiting for thermal paste). As soon as I have everything setted up, I'll put it on the bad SD-Card with a cheap phone charger to see how stable it runs.
  2. Test setup: After the micro-USB thread where I showed that USB cable and charger matters, it’s time to speak about SD-Cards. For this I buyed a cheap SD-Card from aliexpress claimed to be a 8GB class 10 SDHC. Since I have no other 8GB cards I’ll compare this card with a Samsung EVO+ 32GB card which I usually use with my SBCs. After arrival, I did (as recommended by the armbian getting started guide) a first H2testw to check if the card is in a good shape (test results in german). Seems that this card still starts with bad sectors on it (384 sectors, 192 KB). Since formate a SD-Card on windows is shitty, I downloaded the tuxera SD-Card formater from Formate the card and do the H2testw again showed that we no have 12MByte more space. but the number of corupted sectors also increased (896 sectors, 448KB). Burning Armbian: So we could expect that this card wouldn’t be a good choice for a SBC but doesn’t matter, let’s reformate the card and burn armbian 5.24 (debian with legacy kernel) to it. After burning the image with Etcher, it reminds me kindly that this may be not a good idea. Let’s forget about warnings, connect the board via lan to the router and via serial debug to PuTTY. The first boot needs about 50 seconds. Set up the new password and new user for daily use and reboot the system (~30 seconds + 15 seconds for log in). Since everything runs smoothly, I decided to follow @tkaisers SD-Card benchmark test to see how this card performs (10M instead of 100M, forgott to remove the 16384k files ) 'iozone -e -I -a -s 10M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' The results aren’t that stable and we should consider that there’s a different kernel used compared to tkaisers thread but we see clearly that this card is slow. The reason why I choosed a outdated armbian is simple. I wanna see much the impact of the sd-card is during apt-update/ apt-upgrade from 5.24 to 5.31. Apt-get update needs 43 seconds followed by apt-get upgrade which needs 14 minutes. After a second reboot (~34 seconds) the SD-Card was removed formatted and a third H2testw was done. Surprisingly h2testw found less corrupted sectors than before (608 sectors, 304KB) After all these tests with the cheap SD-Card, I formatted my Samsung EVO+ SDHC 32GB card and tested it with H2testw. As expected there were no bad sectors since my last test of this card. Also read and write speed are ~3MB/s faster as with the cheap SD-Card. Burning the same image of Armbian to this SD-Card showed no error and the first boot needs about 44 seconds. After setup of the daily user followed by a reboot (30 seconds, 2 seconds after login), ‘iozone -e -I -a -s 10M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2’ showed that the card is faster than the cheap SD-Card but not as fast as in tkaisers setup on the banana pi. After finishing the SD-Card performance tests apt-get update was done in 40 seconds and apt-get upgrade to Armbian 5.31 was done in 11 minutes! Conclusion: Both, etcher and H2testw, did a good job. They indicated that the cheap SD-Card isn't recommended to install a OS on it. Iozone then showed also that the cheap SD-Card is a way slower than the Samsung EVO+, this was also proved by apt-upgrade, which took 3 minutes longer than on a Samsung EVO+ (~27% slower). Even if there were no instabilities during this short test, I would never use this SD-Card on an SBC cause it's only a matter of time until this setup runs into instabilities. Outlook: So, what's next? I'll combine the shitty charger with the shitty micro USB cable, mixed it with this SD-Card and serve it as the worst case armbian set up to you. This 'toxic cocktail' will then run 24/7 with some data generating stuff on it, sending some 'still alive' notes to a proper powered SBC, until it crashes (thinking about connecting a USB-Camera& motion to generate data).
  3. Unfortunately, I did not made a backup of the CAD file before I reinstalled windows on the computer (shame on me...) Do you plan to setup your mobile phone with linux? By the way, they removed their i96 board from aliexpress. Should be more or less the board without 2G modem. Does someone know why?
  4. With an el cheapo CHG340 serial to USB or is it claimed to be a FTDI? I have three of them lying around. The CHG340 works just fine. Both FTDIs are fake, one works fine the other one made me crazy. So test your USB to serial before you run into 'unexpected issues on serial output'. Even if FTDI decided to no longer brick fake FTDIs with their driver.
  5. Let me guess, you have a plus model with emmc, and you're not booting armbian. You're booting the stock android on emmc.
  6. Notations are always an issue, thats why I tried to have it somewere described. But I'm open for a US-version (imagine someone wants to fly with armbian to mars and fails due to undervoltage of his board ) I think this could be explained by the tunneling effect. So, let's decide which model of anharmonic oscillator we choose (since we do not have a one electron system there's no possibility to solve this with an agebraic solution) and calculate this. Thats why the 'FYI: These measurements weren't made under laboratory conditions nor with high precision equipment' is inside this post. I don't have professional equipment nor beeing an electrical engineer, so it's also interessting to me learning something about power supply from you and others! What i noticed: the cheap chinese charger (new) flipped much more in the voltage than the 5 years old iphone charger, maybe they used old capacitors or had some other design flaws inside the powersupply.
  7. I finally made a copy past monkey work out of it and posted it in the forum. So if people want to keep this 'white paper' idea alive we could still do it, but as long as there's not enough manpower i'll left it in the forum (doesn't make sense to hide it)
  8. Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB). Basics: It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)! The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1). Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm) Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability. How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2. Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1). Illustration 1: AWG print on cable Example: If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes? *this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability. Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2). Figure 2: Voltage drop of a copper cable at various thiknesses If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done. Case Study: Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2). Illustration 2: Setup vor measurement FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1. Table 1: Specification of the tested chargers Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC! Table 2: Tested micro USB cables Results: After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3. Figure 3: Voltage drop at delivered current of all chargers Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger. If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC. All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4) Figure 4: Voltage without load, with load and on output and @powerbank . Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side. The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it. Conclusion: What's next? Should we never buy again a micro USB powered SBC? IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load. Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you! Illustration 3: Recommended powersource
  9. it's called up, and normally not helpful to get an answer faster you ask the same question 2 months ago. The links provided by igor didn't helped you? Maybe this or this link gives you some information (@tkaiser, please forgive me posting bpi forum links ). Starting from server version is IMO not the best idea since you need most things wich are included in desktop version... To my knowledge, configuration of kodi on new boards is not trivial, since this work is still done, why do you want to do this again? If Kodi 16 does not fit to your needs, you might change to a SBC on which kodi 17 is still running.
  10. I finally gave up playing arround with the MySensors lib. Main reasons are: For every example they use predefined libs (DS18b20, DHT etc.) sometimes no support for updates of these libs. Things like "This example uses a modified version of the external DTH library, which is included in the MySensors external examples." indicates to me, that this lib has some 'problems', otherwise this should work with the standard DHT lib. The hole project seems a little bit predefined to me: Use the nodes we think you need, and since I'm not interessted in their nodes it does not make sense for me. They presented so many examples of nodes, but I never found a example like: how to build your one node (for IoT stuff, where every one, including me, thinks that he would have a better idea how his node should look like, this is IMO the most important tutorial that you should have on your webpage). I tried to get a DHT11/DS18b20 working on an arduino nano just to give you an example that this setup works, but I failed several times. Since im not really interessted in the MySensors stuff anymore I would not waste my time for this. If someone tries it and it works, please add it to this thread, it would be cool for others which are interessted in the MySensors stuff! @pfeerick the finally made it! (ok, not for the toilett, but would not be hard to adapt this.. ) Found on CNXSoft that BLE is now able to implement mesh networking. If this will be implemented on the cheap BLE modules (e.g. CC2541) this would be a game changer for IoT thingies...
  11. fourth topic in the searchlist. seeems like a good starting point, whenever its not from the armbianforum. From the known issues: TV Out doesn’t work as expected (only PAL/NTSC resolution, overscanning, no h3disp support, notes for OPi Zero)
  12. According to de getting started guide: Images shall only be written with Etcher on all platforms since unlike other tools Etcher validates burning results saving you from corrupted SD card contents. just to remove one possible problem.
  13. More or less, just cause i'm interessted if it gets worser or not. If it would be that unstable I'll make a new case for the OPi0 with active cooling possibilities.
  14. Hmm, interessting. I thought the rev. v1.4 board is the troublemaker in terms of overheating. Could you repeat this experiment with your v1.4 board? I plan to do some thermal stresstests with the board as soon as my second one arrives (with current&voltage measurement on different spots on the board).
  15. which one? The more connectors, the more possibilities for errors. If this is a fixed system, why using connectors? If I see it right on the pictures the expansion board does not overlay the 26 pinheader. There are two possibilities, bent or not bent pinheader (bent is for sure more expensive, cause for the linear you can use two rows of 13 pins). Male or female connector (does not really make a difference, as long as you don't stack your own expansion board directly to the opi). Going out of your case depends on your needs (e.g. on which side of your case do you need the wires, should it look "perfect" or just work). Quick and dirty solution: If you don't use the 3.5mm jack from the expansionboard, just cut it out and you have your hole or melt a hole with your soldering iron into the case (ABS is a thermoplast so melting would be the easiest way). If you want the nice perfect solution, download a CAD, design the perfect case for your needs bring this to a printservice and you're happy to have a nice case.. This is mostly a software related forum and all the support is for free. You get some hints (e.g. about ABS), IMHO it's time that you start to think about your needs. Seems that nobody who have the OPi 0 case used the pinheader or they don't saw your topic.