Portable Go Box

>> This is an nice post by VE6AB, the same author that had the article on
>> HF APRS in the last QST.
>>
>>   http://ve6ab.blogspot.ca/2015/10/scs-trackerdsp-tnc-for-hf-aprs_18.html
>>
>> My DSP TNC is on order.  Looking forward to exercising it on all band
>> with all modes once it arrives.

> Are you going to put it in your car, your boat or plane? What radio are you going to use?

The plan now is to build it into a portable communications Go box.
It'll have the good old ICOM IC-706Mk2, a small switching power
supply, manual tuner and basic netbook for controlling the radio and
talking to the TNC.

So the next time I'm visiting Montana or Seaside I should be able to
check in to the Traffic Net or Noon-Time-Net or voice, run Robust
Packet for tracking on 30 meters and access the local 9600/1200 packet
infrastructure on VHF/UHF.

It's a fun little project that may turn out to be very useful...

AP510 Tracker

Better all the time.   Radio, GPS, TNC, memory, thermometer, etc etc.   All for around $100 with Amazon Prime shipping.

Perhaps this will be the Ham Radio side of the Montana Lander...


2015-2-7  AP510 arrived at Zeus.  Downloaded files from the Yahoo group.  Watched helpful 9 minute video by Eric/KI4xxx - on how to configure hardware and software.
   *

Alternate download location for AP510 files

2015-2-8 Watched video again.  First pass at configuration.  Fortunately there were no issue on DLL's or serial drivers with my dated Vista laptop.

Visited 8GNJ - helped him set up his AP510.  His went fine - mine started acting weird.

Reinstalled Firmware in mine.  Now it's happy and acting normally.

2015-2-9 It's running.  Light turned solid blue for the first time while sitting on the car's dash.  Apparently that indicates GPS lock.   Note to self.  Beacons and beeps every 15 seconds is a bit much.  Reconfigure tonight to turn off beep and set transmission to nice sane 2 minutes.

2015-2-10  Reconfigured.  Changed SSID from -4 to -5 to be in sync with Herb.  The -5 is for 510..  Set beacon time to 125 seconds.  Turned off the beep.   Next time - turn off MIC-E to see what it looks like.  MIC-E is much shorter which is a good thing but we're curious how the packets are going to look.

All the Audio

We have big CPU's and bigger hard disks.  There's no reason today to not record (compressed) ALL the audio from a data channel.  In particular - APRS - with its wide mix of stations and applications.

Here's a twist on the web pages - instead of "Map Me" how about - play back what my packets sound.

APRSTT - Touch Tones

Using touch tones to do APRS:

• http://www.aprs.org/aprstt.html
• http://www.aprs.org/aprstt/aprstt-v.txt - the spec
• https://www.tapr.org/pdf/DCC2010-APRSSpeak-KA2UPW.pdf - implementation
• http://info.aprs.net/index.php?title=APRStt - the APRS wiki

Touch tones?   Why not use voice input?  As long as a raspberry pi has Internet access to Google, it should be fairly straight forward to replace the touch touch responses with speech commands.

http://www.raspberrypi.org/meet-jasper-open-source-voice-computing/

APRS-IS2 The Next Generation

At much discussion and debate on the International APRSSIG it's been decided to move ahead with the next generation APRS Internet Infrastructure. Some core changes will improve system security, stimulate development of Amateur Radio tools and discourage reliance on Internet Connected Land-Line technologies.

First new core concept is that there will no longer be any non-RF activity allowed to be directly submitted to the APRS-IS2. If it's on the list - it will come from RF.

Second change is a new signed and accepted by a Web-Of-Trust agent will be the only tool allowed to inject traffic to the APRS-IS2. This new tool will be developed and implemented as soon as possible.

Third, some exposure to the magic of the Amateur Realm for non Hams and Internet connected stations is a good thing. This Read-Only technology will be preserved with the old applications but it will be limited to one random packet per minute. This will be a sample of what's available and folks that want more can get it on RF.

Once this is in place we can move on with new smarter systems and Ham Users will never again need to do 'paths'

Onward to the Beyond!

73,
Bill

MRTG running

Yeah - we're back...   Many years ago we had MRTG graphs for the various Wetnet LANS.   Now, thanks to our little TCP on packet project and the addition of SNMP info in JNOS - we're once again collecting and plotting data.   This is the 9600 baud UHF APRS channel in the Puget Sound region...

I should have waited a couple days to get better charts with more data - but what the heck - it's cool to have these running again.   It's not live on the internet - internal only for now..

Now to figure out how to do this on the NW-MESH boxes.   Let's see if we can move the left column from Bytes per Second to Megabytes per Second..

UI-View TNC Config File for 96UHF

The UI-View program works well with the Kenwood D7 HT.   So well, it even sets the frequency at startup time.   The beauty of this is that it allows setting up different configuration files for different channels and, it turns out, for different baud rates.

Editing the stock file to create a new configuration file for 145.01 was trivial and only a matter of changing the frequency setting.

Moving to 96UHF, where not only the frequency but also the band and baud rate changes, was a bit trickier.

Fortunately, before I had to spend too much time discovering the silly little things that thrive on eatting our minutes, I found the SV1BSX  web page were he already had it figured out.

  http://www.qsl.net/sv1bsx/APRS/d7-9k6.html


This is working for me now.  I'm sure there will be future tweaks..

Here is the text for a 96UHF.cmd file to be saved in the ui-view\cmd folder:

;This is a TNC initialisation file for use with
;the Kenwood TH-D7 on the NWAPRS 96UHF 9600 baud APRS on 440.800 MHz.

;
;TH-D7.ORG will allow you to revert to the default
;version of this file, if you edit it and mess it up!

[SETUP]
;DON'T alter anything in this section unless you are
;sure you know what you are doing!
COMMAND_PROMPT=cmd:
COMMAND_CHARACTER_CODE=3
ESCAPE_CHARACTER_CODE=
CONV_COMMAND=CONV
MYCALL_COMMAND="MYCALL "
UNPROTO_COMMAND="UNPROTO "
NO_BEACON_COMMAND=BEACON EVERY 0

[INIT_COMMANDS]
^C
AI 1!
;Control mode on.
TC 1!
;Select packet mode.
TNC 0!TNC 0
;Select band 'A'.
;sELECT band B for 9k6
BC 1!BC 1
;Set the frequency to 440.800.
FQ 00440800000,0!FQ 00440800000,0
;No shift.
SFT 0!SFT 0
;Select data band as 'A'.
DTB 1!DTB 1
;Open the TNC in packet mode. Wait for up to 4 seconds
;for PORTOUT to be seen in the response from the TNC.
TC 0!PORTOUT!4
;Send some TNC commands.
ECHO OFF
HBAUD 9600
AWLEN 8
BEACON EVERY 0
MON ON
MCOM ON
CONOK OFF
LTMON 10
LOC E 0
GPSTEXT $GPRMC

[EXIT_COMMANDS]
MON OFF
;Close the TNC.
TC 1

APRS at 9600...

> In the Pacific Northwest, there are a number of people experimenting
> with 9600 baud APRS. They have a reasonable network of i-gates and
> digipeaters. They've shown a couple of things: 9600 baud works for
> APRS; it can be more reliable for mobiles (less chance flutter will
> corrupt the packet, because the data burst is so short); and it ends
> up doing more for the network than halving the bandwidth because it
> moves a lot of stations off 144.39 and onto an alternate channel. Most
> of that network is Kenwood D700's, D710's, D7's and D72's.
> Tom

Following up on Tom's comment above...    I've been almost exclusively on the PNW UHF 9k6 APRS network for years and years.   In general -- it's great to get off the chaos of 144.39 and the system is working better than every with multiple I-Gates and digipeaters.

Messaging just work's as long as you have a real I-Gate or two.   What doesn't work is Voice Alert.   We've worked around that by bringing a significant portion of the local 144.39 traffic to the UHF network. Also I sometimes run with my second VFO on the Tone Squelched 144.39 channel just to see if anybody is in range.

It's really nice to have the extra bandwidth for more information... We have DX spots of 6 meter openings, satellites, winlink2K access points and the echolink/irlp nodes in the area and room for more.

As to TXdelay - ideally it would be a bigger win but since the D700 is fixed at 1/2 second (silly Kenwood) it is far from optimum.  With the light traffic load it's apparently a non-issue.

While 9600 is cool and it's trivial to set up with the Kenwood mobiles PM feature, I recommend to anybody that asks to not use 9600 buad.

Two reasons:

1.  The data you can see on a mobile radio is the rate limiter.  With a full 1200 baud channel the display too busy and distracting. Anything beyond that from a faster 9600 channel is just unusable. 9600 would work good for a backbone but not a 'user channel.'

2.  If the goal is to help spread the load from the busy 144.39, you don't want 9600 - you want 1200 which all the trackers use.  Moving the dumb trackers off the main channel onto an alternate frequency is good for both the trackers and the main channel.  Since the trackers aren't running Voice Alert, they're the ones that can run there without missing this incredibly useful APRS feature.

> Why would using a subtone suddenly not work when changing the baud rate?

Two issues with the tone .. I should have been more clear.

1. The affect of the tone on 9k6 data is an unknown.

2. Stations on the alternate channel don't hear the other stations on
the main channel... It would work if everybody moved. It doesn't
work cross channel.

The big win is the alternate channel to spread the load which only takes an I-gate or two to make happen.   Add digi's as necessary...

73
Bill - WA7NWP

Crank up the power!! - nwaprs sig posting

> Placed order for a MT-8000FA on Wednesday, it arrived today

There seems to be a significant number of folks getting these new
tracker units. While it's always great to see new technology hit the
streets, this is one place where it's a real step backwards. Despite
comments that a system with a receiver was coming, they continue to
release new products that cannot tell if they're transmitting at the
same time as other stations.

In the early days of packet, these systems would have been tracked
down and had their coax pinned...

It looks like one hope for the rest of us is to compete is to get
amplifiers or go to the high power settings with our existing systems.

This is unfortunate because it's so contrary to good amateur practice
and what ham radio should stand for. It's another example of the
tragedy of the commons that Bob B. talks about in:
http://eng.usna.navy.mil/~bruninga/aprs/fix14439.html
" Whenever there is a balance between individual interests and the
common good, human nature guarantees the overloading and ultimate
demise of the common resource."

Personally - I think I'm just going to start treating the stock APRS
144.39 channel like the CB it is becoming. It's relatively useful out
on the road but suffers from a far too low signal to noise ratio
around the cities... There is lots of interesting packet that can be
done on 9k6 or the data and emcomm 1200 baud channels. This is also
a good excuse to start making use of 6 meters since it's that time of
year... I'm going to miss voice alert but I think we can come up
with some even better alternatives.

Onward through the fog...

Bill - WA7NWP

PS. Note what Riley said quoting Bill Cross: -
http://www2.arrl.org/news/stories/2007/06/01/100



"Cross cited §97.7 of the rules, which requires each amateur station
to have a control operator and, in essence, to employ a
"listen-before-transmit" protocol.""