https://www.allaboutcircuits.com/projects-preview/116984
I made a number of revisions. The following are remaining issues.
1. The "Required Items" section has both "SIM900A GSM module with a working SIM card" and "SIM900A GSM module." I assume that you need only one of those.
2. Please include links for the required items (unless you can't think of anything to link to, or it's extremely common, like wire or a breadboard).
3. The caption for the bar graph says "The most recent 10 readings for onboard temperature and humidity." But there are only nine readings; the first one is just the start-up data.
4. I'm a bit confused about the flowchart: There are two arrows coming from the "Count down minutes and seconds" block. Since there are no conditions attached to these arrows, the flowchart is indicating that two different events happen simultaneously. In general, a flowchart must correspond to the way that code executes in a processor, i.e., each action is followed by only one action, with the action determined by the sequence of instructions or the state of a variable.
5. In the flowchart, "operators" should be "operator's"; also, I don't understand why the welcome message is described as "Awesome" (this occurs also in the text following the flowchart).
6. After the microcontroller schematic, you say, "By doing that, I can add features in the software and hardware without having to etch a new PCB." It seems to me that the test points facilitate hardware changes, but you certainly don't need test points in order to add software features. Maybe this would be a good revision: "By doing that, I can modify functionality or add features without major inconvenience (such as etching a new PCB)."
7. "Instead of turning the PIC on and off, I've added a reset switch." The schematic doesn't show a switch or a button, but rather a connector of some kind (JP5).
8. AAC's standard design practice requires at least one decoupling capacitor for every IC. This applies also to modules that are based on IC functionality and that do not already have decoupling caps. This means that the DHT11 needs a decoupling cap (the datasheet for a similar module, the DHT22, mentions 100 nF as an acceptable value). The LCD module should also have a decoupling cap, unless the module's PCB has one already. However, the decoupling cap will do basically nothing if it is separated from the module by a long wire, so in that case don't bother.
9. We need a link to the SIM900A module that you're using. The language in the article is a bit confusing because SIMCom refers to the chip itself as a “module,” so actually you are working with some sort of development/evaluation board for the SIM900A module.
10. “It is essential to clean the board thoroughly before you start ironing.” I find this caption confusing because it seems to refer to the process of manufacturing the PCB itself, but the caption is attached to an image of a finished PCB with components already installed.
11. “During testing and programming, I tried baud rates up to 57600 and it worked. It wasn't very reliable, but it worked.” This doesn’t inspire much confidence—57600 baud is not exactly high-speed communication. Do you have any idea why the system would experience failures at this higher baud rate?
12. “This commands the module to list the preferred operators. The reply is read into an array, called gsm_buffer. This buffer can hold 40 characters along with the null character. From the reply, we get the operator name.” The first sentence indicates multiple operators, but in the last sentence you say “the operator name,” as if there is only one. Should the last sentence have “names” instead?
13. “Since these commands are sent to the GSM module, and the GSM module communicates with the operator, I've added a two-second delay.” This doesn’t explain exactly why you need the delay. Are you saying that it takes about two seconds for the GSM module to complete its communication with the operator, and the code needs to wait while this communication is taking place?
14. “This is a proprietary SIMCom AT command.” I’m not sure what you mean here. “Proprietary” implies that SIMCom has some sort of special ownership of this command, but I think you are simply indicating that it’s a custom command defined in a SIMCom technical document.
15. How important do you think it is to include the log file? It just looks kind of messy and confusing, and there are typos (spaces before periods, double periods, double space, no space after period, “sucessful” instead of “successful).
16. You use the word “call” with “file” (“PIC calls a file that takes two arguments,” “When this file is called,” “tag calls 1_graph.php”). Maybe this is specialized terminology that I’m not familiar with, but in my experience “call” is used with functions and “open” is used with files. I’m also not familiar with a file “taking arguments.” That again makes me think of a function.
17. A video is theoretically required for all AAC project articles (see page three of the writer’s guide). We don’t like to be too strict with article requirements, and in some cases a video is not as important (such as in Part 1 of a series). But there really should be a video whenever possible. Would you be able to put together some sort of video for this project?
I made a number of revisions. The following are remaining issues.
1. The "Required Items" section has both "SIM900A GSM module with a working SIM card" and "SIM900A GSM module." I assume that you need only one of those.
2. Please include links for the required items (unless you can't think of anything to link to, or it's extremely common, like wire or a breadboard).
3. The caption for the bar graph says "The most recent 10 readings for onboard temperature and humidity." But there are only nine readings; the first one is just the start-up data.
4. I'm a bit confused about the flowchart: There are two arrows coming from the "Count down minutes and seconds" block. Since there are no conditions attached to these arrows, the flowchart is indicating that two different events happen simultaneously. In general, a flowchart must correspond to the way that code executes in a processor, i.e., each action is followed by only one action, with the action determined by the sequence of instructions or the state of a variable.
5. In the flowchart, "operators" should be "operator's"; also, I don't understand why the welcome message is described as "Awesome" (this occurs also in the text following the flowchart).
6. After the microcontroller schematic, you say, "By doing that, I can add features in the software and hardware without having to etch a new PCB." It seems to me that the test points facilitate hardware changes, but you certainly don't need test points in order to add software features. Maybe this would be a good revision: "By doing that, I can modify functionality or add features without major inconvenience (such as etching a new PCB)."
7. "Instead of turning the PIC on and off, I've added a reset switch." The schematic doesn't show a switch or a button, but rather a connector of some kind (JP5).
8. AAC's standard design practice requires at least one decoupling capacitor for every IC. This applies also to modules that are based on IC functionality and that do not already have decoupling caps. This means that the DHT11 needs a decoupling cap (the datasheet for a similar module, the DHT22, mentions 100 nF as an acceptable value). The LCD module should also have a decoupling cap, unless the module's PCB has one already. However, the decoupling cap will do basically nothing if it is separated from the module by a long wire, so in that case don't bother.
9. We need a link to the SIM900A module that you're using. The language in the article is a bit confusing because SIMCom refers to the chip itself as a “module,” so actually you are working with some sort of development/evaluation board for the SIM900A module.
10. “It is essential to clean the board thoroughly before you start ironing.” I find this caption confusing because it seems to refer to the process of manufacturing the PCB itself, but the caption is attached to an image of a finished PCB with components already installed.
11. “During testing and programming, I tried baud rates up to 57600 and it worked. It wasn't very reliable, but it worked.” This doesn’t inspire much confidence—57600 baud is not exactly high-speed communication. Do you have any idea why the system would experience failures at this higher baud rate?
12. “This commands the module to list the preferred operators. The reply is read into an array, called gsm_buffer. This buffer can hold 40 characters along with the null character. From the reply, we get the operator name.” The first sentence indicates multiple operators, but in the last sentence you say “the operator name,” as if there is only one. Should the last sentence have “names” instead?
13. “Since these commands are sent to the GSM module, and the GSM module communicates with the operator, I've added a two-second delay.” This doesn’t explain exactly why you need the delay. Are you saying that it takes about two seconds for the GSM module to complete its communication with the operator, and the code needs to wait while this communication is taking place?
14. “This is a proprietary SIMCom AT command.” I’m not sure what you mean here. “Proprietary” implies that SIMCom has some sort of special ownership of this command, but I think you are simply indicating that it’s a custom command defined in a SIMCom technical document.
15. How important do you think it is to include the log file? It just looks kind of messy and confusing, and there are typos (spaces before periods, double periods, double space, no space after period, “sucessful” instead of “successful).
16. You use the word “call” with “file” (“PIC calls a file that takes two arguments,” “When this file is called,” “tag calls 1_graph.php”). Maybe this is specialized terminology that I’m not familiar with, but in my experience “call” is used with functions and “open” is used with files. I’m also not familiar with a file “taking arguments.” That again makes me think of a function.
17. A video is theoretically required for all AAC project articles (see page three of the writer’s guide). We don’t like to be too strict with article requirements, and in some cases a video is not as important (such as in Part 1 of a series). But there really should be a video whenever possible. Would you be able to put together some sort of video for this project?