Alarming problem

[Early1]

Two years ago I built an alarm unit using the flash lab system with a 18F452 running at 20Mhz. It has been in the field on different construction sites since then and has worked flawlesly.

I have built a second one using the flash lab again but with a 18F452 running at 40Mhz. The only other change is the LCD was a 2x16 and now is a 4x40 serial LCD. The keypad the LCD the menue sytem all work as expected but I can not get the GSM modem to send the text messages, which makes the alarm useless.

Surely it can not be the change in chip speed that is causing the problem?

I have tried serin2 serout2, hserin hserout, I have put delays in the instructions and pauses in the program. I have checked and changed about every AT command on the modem and nothing changes.

I have used the LCD to debug the program and the PIC does not seem to be getting any replies from the modem, except the first one. I send AT to the modem the modem replies with OK and the program continues to the next instruction which also requires a reply from the modem and it just stops there.

I have connected to the flash lab with hyperterminal and when I type in the expected replies the program runs and when I use hyperterminal connected to the modem it works as expected. They just will not talk to each other.

???????

Steve

[paul borgmeier]

Oops - After rereading your post, I have no idea - my apologies for the false hope

Paul Borgmeier
Salt Lake City, Utah
USA

[Jerson]

But, recently, I had a similar problem with the baud rate on a different chip. I had the prototype working consistently and everytime on every board I built. But, all the other chips I managed to program did not work. I thought I had bad chips and tried to reconfigure and play with the settings. Everytime the result was just the same. The very first chip(proto) worked well irrespective of the code changes, the others wouldn't. Finally, I narrowed it down to the baud rate. The divider count was off by 1 count. Since you said that you changed the clock to 40MHz, perhaps you could check on the baud rate settings. Perhaps the 40MHz is off???

Jerson

[Acetronics2]

Hi, Steve

few weeks ago,I read on this forum the PLL clock of the PICs was not working so well ... and was very sensitive to power variations.

...

Alain

[Bruce]

Does the new one work if you switch from 40MHz to 20MHz?

[Early1]

Thanks Guys

I have come to the conclusion that faster is not necessarily better. I have read and re-read the 18F452 data sheet and my impression is that at 40Mhz I should be using a higher baud rate but years of using GSM modems at 9600 has taught me that this is a safe reliable connection speed.

Bruce I have ordered a 20Mhz Flash Lab and in due course all will be revealed.

Cheers

[Early1]

Gents

The 20Mhz Flash Lab does not work either.

Hmmmmm.

I can make it work, and the 40Mhz also, by entering the telephone number into the HSEROUT instruction.

HSEROUT[34,"0123456789",34,13]

but the way I want it to work and the way it did work was by using a string variable.

HSEROUT[34,STR TelephoneNo\16,34]

The reason I need it to work this way is because a keypad is used to enter or change the telephone numbers to text and also to store them in the onboard EEPROM.

The real curiosity to me is that both of the above instruction work when connected to hyperterminal.

I have upgraded to the latest version of PBP.

This is all very curious.

[Bruce]

Has your string TelephoneNo been converted to ASCII first?

Except for the first example being terminated with CR, ASCII conversion
handled in-line, and the number of digits dialed, it looks like both should
work the same.

Does something like his work?


STRING VAR BYTE[6]
X VAR BYTE

MAIN:
FOR X = 0 TO 5
STRING[X] = X + "0" ' convert digits to ASCII
NEXT X
HSEROUT [34,STR STRING\6,34]

DONE:
GOTO DONE

[Early1]

Hi Bruce

No I have never included ASCII conversion and yes previously both did work the same. Curious is it not!!

and even more curious is the way that they do both work when connected to hyperterminal.

I will do some more testing tomorrow.

Maybe I need to set the modem to ATE0.

Thanks

Steve

[Early1]

Here is some test code.


define OSC 20 ' set the correct speed here!!
define LOADER_USED 1

define HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h
DEFINE HSER_BAUD 9600
DEFINE HSER_SPBRG 32
DEFINE HSER_CLROERR 1



Teladd var byte
TelephoneNo1 var byte[16]

For Teladd = 0 To 15 ' Read Telephone number in memory

Read Teladd,TelephoneNo1[Teladd]

Next TelAdd


sms:

'THIS WORKS
hserOUT [65,84,13] 'Sending "AT" and Carraige return to GSM module
hserin 5000, SMS,[WAIT("OK")] ' wait for response ok for 5 seconds
hserOUT ["AT+CMGS=",34,"07771716175",34,13] 'Here the GSM module is told the desitnation phone number
hserin 15000,SMS,[WAIT(62)]
hserOUT ["WJ Groundwater Limited One Pump Failed",26]
hserin 15000,SMS,[WAIT(43,67,77,71)]
'AND THIS DOES NOT
hserOUT [65,84,13] 'Sending "AT" and Carraige return to GSM module
hserin 5000, SMS,[WAIT("OK")] ' wait for response ok for 5 seconds
hserOUT ["AT+CMGS=",34,str TelephoneNo1\16,34,13] 'Here the GSM module is told the desitnation phone number
hserin 15000,SMS,[WAIT(62)]
hserOUT ["WJ Groundwater Limited One Pump Failed",26]
hserin 15000,SMS,[WAIT(43,67,77,71)]


serout portc.5,6,[12, "msg SENT"]

[Bruce]

The version that works is sending an 11 digit phone number. The version that
doesn't is sending a 16 digit number that may or may not be in ASCII format.

Does this work?


TelephoneNo1 var byte[16]
X VAR BYTE
Y VAR BYTE

FOR X = 0 TO 10 ' 11 digit phone #
LOOKUP X,["07771716175"],Y
TelephoneNo1[X] = Y
NEXT X

hserOUT [65,84,13] 'Sending "AT" and Carraige return to GSM module
hserin 5000, SMS,[WAIT("OK")] ' wait for response ok for 5 seconds
hserOUT ["AT+CMGS=",34,str TelephoneNo1\11,34,13] 'Here the GSMmodule is told the desitnation phone number
hserin 15000,SMS,[WAIT(62)]
hserOUT ["WJ Groundwater Limited One Pump Failed",26]
hserin 15000,SMS,[WAIT(43,67,77,71)]

[Early1]

Hi Bruce

A couple of very good points you have made there.

I had the same qeries when I originaly wrote the program.

The telephone numbers are stored on the eprom and non digits are padded out with nulls so

012345678912 in the eprom looks like
012345678912______ where _ is null or 0 in hex

the program then loads this data into the telephone variable and when viewed in ICD mode looks like

48
49
50
51
52
53
54
55
56
57
49
50
0
0
0
0
0

Now what happens is that when I use the hserout str function it automaticaly detects the first null and concatinates to 012345678912

and looks like this in hyperterminal AT+CMGS="012345678912"

I was well impressed when it worked, over the moon sort of thing and it was the easiest of many issues to solve. I2C master and slave mode were the hardest by the way.

But this time it does not work.

I will try your suggestions.

I believe that we are foucusing in on the root cause of the issue.

Thanks

Steve

[Early1]

Well changing fro a 16 to 11 character string did the trick, it works.

Thanks

[Bruce]

Great. I think I may have found out why.

Try running this with a terminal program. When you change array elements
11-15 in TelephoneNo1 from ASCII 0's to null characters, it does not output
what you might expect.


DEFINE LOADER_USED 1
DEFINE OSC 4

TelephoneNo1 var byte[16]
X VAR BYTE
Y VAR BYTE

MAIN:
FOR X = 0 TO 10
LOOKUP X,["01234567890"],Y ' 11 digit phone number
TelephoneNo1[X] = Y
NEXT X
FOR X = 11 TO 15 ' Now load unused array elements with something
TelephoneNo1[X] = "0" ' Change this to = 0 VS "0" to see the effect.
NEXT X

HSEROUT [34,STR TelephoneNo1\12,34]
HSEROUT [13,10]
PAUSE 500
GOTO MAIN

' Incorrect
' Outputs this when 11-15 are assigned null chars
' "01234567890"01234567890"01234567890"01234567890"01234567890
' Should be (assuming it continues when reaching the 1st null char #12)
' "01234567890"
' "01234567890", etc,,

' Correct
' Outputs this when 11-15 are assigned ASCII 0's
' "012345678900"
' "012345678900"
' "012345678900"
' "012345678900"
The null characters seem to be screwing up things. Assuming HSEROUT will
drop the 1st null character in your string, then send the next valid characters
afterwards, may be the problem.

It seems to choke after bumping into the 1st null char, and not send the
remainder of data as expected in the HSEROUT line.

Maybe the one that originally worked was with an earlier version of PBP, and
an error has been introduced in the latest version? Could explain why it
worked then and doesn't now with the same code.

[Early1]

Hi Bruce

I could dig out the old computers with the old version of PBP and give it a try.

Unfortunately there a many old computers in various stages of being canibalised in my garage so it could be a bit of a mission. There again the old original PBP flopy disks must be some where.

I will see what I can come up with at the weekend. Being an engineer is a curse some times, one has just got to get to the bottom of an issue no mater what.

Thanks Again

[Early1]

Hi Bruce

The good news is that the alarm is working, my son has built two more one is in the field and the second is ready to go on to a site in London. The Flash Lab is very neat in its simplicity, which is its strength, I would recomend it to anyone. Have you tried one Bruce? :-)

I dug out the original PBP disks and programmed the Flash Lab board and the result was the same, I have to use the correct number of digits for the telephone number to work. So my conclusion is that the change has nothing to do with the Flash Lab board being 40 or 20 Mhz and nothing to do with the program.

The modem is different, on the original alarm I used a siemens M20. I can not test this as I do not have one to hand, they are all out in the field.

Steve

[Bruce]

Hi Steve,

Glad to hear you got everything going.


Have you tried one Bruce?
I use them every day. I designed the Flash-Lab boards...;o}


I dug out the original PBP disks and programmed the Flash Lab board and the result was the same, I have to use the correct number of digits for the telephone number to work. So my conclusion is that the change has nothing to do with the Flash Lab board being 40 or 20 Mhz and nothing to do with the program.
I ran a few tests with older versions, and had the same results. Just doesn't work with null characters like you would expect.