 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
 Posted: Thu May 08, 2014 9:56 am |
 |
|
Hi moryoav,
First, the Tx/Rx LEDs on the evaluation board are related to the FTDI USB-to-UART converter IC, which is now disconnected. You should see no activity on these LEDs!
Second, what are the 'Network' and 'Command' LEDs doing? they should be On. If not, you must hold down the 'ONKEY' pushbutton for several seconds to initiate the ADH8066 turn-on sequence. The Command LED indicates that the ADH8066 is ready to communicate with the host processor over the UART interface, and the Network LED indicates that the ADH8066 is ready to communicate with the cellular network. Getting to this point is the next step before you actually try send/receive data to/from the ADH8066.
If you get to this point, the ADH8066 defaults to 115200 baud. Your earlier program was setup that way, but your later program changed the baud rate to 2400. Why?
John |
|
 |
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Thu May 08, 2014 10:03 am |
|
|
| ezflyr wrote: | Hi moryoav,
First, the Tx/Rx LEDs on the evaluation board are related to the FTDI USB-to-UART converter IC, which is now disconnected. You should see no activity on these LEDs!
Second, what are the 'Network' and 'Command' LEDs doing? they should be On. If not, you must hold down the 'ONKEY' pushbutton for several seconds to initiate the ADH8066 turn-on sequence. The Command LED indicates that the ADH8066 is ready to communicate with the host processor over the UART interface, and the Network LED indicates that the ADH8066 is ready to communicate with the cellular network. Getting to this point is the next step before you actually try send/receive data to/from the ADH8066.
If you get to this point, the ADH8066 defaults to 115200 baud. Your earlier program was setup that way, but your later program changed the baud rate to 2400. Why?
John |
oops, my bad! prob because i also ran some codes in EMIC hehe.
anyways, board is on, rx\tx connected, LED is connected. now what? |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Thu May 08, 2014 10:08 am |
|
|
Hi moryoav,
Your last reply is too cryptic, so I really don't know your current status.
Which 'prob' is now solved? 'LED is connected' - what does this mean? Unless you answer my specific questions in a clear manner this process is going to be hopeless!
John |
|
|
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Thu May 08, 2014 10:23 am |
|
|
| ezflyr wrote: | Hi moryoav,
Your last reply is too cryptic, so I really don't know your current status.
Which 'prob' is now solved? 'LED is connected' - what does this mean? Unless you answer my specific questions in a clear manner this process is going to be hopeless!
John |
ah sorry. what i meant is that yes its fixed back to 115200 baud.
i also have a LED connected to a pin of the uC to have an indication when the uC receives an OK from the gsm |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Thu May 08, 2014 10:27 am |
|
|
Hi moryoav,
OK, then what about this part of what I wrote:
| Quote: |
Second, what are the 'Network' and 'Command' LEDs doing? they should be On. If not, you must hold down the 'ONKEY' pushbutton for several seconds to initiate the ADH8066 turn-on sequence. The Command LED indicates that the ADH8066 is ready to communicate with the host processor over the UART interface, and the Network LED indicates that the ADH8066 is ready to communicate with the cellular network. Getting to this point is the next step before you actually try send/receive data to/from the ADH8066. |
John |
|
|
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Thu May 08, 2014 10:41 am |
|
|
| ezflyr wrote: | Hi moryoav,
OK, then what about this part of what I wrote:
| Quote: |
Second, what are the 'Network' and 'Command' LEDs doing? they should be On. If not, you must hold down the 'ONKEY' pushbutton for several seconds to initiate the ADH8066 turn-on sequence. The Command LED indicates that the ADH8066 is ready to communicate with the host processor over the UART interface, and the Network LED indicates that the ADH8066 is ready to communicate with the cellular network. Getting to this point is the next step before you actually try send/receive data to/from the ADH8066. |
John |
i know about the ONKEY. sorry i didn't say sooner. the network and command LEDs do work fine. though i didnt understand exactly what is the difference between them. |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Thu May 08, 2014 10:57 am |
|
|
Hi,
OK, if you are still asking 'what's next?' then I suggest you look at some of Gabriels GSM code. In particular he has a function 'CHECK_COM' that checks to see if a GSM modem correctly responds to the 'AT' command.
Also, did you disable hardware flow control on the ADH8066 evaluation board?
John |
|
|
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Thu May 08, 2014 11:08 am |
|
|
| ezflyr wrote: |
Also, did you disable hardware flow control on the ADH8066 evaluation board?
John |
please explain how just to be sure. sorry again for all the troubles its a project for college and even though im studying mechatronics I got stuck trying to work with this module which is a must have, with a basic knowledge in electronics, and a little time.
I took a glance at gabriel's code and it looks promising. ill try to proceed later as I am not home currently.
please look for a future progress-so-far post, and ALL the thanks in the world for helping! |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Thu May 08, 2014 1:16 pm |
|
|
Hi moryoav,
Don't worry, we were all in your shoes at one time before  !
Unsolder all the remaining jumpers on your evaluation board, and add 1K ohm resistors from the DSR0 and DTR0 signals to Gnd. Then try Gabriel's code!
Good Luck,
John |
|
|
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Sun May 11, 2014 5:42 am |
|
|
unfortunatly, i have tryed several codes based on Gabriel's functions and codes, and did not succeed. also i couldn't find the headers he uses in the example code. (i have no use for the flex_lcd because i dont use any lcd)
im absolutly lost now :( |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sun May 11, 2014 11:36 am |
|
|
Hi moryoav,
When you say "and did not succeed", I have absolutely no idea what you mean by that..... How are you expecting it to work? If you have no feedback whatsoever, or other ability to diagnose what's happening, then you face a long road.....
First, are you absolutely sure the PIC is running? How do you know?
John |
|
|
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Sun May 11, 2014 3:44 pm |
|
|
| ezflyr wrote: | Hi moryoav,
When you say "and did not succeed", I have absolutely no idea what you mean by that..... How are you expecting it to work? If you have no feedback whatsoever, or other ability to diagnose what's happening, then you face a long road.....
First, are you absolutely sure the PIC is running? How do you know?
John |
the general idea of the code is to set a LED high, and if an OK was received after sending "AT\r", the LED should blink. when i ran the code(s) the LED was high, but nothing else happened, meaning either an OK was not received, or the code wasn't written right |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Mon May 12, 2014 6:55 am |
|
|
Hi moryoav,
At this point, it's not clear whether the problem is hardware related, software related, or both. It's a huge undertaking to try to design and debug a project like this via the forum, and very time consuming. If you want to continue, I'll help you out as long as you are willing to follow directions closely, and you are very thorough and precise in your answers.
The first step is to verify that your PIC is running correctly. I assume it's still connected to the ADH8066 Evaluation board, and is receiving power from the board? OK, the first thing you need to do is to forget about powering things via the USB connection. Plug a 12VDC power source into the power connector on the Eval. board, and do this for all subsequent tests. Now, write a small program that blinks the LED you have connected to the PIC at a 1 second On, 1 second Off rate. Run this program and time the flashes of the LED. Is it correct? This is a simple test to tell you that the PIC is actually running, and running at the correct speed.
The next step is to make your PIC communicate with your PC for diagnostics, so you are going to need a MAX232 IC and associated components. Start getting those items together.
Again, be sure to be thorough and precise when you write back to let me know what's happening. If I need to start playing '20 questions', my level of interest in this project will fade very quickly!
John |
|
|
moryoav
Joined: 23 Feb 2014
Posts: 35
|
|
| Posted: Thu May 15, 2014 1:38 pm |
|
|
| ezflyr wrote: | Hi moryoav,
At this point, it's not clear whether the problem is hardware related, software related, or both. It's a huge undertaking to try to design and debug a project like this via the forum, and very time consuming. If you want to continue, I'll help you out as long as you are willing to follow directions closely, and you are very thorough and precise in your answers.
The first step is to verify that your PIC is running correctly. I assume it's still connected to the ADH8066 Evaluation board, and is receiving power from the board? OK, the first thing you need to do is to forget about powering things via the USB connection. Plug a 12VDC power source into the power connector on the Eval. board, and do this for all subsequent tests. Now, write a small program that blinks the LED you have connected to the PIC at a 1 second On, 1 second Off rate. Run this program and time the flashes of the LED. Is it correct? This is a simple test to tell you that the PIC is actually running, and running at the correct speed.
The next step is to make your PIC communicate with your PC for diagnostics, so you are going to need a MAX232 IC and associated components. Start getting those items together.
Again, be sure to be thorough and precise when you write back to let me know what's happening. If I need to start playing '20 questions', my level of interest in this project will fade very quickly!
John |
Sorry for the disappearance, i was focusing on other things...
the pic works just fine, checked and worked with it running other programs.
Instead of mx232, I'm using a usb cdc code. I can not get my hands on those components in the little time i have left for the project. Hope the cdc is not a problem.
I'm pretty sure sending the codes in hex, and not in ascii helps, so I'll keep my eye for it.
also, i tried running this power on code as explained in the datasheet.
the way of speaking to the gsm works, because the command led blinks, though thats the problem-it blinks, and not staying on.
is this way ok?
| Code: | #include <18f2553.h>
#fuses NOWDT, HS, NOPROTECT
#use delay (crystal=24MHz)
#use rs232 (baud=2400, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
void main()
{
printf("output_high(CTS0)"); //CTS high // |||}}}}}}}}}}}}}}}}}}
printf("output_high(DTR0"); //DSR high // |||
delay_ms(200); // |||
printf("output_low(ON_KEY"); //ONKEY LOW // ||| POWER ON SEQUENCE
delay_ms(2000); // |||
printf("output_high(ON_KEY"); //ONKEY HIGH // |||
delay_ms(2500); // |||
printf("output_low(CTS0"); //CTS low // |||
printf("output_low(DSR0"); //DSR low // |||}}}}}}}}}}}}}}}}}}
DELAY_MS(5000);
printf("output_high(CTS0)"); //CTS high // |||}}}}}}}}}}}}}}}}}}
printf("output_high(DTR0"); //DSR high // |||
delay_ms(200); // |||
printf("output_low(ON_KEY"); //ONKEY LOW // ||| POWER OFF SEQUENCE
delay_ms(2000); // |||
printf("output_high(ON_KEY"); //ONKEY HIGH // |||
delay_ms(6000);
} |
|
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Thu May 15, 2014 3:41 pm |
|
|
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 |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
