Date   

How open are we?

bhhoyer@...
 

This is a good topic and deserves it's own thread.


First off NW Digital Radio is a for profit corporation. We design and manufacture HW and sell it with adequate margins to keep us doing it in the future to the benefit of Amateur Radio (at least in theory). We will provide schematics and assembly drawings to enable repair/modification.


Our products rely on Open Source SW and appropriately, ALL of our software will be open source, which raises a couple of questions.


License:

At DCC last September Bruce Perens talked about how only a chump would use a completely open license and he has chosen GNU Affero GPL 3.0 for his company.  Bruce knows a lot more about Open Source Licensing than I do and I'm inclined to do the same. This hasn't been cast in stone so let us know if there's a legitimate amateur radio need that isn't served by this.


Repository:

All software that has been written or modified by NW Digital Radio will be in an open source repository most likely GitHub. The software is currently on a private svn repository. Moving it now is not a priority.


Web Interface vs Command Line:

We use Debian Linux 3.x and you can SSH into the UDR and do whatever you want, that's how we develop and test it. Everything you can do thru the web interface has a command line equivalent.


For example, to set the frequency you have to send rather cryptic commands using  2 different and non-standard SPI ports to both the DDS and the LO synthesizer. We have a user level command


freq 440800000


which figures the values out and calls the underlying routines. Commands are documented in the UNIX convention. Typing freq lists the syntax and options. All commands will be listed in a man page. The low level commands are documented in the data-sheets of the chips themselves (and they are ugly).


The web interface uses web sockets to transfer user commands to the UDR where the commands are executed.


The Slippery Slope:

How many companies can you think of that started out as open source then found that they had made something potentially valuable that they didn't want to share? This is why we formed the ARETF to move the software and the discussion away from NW Digital Radio and into the amateur community where it belongs.


Bryan - K7UDR



Re: PHY Layer Protocols

myyahoo@...
 

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC. If we were talking about long haul lossy links (as on HF), then FEC can be a winner. This is a reason that D-Star does not use FEC (and no one is complaining about packet loss there), and I don't believe that we'll need it for most applicaitons either. Time will tell, and there's nothing stopping anyone from comparing FEC to non-FEC transmissions and measuring it in real life...

You ask some interesting questions about channel allocation and use - I doubt that we will settle this before the radio ships, it is something that I know that I will be experimenting with - and I know that others will be doing the same. The beauty of SDR is that the standard doesn't need to be cast in stone, and there may be reasons for more than one standard depending on the network topology (a few stations scattered along a long distance may need a different solution than a city full of adjacent stations). Even after the first standard(s) are in place, if experimentation comes up with a better scheme some time later - it's trivial to load new software and reinvent the entire network!

As to channel allocation, one suggestion is to use an ISDN-like approach, with a fixed, narrow control channel that does all (or most) of the channel assignments, and then the rest of the bandwidth can be sliced-and-diced as needed. Deciding how this is coordinated among stations that do not have complete connectivity with one another (a distributed mesh) is one of the issues that needs to be tackled - but there are some simple allocation schemes that can be used to start. I certainly don't want to see a master/slave approach, but more like 'cooperating masters', where every station is part of the control puzzle. Some heuristics can be built to map the network and determine how to best use the channels at any given time, and give appropriate QOS based on the type of traffic - e.g., audio traffic is much more sensitive to latency than email or SSH connections.

- Richard, VE7CVS


Re: How Open? How Free? OpenBSD? NetBSD?

Tom Hayward <esarfl@...>
 

On Mon, Mar 2, 2015 at 12:17 PM, 'John D. Hays' john@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
NW Digital Radio will publish the source to its drivers and supporting software,
Allowing us to see the source isn't terribly useful. To do great
things, we need the code to come with a license that allows free
modification. What license will you use? (If you need help choosing
one, this site is great: http://choosealicense.com/licenses/ )

Healthy open source projects also have a defined process for
integrating changes. This is what has made GitHub so popular. Not only
do they provide a place to store code, they provide a way to suggest,
review, and integrate changes from others. Think about how you will
handle this process.

Tom KD7LXL


Re: How Open? How Free? OpenBSD? NetBSD?

dsp_stap@...
 

--- John Hays K7VE wrote:
> Some components, e.g. the AMBE-3000 chip,
> are protected intellectual property ...

I understand, and I really don't care. I won't use it.  I can use Codec2 instead.

By the way, I'm very pleased that the AMBE chip is not included in the radio by default, forcing all users to pay an AMBE tax, even if they don't plan to use it.  That was an excellent design decision!  Thank you.

> Some components, e.g. microprocessors, etc.
> are protected intellectual property ...

That's the scary part.  And you really didn't answer the question.

As soon as you can say it is really, totally, absolutely, completely open, fully documented, etc., you should emphatically do so.  Otherwise, I must assume that you have a Raspberry Pi situation.

So sad, for an otherwise very promising product.

Please alleviate my (and others') fears on this isue as soon as you possibly can.

> We are very interested in mobile ad-hoc
> mesh networking and DSP development
> (especially for modulation and demodulation
> using I/Q).  If you possess the skills, we
> would love to hear what you have done
> and what you have in mind.


As far as low-level signal processing goes, my email address should give you a very big clue as to my capabilities and accomplishments.
http://en.wikipedia.org/wiki/Space-time_adaptive_processing

http://www.eetimes.com/document.asp?doc_id=1278878

http://www.mathworks.com/help/phased/examples/introduction-to-space-time-adaptive-processing.html

I've also done very special purpose software defined radios.


I don't have as much experience in designing mobile ad-hoc mesh networking algorithms, but I did work for two years implementing algorithms which others developed for the WIN-T tactical radio system.  WIN-T is a mobile ad-hoc mesh networking TCP/IP communication system.  All of that work was at layer 2 of the OSI 7-layer network stack, which in fact is the interesting layer.

http://en.wikipedia.org/wiki/PM_WIN-T


73,
Ken N8KH

PS  The issue of fully documented radio interfaces is essentially identical to that of microprocessor booting, for all hardware in the radio. I don't need to know the innards of how it works, but I do require a complete interface specification so I can use the product.

PPS  It should go without saying that all users always need a complete interface specification; if they don't have a complete interface specification, then how do they properly use the product? It says something very bad about our modern world that interfaces are kept proprietary.  I will continue to choose and use products that are completely documented, and refuse to buy and use products that aren't. I hope your product is in the former category. But now I am not sure.  Please assure me as soon as you can.

PPPS  Send me one of the single board computers so I can port OpenBSD to it.  I'll send it back to you when I'm done. Or I'll be happy to send it on to the NetBSD team.


Re: PHY Layer Protocols

dsp_stap@...
 

--- John Hays K7VE wrote:
>Raw TCP/IP packets will need some kind
> of synchronization training sequence at
> the beginning.

Right.  Each lower layer wraps the previous upper layer in its own header and trailer before sending.  The PHY layer's header is for synchronization and error correction.

> Right now we have two Amateur protocols
> that provide framing around TCP/IP and
> handle the synchronization as part of their frames.
>
> TCP/IP runs within a UI AX.25 frame.
> TCP/IP runs within Ethernet Frames inside of D-STAR frames.

> ... create more robust and efficient air protocols,
> e.g. forward error correction, header compression ...

Really? D-Star has no FEC??  I'm shocked!!  (And horrified!)  If it were possible, I would now have an even lower opinion of D-Star than I had in the past.

The ARETF needs to develop a PHY layer protocol, or perhaps even more than one.  We should look to 802.1x for ideas.

All PHY layer protocols should do FEC, and synchronization.  Perhaps we need a very simple PHY layer that does only that, for simple point-to-point links.

Then perhaps we need more complex PHY layers which handle media access (to minimize collisions and thus maximize throughput).

How fast will Xmit/Recv switching be?  Will it be fast enough for TDMA?

Finally, I'm thinking we want more complex LINK layer which would handle discovery, link establishment, ad-hoc networking, etc.

It is not clear to me how to handle frequency selection. It is clear to me that if we can solve the problem of using multiple chanels simultaneously in a network, it has the potential to increase aggregate network throughput. Frequency selection is part of the physical layer, but perhaps it should be controlled at the link layer.  On the other hand, how do you tell all nodes who might want to talk to node X that he has moved to channel Y?  What about the choice to QSY? Should that control be centralized?  That seems like a bad idea, but it is also not clear how to do it in a distributed fashion.  What happens when node Z didn't get the message, and continues to waste bandwidth on channel X, talking to node X, when node X has QSYed to channel Y?

I think there is possibly a Ph.D. thesis lurking in the problem of channel selection controlled at the link layer. I note that NOBODY has done it yet.  I've never read any academic papers on the subject.  And it is such an obvious solution; hams have been doing it on nets for passing traffic for almost 100 years -- maybe longer.

All of a sudden, ham radio is fun again.

73,
Ken N8KH


Re: How Open? How Free? OpenBSD? NetBSD?

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



On Sun, Mar 1, 2015 at 11:59 PM, dsp_stap@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

How open/free will the platform be?

Different people have different definitions of these terms.  Here is our vision.

NW Digital Radio builds hardware.  We depend on many outside software developers, mostly open source, to support our hardware.

NW Digital Radio believes that the Amateur Radio community is best served when that hardware runs software developed by the Open Source community and specifically by amateur radio operators.

Some components, e.g. the AMBE-3000 chip, microprocessors, etc. are protected intellectual property and we will honor established intellectual property law.

NW Digital Radio will publish the source to its drivers and supporting software, with the caveat that NW Digital Radio does not anticipate such limitations, but some hardware components that go into a product come with non-disclosure requirements, in which case we will divulge as much as we are permitted and will document when we are unable to share additional information. 

Should NW Digital Radio enter into agreements with commercial customers that require some information and/or code be kept confidential, we will honor those agreements, and treat such as a separate product, but will continue to provide amateur radio products with open access to our hardware and amateur radio specific software as stated above.


Will I be able to port OpenBSD, compile all of the device drivers, and have the computer/radio run on OpenBSD instead of Linux?  (Requiring GPL for some software is fine with me, and even preferred, to make sure it stays open and free.)


Assuming the requisite skill, NW Digital Radio, encourages independent development and support.  However, we cannot be liable for any damages that arise out of that development, as it is independent and not under our control. Selection of licenses is up to the authors of the software.
 


(I prefer OpenBSD for all interfaces to the outside world, for its greater security.  A radio interface is certainly an interface to the outside world.)

How will the system boot?  U-Boot?  PXE?  Either?

Our current implementation uses U-Boot, but could be subject to change.
 


Will it be possible to completely control/configure the system via text-based files, or will the web server be required?  If I want to, can I disable the web server, and control it via text-based files in /etc?  I don't mind if the GUI is provided for other people to use, but I prefer a traditional text-based interface for myself.


There is no requirement to run the web server or a gui.  In a complex and evolving system such as the UDRX, control of various components may have varying requirements whether text base configuration files, api, or other mechanisms, we cannot guarantee that implementations (often done by others and adopted by NW Digital Radio) will always meet every user's expectations and preferences.
 


73,
Ken N8KH

PS  Having NetBSD ported to the platform would be another feather in your cap.  And you don't have to do the work.  The NetBSD folks will do it for you if you are open enough.

Even within our small staff we have BSD advocates.  With limited resources we will likely settle on a single OS/Distribution for direct delivery on the UDRX.  This does not prevent others from providing distributions with accompanying support.
 

PPS  I'm interested in helping to develop mobile ad-hoc mesh networking algorithms and protocols.  I also do DSP.

We are very interested in mobile ad-hoc mesh networking and DSP development (especially for modulation and demodulation using I/Q). If you possess the skills, we would love to hear what you have done and what you have in mind.
 


PPPS  I'm also interested in the next generation radio, which should be capable of roughly 400 kHz - 1 MHz of instantaneous bandwidth, and correspondly higher data rates, perhaps on the microwave bands.



Our focus for now is getting the UDRX ready for market.  We have made provisions for somewhat higher bandwidth in the UDRX, however, in the US we are limited by regulations as well as being good neighbors to other spectrum users.

There are many microwave products out there which provide higher bandwidth at reasonable prices, we have to determine if we would add value with our offerings. 

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: RF access point application confirmation

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

Ken,

Raw TCP/IP packets will need some kind of synchronization training sequence at the beginning.  Right now we have two Amateur protocols that provide framing around TCP/IP and handle the synchronization as part of their frames.

TCP/IP runs within a UI AX.25 frame.
TCP/IP runs within Ethernet Frames inside of D-STAR frames.

This will be in our early releases.  

We believe there is plenty of opportunity to create more robust and efficient air protocols, e.g. forward error correction, header compression (ala IPv6), more efficient modems, etc. and we invite developers and experimenters to do so.  Our system is open to allow such development and experimentation.  So, if one has the skill to develop and support such improvements we are all for it.

On Sun, Mar 1, 2015 at 11:48 PM, dsp_stap@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

--- Michael E Fox - N6MEF wrote:
> The UDRX-440 functions as either a layer 2 bridge or a layer 3 router.

I'm interested only in TCP/IP, not AX.25 or D-Star.  So I have the same question.

If the radio doesn't yet have that capability, I assume it will be possible to write software to make it so (even if that requires re-transmitting packets on the same, or different, frequency).  Is that correct?

73,
Ken N8KH

PS  Part of mesh networking will be the link layer, and connecting/solving the hidden node problem.  Not all nodes should be connected; aggregate network bandwidth can be higher, and the users served better, under an optimal link layer solution, rather than an everybody connected to everybody link layer solution.  This is still a very active area of research in which amateur radio operators could contribute a great deal -- if only we had the hardware to experiment with.

__._,


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


How Open? How Free? OpenBSD? NetBSD?

dsp_stap@...
 

How open/free will the platform be?

Will I be able to port OpenBSD, compile all of the device drivers, and have the computer/radio run on OpenBSD instead of Linux?  (Requiring GPL for some software is fine with me, and even preferred, to make sure it stays open and free.)

(I prefer OpenBSD for all interfaces to the outside world, for its greater security.  A radio interface is certainly an interface to the outside world.)

How will the system boot?  U-Boot?  PXE?  Either?

Will it be possible to completely control/configure the system via text-based files, or will the web server be required?  If I want to, can I disable the web server, and control it via text-based files in /etc?  I don't mind if the GUI is provided for other people to use, but I prefer a traditional text-based interface for myself.

73,
Ken N8KH

PS  Having NetBSD ported to the platform would be another feather in your cap.  And you don't have to do the work.  The NetBSD folks will do it for you if you are open enough.

PPS  I'm interested in helping to develop mobile ad-hoc mesh networking algorithms and protocols.  I also do DSP.

PPPS  I'm also interested in the next generation radio, which should be capable of roughly 400 kHz - 1 MHz of instantaneous bandwidth, and correspondly higher data rates, perhaps on the microwave bands.


Re: RF access point application confirmation

dsp_stap@...
 

--- Michael E Fox - N6MEF wrote:
> The UDRX-440 functions as either a layer 2 bridge or a layer 3 router.

I'm interested only in TCP/IP, not AX.25 or D-Star.  So I have the same question.

If the radio doesn't yet have that capability, I assume it will be possible to write software to make it so (even if that requires re-transmitting packets on the same, or different, frequency).  Is that correct?

73,
Ken N8KH

PS  Part of mesh networking will be the link layer, and connecting/solving the hidden node problem.  Not all nodes should be connected; aggregate network bandwidth can be higher, and the users served better, under an optimal link layer solution, rather than an everybody connected to everybody link layer solution.  This is still a very active area of research in which amateur radio operators could contribute a great deal -- if only we had the hardware to experiment with.


Re: 44 addresses / JNOS 56K / Gateway Security ?

Bill Vodall <wa7nwp@...>
 

That was fun...

1.5 billion earthlings find social networks a bit more interesting..
Compare that to the 15 or so folks still on packet radio.. The
multi-media multi-mode communications web application (Facebook and
more) is the exciting future..
Just rediscovered the "NW DIgital Radio" Facebook group and invited a
hundred or so of my closest ham friends.. That's one little step
toward moving beyond the 20th century...

Bill, WA7NWP


Re: 44 addresses / JNOS 56K / Gateway Security ?

Bill Vodall <wa7nwp@...>
 

A few years ago, there was a crash at the National Championship Air Races in
Reno, NV, injured dozens, killed a few. I wasn't there... I was 10 miles
away at the time; Yet, the cell network was down, and I couldn't make calls
or send texts. My amateur radio saved the day,
I had a similar experience when, several years ago, we had a nasty
windstorm that nailed the power grid and it was lights out for 5 days.
That's when I realized that Ham Radio with APRS was THE ultimate
situational awareness information tool. It still is.

The promise of talking to Australia got me to get my
license when I was young... But I still haven't done it, because 15 years later...
It was just this week that we on a different discussion list realized
that an experimental HF SDR data radio system can now be had for less
than $200... That would be a RXTX three band transceiver and a new
RPI 2. I know that station will easily WSPR to Australia, probably
WSJT or APRS-messenger and maybe even on APRS HF packet with the new
bit correcting software.

Are we having fun yet?

Bill


Re: 44 addresses / JNOS 56K / Gateway Security ?

Bill Vodall <wa7nwp@...>
 

Had you said "We wanna make a facebook-like social network," that would have
been one thing... It's probably a "Thing" that would be popular for a few
minutes in a few geographic regions before following BBS' 1998 journey into
obscurity, but it would be a thing none the less.
1.5 billion earthlings find social networks a bit more interesting..
Compare that to the 15 or so folks still on packet radio.. The
multi-media multi-mode communications web application (Facebook and
more) is the exciting future..

But that's a far cry from telling the high schoolers that they can Facebook
on Ham Radio; Merely making the statement could be a liability, because what
happens when they take you literally?
I would love to see a hand full of high schoolers doing Facebook
across town on Ham Radio. It would be an awesome accomplishment and
probably one of the high points for the year.

The unfortunate twist is that Ham Radio isn't needed for it. That's
all available with COTS cheap hardware. It could be shoehorned into a
pseudo Ham Radio project with some small advantages but then it would
be quickly shot down.

Not to mention the fact that Facebook uses all kinds of media types that
aren't well suited for this bandwidth... And once all restrictions pan out,
it won't really be very Facebook like. In fact, it will be fairly BBS
like... And as previously mentioned, that lost its allure about two decades
ago.
What bandwidth restrictions? With a bit of creativity we can do
fractional gigabits. Even limiting it to the technology sponsoring
this discussion - crafty multicasting and caching techniques can
provide far more than the apparent native speeds.

So again... What real traffic will this network carry?
IM, CHAT, Email, pictures, files, database replication, federated
wiki's, audio, ham radio now presentations.. Everything...

And if it's just
EmComm stuff... I'm on board, I'll set up a node... But I won't be comparing
it to Facebook, and I sure won't be presenting it to the younger generation
as any kind of revolutionary wave of the future.
We have far more potential than that... If we don't do it - we might
as well just move over to running CW emulators on some Skype channel.

Bill


Re: 44 addresses / JNOS 56K / Gateway Security ?

"Tyrell Jentink, KD7KUJ" <tyrell@...>
 

A few years ago, there was a crash at the National Championship Air Races in Reno, NV, injured dozens, killed a few.  I wasn't there... I was 10 miles away at the time; Yet, the cell network was down, and I couldn't make calls or send texts. My amateur radio saved the day, not only getting me directions to where I needed to go, but also kept me updated faster, and with more accurate information than the news was providing.

I was the president of the student amateur radio club at the University of Nevada. That story excited kids at conventions, but it didn't even attract new hams from the Red Cross club (Although, we did get 2 people from the Doomsday Prepper club... But I think they were interested before I talked to them). The IEEE kids looked at us like we were some relic of the past, and they looked at our shack like it was a museum. I heard a resounding "I don't wanna take ANOTHER test, just to get to play with technology that my cell phone laughs at, just in the off chance that we have another city wide emergency like the plane crash."

We shouldn't have to emulate the commercial world... But EmComm isn't attracting the kids. The promise of talking to Australia got me to get my license when I was young... But I still haven't done it, because 15 years later, I still can't afford an HF radio. There are a lot of half-baked promises built into this hobby... Things that sound like they should attract new people, but when faced with the reality of time and money prioritization, just don't pan out with the majority of young people.

We need creativity. We need something that has a coolness factor that can't be beat by the commercial world. In the '80s and '90s, packet seemed to meet that description... But we haven't done anything revolutionary since the iPhone.

On Feb 27, 2015 7:09 AM, "ve7dhm@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

Amateur radio was/is portable/mobile/base station radios giving those
who can pass an exam the capability to talk across town or around
the world using voice and data. No infrastructure required.

Commercial development morphed it into a capability for the masses. So
now a greater part of everyones paycheck goes to pay for their monthly
communication expense than when it was landlines and over the air TV.
A huge infrastructure is required.

A friend went to an emergency planning group meeting and as he was
describing 1200 baud packet radio, the equipment, the nodes for
extending communication range, and the application software a couple
of IT guys at the table scoffed at the idea of using such a slow
system for an EOC emergency message system as a backup.  The friend
walked over to the IT guys and handed them a pencil and piece of paper
and said well then you had better start learning to write real fast
because that's all you are left with when infrastructure fails.

So maybe showing the kids of the world a UDRX-440 based network isn't
so bad after all.  It doesn't have to mirror the commercial world...
where is the innovation in that?  But it certainly has the potential
capability of handling text, voice, pictures, GPS data faster than
writing with a pencil.

Revolutionary....no monthly user fee and the capability to keep working
when the infrastructure fails....something to show the kids.

Paul VE7DHM


Re: 44 addresses / JNOS 56K / Gateway Security ?

ve7dhm@...
 

Amateur radio was/is portable/mobile/base station radios giving those
who can pass an exam the capability to talk across town or around
the world using voice and data. No infrastructure required.

Commercial development morphed it into a capability for the masses. So
now a greater part of everyones paycheck goes to pay for their monthly
communication expense than when it was landlines and over the air TV.
A huge infrastructure is required.

A friend went to an emergency planning group meeting and as he was
describing 1200 baud packet radio, the equipment, the nodes for
extending communication range, and the application software a couple
of IT guys at the table scoffed at the idea of using such a slow
system for an EOC emergency message system as a backup.  The friend
walked over to the IT guys and handed them a pencil and piece of paper
and said well then you had better start learning to write real fast
because that's all you are left with when infrastructure fails.

So maybe showing the kids of the world a UDRX-440 based network isn't
so bad after all.  It doesn't have to mirror the commercial world...
where is the innovation in that?  But it certainly has the potential
capability of handling text, voice, pictures, GPS data faster than
writing with a pencil.

Revolutionary....no monthly user fee and the capability to keep working
when the infrastructure fails....something to show the kids.

Paul VE7DHM


Re: 44 addresses / JNOS 56K / Gateway Security ?

ve7dhm@...
 

Well, thanks for the feedback.  All comments interesting.

44 allocation request: I have a request in at portal.amp.org
The BC admin emailed me and after some discussion he forward
my allocation request up to Luc Pernot.  That's where that
stands.

Existing LAN or my own LAN.  Just trying to find out what other
UDRX-440 users plan to do in the Puget Sound area.  Yes I could
do my own thing.  But considering what was in place years gone
by with the 1200 baud 2M / 220 / 440 Vancouver/Victoria/Seattle
packet system I was wondering if it might be able to rebuild it
but having increased speed / capacity.  This would require some
frequency and IP co-ordination.

Basil, N7NIX, thanks for the WL2K message.  Great to see there is
a 2M path between us.  Looking forward to trying the UDRX-440 between
us.

John, K7VE, thanks for the info and yes the map says it all.  Once
the UDRX-440 hits the street I am sure more orders will follow to
get in on the action.  After some initial testing my plan is to give
a presentation, to several groups in the Victoria area, on how the
UDRX-440 can be used to supplement or replace existing equipment.
1200 baud 2M and or 440 packet is in all 10 municipal EOCs and 3
districts over here on southern Vancouver Island.  An interesting
project would to make it a UDRX-440 MESH network with also mobile
units.

Richard, VE7CVS, thanks for the comments.  Lots to play with and lots
to learn...just like the long past years of VARPA and VAPO when packet
radio was new.  Back a few years ago I helped setup a local network,
using ID-1s for the Swiftsure Yacht Race.  The rounding mark vessels
where equipped with a laptop, ID-1, antenna, and camera.  I setup an
ID-1 on a hill top with a wifi link back to my house as a gateway.
The hams on the boats took photos and short length videos and ftp the
files back to a server.  Many megabytes of data were successfully sent
to the server.  The rocking of the boats caused some problems but the
fog really killed the ID-1 signal when it rolled by down the strait!
It was an interesting experiment and fun to do.  Really looking
forward to playing with the UDRX-440.

Paul VE7DHM


Re: 44 addresses / JNOS 56K / Gateway Security ?

"Tyrell Jentink, KD7KUJ" <tyrell@...>
 

Had you said "We wanna make a facebook-like social network," that would have been one thing... It's probably a "Thing" that would be popular for a few minutes in a few geographic regions before following BBS' 1998 journey into obscurity, but it would be a thing none the less.

But that's a far cry from telling the high schoolers that they can Facebook on Ham Radio; Merely making the statement could be a liability, because what happens when they take you literally?

Not to mention the fact that Facebook uses all kinds of media types that aren't well suited for this bandwidth... And once all restrictions pan out, it won't really be very Facebook like. In fact, it will be fairly BBS like... And as previously mentioned, that lost its allure about two decades ago.

So again... What real traffic will this network carry? And if it's just EmComm stuff... I'm on board, I'll set up a node... But I won't be comparing it to Facebook, and I sure won't be presenting it to the younger generation as any kind of revolutionary wave of the future.

On Feb 26, 2015 11:36 AM, "Bill Vodall wa7nwp@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

>> > So what are people planning on doing once a 56k mesh network exists?
>> > What
>> > kind of traffic will it carry?
>>
>> Facebook and much more... With RF multicast to take advantage of our
>> spectrum resources instead of the old one-to-one model that so
>> hindered the previous generations of tools.
>>
>> Bill, WA7NWP

> Facebook uses HTTPS, which is encrypted, and is definitely designed to
> "Obscure the meaning of the message," and is definitely against the rules in
> the US.

That's an implementation detail. Our better version can be and do
what we want... It's the concept, and beyond, that we need to work
on.

Bill


Re: 44 addresses / JNOS 56K / Gateway Security ?

Bill Vodall <wa7nwp@...>
 

So what are people planning on doing once a 56k mesh network exists?
What
kind of traffic will it carry?
Facebook and much more... With RF multicast to take advantage of our
spectrum resources instead of the old one-to-one model that so
hindered the previous generations of tools.

Bill, WA7NWP
Facebook uses HTTPS, which is encrypted, and is definitely designed to
"Obscure the meaning of the message," and is definitely against the rules in
the US.
That's an implementation detail. Our better version can be and do
what we want... It's the concept, and beyond, that we need to work
on.

Bill


Re: 44 addresses / JNOS 56K / Gateway Security ?

"Tyrell Jentink, KD7KUJ" <tyrell@...>
 

Facebook uses HTTPS, which is encrypted, and is definitely designed to "Obscure the meaning of the message," and is definitely against the rules in the US.

On Feb 26, 2015 11:00 AM, "Bill Vodall wa7nwp@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

> So what are people planning on doing once a 56k mesh network exists? What
> kind of traffic will it carry?

Facebook and much more... With RF multicast to take advantage of our
spectrum resources instead of the old one-to-one model that so
hindered the previous generations of tools.

Bill, WA7NWP


Re: 44 addresses / JNOS 56K / Gateway Security ?

Bill Vodall <wa7nwp@...>
 

So what are people planning on doing once a 56k mesh network exists? What
kind of traffic will it carry?
Facebook and much more... With RF multicast to take advantage of our
spectrum resources instead of the old one-to-one model that so
hindered the previous generations of tools.

Bill, WA7NWP


Re: 44 addresses / JNOS 56K / Gateway Security ?

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

BTW, Chris (G1FEF) is actively looking for people willing to help enhance portal.ampr.org

LAMP experience is helpful.


On Thu, Feb 26, 2015 at 8:31 AM, 'Tyrell Jentink, KD7KUJ' tyrell@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

I've always wanted to play with 44net. I mean, I really have no idea what I expect to achieve... I feel like reviving the BBS network of the past would be counterproductive for the Advancement of the Radio Art... Yet, at the same time, relying on the internet isn't good for the resilience of communication in general. It seems that the 44.x allocation had good intentions, and it certainly seems that amateur radio pushed the advancement of internet technologies early on, but we have dropped the ball. We need something creative if we want to become relevant again.

So what are people planning on doing once a 56k mesh network exists? What kind of traffic will it carry?

On Feb 25, 2015 11:03 PM, "myyahoo@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

Something that we need to influence when the UDRs start shipping in quantity. I have a 44.x net allocation for the old 56kbps network (I was last on there in 1998) in the Vancouver area but we may need to look at different routing mechanisms as mesh networking becomes a reality, and gateways to the network will be more varied and variable. Guess I'll have to study up on BGP. Good thing I work at a company that has a 'past' with BGP... Don't have a CCIE - yet...

I'm now in San Jose, CA, so I also need go write the local exams to get 'local' and confuse things less when we form a network here. Think I've said this before. :-)

If the political processes are not working, it may be because no one is interested in supporting and maintaining them. That may be fixed by offering to step up to the plate - but then again, there is frequency coordination... not been a lot of hope in that area. (We will need to push there too. ;-)

If the 44.x net progress has stagnated, new blood may be able to effect some change (politics notwithstanding). Some of us associated with this project have been associated with packet radio since the early days and may be able to effect some gentle pressure among friends to help things move along. If not, there are alternatives (e.g., 10.x net and NAT/PAT) that can get us running without employing the 44.x net, at least initially, if we need IPv4 address space, and IPv6 is wide open. Getting a piece of 44.x allocated to this effort would be another alternative. We don't have to clean up the whole 16M address space, if we were to get a 64K slice we'd serve the continent for a millennium or three. :-)

BTW - we're really pushing to use IPv6 here (the on-air footprint could be critical to performance, with IPv6 header compression), where one subnet is the size of the *entire* IPv4 space, but we'll likely need some IPv4 space for a while to tide us over for maybe the next decade until the Internet becomes more IPv6 aware. Some 6-to-4 conversion will be likely to boost performance while retaining compatibility. We only really need numerous IPv4 addresses for inbound-to-ham-net connections, PAT can help solve outbound - but we need to control those inbound connections, to prevent non-ham-legal content from traversing the ham links. Software for this already exists, in one form or another.

- Richard, VE7CVS (/W6)




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223