ok so admittedly this post is a bit late but like, i haven't been able to actually complete any tasks lately so better late than never
i'm overall kind of upset because it's been very clear lately that pine64 is an embarrassingly amateur operation. i'm literally a college student and the actual definition of jank when it comes to anything with technology, so you can take me calling something amateur pretty seriously
let me be clear i don't want to start any bad discourse or talk trash without evidence. i honestly believe in pine64's mission of creating open independent hardware accessible to everyone, and i want to trust pine64 to achieve this goal. i'm even writing this post on my pinebook pro literally right now. for a long time i looked up to pine64 as a kind of amazing organization that was doing the sort of open hardware work that i thought needed to be done. but it turns out some things about pine64 are just embarrassingly bad, and i'm just disappointed that pine64 consistently displays a lack of attention to important details that seems to be the M.O.
upon readback of this post after drafting it, turns out it is kind of inflammatory so i want to emphasize again that i actually do like pine64 and what they do, but i would seriously like them to do better
i have a pinebook pro. i like my pinebook pro. or at least i want to, but i noticed an issue with the builtin speakers that whenever audio plays, there's always an annoying whine produced by the speakers. a user
@m42uko on the forums tracked this down to a crappy switching regulator that was causing ripple in the power supply of 250-300 mV at frequencies varying from 150-5000 Hz depending on load (http://forum.pine64.org/showthread.php?tid=8242&pid=54313#pid54313)
250-300 mV !!!!
interestingly, the datasheet for this regulator is not available. nobody even knows what kind of regulator it is, or why exactly it's injecting such significant ripple into the circuits that it actually leaks into the audio, or really why it's rippling at anywhere near audio frequency. it seems clear to me that someone at pine64 just slapped a crappy cheapo regulator onto the design without verifying that it wouldn't cause literally obnoxious amounts of EMI first. the entire pinebook pro design seems to be centered around "lol what even is EMI haha never heard of that!!!!"
another audio issue i experienced, luckily fixable, is that the sound quality was just overall extremely poor until i discovered the audio codec parameter for "Stereo Enhancement", which for some reason appears to be enabled by default on new pinebook pros and causes the audio to sound noticeably awful
luckily this issue can be fixed by
sudo amixer sset 'DAC Stereo Enhancement' 0
still on the topic of pinebook pro
sorry this is the topic i can directly speak to the most, having been using my pinebook pro regularly through a lot of this year but i also wanna talk about charging
luckily, unlike a certain other pine64 device here pine64 picked a standard non-configurable TI battery management part that seems to be able to safely charge and discharge the battery without any issues
the problem is as usual complete lack of attention to design parameters. on AC power using the provided 5V/3A power supply, the battery discharges during a lot of normal usage, and will definitely discharge under heavy usage because this part is underpowered. that or the pinebook pro is using more than 15 watts, which i pretty highly doubt unless i'm trying to get it to compile the linux kernel or something. i can't measure power consumption on AC, but on battery with the TLP AC profile applied and firefox + konsole (vim, tmux, etc) open (this is kind of my normal usage) it consumes 2-5 W. as usual, pine64 didn't seem to actually test the part in their design, and didn't even appear to do a basic back of the napkin calculation to figure out if the power requirements of the device could be met by the components!
boom one day your phone goes boom
here's a fun article: https://xnux.eu/log/#017
that is all. i don't have any comment on this because currently i have barely used the pinephone despite intending to spend some time with it (this is kind of the case with most of my projects right now)
but overall this is representative of pine64's general attitude. they provide the hardware (even if the hardware has important design flaws) and expect the community to magically conjure up software solutions that will work post-launch, even when the community doesn't fully understand the hardware or the implications of how they're running it. this is kind of why pine64's attitude of "we don't do the software" isn't sustainable
and again, with the dock situation. pine64 literally didn't bother to do a basic back of the napkin calculation to figure out how much current a docked pinephone would be drawing and compare that to the battery's rated limit. which is again, embarrassingly amateur. this isn't how hardware engineering is supposed to be done, and for having the whole "we don't do software" attitude they sure don't really seem to do hardware either
this really makes me afraid that when i get the pinecil (hopefully!) which for some reason i still actually intend to get, it's just going to immediately explode in my hands. maybe i should just get a regular TS-100 like a normal enby
finally, i want to take a moment to talk about the new reverse engineering effort that pine64 seemed to just dump onto the community recently. the "nutcracker challenge" aims to create a blob-free version of the SDK for a new RISC-V wifi/BLE SoC by promising a free devboard for each contribution made by the community
the problem is this seems to be rather poorly managed and completely ignores potential legal issues surrounding copyright and reverse engineering. i'm not a legal expert, but looking at contributions such as https://github.com/pine64/bl_iot_sdk/pull/30, this is kind of a dangerous precedent as having people look at reverse-engineered blobs and then directly write new code based on those blobs can be construed as copyright infringement, at least in the United States. this is why clean-room methodology is usually employed. i really do not want a situation where the pine64 firmware for this device becomes illegal because of this, but when i raised the issue on the chat the person managing this project (i don't want to potentially dox, but you can go look at the logs of the matrix channel) they seemed to not initially understand the issue, and to date i don't see that there has been a plan or methodology for clean-room design implemented or enforced in this reverse-engineering effort. and like, i should not be the one to tell them this in the first place! i'm a college student!!
so they may very likely end up just creating illegal firmware. another case of blatantly disregarding what should be a pretty baseline issue in this field
where to go from here
honestly, i think pine64 needs to fundamentally shift their attitude towards their role in the community and the level of attention and testing given to their products, as well as the software development lifecycle associated with their products. i fundamentally think that there can be a place for community-driven nonprofit open hardware if managed correctly. and there should be. we need more pine64 philosophy in the world, especially when the usual for-profit hardware vendors continue to release locked down turbo proprietary NDA crap that is completely inaccessible to hackers and tinkerers. but you can't just go around designing and selling hardware with pretty basic engineering issues in it, ignore copyright law, and expect the community to produce all the software for your devices without properly managing that. being community-driven means using your community in empowering ways, not just throwing out a task like the nutcracker challenge with no guidance and no attention to proper methodology and being like, go do it!!! and college students should not be the ones complaining about this on their blogs. i really think things can be better than that
that is all :wq
see this is actually false, this whole blog post is the comment
No comments yet. Be the first to react!