How to put a string value to an array variable? And GPS issues relating.

aladas

I can't find any instance of code which assigns a string, lets us say "ABCD" into an array, let us say MyString VAR Byte(5). I have got the hang of using STR with debug but so far all my experiment with assignment come up with syntax errors. I have searched on the forums and I came across one piece of advice to store a string in EEPROM. Am I being thick, or is this just out of the areas where the BS2 excels?

I am stuck on this point when what I am actually trying to do is see what my EB500 is getting from a bluetooth GPS unit.

Writing this has helped me spot a way round the immediate need for string assignment, but I still wish I knew how to do it.

But now my stuckness comes from trying to read the strings coming in from the GPS unit. The PC with hyperterminal is getting good NMEA sentences in at 9600,8,1,n and the Stamp 2 with the EB500 bluetooth can connect and can detect the GP strings I am waiting for, but after that I only get just a very few bits of what might be GPS speak.

Here is some of the debug output:
This is Connect3GSP.bs2 - for EB500
Trying to connect to 00:16:CF:E6:E4:28
EB500 connected to BT GPS
Apparently connected
.

Mike Green

There are no examples because you have to do it one character at a time. There really are no "strings" in Stamp Basic. You can supply strings as part of many of the output statements, but they're treated specially.

Part of your problem may be that you're trying to receive a sequence of characters at 9600 Baud and the BS2 just can't do that reliably. The best you get is about 4800 Baud or isolated characters at 9600 Baud with pauses in-between.

aladas

Thanks.
Drat!
So I will have to do loops though the index of my array. And use an older serial GPS which works at 4800. (Perish the thought that I might have to buy a Parallax GPS. Well, maybe later.)
In general - from what you have seen of how many different things I want to be able to do, shall I run out of variable space and/or pins, do you think? I knew I was going to need to reuse variable names in a lot of different contexts - aha, but now I have come across the concept of aliases - and pins too. If I want to go all the way would you sugest going to two BS2s or up a level or so? Or adding a pickaxe or three?
regards - A.L.

aladas

But Mike - there is another thing I don't understand - the EB500 embedded bluetooth is incapable of handling baud rates of less than 9600, or so it says, both in the Spec document and the User Manual. Does this mean all communication between the EB500 and the stamp is untrustworthy - which I have not found it to be so far - or is there hardware buffering and flow control - in which case why do these not apply to my GPS situation? Any thoughts. I had decided that even if I could not use the EB500 with the GPS I might anyway be able to use it to link to a cellphone and send SMS status reports back to base. Concluding I would be in trouble above 4800 baud I verified I could put my Sony Ericsson Z310i into any baud rate, which indeed I could, using the AT+IPR command. But if the EB500 can't stoop so low - then what?

Mike Green

The SERIN statement has the capability of using flow control and that can help with this. A lot depends on how much the device will send after CTS goes false. Have a look at the EB500 sample code. I suspect it uses flow control.

A lot depends on how quickly the device feeds characters to the Stamp. Even though the characters may be sent at 9600 Baud, if the device uses 2 stop bits or otherwise pauses a little between characters, the Stamp has a chance to do its stuff. Setting up the formatters, like DEC, is particularly problematic since this can take enough time for the Stamp to miss the next start bit and get out of sync with the data stream.

Do recheck your Baud mode constants.

aladas

Dera Mike - thanks. I have put in a question to my GPS unit's distributor to see if there is any kind of command language which would allow me to drop the rate, or slow things down but as we now know the EB500 won't care, even if I can. On my use of SERIN, which is still very halting, there does not seem to be much I could do. Here is the relevant snippet:

SEROUT 1,84,[noparse][[/noparse]"con 00:0a:3a:25:7e:7d",CR]  'BT GPS
SERIN 0,84,[noparse][[/noparse]WAIT("ACK",CR)]
'Wait for the connection to be established and switch to data mode
WaitForConnection:
  IF IN5 = 0 THEN WaitForConnection
HIGH 6
PAUSE 300
DEBUG "EB500 connected to BT GPS",CR
MyString(4)=0
SERIN 0, 84,[noparse][[/noparse]WAIT ("GP"),STR MyString\4]
DEBUG STR MyString, "..."

This is what produced .

Phil Pilgrim (PhiPi)

Since you're occasionally able to receive the GGA, it's not a baudrate problem. The issue appears to be the BS2 missing the start bit between the WAIT and the beginning of the STR. If you don't mind switching to a different Stamp, the BS2p would be a better choice for two reasons: 1) It is faster and can handle higher baudrates, and 2) it has a buffer area in auxilliary RAM that can handle longer strings.

-Phil

aladas

It feels as if you are right, and if I did get a BS2p I would then have two stamps and hence more pins and more variable and program space. But the business of losing the start bit surely should mean just one rubbish character followed by some good ones. Or does the whole thing get out of balance?

Phil Pilgrim (PhiPi)

Once you lose a start bit, you'll get garbage until the serial receiver can resynchronize. That can often take several characters to happen, depending on the actual data and how many stop bits are sent after each byte. If you had a way to add extra stop bits (or a delay) after each byte, that alone would probably solve your problem.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 3/19/2008 5:28:14 PM GMT

aladas

I am pessimistic about it but trying to find out if my GPS device supports any kind of command set. Otherwise it will have to be the BS2P - or a serial GPS or the parallax one. Or should I start thinking about some other piece of circuitry to interpose between the Stamp and the EB500 to provide buffering or some baudrate change or flow control?
Don't necessarily bother answering this - my mind may have turned into a hamster on a wheel, but that is no reason yours should. Actually of course you obviously won't if you haven't the time or the inclination, but be aware that I do not take your help for granted.