| Versions |
  |
|
| Author |
 Topic  |
|
m.g
49 Posts |
 Posted - 05 oct. 2007 : 00:42:01
|
You can use splitLog to separate gps data from tmc data. As for the ISO: look for ALERT-C, this should help to find the correct iso-specs.
Here is (partially) what I extracted from your file: 
regards,
m.g
|
 |
|
|
VolkerSchulz
4 Posts |
Posted - 05 oct. 2007 : 01:30:21
|
Awesome! Splitting works perfectly and 'ALERT-C' may point me to the right direction. Would be glad to receive any additional information.
Which app did you use to display the extracted TMC data?
Did you write the spliter app? If so, is it as straightforward as I think it is:
- Find first '?'
- Extract 8 bytes from first position after '?'
- Delete 10 bytes from first '?' (data bytes + both '?')
- Start over
Do you know how to 'communicate' with the GPS receiver? Means:
- How to switch to TMC mode?
- How to tune manually?
- How to seek a station automatically?
- How to read information about current station (RDS)?
Can I contact you by instant messenger or email? |
|
|
|
m.g
49 Posts |
Posted - 06 oct. 2007 : 00:42:03
|
Splitter app: I read the original file byte after byte with some counter and switch output between the two out-files when '?' is met as delimiter of a rds-group.
The app for data-analyzis is a little more complicated, it is mine also. The image shows only partial information of the csv-file generated.
Communicate with the GPS receiver: Maybe just contact GNS and ask them kindly if they are willing to provide you this information. Otherwise you will need to log the communication data (in both directions) and analyze. Also search the posts from user 'bill_gehts?' on pocketnavigation.de...
For contact - if you prefer private communication, please pm me either on pocketnavigation.de or on navifriends.de, I will probably be back by Monday.
Sorry, this reply is rather short, but it is late in good old Europe... ;-)
m.g |
|
|
|
VolkerSchulz
4 Posts |
Posted - 06 oct. 2007 : 13:57:43
|
Thanks, m.g., I'll send you a PN over there.
I didn't receive an answer to my inquiry from GNS but I did some research (also checked out what 'bill_gehts?' wrote) and I logged some communication data between the GPS receiver and Destinator PN navigation software.
Here's what I got so far:
-After starting the GPS receiver it sends out raw NMEA data with no RDS (TMC) included.
-After starting Destinator it 'initializes' the GPS receiver with some sort of command string to make it send out RDS data.
-Maybe it doesn't even 'initialize' but just tunes the receiver to a certain FM frequency.
-DavBouBou found out that the original app from GNS writes 5 bytes to the COM port (0xff,0x46,0x00,0x78,0x46). 'bill_gehts?' mentioned in another forum that this is the 'tuning comand', which should work as follows:
0xFF 0x46 ?? 0x78 0x46
?? = frequency:
00 = off
...
75: 99,2 MHz
76: 99,3 MHz
...
95: 102,4 MHz
-In my communication logs I've found the following:
(DST=Destinator, GPS=GPS receiver)
1:DST: 0x3F 0x56 0x78 0x78 0x56 0x0D 0x0A
2:GPS: 0x0A 0x0D 0x0A
3:DST: 0x3F 0x56 0x78 0x78 0x56 0x0D 0x0A
4:GPS: 0x3F 0x00 0x00 0x56 0x06 0x07 0x30 0x08 0x03 0x3F 0x0F 0x0A
5:DST: 0x3F 0x46 0x7A 0x78 0x46 0x3F 0x46 0x7A 0x78 0x46 0x0D 0x0A
6:GPS: <two NMEA sentences>
7:DST: 0x3F 0x46 0x7A 0x78 0x46 0x0D 0x0A
Line 1: Some sort of init? Also note the CR LF at the end.
Line 2: Answer?!? LF CR LF?
Line 3: Same as line 1.
Line 4: Looks like the first RDS block, encapsulated by '?'.
Line 5: Two(?) tuning requests with CR LF after the last one.
Line 6: NMEA sentence
Line 7: One tuning request with CR LF
|
|
|
|
VolkerSchulz
4 Posts |
Posted - 06 oct. 2007 : 15:12:08
|
Seems to work!
Sending a tuning request to the GPS receiver twice(!) turns on GNS 2.0 and makes the receiver sending both, NMEA and RDS/TMC data.
I do not have a RDS decoder yet, but the receiver starts sending those 10 byte blocks (probably 8 bytes RDS data + the '?' encapsulation).
Starting with either 0x3F or 0xFF seems to work fine.
So:
0x3F 0x46 0x7A 0x78 0x46 0x0D 0x0A 0x3F 0x46 0x7A 0x78 0x46 0x0D 0x0A
turns on GNS 2.0 support and tunes to 99.7 MHz
0x3F 0x46 0x00 0x78 0x46 0x0D 0x0A 0x3F 0x46 0x00 0x78 0x46 0x0D 0x0A
turns off GNS 2.0 support and switches back to NMEA 2.0 only.
Find a HEX to MHz conversion table here: http://www.capuzza.com/GNS/HEX2MHz.txt |
|
|
|
camomille
France
15 Posts |
Posted - 27 févr. 2008 : 19:37:01
|
Hello,
My contribution :
Flux exchange data between "DecoRDS" on x50v and GNS5843 connected with serial port(rxd/txd) .
Scan frequency 87,6 Mhz by step 0,1 Mhz and search on 94,1/94,2/94,3/94,4 (RDS without TMC) and stop on 97,1 Mhz (with TMC).
Log asc in HTML for color
http://gardemanger.perso.cegetel.net/TMC/log_asc.htm
Log Hexa in HTML for color
http://gardemanger.perso.cegetel.net/TMC/log_hex.htm
Log asc in TXT for modify
http://gardemanger.perso.cegetel.net/TMC/Scan_DecoRDS_asc.txt
Log hex in TXT for modify
http://gardemanger.perso.cegetel.net/TMC/Scan_DecoRDS_hex.txt
Short script UltraEdit32 for extract codes RDS with file *_hex.txt :
var msg="";
var rds="";
var targetStr = UltraEdit.document[0];
targetStr.findReplace.regExp = true;
while (targetStr.findReplace.find("(3F.{25}3F|FF.*$)"))
{msg=targetStr.selection;
if (msg.substr(0,2)=="3F"){msg=msg.substring(3,27)+" <<<GNS";}
else {msg=msg+" >>GNS";}
rds=rds+msg+"\r\n";}
UltraEdit.newFile();
UltraEdit.activeDocument.write(rds);
Thanks to Jose-Ramon for DecoRDS
http://foro.todopocketpc.com/showthread.php?t=131911
http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=92857 |
Edited by - camomille on 29 févr. 2008 14:31:41 |
|
|
|
Jose-Ramon
Spain
5 Posts |
Posted - 03 mars 2008 : 10:28:46
|
quote:
Thanks to Jose-Ramon for DecoRDS
Hello everybody, I am the creator of the DecoRDS. Let me answer some questions that I have seen in this thread:
1) No manufacturer publishes its communications protocol.
2) The information that I am going to make here, is the result of 'reverse engineer' ... therefore, may contain errors.
3) The GNS protocol, inserted information in binary RDS within chains NMEA GPS (ASCII). The indicator of the beginning and end of the RDS frame, is the character '?' CHR(&h3F)
4) Some receivers GNS must starting to begin insert information RDS within chains NMEA GPS ... others need to receive this information on a regular time (RDS-ON every 3"). Otherwise, non inserting the information RDS.
RDS-ON > CHR(&hFF) + CHR(&h56) + CHR(&h78) + CHR(&h78) + CHR(&h56)
RDS-OFF > CHR(&hFF) + CHR(&h53) + CHR(&h78)+ CHR(&h78) + CHR(&h53)
5) This is the way to tune the RDS receiver, using a GNS receiver:
6) The DecoRDS, detects and operates automatically with 5 different communication protocols.
7) The RoyalTek protocol inserted RDS using commands NOT included in the NMEA standard ($ RTTMC) ... but this makes it compatible with any software GPS, as it never breaks the frames NMEA GPS. This is an example, with the information sent by RDS RoyalTek GPS:
$RTTMC,1,e213,1540,00e2,0080*4B
$RTTMC,8,e213,8543,8873,1458*1B
$RTTMC,0,e213,054f,395e,2020*18
8) The DecoRDS can reproduce files 'log', but these files must be created with a single protocol (one line for each RDS group):
RDS: 16 hexadecimal characters (0 ... F) formatted text
ERROR: 1 character hexadecimal (0 ... F) formatted text to the error control (0 = 0% error / F = 100% error)
CR: 2 characters end line = CHR(&h0D) + CHR (&h0A)
Example, with RoyalTek protocol:
$ RTTMC,0,e213,054f,395e,2020*18
E213 054F 395E 2020 + ERROR (0 ... F) + CR
This is a file 'log', seen with a text editor:
E213E55D1800E2110
E213154000E208000
E213054F2F424D430
E2130548E32F44650
E21305492F426D6F0
E213255C6F7220650
More information here:
http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=92857
http://forum.pocketnavigation.de/thread.php?threadid=1061162&threadview=0&hilight=&hilightuser=0&page=2
|
|
|
|
adonix
1 Posts |
Posted - 11 mai 2008 : 01:49:22
|
Helle everyone, i need your help.
I'm trying to create a virtual TMC receiver for my Eten X500 using it's radio module.
Right now, i'm able to receive RDS packets and identify TMC messages. My software will interface with iGO using the Royaltek protocol.
Till now, i managed to send the following sentences to iGO:
$RTTMC,1,e213,1540,00e2,0080*4B : RDS/TMC message
$RTRDS,091.7,0,0,2,1,1,1,000,255,5,0,50*63 : Frequency identifier
iGO detects the vitualTMC, it also gives the channel name and display some RDS text if available. As for TMC, it writes "Test", then "TMC present" then "TMC status N/A" and it cycles these messages.
i noticed that iGO send sentences to the TMC hardware:
$PSRF121,1*38
$PSRF122,87.7*1C
i guess that these are tuning signals.
What i need is a log of an Royaltek receiver in order to reverse engineer the protocol. Or, informations on the protocol.
I dunno if Jose-Ramon have some information that helps me.
Thank you very much |
|
|
|
gpspassion
93394 Posts |
|
|
phmartin
France
8 Posts |
Posted - 04 nov. 2008 : 23:33:51
|
The following is based on my experience with the Bluetooth GPS-TMC receiver Royaltek RTG-2000
I used the following references:
[1] SiRF Binary Protocol Reference Manual and SiRF NMEA Reference Manual
[2] Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz, European Standard EN 50067
[3] Coding protocol for Radio Data System — Traffic Message Channel (RDS-TMC) using ALERT-C, International Standard ISO 14819-1
[4] GPS Diagnostics V1.05 by CommLinx Solutions -PC freeware
[5] Royaltek TMC demo software for Pocket PC -PPC freeware
http://www.royaltek.com/FileDownload.php?dir=DownloadFile&file=TMC_Demo_PPC2003_1209717193.CAB
As indicated by Jose-Ramon in his post 3-3-2008 (point 7) the sentences are inserted between NMEA sentences.
All sentences (sent and received) start with $ and end with * followed by a checksum (checksum is defined in ref [1])
Three types of sentences are sent by the receiver: $PSRFTXT, $RTRDS, $RTTMC.
$PSRFTXT followed by a string: this is a text message, directly readable (example: $PSRFTXT,Ack Input...)
$RTRDS provides tuning information; the format is
$RTRDS,p1,p2,.....p11,p12*checksum
p1 is the tuned frequency (readable text)
p2 is the signal level, 0 to 15 (readable text)
p8 is the "block ratio", 0 to 100% (readable text). "block ratio" is the name used in the demo s/w ref. [5]
I dunno what the other parameters are supposed to mean
$RTTMC provides RDS messages; according to [2], the RDS protocol defines an RDS message as 4 blocks of 16 bits of data; an RTTMC sentence simply contains one RDS message.
the format is
$RTTMC,p1,p2,p3,p4,p5*checksum
p1 is the RDS group type (readable text) as defined in ref [2], the most interesting are
....0: basic information
....2: radio text
....4: clock time and date
....8: TMC traffic message channel
....14: EON Enhanced Other Networks
p2 is the Pid (programme identification code) in readable form. The Pid is defined in [2]; it always is the first block of any RDS message
p3, p4, p5 are three 4-character chains containing blocks 2 to 4 of the RDS message in Hexadecimal. Detailed definition of these messages can be found in ref [3] for group type 8 (TMC) and in ref [2] for the other groups.
The following sentences can be sent to the receiver: $PSRFxxx (SiRF binary messages, see ref [1]) where xxx can be 107, 121, 122, 123, 126. The receiver sends in response to sentence 121-126 an acknowledgement sentence $PSRFTXT,Ack Input121*checksum (or an error sentence $PSRFTXT,Nak Input121*checksum).
The purpose of the sentences is the following: (see ref. [5])
$PSRF107*21 Get firmware version. Response (with my device)
>>>>>>>>$PSRFTXT,VersionR: 2K00320101N10151006080906*42
>>>>>>>>$PSRFTXT,RoyalTek Ver 1.1.0.106 GSW3LP EE*74
>>>>>>>>$PSRF154,107*3D
$PSRF126,0*3F Set scan mode (see ref. [5]) to FM
$PSRF126,1*3E Set scan mode to RDS
$PSRF126,2*3C Set scan mode to TMC
$PSRF123,1,1*27 scan up
$PSRF123,0,1*26 scan down
The receiver will scan until it locks on any transmitter (if scan mode=FM), or until it locks on a station sending RDS messages (if scan mode=RDS), or until it locks on a station sending RDS group type 8 messages (if scan mode=TMC)
$PSRF123,1,0*26 tune up (ie increase the frequency by 0.1 Mhz)
$PSRF123,0,0*27 tune down
$PSRF122,freq*checksum tune to freq
example: $PSRF122,95.3*1B tune to 95.3 MHz
(Note: to perform tests without having to compute the checksums, s/w ref. [4] came quite handy to experiment sending these types of messages)
$PSRF121,p1*checksum still is unclear to me. It seems that sending $PSRF121,0*39 will memorize a Pid and that $PSRF121,1*38 will scan if the current Pid is different from the one in memory. That's an unconsolidated guess for the time being.
So this is where I stand. All questions are welcome. I hope others will pick up from here and complete the interpretation of the $RTRDS and the $PSRF121 sentences.... |
Edited by - phmartin on 05 nov. 2008 13:18:42 |
|
|
|
BeamRider
Italy
6 Posts |
Posted - 25 mars 2009 : 10:57:14
|
What about OpenTMC standard? It "should be" pretty well documented because but I can still find only Anaryllo docs like:
http://www.locosystech.com/download/oem/Open%20TMC%20V2.00-1.02pdf.pdf
That's more than enough to decode TMC on those devices. Is there someone that has such a device that can provide logs? (there are some blind spots to clear in the document)
|
Edited by - BeamRider on 25 mars 2009 11:11:36 |
|
|
|
beemer
4 Posts |
Posted - 11 mai 2009 : 17:17:56
|
This thread has been very useful for me developing HyperGPS ( http://forum.xda-developers.com/showthread.php?t=512630 )that is currently capable of comunicating with iGO 8 in royaltek mode from an HTC PDA FM radio reciver based on flywhc@xda-developers user FM API, but I wonder if you have more deep information on Royaltek and/or GNS protocols.
For example, that information from user phmartin, does somebody have completed it a little more?
$RTRDS provides tuning information; the format is
$RTRDS,p1,p2,.....p11,p12*checksum
p1 is the tuned frequency (readable text)
p2 is the signal level, 0 to 15 (readable text)
p8 is the "block ratio", 0 to 100% (readable text). "block ratio" is the name used in the demo s/w ref. [5]
I dunno what the other parameters are supposed to mean
The idea is to make HyperGPS as compatible as I'll can with GNS and royaltek protocols.
TKS.
|
Beemer
VolDpad, BattLogger, NullKeyboard and much more on...
http://beemer.sesma.eu |
|
|
|
beemer
4 Posts |
Posted - 30 juil. 2009 : 16:50:19
|
What I've found and tested about GNS with iGO and Navigon.
==========================================================
RDS-ON
======
RDS ON
FF(or 0x3F) 56 78 78 56
answ:3F 00 00 56 05 11 2D 07 03 3F
Unknown meaning of fields 4-8 (05 11 2D 07 03) ?
Two differnet answer found in real TMC device logs:
3F 00 00 56 05 11 2D 07 03 3F iGO
3F 00 00 56 06 07 30 08 03 3F José Ramón
RDS_OFF
=======
FF(or 0x3F) 53 78 78 53
-Dont answer, only empty buffer
Tunning
=======
FF(or 0x3F) 46 xx 05 46 Used by iGO
FF(or 0x3F) 46 xx 78 46 Used by GNS Test
FF(or 0x3F) 73 xx 78 46 Used by DecoRDS
Answ: 3F 00 00 46 xx yy zz 00 00 3F
xx = (char) dwCurrentFrequency / 100 - 875 ;
yy zz = (Not sure).
00 00 if there are no station
01 55 if there are station with or without RDS or TMC
SCANNING
========
FF 79 xx 01 79 scan from xx up
xx = (char) dwCurrentFrequency / 100 - 875 ;
Inmediate answer: 3F 00 00 79 00 6F 6B 00 00 3F
Answer when scan stop: 3F 00 00 66 ww yy zz 00 00 3F : Stoped on ww with yy zz result
yy = (char) dwCurrentFrequency / 100 - 875 ;
yy zz = (Not sure).
00 00 if no station found. Continues scanning automatically
01 55 if there are station with or without RDS or TMC
RDS/TMC messages
================
3F aa bb cc dd ee ff gg hh 3F
aa-hh Four RDS data blocks RDS
Hope helps in a future to someone. HyperGPS TMC virtual driver is based on this and works fine.
|
Beemer
VolDpad, BattLogger, NullKeyboard and much more on...
http://beemer.sesma.eu |
Edited by - beemer on 30 juil. 2009 16:52:12 |
|
|
|
L_o_k_i
19 Posts |
Posted - 14 août 2009 : 13:34:41
|
To scan down, starting from xx:
command: FF 78 xx 01 78
answer: 3F 00 00 78 00 6F 6B 00 00 3F (to be confirmed!)
when scan stops: should be the same as scan up
This command has been found in Navigon. |
Edited by - L_o_k_i on 14 août 2009 13:35:22 |
|
|
|
grandpa
1 Posts |
Posted - 05 nov. 2009 : 19:50:29
|
using iGO on a c710 wich contains an fm4 gns chip.
iGO's FF 56 78 78 56 results in
in: 3F 00 00 56 05 1D 2E 06 05 3F
message FF 43 01 00 43 seems to report the producer:
in: 3F 47 4E 53 20 47 6D 62 48 3F (GNS GmbH)
iGO tunes with message FF 59 01 01 59 and gets two lines in response
in: 3F 00 00 59 00 6F 6B 00 00 3F
in: 3F 00 00 66 02 01 55 00 00 3F
The fifth byte of the second message (02) is the frequency igo tunes next to, after CC the value is 00.
When manual tuning is used iGO tunes with FF 73 52 05 73 reply is
in: 3F 00 00 73 52 01 55 00 00 3F |
Edited by - grandpa on 05 nov. 2009 20:07:58 |
|
|
|
Topic |
|
|
|
| This page was generated in 1,3 seconds. |
 |
|
- 
- 
[GUIDE] Decoding the TMC Protocol (GNS°
