|
|
View previous topic :: View next topic |
Author |
Message |
moryoav
Joined: 23 Feb 2014 Posts: 35
|
|
Posted: Thu May 15, 2014 3:59 pm |
|
|
ezflyr wrote: | Hi moryoav,
Hmmm, why is your baud rate back to 2400? I know, you were playing with some other device, and forgot to put it back, right? You know, it *is* possible to maintain multiple programs so that you don't need to keep changing this.....
You seem to be manipulating the hardware handshaking lines. I don't do that, and recommended that you don't either. It's not necessary, and it overly complicates a project that frankly is already on serious life-support.....
You appear to be manipulating the 'On_Key' signal directly with the PIC I/O. That is NOT what the ADH8066 hardware design guide recommends. The hardware design guide recommends using a bipolar NPN transistor for the job. Why have you ignored this advise?
As I said, your project is already in serious jeopardy, and you keep adding more and more unknowns into the mix.....
I monitor the CMD_Rdy, and Net_Rdy signals from the ADH8066 using PIC inputs. Here is a snippet from my power On sequence:
Code: |
// Here we look at both the CMD_Rdy and Net_Rdy signals. If either one is low, we initiate the Power ON
// sequence to the ADH8066 by toggling the 'GSM_Pwr' signal high for 5 seconds. This makes the ADH8066
// On_Key signal go low. We then set 'GSM_Pwr' low, to make the ADH8066 On_Key float.....
if ((!input(CMD_Rdy_Input)) || (!input(Net_Rdy_Input)))
{
fprintf(Diag, "Turning the ADH8066 module ON! Please wait for 15 seconds!\n\r");
output_high(GSM_Pwr);
delay_ms(5000);
output_low(GSM_Pwr);
|
John |
Again, there's my problem. You use "gsm_pwr" but it isn't any pin's name, but an identifier you choose. Same goes to "CMD_rdy_input" and "Net_rdy_input".
How did you declare that those names are related to the GPIO10 and GPIO3 pins? If you would write "output_high(CMD_rdy_input)", would the COMMAND LED stay high? how do i do such thing?
Talking to the gsm like that, THAT's my biggest problem.
Also i took notes of what you said and removed what needed to be removed from the code. I'd like to wait for your answer before going any further with it. |
|
|
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Thu May 15, 2014 9:37 pm |
|
|
Hi moryoav,
*GSM_Pwr* is an output that controls the recommended NPN transistor connected to the On_Key input of the ADH8066. When GSM_Pwr goes 'high' then On_Key is driven 'low'.....
CMD_Rdy and Net_rdy are outputs from the ADH8066 that drive the LEDs on the evaluation board. I read these inputs to determine what state the ADH8066 is currently in.
OK, you need to forget about all this stuff for a moment. There is a pushbutton on the evaluation board that will allow you to manually 'power up' the ADH8066 module, and there are LEDs to show the current status. Don't worry about these functions with your PIC for the moment, and do them manually for now. Concentrate only on communicating with the ADH8066 module via the PIC UART.
Do this:
1. Cycle the power to ADH8066 evaluation board and the PIC.
2. Press and hold the pushbutton on the evaluation board for about 3 seconds.
3. Wait for the yellow 'Cmd_Rdy' LED to illuminate. Does it come on?
4. Wait for the green 'Net_Rdy' LED to illuminate. Does it come on?
5. Send the 'AT\r' sequence to the ADH8066 at 115200 baud, and see if
the module responds with 'OK'. Does this work?
Do it in this order, and don't do anything else. Report back your findings!
John |
|
|
moryoav
Joined: 23 Feb 2014 Posts: 35
|
|
Posted: Fri May 16, 2014 2:01 am |
|
|
ezflyr wrote: | Hi moryoav,
*GSM_Pwr* is an output that controls the recommended NPN transistor connected to the On_Key input of the ADH8066. When GSM_Pwr goes 'high' then On_Key is driven 'low'.....
CMD_Rdy and Net_rdy are outputs from the ADH8066 that drive the LEDs on the evaluation board. I read these inputs to determine what state the ADH8066 is currently in.
OK, you need to forget about all this stuff for a moment. There is a pushbutton on the evaluation board that will allow you to manually 'power up' the ADH8066 module, and there are LEDs to show the current status. Don't worry about these functions with your PIC for the moment, and do them manually for now. Concentrate only on communicating with the ADH8066 module via the PIC UART.
Do this:
1. Cycle the power to ADH8066 evaluation board and the PIC.
2. Press and hold the pushbutton on the evaluation board for about 3 seconds.
3. Wait for the yellow 'Cmd_Rdy' LED to illuminate. Does it come on?
4. Wait for the green 'Net_Rdy' LED to illuminate. Does it come on?
5. Send the 'AT\r' sequence to the ADH8066 at 115200 baud, and see if
the module responds with 'OK'. Does this work?
Do it in this order, and don't do anything else. Report back your findings!
John |
1.done
2.done
3.yes.
4.yes
5.sent AT\r in both ascii and hex, at 115200 baud rate, nothing happens. does network or command LEDs need to blink?
i also tried using Gabriel's code. simplified it so if the CHECK_COM() returns 1 (OK was received), to turn on a LED. didn't work. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|