It starts off pointing how important Magazines and people like Wayne who were on the ball with publishing new ideas and technologies was to the dissemination of information and advancement of technology. Wayne often was ahead of the curve, which I suspect is not easy to do in the publishing business. I have noticed at least with QST, it takes a year or better for articles to be published on happening topics. (I figure next year I will read something about the Raspberry Pi and ham radio in QST)
"Before there was a PC revolution, before the days of PC Magazine and MacWorld, before COMDEX, there was Wayne Green."
Now days that role is somewhat diminished, with the internet an all. But some people won't go research things on their own, so shoving the ideas in front of them monthly is still important to keeping things active and moving forward.
David Sumner, K1ZZ on the ARRL website notes a an important technique to keeping things lively in the hobby:
In the early days of packet radio he (Wayne Green) gave me some good advice as to how the ARRL should promote the new technology: ‘Talk about it as if everybody’s doing it, and eventually they will be.’”
A while back a took on a big project in hopes 73 magazine would live on. Wayne did give the okay to place his publications in the public domain. So he maybe be gone, his his legacy lives on.
His last three missions toward the end where to change the world on health and oil and education. In his honor it would seem logical to share his Secret Guide to Health and maybe track down the Cold Fusion Magazines.
I think a local New Hampshire paper coined him in the 1980's as the "World's Most Interesting Man," and I have to say that fits him well. I look forward to reading the Wayne Green biography when it comes along. 73 OM!
As the focus of my blog has been more of a modern ham radio theme, it seems appropriate to share this video about ham radio in the future. This is a must-view by all as it provides us timely perspective on the future challenges.
It's from a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict and speculate what ham radio will be like in 25 years.
The first part is more a regulatory look by Chris Imlay W3KD, where as the
second part is a bit more of a technical/operational look by Ed Hare, W1RFI.
Ed Hare predicting the continued use of Amateur Radio MESH networks, and
Software Defined Radio all entangled with the internet.
~57:00 "Software defined radio super stations perhaps accessible by the internet put at
locations where you can put up antennas (future antennas restrictions).
This could allow licensed amateurs to log on to that transmitter, that's generating
a broad signal across the entire band, filling each little channel within that
band with an different actual amateur signal. So that that all those hams
have an easy way to operating from a good location, even if they are operating
from an apartment....
Amateur radio will have developed a nationwide amateur radio digital back bone,
using a broad range of frequencies and technologies. I think its going to
grow ad-hoc. Planning is all good, but if you look at the same way the
radio relay network was developed in the spark days, we are going to see that
same type of approach. That same type of pioneering spirit. Ham equipment
will be fully integrated with the internet....
Analog repeaters will be real legacy technology, replaced by digital repeaters
that will allow multiple users on the same spectrum channel. Right now the
repeater paradigm is such that we are limited by the maximum number of possible
users. Where we have a lot of repeater that are used, but might spend 50%,
90% or more of their time not being used. And in the meantime, nobody else
can use that pair. If we can imagine ways of multiplexing all of these
repeaters together so that anytime someone wanted to get on the two meter band
on a quote "repeater", a virtual repeater could be created out the
multiple repeaters that are there. Kind of a trunking system on steroids."
Related:
At the September 2013 DCC, Heikki Hannikainen, OH7LZB, presented on Friday
morning a talk about authenticating
amateur radio services on the Internet.
Some of the interesting sites allow you transmit RF, directly or indirectly.
Such as IRLP, EchoLink, Allstar APRS-IS, remotehamradio.com etc. And there is more potential
for that. I.e. text messages for DMR, APRS, SDR, and remotely operated
stations.
Presently each such service has a different manual authentication method.
The ARRL Log of the World Certificate conforms to the X.509 standard used all
over the internet. It may be installed on web browser, and used to
log into web services. Any third party can technically validate that the
web user connecting really has an ARRL LoTW certificate. Any one implementing
this method on their website to restrict access to hams, does not get access to
the users private key. This is the same crypto used by banks and the
military. The ARRL doesn't need to do any addition work to make this
happen. Websites implementing this do not need to query the ARRL anything
about the user. No single point of failure.
There are plenty of developers who would be happy to create new web services
for hams. They just don't have the time or motivation to go though all the
license papers to manually authenticate them.
Add the LoTW CALLSIGN.P12 file to your browser like so. Options -> Advanced -> Certificates in FireFox
In the future websites seeking authentication will show this.
Success!
If you've ever logged into a third-party web site with your
Google, Facebook, or Twitter account by granting the app permission to that
respective account, then whether you knew it or not, you've used OAuth (an
open standard to authorization.), and it's a great way to dole out
permissions.
Ham Radio needs something simple like this. It would be
great if it could be implemented at the regulatory level (FCC), where your FCC
ULS login could be used to log in to other ham radio websites, that seek to
authenticate you as a ham. Fat chance of that, so the next best would
probably be the ARRL login.
When you are ready to start messing with software defined radio, look into HackRF (capable of transmission or reception of radio signals from 10 MHz to 6 GHz): https://github.com/mossmann/hackrf/wiki
Think; two cheap Raspberry Pi micro computers. One with a speaker mic. Stream with speakfreely, over a VPN, and use the hamlib php web for remote frequency control.
Many are familiar with hamradio deluxe for local station control. It does have remote server and client functionality. What it lacks is a way to transport the audio. You have have to use other software such as Skype to transport the audio.
One of perhaps the most elegant ways to operate remotely is with a fairly new product (2010) from Remote Rig. The RRC-1258MkII consists of two devices; one placed at the host, and the other at the client. They handle remote control and audio. They require no computer either (after setup), just a compatible radio with remove-able head. The head connects to one device, the RF guts to the other, and just ethernet between them.
It's not the cheapest solution, but perhaps one day radio manufactures will adopt this idea of a an ethernet transport cable between the head and radio deck. Till then, ham clubs could invest in one. Many club stations see little use, and this way a number of members (some not able to afford a nice station or able to put up antennas) would benefit.
I have to say however the remote rig guys figured out the TTL communication between the head and deck and managed to encapsulate that in standard TCP/IP is truly awesome.
It even works with radios that don't have direct CIV/CAT control, like the FT-8800, FT-7800, so you don't need to own a really expensive radio to be able to use it remotely.
Perhaps in the future there will be more radios that are remotely tunable (CAT/CIV). It would be awesome if the cheaper handhelds like Baofeng, would support this. Till then, the Kenwood F6A HT works great with Hamlib.
It would be nice if future base/mobiles like the Yeasu ones would just have an ethernet jack on them.
Yeah I know, but it's nice to dream!
Dubus is a quarterly magazine for technology, construction, DX and propagation on VHF/UHF and Microwave bands. It is edited in English and German languages by an international group of hams, printed in Germany.
The problem is for the most part, the microwave bands sit idle, except for a few contests a year. Dubus is mostly what you'd expect, hams building microwave stations for the quest of a contact record.
I have never been that type, to each their own.
I am more interested in building infrastructure or something a number of hams can use. Which is why I like data networks, as I feel it can support a variety of applications while keeping some constant use of the frequencies.
Dubus 4/2006 - Microwave Japan
Seiji Fukushima, PH.D, JH6RTO
High-speed IP connection on 5760 MHz
by Hiroyuki, JH1UGF and Tsugno, JN1AYV
We report a 63 km high-speed IP connection on 5760MHz using ICOM ID-1's and modified transverters, UTV5600BIIP. The throughput was measured as about 100 kb/s at the application of layer .
Here are the details.
On the 29th of October, 2006, Hiroyuki, JH1UGF moved to Mt. Toogasa (altitude about 900 metres) and Tsugno, JN1AYV stayed at home in Chagasaki, Kanagawa for this experiment. The distance was 63km and both of us were within the line-of-sight. We used the same systems as follows. Our 1295MHz, digital transceiver was ICOM's ID-1 . To up/down-convert frequency, the 5760MHz transverters UTV5600BIIP were employed but some circuits were modified for this experiment. Since fast T/R switching is quite important, we removed the coaxial relay and added a circulator instead, as shown in Fig.1. In addition, two anti-parallel diodes were Inserted at the RX front end in order not to damage the preamplifier. These diodes cannot be seen In Fig, 1 unfortunately . The driver amplifier is MGF0904A and the final amplifier is 2xMGF1302, which outputs about 1W. We used a homebrew 25cm dish antenna with a horn radiator. Its gain was 25dBi.
We started our experiment. The voice QSO on FM was quite successful, RS 59+, as the distance was short enough . Then, we switched to direct digital mode for IP connection but the result was poor . Using a ping command of MS-DOS, Its connection rate was lower than 10%. Considering the multipath effect, we changed the frequency and/or antenna direction, but in vain. Lastly, Tsuguo moved his entire system , which was initially set in his room, to a balcony. Tsuguo had thought the experiment would have been successful even through a glass window since they had been within the line-of-sight. We got 100% ping connection after this trial.
Then we tried an application experiment. Using IP Messenger (IPmsg) software, Hiroyuki loaded an Tsuguo's image file into the Hiroyuki's PC. Look at our evidence of Fig. 2. The front is Hiroyuki and the back is Tusguo in the inset photograph. The 90KB file transfer took 6 or 7 seconds and, then, its application-layer throughput was calculated to be approximately 100kb/s . We learned that any thin obstacle in the path might make the multi-path interference at high-speed data communication. We would like to make the distance longer and to make the throughput higher in future.
As there seems to be quite a bit of interest, I've put together some preliminary installation instructions. More technical info, build detail, etc will follow.
Download latest Rasbian image from http://www.raspberrypi.org/downloads and write to an SD Card in the usual way. (2GB is enough, but larger can be used). Leave card in PC.
Check that you have folders lib, proc, sys, dev, etc, bin, files, OpenWRTFiles, PIFiles. I've sometimes had problems with winzip not creating empty folders.
Open the boot partition of the SD card, and copy all the files and folders from meshautoconf0.4.3 into it.
Unmount the SD card, install in PI, and power up, If you have a monitor it is worth connecting it so you can see what is going on.
The PI should boot 3 times. The first time it uses the boot partition as the root partition, and copies a few files to the main partition on the PI. This takes a few seconds. The second time it uses the rc.local file just installed to install some packages (from the boot partition, so no internet is needed). and configure the node. This can take several minutes. It then boots again to activate the MESH configuration.
The files are set up to work the same as a WRT54 node - the LAN port is configured as 172.27.0.1, with DHCP enabled - so you can connect a PC and configure the node in the usual way (web browser to localnode:8080). Sometimes I've found the PC doesnt get an IP address the first time. If this happens, rebooting the PI should fix it.
I've found it easier to configure the LAN port with an address on my LAN, so I don't have to unplug the PC and connect it to the PI. You can edit file "interfaces" to set an address on your LAN instead of the 172.27 address. If you do this, remember to set the same address when you configure the Node. or you will loose access. You'll need to connect to the IP address:8080 to configure.
73,
John
(Footnote: The userid/password is the standard HSMM-MESH root/hsmm)
KK6DCI also has a project for building a BBHN node ("Broad Band Ham Net", the new name that replaces HSMM-MESH) on a RasPi at https://github.com/urlgrey/hsmm-pi. It has been used with a 1 watt Alfa AWUS036 USB wireless adapter (using the aircrack-ng driver for the rtl chip in the Alfa).
So what is the advantage of rolling your own this way, you may be asking?
The real advantage is that you can drive a cheap, relatively high-power USB wireless device, like the 2 watt Alfa AWUS036NH... Also the Alfa devices use the Atheros chipset, instead of the Broadcom chipset used in the WRT54.. devices. Atheros devices can be programmed to work outside of the normal Part 15 overlapping channels.
In addition utilizing different supported-rates, you can take advantage of the different channels with minimal or no overlapping. You may also be able to fit a ham only channel in in band segments not shared with Part 15, resulting in a lower noise floor.
The WRT54 and other embedded devices have a limited amount of on board memory and processor power. This is not an issue if you roll your own using a Raspberry Pi. The Pi will also be able to easily support many running services, like FTP, IRC, etc.
Bob, K0NR wrote back in 2012 about the theory of dualband (2M/70cm) handheld
transceiver that is built on top of the Android operating system.
He wrote:
"While this hardware configuration is exciting, the real power comes
from having a software developers kit (SDK) with a stable Application
Programming Interface (API). This would unleash the creativity of all those software-oriented hams
out there and a plethora of apps would emerge"
I agree.
Since then, smartphones like the Runbo X5 are available, these have a built
in UHF two way radio.
More recently Bruce Perens K6BP has been giving talks about his vision of the
"HT of the Future."
Some of his points are:
Narrower bandwidth, not more than 3 KHz
Higher end units run Android, and host applications which communicate over
digital radio.
-The prototype we are working on is based on Chris Testa's Whitebox design,
and an Android touchscreen computer as the user interface and application host.
-It can run Android applications in conjunction with it's packet, digital
voice, or FM two-way radio.
- It has WiFi, Bluetooth, GPS, USB, Ethernet.
The problem is Apps use data to transfer information to work. If we are
talking 1200 or even 9600 baud, then the app space is doomed by this limitation. There really isn't any talk about apps as those
will be a third party thing. However I feel you should identify what
some potential ones would be, so that the hardware can be designed to
accommodate. I don't see that, so it's more or less; here it is, if you can make it do what you want, cool. Else not cool. In short I think the data rate will
significantly impact what you can do with it.
Whitebox is SDR design optimized for a handheld. It uses a Flash based
gate-array for low power consumption. The problem is it's a narrow band
I/Q modulator design. This version probably isn't good for spread spectrum.
However HackRF, an open source SDR platform by Michael Ossmann would
be.
I have written many times that ham radio needs to embrace spread spectrum. I have also pointed out that is somewhat incompatible with our gentlemen's
developed bandplans.
So I'd like to compile a list of things (think big) you'd like to see your future HT do. Here are some of my initial thoughts:
Mesh style, were if your HT can't reach the repeater/ other person it
will find a relay (your mobile etc - think same band crossband)
GPS for APRS as well as auto downloading/programming local repeater
frequencies on the fly. Street level map display for APRS (android
interface)
Voicemail - if your not answering a directed call it will go to a hunt
group, and lastly voicemail till next time you PTT (SIP integration)
Ability to use the HT as a remote base for your frequency agile home station.
RTL like ability- able to monitor public safety trunked systems out of
of the ham band, while simultaneously monitoring the ham channel.
For those who don't know; the amateur radio service has a good chunk of the
IPv4 Internet address space (44.0.0.0/8), and it's not being used to its fullest
potential. Meanwhile, the rest of the Internet is crowding into the remaining
address space and will no longer have any left in the near future.
The address space isn't being used because of a chicken-and-egg problem: the
necessary digital repeaters aren't available for users, and there are no users
to justify building the repeater network.
But it doesn't have to be limited to just slower packet radio for TCP/IP,
either. Some of the newer 802.11 wireless ethernet devices use frequencies that
meet with amateur radio spectrum in the 2.4 GHz area. As a result, amateurs can
modify the Part 15 compliant devices to increase the power and use better
antennas, providing more gain and increasing usable range. These devices are
considerably faster at up to 54 megabits per second than the 1200 and 9600 bit
per second speeds of VHF and UHF packet radio.
Good connectivity enables a number of applications that were not previously
practical to experiment with due to bandwidth requirements; among these could be
digital voice repeater linking, digital quality facsimile picture transmission,
television (D-ATV), Web-SDR, multimedia, and so on.
In the United States there has been debating a bill to create an Internet
kill switch, also known as the PCNAA
bill. Echolink, IRLP, APRS gateways, and many other services assume the
Internet's original distributed design won't allow a single entity to take out
the entire network. If the PCNAA passes, this will no longer be true. For true
redundancy, a non-critical
network can and should be built by the amateur service to avoid this single
point of failure.
The cost of the equipment has finally come down to the point where even a
modestly funded amateur radio club can afford to set up a small regional network
by themselves. Through advocacy and standards development.
Ham radio used to be a good starting place for many who later
entered broadcast and electronics careers. Today those positions are few
and far between due to disposable electronics and consolidation of engineers
with mega broadcast groups. What is the most notable/abundant
"tech" career today is IT (information technology) work.
Building these networking helps ham radio stay relevant. These networks
have the potential to draw new blood into the hobby. New hams who have
software skills that can help the community with software defined radio and so
forth.
In the USA the Broadband Hamnet HSMM-Mesh website is the most
active collection of people trying to accomplish the same thing our European
amateur friends have. What their firmware build lacks in a way to use the
amprnet and the 44 net address space and it's automatic tunnel
connectivity. The firmware so far also lacks a way to address channels
outside of the Part 15 overlap where there is typically a better noise floor.
Attached are some screen shots of interesting things I have
stumbled into on the Amprnet.
Many of today’s experienced engineers got their start in electronics through amateur, or ham, radio.
Over the years, however, the demands of these engineers’ work, families, and communities took precedence, and many hams lost interest and let their licenses lapse. Meanwhile, with the rise of personal communications and Internet connectivity in homes, many young engineers never needed ham radio as a way to explore electronics. They’ve missed the opportunity that this fascinating hobby presents.
The first wireless communicators were by definition all amateurs. Guglielmo Marconi himself, generally regarded as the inventor of radio, once famously remarked that he considered himself an amateur.
Experimenters have created modulation schemes and accompanying protocols, complete with forward-error correction, which enable direct keyboard-to-keyboard contacts even with low power and small antennas.
Above are some current books that help us fulfill part of the basis and purpose of ham radio; to contribute to the advancement of the radio art.
Ham radio is a hobby for those who like to learn (usually by experimentation) and would never be satisfied being just a mere consumer of today's technology and gadgets.
The engineer and hams mindset is "how does this work, how can I make it better?"
The local club that I belong to recently took a look at their bylaws basis and purpose.
1. The promotion of the interest in amateur radio communication and experimentation.
2. The establishment of amateur radio networks to provide electronic communications in the event of disasters or other emergencies.
3. The furtherance of the public welfare.
4. The advancement of the radio art.
5. The fostering and promotion of non-commercial inter-communication by electronic means throughout the world.
6. The fostering of education in the field of electronic communication.
7. The promotion and conduct of research and development to further development of electronic communications.
8. The dissemination of technical, educational and scientific information relating to electronic communication.
9. Provide encouragement and educational opportunities to any person interested in participating in the radio art.
10. The printing and publishing of documents, pamphlets and other information necessary or incidental to any of the above purposes.
The hard question is how specifically have we fulfilled these in the last year.
I think this is a good idea for clubs, to annually review what there have done in the name of what they are about.
An idea was presented at our most recent meeting to donate some ham radio books to the local libraries (both public libraries and at the colleges). A special committee was formed to investigate what is currently on the shelves.
Being on that committee, license manuals are at several public libraries, along with small scattering of other traditional books.
Ward Silver's "Ham Radio for Dummies" I feel replaces the old Now Your Talking Book. Now Your Talking was not only was a license manual, but also gave a pretty good explanation of the different facets of the hobby. Ward's book does a great job explaining the different facets. There were a few copies of this floating around at the different libraries, which is good.
At the local technical college, there weren't any books specific to ham radio. When I attended, QEX magazine was in the periodicals area. Today there isn't anything of the sort, nor any Circuit Cellar, Elektor, Nuts and Volts or really anything of the nature. I was saddened to see this.
So to help the hobby in the right direction, the books above, I'd love to see in the colleges.
If your club decides to donate books, you can put a sticker on the inside cover to read something like "Donated by the Green Bay Mike & Key Club. www.k9eam.org" To point them in the right direction if the book interested them.
There is plenty of information about ham radio on the internet, but the newer areas currently being explored by hams, isn't as prominently displayed to would-be hams or even the existing hams.
The July 2013, QST magazine contains an article on page 68 on the use of HSMM-MESH(TM) / Broadband-Hamnet(TM) in support of the Big Bend 50 Ultramarathon foot race.
Beyond that, it is the cover story of the July QST. Our Austin mesh crew made the cover!
Some of you may have known K8OCL, John Champa, who was the first ARRL HSMM Working Group chairman. He is now a Silent Key.
He had a photo taken of him back in 2003, with a "dream" photo-shop edition of QST in his hands with HSMM on the cover. He worked hard for many years to help hams realize that we have been gifted with some mass produced consumer gear ( like the LInksys WRT54G ) that allows hams to get into wireless broadband radio at prices of a lifetime!
I am glad to see that we managed to carry on his efforts with HSMM gear and have actually made the cover of QST, 10 years after he held up his "dream" copy of QST.
Your printed copy of the July QST should arrive soon. Please do what you can to help raise interest in HSMM efforts in your area. It would make John happy to know that the word is getting out - cheap ham gear with massive bandwidth capability, so hams can have their own version of a wireless broadband tool.
So let say you want to offer a service to hams, and only hams. How do you verify they are hams?
Perhaps you are creating VOIP network, with Asterisk, like Allstar. Or maybe you want to offer a dynamic dns service only to hams or, maybe some web hosting.
It can be a major pain to manage an user account database for thousands of hams and check if your users around the Internet are, in fact, licensed.
It turns out that ARRL's Logbook of the World has already given out cryptographic X.509 certificates to 57334 amateur users, after verifying their license status against the FCC database (they send a postcard with a random token code to the FCC-listed snail-mail address to make sure they give the certificate to the right guy) or after looking at a paper photocopy of a license + a photo ID.
If your registered with LoW, it's not to hard to extract your certificate. This could be used for any number of authentication purposes. One big one comes to mind. Repeater frequency coordination.
Seems this is still done by mailing reminder renewals, and signing and mailing back. If only there was a way to modernize this, and still have a (digital) signature... :-)
Here are the steps to take to get APRX (as a receive only I-Gate) to run on a Raspberry PI using a sound card. Special thanks to Bob, KB8ZXE for providing the info.
This approach is cheap as it doesn't require a TNC or hardware tracker board. You should be able to throw together everything minus a radio (The Pi, power supply, sound FOB, case etc) for less than $60.
This is assuming that you have taken the steps to make your usb soundcard your default soundcard. You should refer to my earlier post about how to get that going. Since then (using the latest Wheezy), I have been successful with USB other FOBs. I did not need to manually provision /etc/asound.conf
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
#1 W1AW-14 1200 255 2 144.390 MHz (1200 bps)
sm0 W1AW-14 1200 255 2 VHF APRS (1200bps)
At this point soundmodem should be installed and ready to run. To test this you can feed a radio or test audio file into your soundcard. If you start soundmodem in the background (soundmodem &) and then run axlisten -c -a you should see packets being received.
4.) Download aprx and compile it, (I am using version 2.07 SVN 539) Grab the latests tarball from here: http://ham.zmailer.org/oh2mqk/aprx
untar, run the configure script, make, make install.
5.) Edit /etc/aprx.conf ( I have included a very simple conf file for aprx rx-only i-gate)
#
# Simple sample configuration file for the APRX-2 -- an APRS iGate and Digipeater
#
# This configuration is structured with Apache HTTPD style tags
# which then contain subsystem parameters.
#
# For simple case, you need to adjust 4 things:
# - Mycall parameter
# - Select correct type of interface (ax25-device or serial-device)
# - Optionally set a beacon telling where this system is
# - Optionally enable digipeater with or without tx-igate
#
mycall W1AW-14
<aprsis>
server noam.aprs2.net
</aprsis>
<logging>
pidfile /var/run/aprx.pid
# rflog defines a rotatable file into which all RF-received packets
# are logged. The host system can rotate it at any time without
# need to signal the aprx that the file has been moved.
#
rflog /var/log/aprx/aprx-rf.log
#
# aprxlog defines a rotatable file into which most important
# events on APRS-IS connection are logged, namely connects and
# disconnects. The host system can rotate it at any time without
# need to signal the aprx that the file has been moved.
#
aprxlog /var/log/aprx/aprx.log
#
</logging>
<interface>
ax25-device $mycall
# #tx-ok false # transmitter enable defaults to false
</interface>
<beacon>
beaconmode aprsis
cycle-size 20m
#
beacon symbol "R&" lat "4427.28N" lon "08756.22W" comment "sound modem"
#
</beacon>
At this point your soundmodem is running and when you start aprx everything should work. You may want to create scripts that will start soundmodem and aprx on boot. If you run mheardd you can use the command mheard to display recently heard stations.
A while back my friend and I found hamlib, a development library designed to remotely control nearly any CAT/CIV capable transceiver or receiver. It compiles and works just fine on the Raspberry Pi.
Before-hand ensure you have these dependencies installed:
libltdl-dev or libltdl-devel or libtool-ltdl-devel (use yum/apt-get)
wget http://sourceforge.net/projects/hamlib/files/hamlib/1.2.15.3/hamlib-1.2.15.3.tar.gz
tar -xvzf hamlib*
cd hamlib*
./configure
make
make install
ldconfig
So we have been using SSH and hamlib to control a remote Icom 706. We have been using speak freely to stream the audio.
I have been meaning to try and create a PHP/CGI web based front end for this. Couple that with darkice and icecast for a way to stream audio to that browser.
root@darkpi-ice:/# telnet localhost 4532
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
f <---- I sent this and got back below:
1590000
Here is a screen shot of my web control front end:
Here is the radio with the Raspberry Pi, USB sound input, USB TTL converter for CIV.
Basically a way to enable web based control of a radio with CIV. Remi, F4ECW has some example PHP code for this that I snagged from a Yahoo group. It also appears to have a start for remote fldigi.
Another good project would be to layout a small board with jumper selectable COR and PTT transistor configurations than can be interfaced to the Raspberry Pi GPIO. So far I have just been bread-boarding this.
I just haven't had the time to create such art work and submit it to Far Circuits.
Again if anyone wants to beat me to the punch on either of this, please do.
Worth reading: "Raspberry Pi: A Tiny Computer for Big Projects" by; Matt, KB3TAN - CQ Magazine, March 2013
Name will change to Broadband-Hamnet™
Written by Rick Kirchhof, NG5V
Wednesday, 27 March 2013 22:46
A firmware release is scheduled in the 2nd quarter. Some major changes will be included. The list below gives a bit of detail but some changes are already in place. For example Broadband-hamnet.org or Broadbandhamnet.org already bring up this site. HSMM-MESH.org will
still work but the site will now answer to both. Other things to expect are:
SSID changes to Broadband-HamnetV1
Upgrade ALL is necessary as SSID and the actual format of data flowing will be changing.
SSID minor level (V1) will roll when succeeding firmware requires another upgrade all.
Interoperability with Ubiquiti hand loaded systems (simple web page config for Ubiquiti comes later)
DNS changes from the Austin.TX.mesh style to local.mesh
More FAQs to be written, better documentation on the way
YouTube videos becoming more popular, see "videos" in left menu or search YouTube.
More mesh elmers have joined, more are needed.
Over 1200 registered users on the forums, rising by nearly 100/month.
Web site hits growing at an increasing pace, Google hits for hsmm mesh search terms growing.
QST article in July with more to follow.
Watch here or in the developers newsgroup for updates.
73,
Rick, NG5V
Here are some excellent starter videos from Kevin, N7RXE:
--
Dave AD5OO has officially released the 1.0.0 Broadband-Hamnet firmware. (8/2013)
This new firmware is NOT backward compatible and has some significant changes upon install by default. Any nodes flashed with this new 1.0.0 will NOT talk in any way shape or form with 0.4.3 (or older) firmware. Its All or Nuthin.
The major change you will notice is that instead of the LAN being in NAT mode, it is now in 5-host DIRECT mode (formerly called DMZ). NAT mode is still available for those who wish to switch back, but give Direct Mode a try, as it makes devices/servers easier to put out onto the mesh.
Also, this firmware now allows those who hand-craft firmware onto other manufacturers' hardware to be able to mesh back with the WRTs we have all come to know and love.
You can read the change log on the site (below the WISH LIST, dont get those confused like I just did myself...), and get the new firmware from the software download page.
OR, if your node(s) have internet access, you can go to the Setup-Administration page, click REFRESH next to the Firmware Download section, then use the pull-down to pick the 1.0.0 TRX file.
IF you have mesh nodes already at 0.4.3, you can just choose the generic TRX file without needing to use the hardware-specific BIN files.
But remember, this is a FULL flash: You WILL need to setup as if from scratch (set the nodename and new passwords) once you flash. If you have any services running on a node, backup in some way any customized settings before flashing (dummy me lost a custom script I wrote on one node because I forgot to copy it off the node to somewhere else before I flashed it---LEARN FROM MY MISTAKE!BACKUP BACKUP BACKUP)
I HIGHLY suggest you read the documentation again to refresh your memory, and if you have any questions, the Documentation on the site, Help files, and forums are a great place to start.
Happy Meshing!
Jim
K5KTF
Webmaster & Mesh Geek
Broadband-Hamnet.com
Here are some screen shots from the web GUI to show the features of the Broadband HamNet firmware (BBHN).
-
The purpose of what follows is to show network throughput speeds in a direct verses indirect scenario. There are concerns about significant bandwidth preference hits in a mesh network, when you have to hop though a couple nodes to get where you are trying to go.
The simulation will use three mesh nodes. Where "A' has a HTTP server attached to it, and "C" is the client trying to reach "A". All are spare WRT54 series Linksys units that were floating around. The output power was adjusted to 1 dBm and TX and RX antenna were set the same on the basic configuration page. The use of dummy loads, and a little physical distance will then help simulate a situation where nodes "A" and "C" cannot reach each other directly. This is where we will introduce node "B".
The HTTP server is a Raspberry Pi B+, running apache. It is connected to Node "A" via the LAN port of the WRT54G.
The client computer is an old Sony PIII laptop running XP. It has a Windows version of Wget installed to retrieve the file from the Raspberry Pi Webserver since it has a convenient throughput output. The laptop is connected to the LAN port of node "C".
MB/s = MegaBytes per second
KB/s = KiloBytes per second
First some baselines for comparison:
Wired Direct:
C:\Program Files\GnuWin32\bin>tracert 10.25.39.60
Tracing route to 10.25.39.60 over a maximum of 30 hops
1 1 ms 1 ms 1 ms localnode.local.mesh [10.195.3.201]
2 3 ms 2 ms 2 ms 10.25.39.60
Trace complete.
C:\Program Files\GnuWin32\bin>wget 10.25.39.60/file.tar.gz
--2014-10-17 03:38:07-- http://10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 7.89M/s in 4.2s
2014-10-17 03:38:11 (7.91 MB/s) - `file.tar.gz' saved [34764375/34764375]
With DD-WRT, standard Wireless AP/Client configuration
(DD-WRT AP has the Pi at 192.168.1.122):
C:\Documents and Settings\Owner\tracert 192.168.1.122
Tracing route to raspberrypi [192.168.1.122] over a maximum of 30 hops:
1 20 ms 1 ms 1 ms raspberrypi [192.168.1.122]
Trace complete.
wget http://192.168.1.122/file.tar.gz
--2014-10-18 22:23:42-- http://192.168.1.122/file.tar.gz
Connecting to 192.168.1.122:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 2.80M/s in 12s
(2.79 MB/s) - `file.tar.gz' saved [34764375/34764375]
Using BBHN, direct, from node C to A (100 % Link Quality):
C:\Program Files\GnuWin32\bin\tracert 10.25.39.60
Tracing route to 10.25.39.60 over a maximum of 30 hops
1 1 ms 1 ms 1 ms localnode.local.mesh [10.195.3.201]
2 3 ms 1 ms 3 ms kb9mwr-A.local.mesh [10.99.36.231]
3 3 ms 2 ms 2 ms 10.25.39.60
wget 10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 1.90M/s in 17s
2014-10-17 02:58:02 (1.06 MB/s) - `file.tar.gz' saved [34764375/34764375] (1900 KB/s)
Using BBHN, direct, from node C to A (16 % Link Quality):
wget 10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 1.11M/s in 31s
(1.06 MB/s) - `file.tar.gz' saved [34764375/34764375]
BBHN indirect, through B (100 % Link Quailty):
C:\Program Files\GnuWin32\bin\tracert 10.25.39.60
Tracing route to 10.25.39.60 over a maximum of 30 hops
1 1 ms 1 ms 1 ms localnode.local.mesh [10.195.3.201]
3 6 ms 6 ms 6 ms kb9mwr-A.local.mesh [10.99.36.231]
4 6 ms 6 ms 7 ms 10.25.39.60
wget 10.25.39.60/file.tar.gz
--2014-10-18 17:49:18-- http://10.25.39.60/file.tar.gz
Connecting to 10.25.39.60:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 279K/s in 1m 43s
2014-10-18 17:51:02 (329 KB/s) - `file.tar.gz' saved [34764375/34764375]
82.68 % slower throughput, compared to the direct A to C connection!
Summary:
The automatic routing that a Mesh network provides is very handy for issues; of interference between nodes, fading and other temporary obstructions that crop up in the path. It is beneficial because the connection can continue, instead of dropping out completely. It also simplifies configuration, which is a real benefit for end users or quick deployments, where the users might not be familiar with the network topology.
However, as you can see, there really isn't a replacement for good network planning. Hops should always try and be minimized in the network design. Dedicated back bone channels should exist between high profile user end access points, to essentially provide a full duplex radio link back. This will help eliminate the throughput problem that occurs with half duplex radio links.
With Nano M2 to M2 using UBNT firmware one as AP the other as station,
standard 20 MHz channel:
C:\Program Files\GnuWin32\bin\tracert 192.168.1.200
Tracing route to 192.168.1.200 over a maximum of 30 hops
1 3 ms 1 ms 1 ms 192.168.1.200
Trace complete.
wget http://192.168.1.200/file.tar.gz
--2014-11-04 15:17:24-- http://192.168.1.200/file.tar.gz
Connecting to 192.168.1.200:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 3.50M/s in 9.5s
2014-11-04 15:17:34 (3.48 MB/s) - `file.tar.gz' saved [34764375/34764375] (3500 KB/s)
BBHN indirect using Ubiquiti gear, through B (100 % Link Quality):
C:\Program Files\GnuWin32\bin\tracert 10.80.117.246
Tracing route to 10.80.117.246 over a maximum of 30 hops
1 1 ms 1 ms 1 ms kb9mwr-c [10.98.20.137]
2 4 ms 4 ms 3 ms kb9mwr-b.local.mesh [10.230.178.251]
3 7 ms 8 ms 7 ms kb9mwr-a.local.mesh [10.10.14.190]
4 6 ms 8 ms 5 ms 10.80.117.246
Trace complete.
wget http://10.80.117.246/file.tar.gz
--2014-11-04 17:10:18-- http://10.80.117.246/file.tar.gz
Connecting to 10.80.117.246:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34764375 (33M) [application/x-gzip]
Saving to: `file.tar.gz'
100%[======================================>] 34,764,375 965K/s in 36s
2014-11-04 17:10:53 (955 KB/s) - `file.tar.gz' saved [34764375/34764375]
72.71% slower throughput, compared to the direct A to C connection!
Note that there is about a 10 % improved throughput using the Ubiquiti gear over the Linksys!
A large part of the throughput hit is related to the fact that collisions are
likely going on, as the relay node is transmitting, the server is likely sending
its next frame, for example.
I was told that 802.11n capable chipsets (like the Ubiquiti M2 line), there are
enhancements related to the RTS/CTS mechanism to help with this. And
apparently this is so after performing these tests.
A large part of the significant slow down (50-60%) between the direct and the
second is because the channel becomes a half duplex link that has to
repeat the content (same as 1200 baud through a digipeater) but would expect it
to taper off the more hopes you get as you get to a point where one set of nodes
is receiving while another is transmitting.
Last night's episode of Family Guy was a re-run from Season 11, Episode 3 that originally aired 10/21/12, titled "The Old Man and
the Big 'C'." It had a quick reference to ham radio.
At a ballgame, Quagmire accidentally loses his toupee going for
a fly ball. When he becomes a laughingstock, he decides to ditch the wig. The
change in his appearance affects his attitude, changing him into a old man.
Quagmire runs a radar gun in-front of Peters house asking hot rodders to slow
down. "My ham radio interferes with my radar gun. Talked to
some fella in Papua New Guinea last night, you should stop by some time."
What is actually disappointing
about D-Star is that it's only a 4800 baudtotal data stream equivalent
signal. 2400 bps is reserved for actual digital voice, 1200 bps is
reserved for FEC (forward error correction) on the digital voice. (This
is for callsign and short message data.) 1200 baud is
reserved for serial data low speed digital data . (This is for APRS, and text messages/text
query's.) The sad part is 1200 baud data is what we were doing in the
1980's.
So if 4800 baud can
fit into a 6kHz bandwidth, we could have had a 12800 (12.8k) baud total data
stream equivalent signal fit into our existing 16 kHz bandwidth plans. This
could have left us with 9.2k left for data. Or at the very least more
could have been given for the digital voice codec, so that we could use other
license free-codecs that sound more natural.
The problem is frequency coordinators have broken the bands into
channels most fairly narrow in width, with conventional input and
outputs. I think this image/model discourages potential other use, that
may not fit the convention.
And my last blog was about a potential rules re-write to encourage some new developments in the hobby.
Ham radio has always used hand-me-down gear from the commercial world.
And I would be absolutely irate if some coordination body told me as an
existing repeater owner that I had to narrow band.
I think a some guidelines would be;
-If you are putting a new analog repeater on the air, if it's narrow
band capable, it should be. To start a 5-year phase-in plan for
6.25kHz channel centers and mandatory 2.5 kHz narrowband FM deviation on
analog.
-The number of wide band and narrow band analog channels needs to be
rationed. I'd like to see some effort to slowly over time (via
attrition) clear out and reserve some wider channels on the VHF and UHF
bands for new techniques.
-I think when it comes to coordination requests, newer modes should be
given priority. If there are 10 analog repeaters in a given area, and
someone proposes to put up a P25 system, but there are no channels
available... back to rationing space for older modes.
Of all the VHF/UHF digital radio modes I have played with. I like TETRA the most, as it's the most versatile. The biggest problem is price.
It supports 4 TDMA channels in a 25 kHz bandwidth channel. Mototrbo/DMR does 2 TDMA channels in a 12.5 kHz bandwidth channel.
The main reason I like it is because it doesn't sound digital. It sound
like a telephone grade voice path. This is because the radios also
function like mobile phones. There is Asterisk SIP tie in support.
And for IP packet data services, DMR offers a throughput of 2.0 kb/s per
timeslot, whereas TETRA offers 3.5 kb/s per timeslot. So if you code
an application for DMR that uses both slots, the max is 4 kb/s. With
TETRA 4 timeslots can be combined into a single data channel to achieve
higher rates.
And if you are not in range of the repeater system, DMO mode allows you
to repeat though a
sequence of one or more TETRA terminals as relays to reach your
destination. (Think same-band crossband using alternate time slots)
So in summary, narrow banding just so we can have more of the same
(under used analog repeaters) is just plumb stupid in my opinion.
Here are some relation observations that I made early in 2011:
During an interview, the Beaver Valley ARA revealed that ARRL President,
Kay Craigie, N3KN got licensed in 1983 because she was jealous of all
the fun her husband was having with ham radio. She was a computer
hobbyist at the time and became a ham just when computers
were starting to be integrated with amateur radio.
So it would seem natural to assume her stance on the future of digital communications is strong.
Brennan Price, N4QX is the new Technical Relations Manager filling the
vacancy created by the retirement of Paul Rinaldo, W4RI.
It was Paul, W4RI's recommendation (back in 2001), to the Board that
the HSMM Working Group be founded and he has written many-many articles
over the years on packet radio and other digital aspects.
I don't know much about Brennan, N4QX, other that his stated goal is
to "defend Amateur Radio spectrum. So it would seem that encouraging new uses and techniques would be logical.
I fell strongly about the ARRL Technology Task Force. I hope he can
fill the shoes as well as Paul did.
So far I haven't really seen anything happen at the league level that
affirms my above assumptions of these two. I kind of expected these
jokers to file comments to the FCC along the lines of what Bruce Perens
did in terms of getting some rules relaxed to help move things forward.
Bruce Perens, K7BP a well know open source advocate and proponent of Codec2 filed FCC comments to the on-going petition for rules chance to allow TDMA used by MotoTrbo.
Some back ground:
The KA9FLX repeater in Chicago, IL was the first Mototrbo Amateur Radio Repeater. It was put on the air in 2008.
In March 2011, some overly concerned fellow Amateurs brought a emission rule technicality to the forefront. Apparently the classified emission type doesn’t match those specifically allowed for ham radio.
At the time of the petition, there are more that a dozen Mototro repeaters in service on amateur frequencies. Since then, over 90 repeaters have been reported as up and running.
The processing time of requested FCC rule changes for all services is enormous. For example, the request to Eliminate the Spread Spectrum Automatic power control Requirement took 4 years to be approved.
For the past several years, all the ARRL initiated petitions for FCC rule changes have been very narrow requests.
In Bruce’s comments he points out that the regulatory framework continued by this NPRM would not handle software-defined radio well.
The point is that development is already rapid, and will only increase. The current regulatory framework will not keep up with this development.
This contrasts starkly with Amateur Radio's mission to advance the state of the art.
The present system that FCC must approve each significantly different modulation type to reach Amateur Radio only causes Amateur Radio to fall further and further behind in terms of developments.
Continuation of this piecemeal process of authorization would place severe regulatory hurdles and hinders the capability of Radio Amateurs to experiment and innovate.
I wrote Bruce to thank him for his comments. A major rule revision like he is proposing is long over due in my opinion.
Why the ARRL hasn’t gotten behind a major rule re-write like he is proposing is beyond me.
Apparently, their ideology on getting more amateur activity has focused on consolidating the license classes, instead of helping enable new technologies that might help foster more interest in the hobby.
If you are a Ham Radio Operator you've probably been looking at the Raspberry Pi with a lot of possibilities.
One of it's downfalls if the lack of an on-board input. But once you add a USB sound fob, Echolink, remote rig applications, IRLP, and decoding various digital modes like PSK, and so on, are all a reality.
Finding a USB sound device and setting it up can be aggravating.
I recommend the SYBA SD-CM-UAUD USB CM119 audio adapter.
If lsusb doesn't report it as below, you have the wrong one:
root@pi:~# lsusb
Bus 001 Device 005: ID 0d8c:000e C-Media Electronics, Inc. Audio Adapter (Planet UP-100, Genius G-Talk)
Next you need to make the usb sound card (0) the default audio device
Check yours like so: cat /proc/asound/modules
0 snd_bcm2835
1 snd_usb_audio
Edit /etc/modprobe.d/alsa-base.conf comment out "options snd-usb-audio
index=-2" You want ""options snd-usb-audio index=0" After a reboot it should always appear in this order:
0 snd_usb_audio
1 snd_bcm2835
Take this one step further and comment out the kernel module for the onboard sound and add the usb
cat /etc/modules should look like: #snd-bcm2835 snd-usb-audio
While, I did not find the following necessary in my case, I have read to get better latencies out of USB audio devices, it is suggested to also add:
Since there are some USB issues, I suggest setting the device to boot the USB hub in USB 1.0 mode, this should fix choppy audio. (I did not find this necessary in my case, but it's not a bad idea)
Add "dwc_otg.speed=1" to /boot/cmdline.txt.
Pulseaudio might be part of your raspberry wheezy default image. Personally I am not a fan of it, and have read it wasn't working well on the Pi. I am not sure if that still holds true. I just removed it: apt-get purge pulseaudio I recommend replacing it with Alsa. It has been around a bit longer: apt-get install sox alsa-oss alsa-utils alsa-tools
This should be a good starting point for most. Hopefully in the future, newer Raspberry wheezy images can make this a bit easier, and more kernel support for other USB sound FOBs.
I have been running my Pi using a 5 volt, 1 amp supply via the micro USB power port. I do not use a USB hub. My model B rev 2 has been running reliably for a few weeks now.
Just as a note. If you are making connections to the GPIO for keying a radio or whatever, check your local Radio Shack for "Schmartboard Jumpers ." These are a new thing they are carrying, and are handy.
The code uses the hardware on the raspberry pi that is actually meant to
generate spread-spectrum clock signals on the GPIO pins to output FM
Radio energy. Just add a quarter wave length of wire to GPIO 4 to act as an antenna.
root@raspberrypi:~# ./pifm
Usage: program wavfile.wav [freq] [sample rate]
Looking at the source, it seems simple enough to narrow it a bit: In pifm.c look for:
float dval = sample*15.0; // actual transmitted sample. 15 is bandwith (about 75 kHz)
Obviously this isn't a clean transmitter implementation, so don't expect much more than an autofox.
For a low power foxhunt it might amusing to wire a motion sensor to the other GPIO to adjust your transmit and announce timing cycle, when folks are getting close.
Narrow Band FM transmitter derived from pifm. It is able to transmit FM
from VLF to UHF with a settable deviation and pre-emphasys, frequency
correction and subtones. It runs under debian distr.
In a SSH session type ./nbfm.out for help.
