Michael Dehn Klit

  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Michael Dehn Klit got a reaction from lanefu in Orange Pi R1   
    If anybody missed it, there is an openwrt image now.

  2. Like
    Michael Dehn Klit reacted to konsgn in New OPi Zero - Yet another high temperature issue...   
    Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
    In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
    For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
    I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
    Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
    This results in the following temp readings stable/finger tested:
    19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
    19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
    19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
    19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
    19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
    19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
    19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
    19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
    This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
    I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
    Alright, here's what I found:

    All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
    Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
    Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

    Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
    Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
    Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

    PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
    "R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
    1- apply generous amounts of flux from flux pen.
    2) use solder wick to remove as much solder as possible
    c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
    If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.
  3. Like
    Michael Dehn Klit reacted to Igor in Orange Pi R1   
    "Rear" could be understood both ways  Router rear are usually RJ45 sockets. In any case logical connections matters - both are 100M only and can be used in any WAN/LAN combination. Current armbian-config have a wizard for setting AP while for extended interfaces manipulating, creating bridges, firewall, ... is not yet done. Network config is anyway on your own/upon your needs and my goal is to provide some simple router functionality. If you need some serious stuff it's better to use (containerized) OpenWRT or similar.
  4. Like
    Michael Dehn Klit got a reaction from xalu in Details with OPIZ2+ H5   
    So I used the 5.32.170706 nightly Ubuntu 16.04.2 LTS 4.11.8-sun50iw2
    Locked Kernel in Armbian-Config and did a

    apt-mark hold linux-firmware
    apt-mark hold armbian-firmware
    apt-get update && apt-get upgrade

    And Wifi is working

    The I unlocked the Kernel and did an upgrade, but didn't unlock linux-firmware & armbian-firmware

    And Wifi is working
    Then apt-mark unhold armbian-firmware
    apt-get update && apt-get upgrade
    And WIFI is gone