sim900

friis

Senior Member
#1
Hi,
Can anyone point me to a step by step guide in connecting a picaxe (14m2) to a sim900 phone module?
best regards
torben
 

hippy

Technical Support
Staff member
#2
It might depend on the module but it would seem to be; connect the module's 0V to the PICAXE 0V, TXD to PICAXE HSerIn pin, RXD from PICAXE HSerOut pin.

It is probably worth including 1K inline resistors on the TXD and RXD lines.

However, I wouldn't recommend using an M2 chip; I would suggest an X2 so you can take advantage of high speed serial background receive.
 

friis

Senior Member
#3
Hi hippy,
Actually, it is a Goouuu Tech IOT-GA6, but I think that makes no difference.
So, after connecting the wires I should just start issuing AT commands? I tried that with:

Code:
#PICAXE 14M2
#Terminal 19200

Symbol TlfSet           = B.4                   '"SET" pin, when low, places module into command mode
Symbol TXpin            = B.3                   'output to HC-12
Symbol RXpin            = B.2                    'input from HC-12
Symbol TlfBaudRate     = T9600_16               'HC-12 Baud rate

PowerOnReset:
    High TXpin                                                 '??????????
   ' Low TlfSET
    SetFreq M16
    SerTxd( Cr, LF, "Started PowerOnReset", CR, LF )
    pause 4000

MAIN:    
        b1 ="?" : b2 = "?" : b3 = "?" : b4 = "?"
        b5 ="?" : b6 = "?" : b7 = "?" : b8 = "?"
        
        SerOut TXpin, TlfBaudRate, ( "AT+CMGF=1 )
                
        Serin [8000], RXpin, TlfBaudrate, b1,b2,b3,b4,b5,b6,b7,b8
            
        if b1 = "?" OR b1 = "E" Then
            SerTxd( "No response", CR, LF )
        Else
              SerTxd( "R:", b1,b2,b3,b4,b5,b6,b7,b8, CR, LF )
        End if
        
        pause 4000
        goto MAIN

and get:

Started PowerOnReset
No response
No response
No response
No response
No response
R:[FF]???????
R:[00][FF][00][F0][FF][00][FF][1F]
R:[FF]???????
R:[03][FE][00][FF][FF][00][FF][FF]
R:[00][FE][00][FE][EF][00][FF][01]
R:[FF][01][FF][FF][00][00][FF][00]

Some thing wrong with Baud Rate and " High TXpin                                                 '???????????"?
torben
 

lbenson

Senior Member
#4
It would probably be easiest if you connected first to your pc with serial USB. That way you can use puTTY or another terminal program to find the right baud rate, and issue "AT" commands to assure that the module is responding, that it can connect to your carrier, and that you can send and receive SMS messages (for instance).
 

hippy

Technical Support
Staff member
#5
I would second lbenson's suggestion and get it working from a PC terminal program first. Then you can determine what settings you need, what you need to send, what you get back, how long it takes for responses and what those are, what works and what doesn't.

Then, armed with that knowledge and any issues sorted out, you can turn it into something a PICAXE can use. Start with just sending an "AT<eol>" command and checking an "OK" comes back.

A USB-to-UART cable or module will be useful and probably easiest to use. If you have an AXE091 and a physical 9-way COM port or a USB-to-RS232 cable, the 9-way connector at the bottom of the board converts between RS232 and UART compatible signals.
 

friis

Senior Member
#6
Hi,
Using a tty terminal is new to me, but it looks as if the gsm modulen has a mini usb connector on it. Can I connect a usb -> mini usb cable between thr PC and the gsm? The mini connector on the gsm appears to have 5 terminals.
torben
 

hippy

Technical Support
Staff member
#7
Can I connect a usb -> mini usb cable between thr PC and the gsm?
Possibly. Posting a link to the exact module you have and its datasheet will help members answer whether you should and whether doing so will be useful.
 

friis

Senior Member
#8
Hi hippy,
Apparently 115200 is the default baud rate Goouuu Tech IOT-GA6
For hSerSetup I get:

n = ((64000000/115200)/4) - 1 = 138

Ie.

hSerSetuop 138,%000

Is that possible with 14M2?
torben
 

hippy

Technical Support
Staff member
#9
You could just use the B115200_4 pre-defined baud rate constant. That is set to 8 at 4MHz when run through the simulator -
Code:
#Picaxe 14m2
HSerSetup B115200_4,%000
SerTxd( #B115200_4, CR, LF )
Added: The actual baud rate calculations are -

baud = Fosc / ( 4 * (N+1) )

N = ( Fosc / ( 4 * baud ) ) - 1

So, for 4MHz and 115200 baud that's

N = ( 4000000 / ( 4 * 115200 ) ) - 1 = 7.7 ~= 8

That 8 rather than 7.7 (+0.3) gives a baud rate error (+3.9%), so when running at higher baud rates it's usually better to run at higher operating frequencies, for example at 32MHz -

N = ( 32000000 / ( 4 * 115200 ) ) - 1 = 68.4 ~= 68

That's a larger error (-0.4) but a much lower percentage of error (-0.6%)
 
Last edited:

hippy

Technical Support
Staff member
#11
I am not sure why nothing is being seen on the Terminal; that suggests a wiring error.

The HSEROUT polarity will be wrong for what the AXE027 expects but I would have expected it to show some sort of 'meaningless data'.

It is going to be very hard to debug this on a 14M2 because HSEROUT and SERTXD share the same output pin but require different polarities, and you won't be able to issue diagnostic reports using SERTXD without also sending that to the SIM900 module Added: - Actually won't be able to use SERTXD while HSERSETUP is being used.

You ideally need to use a PICAXE which has SERTXD and HSEROUT outputs on different pins.
 

friis

Senior Member
#12
Hi hippy,
I have changed to 28X2 in order to separate hSerOut pin fra sertxd pin.
I have had a lot of problems with the system half-freezing and freezing.
The attached screen shot shows output in the serial terminal and if I had been able start the scope it would have shown a bit or byte passing the screen at regular intervals.
But I cant see the relationship with the "A" sent in the serial terminal.
I have tried different SetFreq, but have been unable to get the desired output ("A").
Does the problem lie with the SetFreq? The baud rate of 115200 seems to be OK.
torben
 

Attachments

lbenson

Senior Member
#13
Your #terminal setting is not related to the hsersetup speed--it is the sertxd speed at the frequency for the chip you are using. For 28x2 with no setfreq command, it should be 9600. (But I admit I do not see exactly what the program is trying to do.)
 

Aries

New Member
#14
Also, you appear to be running the 28X2 at its default setfreq (of 8MHz). In your HSerSetup you should therefore be using B115200_8 and not B115200_4 which was correct for the M2 at its default setfreq (4MHz).
 

friis

Senior Member
#15
Hi hippy,
I got things working - sort of.
Screenshot 1 shows what I have wandering across the scope and the result of sertxd. Screenshot 2 shows the pgm.
If I activate hserin, the pgm stops there and nothing comes to Serial Terminal.
The problem is, that what shows up on the scope does not look as an "A". And the other problem is that the pgm stops at hserin.
Can you help?
"Your #terminal setting is not related to the hsersetup speed--it is the sertxd speed at the frequency for the chip you are using". I thought that the #terminal setting had to keep up with the hsersetup speed?
torben
 

Attachments

hippy

Technical Support
Staff member
#16
I would say forget the SERTXD and what appears on the terminal; that's not showing you anything other than the program is running. Just go for the simplest of programs -
Code:
#Picaxe 28X2
HSerSetup B115200_8, %000
Do
  HserOut 0, ( "U" )
  Pause 100
Loop
On your scope you should see -
Code:
     |<----- 78us ---->|
_____   _   _   _   _   _____
     |_| |_| |_| |_| |_| 

      S 0 1 2 3 4 5 6 7 P
Note that at 115200 baud that burst is only 78us wide so you will have to alter your scope timebase form 5ms per division. The single spike going low in your earlier post is probably your data being sent, just that it's too short to really be observable.
 

friis

Senior Member
#17
Hi hippy,
I still see the occational 1 spike. If I transmit a series of "U" I mostly see a series of 1 spike and occationally 2 spikes.
torben
 

friis

Senior Member
#18
Hi hippy,
I think the oscilloscope I am using (Picaxe's pcscope) may not be good enough or there is something wrong with it. I am checking up on that.
torben
 

hippy

Technical Support
Staff member
#19
You could always temporarily change the B115200_8 to B2400_8 which will increase the period of pulses to near 4ms which should be more easily seen on the scope.
 

hippy

Technical Support
Staff member
#20
It may be that the OSC001 scope analogue input simply isn't good enough to show the 8us bits of 115200 baud; the 20kSa/sec might only go down to 50us, 50kSa/sec down to 20us.

An alternative may be to use the Logic Analyser mode which appears to support 1MSa/sec which should go down to 1us which should be more than enough for an 8us bit time, a 78us period of pulses.
 

hippy

Technical Support
Staff member
#23
I have to get a better scope.
You should be able to do what you want without a scope. A scope is only really useful for checking that something is going to the module or coming back. If data is passing then it should be possible to figure any other problems out without the scope.
 

friis

Senior Member
#24
Hi hippy,
I am curious about what is going on so I got DPScope_II. The result is shown in the 4 screen dumps:

The first screen dump shows the result of sending "U" and the pgm is shown in the second screen dump.
The third screen dump shows the result of sending "A" and the pgm is shown in the fourth screen dump.

The problem is that I recognize "U" in the curve shown ("1" as start bit, "0" as stop bit), but I dont recognize the "A" shown in the curve.

I am also surprised that one can maintain a high transmission speed (115200 b/s) with a relatively low clock frequence.
Can you help?
torben
 

hippy

Technical Support
Staff member
#25
Your screen dumps seem to be missing but with normal UART idle high transmission the waveforms should be -
Code:
                  ___   _   _   _   _   ___
Idle High U = $55    |_| |_| |_| |_| |_|    
                      S 0 1 2 3 4 5 6 7 P
                  ___   _           _   ___
Idle High A = $41    |_| |_________| |_|
                      S 0 1 2 3 4 5 6 7 P
For RS232 idle low -
Code:
                      _   _   _   _   _
Idle Low  U = $55 ___| |_| |_| |_| |_| |___    
                      S 0 1 2 3 4 5 6 7 P
                      _   _________   _
Idle Low  A = $41 ___| |_|         |_| |___
                      S 0 1 2 3 4 5 6 7 P
 

friis

Senior Member
#26
Hi hippy,
As I understand your last message idling high means that the start bit is a 0. And the data are transmitted least significant bit first (sorry I forgot the screen dumps)

I also understand that the transmission speed of the UART is independent of the clock frequency. I assume that the transmission speed must be high enough so that bytes coming in do not overtake the transmission.

I can see (on the scope) that I am transmitting "AT",cr (not when I am connecting to a phone module (Goouuu Tech IOT-GA6) - but that is another problem).

In the example given for hSerIn by Picaxe there is no mention of hSerPtr or hSerFlag. Do I have to deal withn that?
Or can I just retrieve get 0,b0, get 1,b1, ..... (I am using 28X2)

Is there anywhere a basic example of the communication hSerOut/hSerIn (fx. with a mobile phone)?
torben
 

hippy

Technical Support
Staff member
#27
As I understand your last message idling high means that the start bit is a 0. And the data are transmitted least significant bit first
That is correct.

I also understand that the transmission speed of the UART is independent of the clock frequency. I assume that the transmission speed must be high enough so that bytes coming in do not overtake the transmission.
It is more data rate than baud rate which is most important; how quickly characters/bytes are being sent in a stream. If bytes are sent too quickly after each other the PICAXE may not have processed the first before receiving the next and may miss or corrupt that. Using a slower baud rate gives the PICAXE more time to deal with the first before it has to deal with the second. Running at a higher operating speed can also help.

It is more an issue with SERIN than it is with HSERIN.

In the example given for hSerIn by Picaxe there is no mention of hSerPtr or hSerFlag. Do I have to deal withn that?
Or can I just retrieve get 0,b0, get 1,b1, ..... (I am using 28X2)
Both hSerPtr and hSerFlag can be ignored when using HSERIN to read direct to Scratchpad. They really only apply to using Background receive..

Is there anywhere a basic example of the communication hSerOut/hSerIn (fx. with a mobile phone)?
There are some posts on the forum regarding GSM modules including -

https://picaxeforum.co.uk/threads/at-commands-gsm-receive-sms-need-help.29740
 
#28
Hi hippy,
I have copied your pgm and it worked.
Now, however, I get only rubbish - with the same pgm.
I have tried all the frequencies available in the Serial Terminal and I get rubbish on all of them.
Can you see any explanation of this?
torben
 
#30
Hi hippy,
I have now tried for several days using different 28X2 and using different versions of the pgm to run your pgm. The result is seen below. I have added the statement "SerTxd ("hSerPtr: ", @ptr," ",hSerPtr,cr,lf)".

Started.....
hSerPtr: [00] [CE]
[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00].....
----
hSerPtr: [00] W
[00][FF][01][FD][00][FF][00][FF][00][00][00][00][00][00][00][00][00][00][00][00][00].....
----
.
.

Connected to the phone:
hSerPtr: [00] [A3]

----
hSerPtr: [00] [A3]

----
hSerPtr: [00] [A3]

----
.
.

I can download the pgm and I have tried the download cable on another system.
I have ordered a SIM900 in the hope that would clear up matters, but since I have seen this work on the current phone I dont think that will change anything.
The scope shows that something is sent, but I dont think it is what I input. If I operate without the phone attached I should at least see the data sent?
Can you help?
torben
 
#32
Hi,
Hermed kode:

Code:
#PICAXE 28X2
#Terminal 9600

hSerSetup B2400_8,%001
pause 2000
SerTxd ("Started.....",cr,lf)

MAIN:
    do
        hSerOut 0, ( "AT+CMGL=",$22,"ALL",$22,CR )
        'hSerOut 0, ( "AT&F",CR )
        pause 2000
        SerTxd ("hSerPtr: ", @Ptr," ",hSerPtr, cr,lf)
        do while ptr <> hSerPtr
            SerTxd (@PtrInc)
        loop
        
        SerTxd (cr,lf,"----",cr,lf)
        

    loop
torben
 

hippy

Technical Support
Staff member
#33
Start with something a little simpler -
Code:
#PICAXE 28X2
#Terminal 9600

hSerSetup B2400_8,%001
pause 2000
SerTxd ("Started.....",cr,lf)
MAIN:
    do
        hSerOut 0, ( "AT",cr )
        pause 2000
        do while ptr <> hSerPtr
            b0 = @ptrInc
            SerTxd ( "Rx", tab, #b0, tab, $22, b0, $22, cr,lf )
        loop
        SerTxd ("----",cr,lf)
    loop
Then try adjusting the B2400_8 baud rate until you hopefully see "O" "K" in the output.

According to the SIM900 datasheet I looked at it says baud rate is 115200, so include B115200_8.

It is not clear if the SIM900 starts in command mode. If you don't see an "OK" with various baud rates try changing HSERSETUP to -
Code:
HSerSetup Bxxxx_8, %001
Pause 2000
HserOut 0, ( "+++" )
Pause 2000
 
#34
Hi hippy,
I have tried 2400, 4800, 9600,19200, 38400, 76800, 115200 together with _4, _8, _16 and all I get back is "----". Which means "no answer" I suppose. Since I at one time did get "OK" as the answer to "AT"cr it appears that something has gone wrong with the phone. I have tried "AT&F" (reset).

The thing that disturbs me though is that I get rubish if the phone is not connected - I should get "AT". Right?

I other words, the hSerOut should first fill up the scratch pad area with "AT" and next fill it up with the return (OK) from the phone.

I had trouble reading the scope output, but I think it was not AT.

I assume that 2400_8 both sets the transmission speed and the clock rate?

The compiler rejects hSerSetup Bxxxx_8, %001
torben
 

hippy

Technical Support
Staff member
#36
I have tried 2400, 4800, 9600,19200, 38400, 76800, 115200 together with _4, _8, _16 and all I get back is "----". Which means "no answer" I suppose.
That would seem to be correct.
Since I at one time did get "OK" as the answer to "AT"cr it appears that something has gone wrong with the phone. I have tried "AT&F" (reset).
I would double check the wiring. Especially that the wires are not crossed over.
The thing that disturbs me though is that I get rubish if the phone is not connected - I should get "AT". Right?

I other words, the hSerOut should first fill up the scratch pad area with "AT" and next fill it up with the return (OK) from the phone.
You shouldn't receive anything if the phone is not connected though electrical interference and pick-up might generate some meaningless data.

The Scratchpad only collects what's received, not what's transmitted, unless the SIM900 itself echoes that back.
I assume that 2400_8 both sets the transmission speed and the clock rate?
It sets the baud rate. The frequency is 8MHz by default. You need to adjust that to match the frequency used if there is any SETFREQ command.
The compiler rejects hSerSetup Bxxxx_8, %001
Yes; I was expecting you to change the 'xxxx' to the baud rate value, eg '4800' etc.
 

hippy

Technical Support
Staff member
#37
Maybe I should rather ask what fills in the AT I should see on the screen and what fills in the OK reply, since there is no hSerIn.
HSEROUT sends the "AT", everything received is automatically handled by the background receive code by the PICAXE firmware, specified by the %001 in the HSERSETUP command.
 
#38
Hi hippy,
If I set hSerSetup B115200_8, %001 and connect pin C.6 to U_TXD and C.7 to U_RXD I get the following:

Started.....
RX 0 "[00]"
RX 65 "A"
RX 84 "T"
RX 13 "
"
RX 13 "
"
RX 10 ""
RX 79 "O"
RX 75 "K"
RX 13 "
"
RX 10 ""

----
What a relief! But is that not unusual to connect hSerOut to U_TXD and hSerIn to U_RXD? It did not occur to me.

And I understand that "AT" is echoed back and "OK" is transmitted to the pgm. - no hSerIn needed. I understand things now.

Thank you very much.
torben

PS. I will check the statement HSerSetup Bxxxx_8, %001 when I get the SIM900.
 

hippy

Technical Support
Staff member
#39
What a relief! But is that not unusual to connect hSerOut to U_TXD and hSerIn to U_RXD? It did not occur to me
It is more common to connect hSerOut to an RXD pin, because that's how it is from the device's perspective, but sometimes a pin can be labelled TXD to indicate what it connects from. And, yes, it can be confusing!

And I understand that "AT" is echoed back and "OK" is transmitted to the pgm. - no hSerIn needed. I understand things now.
Almost. Normally "AT<CR>" is send out, "OK<CR><LF>" is echoed back.

In this case it seems the device has its echo on so what is sent is also echoed back; so "AT<CR><CR><LF>OK<CR><LF>" as you are seeing is correct.

Echo can usually be disabled, and it is often easier to parse responses when it is, but I wouldn't worry about that for now. I would replace "AT" with "AT+GMI" or "AT+GMM" to see what they return. They should show the manufacturer and model of the device.

I would also try -
Code:
#Picaxe 28X2
#Terminal 9600
#No_Data
#No_Table

#Macro Send(text)
  SerTxd( "Send : ", text, CR, LF )
  HSerOut 0, ( text, CR )
  Gosub GetReply
#EndMacro

Init:
  HSerSetup B115200_8, %001

Main:
  Pause 2000
  SerTxd( "Started", CR, LF )
  Send( "AT")
  Send( "AT+GMI" )
  Send( "AT+GMM" )
  End

GetReply:
  Pause 2000
  Do While ptr <> hSerPtr
    b0 = @ptrInc
    If b1 = CR And b0 <> LF Then
      SerTxd( CR, LF )
    End If 
    Select Case b0
      Case CR : SertXd( "<CR>"         )
      Case LF : SertXd( "<LF>", CR, LF )
      Else    : SerTxd( b0             )
    End Select
    b1 = b0
  Loop
 
Top