Why am I thinking so much about Digital Voice modes?

I have a project I would like to do...  I want to be able to remotely lock/unlock my car, remotely start the car in the morning, and to be notified remotely if the alarm is going off.  Some commercial products do some of those things; Certainly, the locking, unlocking, and remote starting are easy... As long as I'm in range of a key fob transmitter.  In the modern era, even the rest of it is doable, given cell phone technologies (See the Chevy commercials that allow you to do all of that from your smartphone.)  But what if the car is outside of my office building, and I'm working on the far side and can't hear the alarm?  Or if I'm in a building that doesn't have cell service? Or if I'm at the mall, and I want the car warm when I get there?

Ham radio transmitters have more power than the keyfobs, and would probably solve some of these problems;  Ham radio repeaters often have better coverage than cell towers, and would also largely solve the problem; The APRS network, as one example, has entirely decent national coverage, and can relay messages across RF and the internet to get a message across the country.  Clearly, to get what I want, I need something from the amateur market.

SO, a couple of years ago, I started researching various digital modes for this purpose...  POCSAG was nice, as it can provide the telecommand services I need... However, it's one directional, and the car wouldn't be able to report back it's success on a command, or tell me of a problem.  APRS is bi-directional, and supports telemetry and text messages... I could build an interpretter that could use text messages as commands...  But it's certainly not very battery efficient...  Maybe a combination of the two: POCSAG for telecommand, APRS for telemetry...  Keep the pager on all the time, but the APRS only boots up in the case of an event.

But then the idea of D-STAR occurred to me... It's getting good press, it supports voice and text messages, and it is designed for amateur radio; It's neat, because it carries your callsign as the radio ID, and can do call routing based on your callsign. However, through research, I found that the equipment isn't very well built, as Icom doesn't have any competition in the market... And the spec is poorly written, with the FEC in the datastream, NOT the voice stream, perpetuating lost packets and slow resync on the fringe of each repeater's coverage.

ETSI DMR, and particularly MotoTRBO, seemed to solve those design failures, and was just downright awesome, with 2-timeslot TDMA, and built in telemtry and telecommand.  The only downside was the lack of datastream callsign radio IDs...  Leading to some questionable legal issues in my project.

Also, in all cases, the price is absurd.  I can't afford it, none of my friends can afford it, and to make my project work, I would need to buy TWO radios just to have no one to talk to...

Yet, I am following all of these forums about D-STAR, D-STAR GMSK Nodes, MotoTRBO, DMR-MARC, etc.  I could BUY a MotoTRBO radio, add a GMSK node, and have DMR, D-STAR, and analog all in one radio, all for less than the cost of one of each!  But... I still wouldn't have anyone to talk to... And it would be rediculous overkill for my car project.

The fact of the matter is that I can't afford any of those radios... None of my friends can, either... And if I can't talk to my friends, I'm just not interested.  Further, if I can't use them in the back country, when I'm stuck in the snow and need a recovery, then it's pretty much useless.

My emotional mind is super curious and wants to build a D-STAR gateway at home...  But my logical mind tells me that doing so would be a waste of time and money.  I want to be on the cutting edge, but in the real world, I just need what works... At at this moment, FM voice is what works.

As for my car project...  It will stay on the back burner for a while...  And if I ever get around to doing it, the POCSAG telecommand / APRS telemetry idea is probably my best bet.   I just wish I could get myself to emotionally calm down about this digital voice stuff...

NMEA Sentences, Kenwood Sentences, and the G6APRS

This afternoon, Don Arnold (W6GPS) wrote on the G6APRS forums on Yahoo a rather informative post about how support for the full set of APRS icons and such are supported inside the AvMap G6APRS: 
On Tue, Oct 1, 2013 at 10:15 AM, <w6gps@yahoo.com> wrote:

this is clearly Yeasu. The Kenwood sentence is not proprietary. Argent and Byonics use it and they have not been sued. I guess the Idea of Yeasu having a function call Kenwood sentence in there radio is not cool..but any way if Yeasu created a P YEAD wpl instead of P KWD wpl and if parsed the same Avmap could also add the process this prompt command to the string and you would get all these features..
now using Magellan or Garmin format selection does not create a conflict. But to have the word Kenwood as a menu Item in a Yeasu radio I think wont happen...call it APRS Format with a PKWDWPL command prompt
and the Avmap will reconize the command then parse the string out correctly..But as far as I can see I cannot even get the wpl sentence out of the FTM400.     Don

---In G6APRS@yahoogroups.com, <g6aprs@yahoogroups.com> wrote:

So who's to blame here? Is it Yaesu's fault for not
implementing/supporting the Kenwood proprietary sentence format. Or is
this a case where it's "proprietary" and therefore Yaesu can't
implement or support it even if they wanted to?

New to the group (first post!), so sorry if this has been explained before.

Thanks!

-- Daniel - KJ4DAJ

In response, I felt it was important to make the following technical response:  

I have noticed two things that happen on this list far too frequently: 1) Fancy terms like "NMEA," "Sentence," and "PKWDWPL" or "$GPWPL" get thrown around without any explanation, and 2) The assumption that the audience is a bunch of industry experts is made rather falsely. Let me do my best to break down these terms for the benefit of the general public, who might not know the difference between a "Computer," a "Hard drive," and the "Screen."

The National Marine Electronics Association (NMEA) wrote a bunch of communication standards back in the '80s to specify how navigation equipment, weather instruments, mechanical and electrical sensors, autopilot, and other boat electronics communicate together; This standard was called NMEA 0183.  Think of NMEA 0183 as the boating world's version of the onboard computer in your car, except that it's expandable and is supported by a bunch of different manufacturers. Remember that by 1993, when GPS first became available to the public, NMEA was already an established standard;  The data we are trying to use today was not forseen by it's developers.   

On the wire, NMEA 0183 uses RS-422, which is electrically similar to but not quite the same as the serial port on your computer (RS-232); It sends pulses of 1's and 0's using ASCII characters.  Radio people will understand it, as it's not entirely unlike the over-the-air standards used in our digital modes. SO, these 1's and 0's form words and sentences, much like written language; So when we say "Sentence," we mean literally a sentence with words of data.   

I've been researching this NMEA sentence stuff for some time now (The last two years, anyway). Each sentence starts with a $, a data type, and then the information carried by that data type, and ends with an *, a check sum and a carriage return. GPS data starts with $GP, and is followed by a wide range of specific datatypes; Of interest to this group might be the $GPWPL sentence, which carries a waypoint to be displayed; It carries only a name and a location, and sometimes whether or not the waypoint is moving. TECHNICALLY, our use of $GPWPL is wrong...  The dreaded breadcrumb trail that some older Garmins are famous for is actually the CORRECT behavior, as each one of the $GPWPL lines is supposed to be displayed as a NEW waypoint... It's intended as a method of distributing a waypoint between multiple chartplotters on a boat. 

So far in my research, I have been refusing to even look at the official spec, because to do so might compromise some future projects I may work on; and have been looking at the reverse engineered spec instead. Let's just say that it's a mess...  For some interesting reading on the subject, check out this: http://esr.ibiblio.org/?p=801.  

The reason I mention it is this:  The NMEA sentences are incomplete, even in carrying just GPS location data...  The data spit out by a standard GPS may or may not carry elevation, or error rate, or any other combination of important data.  Many manufacturers use custom fields (Identified with a $P, followed by a three digit manufacturer code, followed by 2-5 digit data type code; In the case of Kenwood, this is a $PKWDWPL for the Kenwood custom waypoint sentence) that fix these oversights in the spec. Unlike the $GPWPL sentence mentioned before, the $PKWDWPL sentence is designed to specify a temporary waypoint, one that gets deleted when the next waypoint from that callsign gets sent.  It's pretty neat... As it's designed by radio engineers for the purpose of supporting APRS, rather than boat engineers with the purpose of communicating with boat navigation equipment. Just a few thoughts on the Kenwood sentence... It is called such because it's a Proprietary Sentence from Kenwood (From NMEA's perspective), not because Kenwood is protecting it; As Don has mentioned, several other manufacturers support it, and it's fairly well documented when you know what to look for. 

The reason I've been researching this stuff is this: GPSd is the daemon responsible for interpreting GPS data on Linux, and by extension, Android; It's capable of spitting out NMEA sentences, and also a more complete sentence developed by them for use with software based on their libraries; Because their sentence fills in the gaps left in other GPS manufacturer's implementations, it's output can be used more reliably than the input data. It's pretty cool... 

Also interesting are the Automatic Information System (AIS) sentences, which are designed to carry data similar to APRS but engineered for boats (Boat identifier, boat name, length, bearing, destination, size, etc.). The advantage being that AIS is standardized by NMEA, and is supported by a wide array of chartplotters and GPS units; The disadvantage is that AIS's icon set only includes boats... Far from complete for APRS use.  However, being similar to APRS, it also carries a lot of the data we care about; Namely, the identifier, name, and velocity; However, because all boats are at sea level, it does NOT carry elevation.  

Finally, I dream of someday writing a library that converts between the AIS sentences and the Kenwood sentences, the hope being that I can use a amateur radio TNC, paired with am AIS Chartplotter, and display APRS data in a more complete form than the $GPWPL sentence currently allows.  

I also dream of a day when I can use ONE G6 with TWO TNCs and radios, and be able to participate in both VHF APRS and UHF high speed APRS simultaneously... It SHOULD be as easy as plugging in a multiplexer, but I can't afford one... So maybe with this software I want to write, I will be able to use a Raspberry Pi as a cheap multiplexer. 

I hope that this post gives some insight into how this stuff works, and when Don throws around these terms, people can better understand what he's talking about; And should any of my dream projects come to fruition, this may be a good reference for what it's all about as well ;)

--

EDIT:  It has been brought to my attention that this post may come off in a derogetory tone; It's the furthest thing from my intention to offend anyone. Specifically, with regard to my comment "who might not know the difference between a 'Computer,' a 'Hard drive,' and the 'Screen.'"I didn't mean it as a put down, and I'm sorry if it came off that way...  In fact, I meant the exact opposite; Allow me to explain:

I only use that example because 1) most of my readers WILL know those differences, and might understand how others might not... And 2) it describes many of the people in my life...  Including my own parents, who are professionals in their own fields, and know a great deal more about the law and real estate than I ever will (My mom is a lawyer, and my father is a real estate developer).  Further, I'm a Geography major, and some of my college age classmates are unaware of the technical aspects of what a computer is, despite using them on a daily basis; That said, they probably know more about things like map projections, slip faults, and tree rings than most IT professionals do. Just because you aren't an expert in all fields doesn't mean your not an expert in something... And it certainly doesn't mean that your an idiot.

All I'm saying is that, in all things, it's important to assess your audience.  And on a mailing list that targets radio experts, throwing around technical developer nautical terms might not be the best path to a conducive learning environment.