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
 


Join main@nw-digital-radio.groups.io to automatically receive all group messages.