[Roel] wanted to put a wireless weather station in his greenhouse. Even though the weather station was supposed to transmit over fairly long distances, the geometry of his back yard and a few stone walls killed the radio signal even after putting a good antenna on the receiving side of his wireless weather station setup. Wanting to get his weather station working, [Roel] did the sensible thing and built a packet radio setup out of a pair of walkie talkies, greatly increasing the range of his weather station.

This build comes after [Roel] spent a great deal of time reverse engineering the wireless protocol of his Thierry Mugler weather station. With a little bit of code, [Roel] is able to get the current temperature and humidity reading into his Linux box. This system relies on the transmitter inside the weather station, so the system falls apart over any sufficiently large distance.

To increase the range of his weather station, [Roel] took his existing hardware and added a pair of inexpensive FRS walkie talkies. The build uses the hardware from his previous build to get the radio data from the weather station. This data is sent over to an ATmega88 where it’s converted to packet radio and sent over the walkie-talkie. On the receiving side, the output of a second walkie-talkie is piped into the Linux soundmodem app (link, but it’s down as of this writing) where it’s decoded. Sending the received data to gnuplot makes a very nice graph of the temperature and humidity.

[Roel] put the code for both the tx and rx sides of the build up on his build page. Very nice work that uses very inexpensive hardware.

A blog posting with some thoughts and pros/cons on 6 meter packet can be found here.

While it’s not as bad as it used to be, six meter “band plans” vary from area to area and country to country. You take that and add in that 6 meters is a “skip” band with strong and frequent seasonal e-skip openings, TE propagation, meteor scatter, even globe spanning F-layer skip during strong solar peaks, and you have a recipe for unintentional QRM at times. As such, take extra care in choosing a frequency especially when it will have 24×7 activity on it.

For packet, at least in N. America, there has traditionally been four regions of the 6 meter band used for packet radio:

50.600 to 50.800 MHz
51.120 to 51.180 MHz
51.620 to 51.680 MHz
53.490 to 53.590 MHz

The 50.600-50.800 and 51.120-51.180 MHz regions are by far the most commonly used of the four. There has been packet activity in those two regions for decades.

50.600-50.800 MHz:

Channel layout within the 50.600-50.800 MHz region is pretty much a free for all.  The only “standard” packet frequency in that region is 50.6200 which WAS probably the most common 1200 baud frequency at one time. Today you will probably find little if any activity there. At one time PropNET was using it for packet beacons, but that faded away years ago. While I don’t think PropNET is dead (on HF at least), today most ops interested in HF/VHF propagation study find the WSPR network and approach superior.

Some known active six meter packet frequencies in this region are:

50.615 – Arkansas – I think they still have several 1.2k “backbone” sites online. (see Note 1)
50.620 – Packet Calling Freq (1.2k) – doubt you’ll find any daily activity there anymore.
50.640 – Ohio – several 24×7 general use 1.2k sites on the air.
50.680 – Missouri – some 4.8k “backbone” sites in the NE half of the state.  (see Note 2)
50.730 – Kentucky, New York – 1.2k general use in NKY, 1.2k “backbone” use on Long Island NY. (See Note 3)

Note 1 – Yeah, odd allocation right up against 50.620 MHz.  Given current state of 50.620, doubt it’s an issue.
Note 2 – Some band plans list this as a SSTV frequency along with 50.950 MHz.
Note 3 – NY nodes are backbone use only. You can try WA4ZKO-1 here when the band is open.

Usage Notes:
On frequencies listed as “back bone” general user access/connects may be frowned upon or rejected by the system.
On frequencies listed as “general use” these are typically frequencies where user access is welcome.

Also 50.700 MHz used to be a common RTTY frequency, but I think most RTTY ops moved down to the area around 50.300 MHz if there is even much 6m RTTY anymore?

51.120-51.180 MHz:

Channel layout within the 51.120-51.180 MHz region is usually more structured and with four channels:

51.120 – California, Arizona – old 4.8k “back bone” links. Possibly defunct? (see Note 4).

51.140 – Ohio – 1.2k general use.

51.160 – North Carolina – 1.2k mixed use. (see Note 5)

51.180 – Maine – 1.2k general use.  (see Note 6)

Note 4 – While the info out there is vague, this freq was once used for a major coastal 6m 4800 baud back bone at one time. It used high profile nodes located on mountaintop sites and they covered a lot of territory. I think there was also a 4.8k link from SoCal into Arizona on this frequency at one time. I believe this network is most likely defunct now, but I could be wrong. I was told the Mt Otay (San Diego) site was still there, but I heard no sign of any AFSK or FSK packet on the freq the last time I checked.

Note 5 – mixed info on whether or not this frequency is still active.

Note 6 – Some packet radio folks in Maine reportedly have some 1200 baud stations active on this frequency.  You can try KB1TCE-1 or KB1TCE-7 here when the band is open to Maine.

51.620-51.680 MHz:

I have not noted any activity here since the late 1990′s. This is a region of the band where band plan”conflicts” are more likely to occur.

51.700  MHz was a proposed “National Packet Frequency” at one time (? late 1980′s). Best I can tell this idea never took hold and 50.620 MHz was already being used in a similar fashion. For many years 50.620 has been listed as the 6m packet calling frequency in most formal bandplans. Frankly, I would not expect to hear much regular activity on either frequency.

53.490-53.530 MHz:

At one time there was some 1200 baud APRS activity on 53.530 MHz. This is a region of the band  where band plan”conflicts” are more likely to occur.

So as you can see, there is still 6 meter packet activity out there. 6 meter packet radio can also be useful for detecting band openings since most systems are on 24×7 and usually beacon their presence every few minutes.

WA4ZKO

(corrections/additions to my callsign @ yahoo.com)

A blog posting with some thoughts and pros/cons on 6 meter packet can be found here.

While it’s not as bad as it used to be, six meter “band plans” vary from area to area and country to country. You take that and add in that 6 meters is a “skip” band with strong and frequent seasonal e-skip openings, TE propagation, meteor scatter, even globe spanning F-layer skip during strong solar peaks, and you have a recipe for unintentional QRM at times. As such, take extra care in choosing a frequency especially when it will have 24×7 activity on it.

For packet, at least in N. America, there has traditionally been four regions of the 6 meter band used for packet radio:

50.600 to 50.800 MHz
51.120 to 51.180 MHz
51.620 to 51.680 MHz
53.490 to 53.590 MHz

The 50.600-50.800 and 51.120-51.180 MHz regions are by far the most commonly used of the four. There has been packet activity in those two regions for decades.

50.600-50.800 MHz:

Channel layout within the 50.600-50.800 MHz region is pretty much a free for all.  The only “standard” packet frequency in that region is 50.6200 which WAS probably the most common 1200 baud frequency at one time. Today you will probably find little if any activity there. At one time PropNET was using it for packet beacons, but that faded away years ago. While I don’t think PropNET is dead (on HF at least), today most ops interested in HF/VHF propagation study find the WSPR network and approach superior.

Some known active six meter packet frequencies in this region are:

50.615 – Arkansas – I think they still have several 1.2k “backbone” sites online. (see Note 1)
50.620 – Packet Calling Freq (1.2k) – doubt you’ll find any daily activity there anymore.
50.640 – Ohio – several 24×7 general use 1.2k sites on the air.
50.680 – Missouri – some 4.8k “backbone” sites in the NE half of the state.  (see Note 2)
50.730 – Kentucky, New York – 1.2k general use in NKY, 1.2k “backbone” use on Long Island NY. (See Note 3)

Note 1 – Yeah, odd allocation right up against 50.620 MHz.  Given current state of 50.620, doubt it’s an issue.
Note 2 – Some band plans list this as a SSTV frequency along with 50.950 MHz.
Note 3 – NY nodes are backbone use only. You can try WA4ZKO-1 here when the band is open.

Usage Notes:
On frequencies listed as “back bone” general user access/connects may be frowned upon or rejected by the system.
On frequencies listed as “general use” these are typically frequencies where user access is welcome.

Also 50.700 MHz used to be a common RTTY frequency, but I think most RTTY ops moved down to the area around 50.300 MHz if there is even much 6m RTTY anymore?

51.120-51.180 MHz:

Channel layout within the 51.120-51.180 MHz region is usually more structured and with four channels:

51.120 – California, Arizona – old 4.8k “back bone” links. Possibly defunct? (see Note 4).

51.140 – Ohio – 1.2k general use.

51.160 – North Carolina – 1.2k mixed use. (see Note 5)

51.180 – Maine – 1.2k general use.  (see Note 6)

Note 4 – While the info out there is vague, this freq was once used for a major coastal 6m 4800 baud back bone at one time. It used high profile nodes located on mountaintop sites and they covered a lot of territory. I think there was also a 4.8k link from SoCal into Arizona on this frequency at one time. I believe this network is most likely defunct now, but I could be wrong. A few years ago I was told the Mt Otay (San Diego) site was still there, but I heard no sign of any AFSK or FSK packet on the freq the last time I checked.

Note 5 – mixed info on whether or not this frequency is still active.

Note 6 – Some packet radio folks in Maine reportedly have some 1200 baud stations active on this frequency.  You can try KB1TCE-1 or KB1TCE-7 here when the band is open to Maine.

51.620-51.680 MHz:

I have not noted any activity here since the late 1990′s. This is a region of the band where band plan”conflicts” are more likely to occur.

 51.700  MHz was a proposed “National Packet Frequency” at one time (? late 1980′s). Best I can tell this idea never took hold and 50.620 MHz was already being used in a similar fashion. For many years 50.620 has been listed as the 6m packet calling frequency in most formal bandplans. Frankly, I would not expect to hear much regular activity on either frequency.

53.490-53.530 MHz:

At one time there was some 1200 baud APRS activity on 53.530 MHz. This is a region of the band  where band plan”conflicts” are more likely to occur.

So as you can see, there is still 6 meter packet activity out there. 6 meter packet radio can also be useful for detecting band openings since most systems are on 24×7 and usually beacon their presence every few minutes.

WA4ZKO
(corrections/additions to my callsign @ yahoo.com)

© WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2012. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content.

Since the first of the year I have received several inquiries regarding 6 meter packet radio. Interesting since most past 6m inquiries usually revolved around if I knew of anyone active on 6m “DX” modes from EM87 (semi-rare grid). It is nice to see a revival in six meter packet interest. It brings some unique advantages and makes a lot of sense for a variety of scenarios.

A posting covering common 6 meter packet frequency usage can be found here.

I have often wondered why so many packet ops seem to ignore the two VHF bands that are often a better choice for packet radio than 2 meters. Those 2 bands are 6m and 220 MHz.  Yeah some will try to argue that 220 is UHF, but technically it is VHF (30-300 MHz = VHF) although it behaves like a nice mix of both. This fixation on 2m packet made some sense back a couple decades ago. Back in the 1980′s and early 1990′s the typical ham usually only owned a HF rig, a 2m rig, and maybe a 2m HT.  Hams that owned FM gear on any other band than 2m were a pretty low percentage, so putting most packet activity on 2m made sense back then.

As the hobby progressed into the late 1990′s, hams with 440 gear and dual-band mobiles/HTs became very common. Even the once limited selection of 220 FM gear faded as several 220 FM “off the shelf” radios became readily available. Today it is a pretty rare ham that does not have both 2m and 440 FM gear! A good percentage probably own a tri-band or quad-band radio.  Today many of the HF rigs now include six meters, some have HF plus 6, 2, & 440! So today many hams have some 6m or 220 FM capability. In short, a lot of the “gotta use 2m for packet” logic simply does not apply anymore and hasn’t for well over a decade.

Moving on….it seems that some folks are figuring out that if you have to deal with the noisier VHF bands for packet then you might as well take advantage of six meters and keep/free up your 2m/440 rig for voice usage. Often makes a lot of practical sense when you think about it.

So what are some of the pros and cons of using six meters for packet beyond freeing up your 2m/440 rig?

PROS:

1.  RANGE! – All things being equal, 6 meters will provide you with the longest VHF range. Signals at 50 MHz have a 9-10 dB free space path loss advantage over 2 meters. 6 meters is well suited for rural coverage situations where you need the best signal penetration into hilly or mountainous terrain. Packet network ops in Arkansas found 6m worked well in their terrain for a 6m packet backbone….same for parts of Missouri. Some packet radio movers-n-shakers up in Maine are using 6m packet to get past rugged terrain that was making 2m packet tough to impossible on some paths. Here in my area we find it works well for covering the very hilly terrain in parts of our county.

2.  Cheap – 6 meters is a relatively easy band to get active on. Many of the new HF rigs come with 6 meters (often 100w) included so many hams already have 6m available to them. Alinco makes a reasonably priced 50w FM mobile (DR-06T) that is well suited to 1200 baud packet use. At the end of this posting I have included some prices/links for the Alinco mobile if you are interested. There are even some 6m HT choices out there.  RCI/Ranger has some SSB/FM mobile/base radios available. Plenty of used/older 6m gear available too. Some of the “high split” VHF-Low Band commercial gear can be converted to cover at least the lower part of the 6 meter band.

3.  Plenty of antenna options. The Cushcraft AR-6 and Comet GP15 antennas are just two of many choices for FM usage. If you are into homebrewing and experimenting with antennas, then 6m is a great band for you. Antenna construction tolerances are much more forgiving at 6m compared to the higher bands (especially UHF). While beams for 6m have some size to them, a 2-3 element design is still of reasonable size for many installations and can be handled by a decent TV grade rotor if installed with care.

4.  Nice band for EMCOMM simplex use.  During portable EMCOMM use you are often unable to use large high gain antennas at heights needed for good 2m/440 simplex range. I have personally seen a simple 3 dB  Cushcraft AR-6 six meter vertical at 15-20′ cover a surprising amount of turf.  The AR-6 easily mounts on top of typical TV mast pipe, is around 110″ tall, but can be collapsed to about 50″ making it well suited to pack-n-go, unpack-n-deploy situations.

5.  Good choice from a self and served agency desense/QRM perspective. In my area most of our served agencies are on VHF-HI and this can create all kinds of QRM problems when 2 meters is used in close proximity. The use of 6m and 220 will usually prevent most of these problems. Why create potential self/served agency QRM if you don’t have to? As hams we have been given tremendous spectrum flexibility so let’s use it!

6.  It is easy to “feed” a 6m antenna. Feed line losses at 50 MHz are much lower than 2m and higher.  Even RG-8X is tolerable for many short 6m feed line run lengths.  With a 25′ run of RG-8X you will only loose about 0.5 dB at 50 MHz versus about 1 dB at 2m and nearly 2 dB at 440.  You can do some pretty long 6m feed line runs with good quality RG-8U or RG-213 and loose a tolerable 1.3 dB per 100′ at 50 MHz. You can get  just under 1 dB per 100′ with 9913 or LMR400 coax.

7.  Foliage losses are typically the lowest on 6m versus the other VHF/UHF bands.There is a reason why our military uses VHF-Low for a lot of their simplex needs and have even been known to show up in the 6 meter band.

8.  Tropo/Inversion type openings on 6m don’t seem nearly as pronounced as they are on 2m & up.

9.  E-skip band openings are common during the late spring/summer months (northern hemisphere) with another mini-peak around late December. This can be bad (QRM) or a good (fun) thing if you enjoy working 6 meter DX. Here in KY we share our main 6m packet frequency with a fairly chatty FlexNet packet system up on central and eastern Long Island NY. Since most of us around here are 6m DX’ers this serves as a handy band opening indicator for that part of New England.

CONS:

1.  VHF can be noisy spectrum for data usage and 6 meters is no exception. Power line noise is probably the most common issue, but 2 meters is often just as vulnerable.

2.  Nearby thunderstorm QRN will impact 6 meters more than 2 meters and at a greater range.

3.  6m HT antenna efficiencies are poor compared to 220/UHF. Stock 6m HT antennas are often little short of a glorified poorly radiating resistor. Due to the longer wavelength, 6m HT’s on already compromised stock antennas will perform poorly inside a metal vehicle compared to UHF.

4.  TVI can be a problem, but now that CH-2 TV usage has faded away in most ares this is not nearly the problem it used to be. I have actually had more TVI issues with 2m than with 6m.

5.  Building penetration performance is poor compared to UHF. 6m is great out in the country, but not a great band choice for urban use!

6.  E-skip band openings are common during the late spring/summer months (northern hemisphere) with another mini-peak around late December. This can be a “con” in that there is potential for unintentional QRM issues on some frequencies.

7.  Getting a good ground plane for a 6m mobile antenna can be a bit of a challenge, especially on a smaller vehicle. Expect to spend some time and effort getting the trunk lid and hood well bonded to the rest of the vehicle. Ignition noise can be problematic too.

So you can see that like any other band, 6 meters has its share of pros and cons.

Some current pricing (subject to change) and sources for the Alinco DR-06T 50w FM mobile are below:

$269.95 – R&L Electronics (Ohio)

$269.95 – The Antenna Farm (Montana)

$271.95 – Universal Radio (Ohio)

$259.95 – GigaParts (Alabama)

$278.99 – Installer dot com (Texas)

$265.00 – HamCity (California)

$249.99 – AES (Wisconsin)

$270.00 – CheapHam (New Jersey)

When figuring total cost, be sure to see what the shipping costs will be. Also watch out for “coupon” prices where you might be able to save a few dollars if patient.

I would also refrain from buying the “internal” TNC option as you can do much better for a TNC.

I am not endorsing any of the above vendors nor are they the only sources for the Alinco DR-06T 6 meter radio.

WA4ZKO

© WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2012. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content.

So you have plundered the High Seas of the Internet and the Ethernet?

When you swivel your chair around and look out the window toward the horizon, what is next to Plunder?

Maybe you need to be looking UP!

That’s right… the Interplanetary Internet! ‘Ha !’ you say? Think I’m blowing a little Vaporware vapor-trail up your butt? Swivel that chair back around and take notes. The IPN is coming, due to the current work on the DTN being funded by DARPA and kicked in the ass by Homeland Security, augmented by work being done under the auspices of NASA. What?

Firstly let us not forget, the current Internet was conceived, designed and implemented by the US Military, and paid for by the US Taxpayers. Then the technology and some early infrastructure was turned loose to the users of the world. Nice of them, eh? Little did DARPA dream of the extent the Internet would drill down to the basic fabric of the data-handling of everyone in the world.

The future vision of communications goes to Space. Yes the Interplanetary Internet. But, and there are a lot of buts: Speed of light, transmission speeds vs distance delays, temporary net failures due to Cosmic events or man-made sabotage/interference problems, along with an unbreakable network routing/encryption schema now only existing in the vapor of the vapor. This new frontier demands a complex combination of skills we are only now conceiving and developing. Space based communication delays and interruptions will no doubt require simplex packet type burst transmissions, with cloud type way-stations/relay-stations, instead of an almost instantaneous duplex emulating transmission type now enjoyed in today’s version of the Internet. This situation is further complicated by an interruptable data stream demand vs supply phenomenon combined with the complexities of network packet routing and top to bottom encryption.

We have already taken many of the initial baby-steps that will lead to the next ‘Leap of Mankind’ into tomorrow’s ‘taken-for-granted’ fundamental form of electronic communication.

The major basic building blocks of the end goal of the Interplanetary Internet will include the following concepts (to name only a few):

• Packet Radio
• Cloud Computing
• Delay-tolerant networking (DTN)

Let’s pirate some intel from Wikipedia and take a closer look-see at these concepts and see where the work is being done along the way:

Packet Radio

Packet radio is a form of packet switching technology used to transmit digital data via radio or wireless communications links. It uses the same concepts of data transmission via Datagram that are fundamental to communications via the Internet, as opposed to the older techniques used by dedicated or switched circuits.

Packet Node Controller

Packet radio is the fourth major digital radio communications mode. Earlier modes were telegraphy (Morse Code), teleprinter (Baudot) and facsimile. Like those earlier modes, packet was intended as a way to reliably transmit written information. The primary advantage was initially expected to be increased speed, but as the protocol developed, other capabilities surfaced.

By the early 1990s, packet radio was not only recognized as a way to send text, but also to send files (including small computer programs), handle repetitive transmissions, control remote systems, etc.

The technology itself was a leap forward, making it possible for nearly any packet station to act as a digipeater, linking distant stations with each other through ad hoc networks. This makes packet especially useful for emergency communications. In addition, mobile packet radio stations can automatically transmit their location, and check in periodically with the network to show that they are still operating.

Since radio circuits inherently possess a broadcast network topology (i.e., many or all nodes are connected to the network simultaneously), one of the first technical challenges faced in the implementation of packet radio networks was a means to control access to a shared communications channel. Professor Norman Abramson of the University of Hawaii developed a packet radio network known as ALOHAnet and performed a number of experiments around 1970 to develop methods to arbitrate access to a shared radio channel by network nodes. This system operated on UHF frequencies at 9600 baud. From this work the Aloha multiple access protocol was derived. Subsequent enhancements in channel access techniques made by Leonard Kleinrock et al in 1975 would lead Robert Metcalfe to use carrier sense multiple access (CSMA) protocols in the design of the now commonplace Ethernet local area network (LAN) technology.

In 1977, DARPA created a packet radio network called PRNET in the San Francisco Bay area and conducted a series of experiments with SRI to verify the use of ARPANET (a precursor to the Internet) communications protocols (later known as IP) over packet radio links between mobile and fixed network nodes. This system was quite advanced, as it made use of direct sequence spread spectrum (DSSS) modulation and forward error correction (FEC) techniques to provide 100 kpbs and 400 kpbs data channels. These experiments were generally considered to be successful, and also marked the first demonstration of Internetworking, as in these experiments data was routed between the ARPANET, PRNET, and SATNET (a satellite packet radio network) networks. Throughout the 1970s and 1980s, DARPA operated a number of terrestrial and satellite packet radio networks connected to the ARPANET at various military and government installations.

In order to get a small glimpse of networking complexities click this link to get a look at IP Protocols now being used.

Cloud Computing

The term “cloud” is used as a metaphor for the Internet, based on the cloud drawing used in the past to represent the telephone network, and later to depict the Internet in computer network diagrams as an abstraction of the underlying infrastructure it represents.

Cloud computing is a natural evolution of the widespread adoption of visualization, service-oriented architecture, autonomic, and utility computing. Details are abstracted from end-users, who no longer have need for expertise in, or control over, the technology infrastructure “in the cloud” that supports them.

The underlying concept of cloud computing dates back to the 1960s, when John McCarthy opined that “computation may someday be organized as a public utility.” Almost all the modern-day characteristics of cloud computing (elastic provision, provided as a utility, online, illusion of infinite supply), the comparison to the electricity industry and the use of public, private, government, and community forms, were thoroughly explored in Douglas Parkhill‘s 1966 book, The Challenge of the Computer Utility. Other scholars have shown that cloud computing’s roots go all the way back to the 1950s when scientist Herb Grosch (the author of Grosch’s law) postulated that the entire world would operate on dumb terminals powered by about 15 large data centers.

The actual term “cloud” borrows from telephony in that telecommunications companies, who until the 1990s offered primarily dedicated point-to-point data circuits, began offering Virtual Private Network (VPN) services with comparable quality of service but at a much lower cost. By switching traffic to balance utilization as they saw fit, they were able to utilize their overall network bandwidth more effectively. The cloud symbol was used to denote the demarcation point between that which was the responsibility of the provider and that which was the responsibility of the user. Cloud computing extends this boundary to cover servers as well as the network infrastructure.

After the dot-com bubble, Amazon played a key role in the development of cloud computing by modernizing their data centers, which, like most computer networks, were using as little as 10% of their capacity at any one time, just to leave room for occasional spikes. Having found that the new cloud architecture resulted in significant internal efficiency improvements whereby small, fast-moving “two-pizza teams” could add new features faster and more easily, Amazon initiated a new product development effort to provide cloud computing to external customers, and launched Amazon Web Service (AWS) on a utility computing basis in 2006.

In early 2008, Eucalyptus became the first open-source, AWS API-compatible platform for deploying private clouds. In early 2008, OpenNebula, enhanced in the RESERVOIR European Commission-funded project, became the first open-source software for deploying private and hybrid clouds, and for the federation of clouds. In the same year, efforts were focused on providing QoS guarantees (as required by real-time interactive applications) to cloud-based infrastructures, in the framework of the IRMOS European Commission-funded project, resulting to a real-time cloud environment.By mid-2008, Gartner saw an opportunity for cloud computing “to shape the relationship among consumers of IT services, those who use IT services and those who sell them”and observed that “organizations are switching from company-owned hardware and software assets to per-use service-based models” so that the “projected shift to cloud computing … will result in dramatic growth in IT products in some areas and significant reductions in other areas.”

In July 2010, OpenStack was announced, attracting nearly 100 partner companies and over a thousand code contributions in its first year, making it the fastest-growing free and open source software project in history.

Nebula is a Federal cloud computing pilot under development at NASA Ames Research Center in Silicon Valley, California. The project began in 2008 under the direction of Chris C. Kemp.

The Ames Internet Exchange, which hosts the Nebula Cloud, was formerly MAE-West, one of the original nodes of the Internet, and is a major peering location for Tier 1 ISPs, as well as being the home of the “E” root name servers. Nebula also connects to CENIC and Internet2, with 10GigE connections.

Nebula is an open-source project and uses a variety of open-source components, including OpenStack, Lustre and RabbitMQ.

Delay-tolerant networking (DTN)

Delay-tolerant networking (DTN) is an approach to computer network architecture that seeks to address the technical issues in heterogeneous networks that may lack continuous network connectivity. Examples of such networks are those operating in mobile or extreme terrestrial environments, or planned networks in space.

Recently, the term disruption-tolerant networking has gained currency in the United States due to support from DARPA, which has funded many DTN projects. Disruption may occur because of the limits of wireless radio range, sparsity of mobile nodes, energy resources, attack, and noise.

Interplanetary Internet (IPN)

The Interplanetary Internet (IPN) is a conceived computer network in space, consisting of a set of network nodes which can communicate with each other.  Communication would be greatly delayed by the great interplanetary distances, so the IPN needs a new set of protocols and technology that are tolerant to large delays and errors. While the Internet as we know it tends to be a busy network of networks with high traffic, negligible delay and errors, and a wired backbone, the Interplanetary Internet is a store-and-forward network of internets that is often disconnected, has a wireless backbone fraught with error-prone links and delays ranging to tens of minutes, even hours, even when there is a connection.

Concurrently with (but separate from) the MANET activities, DARPA had funded NASA, MITRE and others to develop a proposal for the Interplanetary Internet (IPN). Internet pioneer Vint Cerf and others developed the initial IPN architecture, relating to the necessity of networking technologies that can cope with the significant delays and packet corruption of deep-space communications. In 2002, Kevin Fall started to adapt some of the ideas in the IPN design to terrestrial networks and coined the term delay-tolerant networking and the DTN acronym. A paper published in 2003 SIGCOMM conference gives the motivation for DTNs. The mid-2000s brought about increased interest in DTNs, including a growing number of academic conferences on delay and disruption-tolerant networking, and growing interest in combining work from sensor networks and MANETs with the work on DTN. This field saw many optimizations on classic ad-hoc and delay-tolerant networking algorithms and began to examine factors such as security, reliability, verifiability, and other areas of research that are well understood in traditional computer networking.

HAL-9000

What’sWho is NEXT? = IPN

Do not be in the least surprised when they get the Interplanetary Internet up, they name it HAL.

Oh yeah, in the meantime, don’t forget to look up.

*[This article is in no way intended to be a comprehensive discussion of the matters involved. This is only a Teaser, and perhaps a starting point for those interested in the subject of tomorrow.]

After discussions with Ed Hare, W1RFI at the ARRL Lab here are some
facts regarding this situation:

1.  The ARRL Lab BER testing was dependent upon some aging hardware that used DOS software. This hardware/software has been retired.

2. The Lab has NOT received any “pressure” from manufacturers
regarding this testing.

3. The Lab is looking into ways to reintegrate BER testing back into
their testing when time and resources allow.

For now I’d exercise great caution in purchasing a new rig for 9600
packet that doesn’t have both TXD and BER test data available.

WA4ZKO

© WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2011. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content.

The following are my suggestions for KYPN packet node/application naming standards:

1.  Node/application aliases should be restricted to 6 alphanumeric digits.

2.  NetRom node aliases should start with the 2-digit state code (KY, IN, OH, WV and so on) followed by a 3 or 4 character abbreviation for the location which can be an airport code or something that makes sense locally. The main thing is that it starts with the 2 digit state code.

3. KYPN packet BBS systems should use the -1 SID.  (eg  CALLSIGN-1)

4. KYPN nodes will normally use a SID of -4 or -7.

If you choose to use an “area” suffix (NKY, CKY, EKY, etc) for the suffix, then you should be prepared and capable of serving that area with a reasonable level of base-to-base coverage via it’s primary user port.

Trust me, it is much easier to adopt standards in the beginning than to go back and rename a bunch of things later on.

WA4ZKO

© WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2010. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content.

Here are some of the quotes in the article that brought back some vivid memories of the frequent trips I made to RadioShack as a tinkering youth:

Some people say RadioShack is just a store  … But to me it was an idea — a learning and resource center that really shaped people’s lives.

I remember countless days spent working on an electronics project, where I made many trips to the local Radio Shack for components.  It was exciting to learn about photocells, electromagnets, diodes, transistors, etc.  Sometimes these projects would last weeks on end.  I was always taking things apart (and in many cases never got them put back together!) much to my parents’ chagrin.  I recall only very few of my peers frequenting the store… so it is nice to see this article put a face on the real impact RadioShack had on people’s lives.  I never really realized the magnitude RadioShack had on others until I read this article.  I went on to study Electrical Engineering and Computer Science, and in a real way, my tinkering has turned into a marvelous career.

He also pored over the RadioShack catalog the day it arrived, studying up on what was then cutting-edge technology — reel-to-reel tape decks, fax machines — and the pages and pages of arcane electronic components.

Wow, this hit the nail on the head.  I spent so many hours dissecting all the new components in every Radio Shack catalog.  There was so much cool stuff to build!  (Ready for some nostalgia?  Check out 67 years of old RadioShack Catalogs here).  Of course, there were Heathkit catalogs as well…

Oh, how I lusted over the GC-1000 Most Accurate Clock (I finally purchased a used one on eBay a few months ago).

The books were written exclusively for RadioShack and were offered in stores for a few dollars each. They were essentially giveaways; the real money came from all the diodes, transistors, and tools that hobbyists needed to build the circuits he diagrammed.

Remember the Engineer’s Mini-Notebooks?  These were always filled with great projects, and circuits, that could be used to build a multitude of gear.  I was always interested in radio, and built all kinds of receivers and transmitters.  One of the neatest projects I made was a digital voice synthesizer, that took its input from and 300 baud serial line.  Now that was cool!

Over the years, I got interested in Ham Radio… especially packet radio.  There was just something so neat about sending digital messages to others across the country with a TeleVideo 925 dumb terminal, a MFJ packet radio, a Yaesu 2m ham radio, and a homemade J-pole antenna on the roof.  Of course, many of the parts that made it work were from RadioShack.

I leave you with one last quote from some reader correspondence printed in the July issue:

RadioShack “was my tech school as kid”

That about sums it up.   Except for the fact that my folks now think this video clip “The Knack” pretty much sums up my childhood.

Update 7/14/10 – I came across this similar retrospective, Raised, in part, by Radio Shack.  Good reading.

The modules are the X-Bee 900 Pro‘s. We had the baud rate ramped up to 115.2 but decided after some calculations to drop back to 38400. No help. So I dug through the manual again. Likely, we should be using API mode but for the moment we kept it simple and just left them in the default broadcast configuration.

The downside of this mode is that the modules are not really communicating point to point even though only two are in the system. So they duplicate broadcast messages to help assure the messages get to everyone in the message. The default duplication is set to 3. I lowered it to 1. If we drop a message here or there, it shouldn’t really effect the performance of the system significantly.

Also, the vehicle is really and end-point, not a router and will never be for this configuration so I changed it to be an end-point not a router. However, that required a firmware upgrade which was seamless using the X-CTU software other than it defaulting the module back to 9600 baud. Honestly both could be set as endpoints I think but I didn’t test that configuration since I was in a rush to get the comm working.

I also tried lowering the packet ratio to zero prior to the other changes to immediately transmit characters rather than bundling messages. It proved too not help but might be a good option at some point. I also lowered the XOFF buffer maximum to 128 characters down from the default of 319 since none of our message strings exceed that length.

If we were going to rely on the radios for good communication, the API interface is the way to go not the transparent default. The changes cleared up the congestion but I made mass changes so cannot specify precisely which one did the trick. If you run into similar issues, I can check the exact configuration and setting changes.

In the end, one more hurdle cleared.

2.  I know a lot of the old hats like to use the 44.x.x.x AMPRNet IP’s on the RF side of packet radio even when there’s really no need for it.  Often TCP/IP is deployed on RF just so folks can say they are doing TCP/IP over RF. Often done without a good reason to be adding that additional payload and administrative overhead to the RF side of things. No I’m not saying TCP/IP doesn’t have any place on RF, but often it’s deployed everywhere on RF when there is no real need for it.

3.  Many of the state/region subnets taken from 44.x.x.x AMPRNet address space are mismanaged or basically in a free for all status.

4.  I’ve personally dealt with some AMPRNet coordinators that clearly had no clue about TCP/IP fundamentals like subnets and so forth. This has likely  “scared” off more than a few talented TCP/IP savvy folks to not even bother with 44 Net in their areas.

5.  I don’t think there is any frequent verification of the ampr.org address space to verify what is actually on the air/net  and where it is.

6.  This will raise the hackles of many, but I just don’t see much need for AMPRNet (44 Net) anymore. In the 1990′s it was a viable idea, but not  nearly so much today. This is due to a variety of reasons:

a.  Security mandated changes to the routing infrastructure of the public internet makes widespread and straightforward deployment of 44.x.x.x addresses challenging at best.

b.  With the proliferation of cheap (relatively) broadband access in most areas, the rules and options for internet access have changed drastically since the 1990′s. Stop and think about this. It’s amazing how far consumer internet access has come in a decade or so.

c.  In most areas getting a static “public” IP address on a consumer broadband connection is no big deal anymore. All three providers in my area offer it for just a few bucks ($5-6) more a month.

d.  For those that can’t get a static IP address, Dynamic DNS (DDNS) services are available for costs ranging from free to a few bucks a year.

e.  Powerful DNS systems are available to us now. For costs ranging from $15-$50 a year you can have access to first class, highly distributed, fault tolerant DNS services that were only a wild dream a decade ago. Many of these come with DDNS as part of the package, sweet!

f.  In many cases (if not most) there is little reason why TCP/IP packet networks can’t be built around the 10.0.0.0 /8, 172.16.0.0 /12, and 192.168.0.0 /16 private IP netblocks. Public internet access from these address spaces can be done via NAT and well controlled by local folks that probably know best regarding what their particular area’s needs are. The fact that these 3 private netblocks are not public internet routable may often be more beneficial than restrictive for what hams are doing. That said, I really don’t suggest building ham radio IP networks for EMCOMM anymore. If it’s only tinkering and non-EMCOMM use….then go for it.

g.  Private VPN’s could be used for cases where more “open” links between gateways are needed. Yeah encryption adds some overhead to things, but I don’t think you’ll find too many cases of where RF networks are going to be faster than the slowest broadband based VPN link will be! The encrypted tunnels will also add some security to protocols that normally don’t have much security to them. For example, think POP3/SMTP/Telnet transactions where passwords are sent in the clear.

UPDATE 01/14/2010:  SMTP-AUTH for above. POP & Telnet security issues should be obvious.

h.  The 10.0.0.0 /8 netblock is just as big as 44.0.0.0 /8 is, both are Class A netblocks.  Yeah, you still would want some rhyme, reason, controls, and tracking of what is being used where.

i.  The evolution of the “bad stuff” on the public internet shows no sign of slowing down. DDOS, aggressive netblock scans, and other evil/silliness will only continue to plague any public internet facing 44 Net gateway like mirrorshades.

j.  mirrorshades.ampr.org is located at the University of California San Diego campus (UCSD). With the uncertain and worsening fiscal situation that California faces now, deep state budget cuts have occurred and more cuts are inevitable. Since mirrorshades.ampr.org has had a free ride for many years now, it’s reasonable to have some concern over it’s future out there in a state university.

k.  Hopefully nothing ever does, but what happens if something unexpected happens with Brian Kantor? As the N1URO situation should teach us, such key wide area impacting infrastructure ran/provided by a single person creates a big risk of SPF (Single Point of Failure).

So outside of pure experimentation, I just can’t see much advantage to using 44 Net AMPRnet addresses in today’s world of packet radio. All you’re doing is adding another layer of potential failure and administration on top of an existing internet connection. Why do it twice? But that’s just my opinion.

WA4ZKO

© WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2009. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content.

It’s an AP story, otherwise I’d normally be just a tad uneasy about seeing a story about Kentucky in the New York Times (wink).

As you read the story, remember these problems were in fairly highly populated urban/suburban areas of the state. We’re not talking some very rural, financially challenged, and sparsely populated county!

http://www.nytimes.com/2009/08/02/us/02kentucky.html

Some interesting parts of the story:

“During the ice storm, cellphone service throughout the area was disrupted, sometimes for days at a time. Landlines were also affected, and communication problems were cited by multiple emergency response agencies as the biggest issue they faced.”

and

“Having amateur radio operators throughout the county would give real-time, on-the-scene feedback to emergency managers and to officials with the National Weather Service office in Paducah, Mr. Atherton said.“ There are so many circumstances where they could be our only contact with the outside world,” he said.”

My take (FWIW)?

Hey at least it looks like parts of Kentucky are learning some hard lessons about how fragile local cell phone availability can be during bad times. Let’s face it, we’ve had several “events” in the last few years that should serve as ‘wake up’ calls for us to rethink EMCOMM in Kentucky. Unfortunately we Kentucky hams don’t seem to be learning enough from these events.

I’m not too fond of the “dying” part of the story, but in a way it’s sadly true for many facets of the hobby today. Even sadder since it doesn’t have to be so.

A lot of our older “slower” techniques of communicating and moving data around may not compare to the new high speed stuff the average citizen takes for granted today, but they often prove themselves much more resilient when the going gets tough.

I love tech progress as much as the next geek. The problem is that a lot of these newer “high speed” technologies work okay during normal times,  yet repeatedly turn out to be extremely fragile during “bad times.” Don’t get me wrong, I’m not dissing them  for what they are, but we just need to recognize how fragile they can be. We should not become too dependent upon them for EMCOMM without a viable Plan B on stand-by.

As I like to say, a lot of this “latest and greatest” stuff is often just the “latest” no matter how much money and effort the marketing folks behind it use to convince you it’s a must have. No wonder why the average household credit card debt was around $10K the last I checked, probably even higher now?

Back to ham radio, I often joke that ham radio is about 10 years behind the rest of the communications world anymore. A communications world that we used to lead in many ways. Then I add in that ham radio in Kentucky is an additional 10-20 years behind, chuckle. If those words “sting” then maybe it would be healthy for us to ask why and be honest with ourselves? Getting past “denial” is the first step to recovery.

In many portions of Kentucky, KY ARES really needs to step up and lead on this stuff. Using voice/cw nets to manually move all EMCOMM and NTS information around (often very slowly) leaves a lot to be desired, especially with many nets struggling with activity levels.  As one NTS guy told me, it’s embarrassing to routinely be delivering messages that are weeks old. This just isn’t going to cut it today unless you’re happy with “slightly better than nothing” attitudes and results. Trust me they may not say it to your face, but this stuff doesn’t impress the EMA folks that much either. They work in a world of near instant email and messaging on their belts.

I’m not dissing the fine efforts of the NTS guys/gals hanging in there, but there clearly is a lot room for improvement. Using packet to automate a lot of the NTS traffic flows would be a great start.  In EMCOMM it’s high time to think beyond just voice traffic, data needs to be embraced also.

So I think it’s time for many in our KY ARES leadership to embrace packet radio. Packet BBS’s and WinLink may seem to be “old tech” but they remain a much better way to distribute NTS traffic and local/semi-local messages (think shelter lists, latest news) over a small or large area.  A few real (non-TNC based) packet BBS’s located in key EOC’s around the state, available on RF and Telnet, linked via the internet with a decent RF backbone as backup would be a great start.

In building out our packet networks, let us learn from the past and not try to do everything at 1200 baud and on 2 meters!  We’ve got much better bands for data, let’s use them! 9600 baud packet is much easier to do today than it was back in the 90’s so there’s no excuse to not embrace it.  Plus putting your very active data channels on the same band (2m) that you will likely be running most of your EMCOMM voice communications on (2m) = very bad idea. If your served agencies also use VHF-Hi, you’re really asking for trouble in a cramped EOC/MCU environment. It’s not like we’re spectrum limited, so let’s stop acting like we only have HF and 2 meters, grin.

It’s also time to finish up the build out of the APRS digi network across  Kentucky. We’ve got a lot of coverage for sure, but there remains a lot of mobile coverage holes out there. I hear a lot of the Nay Sayers arguing that a statewide packet network can’t be done? I say Bravo Sierra! In many ways we’ve already nearly built one statewide packet network…its’ called APRS!

APRS is infinitely usable for EMCOMM resource tracking needs and short (think like twitter) text messaging. Folks APRS is a flat out no-brainer for so many of your EMCOMM resource tracking needs. Get some portable APRS  trackers, try them out for resource tracking, and introduce yourselves to your local APRS digi sysops. The newer “S-Class” digipeaters will support 7 hop KY only paths (KY7-7) so there are a lot of possibilities there just waiting to be tapped into.

As several have commented, it says a lot when our own state EOC doesn’t have a presence on packet or at least APRS.  Read the above sentence again, then think about it. Why the heck not? Why not lead by example? The state EOC would be a great spot for an APRS digipeater and give us better coverage in our own capital city for a refreshing change! It’s the no-brainer location for a central packet BBS system. They need help? Then just ask around for help, many of us would be glad to help them build things out.

All kinds of potential out there, we just have to embrace it with reasonable expectations. Many in KY ARES leadership dearly need to step outside of their comfort zones and draw upon the diverse talent pool we have among the Kentucky ham population. Don’t get me wrong, I don’t want this to be all about bashing KY ARES.  There are some local ARES groups in Kentucky doing some darn good work here and there, but it’s clear we have a long ways to go when you look at the state as a whole.

So it’s time for Kentucky hams to deliver more truly useful EMCOMM capabilities to our served agencies and communities, BOTH VOICE and DATA. Yeah it’s going to take some hard work, money, some adventurous folks stepping outside of their comfort zones, and a lot of time.  Across the state so much key ham radio EMCOMM needs/infrastructure have been neglected (or flat ignored) for well over a decade+, so we’re not going to fix things overnight. The good news is we don’t have to do it all overnight, just have a plan and slowly work towards it.

WA4ZKO

© WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2008-2013. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content.

As you read the story remember that these problems were in fairly highly populated urban/suburban areas of the state. We are not talking about some very rural, financially challenged, and sparsely populated Kentucky county!

http://www.nytimes.com/2009/08/02/us/02kentucky.html

Some interesting parts of the story:

“During the ice storm, cellphone service throughout the area was disrupted, sometimes for days at a time. Landlines were also affected, and communication problems were cited by multiple emergency response agencies as the biggest issue they faced.”

and

“Having amateur radio operators throughout the county would give real-time, on-the-scene feedback to emergency managers and to officials with the National Weather Service office in Paducah, Mr. Atherton said.“ There are so many circumstances where they could be our only contact with the outside world,” he said.”

My take (FWIW)?  Pardon me while I get up on a amateur radio EMCOMM soapbox for a bit….

Hey at least it looks like parts of Kentucky are learning some hard lessons about how fragile local cell phone and internet availability can be during bad times. Let’s face it, we’ve had several “events” in the last few years that should serve as ‘wake up’ calls for us to rethink EMCOMM in Kentucky. Unfortunately we Kentucky hams don’t seem to be learning enough from these events.

I’m not too fond of the “dying” part of the story, but in a way it’s sadly true for most facets of the hobby today. Even sadder since it doesn’t have to be so.

A lot of our older “slower” techniques of communicating and moving data around may not compare to the new high speed digital stuff, but they often prove themselves much more resilient when the going gets tough. I love progress as much as the next geek, but a lot of these new technologies work okay during normal times, yet they turn out to be extremely fragile during “bad times.” Don’t get me wrong, not dissing them or saying we should completely abandon these wonderful technologies. We just need to recognize how fragile they are and not become too dependent upon them for EMCOMM.

As I like to say, a lot of this “latest and greatest” stuff is often just the “latest and far from the greatest.”
Back to ham radio….

To put things bluntly? Today the EMCOMM world is increasingly ICS/NIMS oriented and many in ARES & NTS need to come to grips with that fact. Unfortunately the things I hear some of the KY ARES and NTS folks discussing tells me they have not learned much from the past.

I often joke that in far too many areas ham radio is about 10 years behind the rest of the communications world. Then I add in that ham radio in Kentucky is an additional 10 years behind, chuckle. If those words sting then maybe it would be healthy for us to ask why and be honest with ourselves? Getting past “denial” is the first step to recovery.

In many areas of Kentucky, ARES really needs to modernize beyond voice, CW, and maybe a PSK31 net. Not saying those modes serve no purpose, but using them to move traffic around just isn’t going to cut it during a major event/disaster. Voice & CW nets can overload too easily. Experience has also taught us that voice/CW net message accuracy is often a problem that only gets worse with operator fatigue during high traffic volume and/or an extended event.

PSK31 for EMCOMM? Sorry, but PSK31 alone is simply unsuitable for passing traffic since it has no error detection or correction. PSK31 is fine for casual use, but it is NOT suitable for critical EMCOMM needs. We have much better modes for EMCOMM messaging like VHF/UHF packet, HF robust packet, MT63, and Olivia. When using MT63 or Olivia you will still need to add a “CRC” to messages to ensure accurate delivery (eg Fldigi and Flwrap).

I also see some training nets using modes/tools that are inappropriate for the task they are supposedly trying to train for. To do so is counterproductive on many levels. One of the fundamentals of an effective training net is to use the very modes/tools that you will be using during an actual event/disaster and in the manner they will be used during same.

While you will probably need HF NBEMS to meet regional/state-to-state needs, you will also need to consider VHF/UHF packet radio for local traffic. Remember that typically most traffic is local in nature. VHF/UHF packet is faster and often much better suited for handling heavy local traffic flows. In many cases a lot of the VHF/UHF packet radio message flows can be automated (think Outpost polling a local mailbox) versus trying to use the “manual” Peer-to-Peer (P2P) NBEMS techniques for local flows. Also do not discount the benefits of packet’s store-n-forward and error free capabilities when used with  EMCOMM oriented packet software like Outpost.

NTS for modern EMCOMM? I would not say that NTS has no place in today’s EMCOMM world, but as stated above, it is an increasingly ICS/NIMS world. Unfortunately many in NTS leadership roles seem stuck in a “status quo” and self-justification by raw numbers mode versus recognizing the need to adapt and modernize to the times. Far too often the attitude I hear or read is that the served agency and/or ARES needs to adapt to NTS versus the other way around. Sorry folks but it is an ICS/NIMS world and NTS can adapt to that reality or continue to fade away. I have a lot of respect for what those NTS guys/gals did in the past, but today’s EMCOMM world is a very different beast.

Whatever mode you use, always ask yourself how will your approach deal with the need to move hundreds of messages a day? How will the operators hold up? Can you keep enough rested operators available to staff the stations for manual P2P modes if the communications emergency/need lasts for more than a day or two? Can you move traffic around the clock? Is the software or approach going to get too cumbersome or error prone when you have dozens to hundreds of messages to send out and thousands more to keep around readily available for reference, readable, copy/printable, etc?

IMHO it is time for KY hams to improve our ability to deliver more useful backup communications to our served agencies and that often means adding appropriate data/digital tools to the mix. As several have commented, it says a lot when our own state EOC doesn’t have a presence on packet and/or APRS. Read the above again, then think about it. Why the heck not? The state EOC would be a great spot for an APRS digipeater and give us better APRS coverage in our own capital city. Why not a simple packet terminal/maildrop too?

Let me step down off this soapbox before it gets any longer. Agree or not, hopefully I have left you with some food for thought.

WA4ZKO