Alarming problem

[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