HSERIN and STR - character encoding

[boban]

Hello, I have strange problem with the encoding of some ascii characters when I am using the STR command.
For characters A-Z and a-z I have no problem, the codes are valid and are the same as ascii encoding.
But for the characters like 0-9 I should get based on the ascii codes $30 - $39 but I am receiving for e.g. character 3 code $37 instead of code $33. What is the problem?

R.

[mackrackit]

Something like this will strip the 3s from 3132333435363738 and write to the variable X1 -X2 so on, 1,2,3,4,5,6,7,8

Might help you figure out what is going wrong. ?


[WAIT("A"),STR NUMS\16]

X1 = (NUMS[1]-"0")

X2 = (NUMS[3]-"0")

X3 = (NUMS[5]-"0")

X4 = (NUMS[7]-"0")

X5 = (NUMS[9]-"0")

X6 = (NUMS[11]-"0")

X7 = (NUMS[13]-"0")

X8 = (NUMS[15]-"0")

[boban]

Hello, Thanks, however, this doesnt answer and explain my problem. What you are doing is simply substracting ascii value 0 ( which should be $30 ) from the character e.g. 1 ( which should be $31 ) so then as a result, you have 1 in the variable. But my issue is wrong ascii code, which is received using the STR function. If in the input string, I have e.g. character "1", I should receive $31, but I am receiving something else, that's the problem. And because I don't know, where in the input string is the character "0" - "9", then I cannot do the trick like you are doing.

[Ioannis]

From where do you get this characters?

Ioannis

[skimask]

What is the problem?
No idea which PIC you are using, if in fact you are using Microchip PIC's...
No idea if you're actually using PicBasicPro, PicBasic, C, straight assembly, or if this section of the forums was just an easy place to put the post...
No idea which type of oscillator your are using on your PIC (internal, external, crystal, resonator, R/C, etc)...
No idea what your code looks like...
No idea what the hardware itself is (for all we know you're trying to send 115.2Kbaud serial over a 2-wire connection for 3 miles)...
http://www.picbasic.co.uk/forum/showthread.php?t=1742

[boban]

Hello skimask,
OK, here are the answers for your questions:
1. I am using PIC 18F2520
2. I am using hw serial at 19200 bps
3. I am using PicBasic Pro 2.49
4. I am using crystal resonator - 4Mhz
5. Here is the code snipplet:

<code>
while 1
for i = 0 to 95
COMMAND[i] = 0
next i
if (PIR1.5==1) then
HSERIN 100, aaaa, [STR COMMAND\96\$0D]
HSEROUT[COMMAND,$0D,$0A]
endif
wend
end
</code>

[skimask]

PicBasicPro 2.49? You must have one of those 'SPECIAL' versions...

Still left out quite a bit of useful information.
Doesn't tell us what hardware is sending the serial to the PIC
Doesn't tell us what kind of oscillator you are using
Doesn't tell us if you are setting up the serial port correctly in the first place
And that snippet isn't very helpful. Who knows what else you've got going on...interrupts, other code that may or may not modify any of the variables involved...etc...

[sayzer]

2. I am using hw serial at 19200 bps

4. I am using crystal resonator - 4Mhz


How does 19200 bps behave at 4MHz?

Would you consider it as safe?


Note:
I think Ski has some "special days" from time to time; and Boban hit one of them.
Ski? :)

[skimask]

How does 19200 bps behave at 4MHz?
Would you consider it as safe?
Note:
I think Ski has some "special days" from time to time; and Boban hit one of them.
Ski? :)

I could've swore that line abouot the resonator wasn't in that post a few minutes ago!

Yes, how does hardware 19,200 run at 4Mhz on a PIC18F2520?
Using one method, you get an +8.51% error in baud rate, doable, sometimes, as long as the sending serial port isn't on the low side, causing the tolerance to be even farther out.
Using the other method, you get a .16% error in baud. The sender has to be out in the weeds to cause that to mess up.
I'm voting for the first method...
It's all in the datasheets on how to set up the serial port using either method...

[boban]

Hello based on the documentation of 18F2520, I can see that for 4 Mhz clock and speed 19.200, I have the bit error only 0.16 - Page 207 of the PDF.

My configuration is

DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 24h
DEFINE HSER_SPBRG 12 'DEFINE HSER_BAUD 19200 on 4 Mhz
DEFINE HSER_CLROERR 1

Boban

And Skimask, I did mistake, I have PBP 2.46 not 2.49. Also for the serial communication, I have on the other side Ethernet module - XPORT direct.

[skimask]

Ok, now we're getting somewhere... Looks relatively normal so far.
All other things equal, I'd say something 'upstream' of the XPORT module is messing with your data, but that's just me and I'm guessing.

Get rid of the STR modifier in your SERIN statement and try just reading RAW data/numbers/characters/etc.
What is HSEROUT going to? Right back to the XPORT module? Is the feedback from the XPORT/PIC how you are verifying that it's sending/receiving data correctly?

And we still haven't seen your REAL code

[Ioannis]

And also no mention of the trasmitting device. If it is not sending the correct numbers in ASCII, we are playing Holmes here...

Ioannis

[boban]

Hello, I have solved the problem. I have discoverred, that each 3rd character received doesn't correspond to the ASCII code. I have tried to change the speed of the communication and it is working. So the problem was, that some of the bits were not readed correctly. Now I am wondering why at 115200 bps it is working, because in the PIC manual is written, that there is 8% error rate at 4 Mhz and 115200 and at 19200 the error rate is only 0.6 %.

[skimask]

Hello, I have solved the problem. I have discoverred, that each 3rd character received doesn't correspond to the ASCII code. I have tried to change the speed of the communication and it is working. So the problem was, that some of the bits were not readed correctly. Now I am wondering why at 115200 bps it is working, because in the PIC manual is written, that there is 8% error rate at 4 Mhz and 115200 and at 19200 the error rate is only 0.6 %.

If that module you're using is a bit fast, say 5% fast, then that 8% might only be 3% combined, whereas with .6%, might actually be 3.4%.
Could be a bunch of different reasons...