We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
1. I've bought a GSM Modem, containing SIM900 module and successfully able to send AT Commands to it through my PC using Hyperterminal.
2. I also have an 8051 circuitboard with Serial interface and programmed it in C to receive/send(exclusively) strings serially though UART. I'd like to control the state of an led(On/Off) on the circuit board as per the message received. i. For reception of strings(what the program does): a. If the string contains 'On', it should turn on the led. b. If the string contains 'Off', it should turn on the led.
ii. For sending strings: Sends AT commands to the modem.
3. I have written a Java program to send AT commands to hte modem and receive and display the responses from the modem on the console which works perfectly.
4. I interfaced the modem and the 8051 circuit board using RS232 and found that it wouldn't work. Sending On/Off message wouldn't trigger the action to put On/Off respectively the led. So I tried to send AT command to delete the message stored at location '1'(AT+CMGD=1) to the modem, but neither would this work.
5. Hence, in order to troubleshoot the problem I developed another Java program to communicate with my 8051 board. So essentially this 2nd Java rogram of mine simulates the modem. The sending program in 8051 sends the strings and are captured by my Java program and displayed on the console. The response strings from my modem(with the message content) that was captured by my earlier JAva program, I've exactly used them in my 2nd program with the carriage return and line feed characters. This time my C program in 8051 seems to be able to capture the input string properly and take the correct action, i.e turning On/Off the led according to the input.
6. i. PC-GSM MOdem connection: 9600 baud, 8 Data bits, No Parity, 1 Stop bit. Flow Control: None
ii. PC-8051 Board connection: 9600 baud, 8 Data bits, No Parity, 1 Stop bit. Flow Control: None
Kindly suggest what the missing link could be? Why is 8051 not able to communicate with the modem and vice versa? Please do let me know if any more details are required.
Unfortunately, I have neither a sniffer nor 2 com ports, only 1. But as I mentioned earlier both work well when individually connected to the PC. 1 more thing, my modem contains a serial port(also MAX232 ic) & my 8051 board also contains a serial port(with MAX232 ic). Could it be that the signals/power that is transferred between the board & the modem is less than that is required? I somehow feel that that might be the case.
If your board powers the MAX232 with the correct voltage, and you have the correct values for the capacitors connected to it, then the MAX232 will supply correct RS-232 signals.
It's only when a 5V RS-232 transceiver is powered with 3.3V that there is a violation of the transceiver requirements, and the transceiver will not be guaranteed to supply correct signals on the cable.
It's all about contracts. The transceiver manufacturer promises valid RS-232 signals, if you fulfill their list of requirements.
What else could be an issue?? I'm not able to think of more solutions to this problem. When individually connected to pc both work fine, but when connected to each other they don't communicate.
This is where the use of an oscilloscope would give you the required hints why the two boards doesn't communicate. You would see timing, voltages, slew-rate, noise, ...
well, you have everything to try connecting your board with the PC. try that.
Erik
which SPECIFIC '51? show yout timer init and UART init code, I guess your baudrate may be off
"well, you have everything to try connecting your board with the PC. try that."
The OP has already indicated that the units can communicate when connected directly to the PC. But they can't communicate when connected to each other.
And that's where an oscilloscope looking at the RS-232 signals on the outside of the transceiver and the logic-level signals on the inside of the transceiver would quickly indicate what is wrong.
yes, Per I missed that
OP: did you use the same cable for PC-modem, PC-your board, and your board-modem?
Have you consider to use a NULL modem cable ?
Since each device communicates with the PC, this means that each device connects as DCE(and the PC is DTE). When two DCE devices have to communicate to each other then the NULL modem cable is the solution(It turns a DCE to be like DTE).
en.wikipedia.org/.../Null_modem
If the connection uses just 3 wires (TX, RX, GND), then
connect TX to RX, RX to TX and GND to GND between the 2 devices
Of course, serial settings must be the same, baudrate, databits, parity, XON/OFF settings.
...
Unless the two units are "PC" and the OP already is using a null-modem cable. Then a straight or cross-over cable isn't the answer to the problem.
TX connected to TX is one of all the things that would show up if looking at an oscilloscope or using a multimeter because of the fight to control the signal levels - while RX connected to RX would show up as a quite idle signal line.
And if the communication - quite unlikely - is set up to expect RTS/CTS or DSR/DTR then it would be really silent on all signals. But the voltage levels would indicate the incorrect state of the handshake.
Those old communication testers with LEDs for each signal line really did help a lot when quickly indicating cabling issues. Simple, but very effective: www.artekit.eu/.../