Sunday, October 15, 2017

Another 900 MHz mesh gadget

From some discussion on the wetnet mailing list:


> https://www.sonnetlabs.com/
>
> Mesh, external antenna connector and cheaper then some of the others I've
> seen.
> Huh... maybe worth finding out more about there type of modulation etc.

A FCC ID search by manufacturer brings back nothing.  So I suspect  this thing isn't as far along as they make it seem.

Some how I suspect the thing will be overpriced like the goTenna and Beartooth anyway.

Else I was going to suggest since its never clear if it has to abide by the image, data, spread spectrum rules or all of the above.... pick whatever is the least restrictive is how I'd go about it.  Consider it an ignorant form of civil disobedience to make a case for rule reform if you like. 

It's the classic case of a multi-media gizmo; "send text messages, images, audio recordings.."

One day likely not in my lifetime the old men at Newington will pull the head out of their posterior, and realize they should have lobbied 30+ years ago to make rule situations like this clearer if they expect anyone to take the things and themselves seriously.

Monday, September 4, 2017

FCC investigating technical regulations

This is mostly stuff I just communicated again to my Division Director.  But I plan to file comments directly, and encourage others to do the same.

I just read the blurb about the FCC Technological Advisory Council Investigating Technical Regulations.  And I was just going to inquire with the league about the status of the October 2013, proposal to modernize the rules for data transmissions.

I have stressed before that I am fine with doing away with the symbol rates, and establishing the proposed 2.8 kHz bandwidth limit for HF. But I am totally against not revising the bandwidth limits for above 50 MHz.  There is plenty of spectrum on the VHF/UHF bands, and other modes like image presently are not as limited as data is.


From: http://www.kb6nu.com/arrl-finally-realizes-status-quo-isnt-going-cut/
(ARRL link)
"From the committee’s vantage point, the status quo is no longer adequate: we need to have a vision of the future and convey it to our current membership. If we do not convey the need to change the paradigm, the ARRL’s relevancy will not move forward."


The first step in anything is admitting there is a problem.  Now if they follow through with comments that reflect something other than the status quo in this latest proceeding, I might feel this is more than hot air.

There are also some good points in The Future of Amateur Radio Is Not In The Numbers , by Chris Warren.

So I sincerely hope any league comments I read on this latest docket reflect some sort of different carve out in respect to bandwidth for data on the VHF/UHF bands.  If for some reason someone doesn't understand why data is important, you can skip down to "Internet Threats and Regulation and The Need for Speed and Digital Networks"portion of this document.

In my opinion we need a group such as TAPR to start getting more involved with the FCC and bypass the ARRL.  It's my impression that the League only cares about contesters and DXers because that is where most of their money comes from.

I remember back when I never really understood TAPR. I knew what the name stood for, so I always assumed they were the voice representing the digital aspects of the hobby. Then I heard a 2008 Rain report where Steve Bible explained TAPR. I wonder if there is any chance of TAPR taking up the role that I thought there were about? 

And as I stressed before, I feel its important to have a futuristic thought process when making comments as it takes many years for regulator changes to actually happen. And in that light, there is a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict and speculate what ham radio will be like in 25 years (2037).

So I encourage everyone to listen to that when you have the time, add your own thinking and start drafting your thoughts to the commission.  I believe they are referring to Subpart D, Technical Standards, which includes; 97.301 Authorized frequency bands, 97.303 Frequency sharing requirements, 97.305 Authorized emission types, 97.307 Emission standards, 97.309 RTTY and data emission codes, 97.311 SS emission types, 97.313 Transmitter power standards, 97.315 Certification of external RF power amplifiers, and 97.317 Standards for certification of external RF power amplifiers.

Now on to what I think:

I actually recommended basically do away with the bandwidth limits, and let gentlemans agreements take rule.  This was something that made sense to me from Bruce Peren's Dec 2012 Codec 2 filed comments. This is how a lot of other countries handle ham radio things.  As long as there is a list of permitted emission designators, our regulations remain brittle and prone to rapid obsolescence (and holding the rest of the world back).   Allow any emission that fits within the band.   Hams have always been responsible and share the bands on their own, without the authorities wielding a stick.

I think that seems logical moving forward.  All we are doing is taking up the FCC's time and screwing ourselves with this 10-15 year re-revising the rule, piece meal approach game like we have been playing, that really just impedes innovation.

I am sure from the leagues recent license survey, they are fully aware that in the next 10 or so years a large number of the existing ham population will have passed on.  A new group of hams who need better representation are the future ARRL customers/members.

Since I got into the hobby in the mid 90's, there have been a couple big license changes.  The first was around 2000, where 5 WPM became the highest code test, and they consolidate the license classes, eliminating novice and advanced classes.  Then around 2006, when the code test went away all together.  I should research how these event came about.  I assume they were ARRL endorsed.  So why the ARRL doesn't endorse some major rule changes bugs me.

Thursday, July 6, 2017

Listening to local 700 MHz Simulcast public safety cheaply

March of last year I blogged about a method I have been using since 2013 to listen the Brown County Sustained Interoperable Radio for Emergency Notification (SIREN) 700 MHz APCO-25 Simulcast system.

The method I mentioned involved using a commercial radio specifically programed not to affiliate with the system.  At the time there were no scanners capable of dealing with LSM (linear simulcast modulation).  Well there are a couple now; the Uniden BCD436 does handle simulcast pretty well, and the newest is the Unication G4/G5 receiver.  The problem is both will set you back well over what most people are willing to pay.

A lot of people are listening to the Police these days on smartphones using various apps, which unknown to many of them is a volunteer effort of a local guy feeding broadcastify over the internet.  I don't like that way, as it eats the phone battery and data plan.  Nor I am overly fond of reliance on someone else to receive the info.  I am the type who likes a scanner on basically all the time in the background at home.  This sounds better, doesn't rely on the internet and gives you the control to stop the scan on an interesting talkgroup. Software Defined Radio is the future of radio anyway so might as well try and learn something I figure.

Today I will detail a software defined radio, that you can build for about $60, that will let you listen.  It uses the RLT-SDR hardware, a Raspberry Pi computer, and runs the OP25 trunking software ontop of GNU Radio.

Unless you live in complete darkness, you should know that RTL is a chipset originally designed for a USB digital TV tuner dongle.  Since the TV frequency band is basically 30 MHz to 2 GHz, the hardware is capable of pretty much anything in that range.  The folks behind osmocom.org are to thank for creating a replacement driver that enables all kinds of cool, and really cheap SDR projects, like the one I am about to explain.  (Did I mention I think someone like the ARRL should give folks like this an award?)


Needed Hardware:
-Raspberry Pi3 single board computer
-SD card (8 GB is fine)
-A RTL-SDR dongle (mine is version 3), and a SMA rubber duck antenna
-Amplified speaker (bluetooth?)
And just to get things setup:
-USB keyboard and USB mouse
-HDMI monitor or adapter to achieve the same (I have a nifty Radio Shack HDMI to VGA adapter that I got dirt cheap when they were going belly-up)

What finally pushed me to try this on the Raspberry Pi was a post from John, N8UR that is some of the best info I have found on how to use/configure OP25.  I applauded his write up and mentioned if it could run on an ARM computer, I'd be playing with it tomorrow.  Shortly their after it was confirmed by the code maintainer that it will run on a Raspberry Pi, so I sought out to figure it out.

Installing:

You'll want to download the Desktop version of Raspbian, and get that on a SD card.  We need the GUI to set things up/verify the signal, but after that, it can be turned off and this thing can run headless.  Perform the normal setup things with raspi-config (set keyboard to US, enable SSH, etc)

The OP25 author released these helpful tips to getting a good start:
First, the testing has been done on the PI 3 "B" with the default install of Raspbian. Load average was around 1.5 or 1.6, with the RPI GUI running and 'top' running in another window...
You'll need to edit the /etc/apt/sources.list file; the file contains the needed "deb-src" line in it, but it's commented out. To fix, edit the file and remove the '#' so the 'deb-src' appears in column one of the file. Save the file, then proceed with the install as follows, first installing the OP25 prerequisites:
sudo apt-get update
sudo apt-get build-dep gnuradio
sudo apt-get install gnuradio gnuradio-dev gr-osmosdr librtlsdr-dev libuhd-dev libhackrf-dev libitpp-dev libpcap-dev git

Then install OP25

cd ~
git clone https://git.osmocom.org/op25
cd op25
git checkout max

mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig


The previous generation OP25 application (scope.py) is being deprecated soon; instead we now use the new rx.py. This app is discussed in the README file that's in the OP25 repo that you checked out:

/op25/op25/gr_op25_repeater/apps/README
(Optionally to speed up the compiling add -j4 to the make command it will use all four cores on a Pi3 and save a ton of time. )
You'll also likely want to have some other tools:
sudo apt-get install ftp gnuplot xrdp

You'll note this new max branch has a different GUI.  The previous version used the wxwidgets GUI library, and that was a common compatibility/code maintenance issue.  This new version has a lighter weight approach using gnuplot for the GUI.  Keep in mind that like any cool Linux development like this is in a constant state of flux, so the steps I detailed today, may very well change tomorrow.  I am sure I'll be blogging again about this.

Now on to the things that I had to figure out.

Configuring/Running:

The first thing you want to do is fire up the new rx.py script tuned to the data control channel of the Brown County System (772.63125)

Everything cool happens in this directory, so change there:

/op25/op25/gr-op25_repeater/apps/

I assume you read the README file mentioned before, which really tells you everything.

Here is my shell script to start the thing.  The first line is the finished product.  It starts the thing with no GUI.  The second line (uncomment it) I used for trouble shooting.  It fires up the gnuplot constellation (more on that shortly).   I tried other sampling rates, but ultimately found the  command line sample  rate to –S 1000000 lowered the processor cycles consumed by the higher SDR sampling rate, which is important when dealing with the Pi.

An observation I had was with OP25 was sometimes it misses very short or very quick response transmissions. It seemed like it just couldn't switch fast enough back and forth between the control channel and any given voice trunk on the system. I tried various sample rates thinking this would lessen the processor load and help this.  Then I read that RTL devices aren't known for their speedy tuning abilities.  Then I learned about the -o (tuning offset) option.  Adding an offset of -o 12.5e3 improved the missing audio problem for me.

Before you start the thing, there are two files you need to create;  trunk.tsv and brown.tsv.  However you can start it without the -T trunk.tsv option just to see if its decoding the control channel.  If everything is working, you'll see a terminal output with an increasing tsbks (trunking signaling blocks), and active voice channels.  If you don't even see that, you should look at the gnusplots and stderr error log for clues as to why its not decoding.




 The gnuplots are live (animated), though what I show here are obviously still screenshots.





Using the constellation plot as a guide you may need to re-arrange the antenna and play with the various command line options until you get a good 4-point constellation. What you want to do is to get rid of the cluster of symbols at the center of the plot so all the symbols move outward into four discrete groups.   If you live near one of the towers you may need to back off the gain to achieve this.  Another common thing to know is if you are tuned on center.  You might want to calibrate your RTL stick using SDRSharp or some other method.  Else just look for -1200 type errors, and add a -q -1 or -q -2 to your rx.py command line for compensation.

The bottom line is: Look in the stderr file for anything untoward.


On To Trunking:
Once you can decode the data control channel properly its time to configure the trunking.  This is commonly done in a file called trunk.tsv.






Make sure that all of the fields in your trunk.tsv are quoted and tab spaced.  Note the Brown System NAC is 0x4a1.

As you can see trunk.tsv references brown.tsv which is where the talk groups are defined.




brown.tsv provides a table of talkgroup numbers and names for the Brown SIREN site.  You are basically defining what you want it displayed as when its active.  Once again there must be a tab space between the talkgroup decimal ID and name.



Starting The Audio:

After rx.py starts, you can start the audio listener.  Do that in a separate terminal window, or start it as a background process.  There is more than one way to listen/ get audio to speakers.  The -w option in rx.py is the output data to wireshark option.  This includes audio as UDP.

Using that, a simplistic way to redirect the audio portion to your sound system is to use netcat.




The first line tells the Raspberry Pi to set its audio output to the 1/8" jack, instead of HDMI which may have been automatically setup when you hooked up a monitor.  Netcat redirects to aplay, which is pretty self explanatory.

When its up and running the terminal does show you what talkgroup you are hearing.



This should be everything you need to know.  It has a learning curve, but anything cool usually does.  If someone finds a nice case (a 6x4x2 project enclosure) and an amplified speaker with its own volume knob then we have the final touches.  I'd look forward to reading others performance feedback on other single board computers, and SDRs.  The Pi3 is pretty much the bare minimum, so I'd recommend heatsinks for your Pi.  I haven't yet read of anyone who has got it going on Asus Tinker Board, but would be interested in hearing from anyone on that.





{edit 8/13/17}
A friend reports that they tried the NooElectric SDR and have had better results.  They have done some extensive testing and report no chopped audio, and with few if any chirps on the beginning or end of transmissions.

One note; the NooElec dongles do not seem to exhibit any significant DC spike so the -o 12.5e3 offset on your rx.py command line offset is unnecessary. We have tested two of them and they work just fine with -q 0 specified.  Below are a couple of links to find them on the internet. 



And here is what my friend did to complete the project.  He installed it inside of an old Motorola Alert Monitor.  He drives the speaker with a 5v 3w amplifier. 

The small oled 128x32 display on front shows ip and disk usage on bootup. ( Use the available adafruit libraries and examples to add the necessary pieces to the OP25 terminal.py script.)


While receiving it shows talkgroup, frequency, and talkgroup description. The original volume knob controls volume, and turns system on/off.


Like I mentioned above, any cool Linux development like this is in a constant state of flux, so the steps I detailed today, may very well change tomorrow.  Thanks to these folks to keep sharing pointers like I did:

{2018 Update} I recommend reviewing KN4FMV's op25 for dummies:
https://www.hagensieker.com/wordpress/2018/07/17/op25-for-dummies/

{2019 Update} KN4KNG's blog:
https://abowman.org/2019/01/27/op25-on-rpi3-part-1/



Sunday, February 12, 2017

ARRL entry license survey

The ARRL recently announced an Entry Level License Survey:

http://www.arrl.org/license-1

I really would like to encourage folks to take it a step further and write their division director, as the survey doesn't let you convey much anyway.  Also they really need to have some feed back from non-members who feel might feel alienated and may otherwise given up on the ARRL in my opinion.   So don't feel shy about emailing someone even if you aren't an ARRL member.  This is still your hobby.

Not sure if the ARRL read my blog..  Just a few weeks ago I was thinking when are they going to think about creating a different license class.

Here is what I wrote my division director;

Hi Kermit (W9XA),

I’ve swapped some emails with your predecessor, Dick, W9GIG before. In light of the recent ARRL survey I figured I’d drop you a message in addition to the survey I have completed.

First off I at least someone is admitting/realizing there are problems despite a good turn out of hams entering the hobby each year.

I got into the hobby in high school in the mid 90’s.  I shouldn’t need to explain what the lures were then verses now.  When I show up at a VE session mostly to meet and congratulate the newbies, in the back of my mind I wonder what is the lure these days.  I have seen new guys show up off and on, and then a few years later you never see them again.

Anyway like I said from reading the survey page, seems someone besides myself is showing concern, which is good.  Quite frankly I have been a bit concerned for a while.  A lot of the regular members in my club are getting up there in age, and while I have taken over some things, I really don’t care to be doing everything.

While I may not know the solution, I can say it’s likely going to need to be more that just re-vamping the license structure etc.  But I think overall that is a good idea as part of a plan.  Keep in mind many younger folks are renting, so getting on HF even if their license would let them is still a bit out of reach.

I am not so sure the entry level privileges need to be more, but I do see the logic of some of the old novice class privileges.  So putting some restrictions on an entry class moving forward, and some trade offs, like access to some portions of HF with power restrictions like the old novice makes sense.  The entry test doesn’t need to be any less than it is now.  There has been enough of that over the years. We need more hams ready to dig into things.

I’d actually like to see a new class of license, geared more toward the experimenter.  The hobby desperately needs more people interested in something beyond just communicating and the social gathering aspects.

As you may be aware from conversations with Dick, I have been a proponent of some fairly large changes (as opposed to the classic piecemeal approach which takes decades to accomplish really anything major scale) to the rules mostly in terms of data, which I feel is the future.

I considered applying for STA.  Instead, I think an experimenter license class, that allows curtailed data/emission and other antique rules should be considered to help attract folks interested in developing the future.

Other things to consider include, widening the bandwidth for VHF/UHF data.  The stalled 2013 ARRL proposed to modernize the rules for data transmissions, really only helps HF.  I’d like to see 200 KHz for 70cm.  And maybe some thought to carving out more space on other less used VHF/UHFbands like 50 MHz or 220 MHz for something wider than presently allowed.

Consider maybe dropping or lumping Image emissions into the same as data? Since 1980, I am not sure “Image” makes sense, in light of the fact everyone has a computer now days.  So really the only difference there is the content type.  And regulating emission by content is screwy at best?  An area that needs thought for sure.

The best thing I have seen from the ARRL was the 2001 development of the HSMM working group.  While the working group got really no where with any of their proposed regulatory ideas, it started a movement that created some excitement.  That’s the main problem with the hobby. It needs fresh ideas, promoters, and folks to help clear any regulatory hurdles.  And then hopefully one day some small manufacturers to adopt the ideas in put the stuff in the hands of many as dictated by market demand.  I realize that is a lot to swallow. But this solicitation/survey for comments is always the first step, seeking and listening to many people's ideas/direction.

Another thing to consider is possibly a possibly co-funded (with TAPR?) big project.  The JARL helped bring about the D-Star spec.  And I have read about the European New Radio, multi-band, multi-mode DV radio initiative between the German and Austrian Amateur Radio Societies, which I believe is the DV4 line, hotspot and future mobile radio.

Rather than re-hash a lot of things, I’ll just leave you with some of my blog links to further explain, and expand upon things.  I hope you’ll take the time to review them.

http://kb9mwr.blogspot.com/2016/12/experimenter-license.html
http://www.qsl.net/kb9mwr/wapr/tcpip/amprnet.html
http://www.qsl.net/k/kb9mwr//projects/wireless/70cm-ATV-HSMM.html

In closing, feel free to google more about me and what I have been doing in the hobby the last 20 or so years as it seems the league is seeking some ideas on what someone under 30 interested in.  I’m now soon to be 38, and my greatest fear is that it will take till I am 50 for anything truly cool to come to the hobby.


73
Steve, KB9MWR

{update}
The July 2017 Entry Level License Committee report can be read here.