GPS & TxT 2 Speech.??
TJW
Posts: 5
I am trying to give verbal directions with the text to speech using a GPS module.
The programing part is killing me.
I was trying to use Select and Case commands?
The programing part is killing me.
I was trying to use Select and Case commands?
Comments
The code I was working with is attached.
*I was using the debug first and when it worked I was going to replace debug with the Text to speech commands.
We have ran the demo for both sensor and both function correctly. I noticed there is a Raw mode option, but I don't think that format of the GPS's information is what we need.
GPS is connected to P15 and our Text 2 Speech is connected as the following: SIN = P0 , SOUT = P1, Busy = 2, AIN = P7, AReset = P12
Thanks for the help!
Post Edited (TJW) : 2/18/2010 11:51:45 PM GMT
Does the code work as expected or what is the code currently doing or not doing? Is this all of the program? resaon I ask is that I dont see the EMIC routines; do you have that portion working already?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Respectfully,
Joshua Donelson
www.parallax.com
It currently Says that my destination is south west of me but when I look at the Lat. and Long.
It should say that the Destination is north of me and my Latitude matches because when I ran the demo GPS 1.1 demo my Lat was exact but my long was lower than my destination. About .4 seconds off if I remember correctly.
And yes that is all of the program I have done so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Respectfully,
Joshua Donelson
www.parallax.com
... And I think my problem is MindutesD... The GPS gives Degrees minutes and decimal minutes(minutesD)... I think I need to convert that to seconds but not too sure how to manipulate it.
New Code is below. EMIC says it once and then stops.
Is it possible to implement a short delaytime between 2 text passage i.e. [noparse][[/noparse]say, " Volt ", 0.5 sec delay, " Amp ",EOM]
Thanks foar any help
Daniel
I don't have time to look at your code. But in general, if you want to see if your program is executing certain lines of code, you can stick in simple DEBUG test messages.
DEBUG "here1"
DEBUG "here2"
DEBUG "here3"
Etc.
Then you can see these messages pop up and see that the program is getting to those points. Or if a message does not pop up, see that the program is never getting to that point.
As to the module not saying something twice. You can also try a separate test program which tries to say something twice and not rely on your input. See if the way you are telling it to say these things would work in that manner.
And the inputs you get can be output to the screen with debug messages as well.
The trick is to "isolate" problems. Do isolated testing to see if something *can* work that way. And "see" what is happening with the program while it is executing. DEBUG can allow you to "see" what is going on - if a statement is executing or not - what the values of something is.