1. main@nw-digital-radio.groups.io
   Date   
Re: PNW digital network

Tom Hayward <esarfl@...>
 

On Mon, Mar 17, 2014 at 4:05 PM, flightresq@...
<flightresq@...> wrote:

Does anyone know the baud rate or hertz for project 25?
Not really sure what this has to do with the current thread, but...

P25 Phase I is 4800 symbols per second - where each symbol encodes two
bits of data for a raw bit rate of 9600 bps. Phase II is 6000 symbols
per second where each symbol encodes two bits of data for a raw bit
rate of 12000 bps.

Tom KD7LXL
Re: PNW digital network

"flightresq@..." <flightresq@...>
 

Does anyone know the baud rate or hertz for project 25?

Sent from Yahoo Mail on Android


From: ve7dhm@... ;
To: ;
Subject: [UniversalDigitalRadio] PNW digital network
Sent: Mon, Mar 17, 2014 10:17:30 PM

 

Back in the mid 90s, when packet radio was well established in the
PNW, Vancouver Island, the B.C. mainland, and the Puget Sound area
was well served by a network of nodes and BBSs.  The 1200 baud
network used 2 meter, 220, and 440 frequencies to link node stacks
such as VIC, SPR, PTN, SKAGIT, NMSL, BRMRTN etc.  That network
moved  a lot of information around for the multiple BBSs in the
area.  Most of that network is now gone along with the BBSs which
used that network for information distribution to hams.

VHF packet radio is still alive and well on Southern Vancouver
Island where it is used to support local authorities in times of
disaster when infrastructure fails ( 13 municipalities and 7
districts surrounding the Greater Victoria area. )  As well,
Pactor 3 / 4 is used for long distance information exchange
for EMBC, PSC and CFARS.

It is my hope that with the UDR-X that a version of that former
network can be established as a point to multi-point "when all else fails"
backup for internet infrastructure which is so now embedded in
operations by local authorities.  That is where my interest is
dedicated in using the UDR-X and in support of that interest I
have 7 UDR-Xs on order.  1200 baud is fine for text messaging and
text emails.  1200 baud does not support picture and data base
file transfers.  It has been a long time coming for hardware that
can provide a dramatic jump in data speed for the Amateur Radio
Service.  I had high hopes for the Icom ID-1 but with high feedline
loss, line of sight propagation issues in the area, and high cost
it did not become popular for use in my area.  I did setup a trial
where it was used in the Swiftsure boat race several years ago and
many megabits of data...still pictures and 15 second videos were
sent from several boats to a land based server...the weather,
especially fog, decreased received signal to unusable levels...not
really good for TCP/IP nets!

So, hopefully 440 will be the high speed data backbone answer.  I
can wait for NWDigital to put out a quality product complete with
end user apps for those that don't or can't roll their own.  Keep
up the good work NWDigital Team and looking forward to receiving my
order and start building the PNW Network.

Paul VE7DHM 

Re: PNW digital network

Bill Vodall <wa7nwp@...>
 

So, hopefully 440 will be the high speed data backbone answer.
Have you seen HamWAN? http://www.hamwan.org There are some
differences of vision here but in general the HamWAN folks are doing a
heroic job.

That said, I'm hoping to see a robust wide area ad-hoc system evolve
from the new functionality that UDR-X will bring.


I can wait for NWDigital to put out a quality product
Not me - I want it yesterday...


Paul VE7DHM
Bill, WA7NWP
Re: PNW digital network

Don Poaps <va7dgp@...>
 

I'm waiting too.. I'm trying to setup a BBS in New Westminister, BC. I'm having issues with TNC not wanting to talk to BPQ. Issue with com ports on windows XP. Not know Linux. I'll need all the help I can get.

Don va7dgp


On Monday, March 17, 2014, <ve7dhm@...> wrote:
 

Back in the mid 90s, when packet radio was well established in the
PNW, Vancouver Island, the B.C. mainland, and the Puget Sound area
was well served by a network of nodes and BBSs.  The 1200 baud
network used 2 meter, 220, and 440 frequencies to link node stacks
such as VIC, SPR, PTN, SKAGIT, NMSL, BRMRTN etc.  That network
moved  a lot of information around for the multiple BBSs in the
area.  Most of that network is now gone along with the BBSs which
used that network for information distribution to hams.

VHF packet radio is still alive and well on Southern Vancouver
Island where it is used to support local authorities in times of
disaster when infrastructure fails ( 13 municipalities and 7
districts surrounding the Greater Victoria area. )  As well,
Pactor 3 / 4 is used for long distance information exchange
for EMBC, PSC and CFARS.

It is my hope that with the UDR-X that a version of that former
network can be established as a point to multi-point "when all else fails"
backup for internet infrastructure which is so now embedded in
operations by local authorities.  That is where my interest is
dedicated in using the UDR-X and in support of that interest I
have 7 UDR-Xs on order.  1200 baud is fine for text messaging and
text emails.  1200 baud does not support picture and data base
file transfers.  It has been a long time coming for hardware that
can provide a dramatic jump in data speed for the Amateur Radio
Service.  I had high hopes for the Icom ID-1 but with high feedline
loss, line of sight propagation issues in the area, and high cost
it did not become popular for use in my area.  I did setup a trial
where it was used in the Swiftsure boat race several years ago and
many megabits of data...still pictures and 15 second videos were
sent from several boats to a land based server...the weather,
especially fog, decreased received signal to unusable levels...not
really good for TCP/IP nets!

So, hopefully 440 will be the high speed data backbone answer.  I
can wait for NWDigital to put out a quality product complete with
end user apps for those that don't or can't roll their own.  Keep
up the good work NWDigital Team and looking forward to receiving my
order and start building the PNW Network.

Paul VE7DHM 



--
Don Poaps
New Westminster, BC
VA7DGP
 
PNW digital network

ve7dhm@...
 

Back in the mid 90s, when packet radio was well established in the
PNW, Vancouver Island, the B.C. mainland, and the Puget Sound area
was well served by a network of nodes and BBSs.  The 1200 baud
network used 2 meter, 220, and 440 frequencies to link node stacks
such as VIC, SPR, PTN, SKAGIT, NMSL, BRMRTN etc.  That network
moved  a lot of information around for the multiple BBSs in the
area.  Most of that network is now gone along with the BBSs which
used that network for information distribution to hams.

VHF packet radio is still alive and well on Southern Vancouver
Island where it is used to support local authorities in times of
disaster when infrastructure fails ( 13 municipalities and 7
districts surrounding the Greater Victoria area. )  As well,
Pactor 3 / 4 is used for long distance information exchange
for EMBC, PSC and CFARS.

It is my hope that with the UDR-X that a version of that former
network can be established as a point to multi-point "when all else fails"
backup for internet infrastructure which is so now embedded in
operations by local authorities.  That is where my interest is
dedicated in using the UDR-X and in support of that interest I
have 7 UDR-Xs on order.  1200 baud is fine for text messaging and
text emails.  1200 baud does not support picture and data base
file transfers.  It has been a long time coming for hardware that
can provide a dramatic jump in data speed for the Amateur Radio
Service.  I had high hopes for the Icom ID-1 but with high feedline
loss, line of sight propagation issues in the area, and high cost
it did not become popular for use in my area.  I did setup a trial
where it was used in the Swiftsure boat race several years ago and
many megabits of data...still pictures and 15 second videos were
sent from several boats to a land based server...the weather,
especially fog, decreased received signal to unusable levels...not
really good for TCP/IP nets!

So, hopefully 440 will be the high speed data backbone answer.  I
can wait for NWDigital to put out a quality product complete with
end user apps for those that don't or can't roll their own.  Keep
up the good work NWDigital Team and looking forward to receiving my
order and start building the PNW Network.

Paul VE7DHM 
Re: SAW Filter limitations

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

Hi Steve,

Currently, the only DD network implementation is 128 kbps on 23 cm from Icom (ID-1 terminals, and RP-2D access point) and is half duplex (no repeaters).  The UDRX will change this, as it will permit DD at data rates from 4.8k to the top data rate (estimated to reach 100k+) of the radio using 70cm band(s). In the US we are limited to a 100 kHz channel.

In the Icom architecture DD is always a separate band module.  With the UDRX we have the potential to run both DD and DV on the same module (at 4800bps).

It may also be possible to build a repeater having 100 kHz channels using the UDRX. (Either bonding 4 adjacent 25 kHz channels at 440 band or using a split in the 430 band.)

DV (which includes a slow data subchannel) is typically simplex, repeated, or simplex access point (hotspot).  This is  a 6.25 kHz channel (or repeater pair).  In the US DV repeaters usually are following the local band plan.  Here in Western Washington (State) we use high in/low out for our repeater pairs and the bandplan has 12.5kHz and 25kHz pairs. 

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  






On Mon, Mar 17, 2014 at 11:01 AM, Steve <yahoo-udr@...> wrote:
 

How does this discussion affect digital voice (DV) and digital data (DD)
modes in the USA? Do DV repeater operators always enable DD capability?
Or, are there separate DD repeaters? Do the repeater operators follow
the ARRL or other local band plans?

Steve
Re: SAW Filter limitations

Steve <yahoo-udr@...>
 

How does this discussion affect digital voice (DV) and digital data (DD) modes in the USA? Do DV repeater operators always enable DD capability? Or, are there separate DD repeaters? Do the repeater operators follow the ARRL or other local band plans?

Steve

---------- Original Message ----------
[ Sent by bhhoyer@... at 03/17/2014 10:27 AM ]

We could do a UDRX-430.

there is a 20MHz 431 Filter (421-441). Takes care of the bottom of the US Band as well


It's in a different package (of course) so we'd end up building 440s in mass then reworking the filters.


Might be a small upcharge of 20-25 USD


Bryan K7UDR
Re: SAW Filter limitations

bhhoyer@...
 

We could do a UDRX-430.

there is a 20MHz 431 Filter (421-441). Takes care of the bottom of the US Band as well

It's in a different package (of course) so we'd end up building 440s in mass then reworking the filters.

Might be a small upcharge of 20-25 USD

Bryan K7UDR
Re: SAW Filter limitations

John Ronan <jpronans@...>
 

On 17/03/14 16:05, Andre wrote:
op 17-03-14 16:50, bhhoyer@... schreef:
 

The UDR has a SAW Filter in both the transmit and receive paths. We are currently using a 440MHz filter with a 19MHz BW, meaning we are 3db down at 430.5MHz and 449.5MHz.


I have been searching for 20MHz filters and have found no reasonable cost solutions. I will be traveling to China later this year to look into the cost (MOQ really) of having SAW filters made to our specification.

Looking at the ARRL BandPlan for 70cm, ATV is up to 432 and the top of the band is for Voice repeaters. Many countries only go up to 440.

The question for the group is, how does this affect your planned deployment? Is it a real issue for production.

Thanks,
Bryan K7UDR
All 9k6 AX.25 channels in the Netherlands are between 430.400 and 431.025 and german duplex ax.25 channels have input between 430.400 and 430.5875 and output between 439.800 and 439.9875.

So there would be some limitation if the 19 MHz SAW filter is used in this configuration.

73 de Andre PE1RDW

It is a similar situation here in Ireland, and I guess throughout all of IARU Region 1. 

Regards
John
EI7IG
Re: SAW Filter limitations

Andre <pe1rdw@...>
 

op 17-03-14 16:50, bhhoyer@... schreef:
 

The UDR has a SAW Filter in both the transmit and receive paths. We are currently using a 440MHz filter with a 19MHz BW, meaning we are 3db down at 430.5MHz and 449.5MHz.


I have been searching for 20MHz filters and have found no reasonable cost solutions. I will be traveling to China later this year to look into the cost (MOQ really) of having SAW filters made to our specification.

Looking at the ARRL BandPlan for 70cm, ATV is up to 432 and the top of the band is for Voice repeaters. Many countries only go up to 440.

The question for the group is, how does this affect your planned deployment? Is it a real issue for production.

Thanks,
Bryan K7UDR
All 9k6 AX.25 channels in the Netherlands are between 430.400 and 431.025 and german duplex ax.25 channels have input between 430.400 and 430.5875 and output between 439.800 and 439.9875.

So there would be some limitation if the 19 MHz SAW filter is used in this configuration.

73 de Andre PE1RDW
SAW Filter limitations

bhhoyer@...
 

The UDR has a SAW Filter in both the transmit and receive paths. We are currently using a 440MHz filter with a 19MHz BW, meaning we are 3db down at 430.5MHz and 449.5MHz.

I have been searching for 20MHz filters and have found no reasonable cost solutions. I will be traveling to China later this year to look into the cost (MOQ really) of having SAW filters made to our specification.

Looking at the ARRL BandPlan for 70cm, ATV is up to 432 and the top of the band is for Voice repeaters. Many countries only go up to 440.

The question for the group is, how does this affect your planned deployment? Is it a real issue for production.

Thanks,
Bryan K7UDR
Forum Etiquette

bhhoyer@...
 

To all,

The purpose of the forum is for you to ask questions about the UDR and post your thoughts on Digital Amateur Radio. In addition, we use it to gain insight into how you want to use the UDR so we can prioritize our development.

To Michael E Fox,

This is your second attempt to hijack one of my threads. There will not be a third.

Feel free to start your own thread, where you may wax eloquently about your vision. I am not in disagreement with your technical position and there are other experimenters looking for similar functionality.

Cheers,
Bryan K7UDR
Re: Webmail Clients

Dean Gibson AE7Q <yahoo@...>
 

On 2014-03-13 23:02, Bill Vodall wrote:
However, like everyone else, I'm not getting any younger, and I've been looking at alternate solutions. Tuesday evening I bought a commercial 5.8GHz digital (eg, Ethernet) radio and 36" dish for $200 total to use with the HamWAN project. Two days later (today) I am on the air (through a 2nd story window -- ....

Assuming we get the UDRX with a speed of (say) 128Kbps by fall, then some of us will only have ourselves to communicate with. I'm in the Pacific NW, and I know some of the UDRX buyers: some of them will be "slow" to get a usable network up. Meanwhile, I'm on the air to others on the HamWAN network and the Internet, today.
...

The technologies are complementary - but the Internet as it sits is an anti-goal. Doing this just to hook to the Internet - limited as it may be for ham regulations - is pretty much ho-hum. It's what we can and will do in our own side of that fence that's super cool and special.
You are correct; accessing the Internet is normally a "means-test", to see if the amateur radio network is just a toy between three amateurs, or actually useful.
Re: Webmail Clients

Bill Vodall <wa7nwp@...>
 

However, like everyone else, I'm not getting any younger, and I've been
looking at alternate solutions. Tuesday evening I bought a commercial
5.8GHz digital (eg, Ethernet) radio and 36" dish for $200 total to use with
the HamWAN project. Two days later (today) I am on the air (through a 2nd
story window -- ....

Assuming we get the UDRX with a speed of (say) 128Kbps by fall, then some of
us will only have ourselves to communicate with. I'm in the Pacific NW, and
I know some of the UDRX buyers: some of them will be "slow" to get a usable
network up. Meanwhile, I'm on the air to others on the HamWAN network and the Internet, today.
I was going to get a HamWAN setup but then I took my laptop with built
in wifi to McDonalds... Had an fast internet connection and
downloaded some cool John Denver videos and a few wild Viking wood
songs... That's working great - guess I don't need HamWAN or
UDR-X...

Mostly just kidding. I really didn't get any Viking songs yet.

The technologies are complementary - but the Internet as it sits is an
anti-goal. Doing this just to hook to the Internet - limited as it
may be for ham regulations - is pretty much ho-hum. It's what we
can and will do in our own side of that fence that's super cool and
special

So Dean - what email client did you use with your new toys to send
these notes? You web site was the first to know we had a new call
listed in 59454 - good job - was that hosted on the hamWAN?

i'v been teasing Bruce for weeks about hooking up to Hamwan and bring
it to brunch to supplement the coverage we get from his clear wire
equipment. Are you going to fill in with a connection from your car
and backup bruce. I've got those John Denver videos to upload to my
cloud server and that would be good workout for a mobile hamWan node.

I'd offer to share our UHF 9600 bandwidth but give we can't download a
simple web page yet I don't think it'll help much. Still getting some
pings across every hour or soo.

Whether these radios supplant or replace my reservation for two UDRX radios,
I have not decided.
Hope to see you at burnch. Might bring my Groove and fire it up..

73
Bill, WA7NWP
Re: Webmail Clients

Dean Gibson AE7Q <yahoo@...>
 


On 2014-03-13 10:44, Michael E Fox - N6MEF wrote:

You missed the point.

My point is that all this time spent on defining applications could and should be spent on defining management/configuration screens, status screens, logging, etc. for the primary purpose of this box.  ... 

Michael N6MEF


I think part of what all of us are experiencing, is the frustration of (in many cases) made purchasing decisions (eg, not buying something else) based on a schedule that has (for speeds over 9.6k) slipped by at least a year.  Some of us have also seen software products (whether free or commercial) languish for bug fixes or serious enhancements, while "software engineers" fiddle with changes for the sake of cosmetics (Thunderbird being a prime example).  Like you, I hope that primary software efforts are not being delayed for "adjunct" software.  Of course, most of the software effort is volunteer, and different people have different skills (I'm an embedded developer, not a GUI wizard).

On the other hand, many commercial products can't survive economically without "appliance" users, or even "toy" users.  Ten years ago, the number of amateur radio licensees was steadily declining;  now, it is up by about 8%.  Now, some will argue whether or not that's a good thing (I will argue the latter, but not here), but the fact is, most consumer products exist (at least at current prices) due to this effect.  UDR has appliance purchasers lining up, and it needs them as well as "us" (meaning those that don't want any eMail software on the UDRX) for both survival and the resources to support us (there will be changes).

However, like everyone else, I'm not getting any younger, and I've been looking at alternate solutions.  Tuesday evening I bought a commercial 5.8GHz digital (eg, Ethernet) radio and 36" dish for $200 total to use with the HamWAN project.  Two days later (today) I am on the air (through a 2nd story window -- need to move it higher) to a remote Internet connection at 1.5Mbps, for 1/2 the price of a UDRX.  When I mount the antenna higher, I should get over 10Mbps.

Assuming we get the UDRX with a speed of (say) 128Kbps by fall, then some of us will only have ourselves to communicate with.  I'm in the Pacific NW, and I know some of the UDRX buyers:  some of them will be "slow" to get a usable network up.  Meanwhile, I'm on the air to others on the HamWAN network and the Internet, today.  I will probably buy a second radio/antenna combo to experiment with.

Whether these radios supplant or replace my reservation for two UDRX radios, I have not decided.
Re: Webmail Clients

Bill Vodall <wa7nwp@...>
 

With the built-in apps, incorporating the UDRX
into such Amateur Radio networks will be easy - just use a web browser
on the existing PC.
What infrastructure is there? Working with the 'local' system is key
and given hams, all local systems will be different. So no matter
what there is out of the box - there will be local modifications...
Maybe we need an "apt-get install local-system" default target so
it's possible to (nearly) automatically install local requirements...

Bill
Re: Webmail Clients

Mark L Friedlander <marklfriedlander@...>
 

I'm not so sure it's productive to judge SquirrelMail based on how you found it over 5 years ago. I'm currently using it and find it as good as any other webmail software and better than some others I've used recently.

Mark KV4I



On Thu, Mar 13, 2014 at 12:16 PM, Steve Stroh N8GNJ <steve.n8gnj@...> wrote:
 

Bryan:

SquirrelMail at least the last time I was forced to use it 5+ years
ago, is, at best, adequate. But there's got to be something better. As
a result of the infestation of Google+ into Gmail, there are several
projects going on to replicate the Gmail experience on one's own
server, and those might be worth investigating.

I've found that text mode PINE mail client to be more usable than
SquirrelMail. I believe Pine and it's associated text mode, text
editor Pico, are open source from the UW here in the Seattle area.
http://en.wikipedia.org/wiki/Pine_(email_client). Apparently there is
a successor to Pine - Alpine. In contrast to most text mode mail
clients, Pine was intuitive and easy to use. Being text mode, it was
very responsive. Its one downside is that it didn't deal with
attachments very well. One real positive was being text only, it
stripped "foo foo'd" email messages with lots of fonts, colors,
dancing bears, etc. down to just the text.

Pine also did a great job of reading USENET News -
http://www.washington.edu/pine/faq/news.html#top

I think the POP/SMTP capability will be more widely used with
Thunderbird, which is a pretty good mail client.

BBS Style Bulletins...
1. For semi-static content (my station information) it would be great
if the web apps could include a Wiki, preferably a "federated" Wiki
like what Ward Cunningham discussed at last year's MicroHAMS Digital
Conference - changes in one are automatically replicated to others
that are subscribed.
2. Some kind of simple blog generation would also be great, and you
can subscribe to it using RSS. That works great, lots of RSS clients
out there in opensourceland, and it's pretty lightweight to poll a
blog with RSS to see if there's an update.
3. NNTP / USENET servers / clients are THE way to go in Amateur Radio
TCP/IP Networking. It's just such a good match overall with the likely
way that UDRX networks will likely evolve.
4. Markdown - yes. It's the new HTML, and even more efficient.

One related comment related to the apps - please include some simple
way for the system to be able to make use of secondary storage, such
as a USB flash drive, for storage of user content such as email
messages, etc. I think that I'm going to be using my UDRX so much that
I don't want to fill up and overflow whatever native storage the UDRX
will include in the base unit.

I'm glad that you responded in detail to those that just want a
flexible RF modem. Good grief - that functionality is IN there for the
1% that want to play at that level. Apparently it's tough to convince
the 1% that they're not paying any more, waiting any longer, suffering
from any inefficiencies for having a processor and OS that supports
apps that they can easily bypass and play with pure I and Q.

For the rest of us (you know, the ones that want to throw money at you
and buy MULTIPLE radios, build networks, encourage others to buy
UDRXs)... PLEASE DO develop apps that will be included, supported, and
documented!!!

Thanks,

Steve Stroh N8GNJ
Redmond, WA area
unabashed UDRX fanboy

On Wed, Mar 12, 2014 at 9:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
> When using email over RF either peer to peer or winlink a mail client is required.
>
> We support POP3 and IMAP so you may use your favorite standard email client such as Outlook, AppleMail or Thunderbird.
>
> In order to have a configuration free app we also have a webmail client pre-installed on the UDR. Currently we're using Neomail and it is perfectly satisfactory. However it is no longer actively supported.
>
> There are some advanced features that I believe will be important in the future such as:
>
> * Markdown Support
> * Authentication
> * BBS Style Bulletins
>
> SquirrelMail and Horde look interesting.
>
> What are your thoughts on Webmail Clients? Debian packages strongly preferred.
>
> Cheers,
> Bryan K7UDR
Re: Webmail Clients

Steve Stroh N8GNJ <steve.n8gnj@...>
 

Michael:

I think you make my point rather eloquently, when you conflate RAID
storage and an Amateur Radio network. In my experience, if you're
talking about RAID storage, such usage trends more towards the 1%...
as opposed to the 99% of ordinary Amateur Radio users that I expect to
buy the UDRX and want, and use, the apps that will be include in/on
the UDRX. Not to mention the novel (to me) concept of "... security of
the network path itself" in relation to an Amateur Radio network given
the restrictions on using encryption on Amateur Radio frequencies
(that literally anyone can monitor) and resulting distinct LACK of
security.

I have the benefit of having met the developer of the RF portion of
the UDRX, and as a result have every confidence that users like you
that want to bypass the built in apps and use the UDRX purely as an RF
modem, yeah, "it IS in there".

The amateur radio networks that I've seen that will benefit enormously
from the UDRX typically have really basic computers and limited
software and capabilities (such as EOCs with Winlink software talking
to 1200 baud TNCs). With the built-in apps, incorporating the UDRX
into such Amateur Radio networks will be easy - just use a web browser
on the existing PC.

But perhaps we're comparing apples and oranges - as far as I'm aware,
the UDRX is designed for, will be manufactured for, and operated on
Amateur Radio frequencies, by licensed Amateur Radio operators... 99%
of whom probably won't be using RAID storage on their Amateur Radio
systems.

I think Northwest Digital Radio IS listening - to ALL the potential
customers for the UDRX.


Steve N8GNJ

On Thu, Mar 13, 2014 at 10:44 AM, Michael E Fox - N6MEF <n6mef@...> wrote:



You missed the point.



My point is that all this time spent on defining applications could and should be spent on defining management/configuration screens, status screens, logging, etc. for the primary purpose of this box. This would include screens for OS (disk usage, memory usage, etc.), radio (power level, SWR, etc.), signal levels (including historical), modulation schemes (selection, status, ...), link status, error rates, and bridging function (STP, forwarding status, MAC cache, etc.). If all that stuff is not "IN there" and done well, then the primary function, the ONE thing that we need this box for -- RF bridging -- is not achieved (at least not in a manageable/deployable way). (Just look at a $95 Ubiquity 802.11 radio for an idea of some of the stuff that's needed to actually operate RF bridges in real world networks. Everything else, all your apps, can be done elsewhere/anywhere (and already are). I don't really care if they get added, but we can add linux packages ourselves. What we can't do is develop the management/config/status/troubleshooting screens. That's gotta be done by the folks building the unit. In my opinion, any time not focused on that is time that should be refocused.



And not to put too fine a point on it, but for those of us who do intend to purchase multiple radios and incorporate them into real networks, the user applications will be (or already are) on their own machines with RAID storage, plenty of memory, etc., with their own security. Subjecting a network device to user logins compromises the security of the network path itself. And creating a single point of failure by mixing an application server and a network device would be a real junior level move. To use your percentages, 99% of network design/management folks would never do that. The other 1% are probably unemployed. If you want to play around that way, or use it as an end-user station, that's up to you - it's a free country, and, after all, it's a hobby. But your assertion that only 1% would keep user apps and network function separate is just ridiculous and indicates you've never really run a substantial network.



I've said my piece. The developers can choose to listen or not. I hope they do.



Michael

N6MEF
Re: Webmail Clients

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

On Thu, Mar 13, 2014 at 11:25 AM, Matthew Pitts <daywalker_blade_2004@...> wrote:
 

What do you think the Node.js and Socket.io stuff that John talked about at DCC last fall is for?

For those who missed it - start at minute 5:15 in https://www.youtube.com/watch?v=r0svcHERWrM
 

Besides, they had working prototypes at Dayton in 2012.

We have since reworked the whole RF section for much better performance, and have new management code. 


Matthew Pitts
N8OHU 


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  
Re: Webmail Clients

Matthew Pitts <daywalker_blade_2004@...>
 

What do you think the Node.js and Socket.io stuff that John talked about at DCC last fall is for? Besides, they had working prototypes at Dayton in 2012.

Matthew Pitts
N8OHU


On March 13, 2014 1:44:35 PM EDT, Michael E Fox - N6MEF wrote:
 

You missed the point.

 

My point is that all this time spent on defining applications could and should be spent on defining management/configuration screens, status screens, logging, etc. for the primary purpose of this box.  This would include screens for OS (disk usage, memory usage, etc.), radio (power level, SWR, etc.), signal levels (including historical), modulation schemes (selection, status, …), link status, error rates, and bridging function (STP, forwarding status, MAC cache, etc.).  If all that stuff is not “IN there” and done well, then the primary function, the ONE thing that we need this box for -- RF bridging -- is not achieved (at least not in a manageable/deployable way).  (Just look at a $95 Ubiquity 802.11 radio for an idea of some of the stuff that’s needed to actually operate RF bridges in real world networks.  Everything else, all your apps, can be done elsewhere/anywhere (and already are).  I don’t really care if they get added, but we can add linux packages ourselves.  What we can’t do is develop the management/config/status/troubleshooting screens.  That’s gotta be done by the folks building the unit.  In my opinion, any time not focused on that is time that should be refocused. 

 

And not to put too fine a point on it, but for those of us who do intend to purchase multiple radios and incorporate them into real networks, the user applications will be (or already are) on their own machines with RAID storage, plenty of memory, etc., with their own security.  Subjecting a network device to user logins compromises the security of the network path itself.  And creating a single point of failure by mixing an application server and a network device would be a real junior level move.  To use your percentages, 99% of network design/management folks would never do that.  The other 1% are probably unemployed.  If you want to play around that way, or use it as an end-user station, that’s up to you – it’s a free country, and, after all, it’s a hobby.  But your assertion that only 1% would keep user apps and network function separate is just ridiculous and indicates you’ve never really run a substantial network.

 

I’ve said my piece.  The developers can choose to listen or not.  I hope they do.

 

Michael

N6MEF

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Steve Stroh N8GNJ
Sent: Thursday, March 13, 2014 9:17 AM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Webmail Clients

 

 


I'm glad that you responded in detail to those that just want a
flexible RF modem. Good grief - that functionality is IN there for the
1% that want to play at that level. Apparently it's tough to convince
the 1% that they're not paying any more, waiting any longer, suffering
from any inefficiencies for having a processor and OS that supports
apps that they can easily bypass and play with pure I and Q.

For the rest of us (you know, the ones that want to throw money at you
and buy MULTIPLE radios, build networks, encourage others to buy
UDRXs)... PLEASE DO develop apps that will be included, supported, and
documented!!!

Thanks,

Steve Stroh N8GNJ
Redmond, WA area
unabashed UDRX fanboy



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
2021 - 2040 of 2576  
More
Home Messages Hashtags Subgroups Wiki About Features Pricing Updates Terms Help Twitter