1. On my answering style
Those who think my answer is a "blog" post might like to read the story below.
Some three years ago a newbie asked for an advice on which 9-DOF MEMS sensor to pick. So I wrote a long research report (not a blog!) for his reference.
Adafruit 9-DOF or other accelerometer/magnetometer/gyroscope sensor for Raspberry PI 2/3 with Windows IoT - Viewed 1k times
The OP then asked me the following question:
Is this a blog or what? Never seen an answer so in-depth – ccalboni Apr 18 '19 at 12:30
Well, it is an answer.
A blog is usually a dated diary, with personal opinions. My answer is rather objective, with comprehensive research notes (that is why long and deep), and why I suggest this not that.
When comparing two sensors eg, I list google search counts to convince which is more popular.
And I am digging deep, because I am looking far. I am aware I am writing too long, otherwise I would tell you that the sensor MPU9050 I am recommending is already obsolete! :) invensense.com/wp-content/uploads/2018/10/… – tlfong01 Apr 19 '19 at 7:16
2. On my "long" answers
Those who think my answers are "too long", "not to the point", might like to check out my criteria of length of answer below.
Make your answer as short as possible, but as long as required.
Let me give an example of my short answers.
Raspberry Pi 3b+ do not detect DS18b20 on 1 Wire - Asked 2 years ago, viewed 2k times
The OP complains that he has spent hours without luck on the DS18B20 temperature sense driver. I repeated his experiment and concluded that his driver might be out of date.
Now I could give the one of following three answers:
Your driver is too old, try the new newest.
My configuration works: stretch 19apr08, python 3.5.3, W1ThermSensor V0.3.0.
(a) My configuration works (stretch dated 19apr08, python 3.5.3, W1ThermSensor V0.3.0),
(b) Your 1-Wire cable might be too long, see my photo that works.
(c) You might like to try my debugged python program, with sample output.
I judged that the OP is experienced. So Version 1 should be long enough for him.
However, I usually do not answer for only the OP, but for all the long tail of future newbie readers. So I additionally gave a demo program, written according to the StackOverflow's guideline for the questioners:
MCVE (Minimal, Comprehensive, Verifiable, Example).
Actually my guideline is one longer: ALSO GIVE A SAMPLE OUTPUT, so it is MCVES! :)
3. More on why I write long, and not short answers
So the above Q&A on DT driver shows that I can write vert short, to the point answer for the expert OP, or longer answer for regular readers, or even longer answers for the newbies who do't know what is going on, or don't know what they don know. Actually my answer mentioned above was followed by a couple of follow up answers, on the same laser focused topic of 1-W DS18B20, on the FAQ problem why multiple devices were not detected, problems encountered on different packages etc. I even went one step further on the DS18B20 extension module with buffers/extenders for extremely long wires, for industrial grade building automation application engineers.
Let me show you another recent example on how I can either write very short or very long answers. This is the link to the Q&A:
Is it necessary to use a pull down resistor with this BTS7960? - Asked 4 days ago Active yesterday Viewed 135 times
Actually I could give a very short, a bit rude answer as:
No, already built in.
Though I did give a more friendly, helpful answer as below:
#sanier, I checked that your bts7960 input pins should have already pulled down: https://i.imgur.com/1PuTkGX.jpg. Have a great weekend. Cheers. – tlfong01 21 hours ago
The point is that I need to do "research" (not blog) for over 10 hours to investigate the OP problem. I then wrote long paragraphs on my research, for the benefit of a long tail of future newbies not frying any more their expensive motor driver modules because of using possibly a problematic wiring/control schemes, which I think is a "huge EE circuit design mistake which I have not seen before and if not warned to newbies, would damage any EE forum's reputation, :) .
To summarize, instead of a very short, simple, up to the point, one word answer: "NO", I wrote a long answer on my research which the mods thought was a blog and locked it: :)
4. Another example of my as short as possible answers
Actually I am a huge fan of Occam (Note 1) who say the following:
Make things as simple as possible, but not simpler
Actually my favourite language to teach programming is also called The Occum Programming Language, using UK Open University's teaching material.
Now my story: This morning I answered a ADS1115 ADC question in my favourite "as short as possible" style. The question's link is give below.
How would I go about to troubleshoot the ADS1115's inconsistent readings? Asked today Active today Viewed 22 times
The OP presents his problem very concisely (I would give him 9 out of 10 marks! :)) I read his question twice and skimmed the datasheet and found a possible cause of trouble. So I gave a three sentences long answer, repeated verbatim below:
Now if the problem only appears in the lower mV range, I think it is the FSR（full scale range）not set properly. Please see my datasheet summary on full scale range setting etc in the appendices below.
I know my three sentences answer is already long enough for the OP, but I did length it a bit as I think required: (1) I added a reference to make sure we are referring to the same datasheet. (2) I also gave an appendix to the critical section of the datasheet.
The reference part of course avoids misunderstanding cause by discrepancy of terms of reference. The appendix part is to save the time of the OP and the long tail of future newbie readers going through the boringly long datasheet. In other words, the two required parts making my answer longer are for human efficiency and effectiveness.
By the way, I will later comment on the importance of reference and appendix sections in an answer.
/ to continue, ...