Date   

here is my digital dstar radio

David Warden <dwarden3@...>
 

All digital dstar "radio"! This was $180 to put together.

thumbDV plus one Winbook 7" tablet running Windows 8.1. I'm using WinDV 1.5.8 preview 1.

I was using Ambe server, dummy repeater, and ircddbgateway before I got Windv.

Has been working well so far. battery life on Winbook is somewhat limited, so I just leave it plugged in while monitoring reflectors.


David
KG7NKG
Sent from my iPhone


Re: D-STAR Entry for $180...

"qrv@..." <qrv@...>
 

"... operates on the 13cm band (WiFi)"

Is the range measured like a typical wifi dongle, 50-100',
depending on obstacles?

David KD4E

http://nwdigitalradio.com/thumbdv-create-a-handheld-for-under-200

--

------------------------------------------------------------------------
John D. Hays
K7VE
--

*David* KD4E
ARES-EC Bulloch County, Nevils, Georgia USA

Safe & Secure Search Engine: duckduckgo.com

Android for Hams: groups.yahoo.com/group/hamdroid
Creative Tech: groups.yahoo.com/group/ham-macguyver
Raspi Alternative: groups.yahoo.com/group/beagleboneblack/

Restored to design-spec at Heaven's gate 1Cor15:22


D-STAR Entry for $180...

"John D. Hays" <john@...>
 

http://nwdigitalradio.com/thumbdv-create-a-handheld-for-under-200

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: How fast are decodes

"John D. Hays" <john@...>
 

I don't have any data on speed of actual decode time.  These chips are usually used to handle one stream in slightly delayed real-time (e.g. they can keep up but there is a small amount of compute delay between input and output).  Also the ThumbDV is tied to a 230.4 kbps transfer rate.  I would plan on one ThumbDV per stream.

The DV3000 (GPIO version) can use trace-cut / jumper to increase the bps on the serial interface, but anything along that path is pure experimentation.


On Thu, Feb 5, 2015 at 2:53 PM, lukekb@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Ah! That is good to know about IMBE vs AMBE. Right now I am using OP25 and it doesnt look like it is too tough to dump the packets at the right level.

How much faster than real time can it decode a packet? How long would it take to decode 10 seconds of audio? Would it be 10 seconds? I am trying to figure out how many recordings I could queue up and have it keep pace.




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: How fast are decodes

lukekb@...
 

Ah! That is good to know about IMBE vs AMBE. Right now I am using OP25 and it doesnt look like it is too tough to dump the packets at the right level.

How much faster than real time can it decode a packet? How long would it take to decode 10 seconds of audio? Would it be 10 seconds? I am trying to figure out how many recordings I could queue up and have it keep pace.


Re: How fast are decodes

"John D. Hays" <john@...>
 

Luke,

Richard is correct, the AMBE3000F chip in the ThumbDV is a single stream vocoder.  It only vocodes the audio stream, not the P25 (or other transport) protocol.

Since it is a USB device, you can plug in several which will each appear on their own "COM" or "tty" device to the OS.   Plug in as many as your computer / OS / USB busses can handle for parallelism. Each appears as a 230.4 kbps serial device.

Your software will need to remove the AMBE stream from the P25 protocol (for each channel), buffer it into packets and send it to the ThumbDV, for each packet of AMBE it will return a packet of PCM encoded audio back (and visa-versa).

It will not decode IMBE (P25 Phase 1), only P25 Phase 2.

On Thu, Feb 5, 2015 at 11:52 AM, myyahoo@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

You would need a dongle per stream, the dongle can only decode one stream at a time.

Given the price of dongles, you might want to try a hybrid approach, and offload a stream or two and do the others in software?

- Richard, VE7CVS


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: How fast are decodes

myyahoo@...
 

You would need a dongle per stream, the dongle can only decode one stream at a time.

Given the price of dongles, you might want to try a hybrid approach, and offload a stream or two and do the others in software?

- Richard, VE7CVS


How fast are decodes

Luke Berndt <lukekb@...>
 

I have a system setup to record a trunked radio system. At times I am recording 3-4 P25 voice channels. I am doing the decode in software but it needs a lot of CPU. I am interested in using the USB dongle. I was thinking of capturing the raw streams and then passing them through the dongle. How much faster than real time is the decoder? How many simultaneous recordings could I have going on and still keep up? Would it changes with p25 phase 2?

Sent from my iPhone


Re: RF access point application confirmation

Randy Wilkinson <randy@...>
 

And I will thank you for staying the course and providing a great radio at a reasonable price.  Don't be tempted to make a radio that is all things to all people, and priced accordingly. 

I intend to vote using my decision to buy...I'm sure Michael will exercise his prerogative too.

Randy-W4LKS

On 2/4/2015 5:47 PM, bhhoyer@... [UniversalDigitalRadio] wrote:
 

Yes Michael, you're a potential customer with a clear vision. A vision which has great merit.


After we deliver the hundreds of units to which we are committed, we will evaluate the market and determine how to best allocate our resources. Your input is just one of many requests we have had for the future of the UDR and it will be given our sincere consideration.

Cheers,
Bryan - K7UDR


Re: RF access point application confirmation

Robert Copelan <rcopelan@...>
 

There are some pretty small companies,  some people even not a company but working on their own that are delving into the bleeding edge hardware and software.  The large number of resources of a company like Motorola, Icom, Yaesu or Kenwood are simply not available to them. 

The really leading stuff relatively open hardware like the DV3000 devices, DVMega boards, DVRPTR boards, GMSK modems like Moencomm's board are out there for us to take and use.  There is NO offer from the people that produce them that there will be total turnkey software or solutions developed for specific use cases that each of us might have.  Result is that we get some darn good hardware at reasonable prices.    The  UDRX, the upcoming Moencomm board and  ConnectSystems'  CS-7000 will be welcome additions to that list.   

Yes, not everyone is a programmer and not everyone's requirements will be met.  One thing is for sure:  We are moving at an ever increasing speed in hardware and software development these days (not just in amateur radio).   If a requirement isn't met today then it might be in the future and maybe by a source that hasn't even surfaced so far.    

I'm thankful we have these folks doing things even if it keeps my wife wondering what gadget I'll get next and why my wallet stays empty.  ;-) 

73,
Robert
WB4DHC   

On Wed, Feb 4, 2015 at 7:31 PM, 'Michael E Fox - N6MEF' n6mef@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Huh?

 

In a word, nothing.  I’m neither a hardware nor software developer.  I’m a potential customer.  As such, I’ve given a clear definition of the application and the requirements.  If the product developers (whomever they may be) don’t see fit to provide a solution, then I’ll have to come up with another strategy.

 

Michael

N6MEF

 

 

Michael, the question for you is:

 

If the UDRX doesn't do what you want, what are you going to do to move it forward?

 

 



Re: RF access point application confirmation

bhhoyer@...
 

Yes Michael, you're a potential customer with a clear vision. A vision which has great merit.

After we deliver the hundreds of units to which we are committed, we will evaluate the market and determine how to best allocate our resources. Your input is just one of many requests we have had for the future of the UDR and it will be given our sincere consideration.

Cheers,
Bryan - K7UDR


Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Huh?

 

In a word, nothing.  I’m neither a hardware nor software developer.  I’m a potential customer.  As such, I’ve given a clear definition of the application and the requirements.  If the product developers (whomever they may be) don’t see fit to provide a solution, then I’ll have to come up with another strategy.

 

Michael

N6MEF

 

 

Michael, the question for you is:

 

If the UDRX doesn't do what you want, what are you going to do to move it forward?

 

 


Re: RF access point application confirmation

bhhoyer@...
 

Wow, great discussion. This is exactly what we hoped for when we started the ARETF last fall.

To summarize our position at NWDR:

The UDRX will be released as a turnkey solution for current D-STAR and AX25 applications and provide a documented and supported open-source development platform. This will enable both faster communication thru legacy applications and a migration path to advanced technologies.

To that effort we will engage with the Worldwide Amateur Community thru the ARETF to foster an environment where we can exchange ideas and put them to the test. Experimentation and publication is highly encouraged. We can all play a part as developers and testers.

Our internal priority remains to deliver a high performance SDR as soon as we can.

Michael, the question for you is:

If the UDRX doesn't do what you want, what are you going to do to move it forward?

Must get back to work, have radios to build!
Bryan K7UDR


Re: RF access point application confirmation

myyahoo@...
 

And this is why having the platform up an running, and infinitely programmable, gives us a chance to put the options to the test!

In multipoint use in Vancouver we didn't need FEC to get good throughput. We had a pure IP implementation, not AX.25 or similar. Fixed stations were 10-40 miles from the repeater, in my case even bouncing signals off a mountain (about 20 miles from the repeater) worked well - packet loss was little-to-none. These are real world tests.

I'm not saying the FEC isn't useful, but it's not a cure-all and incurs overhead. FEC is definitely useful in latency-sensitive applications, but overall throughput can be higher when latency is less important than throughput on a link with little loss. It can be a real throughput help on links with lots of loss, but then throughput suffers, so 56k can quickly turn into less than 9600. We talked about FEC as a possible need before building the 56 k network in Vancouver but it turned out to be moot in real world tests - FEC would have swallowed more overhead than it would have returned. One thought - almost all of the calculations that I've seen to predict error in high speed over-the-air networks have been far more pessimistic than in reality (meaning not all of the variable were taken into account). We were amazed that a low-level mobile station would perform so well at 56k. Commercial guys have the same issue, one (RadioLAN? can't remember exactly, 900 MHz ~56k network) said that their modems wouldn't work above about 8 MPH, but discovered that they actually worked up to almost full freeway speeds (I used mine up to about 55 MPH).

So - we'll see what happens - I'm willing to be proven wrong, if FEC improves throughput, it will win out, but having SDR means never having to say you're sorry (for long) - just reload and move on. Even if the first 56k multipoint implementation isn't perfect, it will certainly be much better than current 9600 technology (there's no reason to deploy it if it isn't). We might start with emulating the WA4DSY modem that we used in Vancouver (and other places), and innovate from there. I'd like to pursue an adaptive protocol, that maximises throughput by using FEC only when it improves throughput. We might also use a 9600 bps (or slower) multi-channel approach (since bitrates are regulated here, making sure that we stay within the regs is necessary) using various modulation techniques, using a variable number of channels, and bonding the channels together as needed. These are the kinds of innovations that ham radio can contribute to the world of communications, while still pushing data through our own stations.

I think I should start researching the WA4DSY modem further and see if I can come up with an SDR equivalent as a base to work from (or find another modulation technique). Another advantage of SDR is that we can emulate ideas in software even before the hardware arrives!

- Richard, VE7CVS


Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Bill,

 

Thanks, but neither is a good fit.

For #1, we’re looking to move beyond 9600 (and even 19200).  And the packaging of the UDR is ideal.  So those other options don’t really compete.

For #2, we’re looking for 440, not 900, mostly for the propagation characteristics.  But to answer your question:  yes, I’m very familiar with the Ubiquiti line; less so with Microtik.

 

Michael

 

> Again, the problem to be solved is
>
> 1) lack of FEC causing single bit errors to result in retransmits of entire packets in “real world” (suburban/urban) situations such that the speed gain from 1200 to 9600 is negated, and

Have you had a chance to try the UZ7HO or DireWolf soundcard TNC
programs? Both offer single or some multiple bit error recovery at
9600 or 19200. How robust they are for an infrastructure position is
still open to experimentation... Maybe with windows on the new Pi 2
things will step up a notch.

> 2) the need for even faster speeds (56K+) so we can deliver services that aren’t possible as 1200/9600.

Have you looked at the 900 MHz Ubiquity or Mikrotik data radios.
It's a different solution set than 56K with 25 W at 420 MHz - but
there are probably situations where it will work.


Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Richard,

 

I think I was clear that the intended implementation is for multi-access in suburban/urban areas, not point-to-point.  The signals will not be as clean as typical point-to-point connections.

 

I really don’t see a need to debate the need for FEC any further.  Our measurements – including different digital radio formats -- show it will help.  And there’s a reason why it’s so commonly used in so many different digital radio formats and modulation schemes.  You may not agree.  But I’m betting that pretty much the rest of the world is not wrong.   ;-)

 

Michael

N6MEF

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: Tuesday, February 03, 2015 6:29 PM
To: UniversalDigitalRadio@...
Subject: RE: [UniversalDigitalRadio] Re: RF access point application confirmation

 

 

The 'plan' is to release the platform into the wild and enable the community to produce the SDR components needed/wanted for higher speeds - I don't see this a long-term goal, but a very short-term one. Much of the required software already exists, I'd be surprised if it's more than a month or two before the first, practical 56 kbps transmissions start to happen. I know that I'm going to be experimenting with this as soon as the unit is available. The beauty of SDR is that if the first efforts are less than stellar it's a simple matter to push new code out to one or more nodes, if need be.

And I can say - emprically - that FEC is *not* required for 56 k to work well - the 56 k network in Vancouver had no FEC and had terrific throughput, even when one station was mobile and more than 30 miles from the repeater. Modulation technique will likely have more effect on the throughput. 9600 bps is done using FM because "it's easy" on a typical ham rig designed for voice, just as 1200 bps used AFSK into the microphone and speaker connectors because we wanted to make it accessible using just about any rig - and because some Bell 202 standard modems were available from a local bank "by the pound" @ $1.75 each in 1979. :-) Neither of these modulation techniques are particularly sturdy, and pushing the same techniques to higher speeds would certainly have performance limitations.

This radio is not limited by either of these considerations - the modulation technique can be tailored for data, not shoe-horned onto a voice radio.

FEC may help for latency-sensitive transmissions (like voice and video), but on a relatively clean channel doesn't provide that much bang for the throughput buck for other kinds of data. If you're looking at 56 k for trunking and backhaul (good first, simple uses), good antennas and locations will win out over FEC overhead. Multi-point will be a different story, but even then it will be channel control that will matter more than FEC.

BTW - the RF is being engineered by the same ham (one of the best professional RF engineers I've ever known) who did the 56 k gear implementation in Vancouver, so we're not getting typical Kenwood/ICOM/Yaesu/... warmed-over voice radio efforts.

The flip side - you don't have to order one before the release, you can wait a little while and be a high speed follower - but I expect that the order backlog will be much longer as soon as the high speed software shows up. ;-)

- Richard, VE7CVS


Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Matthew,

 

I don’t understand the distinction you’re making since FX.25 = AX.25 + FEC.

 

But semantics aside, no such reluctance here since the intent is to move to higher speed which will necessitate replacing the existing equipment anyway. 

 

I found a spec and a TAPR DCC presentation on FX.25 from 2006.  But nothing current.  And I can’t find any complete implementations either.  So apparently this was just some experimentation that never went anywhere.  Maybe the UDR is exactly what the inventor needs to revive the work.

 

I did send an email to the Stensat Group (who authored the protocol) to see if they’ve heard of the UDR and would be interested in implementing. 

 

Michael

 

 

The holdup isn't a lack of FEC as such, but a reluctance on the part of the majority of packet operators to stop using perfectly good equipment and replace it with hardware/software options that support FX.25, which is an improved version of AX.25. If we could get past that point, it would be easier to get the faster speeds we want.

 

Matthew Pitts

N8OHU


Re: RF access point application confirmation

myyahoo@...
 

The 'plan' is to release the platform into the wild and enable the community to produce the SDR components needed/wanted for higher speeds - I don't see this a long-term goal, but a very short-term one. Much of the required software already exists, I'd be surprised if it's more than a month or two before the first, practical 56 kbps transmissions start to happen. I know that I'm going to be experimenting with this as soon as the unit is available. The beauty of SDR is that if the first efforts are less than stellar it's a simple matter to push new code out to one or more nodes, if need be.

And I can say - emprically - that FEC is *not* required for 56 k to work well - the 56 k network in Vancouver had no FEC and had terrific throughput, even when one station was mobile and more than 30 miles from the repeater. Modulation technique will likely have more effect on the throughput. 9600 bps is done using FM because "it's easy" on a typical ham rig designed for voice, just as 1200 bps used AFSK into the microphone and speaker connectors because we wanted to make it accessible using just about any rig - and because some Bell 202 standard modems were available from a local bank "by the pound" @ $1.75 each in 1979. :-) Neither of these modulation techniques are particularly sturdy, and pushing the same techniques to higher speeds would certainly have performance limitations.

This radio is not limited by either of these considerations - the modulation technique can be tailored for data, not shoe-horned onto a voice radio.

FEC may help for latency-sensitive transmissions (like voice and video), but on a relatively clean channel doesn't provide that much bang for the throughput buck for other kinds of data. If you're looking at 56 k for trunking and backhaul (good first, simple uses), good antennas and locations will win out over FEC overhead. Multi-point will be a different story, but even then it will be channel control that will matter more than FEC.

BTW - the RF is being engineered by the same ham (one of the best professional RF engineers I've ever known) who did the 56 k gear implementation in Vancouver, so we're not getting typical Kenwood/ICOM/Yaesu/... warmed-over voice radio efforts.

The flip side - you don't have to order one before the release, you can wait a little while and be a high speed follower - but I expect that the order backlog will be much longer as soon as the high speed software shows up. ;-)

- Richard, VE7CVS


Re: RF access point application confirmation

Matthew Pitts <daywalker_blade_2004@...>
 

Michael,

The holdup isn't a lack of FEC as such, but a reluctance on the part of the majority of packet operators to stop using perfectly good equipment and replace it with hardware/software options that support FX.25, which is an improved version of AX.25. If we could get past that point, it would be easier to get the faster speeds we want.

Matthew Pitts
N8OHU
 



From: "'Michael E Fox - N6MEF' n6mef@... [UniversalDigitalRadio]"
To: UniversalDigitalRadio@...
Sent: Tuesday, February 3, 2015 4:20 PM
Subject: RE: [UniversalDigitalRadio] Re: RF access point application confirmation

 
Matthew, Jim:
 
Again, I don’t necessarily disagree with most of what you said.  But with respect, you’re missing the point.
 
Yup.  9600 can be finicky.  FYI - the Kenwood TM-D710 also has a built-in, pre-adjusted 9600 TNC that works very well at 5/10/50 Watts.  The D710 has been the 440 backbone radio for all of our BBSs for the last five years.  It operates just fine in mountain top locations at relatively high duty cycles.  And enough people around here have service monitors to adjust separate TNCs (the PK-96 is probably the best we’ve seen).  So, setting up a 9600 station is a little trickier, but not the problem that needs solving (at least for us).
 
Again, the problem to be solved is
1)  lack of FEC causing single bit errors to result in retransmits of entire packets in “real world” (suburban/urban) situations such that the speed gain from 1200 to 9600 is negated, and
2)  the need for even faster speeds (56K+) so we can deliver services that aren’t possible as 1200/9600.  That won’t be possible without first solving #1.
 
All of the responses so far (including yours), have ardently defended the platform based on what it might do in the future.  But the platform was never in question.  We recognized the value of what NWDR was proposing as soon as we heard about it.  And we wouldn’t have been patiently waiting for the last couple of years if we didn’t think the platform was a good idea.  But the “out of the box” advantages you describe (reducing cost, reducing number of devices to hook together by one) are certainly not “revolutionary” advancements as you say.  After all, the end result is the same service (1200 baud or error-prone 9600 baud) that we can deliver today by other means. 
 
In contrast to that, we’re looking to deploy services that require more than today’s 1200 or 9600 baud.  And faster speed requires error correction.  So the huge disappointment is that after a couple of years of talking about a faster speed radio, there is still no plan to deliver a real faster speed radio (which would necessitate FEC), regardless of who develops it. 
 
Bottom line:  regardless of how cool the platform is and how many cool things folks might do with it in the future, not a single person (including your responses) has articulated the plan to move beyond the same old 1200/9600 functionality.  And *THAT* is the problem.
 
Perhaps a way to bootstrap the community would be for NWDR to host a developer conference/workshop.  They could review/explain the API, developer toolkit, documentation, developer support options, etc. and show folks how to get started right now, as well as articulate the plan for what additional developer tools will be available later.
 
Michael
N6MEF
 
 
 
From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: Tuesday, February 03, 2015 8:47 AM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Re: RF access point application confirmation
 
 
One more comment on "we already have that" line:
 
Yes, 9600 AX25 has been readily available for some time.  However, the existing solutions are both expensive and difficult for many hams to get into.  I've been running one of those 9600 Winlink RMSes for several years now.  So far, the only user that comes in on 9600 is also me.
 
I bought a PK-96 back in the 1990's, and have used that with my Yaesu radio w/ the "data" port on the back.  Cost: about $700.  I could have bought a less expensive radio. Today's cost: $450.  I would still need to borrow test equipment to properly set my deviation.  And even then, the radio would not be "mountaintop safe".  I also know these things, and thus have a "realisitc picture" of what it takes to do 9600 in today's environment.  My local user group just sees the "difficulty of 9600" as too great, and sticks with 1200 packet.
 
The UDR offers to fix that.  In one black box, one gets a radio that today can do 9600 with all the magic levels pre-set/calibrated, with a web-based GUI to configure.  In fact, for winlink applications, it comes with everything you need to offer a winlink to POP/SMTP gateway so users can set this up on their home network and use standard mail clients like thunderbird to read/write winlink mail!  While that can be done with current technology, its a lot of complicated "gluing stuff together" and either borrowing (and knowing how to use) expensive test gear, or buying very expensive radios.  The UDR brings a revolution to packet radio environment by:
 
1) Making 9600 more accessible to "the masses"
2) providing an interesting "tinkering" platform for those interested
3) Building momentum into further development into ham radio digital
 
Will it buy you capabilities that didn't previously exist when it ships?  Probably not.  But those capabilities will very likely be notably less expensive and much easier to use.  And the potential of future capabilities is very real (unlike most other hardware).
 
For the initial application listed, it would be possible to remove your serial-connected 9600 baud radio, put this in, connect it to ethernet, then perform some "additional" / "semi-advanced" configuration to set up a AX25 node over 440Mhz, that when a user connects to a specific call/ssid or alias, they will end up on your BBS.  Its not intended to run like a traditional 802.11 device with access point, clients, and pure IP at high enough speeds that people just run it as an "ethernet bridge over 440".  You probably could do that, but I wouldn't do that until more software is developed after release.
 
Note that the makers are intentionally NOT being the sole software writers...Like the raspberry Pi, they created a hardware platform, and allow the community to write the software for it.  Like the raspberry pi, the community software did not explode or even started getting written.  Not that its impossible, but for an open source community, they don't tend to get excited about a platform and start writing software for it until they have it in hand.
 
--Jim, K7LL
 
 
On Mon, Feb 2, 2015 at 1:23 PM, Matthew Pitts daywalker_blade_2004@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 
Michael,
 
1) High speed has been worked on, since it is currently locked to 56kbps on the 70 cm band in the US, and will likely remain that way until something happens with RM-11708 to break it loose from whatever is holding things up. I have little doubt that they could easily have done simulations with the higher data rates, and chose to code the modems to only run faster based on callsigns (like how the Winlink stuff locks out Pactor 4 if you're a US ham, but allows it for other countries and services that use the system).
 
2) API calls such as what you're asking about could very well exist already, simply waiting for the hardware to be finished; given that they are using websockets for a lot of their stuff (it's been mentioned at various times, and in various groups), I'm sure they have the desired hooks in place.
 
3) It already is, simply by supporting the D-STAR Digital Data mode on a band other than 23 cm; that it doesn't yet support the high speed data rates that you want isn't entirely the developer's fault, since the rates you're asking about aren't yet legal to use (in the US) anyway.
 
Matthew Pitts
N8OHU
 



Re: RF access point application confirmation

Bill Vodall <wa7nwp@...>
 

Again, the problem to be solved is

1) lack of FEC causing single bit errors to result in retransmits of entire packets in “real world” (suburban/urban) situations such that the speed gain from 1200 to 9600 is negated, and
Have you had a chance to try the UZ7HO or DireWolf soundcard TNC
programs? Both offer single or some multiple bit error recovery at
9600 or 19200. How robust they are for an infrastructure position is
still open to experimentation... Maybe with windows on the new Pi 2
things will step up a notch.

2) the need for even faster speeds (56K+) so we can deliver services that aren’t possible as 1200/9600.
Have you looked at the 900 MHz Ubiquity or Mikrotik data radios.
It's a different solution set than 56K with 25 W at 420 MHz - but
there are probably situations where it will work.

Bill, WA7NWP