I've been meaning to clean this post up for a while, but since I don't think I'll really do that soon, here's the rough hypothesis: the next big breakthrough in DStar will be a user-friendly user interface. The current DStar radio interfaces were developed before DStar really was used much and do not reflect how these radios really are and can be used. Many folks hear about DStar, buy a radio, try it for a few weeks, then put it aside or sell it because they feel it is too complicated.
The current DStar radio UI's are as powerful and functional as DOS, and they need to become like windows - note that's a small 'w' so I mean the generic concept rather than a specific Windoze or X-windows, etc. How would this happen? A new radio UI is implemented with: 1) a 'glass cockpit' style of interface - an LCD that is either itself touch sensitive or is surrounded by softkeys, or both. This is against the trend of physicially smaller and smaller radios, but look at some of the current smart phones. HT's don't have to fit in a shirt pocket; 2) a repeater/gateway database that is EASILY downloaded and updated via the internet - wifi too so you can do this in your driveway; 3) no additional 'programming' of the radio to use this downloaded data. The radio will present this data to the user via the UI in one of several useable forms such as lookup by city, by geographic distance from the radio which also has a GPS of course and by good old callsign; 4) selecting a repeater from the database sets all necessary DStar callsigns, frequency parameters, etc; 5) a builtin help system; 6) a logical presentation of the "one-touch call" to callsign route back to a caller on a distant gateway. The UI might popup the caller's information and the matching database information for the caller's gateway and ask if you wish to engage in a QSO now or save for a few minutes later; 7) some limited last heard information accessible via the low-speed (limited bandwidth) data subchannel; 8) reflector linking (via an in-range repeater/gateway - callsign routing to the gateway?), perhaps using the low-speed data subchannel to send a keep-alive request every 30 to 60 seconds to the selected reflector to keep you linked; 9) multiple uses of the low-speed data subchannel so GPS data might be alternated with a reflector keep alive request, etc.; There's more, but this is enough to be food for thought. 73 -- John
