≡
[09:06:48] <Tsvetan> nedko on ftp? ftp://staging.olimex.com/Allwinner_Images/A20-OLinuXino/
[09:38:26] <nedko> Tsvetan: 1.latest_mainline_images/buster/images/ subdir at least has only .7z and .md5 files
[10:14:11] <nedko> Tsvetan: the .asc files and their use for gnupg verification are referenced in the .txt files that where within the .7z files i downloaded via the ftp url
[10:15:39] <nedko> also, i failed to boot the olinuxino-a64 buster images, uboot was loopping early
[10:15:53] <nedko> the board is a 2G ram version
[10:16:58] <nedko> i wrote the image to microsd card and attempted to boot like this
[10:19:12] <nedko> i also did something that was described wrong in the quick start guide. i powered the board via microusb otg (no battery on any peripheral attached), the board seems to be still ok.
[10:19:30] <nedko> *or any perohperal
[10:55:14] <jo0nas> nedko: feeding power via USB-UTG sort-of works, but gets unreliable when stressed - e.g. when plugging in or changing usage of a power-hungty USB device
[10:55:51] <jo0nas> USB-OTG
[12:00:44] <nedko> jo0nas: useful, thanks :)
[12:01:20] <nedko> loading uboot fails early, but spl seems to at least kind of working
[12:01:31] <nedko> i saw 2G RAM mentioned
[12:02:14] <nedko> no so on arm64 build from alpine, which was for another board and detected 0 DRAM
[12:02:23] <jo0nas> anything failing while using USB-OTG, please explicitly mention that you are doing it with flaky power source
[12:02:53] <jo0nas> is uboot failing early with flaky power source or also with reliable power source?
[12:02:58] <nedko> so now i'm building the arm32->aarch64 cross toolchain to build atf bl31 and uboot for the olinuxino-a64
[12:03:45] <nedko> i'm yet to test with reliable power source, and uboot problem indeed may be caused by flaky one
[12:03:57] <jo0nas> or is uboot failing early with a uboot built for another device?
[12:04:58] <nedko> both with the latest buster image from the olimex site and with alpine linux uboot from alpine linux build for different device
[12:05:09] <nedko> just in different way
[12:05:36] <nedko> once i finish the toochain build, will try with latest uboot git
[12:06:15] <nedko> that will hopefully work, given that it is not flaky power issue
[12:07:17] <nedko> it is revision E board with eMMC and 2GiB DRAM
[13:05:37] <Tsvetan> nedko the A64 images on images.olimex.com has not been tested 100% and we shouldn't put them in the release folder, there are number of issues which are fixed and we test the image now to update
[13:06:20] <Tsvetan> the good thing is that simple apt update && apt upgrade + reboot will change your kernel and uboot without writing new images to SD card
[13:06:33] <Tsvetan> just wait couple of days to finish and update
[13:11:16] <Jookia> o/ does the lime2 support power over the USB-OTG port?
[13:17:12] <jo0nas> Jookia: yes, but it is not reliable - use dedicated power jack is the reliable source of power
[13:18:14] <Jookia> ah ok. is there a way to make it more reliable?
[13:19:30] <jo0nas> the chip is designed for mobile devices with little power draw, and the chip includes logic to handle USB-OTG - and Olimex has added additional components to handle more power hungry uses, which requires use of the power jack
[13:20:10] <jo0nas> the way to make USB-OTG more reliable is to build a board around a chip which is designed for more power hungry use
[13:20:17] <Jookia> ah. i'm just having trouble altogether to get it booting
[13:20:24] <jo0nas> :-(
[13:20:44] <jo0nas> step one: forget about USB-OTG - use a "proper" power source
[13:21:07] <Jookia> ethernet phy seems active so i'm not sure it's a power issue
[13:21:08] <jo0nas> step two: use a reliable known working image
[13:21:25] <Jookia> i don't have a 5v psu at the moment, and i tried armbian + the stock image
[13:21:48] <jo0nas> if you insist on experimenting with flaky power source, I will back off and let you discuss that with others
[13:22:34] <Jookia> sure
[13:23:37] <jo0nas> USB2 does not support drawing lots of power - some devices ignore that part of the USB2 spec but it is unreliable even at the specification level
[13:23:55] <jo0nas> USB3 _optionally_ supports drawing more power...
[13:24:27] <Jookia> yeah i just figured it would boot that's all
[13:24:37] <jo0nas> ethernet PHY active is not an indication of power being reliable
[13:24:53] <jo0nas> being able to boot is not an indication of power being reliable
[13:25:04] <jo0nas> problem is power spikes
[13:25:31] <jo0nas> something drawing more-than-average power at some point
[13:25:50] <Jookia> what's the recommended power supply? the website only says 5v
[13:25:58] <jo0nas> maybe randomly a few somethings drawing slightly more-than-usual power accidentally at the same time
[13:26:16] <jo0nas> I believe it says 5V 2A
[13:26:43] <jo0nas> USB2 officially supports only 500mA or something like that
[13:27:37] <Jookia> the website's storage page suggests a 5V1A psu
[13:28:16] <Jookia> neither the storage page nor article specify amperage
[13:28:35] <jo0nas> ah, right
[13:30:03] <Jookia> i do have a 5v 2a psu but it has the wrong cable end, so i may just have to solder something together
[13:30:33] <jo0nas> enjoy!
[13:31:24] <jo0nas> ust don't feed it 12V - I tried that and the power regulator melted
[13:32:16] <jo0nas> (or maybe it was 16V, I don't remember - it was a faulty 5V PSU that just began feeding too high voltage at some point, pretty scary!)
[13:39:20] <Jookia> jo0nas: yeah i promise i won't
[13:40:37] <Jookia> i already run a lime2 as a server from a good power supply and it's never failed on me, i'm just setting up another one for use with GPIOs. i want to try using it for JTAG
[13:41:20] <Jookia> and probably as a more customizable serial cable :P
[13:42:06] <Jookia> i might attach a battery to it eventually so i can get some portability
[13:43:44] <Jookia> i noticed my board has an unpopulated SPI slot, so i might try that unless there's errata with rev k that means it wouldn't work
[13:44:37] <Jookia> i'm kind of just accepting at this point that my life is now embedded linux
[13:50:33] <jo0nas> :-)
[13:52:05] <jo0nas> I stand corrected regarding USB2 max. power draw: Seems there's a battery charge spec supporting up to 5A draw on USB2 - but that's _optional_ and very likely unsupported by the A20 SoC
[14:34:12] <nedko> Tsvetan: ok. thank you!
[14:37:57] <nedko> jo0nas: it probably has to be supported by the PMIC chip, which is AX209 in the A20 SoC case
[15:01:20] <Tsvetan> guys USB-OTG can't provide enough power for the boards, specially if you connect something on the USB host or enable Ethernet etc
[15:02:17] <Tsvetan> most of the cables has 0.5 ohm or more, when 300-400mA flow there is voltage drop which makes input voltage less 4.5V and board stop operating, so do not power the board via USB-OTG it's clearly stated in all documents
[15:13:28] <Jookia> Tsvetan: the storage page lacks anything on OTG power, the article notes this under the 'Console login' section (i had to ctrl-f) and the user manual says you can power it via USB OTG
[15:16:11] <Jookia> oops by article i mean the linux install instructions, the actual board article says you can power it by OTG
[15:22:21] <Jookia> maybe it's time to update the documents to be clearer?
[15:54:13] <jo0nas> 3 A64-OLinuXino boards just now arrived at my home - thanks, Tsvetan!
[16:15:25] <jo0nas> ah, so issue is not how much power can be provided by USB cables, but instead that the USB cables draw too much of that power causing voltage drop
[16:20:50] <adjtm_> jo0nas, there is a big difference in resistance in the power line between different usb cables
[16:21:31] <adjtm_> a bad long cable could have nearly 10 times the resistance of a good short cable
[16:22:06] <jo0nas> (I was aware that it was voltage drop being the problem in the end, I am just not strong enough in my very basic knowledge on electric flow: I thought the voltage dropped because the circuit "ran out of power" - i.e. that putting a "bigger" PSU with e.g. 5V 4A would "cover" for a high-resistence cable
[16:22:45] <adjtm_> it doesn't
[16:23:10] <jo0nas> TIL
[16:23:55] <adjtm_> a higher power in the PSU will guarantee a low voltage drop at the PSU output but not at the end of the cable
[16:24:17] <jo0nas> ACTION made his first electronic circuit ~35 years ago, but learned this only today :-/
[16:24:47] <jo0nas> so the voltage is simply divided across serially connected parts?
[16:25:08] <adjtm_> I know very little about usb power specifications, but I think that the PSU can supply up to 5.4V, not every PSU will supply exactly the same
[16:25:43] <adjtm_> jo0nas, the voltage drop in the cable is current*cable_resistance
[16:26:28] <jo0nas> I mean - if the board has 5 times the resistance of the cable towards the board, then voltage for the board is 5/6 of the input voltage?
[16:27:23] <jo0nas> hmm, so I am rambling?
[16:27:27] <adjtm_> so even if the PSU supplies 5.4, with a 1.5Omh cable and 1A you have a 1.5V drop
[16:27:47] <adjtm_> so 3.9 V at the board input
[16:28:32] <adjtm_> I think that good cables have 0.25-0.3 Ohms
[16:28:44] <jo0nas> let me try again, then: you are saying that the voltage drop is independent of the board, can be calculated solely from the resistence of the cable?
[16:29:12] <adjtm_> resistance times the current the board gets
[16:29:45] <adjtm_> the PSU knows nothing about the voltage at the board input
[16:31:19] <jo0nas> so what is "stable" is the current that the board draws (because of the sum of resistence within all circuitry of the board?) and the voltage varies from resitence of the power cable
[16:31:32] <adjtm_> so if your board needs 3A, then you need a cable with about 0.25 Ohms to maintain good input voltage
[16:32:43] <adjtm_> jo0nas, you need to know the maximum current of the board _plus_ the current the devices you connect to it
[16:33:23] <adjtm_> then multiplying for the cable resistance you can calculate the maximum voltage drop
[16:34:27] <jo0nas> ACTION feels embarrassed not paying attention to his uncle 35 years ago - and not really getting it later either
[16:35:33] <adjtm_> all of this is the reason newer usb can negotiate higher voltage supply
[16:36:10] <adjtm_> nobody want thick cables
[16:36:18] <jo0nas> so they actually request for the PSU to raise voltage to counter loss in power cables?
[16:37:58] <jo0nas> "they" being devices supporting newer negotiation protocol like the battery charge addendum to USB2
[16:38:25] <jo0nas> raise voltage _above_ the nominal 5V, I mean
[16:46:57] <adjtm_> jo0nas, it isn't to compensate for cable loss, but for allowing higher power without increasing the current
[16:47:49] <adjtm_> I looked and it seems that newer usb allow up to 20V
[16:48:12] <adjtm_> but it supplies 5V by default to maintain compatibility
[16:48:58] <adjtm_> I think that for higher voltage you need a USB that supports PD (Power Delivery?)
[17:04:01] <jo0nas> sorry, I don't understand the difference - in our present example, using USB-OTG connection with high-resistance USB cable effectively drops voltage at the board below 4V - imagine this was USB3, we could signal through USB "please raise voltage to 7V" to raise voltage at the board to something closer to 5V, no?
[17:05:01] <adjtm_> yes, but you need both a board that supports USB-PD and a PSU that supports it as weel
[17:05:03] <adjtm_> well
[17:05:13] <jo0nas> yes, I understand that
[17:05:41] <adjtm_> and i think that it's only supported in USB3+ with type C connector
[17:05:51] <jo0nas> I am not saying it actually is a solution the the present issue of Jookia missing a proper PSU
[17:06:33] <jo0nas> just trying to understand the mechanism
[17:07:03] <jo0nas> I guess it is similar reason for PoE to be 40V (or is it 48V?)
[17:10:56] <jo0nas> seems I got that right: from Wikipedia article on power-over-ethernet: " needing 5 Volts cannot typically use PoE at 5 V on Ethernet cable beyond short distances (about 15 feet (4.6 m)) as the voltage drop of the cable becomes too significant, so a 24 V or 48 V to 5 V DC-DC converter is required at the remote end."
[17:11:15] <jo0nas> ...or am I confusing things here?
[17:15:41] <Jookia> jo0nas: My solution is to work together a better PSU or something. I'm a little upset about the docs tho
[17:18:12] <jo0nas> then it's good that the products sold by Olimex are hardware boards, not documentation :-D
[17:18:35] <Jookia> yeah i just expected i wouldn't be told it's clear in documentation when it's not
[17:18:44] <jo0nas> oh well
[17:21:08] <jo0nas> ACTION got upset when told that an Olimex image was "the official Debian image" when evidently it was not "official Debian" only "some image based on official Debian and some other sources, released by Olimex"
[17:21:16] <jo0nas> ACTION is a Debian developer
[17:23:02] <jo0nas> ...but it taught me a lesson on paying attention to who is speaking: What is "official" as stated by Olimex can be true even if not true is same statement is issued by Debian
[17:24:17] <jo0nas> so when Olimex says it's clear in the manual then it means it is clear enough for them to not want to waste more attention on further polishing, not necessarily that it is clear to you
[17:25:31] <jo0nas> Olimex not spending massive efforts on polished documentation might help explain the price tags on their products, which I appreciate
[17:25:54] <Jookia> jo0nas: yeah i understand what it means, it's just disappointing
[17:26:13] <jo0nas> ...but I understand the frustration when you hit a problem tied to inferior documentation
[17:26:46] <jo0nas> you did your homework and now you are screwed :-/
[17:26:55] <Jookia> i'm ok with documentation troubles, it's just the being told it's clear
IRC #olimex 2020-05-19
[00:23:06] <nedko> where to find Armbian_5.92.4_Olinuxino-a20_Debian_buster_next_5.2.21.img.asc and Armbian_5.92.1_Olinuxino-a64_Debian_buster_next_5.2.5.img.asc files?[09:06:48] <Tsvetan> nedko on ftp? ftp://staging.olimex.com/Allwinner_Images/A20-OLinuXino/
[09:38:26] <nedko> Tsvetan: 1.latest_mainline_images/buster/images/ subdir at least has only .7z and .md5 files
[10:14:11] <nedko> Tsvetan: the .asc files and their use for gnupg verification are referenced in the .txt files that where within the .7z files i downloaded via the ftp url
[10:15:39] <nedko> also, i failed to boot the olinuxino-a64 buster images, uboot was loopping early
[10:15:53] <nedko> the board is a 2G ram version
[10:16:58] <nedko> i wrote the image to microsd card and attempted to boot like this
[10:19:12] <nedko> i also did something that was described wrong in the quick start guide. i powered the board via microusb otg (no battery on any peripheral attached), the board seems to be still ok.
[10:19:30] <nedko> *or any perohperal
[10:55:14] <jo0nas> nedko: feeding power via USB-UTG sort-of works, but gets unreliable when stressed - e.g. when plugging in or changing usage of a power-hungty USB device
[10:55:51] <jo0nas> USB-OTG
[12:00:44] <nedko> jo0nas: useful, thanks :)
[12:01:20] <nedko> loading uboot fails early, but spl seems to at least kind of working
[12:01:31] <nedko> i saw 2G RAM mentioned
[12:02:14] <nedko> no so on arm64 build from alpine, which was for another board and detected 0 DRAM
[12:02:23] <jo0nas> anything failing while using USB-OTG, please explicitly mention that you are doing it with flaky power source
[12:02:53] <jo0nas> is uboot failing early with flaky power source or also with reliable power source?
[12:02:58] <nedko> so now i'm building the arm32->aarch64 cross toolchain to build atf bl31 and uboot for the olinuxino-a64
[12:03:45] <nedko> i'm yet to test with reliable power source, and uboot problem indeed may be caused by flaky one
[12:03:57] <jo0nas> or is uboot failing early with a uboot built for another device?
[12:04:58] <nedko> both with the latest buster image from the olimex site and with alpine linux uboot from alpine linux build for different device
[12:05:09] <nedko> just in different way
[12:05:36] <nedko> once i finish the toochain build, will try with latest uboot git
[12:06:15] <nedko> that will hopefully work, given that it is not flaky power issue
[12:07:17] <nedko> it is revision E board with eMMC and 2GiB DRAM
[13:05:37] <Tsvetan> nedko the A64 images on images.olimex.com has not been tested 100% and we shouldn't put them in the release folder, there are number of issues which are fixed and we test the image now to update
[13:06:20] <Tsvetan> the good thing is that simple apt update && apt upgrade + reboot will change your kernel and uboot without writing new images to SD card
[13:06:33] <Tsvetan> just wait couple of days to finish and update
[13:11:16] <Jookia> o/ does the lime2 support power over the USB-OTG port?
[13:17:12] <jo0nas> Jookia: yes, but it is not reliable - use dedicated power jack is the reliable source of power
[13:18:14] <Jookia> ah ok. is there a way to make it more reliable?
[13:19:30] <jo0nas> the chip is designed for mobile devices with little power draw, and the chip includes logic to handle USB-OTG - and Olimex has added additional components to handle more power hungry uses, which requires use of the power jack
[13:20:10] <jo0nas> the way to make USB-OTG more reliable is to build a board around a chip which is designed for more power hungry use
[13:20:17] <Jookia> ah. i'm just having trouble altogether to get it booting
[13:20:24] <jo0nas> :-(
[13:20:44] <jo0nas> step one: forget about USB-OTG - use a "proper" power source
[13:21:07] <Jookia> ethernet phy seems active so i'm not sure it's a power issue
[13:21:08] <jo0nas> step two: use a reliable known working image
[13:21:25] <Jookia> i don't have a 5v psu at the moment, and i tried armbian + the stock image
[13:21:48] <jo0nas> if you insist on experimenting with flaky power source, I will back off and let you discuss that with others
[13:22:34] <Jookia> sure
[13:23:37] <jo0nas> USB2 does not support drawing lots of power - some devices ignore that part of the USB2 spec but it is unreliable even at the specification level
[13:23:55] <jo0nas> USB3 _optionally_ supports drawing more power...
[13:24:27] <Jookia> yeah i just figured it would boot that's all
[13:24:37] <jo0nas> ethernet PHY active is not an indication of power being reliable
[13:24:53] <jo0nas> being able to boot is not an indication of power being reliable
[13:25:04] <jo0nas> problem is power spikes
[13:25:31] <jo0nas> something drawing more-than-average power at some point
[13:25:50] <Jookia> what's the recommended power supply? the website only says 5v
[13:25:58] <jo0nas> maybe randomly a few somethings drawing slightly more-than-usual power accidentally at the same time
[13:26:16] <jo0nas> I believe it says 5V 2A
[13:26:43] <jo0nas> USB2 officially supports only 500mA or something like that
[13:27:37] <Jookia> the website's storage page suggests a 5V1A psu
[13:28:16] <Jookia> neither the storage page nor article specify amperage
[13:28:35] <jo0nas> ah, right
[13:30:03] <Jookia> i do have a 5v 2a psu but it has the wrong cable end, so i may just have to solder something together
[13:30:33] <jo0nas> enjoy!
[13:31:24] <jo0nas> ust don't feed it 12V - I tried that and the power regulator melted
[13:32:16] <jo0nas> (or maybe it was 16V, I don't remember - it was a faulty 5V PSU that just began feeding too high voltage at some point, pretty scary!)
[13:39:20] <Jookia> jo0nas: yeah i promise i won't
[13:40:37] <Jookia> i already run a lime2 as a server from a good power supply and it's never failed on me, i'm just setting up another one for use with GPIOs. i want to try using it for JTAG
[13:41:20] <Jookia> and probably as a more customizable serial cable :P
[13:42:06] <Jookia> i might attach a battery to it eventually so i can get some portability
[13:43:44] <Jookia> i noticed my board has an unpopulated SPI slot, so i might try that unless there's errata with rev k that means it wouldn't work
[13:44:37] <Jookia> i'm kind of just accepting at this point that my life is now embedded linux
[13:50:33] <jo0nas> :-)
[13:52:05] <jo0nas> I stand corrected regarding USB2 max. power draw: Seems there's a battery charge spec supporting up to 5A draw on USB2 - but that's _optional_ and very likely unsupported by the A20 SoC
[14:34:12] <nedko> Tsvetan: ok. thank you!
[14:37:57] <nedko> jo0nas: it probably has to be supported by the PMIC chip, which is AX209 in the A20 SoC case
[15:01:20] <Tsvetan> guys USB-OTG can't provide enough power for the boards, specially if you connect something on the USB host or enable Ethernet etc
[15:02:17] <Tsvetan> most of the cables has 0.5 ohm or more, when 300-400mA flow there is voltage drop which makes input voltage less 4.5V and board stop operating, so do not power the board via USB-OTG it's clearly stated in all documents
[15:13:28] <Jookia> Tsvetan: the storage page lacks anything on OTG power, the article notes this under the 'Console login' section (i had to ctrl-f) and the user manual says you can power it via USB OTG
[15:16:11] <Jookia> oops by article i mean the linux install instructions, the actual board article says you can power it by OTG
[15:22:21] <Jookia> maybe it's time to update the documents to be clearer?
[15:54:13] <jo0nas> 3 A64-OLinuXino boards just now arrived at my home - thanks, Tsvetan!
[16:15:25] <jo0nas> ah, so issue is not how much power can be provided by USB cables, but instead that the USB cables draw too much of that power causing voltage drop
[16:20:50] <adjtm_> jo0nas, there is a big difference in resistance in the power line between different usb cables
[16:21:31] <adjtm_> a bad long cable could have nearly 10 times the resistance of a good short cable
[16:22:06] <jo0nas> (I was aware that it was voltage drop being the problem in the end, I am just not strong enough in my very basic knowledge on electric flow: I thought the voltage dropped because the circuit "ran out of power" - i.e. that putting a "bigger" PSU with e.g. 5V 4A would "cover" for a high-resistence cable
[16:22:45] <adjtm_> it doesn't
[16:23:10] <jo0nas> TIL
[16:23:55] <adjtm_> a higher power in the PSU will guarantee a low voltage drop at the PSU output but not at the end of the cable
[16:24:17] <jo0nas> ACTION made his first electronic circuit ~35 years ago, but learned this only today :-/
[16:24:47] <jo0nas> so the voltage is simply divided across serially connected parts?
[16:25:08] <adjtm_> I know very little about usb power specifications, but I think that the PSU can supply up to 5.4V, not every PSU will supply exactly the same
[16:25:43] <adjtm_> jo0nas, the voltage drop in the cable is current*cable_resistance
[16:26:28] <jo0nas> I mean - if the board has 5 times the resistance of the cable towards the board, then voltage for the board is 5/6 of the input voltage?
[16:27:23] <jo0nas> hmm, so I am rambling?
[16:27:27] <adjtm_> so even if the PSU supplies 5.4, with a 1.5Omh cable and 1A you have a 1.5V drop
[16:27:47] <adjtm_> so 3.9 V at the board input
[16:28:32] <adjtm_> I think that good cables have 0.25-0.3 Ohms
[16:28:44] <jo0nas> let me try again, then: you are saying that the voltage drop is independent of the board, can be calculated solely from the resistence of the cable?
[16:29:12] <adjtm_> resistance times the current the board gets
[16:29:45] <adjtm_> the PSU knows nothing about the voltage at the board input
[16:31:19] <jo0nas> so what is "stable" is the current that the board draws (because of the sum of resistence within all circuitry of the board?) and the voltage varies from resitence of the power cable
[16:31:32] <adjtm_> so if your board needs 3A, then you need a cable with about 0.25 Ohms to maintain good input voltage
[16:32:43] <adjtm_> jo0nas, you need to know the maximum current of the board _plus_ the current the devices you connect to it
[16:33:23] <adjtm_> then multiplying for the cable resistance you can calculate the maximum voltage drop
[16:34:27] <jo0nas> ACTION feels embarrassed not paying attention to his uncle 35 years ago - and not really getting it later either
[16:35:33] <adjtm_> all of this is the reason newer usb can negotiate higher voltage supply
[16:36:10] <adjtm_> nobody want thick cables
[16:36:18] <jo0nas> so they actually request for the PSU to raise voltage to counter loss in power cables?
[16:37:58] <jo0nas> "they" being devices supporting newer negotiation protocol like the battery charge addendum to USB2
[16:38:25] <jo0nas> raise voltage _above_ the nominal 5V, I mean
[16:46:57] <adjtm_> jo0nas, it isn't to compensate for cable loss, but for allowing higher power without increasing the current
[16:47:49] <adjtm_> I looked and it seems that newer usb allow up to 20V
[16:48:12] <adjtm_> but it supplies 5V by default to maintain compatibility
[16:48:58] <adjtm_> I think that for higher voltage you need a USB that supports PD (Power Delivery?)
[17:04:01] <jo0nas> sorry, I don't understand the difference - in our present example, using USB-OTG connection with high-resistance USB cable effectively drops voltage at the board below 4V - imagine this was USB3, we could signal through USB "please raise voltage to 7V" to raise voltage at the board to something closer to 5V, no?
[17:05:01] <adjtm_> yes, but you need both a board that supports USB-PD and a PSU that supports it as weel
[17:05:03] <adjtm_> well
[17:05:13] <jo0nas> yes, I understand that
[17:05:41] <adjtm_> and i think that it's only supported in USB3+ with type C connector
[17:05:51] <jo0nas> I am not saying it actually is a solution the the present issue of Jookia missing a proper PSU
[17:06:33] <jo0nas> just trying to understand the mechanism
[17:07:03] <jo0nas> I guess it is similar reason for PoE to be 40V (or is it 48V?)
[17:10:56] <jo0nas> seems I got that right: from Wikipedia article on power-over-ethernet: " needing 5 Volts cannot typically use PoE at 5 V on Ethernet cable beyond short distances (about 15 feet (4.6 m)) as the voltage drop of the cable becomes too significant, so a 24 V or 48 V to 5 V DC-DC converter is required at the remote end."
[17:11:15] <jo0nas> ...or am I confusing things here?
[17:15:41] <Jookia> jo0nas: My solution is to work together a better PSU or something. I'm a little upset about the docs tho
[17:18:12] <jo0nas> then it's good that the products sold by Olimex are hardware boards, not documentation :-D
[17:18:35] <Jookia> yeah i just expected i wouldn't be told it's clear in documentation when it's not
[17:18:44] <jo0nas> oh well
[17:21:08] <jo0nas> ACTION got upset when told that an Olimex image was "the official Debian image" when evidently it was not "official Debian" only "some image based on official Debian and some other sources, released by Olimex"
[17:21:16] <jo0nas> ACTION is a Debian developer
[17:23:02] <jo0nas> ...but it taught me a lesson on paying attention to who is speaking: What is "official" as stated by Olimex can be true even if not true is same statement is issued by Debian
[17:24:17] <jo0nas> so when Olimex says it's clear in the manual then it means it is clear enough for them to not want to waste more attention on further polishing, not necessarily that it is clear to you
[17:25:31] <jo0nas> Olimex not spending massive efforts on polished documentation might help explain the price tags on their products, which I appreciate
[17:25:54] <Jookia> jo0nas: yeah i understand what it means, it's just disappointing
[17:26:13] <jo0nas> ...but I understand the frustration when you hit a problem tied to inferior documentation
[17:26:46] <jo0nas> you did your homework and now you are screwed :-/
[17:26:55] <Jookia> i'm ok with documentation troubles, it's just the being told it's clear
