BasicMicro - Forums

I am working with an Atom 24 the old version, level shifter and max3232. I am not using the level shifter or the max3232 at the same time but individualy.


Version var byte(40) 'Set up array to store data


Main:

serout p1, i9600, [">QVR<"] 'Send command to gps to quiry version

serin p0, i9600, [str Version40] 'Read in and store responce in Version

serout S_OUT, i9600, [str Version40,13] 'Send version out hardware serial port

pause 1000

goto Main

end

The serout works to get the GPS to send the version and the data shows up on the Atom pin but when sent to the terminal I get this:

>¤>¤‰*Ö®®Y· ÒEÚdª”ªªR§N@ÁŠrI$”02^Å’z
Y’‰*Ö®®Y· ÒEÚdª”ªªR§N@ÁŠrI$”02^Å’z
>¤Y’Y’‰*Ö®®Y· ÒEÚdª”ªªR§N@ÁŠrI$”02^Å’z
‰*Ö®‰*Ö®®Y· ÒEÚdª”ªªR§N@ÁŠrI$”02^Å’z
‰*Ö®®Y· ÒEÚdª”ªªR§N@ÁŠrI$”02^Å’z

I have also tried serin p0, N9600. I do not know what exactly O (open drain) is. I double checked the baud rate and thats not the problem. I run into this same issue with both devices. Any suggestions.

I can't remember which way it goes, but there is an invert bit "i" that must be set correctly. You might give it a try until more information is available.

Alan KM6VV

Hello Mike, Alan.
Alan, he is using the "i", in "i9600".

OK, the MAX232 *IS* a level shifter, so I don't see what you mean when you say you use "one or the other" since they are one and the same?! Secondly, S_OUT is not the hardware serial port, it is a fixed GPIO pin that uses bit bang for serial work and is assigned programming duty specifically, communications after the fact (quibble, quibble...).
As for the terminal junk, if you aren't using the MAX232 properly, it's all greek to the PC. Check your MAX232 circuit, and be sure the terminal is set for 9600 Baud rate and 8N1 (8 data bits, No polarity check, 1 Stop bit).
If that doesn't fix things, send us a diagram of your circuit. Unless you're using a commercial development board, in which case tell us what it is so we can get the schematics and follow what you're doing. And which GPS unit are you using?
Later!

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

I am using a Lassen IQ gps. I have checked all the terminal settings and rechecked the circuts. All seem to be right.

One thing to note is the gps is a 3.3v device. I beleive this is not an issue since the Atom's 5v is being converted by the 232 that is powered by 5v then sent to the other 232 (wich is actually a 3232) that is powered by 3.3v.

I threw something together in Eagle but it was quick so I might have a tx/rx pins crossed.

I also have a logic analizer and I seem to be getting the right signals at every pin including p0.

Here is the output from the logic analizer. Taken from P0 and S-out.

Yep. The MAX232 is wired wrong. V+ (pin 2) should go to a cap (C3) WHICH SHOULD GO TO VCC, not GND as in your diagram. This is part of the high voltage pump. Measure your voltages at pins 1, 3, 4 and 5. You should see approx. -6 to -9, and +6 to +9 among these four pins. I bet your high voltages are wrong. By the way, be sure that chip is a 232A if you are using 0.1uF caps in the pump circuits (C1, C2, C3, C4). If using the old MAX232 (no "A"), use 1uF caps. If using polarized caps, observe the pins polarities. If you have installed 0.1uF caps already, and you don't have the 232A version, use a MAX202 if you can't get a MAX232A. It is designed for 0.1uF caps.
Strangely, the MAX3232 IS supposed to have V+ and V- go to GND thru a cap. Live and learn.
Otherwise, the in-out path looks right.

I don't see how you can say you use one chip or the other when your diagram clearly shows both are in use. Leave it that way.

You use the "O", open drain, when you use a microprocessor such that a low out is done by setting the pin low then making it an output in the direction register. Voilas, you get a low level out. BUT when done, in some cases, code can make the direction register set the pin as an input, creating an open-circuit situation. If the other chip is set for input, it is now floating and this is bad. In this case a pullup resistor is provided to bring the receive pin to a high state. Thus the "O" for "open circuit", which forces the previous low output to go to an input and create a high impedance. Supposedly this allows the use of voltages of other than Vcc through a pullup between the chips.

OK, fix the V+ problem on the MAX232(A) and see what happens.
Later!

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

I have double checked the chip. Sparkfun site states it is the Max 3232 but then gives a data sheet for a ICL 3232
http://www.sparkfun.com/datasheets/Comp ... CL3232.pdf

Re reading the data sheet I see I need bigger caps on V+, V- and C2+ C2-. Instead of the .1uf caps I should have .47uf caps.

I measured the voltages of the pins and compared them to the measured voltages of the 3232 running at 3.3v:

3.3v 5v

P1 5.9v .16v
P2 6.17v 5.64v
P3 2.98v -3.6 to -3.3v
P4 5.6v 5v
P5 -.47 to - .53v -3.8v to -3.7v

I have also change c3 to go to vcc and no differance in operation.

I have also used a palm running a terminal emmulator and a store bought TTL converter (not sure wich one or from where) to read the data being sent to atom pin 0. When I do this I can see the incomming data correctly.

Now for the level shifter. I have attached the schematic for this. When I use and the logic analizer I can see the data is sent to the gps. The gps sends the correct responce and the data is showing up on Atom p0 the way it should. Then when sent to the terminal I get the same gibberish. When I connect the palm in the same manner as above I can once again see the data correctlly. If I understand correctly this device does not convert to true 232 levels. I have seen examples of this being done and it seems to have worked. http://www.thefintels.com/aer/mts.htm

One thing I thought of as I type this is that the palm is probably a 3v device. If my high voltages are wrong could I still get readable data with the palm?

My next step will be to replace the caps on the 5v 3232 chip. As for the level shifter I have no ideas on what could be wrong.

Hello again Mike.
You lost all formatting in your voltages chart. I redid them in Notepad to get them aligned properly, then used the "code" feature to keep the formatting. And they still came out screwy in the preview. But now that they're aligned, it is obvious from the values that something is not right. P1 (pin 1?) shows 16V on the 5V part. I have never seen values this high. That doesn't mean it's wrong, just highly suspect. P3 (pin 3?) is positive on one, negative on the other. Take the readings again, please, and confirm they were right. If they're the same, something is wrong.


THEN AGAIN, your PDA works with all this from the input to P0. Which suggests the translation circuits and lassen are right. This suggests the problem lies in the Atom24. This is a module, right? Download the schematic and take readings at the SOUT/SIN pins of the module, pins 1 and 2 respectively. What do the static (no serial traffic) voltages read?

Connect your PDA directly to the module's SOUT and see if the signal reads right. If not, is it the same crud you get at the PC? This indicates the translator circuit on the Atom is bad somehow. If you have an o-scope (doesn't everyone?) look around the module for suspicious signals, like slow or jagged edges and/or bad levels.
If the PDA sees good signal, the problem is your PC's serial port or terminal program.
We'll crack this puppy yet.

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

It should be 1.6v instead of 16v. I will run through your suggestions and post the results.

Thanks again for your time

I went back and rechecked the voltages all are the same as before. P1 is supposed to be 1.6v as noted earlier. The voltage on the S_out pin when no activity is .51v.

I ran a few more tests here are the results.

Test 1 Atom to 3232 to pda

I ran this code:

main:
serout p1, i9600, ["TEST 1234"]
pause 1000
goto Main

The result was TEST 1234 showed up on the pda

Next I added a serin

new var byte
main:

serout p1, i9600, ["TEST 1234"]
serin p0, i9600, [dec new]
serout S_out, i9600, [dec new]
pause 1000

goto Main

The result was TEST 1234 was displayed then I input a number and this also appeared correctlly on both the pda and in the terminal window of the ide.

Test 2 pda to 3232 to lassen

I sent >QVR< from the pda (command for lassen to return the version) to the Lassen through the 3232. I got the correct responce displayed on the pda.

Test 3 S_in S_out with pda

I re ran the code from test one using S-in and S_out. This worked. I aslo ran this using the terminal window in the ide. This also worked.

Test 4 complet circute using pda to display S-out data instead of terminal window in ide.

The result here is the same as before with the same gibberish.

I can get each portion of the circut to work individually but when I combine the two I can not get readable data. I do agree the voltages do look like there is something wrong.

Have eliminated a few things.
The Atom moduel's S_in and S_out work.
There does not seem to be a problem with the pc's serial port.

As a closing thought:
every time through a translation circut (forgive me if my wording is wrong) the signal on the output side is opposite of what it was on the input side? If this is the case when I use the pda at atom pin 0 and was able to get readable data I used a seperate ttl converter. So the input would be flipped again from what it was at Atom pin 0

Hey! Every once in a while I actually stop and STUDY what people have sent me.
I now notice the logic analyzer printouts appear inverted between them. The pin at the processor doing serial communications typically sits high when using "I9600" until it sends out the start bit, at which time it goes low. In this case your S_OUT is backwards. So tell me: Am I right in thinking the signal at S_OUT was -12V to -12V or thereabouts?
Take a reading at S_OUT with a DMM while running a deadhead program like
MAIN
GOTO MAIN
something that doesn't exercise the S_OUT pin, and tell me what the voltage is. It should be a minus voltage. If your analyzer isn't aware it is looking at an RS232 signal, not TTL, it might report erroneous character results.
Also, I pasted your analyzer readings into Word, one above the other, and used two colored lines to compare pulse widths. They are off. So the signals between the two readings are different. i would LOVE to have you do that test again where you read the PIC pins directly, but you run the risk of toasting the PIC with a single short. However, it would really help...

Now, you supplied a chart, but I really need to know what rig you have the Atom plugged into. A picture is worth a thousand words, and is greatly overdue at this point. A couple of pics is even better.
Until then, Ciaos!

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

I printed up the entire post here earlier and started reading it. I first found the analyzer readings inconsistency and jumped on it. Now I read further and find you have already read the voltage at S_OUT and it's entirely wrong as 0.51V. I think we have found your problem if your new reading shows this to be the same.

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

I rechecked the voltage at S_in and it was .51 running main goto main.
I am able to get S_out to work as stated in the previous post
I have attached readings taken from pic pin 3 (TX), pic pin 22 (Atom p1) and Atom pin 1. I have also included a few pics. The Atom is on a lab board and the 3232 is on the perf board. on the right is the gps with its 3232.

Hello Mike.
Life is a series of large co-incidences.
So BMicro mistakenly shipped me the old version of the Atom28M module, Rev B instead of the newest Rev D, which is closer to what you have. I plugged it in, found the serial communications to be OK, then measured the SOUT and SIN. Yep, same values as you read. If I keep shooting myself in the foot like this I will soon have only ankles.

So I printed your recent photos (nice job by the way), created a chart with the serial wiring on it so I can recreate what you have done so far, and will take the time this weekend to give this all the attention it deserves. Wish I could say why this has eluded me so far. I'll just declare "mea culpa" and come back when I have a solid understanding of the situation.
Later!

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Here is some insight. I changed everything over to a basic stamp to see if I would get the same results. Here is the code I used:

' {$STAMP BS2}
' {$PBASIC 2.5}

Version VAR Byte(10) 'Set up array to store data


Main:
PAUSE 500

SEROUT 1, 84, [">QVR<"] 'Send command to gps to quiry version

SERIN 0, 84, [STR Version10] 'Read in and store responce in Version

PAUSE 1000

SEROUT 16, 84, [STR Version10] 'Send version out hardware serial port

PAUSE 1000

GOTO Main

END

Amazingly this worked like it should with the data showing up correctly.

This leads me to believe there is a problem with the Atom. Somewhere between reading in ,loading the array and sending out. I have sent the data out at both S_out and a different pin with both showing the same junk. I have used different pins to receive the data and that is not the problem either. I have tried using a lower baudrate (4800) and that did nothing either.

The frustrating part is I can get it to work when using Atom to 3232 to pda. But as soon as the information is comming from the gps it won't work.

I know there is some difference in the serin/serout command between the Atom and Stamp. With the Stamp I used 8-n-1 true with the Atom I have been using i9600. This seems opposite of each other. but when I use n9600 with the atom I get less than I do now.