Anyone who’s hung around this site for more than a week knows there are certain problems which arise over and over and many are not necessarily posted in the correct category. I’ve been batting around an idea for a ‘Why won’t my project work?’ thread which would list common hardware problems and their usual solutions. You know, grounds not connected, inductive load activation resets processor, split power/ground breadboard rails, etc. Then it occurred to me, there is no FAQ section on this forum. I note this has been mentioned before but maybe it's time for a revisit. And, if ever a forum needed a FAQ it’s this one.
I don’t know exactly what this would look like or where it would be posted, I’m just throwing the idea out for consideration - or ignoring, as the case may be.
note: rhyming alliterative title due to requirement for fifteen characters
How would that work? The FAQ would be a section that is only writable by a user with an elevated trust level (or moderator)? Folks with write access would move exemplar threads into that section? The rest of us could post links to those threads to quickly answer common questions?
To be clear, what I'm suggesting is a FAQ, at this time, for hardware type questions, as mentioned in the opening post. Also, keep in mind this isn't a fully formed idea. Possibly a better category name would be 'troubleshooting'?
Yes, either or both of those. I don't think a free-for-all of answers (and waves of questions by the searchers) would be helpful - too much clutter. FAQs I've seen are brief and focused. Too many contributors would only add confusion.
Sure. Although I think the answers should be curated. What I think is an excellent description of problem X someone else may see as missing something important or just wrong. I haven't got to the 'who does the curating' part yet.
Again, yes. But the idea is to have this available so people can find it on their own and bypass the 1. open a thread, 2. dribble out information, 3, add conditions as we go along, 4. change the goal, 5. frustrate helpers sequence.
An example:
I've checked my breadboard wiring three times and it's exactly as the schematic/example shows and the project still doesn't work.
If you have modules or devices that are part of the circuit and are not mounted on the breadboard check that there is a ground connection between the breadboard circuit and the external circuitry/module. <links to example solutions here>
Check your breadboard to see if it has divided power/ground rails and that they are jumpered if needed. <links/ graphics here>
If using jumpers on the breadboard, check each one to verify it has continuity, ie, it's not broken internally. With your digital multimeter attached, twist it and bend it and pull, gently, on the ends to test that it doesn't have an intermittent fault. In short check that each jumper is actually functioning as a piece of wire. <links/ graphics here>
// end of example faq
Of course, there may be more things which could cause the problem, and could be added to the list but, the ones listed above are very commonly seen.
Just stick with black type. Whatever that was originally is hard to read, and I'm not even at the beach where I'm mostly certain it would be invisible.
I think the Introductory Tutorials would be a good place to put this topic. Maybe call it "What to check when your circuit doesn't work" or something like this.
Given the new rules about submitting a tutorials, then the initial pre-tutorial post could / should be in the General Electronics section.
Many long time posters here have not read the sticky posts in the Introductory Tutorials section to see how this is now done.
I would agree that the site could use a section curated by certain individuals. I don't think it necessarily has to be moderators, they've got enough on their plate. I don't know from a forum software standpoint how you'd make that work. I can understand how an open wiki could turn into a nightmare, but I think we have a couple dozen or more regular contributors who could be counted on to keep things relatively clean.
Laziness. Plain and simple. I won't mince words about it.
Some people want it explained to them, they don't want to have to figure it out. They want someone else to make the connections for them. All their life they've just had to ask and someone took it from them and did it for them. And now that's what they expect of us. How dare you ask them to read something that wasn't written specifically for their problem.
As soon as I see it I hit ignore and move on. Pitiful that lot.
After some thought, though, I think a sticky on multiple topics (especially the hardware oriented ones) would increase visibility. Based on what I've seen of initial posts, tutorials isn't a popular first stop. As in "My multiplexer isn't plexing and there's a topic for that so..."
True, look at how many people actually read the "How to get the best from this forum" sticky post. Even now when first time posters are automatically directed to it, this is often ignored. As is the simple description of the topic posted.
I have the boilerplate phrases
IDE 1.x is for Problems with the Arduino IDE itself NOT your project.
and
You should never post in the Uncategorized section.
So in a way if we all got familiar with the contents of the Tutorials section we could direct people their, more than we do at the moment.
As to the title a friend of mine in publishing was always asking me to write articles with a title of:-
"20 Mistakes we made so you don't have to"
Or what ever number we get to.
I just thought of one that I don't think we have that would be kind of cool. How about a common error message tutorial with posts for how to understand the common stuff.
For instance "not declared in this scope" with a brief explanation of creating variables and scope rules. Nothing too fancy, but enough to catch the easy stuff.
"Expected _ or _ before ___" with a brief explanation about going back to look at the line before and maybe a little bit about semicolons and braces.
"Does not name a type" with a brief explanation about having code inside of a function and what the compiler thinks you are trying to do when you have code that isn't.
I'm sure we could think of a few more. "too many arguments", "void value not ignored", "class does not have member X", "else without previous if".
I know we can't solve all errors just from the message, but maybe a brief explanation of what the message actually means and how to figure out why you got it would help. Maybe some examples.
