From my interest in D-Star that has since waned, I was most interested in a SIP to AMBE trans-coding bridge. Allowing digital radio to inter-operate with ordinary VOIP.
About the time of all the Codec 2 buzz (2008-09), I was relaxing my interest in D-Star and kind of waiting to see if it would take off. Sadly some 6 years later and there are no radio's or adapters supporting it. Oddly enough Yaesu's System Fusion that was unveiled in 2011, could have but didn't. And I guess it still could as the user radios are firmware upgradable (but don't hold your breath)
Now that DMR seems to be taking off, once again we have that proprietary AMBE codec.
It was also disappointing that the user end radios and repeaters didn't
have a way to address the
AMBE chips inside them in a digital manner.
I.e: Stream Ulaw in, and get AMBE out for example.
Originally the only feasible way to build this bridge was to buy a DV dongle (circa 2007). Since then, it's clear that is not the best bang for the buck, as it can really only process the AMBE stream used in D-Star. It cannot do DMR's AMBE+2.
Now there is the DVSI Products USB-3000, NW Radio Thumb DV (DV3000U ), Matrix Circuits/MoenComm - Star*DV, and the DVMEGA AMBE3000 shield. The best bang for the buck seems to be the Thumb DV.
Sadly they all use a chip solution (minus the DVSI USB-3000 maybe), and can only process one AMBE stream at a time. If someone would have entered a agreement with DVSI maybe they could have cooked their own device that could process more than one stream at a time.
So why do I care about more than one stream at a time? Well for one; DMR has two time slots. For two, I'd really like to see:
Software written to let users capture the raw AMBE audio from D-Star, DMR and Yaesu and save it to a file, and/or re-direct it. (Think remote AMBE dongle) Ideally something that lets them do this off a discrimination tap.
Then websites equipped with the hardware AMBE processor could be set up where;
-You could upload the raw captured AMBE file, and get a MP3 file back.
-You redirect the AMBE output of this previously mentioned software to (much like how an Echolink Proxy works), and get a normal m3u stream back or whatever.
Hams have had their underwear all up tight about AMBE since D-Star was unveiled, and maybe if they had some tools that let them at the very least self police themselves that didn't involve buying a proprietary vocoder of their own, they'd calm down a bit?
These community vocoders would allow hams to create custom repeater voice ID's, club announcement reminders, etc. The real-time community vocoders could be used for when the need arises to patch traffic from one system to another.
A free software application called Digital Speech Decoder was unveiled in 2010 that lets them do this, but remember despite hams supposed to advancing the radio art, many are prudes, and don't want to even speak of the software. The mbelib component may contain code the infringes on (soon to be expired) patents in the USA.
Wednesday, July 10, 2013
Bob, K0NR wrote back in 2012 about the theory of dualband (2M/70cm) handheld transceiver that is built on top of the Android operating system.
"While this hardware configuration is exciting, the real power comes from having a software developers kit (SDK) with a stable Application Programming Interface (API). This would unleash the creativity of all those software-oriented hams out there and a plethora of apps would emerge"I agree.
Since then, smartphones like the Runbo X5 are available, these have a built in UHF two way radio.
More recently Bruce Perens K6BP has been giving talks about his vision of the "HT of the Future."
Some of his points are:
Narrower bandwidth, not more than 3 KHz
Higher end units run Android, and host applications which communicate over digital radio.
-The prototype we are working on is based on Chris Testa's Whitebox design, and an Android touchscreen computer as the user interface and application host.
-It can run Android applications in conjunction with it's packet, digital voice, or FM two-way radio.
- It has WiFi, Bluetooth, GPS, USB, Ethernet.
The problem is Apps use data to transfer information to work. If we are talking 1200 or even 9600 baud, then the app space is doomed by this limitation. There really isn't any talk about apps as those will be a third party thing. However I feel you should identify what some potential ones would be, so that the hardware can be designed to accommodate. I don't see that, so it's more or less; here it is, if you can make it do what you want, cool. Else not cool. In short I think the data rate will significantly impact what you can do with it.
Whitebox is SDR design optimized for a handheld. It uses a Flash based gate-array for low power consumption. The problem is it's a narrow band I/Q modulator design. This version probably isn't good for spread spectrum. However HackRF, an open source SDR platform by Michael Ossmann would be.
I have written many times that ham radio needs to embrace spread spectrum. I have also pointed out that is somewhat incompatible with our gentlemen's developed bandplans.
So I'd like to compile a list of things (think big) you'd like to see your future HT do. Here are some of my initial thoughts:
Mesh style, were if your HT can't reach the repeater/ other person it will find a relay (your mobile etc - think same band crossband)
GPS for APRS as well as auto downloading/programming local repeater frequencies on the fly. Street level map display for APRS (android interface)
Voicemail - if your not answering a directed call it will go to a hunt group, and lastly voicemail till next time you PTT (SIP integration)
Ability to use the HT as a remote base for your frequency agile home station.
RTL like ability- able to monitor public safety trunked systems out of of the ham band, while simultaneously monitoring the ham channel.
Please put your thinking hat on.