lol hello and welcome.
It's not tested but try this one:
include "modedefs.bas"
DEfine OSC 4
buffer var byte[20]
z var byte
x var byte
TRISB= %10001000
portb.4=0
portb.2=0
portb.1=0
serout portb.6,t300,["atz",13]
pause 2000
serout portb.6,t300,["at+cpms=",34,"me",34,13]
pause 2000
serout portb.6,t300,["at+cmgr=1",13]
; wait + sign for 1 second and then store next 2 signs in buffer[0] and buffer[1]
SERIN portb.7,t300,1000,oops,["+"],buffer[0],buffer[1]
portb.1=1 ; port be is high beqause + sign already detected
if buffer(0) ="C" then
portb.2=1
endif
if buffer(1)="M" then
portb.4=1
endif
goto dasasruli
oops: ;no answer from the phone
; do something if there is no answer
dasasruli:
end
I'm new to serial communication, can anyone tell me what does the 34,34,13 do in the below syntax???
serout portb.6,t300,["at+cpms=",34,"me",34,13]
and whats the difference between above and
serout portb.6,t300,["at+cmgr=1",13]
also please tell me does oops block get executed if + is not received ???
SERIN portb.7,t300,1000,oops,["+"],buffer[0],buffer[1]
Best Regards
Jamshid Dastur
Jamshid, The code :
will not work. You should write:["AT+CPMS=ME",13]["AT+CPMS=",34,"ME",34,13]
because ascii code 34 = "
This AT command will set memory "ME" as the sms working place.
This AT command will call a sms in memory location 1["AT+CMGR=1",13]
Yes, If the plus sign is not received, then after one second program will jump to oops label.
Al.
Last edited by aratti; - 11th December 2008 at 19:06.
All progress began with an idea
Can you help me out with one more thing, that is how can i read an sms and store it in an array, lets say an sms contains hi, then which syntax should i use, or if there is some alternative better way...
Syntax1:
buffer var byte[90]
serout portb.6,t300,["at+cmgr=1",13]
SERIN portb.7,t300,1000,oops,["+"],buffer[0],buffer[1]
Syntax2:
buffer var byte[90]
serout portb.6,t300,["at+cmgr=1",13]
for x=1 to 3
SERIN portb.7,t300,1000,oops,buffer(x)
next x
or is there any other way to store the sms in the array,
thanks a lot
Best Regards
Jamshid Dastur
You must send this sms : "123 HI" (123 is the pointer).
Then I suggest the following code:
If everything work, then you should find:Code:buffer var byte[90] SEROUT2 portb.6,3313,["AT^SMGR=1",13] ' Call for sms SERIN2 portb.7,3313,1000,oops,[Wait ("^SMGR:" ),Str buffer \ 5] ' (3313 is baud rate = 300 see PBP manual pag 133) if buffer[1]=48 and buffer[4]=48 then oops ' if no sms has been received then jump to oops label SERIN2 portb.7,3313,[Wait ("123"),Str buffer \ 3] ' If sms is present wait for pointer then load array
buffer[0]=32 (space)
buffer[1]=H
buffer[2]=I
If you want a ready made sms system download it @:http://techni.caliti.es/blog/
Al.
Last edited by aratti; - 12th December 2008 at 13:42.
All progress began with an idea
holy thread resurrection batman...
Yes thats correct, it DOES need the chr(34)'s.............
I just checked this on t610 and t68i and t68
I just restarted doing this all over again, and hit a new issue, after a while the phone stops responding to most commands, but some, ie the simple ones like atz, work...
atz returns ok , at+cfun=1 returns error, at+cmgr1=error, power cycle the phone, they all work again, how am I crashing/confusing it, i dont know, how can i fix it, i dont yet know.....
Last edited by f_lez; - 11th April 2010 at 20:32.
I worked on a project last year where I needed to send a GPS string using PDU mode. I received the GPS string, converted it to PDU mode, then instructed my phone via blue tooth to send the GPS coordinates to my email account. Anyway, when you want to do something like this, you can not hard code the data you want to send obviously because it is always changing. Here is a snippet of the code, pay attention to the octets_to_septets subroutine. Basically PDU mode converts 1 byte into 7 bits for compression, then moves the next byte left 1 bit, etc. The line above the call to the routine, which I have modified so i don't get a bunch of emails from people trying this code, I have hard coded the email address and other configuration bits. Maybe this can be of use to someone.
Code:Loop1: HSerOut ["AT",13,10] HSerIn 3000,Loop1,[Wait("OK")] Print $FE,$C0,"Connected" DelayMS 750 Loop2: HSerOut ["AT+CMGF=?",13,10] HSerIn 3000,Loop2,[Wait("("),Dec Mode] If Mode = 0 Then Print $FE,1,"PDU Mode" If Mode = 1 Then Print $FE,1,"Text Mode" DelayMS 750 Loop3: HSerOut ["AT+CMGF=",Dec Mode,13,10] HSerIn 3000,Loop3,[Wait("OK")] If Mode = 0 Then Print $FE,$C0,"PDU Mode Set" If Mode = 1 Then Print $FE,$C0,"Text Mode Set" DelayMS 750 Print $FE,1,"Waiting For GPS..." Loop4: LoopCount = 0 DelayMS 500 SerIn RX,188,[Wait("$GPRMC,"),Str GPSData\65] If GPSData[10] = "A" Then 'Check for valid position Print $FE,1,"Sending Message..." HSerOut ["AT+CMGS=94",13] HSerIn 10000,Loop4,[Wait(">")] HSerOut ["07913121139418F00100039121F............."] GoSub octets_to_septets DelayMS 1000 HSerOut [26,13,10] HSerIn 10000,Loop4,[Wait("OK")] Print $FE,$C0,"Message Sent" Else Print $FE,$10,GPSData[10] DelayMS 5000 GoTo Loop4 EndIf DelayMS 1000 Loop5: SerIn RX,188,[Wait("$GPRMC,"),Str TIME\6,skip 4,FIX,skip 1,Str LAT\9,skip 1,NS,skip 1,Str LON\10,skip 1,EW,skip 1,Str SPD\5,skip 1,Str HEAD\5,skip 1,Str DATE\6] Print $FE,1 Print $FE,2,"LAT:",Str LAT\9," ",NS Print $FE,$C0,"LON:",Str LON\10," ",EW 'spd = spd * 1.151 Print $FE,$94,"SPD:",Str SPD\5," knots" PrintDate = Mid$(DATE,3,2) + "/" + Mid$(DATE,1,2) + "/" + Mid$(DATE,5,2) PrintTime = Mid$(TIME,1,2) + ":" + Mid$(TIME,3,2) + ":" + Mid$(TIME,5,2) Print $FE,$D4,Str PrintDate," ",PrintTime If FIX = "A" Then Print " " Else Print " -" EndIf DelayMS 350 If FIX = "A" Then Print $FE,$10,"*" DelayMS 150 Inc LoopCount If LoopCount >= 120 Then GoTo Loop4 EndIf GoTo Loop5 octets_to_septets: For i = 0 To Len(GPSData) CurrChar = GPSData[i] If i <> 0 And i // 8 <> 0 Then OctFir = CurrChar << (8 - i // 8) OctCurr = OctFir + OctSec HSerOut [HEX2 OctCurr] OctSec = CurrChar >> (i // 8) Else OctSec = CurrChar >> (i // 8) EndIf Next i Return Stop
Yes if its a pdu mode phone, the you do have to convert, but if you can get the HW side of nokia working it uses text mode.
mind you with the lack of string commands in pbp working in pdu mode is just as easy lol.
the point i made (years ago!) is tha if the data is not changing, and the responses are set, say for like a garage door opener where the only responses could be door open or door closed, then you can pre-encode them and just use them as pdu strings.
Same with the incoming, if the commands coming in are pre-set , ie open door, close door, you can pre-compile the expected expected result and compare the received pdu string to the pre-compiled expected response.
Bookmarks