Go Down

Topic: Can't read data from GPS module (Read 4244 times) previous topic - next topic

SurferTim

Here is the other report:
http://arduino.cc/forum/index.php/topic,74835.0.html

Quote
The client instance you refer to is an instance of Client, and its available() method is known to have issues.

Your version has issues. Mine no longer does.
http://arduino.cc/forum/index.php/topic,68624.0.html

PaulS

Quote
Here is the other report:

I've read that thread. You are the one that assumed that Serial.available() was not working.

SurferTim

WE are the the ones that assumed. This was robtillaart in reply #1 of that topic.

Quote
Do you use Serial.Available() in your code (wild guess what could be the problem)

PaulS

Quote
This was robtillaart in reply #1 of that topic.

Rob was asking IF OP was using Serial.available(). I don't see anywhere in his reply anything that suggests that Serial.available() was returning incorrect data.

If Serial.available() was not used, the problem that OP described could happen. So, it was reasonable to ask if Serial.available() was being used.

I don't see how you got from there to the assumption that Serial.available() might have a problem. It's a far simpler function than the Client.available() function, with much less opportunity for error.

SurferTim

@PaulS: Thanks for calling my attention to that other topic. I see new posts were there. I will respond there also in a few minutes.
The test I suggested there did not work. That means he cannot assume the Serial1.available() routine is broken. Only if blocking with my code 0xFF (it should be int type, and 0xFFFF) would straighten out the data stream, but it did not. There may be characters in the buffer, and something is interpreting them as 0xFF.

Nothing returned from a card swiper would be 0xFF. It's all ascii text.


PaulS

Quote
Nothing returned from a card swiper would be 0xFF. It's all ascii text.

Can you make this assumption, without know how the data got on the card? Even if the data is supposed to be ASCII data, there is nothing that prevents an application from storing non-ASCII data, as long as the size of the data matches the size of the type that is supposed to be stored there.

Please don't think I'm picking on you. You do great work in a lot of threads, and help people I've lost patience with.

SurferTim

#21
Oct 10, 2011, 02:29 pm Last Edit: Oct 10, 2011, 02:34 pm by SurferTim Reason: 1
@PaulS: I don't think you are picking on me. I am rarely intimidated. I am just a bit aggressive, and I like my stuff not broken.
I appreciate your input. It always makes me think.  :)

In the times I have swiped a credit/debit card as a test, I don't recall seeing any of the extended character sets. Maybe he is swiping something with 0xFF on it, but the OP has not mentioned that. It appears it is supposed to be ascii text. ??

And a GPS unit for sure is ascii. Right?

If this did not intimidate me, you won't. You should Google search "surfer tim destin florida". This is my favorite:
http://www.myhero.com/go/hero.asp?hero=Dicus_T_sjh_05_ul

Ternevig

I`ll bet you need a MAX232 circuit..

Nothing is wrong with your code. But the electrical interface is wrong.

CompWiz17

I took a shot of the oscilloscope screen, displaying what my simple circuit is doing to convert the signal.  



As you can see, it is working just as it should, first changing the -5v signal, then inverting the whole thing.  The output matches up with the input perfectly, so the signal should be getting through without a problem.  

Is there something else that I need to do to convert the signal from RS-232 to TTL serial?  

CompWiz17

Actually, this might be working.  I rewired everything, and I'm now getting what looks to be actual GPS data through this.  So, from initial appearances, the simple diode, resistor, and not gate converter does in fact work to convert RS-232 to TTL serial. 

I'm going to do a little more testing, and I'll report how it goes.  For now, here's  a shot of the data I'm getting in:


CompWiz17

#25
Oct 13, 2011, 06:05 am Last Edit: Oct 13, 2011, 06:07 am by CompWiz17 Reason: 1
Yes, it works perfectly now.  I took the circuit outside so the gps could get a signal, ran it through the TinyGPS example code, and it started displaying my exact coordinates.  No failed checksums on the data from the GPS either, so it seems that the data is getting through cleanly.  

Thanks to everyone who posted advice.  

And, for future reference, if you do need to connect an RS-232 device to an arduino, if you can get the voltages scaled down to between 0v and 5v, and then invert that, you will get TTL serial data which the Arduino can use.  No MAX232 chip is required.  And, if the device is already putting out -5v and 5v serial data, all you need is a diode, a resistor, and a not gate(or nand gate with the inputs tied together).  

Hmm, I wonder if you could eliminate the NOT gate by simulating one on the arduino using an interrupt.  Would the arduino be fast enough to run that?  I'll have to give it a shot.  

skyjumper

There is corrupted data in that screen shot. If you look closely you'll notice that there are extra end of line characters where they should not be. Between the $ and the end of the checksum ( thats the *XX ) there should be no line breaks.

CompWiz17

Yes, I did notice that.  I wonder why that's happening. 

Fortunately, it doesn't seem to be bothering the tinyGPS library. 

CompWiz17

#28
Oct 15, 2011, 08:41 pm Last Edit: Oct 15, 2011, 09:00 pm by CompWiz17 Reason: 1
Actually, I did realize what's causing that.  

In the modified MultiSerialMega example I was using to test with, I had it insert a line break every 100 characters, so the garbled data didn't just run on forever on one line.  

So, it does seem to be working perfectly.  

Also, emulating a NOT gate on the Arduino(to eliminate having to include that in the circuit) does not seem to work.  I set up an interrupt to function as a NOT gate, but it didn't put out anything close to the signal that it should.  The arduino doesn't seem to be fast enough to do this.  I figured that that would be the case going in, but it was worth a shot to try it. 

I know this is probably really unlikely, but is there any way to tell the arduino to invert the serial data it receives before interpreting it?  

zoomkat

Quote
I know this is probably really unlikely, but is there any way to tell the arduino to invert the serial data it receives before interpreting it?


Why, didn't you say the below when signal inversion was suggested?


The rs232 signal is already being inverted.  
Google forum search: Use Google Advanced Search and use Http://forum.arduino.cc/index in the "site or domain:" box.

Go Up