Jump to content

Tido

Members
  • Posts

    1539
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Tido reacted to tkaiser in Banana Pi R2   
    Welcome here!
     
     
    Interesting. No one here talked about patches or active development. The person you quoted only reported over in your forum that he did a 'make menuconfig' to fix stuff you forgot to enable in your kernel (according to your indtroduction it's the kernel you maintain?). It might be a surprising experience but you can modify the kernel config and enable/disable stuff there. That's what the person did you ask now for patches.
     
     
    Things are slightly different this time but we got the chance to realize this just recently since SinoVoip blocked successfully every insights for almost half a year.
     
    The R1 is crap in so many areas that it's just a waste of time to list all the issues. So let's try to be positive and look only at what's different now:
     
    Software:
    Unlike back then with R1 which received zero support by the SoC vendor (Allwinner) we know in the meantime that MediaTek (who have/had a horribly bad reputation based on their 'closed' behaviour in the past requiring everyone to sign NDAs and to pay insanely high amounts of money to get access to sources) opened up themselves and are becoming part of open source community. This is really great news but also somewhat surprising. MTK partnered with a vendor not able to understand the meaning of 'open' and so SinoVoip was sitting on a closed MT7623 kernel repo and prevented every member of open source communities to participate/improve for almost half a year for exactly no reason ('just wait and see' was everything we got from their official voice 'sinovoip bpi team') A couple of MTK engineers are active upstreaming software support for both SoC and the R2 so as already said in post #1 in this thread: 'We also know that MediaTek unlike in the past is currently opening themselves, their vendor kernel for this board is a 4.4.70 currently and they're also busy supporting their own hardware upstream. It might get interesting in 2018'. @sean.wang already explained what might be missing currently with mainline kernel in this thread and I really look forward to MT7623 designs in 2018 when mainline kernel support matured. Since MTK is providing mainline kernel support it's just a matter of time until *Wrt/LEDE support will be available (R2 becoming the main development vehicle for MT7623 devices) Hardware:
     
    At the time I could poke SinoVoip's copy&paste monkey censoring their forum and not supporting users to provide a boot log a few weeks ago we also know a bit more about the hardware (it's amazing that their BS collection they call 'technical documentation' still lists so much wrong or contradicting information). Since a few end users now have this hardware in their hands we can expect at least some performance and other numbers soon since for whatever reasons SinoVoip never tested any of their boards wrt performance/usability.
     
    R2 does not suffer from R1's Achilles heel (the shitty Micro USB connector to power the board responsible for so many under-voltage drama), maybe we get some information from users soon how powering connected SATA disks work (isn't it amazing that the hardware vendor is not able to answer such simple questions?) so soon we know a bit more what to expect with regard to specific use cases and overall performance.
     
    MT7623 platform looks great, we've been asked by a Taiwanese company planning to build an 'open' NAS device already about software support (they also mention MTK being really supportive) and at least I'm really looking forward to more devices based on MT7623. But unfortunately I'm allergic to stupidity/ignorance and stuff like this https://archive.is/tY9gt is all we can get from the respective 'vendor' now. I fail to understand the purpose of 'borrowing' a table from a competitor totally unrelated to your own hardware/software to 'demonstrate' whatever. That's not a mistake you make by accident but that's just bizarre. It's now year 3 in Banana land dealing with stupidity/ignorance for whatever reason (unfortunately zero improvements). And that makes me really sad since I fail to understand why...
  2. Like
    Tido reacted to RagnerBG in Banana Pi R2   
    Hello. I just want to say - all this blah, blah, but you missing the point. People are not rude against you just like that, but because of your company actions. This is reputation you've earned. False advertising, incorrect information, hardware issues, this is the problem. TK is maybe sort of sarcastic, but it is for a reason. Most of his comments are not "full of malice and disgust", but full off useful information, for you and your potential customers. It's only better for you if you not ignore them, but take a notes. 17 years software and hardware development and you don't know, it's not all about open source (at lest for your company), but to provide support. If you care about open source support, provide the sources opened and proper documentation, so people can do development for you. But if the hardware vendor don't want to do this, there is nothing wrong in closed source, if it's workable and with proper license. But nor you, nor your vendors do any of this, it's just NO support at all. Let's see MTK now, but with your other partner AllWinner, we see a lot of circus with free interpretation of what "open source" and "GPL" means, reflection mostly on end customer. Things like these are the reason, people with experience with your company, been not so nice. Not your English language (mine is not good too). I personally have experience too. I own one of your products and use it for good, but only at 50% of what was advertised back then and with a lot of hardware and software interventions from my side to make it at least stable at these 50% of usability. How could i be very gentle and buy another product from you? And i could be potential buyer of this new R2, if only things were different this time. But from what we see so far, even in this thread, it's the same - hardware and software, a huge deja-vu. Poor new owners, they don't get it yet, but we do and with this exposure, in this very thread, you don's make things different. You had one good product - the first BPI-1, what's gone wrong since then?
     
    I will keep following this topic. It's really fun . And with latest efforts to use this forum for the same false advertising and reclame, make it even more interesting. Only need popcorn.
  3. Like
    Tido reacted to tkaiser in Banana Pi R2   
    Especially since it's the same since ever or let's say since we have to deal with these guys (in the beginning when Foxconn let LeMaker do the support/software/documentation job for the original Bananas it was different, then LeMaker got greedy, applied for Banana trademarks and has been kicked out... since then we suffer from total ignorance). 
     
    Please look at https://archive.is/tY9gt -- the copy&paste monkey they hired to run the forum and fill their gitbook resources with random nonsense fetched a table from FriendlyELEC wiki where a responsible vendor describes their internal engineer's work to move away from Allwinner BSP to mainline Linux kernel (the result of an email conversation between them and us which even led to hardware improvements once FriendlyELEC realized that mainline kernel allows for DVFS unlike BSP). Now they garnish this with some sentences mentioning MTK/R2, add a screenshot and make a forum post out of it. The sole purpose is to create the impression of some 'hard work' being done and to feature this forum post on G+ and Facebook where a clueless crowd applauds.
     
    And in the meantime this sort of advertising happens even here. It's unbelievable especially that these guys don't get it why lies are wrong, that correct information/specifications are important and so on. That's such basic stuff but they simply don't give a sh*t about this at all since years while at the same time whining about 'people attacking us'. And their ignorance totally shields them from reality.
     
    Edit: 'Lion_Wang, the figure you posted' has been removed by him now. Guess why. The same game they play since years now happening even in Armbian forum, really unbelievable.
  4. Like
    Tido reacted to TonyMac32 in Banana Pi R2   
    Well shit.
  5. Like
    Tido reacted to chwe in Banana Pi R2   
    Cause you find this table on the friendly Arm wiki...
     
  6. Like
    Tido reacted to TonyMac32 in Banana Pi R2   
    Perhaps as an aid to our mutual understanding, would it be possible to link to a schematic and all released technical documents here, and provide an up to date image/layout of the board?  I see a few things on the Banana Pi site that are... awkward.  There are at least 2 revisions of the board on display with different port layouts, and the power jack next to the microUSB is labelled as "12 V"  is that accurate?  I don't know what that PMIC is off hand, so I'd be very unlikely to use that power jack unless you provided the adapter. 
     
    I think there is potential, however I am an automotive engineer, everything document I make must be defensible in a court of law, so I am very specific and I require a lot of verified documentation. 
     
    I am by no means looking for perfection, but it should be accurate enough that I can
    Follow it without destroying the device Compile a generic linux without relying explicitly on your repo. Observe something near the advertised performance specs during empirical testing Identify all the right parts found in documentation. We need a thread where @Lion Wang @Nora Lee and @sean.wang are following and replying as is needed.  We are not asking any questions that should be unexpected, most vendors provide schematics and most vendors have reasonably accurate datasheets.  Our feedback should be very carefully considered, we are an educated user base, something development teams almost never have access to.  We have people that use these single board computers in industrial and other applications, when they say "It would be really great if..."  They know what they're talking about.
     
    Now, I do not speak for the team, I only speak for myself and hopefully as a sane and intelligent individual:  My recommendation on getting Armbian support for boards is to come here, reach out to the Armbian community, and provide accurate and complete documents, ask us questions, listen to our answers, etc.
     
    Lion_Wang, the figure you posted shows WiFi + BT as OK, but you say it isn't complete.  I see it's listed as AP6212 here, but on the R2 manual it says:  " banana pi BPI-R2 have support MTK6625L wifi&BT 4.1 chip onboard. "  <---  That is the sort of thing that causes trouble and upsets people.
     
    The schematics are better than nothing, but they are scrubbed of IC names, values, etc, so really there is a limit to what value they are.  I do at least see +12V being specified there, and consistently through, so OK.  I was bracing myself for magic smoke everywhere...
  7. Like
    Tido reacted to zador.blood.stained in Banana Pi R2   
    I can agree with one thing - IMO it's better to ignore the hardware ot its vendor instead of constantly throwing dirt at them hoping that things will change. Instead of actively trying to improve them (which doesn't work as can be seen) let them improve themselves if they want the attention and possible software support.
     
    While @tkaiser IMO spends too much time being negative about the vendor and/or hardware, he raises at least 3 valid points that apply to this vendor in general:
    Wrong or incomplete technical specifications and documentation False advertising Hardware design issues While I didn't pay too much attention to the BPi R2 board, with other boards those points would cause some problems: people that buy hardware by public information and specifications won't be able to use some of the claimed features, and hardware design issues may result in either stability issues or inability to use some of the features without hardware mods (or both).
    So R2 should be poked with a long stick first (to check if any of those points apply to this board), then somebody (not the vendor!) has to do stability tests and check if primary hardware features (LAN, SATA, mPCIe, wireless) are working as expected, and after that it's OK to start work on mainline based configuration.
  8. Like
    Tido reacted to TonyMac32 in Banana Pi R2   
    @chwe as long as it is not banana Aldi beer...   (There is Aldi here, it does quite well)
     
    There is an old saying, I feel it applies here:. "Fool me once, shame on you.  Fool me twice, shame on me."   I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed.  And that is with only one bad board, imagine 3,4,5?  "Same old story, same old song and dance".
     
     
     
     
  9. Like
    Tido got a reaction from chwe in Banana Pi R2   
    On the R1 the SATA connector had no power for the Harddisk. SinoVoip sold a product with software that would not turn on the main feature of the board.
    Thanks to a hw engineer who tinkered and reverse-engineered it could be powered in the end. Still months after that the sw of SinoVoip was not fixed and people in the forum were asking for help.
    What was your question again
     
    I wrote that begin of 2016, first contact with Nora - can you see improvement?
  10. Like
    Tido reacted to JohnnyWednesday in Banana Pi R2   
    Hey Armbian aficionados - it's me of 'I can confirm that sound support isn't compiled into the kernel' fame. Please don't rush me all at once, I didn't ask for this fame and glory and I've already turned to hard drugs and fast women.

    Since I've got this board and I'm not entirely incompetent (open to debate) - please let me know if there's anything I can do from my end to provide you with information for your assessment.

    I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers - I agree that their software practices and documentation is poor - there's basically no info on the battery connector, efficiency of the step-up, max draw etc - the barrel jack was a different size from their technical drawings (that's £1 on an adapter I'll never get back - it sits on my desk... mocking me) - I'm sceptical in regards to the simultaneous power draw of the 2-pin and 4-pin SATA power headers using the specified 2A supply  (I got a 3A for testing but I'm not ready to risk two drives just yet - definitely need to be careful in regards to lithium battery draw) and there's an unpopulated position for a cap next to the 4 pin supply on my board that's present on their pictures for the v1.1 revision of the board - I'm a little suspicious as to why it was left out in this production batch - perhaps it was determined to be superfluous but I've popped a question to support - they've been really helpful so far (just remember to throw your sentences back and forth between English and Mandarin on a translator to ensure that meaning remains intact - you get much more detailed responses when you remove the ambiguity of translation)

    But all that said - it's a really great bit of kit  very well made, general IO is nippy, the mPCIe is great for development (got a lovely little mPCIe FPGA board coming for my SDR project) SATA is working (tested a an old 2 inch spindle drive - need better kit to probe bottlenecks) sound is working perfectly (when compiled in), GPIO, WAN/LAN, USB3, OTG all seem to be functioning fine (wrote 30gb of data to a flash stick on the device from a CIFS mount - calculated hashes match) - so far it's not crashed on me once - SoC gets a bit hot under load - fine with a heat sink - don't think the thermal sensor is supported yet or perhaps that's not selected for compilation either (there's a lot of MediaTek stuff in this kernel that's not enabled but a lot of it is for other MTK chips - some of it is ambiguous in description so I'm not 100% sure yet)

    Waiting on support for the internal WIFI/BT - hardware video decoding isn't working or not enabled (480p mp4 ran smooth as silk at 1:1 - the moment you scale, performance bombs) - obviously no GLES on the Mali450MP4 (userspace blobs for 3.x kernels - 4.x kernel for the board - that old chestnut) - not eeeeentirely sure if the X11 driver currently used is optimal (gallium on llvmpipe reported under Xorg - will dig into that a bit more now).

    I'm sure the experts here are rubbing their temples at this stage - please don't geek attack me - I'll probably cry. It'll be really pathetic and my face will be a mess - nobody wants to see that.

    Anyway - if I can run any tests and what-not then please let me know - I'm fine compiling/tweaking my own distro for my needs but I'd be a lot happier with a pro distro like Armbian - if you ever deem this board a viable target that is.
  11. Like
    Tido reacted to tkaiser in Banana Pi R2   
    Well, 'I can confirm that sound support isn't compiled into the kernel' so 1) it has been never tested by the 'manufacturer' as expected and 2) users need to compile the kernel on their own to get at least HDMI audio. Besides that combining multimedia features with router/firewall functionality on the same device without appropriate separation is still one of the most stupid goals ever.
     
     
  12. Like
    Tido reacted to TonyMac32 in Tinker Board and the RPI 7" touchscreen   
    HID is now working, of course the touch input does not rotate with the screen (perfect compatibility with raspberry pi! )
     
    I can link to the Deb packages for the kernel/dtb if anyone wants to try them out, and if anyone with a MiQi can make sure they don't break anything before I push the patch to the repo.
  13. Like
    Tido reacted to tkaiser in Banana Pi M2 Berry   
    The above is a so called 'Banana Pi M2 Berry' I bought yesterday and will return today to get my money back (due to 'Irreführende Werbung' / false advertising) showing most probably the use case this device will be bought by clueless people: To connect a SATA 2.5" disk to it since 'native SATA'. Of course this doesn't work as expected since the board's power design is an absolute fail.
     
    The manufacturer already knows what a shit show using Micro USB for DC-IN is. I simply used the same average USB cable I used to demonstrate the problem a few years ago with the original Banana Pi. With an average USB cable the disk does not even spin up but only produces ugly noise (clicks and motor spinning on/off constantly). Check dmesg output at the bottom of http://sprunge.us/FaFL to see how under-voltage shows up in the logs. When the poor disk made ugly noise I measured on pin 2 and 6 (5V/GND) and saw voltage dropping as low as 4.4V which is definitely way too low for a variety of disks. Check with Hardkernel's findings wrt exactly the same issue: 'We found that Seagate 2TB and HGST/Hitachi 1TB HDDs are quite sensitive to the input voltage level while WD 1TB/500GB, Samsung Momentum and Toshiba HDDs are working well even with 4.4Volt input.'
     
    Please note that in the above setup I did not use Gigabit Ethernet. GbE significantly increases consumption and then voltage drops even more. In other words: Depending on the USB cable users choose, the PSU/charger, the type of connected disk and additional load on the board the stuff people buy this board for (NAS use cases) will either work or not. Since all the advertisements for this board are misleading the average buyer of this board must be also clueless -- since if he does some research before he wouldn't buy the board. If Armbian starts to support this board we deal with a user base blaming us for the shitty power design of this board (since not understanding stuff like Ohm's law and talking about instable software where it's just under-voltage/hardware) and also why Armbian is incompatible to Raspberries (omxplayer won't work here, raspivid/raspistill don't work, every graphics stuff for Raspberries doesn't work and the users expect 'spoon feed' mode as known from Raspberry Pi forums).
     
    Since I had the board already on my desk and the vendor itself is as usual too lazy or too stupid to provide any performance numbers I checked quickly for myself:
     
    The USB design of this board is as shitty as DC-IN: all 4 USB receptacles are behind the same USB hub so all have to share bandwidth (the SoC's 2nd real USB2 host port is not used. Responsible board makers in such situations connect only 3 USB receptacles to the hub and the other real USB host port to the fourth USB receptacle so this port doesn't need to share bandwidth and can be used with another disk for example). Here 'lsusb -t' output from me connecting my test USB disk to each of the 4 receptacles. Some CPU/memory performance numbers: https://pastebin.com/gANnaQJ5 (please keep in mind that you need to understand the influence of compiler/OS version to interpret sysbench numbers) Some storage performance made with a good 20AWG rated USB cable between board and my 5V/2A PSU (USB performance shitty since only USB2 and no UAS available with SinoVoip OS images, SATA performance shitty due to Allwinner's SATA implementation being slow): https://pastebin.com/24tTn05L Gigabit Ethernet performance: 654 Mbits/sec in TX direction and 866 Mbits/sec in RX direction (I did not try to tune settings but simply used the stupid SinoVoip defaults). Same shit show as with A20 on the older Bananas: networking is faster in RX direction while with SATA it's the opposite. So in NAS use cases when you need both Ethernet and storage bandwidth at the same time you're always bottlenecked by one of the two): https://pastebin.com/UTT9v9wN Wi-Fi performance not overwhelming (TX 26.6 Mbits/sec, RX 33.5 Mbits/sec, board 1m away from AP), the onboard antenna they use doesn't perform as good as the one on RPi Zero W or RPi 3 (you can't attach an external antenna since SinoVoip's technical documentation consists more or less only of lies like this): https://pastebin.com/AzMtYbFQ  
    The board's advertising consists mostly of lies ('fully compatible to Raspberries and all Raspberry Pi accessories'), same can be said about the 'technical documentation', the hardware vendor doesn't support his own boards (just check the forum: http://forum.banana-pi.org/latest), while the board is already sold they still don't provide schematics (and if they'll provide schematics anytime most probably they cripple them as they did with their R2 board) and the manufacturer also still refuses to merge these pull requests providing tons of security fixes for BPi M2 Ultra and this Berry here.
     
    In other words: customers of this hardware must be absolutely clueless to buy it (trusting in false advertising and not doing any research before) while open source developers must even be stupid starting to work on this hardware given the above problems.
     
    Final remarks: V40 SoC without heatsink idles at +55°C which seems reasonable verifying with 'thumb test', running heavy loads like cpuminer temperature exceeded 80°C but throttling with SinoVoip's OS image is configured to jump in later. DRAM frequency is not 733 MHz as claimed but 576 MHz max (will be lowered by legacy kernel throttling code at high temperatures and can be read out using /sys/devices/1c62000.dramfreq/devfreq/dramfreq/cur_freq), average load of SinoVoip's OS image never goes below 1 as usual (they really repeat every single mistake with every new board again and again) and if you're unfortunate enough to have bought this poor design you should be aware that on their OS image the first 60 seconds the below process is occupying a single CPU core fully:
    root@bpi-iot-ros-ai:~# ps auxwww | grep brcm_patchram_plus root 3812 0.0 0.0 3744 548 ? S 15:48 0:00 /usr/bin/timeout 60s /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212/bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1 root 3813 100 0.0 1444 252 ? R 15:48 0:49 /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212 bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1 The PMIC theoretically exposes under-voltage readouts but for whatever reason 0 is the reported value (so 3rd parties trying to support this board and its users can't identify under-voltage situations. This device is a support nightmare with a 2.5" disk connected):
    root@bpi-iot-ros-ai:~# find /sys -name "*_now" | while read ; do > echo -e "${REPLY}: $(cat "${REPLY}")" > done /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/current_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/voltage_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/current_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/voltage_now: 0 Will now take the board back to the seller asking to refund me since the claim 'fully compatible to Raspberry Pi' is just a bold lie. Will take a RPi camera with me to show the staff that it's impossible to use RPi accessories like cameras due to different physical FPC connector.
     
  14. Like
    Tido reacted to zador.blood.stained in Banana Pi Zero   
    No support currently. Unofficial/community support in the future may be possible, but it depends on the vendor providing complete and correct documentation (I'm sure @tkaiser will write something since this is the first thread here discussing this board).
     
    The only similarity is the form factor.
     
    And if your project is multimedia oriented (i.e. using HDMI display or CSI camera) I would strongly recommend staying with the Raspberries.
  15. Like
    Tido got a reaction from Frostbyte in RK3328 Kernel   
    IIRC, because of Log2Ram it will not write to SDcard when it crashes. You would have to write the data/logs to another storage device USB-Stick or something externally.
    Beside with RPi-Monitor you might also be able to collect some data - is WIP.
  16. Like
    Tido reacted to TonyMac32 in ASUS Tinker Board Reboot   
    *Updated 7-23*
     
    ~~All kernels should be fixed at this point, Legacy, Next, and Dev.~~
     
    The ASUS Tinker Board has a big problem with rebooting properly, centered around the SD card power supplies.  Upon issuing a shutdown request, the kernel is turning everything off , including the vmmc regulator.  To make matters worse, vqmmc is set to 1.8 Volts if you use a UHS SD card, and the kernel is not switching it back to 3.3 volts before rebooting, which is required if the Rockchip boot ROM is to communicate with the device.  The result is a hung board in MaskROM mode.
     
    For the Default kernel (4.4), a patch was carried over from the vendor software (quite literally tagged as "HACK" which added a shutdown routine to the rk mmc driver.  It powers vmmc back up, switches vqmmc back to 3.3 volts, then delays for 20 uS or so.  It works on default.
    7-22:  Need to add fix for " echo b > /proc/sysrq-trigger "  ETA:  7-22 or 7-23 7-22:  Adding device check to make certain there are no complications with the MiQi.  Concurrent with sysrq fiq.  Complete and uploaded.  
    For Next/Dev kernels, however, it does not work.  I don't know the full system that well, so I can't comment as to why just yet.  It is also important to note that testing the patch on kernel 4.11/4.12 resulted in a MiQi crash on reboot, wheras I've had confirmed this doesn't appear to be an issue on 4.4.
    7-22: It was determined a day or so ago that the issue was the mmc not being powered down before the hack happened.  Now that is commanded.  7-22: Initial patch broke MiQi, myself and @Myy worked today on figuring it out, trading kernels and patches.  We thought it a good idea to use the device tree platform to discriminate.  Fix is now known, adapting patches and moving them from Dev to Next.  Implemented 7-23:  Rockchip-DEV is now kernel 4.13, reboot patch tested and works.  
    Any expertise in this area would be welcome, I'll update this post as things go on.
  17. Like
    Tido reacted to chwe in Powering through micro USB   
    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
     
     
  18. Like
    Tido reacted to Igor in RK3328 Kernel   
    NEXT nightly = 4.12.3, updated this morning.
    https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_desktop_nightly.7z
  19. Like
    Tido got a reaction from lafalken in ASUS Tinker Board Reboot   
    Well, I guess it already fits as it is - so there is no need for me to compile the Kernel?
    Burned the SDcard with armbian 4.12 nightly (unfortunately desktop image, quite large).
    What I did:
    git clone -b Tinkering --depth 1 https://github.com/Miouyouyou/MyyQi cd MyyQi tar cJpvf kernel.tar.xz boot lib usr Followed by: sudo dolphin create a folder on the SDcard (home directory) copy the kernel.tar.xz into that. Connect the UART cable.
    Insert the SDcard in tinker board, Power.
    Boot the tinker board (reboot doesn't work so while extending the SDcard it 'dies').
    Power off - Power on - login as root.
    cd /home/tido/ Unpack all the files: tar xJpvf kernel.tar.xz open a second SSH look into the folder:
    cd /usr/ ls -la copy the files
    cp -r usr/* /usr/ cp -r lib/* /lib/ in the second SSH cd /boot ls -la cd /home/tido/boot/ ls -la cp -r zImage /boot/ cp -r rk3288-tinker.dtb /boot/dtb/ Armbian uses currently not the dtb called: tinker. Instead rk3288-miniarm.dtb rk3288-miqi.dtb. cp -r rk3288-miniarm.dtb /boot/dtb/ cp -r rk3288-miqi.dtb It is actually an easy instruction for everyone
    uname -a
    Linux tinkerboard 4.12.0-rc6-The-Twelve-MyyQi+ #1 SMP PREEMPT Fri Jun 30 19:37:05 UTC 2017 armv7l armv7l armv7l GNU/Linux
     
    UART connection
    reboot, it died at:
    [  OK  ] Started Session c2 of user tido.

    reboot - now I can login
    armbianmonitor -u
    /var/log/armhwinfo.log has been uploaded to http://sprunge.us/NAFa
     
    Is this already in the file ? 
    Add the following boot option to your boot loader : rockchip_tinkerrebootfix=on  
    Just the shutdown
     
     
    reboot command:
     
  20. Like
    Tido reacted to Myy in ASUS Tinker Board Reboot   
    By that time, ASUS will already be using 4.9 kernels !
     
    That said, if
    echo b > /proc/sysrq-trigger  
    works, one workaround will be to put this as the last action before rebooting.
     
  21. Like
    Tido got a reaction from Myy in ASUS Tinker Board Reboot   
    Well, I guess it already fits as it is - so there is no need for me to compile the Kernel?
    Burned the SDcard with armbian 4.12 nightly (unfortunately desktop image, quite large).
    What I did:
    git clone -b Tinkering --depth 1 https://github.com/Miouyouyou/MyyQi cd MyyQi tar cJpvf kernel.tar.xz boot lib usr Followed by: sudo dolphin create a folder on the SDcard (home directory) copy the kernel.tar.xz into that. Connect the UART cable.
    Insert the SDcard in tinker board, Power.
    Boot the tinker board (reboot doesn't work so while extending the SDcard it 'dies').
    Power off - Power on - login as root.
    cd /home/tido/ Unpack all the files: tar xJpvf kernel.tar.xz open a second SSH look into the folder:
    cd /usr/ ls -la copy the files
    cp -r usr/* /usr/ cp -r lib/* /lib/ in the second SSH cd /boot ls -la cd /home/tido/boot/ ls -la cp -r zImage /boot/ cp -r rk3288-tinker.dtb /boot/dtb/ Armbian uses currently not the dtb called: tinker. Instead rk3288-miniarm.dtb rk3288-miqi.dtb. cp -r rk3288-miniarm.dtb /boot/dtb/ cp -r rk3288-miqi.dtb It is actually an easy instruction for everyone
    uname -a
    Linux tinkerboard 4.12.0-rc6-The-Twelve-MyyQi+ #1 SMP PREEMPT Fri Jun 30 19:37:05 UTC 2017 armv7l armv7l armv7l GNU/Linux
     
    UART connection
    reboot, it died at:
    [  OK  ] Started Session c2 of user tido.

    reboot - now I can login
    armbianmonitor -u
    /var/log/armhwinfo.log has been uploaded to http://sprunge.us/NAFa
     
    Is this already in the file ? 
    Add the following boot option to your boot loader : rockchip_tinkerrebootfix=on  
    Just the shutdown
     
     
    reboot command:
     
  22. Like
    Tido got a reaction from Myy in ASUS Tinker Board Reboot   
    Hi @Myy,
    I would like to test, but compiling and such is new to me.
    I saw this in another forum:
    This so called release is not an image but all you need to create a Kernel, right ?
     
    I saw your posting with:

    For someone like me who knows quite a bit but not as much as you do
    Can or must I compile this on my x86 PC and burn it on the SDcard or  ..which is the correct way to proceed?
    Hmm, or is this just the Kernel and DeviceTree that need to be compiled and copied into an armbian 4.12 as example?
  23. Like
    Tido got a reaction from TonyMac32 in ASUS Tinker Board Bluetooth   
    In case you haven't read about it: TinkerOS_Debian V1.9 (Beta version)
    18. Don't hold libsbc1 at 1.3-1 and update to latest libsbc1 since the issue for A2DP has been resolved.
  24. Like
    Tido reacted to zador.blood.stained in Le Potato - new board (S905X based) (crowdfunding)   
    Make the Raspberry Pi great again! 
  25. Like
    Tido reacted to sean.wang in Banana Pi R2   
    For all I did there, I would say I can't represent the whole MediatTek, the contributions mostly comes from those passionates in MediaTek internally
    and the core member in LEDE/Openwrt.  Many people still don't recognize importance gained from open source I admit.  I don't blame them because
    everyone has different experiences for defining what success is for them although I still have a little complaining on them as @tkaiser did it for sinovoip
    why let me do the unnecessary and repetitive thing again wasting so much time and energy if they are done well in the initial.
     
    Instead, I would like to change their mindset as much as possible through upstreaming activity to help to link irrelevant groups among MediaTek internal,
    various communities, existing developers, potential users and so on to produce more chemical changes getting more attention on the importance of open source
    and prove commercial product still can be done well with combining appropriate open source project and finally allow us all together walking on the right path.
     
    Maybe there'll  a lot blames/questions/suggestions on coming bpi-r2, but I will be glad to listen to and reflect them into the MediaTek internal, and even
    welcome delivering patches to me making more robust to BSP
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines