Radioactive Networks
Home
Consult
Tracking
APRS
Main
OziAPRS
APRSd
VK2 Info
TinyTrak
Software
Hardware
Resources
FindU.COM
Weather
Books
GPS
TeamTrack
802.11
Ham
Articles
Personal
Technology
Software
Products
Contact
Search
Blog


Google

   
     RINO Decoding     RINO On Air     RINO/APRS     RINO Software     
Garmin RINO GPS Specification

The GARMIN RINO is a combined GPS receiever and radio available for use in the USA. It only has a short range, limiting it's use. Howevere the on-air protocol could be used to send data transmitted by these radios onto the Internet, possably into the APRS data stream. This page is based on the ideas of Bob WB4APR and others on This Page.

NOTE: All data is transmitted LITTLE ENDIAN. I have assumed that this has been taken into account when writing this protocol document

Code to Date

I have archived my work to date into a ZIP file. It is all writen in Visual Basic, and may be downloaded here. The code is without documentation, but seems to work.

Status

Right now we are waiting on more WAV files of data so that we can analyse the file format. For each WAV file we need





   Approximate Lat/Lon

   Approximate Time UTC

   Symobol, Channel, Code used

   Any other information you think may be useful

On Air

On air the data is transmitted at 600 bps. What we have found is that sampling the received signal at 8 KHz and at 8 bits/sample provides enough resolution for processing whilst not over-taxing the receiving compluter.

The data is sent so that a transition increasing in voltage is a '0' whilst a decreasing transition is a '1'. In practice we need to do more work in order to decode the data. We need to differentiate the incoming signal, not only removing any DC offset, not only caused by the hardware, but also by the fact that the data is not scrmbled.

But the differentiation causes a problem within a few samples of the actual data transition - so we need to stop any data being decoded for about 1/2 a bit period after a valid transition.

What we have found is that by comparing a sample to the previous sample does not work as well as we would have expected. What worked better was to compare to a one sample to the sample before the last one. This also allows us to increase the threshold for the data detection.

Protocol

Position Data
Bits 0-31 Longitude

long lat/lon	- length = 4 bytes, long signed integer encoded as
  11930464.7111111111 * lat/lon in degrees
  The factor as a ratio is 2**30/90.  As a C
  expression, it is ((1L << 30) / 90.0).
  All values are in map datum WGS 84.

  Examples:
	00 00 00 00 = 0x0 = 0.0 deg
	61 0b b6 00 = 0xb60b61 = 1.0 deg
	00 00 00 40 = 0x40000000 = 90.0 deg
	00 00 00 c0 = 0xc0000000 = -90.0 deg
	00 00 00 80 = 0x80000000 = -180.0 deg
Bits 32-63 Latitude

See Latitude.

Bits 64-71 Unknown
Bits 72-79 Symbol?
Bits 80-139 Callsign

Callsigns are in 6-bit bytes, with the LSB transmitted first. The character set does not use ASCII, but some other standard as Byon N6BG determined. The offset between the RINO alphabet and the ASCII one is 31 in the case of characters.

Once corrected for the Little-Endian transmission, we get the following character set

	0x00	Space
	0x22	A
	0x23	B
	0x3a	Y
	0x3b	Z
Bits 140-143 Unknown
Bits 144-167 Unknown - CRC?

The data may be summed and the low-order 8 bits then negated (2's complement) to form the CheckSum.

____
Welcome to our Techical Site. If you are interested in an overview, then visit our Marketing Site
Copyright © 1994-2005 Radioactive Networks , darryl@radio-active.net.au
This page was last updated 2005-09-02 15:16:12
This page was last compiled 2005-11-15 18:52:20
Question or Comment? Click here