OFDM is permitted on 70 cm because it is an "Image Emission".

[From http://www.ntms.org/802.11/ARRL Board of Directors 2005.doc ]

OFDM Can Be Classified as an Image Emission

John Stevensen, KD6OZH in 2005 began development of a HSMM Orthogonal Frequency Division Multiplexing (OFDM) Modem that will allow Radio Amateurs to have all –mode voice, text, data, and video (i.e., multimedia) high-speed digital communications on the VHF, UHF and SHF bands. Alpha testing of the OFDM modem was done in Texas using an ATV channel in the 70cm band operating in a digital “image mode” coined Amateur Digital Video (ADV).

In a January 2005 report to the ARRL board of directors, the HSMM Technology Task Force submitted the following concept as basis for such a 70 cm OFDM modem capable of Amateur Digital Video.

The 70 cm band is ideal for HSMM and, using the following interpretation of FCC regulations, we should be able to use OFDM modems with an occupied bandwidth up to 9 MHz (at least) on the 70 cm band. HSMM would be classified as an image emission type. This interpretation also allows 6 kHz (or more) bandwidth OFDM modems on the MF and HF amateur bands.

In 47 CFR 97.315 the emission type "image" is defined as including "emissions having B as the first symbol; 7, 8 or 9 as the second symbol; W as the third symbol".

In 47 CFR 2.201 (c) (2) a first symbol of B defines the type of modulation of the main carrier as an "emission in which the main carrier is amplitude-modulated (including cases where sub-carriers are angle-modulated) with independent sidebands". The OFDM modem fits this description as it has a central carrier with multiple subcarriers in the upper and lower sidebands that are angle (phase) modulated. In 47 CFR 2.201 (d) (5) a second symbol of 7 indicates that the nature of the signals modulating the main carrier are "two or more channels containing quantitized or digital information". 47 CFR 2.201 (d)(2) and (3) indicate that time-division multiplex is excluded for a single channel so the time division multiplex inherent in HSMM communications creates two or more channels. In 47 CFR 2.201 (e) (8) a third symbol of W indicates that the type of information to be transmitted is "a combination of the above" and that includes (4) "facsimile", (5) "data transmission, telemetry and telecommand", (6) "telephony" and (7) "television". HSMM fits this definition as it includes data, speech and image components.

In 47 CFR 97.305 "a station may transmit the following emission types on the frequencies indicated, as authorized to the control operator, subject to the standards specified in 97.307(f) of this part". The following table includes the "image" type for all bands and references 47 CFR 97.307 (f) (2) for the 160 m through 1.25 m bands but does not reference it for the 70 cm through 1 mm bands.

This is the only restriction on the image emission type and states that "the total bandwidth of an independent sideband emission (having B as the first symbol), or a multiplexed image and phone emission, shall not exceed that of a communications quality A3E emission". I can't find a definition for "communications quality" but it seems to be taken as 3 kHz on the MF and HF bands.

Thus OFDM modems using 6 kHz or less should be authorized on 225 MHz and below and OFDM modems with no bandwidth restriction on 420 MHz and above. If the emission must fit within the bandwidth used by existing analog image communication devices, that bandwidth would be 9 MHz for DSM AM ATV with a 4.5 MHz sound subcarrier.

Hi all, looks like I'll be checking in on this forum along with following the Western KY folks on Facebook.

Here in Martin (Weakley County) TN, I have six BHv1 nodes set up.  I have two "robo-cams" that can go online as advertised services so remote users can control pan and tilt, and the gateway "service" node has a NAS with two 32G USB drives attached for filesharing.  The gateway also has a RasPBX with 3-digit internal dialing and a Google Voice trunk for PSTN access when online.  Outside inbound callers reach an auto-attendant which offers single-digit access to a particular node, each node has voicemail that can take a message when busy or unattended/offline.  When no internet connection to the gateway is available the PBX will act as a simple intercom for the phones at each node.

Antenna-wise, I currently have two 8dBi and three 12dBi mast-mount omnis, along with a 7dBi mag mount for a "mobile rover".  For a straight-line hop deployment, I have four 14dBi "backfire" yagis and four 24dBi parabolics.  Of course the antennas can be mixed & matched as the incident requires.

Power is through buck converters so theoretically I can put 8-24VDC into the PowerPole inputs and get a stable 12V or 5V out to the hardware.  I still keep the AC wall-warts labeled and in the bag if needed.

Although everything has been tested inside using the stock ducks, nothing is outside and "live" at this time.  I'm in a rural area where the trees are taller than the buildings and I haven't found anyone yet that's willing to offer 300' tower real estate for a $20 router. 

Field-expedient masts and coax will be my final purchases, got to get through the holidays first.

73!

Anyone who understands mesh radios can connect to our networks. As radio amateurs we are not allowed to use cryptographic means to secure the OLSR protocol which is the only method I am aware of available.

The static IP is placed on the Windows WIFI interface that you intend to use.

I used 10.x.y.z where x.y.z are the decimal equivalents of the 3 least significant hex bytes of the MAC address to make an address to use.

I connect the interface to BroadbandHamnet-v1 first, then start OLSR Switch (it should start with Default.olsr). I look for the interface address in the OLSR Switch Interface list and check it. Then I hit save and start. I switch to the Nodes tab and in a few seconds the members on my mesh appear.

I can then ping or connect using 10.x.x.x addresses with relevant apps like IRC, Mumble, web browser, ssh, etc.

DNS does NOT work. OLSR Switch does not have the DNS Plugin. You might be able to use your 

hosts file:

%SystemRoot%\system32\drivers\etc\hosts


to record DNS names on your mesh as a hack to fix this (I havent bothered).

IPV6 does NOT work. Version 5.6-r3 does not have IPV6.

But IPV4 using numerical addresses works just fine.

73;

Bob KV4PC

Ok I will be try to setup my laptop and Andriod to connect with my WRT54G with HSMM firmware 1.0. It will be nice have to this. Because not all local ham radio operators must buy and use WRT54. We can setup local Mesh Nodes with WRT54 to cover local area use Hamnet network by hamradio operators. One problem for me is that anybody who install on own hardware olsr can connect to our network ?

73 Wladek sp2ong

Yes. I posted about this a while back.

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-4-applications/topic-614-olsr-switch-on-windows-works-to-connect-directly-to-the-mesh.html

Works OK on windows except for DNS and IPV6. Im using the last version of OLSR-Switch that was posted as a binary by the olsr.org folk. I havent been able to successfully build the latest version which fixes IPV6.

I havent gotten it to work on Android because my devices are Motorola which has two issues - insufficient power available at the USB port (could try a powered hub and USB OTG adaptor), and rooting is required to activate ad-hoc mode. Some android devices dont have these issues.

73;

Bob KV4PC

Hi,

Is it possible use laptop + wifi card or Tablet-Andriod with installed OLSR software to connect HSMM-Mesh local network ?

73 Waldek sp2ong

I don't think the data rate loss will be from antenna switching, it comes from the fact that your node is the relay between two other nodes.  It has to receive from one node, then transmit to the other node.   Antenna switching shouldn't matter much.

I would expect about 50% data rate when forwarding traffic from one node to another vs. originating or terminating the data.

You're not the first one to report that removing the power overnight or for a few days unbricked a router.  It's worth a try.

I bought a JTAG setup a while back, to use on 3 bricked WRT54GS I had, and after they had been sitting on the shelf for several (5-6) months, they were mysteriously Un-Bricked..... I was able to go ahead and flash them to my surprise, and they now work great.

Never had to go the JTAG route...

Reset password with safe mode.

Installing software with tftp.  (Look near the bottom.)  It works better from a linux machine, but can be done with a Windoze machine.

When done, stick a label on the router and write the password on the label. 

A very quick way of checking that the tunnel is OK is by pinging the remote end pointopoint IP from your own node in CLI mode.

Ie, login to your node using SSH and issue the command 'ping x.x.x.x' without quotes and the x.x.x.x representing the remote end pointopoint IP.

Hi Ron, here in Barrie we also started off using v1.0.0 firmware for GRE tunneling. And yes, if the tunnel comes up properly you should see the node names from the far end of the tunnel on your Mesh Status screen. Note that the "status: up" for tun1 on the OLSR screen doesn't mean that the tunnel is "operational". It only means that the tunnel (tun1) was configured properly in that node and the tunnel is capable of coming up. If the nodes at both ends of the tunnel show "status: up" but no nodes are displayed on the Mesh Status screen after 5 minutes; check your DynDNS account to see what was entered by the scripts when they were executed. You can enter an incorrect IP in DynDNS for each node and then reboot it, the IP should be corrected by the scripts when they are run.

Some other problems we experienced here in Barrie:

1. The octal (chmod value) had not been set properly for the different script files. 
2. The internet router had not been configured properly to pass port 1723 and to allow PPTP protocol 47 traffic. 
3. Errors in properly entering the 2 new lines needed in crontabs/root. 
4. Didn't reverse the two tunnel IP's in the ifconfig lines at the far end of the tunnel. 

Hope this info helps. 73

Really nice to see that this function is spreading.

From being a very local solution between two locations in south of SM to be an international success :)

This idea really initiated between me and a fellow ham and as we had no RF path I started investigating the possibilities to set up some form of tunneling between us as a temporarily solution :)

Hi,

Yes, that would be a possible solution, however I would like to see several gateways, at least one in each continent, that can share the hostsdatabase on a daily basis.

Also we would need to make sure we can squeeze the RIP function into the WRTs which is easier said than done.

I´m not really sure that this is within the scope of the original developers of HSMM/BBHN as they foresaw an independent network solution (this has somewhat been put aside when we started tunneling traffic), but it is an interesting approach nevertheless.

To make a long history as short as possible, the GRE development for HSMM was initiated by me and a fellow HAM in a neighboring city since we did not have any RF path between us.

So this GRE development was really only going to be a temporarily solution until we could make sure we had enough density of nodes to be able to reach eachother with RF.

Since then some other needs arose and now it seems like this is a very neat solution for bringing really remote locations together, such as city to city mesh networks.