Re: RF access point application confirmation
Matthew Pitts <daywalker_blade_2004@...>
toggle quoted messageShow quoted text
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.
From: "'Michael E Fox - N6MEF' n6mef@... [UniversalDigitalRadio]"
Sent: Monday, February 2, 2015 1:33 PM
Subject: RE: [UniversalDigitalRadio] Re: RF access point application confirmation
I don’t disagree with what you’re saying COULD BE the future. Indeed, the UDR is great because of the stuff that MAY come later.
But that’s betting on the come. And the problem with that is that the radio has been “about to ship” for at least a year now, and yet still, there is evidently no one working on the high speed modem function. (If there was, I expect we would have heard them say something by now).
No, the hardware does NOT have to be built before the software can be started. That’s the whole point of building on an open platform. As just one example, Juniper built the entire JUNOS operating system, routing protocols, user interface, logging, diagnostics, etc., before it had a single piece of hardware built. After that, it was a matter of the drivers for the particular serial or Ethernet or optical cards. We did the same thing at my last startup. The developers built the overall functionality, and then plugged in the specific API calls for each new card as it came out. In fact, the reason I have asked more than once about what test capabilities will be available is because that data needs to be available from the hardware via an API, and that’s something the NWDR guys will need to provide to developers. But answers there haven’t been very clear either, indicating that it’s still not defined and, at this late stage, it’s evidently not a priority.
So, maybe there is a large enough market of folks who want to buy this to tinker with in their garage. But for someone who has been talking this up as a potential real-world, deployable solution for a couple of years now, it’s very concerning that work has not already begun on the one thing that will make the UDR different from what we already have now: the high speed modem.