Whats the difference between DATA

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Hi,
I'm trying to get a PIC to CALL a location message from a Ublox GPS.
I failed prgramming the PIC, and now I'm trying to find why.
Normally the GPS gets programmed and messages can be called using U-center a Ublox program.
What I want to do as an experiment is to mimic Ucenter with a Terminal, then if successful a PIC.
Here's a comparison between what U-center sends to the GPS and what Terminal does.
To me they look the same, but the terminal doesn't work.
Any deas, please?
Cheers, Camerart.
 

Attachments

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Hi,
Using U-center, when a $sentence is polled, it shows the $NMEA sentence in the text screen.
When a Terminal is connected in parallel, and the same STRING of BYTES is sent, a $NMEA sentence shows in U-center TEXT screen, but not on the terminal RX.
So a step forward! I'll try and check all of the U-center programming settings (There a re a lot!) and try to repeat it.
C
 

ericgibbs

Joined Jan 29, 2010
16,790
hi C,
What is the terminal type and the software is it using.? but not on the terminal RX.

Is it TTL levels or RS232 levels

E
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
hi C,
What is the terminal type and the software is it using.? but not on the terminal RX.

Is it TTL levels or RS232 levels

E
Hi E,
It is a USB RS232 to TTL adapter.
EDIT: I have a christmas tree wiring harness, with the GPS, Analyser and 2x FTDI USB adapters.
I tried again today using the second FTDI, and it worked. With U-center disconnected, I sent the required $ sentence, and received the $GNRMC sentence wanted.
Next try a PIC.
EDIT EDIT: Note the $request sentence I used is not from the D/S. I don't know where I found it, but it works. The D/S one doesn't have the correct checksum and doesn't work?
Thanks,
C
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Hi,
The $sentence I send to receive a $NMEA sentence is [ $EIGNQ,RMC*24 ] with CRLF.
In Termite (Computer terminal) I can send this sentence, after checking the tick on the APPEND CRLF box, and the GPS returns a $ sentence.
In Teraterm, this method doen't work, but if I make a MACRO sending this sentence, then the GPS returns a $senyence.

In Termite, if I uncheck the CRLF box and send $EIGNQ,RMC*24\r\n (\r\n = CRLF) instead, it doesn't work.
Any ideas please?
EDIT:
I've found that only LF is needed to work!
I tried my oscilloscope to see if the readings are different from the analyser.
Here is the START and END of [ $EIGNQ,RMC*24 ] (with LF appended by Termite ]
and received an$NMEA sentence.
C
 

Attachments

Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Hi,
Lots of readings, but I still don't know the difference between the DATA that the Terminal sends, and works versus the DATA the PIC sends, that doesn't work, when they look identical to me.
?
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Hi,
I'm trying a different way of sending the sequence of BYTES which should be sent to receive a $NMEA return sentence.
Here is the SEND sentence [ $EIGNQ,RMC*24 ] +LF
I can experiment with CR LF etc once I know this is the correct way of sending.
does this look ok?
EDIT: IN RED
C
Code:
Dim m2g As String
Dim m2g_length As Byte
Dim msg2 As String
Dim data As String

'msg2 = "06 08 06 00 c8 00 01 00 01 00" + CrLf
msg2 = "0x24 0x45 0x49 0x47 0x4e 0x51 0x2c 0x52 0x4d 0x43 0x2a 0x32 0x34 0x0d 0x0a" 'Message to be sent '+ CrLf


MAIN:
WaitMs 1000

Toggle yled
'$GNRMC UART sentence request $EIGNQ,RMC*24 [NOTE D/S shows $EIGNQ,RMC*3A? ############################
'=0x24, 0x45, 0x49, 0x47, 0x4e, 0x51, 0x2c, 0x52, 0x4d, 0x43, 0x2a, 0x32, 0x34, 0x0d, 0x0a

'***************SEND MSG2******************
m2g_length = Len(msg2)  'find the length of msg2
For x = 1 To m2g_length  'set the number of iterations to be done
m2g = MidStr(msg2, x, 1)  'get the character to be sent to the GPS
Serout PORTC.5, 9600, 0x24, 0x45, 0x49, 0x47, 0x4e, 0x51, 0x2c, 0x52, 0x4d, 0x43, 0x2a, 0x32, 0x34, 0x0d, 0x0a 
Next x

Hserout "BYTES SENT  ", msg2, CrLf  'show sent data
data = ""  'clear received data

Goto MAIN
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
3,283
What change did you make?
Hi D,
#9 is using a different way to send BYTEs! (I've tried 2x ways before this)
It is marked in RED.
EDIT: I see that in CODE mode colours don't show!

I added the SEROUT line here:
--------------------------------------------------------------------------------

m2g = MidStr(msg2, x, 1) 'get the character to be sent to the GPS
Serout PORTC.5, 9600, 0x24, 0x45, 0x49, 0x47, 0x4e, 0x51, 0x2c, 0x52, 0x4d, 0x43, 0x2a, 0x32, 0x34, 0x0d, 0x0a
Next x
---------------------------------------------------------------------------------------------
C
 

sagor

Joined Mar 10, 2019
786
Your SEROUT line is sending the data in binary format, which is correct. Your strings format will send the ascii characters, so "0x24" will be sent as "0", "x", "2", "4". That is 4 characters send for a value that is supposed to be a binary 0x24 (hex) value.
I suggested a long time ago (to you) to use simple byte data instead of strings. That avoids confusion as to what string data actually sends. All byte data can be converted back and forth to string data as required. Also, declaring a couple large byte arrays saves space over declaring string data maximum length, as all defined strings use up that maximum length even if you only use one character of the string. Overhead processing of strings takes a lot more CPU time as well, compared to binary byte data.
If you insist on using strings, convert the string to a value before sending it....
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Your SEROUT line is sending the data in binary format, which is correct. Your strings format will send the ascii characters, so "0x24" will be sent as "0", "x", "2", "4". That is 4 characters send for a value that is supposed to be a binary 0x24 (hex) value.
I suggested a long time ago (to you) to use simple byte data instead of strings. That avoids confusion as to what string data actually sends. All byte data can be converted back and forth to string data as required. Also, declaring a couple large byte arrays saves space over declaring string data maximum length, as all defined strings use up that maximum length even if you only use one character of the string. Overhead processing of strings takes a lot more CPU time as well, compared to binary byte data.
If you insist on using strings, convert the string to a value before sending it....
Hi S,
I've been trying to do this (or to be exact this, but using SPI) since March, and today I succeeded, but not really understanding how, it's done..

I just tried commenting out all of the SEND CODE apart from the SEROUT, and it still works. (I spent ages searching for that CODE too)

I don't know what happened, I'm sure I tried the simple SEROUT method a million times.
Cheers,
C.
 

djsfantasi

Joined Apr 11, 2010
8,663
Hi S,
I've been trying to do this (or to be exact this, but using SPI) since March, and today I succeeded, but not really understanding how, it's done..

I just tried commenting out all of the SEND CODE apart from the SEROUT, and it still works. (I spent ages searching for that CODE too)

I don't know what happened, I'm sure I tried the simple SEROUT method a million times.
Cheers,
C.
@sagor has it right. When using the SEROUT command in #9, you are sending the binary values of the characters in the command. Using msg2 and midstr, you are sending the ASCII representation of the commands. Still binary, but coded differently. One is a value and the other is text.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
@sagor has it right. When using the SEROUT command in #9, you are sending the binary values of the characters in the command. Using msg2 and midstr, you are sending the ASCII representation of the commands. Still binary, but coded differently. One is a value and the other is text.
Hi D and Y,
My aim is to received $NMEA sentences from a Ublox GPS module using SPI.
The first step was to use UART, (U-center, the Ublox programmer uses UART) then move on to SPI.
It was a happy accident that I got a received $NMEA sentence using the SEROUT, as I had mixed it up with SPI CODE from March, which communicated with another SPI peripheral.
Rgearding Y's comment " If you insist on using strings, convert the string to a value before sending it.... " am I correct that to use SPI I have to use STRINGS?
Here is the SPI CODE: Not allowed, via CODE method
https://drive.google.com/file/d/1BOEr7G9nGJ4ix0JK724Nvu5aybm8F9Lf/view?usp=sharing
C
 
Last edited:

djsfantasi

Joined Apr 11, 2010
8,663
Hi D and Y,
My aim is to received $NMEA sentences from a Ublox GPS module using SPI.
The first step was to use UART, (U-center, the Ublox programmer uses UART) then move on to SPI.
It was a happy accident that I got a received $NMEA sentence using the SEROUT, as I had mixed it up with SPI CODE from March, which communicated with another SPI peripheral.
Rgearding Y's comment " If you insist on using strings, convert the string to a value before sending it.... " am I correct that to use SPI I have to use STRINGS?
Here is the SPI CODE: Not allowed, via CODE method
https://drive.google.com/file/d/1BOEr7G9nGJ4ix0JK724Nvu5aybm8F9Lf/view?usp=sharing
C
C

I unfortunately find myself once again trying to explain the different representations of data in a program. I believe that in order to fully understand your problem, you need to understand this concept.

It is with irony that I realized that I was repeating the exact same explanations that I had months ago. Coding by cutting and pasting other bits of code will only lead to wailing and gnashing of teeth.

So forgive me. I must bow out so that a better person can help you. My pov is insufficient and I can’t assist.

D
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
C

I unfortunately find myself once again trying to explain the different representations of data in a program. I believe that in order to fully understand your problem, you need to understand this concept.

It is with irony that I realized that I was repeating the exact same explanations that I had months ago. Coding by cutting and pasting other bits of code will only lead to wailing and gnashing of teeth.

So forgive me. I must bow out so that a better person can help you. My pov is insufficient and I can’t assist.

D
Hi D,
An example of brain scramble is, when I'm told that: [ Serout PORTC.5, 9600, 0x24, 0x45, 0x49, 0x47, 0x4e, 0x51, 0x2c, 0x52, 0x4d, 0x43, 0x2a, 0x32, 0x34 ] is sending binary values, when to me they look like HEX and to me binary looks like %10101010, just does not compute.
I have many skills, but programming isn't one of them as you can see, it's just my weakest link, but with help and cutting and pasting, I do get there, so don't bow out, in case there is something that will help in the future. I appreciate all of the help, but I'm sure it can be frustrating with me.
Cheers, C.
 

sagor

Joined Mar 10, 2019
786
All serial port data is a binary stream of bits, with control (stop/start bits) between each character.
So, when printing , for example, 0x45, the serial UART sends "01000101" as a bit pattern. It does not matter if you tell the serial print to send 0x45, a string character "E", %01000101, or a decimal value of 69. Those are all the same bit stream from the UART (or software uart).
It is up to the receiving end to decode the bit pattern into a value, which can be interpreted as binary, decimal, hex or as an ASCII character. But it is still the same "binary" byte value (8 bits). All byte values are binary, meaning the value is made up of a pattern of 1's and 0's
Doing a Serout PORTC.5,9600, "$EIGNQ,RMC*24" is the same as:
Serout PORTC.5, 9600, 0x24, 0x45, 0x49, 0x47, 0x4e, 0x51, 0x2c, 0x52, 0x4d, 0x43, 0x2a, 0x32, 0x34
The UART will send the same byte values as the same bit stream.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
All serial port data is a binary stream of bits, with control (stop/start bits) between each character.
So, when printing , for example, 0x45, the serial UART sends "01000101" as a bit pattern. It does not matter if you tell the serial print to send 0x45, a string character "E", %01000101, or a decimal value of 69. Those are all the same bit stream from the UART (or software uart).
It is up to the receiving end to decode the bit pattern into a value, which can be interpreted as binary, decimal, hex or as an ASCII character. But it is still the same "binary" byte value (8 bits). All byte values are binary, meaning the value is made up of a pattern of 1's and 0's
Doing a Serout PORTC.5,9600, "$EIGNQ,RMC*24" is the same as:
Serout PORTC.5, 9600, 0x24, 0x45, 0x49, 0x47, 0x4e, 0x51, 0x2c, 0x52, 0x4d, 0x43, 0x2a, 0x32, 0x34
The UART will send the same byte values as the same bit stream.
Hi S,
Thanks, appreciated!
I see, I'm missing what the serial adaptor does in my thinking.
Getting the UART to receive a $NMEA sentence, was to prove that it is possible, with a PIC. (Perhaps to most of you this is obvious?)

Next I would like to do similar, but by using SPI this time.
I know how the BITS/BYTES are exchanged with the SSPBUF, so now knowing that the GPS responds to Binary, I should be able to get it to work. I think the SSPBUF also converts HEX to BITs in it's process.

As mentioned, I've been trying since March (with gaps)
NOTE: Please don't be offended if I ask this again, it's like working with a goldfish
:)
Cheers, C.
 
Top