Wednesday, December 31, 2014
Monday, December 22, 2014
like most Python code, this looks super-easy. ... almost magic....
de Scott / KD5NJR
Saturday, December 20, 2014
Date/Time: 05-Dec 17:41Z
R:141205/1824Z 4253@N9PMO.#SEWI.WI.USA.NA BPQ1.4.62
R:141205/1824Z @:JE7YGF.03.JNET7.JPN.AS #:30366 [Ichinoseki] $:1969_GB7COW
R:141205/1823Z @:7M3TJZ.13.JNET1.JPN.AS #:43652 [Sayama] $:1969_GB7COW
R:141205/1822Z @:CX2SA.SAL.URY.SOAM #:12999 [Salto] FBB7.00e $:1969_GB7COW
R:141205/1912Z @:VK2DOT.CC.NSW.AUS.OC [Niagara] #:33900 XSERV500f
R:141205/1741Z @:GB7COW.#44.GBR.EURO #:1969  FBB7.01.35 alpha
To : RPI@WW
To : RPI@WW
Using the Raspberry Pi and GPredict software to track Funcube-1 (or many other) satellites
start up a terminal window (LX Terminal). Then type
sudo apt-get update
sudo apt-get install gpredict
The Pi will then download and install the GPredict software for you and return to the commaind
once it has finished.
To start the software up, from your terminal window, simply type: gpredict
OR: main menu >> Run >> Type gpredict
The software will then start. You need to do a little configuration to tell the program where
(the default is Copenhagen where the author lives!).
73 de Mushtaq
VOA Radiogram this weekend (December 20-21) contains VOA and RFE/RL news items in MFSK32, including six MFSK32 images. That's almost like television.
Details at http://voaradiogram.net/post/105605797142/voa-radiogram-20-21-december-2014-six-mfsk32 http://voaradiogram.net/post/105605797142/voa-radiogram-20-21-december-2014-six-mfsk32
VOA Radiogram transmission schedule
(all days and times UTC):
Sat 0930-1000 5910 kHz
Sat 1600-1630 17860 kHz
Sun 0230-0300 5745 kHz
Sun 1930-2000 15670 kHz
All via the Edward R. Murrow transmitting station in North Carolina.
Wednesday, December 17, 2014
Sunday, December 14, 2014
Monday, December 8, 2014
Happened to have an opportunity to try a BeagleBone Black in a work application (worker timestation). Turns out that the performance web browsing is MUCH faster than the Raspberry Pi. Web pages are loading and rendering 2-3 times faster than the Raspberry Pi in the Chromium web browser.
I don't know that it will be a speed demon for floating point operations or graphically intensive applications, but certainly something to consider in your tool belt for certain applications that need a little more speed.
Some benchmarking to consider:
Thursday, December 4, 2014
Wednesday, December 3, 2014
Interesting observations on how to conserve spectrum by replacing conventional packet with PSK modes.
Note that they are using SSB instead of FM (to save spectrum) and AX.25 over PSK.
Our BPQ32 software actually uses ARQ over PSK, so I will be doing some testing to see the advantages/disadvantages of that versus conventional AX.25 frames. My gut feel is that the ARQ is more efficient, but would like to verify with tests.
Sunday, November 30, 2014
The Baofeng HTs have a 2.5 mm female connector for audio output (speaker) and a 3.5 mm female connector for microphone. The two connectors are designed to be plugged into a "remote" mic that can be placed on your shirt or belt buckle.
3.5 mm is the standard "1/8 inch" audio connector size that we use for consumer electronics, such as MP3 players. It is also the size used by most computer sound cards for either microphone or audio out. 2.5 mm is a non-standard size and is typically only used on cell phones.
I used two male to male adapters to complete the connection between the Baofeng HT and a SYBA sound card. One is a 3.5 mm to 3.5 mm adapter. The other is a 2.5 mm to 3.5 mm adapter, which can easily be found on Amazon.com. It is important to note that both adapters are 3-pole (meaning there are three sections, two black rings). Four pole adapters will not work with the Baofeng.
You end up connecting the 2.5 mm Baofeng connection (audio out) to your sound card microphone or line-in connection. The 3.5 mm Baofeng connection (microphone) is connected to your sound card audio out or speaker connection.
All of this completes the plumbing, but what about push-to-talk? That is the easiest, as Baofeng includes a "VOX" function that will key the transmitter whenever a certain audio level is detected on the microphone. All you need to do is turn the VOX function and set the VOX level to a comfortable speaking level. Test by speaking into the HT and adjusting accordingly.
After you get everything plugged in, start adjusting your sound card microphone and audio out levels. Be careful not to overdrive the output, or you will get a distorted waterfall. Same will be true if the microphone level is too high. If you go too low, the PTT won't engage or you won't see another station's signal on your waterfall. Always helps to have another friend that is running FLDIGI to start making the correct adjustments.
Typically I like to put an audio isolation transformer between the radio and the sound card, but this "shortcut" method will get you on the air. Since you are running FM, there is a little more forgiveness in the waterfall, as you will not be knocking off other stations like you would on SSB. Still, a highly distorted signal will not be copiable and will be hard on other station's ears, so try to get as close as possible to the ideal waterfall.
I ran all the way up to BPSK-1000 with good success between the two Baofeng HTs with this simple setup.
|Baofeng 888 series HT connected to SYBA sound card using|
male to male adapters (3.5 mm to 3.5 mm and 2.5 mm to 3.5 mm)
Saturday, November 29, 2014
Ideally, you should run FLDIGI on a computer with a microprocessor speed of 1 Ghz or greater. The Raspberry Pi only runs at 700 Mhz, so it has typically been overlooked or even discouraged as a platform for FLDIGI.
As I stated in the November 22nd training session, my past experiences with FLDIGI on the Raspberry Pi were mixed. It typically maxed out the processor and was sometimes unstable. Early attempts to use sound cards with the Raspberry Pi were also less than ideal, as the early soundcard drivers in Raspberian had difficulties with normal day-to-day audio, let alone modes that require high linearity. Early versions suffered from snap-crackle-pop sounds on both the output and input (if you used an external USB soundcard), which usually brought experiments in something like FLDIGI to a quick end.
I am pleased to report that the sound card drivers are more robust, plus the hardware solution of an SYBA SD-CM-UAUD has very low background sound levels and appears to get along with Raspberian very well, as evidenced by work by persons on the Dire Wolf APRS project.
So, I used this morning to revisit FLDIGI on the Raspberry Pi. I took a new Raspberian SD card, booted up, and entered "apt-get FLDIGI". Within 20 minutes I had FLDIGI and FLARQ icons in the Ham Radio program group.
The version of FLDIGI that is currently available via apt-get is several versions behind, so it does not have all the latest updates, like PSK-500, PSK-1000, or the KISS port.
So, I decided to connect the SYBA soundcard to my laptop (which is running the latest windows version of FLDIGI). Audio out to audio in on both sides.
After trying to run PSK-250 with some lockups, I decided to drop to PSK-125.
|FLDIGI and FLARQ running side-by-side on the Pi|
I was able to transfer several files between the two computers using FLARQ with no lockups or problems. In fact, I didn't have any errors on either side. Of course, all of this was with a "perfect" audio cable, as opposed to a radio-to-radio connection. However, it was a much better experience than what I had almost a year ago performing the same experiment.
There is a way to recompile the latest version of FLDIGI, FLARQ, FLMSG, and FLAMP on the Raspberry Pi. If you would like an SD card with all four on them, please comment below and I will go ahead and make some cards up (assuming there is interest).
|Close-up of FLDIGI on the Pi|
|Close-up of FLARQ on the Pi|
Monday, November 24, 2014
- You can use it for check for activity
- on a particular band: http://www.pskreporter.info/pskmap.html?preset&callsign=ZZZZZ&band=6000000-8000000&timerange=3600
- on a particular mode: http://www.pskreporter.info/pskmap.html?preset&callsign=ZZZZZ&mode=OLIVIA&band=6000000-8000000&timerange=3600
- or by a particular user http://www.pskreporter.info/pskmap.html?preset&callsign=kd5njr&mode=OLIVIA&timerange=3600
The new port operates at BPSK1000 at a center frequency of 1500 Hz on 145.03 Mhz FM.
The instructions previously given on this blog are identical, with the exception that you have to change the configuration file mode to BPSK1000 instead of BPSK250. Due to the nature of an FM signal, we opted to provide a speed that is comparable, if not a little faster than conventional 1200 bps packet.
Once you connect to the BBS, you can create outgoing connections to HF BPQ32 stations and conventional packet stations on 145.01 Mhz.
For those of you that do not have HF equipment, this is an excellent opportunity to try out the capabilities brought by marrying FLDIGI to BPQ32.
Next stop: APRS on FLDIGI!
Wednesday, November 12, 2014
Boy was he right. Plenty of signals in the waterfall. I worked stationed in IN, OH, ON, PA, OR and a W1AW/7 station in WA. Not bad.
All of these contacts were made using 3 or 5W on my dipole antenna. Mine is down low. It's below the roofline as a matter of fact.
It was later on in the evening, say, 9 or 10pm when I started to wonder "how low can I go?" Using the www.pskreporter.info website I turned the rig down to 1W and started calling CQ. I didn't work anyone, but I did pop-up on the website as being "spotted" in GA.
I have not worked any stations at the higher data rate, PSK-250, (regardless of power) besides Jeff. That's my next project.
- Wednesday night I did some prep work.
- Upgraded to the most recent version of FLDIGI ( downloaded from the FLDIGI webpage )
- Made a few test contacts with PSK-31 on 20m ( 14.070 MHz )to verify my mic and speaker settings were unchanged.
- Downloaded and installed BPQ (as Jeff mentioned in his earlier post)
- Thursday night we
- Made a few test contacts with PSK-31 on 20m ( 14.070 MHz )to verify my mic and speaker settings were unchanged.
- Downloaded and installed BPQ (as Jeff mentioned in his earlier post)
- Overwrote the configuration file for BPQ (as Jeff mentioned in his earlier post)
- Made a few changes to FLDIGI (as Jeff mentioned in his earlier post)
- When you bring up BPQ32 (It will bring up FLDIGI as well)
- open a terminal screen
- give the command : attach 5
- give the command : modem bpsk250
- give the command : c ae5me-15
- give the command : modem bpsk250
- To check mail
- give the command : BBS
- give the command : OP 20
//this will keep test transmissions of a reasonable length
- give the command L or LM
//one of these is LIST, on is LIST MINE
- if you see something worth reading, RM
- if you see something worth reading, R num
//num is the message number.
gives pretty good help.
- Try it out and have fun !!
- give the command L or LM
Sunday, November 9, 2014
It is real simple to set up.
1) Download the latest BPQ32 software from http://dxspots.com/BPQ32/Installer/BPQ32_22.214.171.124_20140818.exe. Run and install.
2) Download the latest copy of FLDIGI from http://www.w1hkj.com/downloads/fldigi/fldigi-3.22.01_setup.exe. Run and install.
3) Replace the BPQ32.CFG file with the following. Anywhere there is KD5NJR, change it to YOUR callsign. Verify that the path for C:\Program Files (x86)\Fldigi-3.22.01\fldigi.exe is correct, as the installed directory for FLDIGI varies according to operating system.
/* This begins a multi-line comment
CONFIGURATION FILE FOR BPQ32: G8BPQ SWITCH SOFTWARE
The purpose of this configuration is simply to confirm that the basic BPQ32
system is operable. It contains only a LOOPBACK port.
To perform the basic test, compile this configuration file by executing
bpqcfg.exe, which will generate bpqcfg.bin. Now execute BPQTerminal.exe, and
in the lowest window enter:
C 1 MYNODE v MYCALL
You should receive the following response:
MYNODE:MYCALL} Connected to MYNODE
This is the CTEXT.
MYNODE:MYCALL} CONNECT BYE INFO NODES ROUTES PORTS USERS MHEARD
If you get the above response the basic test has succeeded.
This file: \Examples\Minimal\bpqcfg.txt
*/ This ends a multi-line comment
;See LOCATOR details at:
; SYSOP Passord - See http://www.cantab.net/users/john.wiseman/Documents/Node%20SYSOP.html
NODECALL=KD5NJR-5 ; Node callsign
NODEALIAS=TDRNDE ; Node alias (6 characters max)
;BBSCALL=MYCALL ; Replaced by APPL1CALL following APPLICATIONS=
;BBSALIAS=MYNODE ; Replaced by APPL1ALIAS following APPLICATIONS=
IDMSG: ; UI broadcast text from NODECALL to fixed dest ID
TDRC BULLETIN BOARD SYSTEM.
*** ; Denotes end of IDMSG text
BTEXT: ; UI broadcast text from BCALL to destination UNPROTO=
TDRC BULLETIN BOARD SYSTEM.
*** ; Denotes end of BTEXT text
INFOMSG: ; The INFO command text follows:
BULLETIN BOARD SYSTEM COURTESY OF Tulsa Digital Radio Club.
*** ; Denotes end of INFOMSG text
KD5NJR-5 > Main Node for Tulsa metro and surrounding areas.
TYPE - I for System Information
TYPE - H for Node Commands
TYPE N for Routes to other Network Nodes
TYPE ? for Available Applications
*** ; Denotes end of CTEXT text
FULL_CTEXT=1 ; 0=send CTEXT to L2 connects to NODEALIAS only
; 1=send CTEXT to all connectees
; Network System Parameters:
OBSINIT=6 ; Initial obsolescence set when a node is included
; in a received nodes broadcast. This value is then
; decremented by 1 every NODESINTERVAL.
OBSMIN=4 ; When the obsolescence of a node falls below this
; value that node's information is not included in
; a subsequent nodes broadcast.
NODESINTERVAL=0 ; Nodes broadcast interval in minutes
IDINTERVAL=0 ; 'IDMSG' UI broadcast interval in minutes, 0=OFF
BTINTERVAL=0 ; The BTEXT broadcast interval in minutes, 0=OFF
L3TIMETOLIVE=25 ; Max L3 hops
L4RETRIES=3 ; Level 4 retry count
L4TIMEOUT=60 ; Level 4 timeout in seconds s/b > FRACK x RETRIES
L4DELAY=10 ; Level 4 delayed ack timer in seconds
L4WINDOW=4 ; Level 4 window size
MAXLINKS=63 ; Max level 2 links
MAXNODES=128 ; Max nodes in nodes table
MAXROUTES=64 ; Max adjacent nodes
MAXCIRCUITS=128 ; Max L4 circuits
MINQUAL=168 ; Minimum quality to add to nodes table
; INP3 Routing is experimental. The two parms which follow will be ignored
; unless activated in the ROUTES: section.
MAXHOPS=4 ; INP3 hop limit to add to tables
MAXRTT=90 ; INP3 max RTT in seconds
BUFFERS=255 ; Packet buffers - 255 means allocate as many as
; possible, normally about 130, depending upon other
; table sizes.
; TNC default parameters:
PACLEN=128 ; Max packet size (236 max for net/rom)
PACLEN is a problem! The ideal size depends on the link(s) over which a packet
will be sent. For a session involving another node, we have no idea what is at
the far end. Ideally each node should have the capability to combine and then
refragment messages to suit each link segment - maybe when there are more BPQ
nodes about than 'other' ones, I'll do it. When the node is accessed directly,
things are a bit easier, as we know at least something about the link. So,
currently there are two PACLEN params, one here and one in the PORTS section.
This one is used to set the initial value for sessions via other nodes and for
sessions initiated from here. The other is used for incoming direct (Level 2)
sessions. In all cases the TNC PACLEN command can be used to override the
; Level 2 Parameters:
; T1 (FRACK), T2 (RESPTIME) and N2 (RETRIES) are now in the PORTS section
T3=120 ; Link validation timer in seconds
IDLETIME=720 ; Idle link shutdown timer in seconds
; Configuration Options:
AUTOSAVE=1 ; Saves BPQNODES.dat upon program exit
BBS=1 ; 1 = BBS support included, 0 = No BBS support
NODE=1 ; Include switch support
HIDENODES=1 ; If set to 1, nodes beginning with a #
; require a 'N *' command to be displayed.
; The *** LINKED command is intended for use by gateway software, and concern
; has been expressed that it could be misused. It is recommended that it be
; disabled (=N) if unneeded.
ENABLE_LINKED=N ; Controls processing of *** LINKED command
; Y = allows unrestricted use
; A = allows use by application program
; N = disabled
AX25 port definitions:
The LOOPBACK port simulates a connection by looping input to output. To test,
start BPQTerminal and enter: 'C 1 MYNODE via MYCALL'
In this example '1' is the LOOPBACK port number. The LOOPBACK port is provided
for testing purposes and would rarely be included in an established system.
ADDR 127.0.0.1 7342 PATH C:\Program Files (x86)\Fldigi-3.22.01\fldigi.exe
ROUTES: ; Locked routes (31 maximum)
/* ; Begin comment block
MAXFRAME, Frack and PACLEN if stated override the port defaults.
INP3Enable = 1 enables, 0 or null disable. The INP3 (internode protocol)
implementation in BPQ32 is experimental. See additional details in bpqaxip.cfg.
Example of a route statement using INP3:
Locked routes tend to be overused and should not be set unless truly needed.
*/ ; End comment block
; No routes are specified, as they would be meaningless for this configuration.
*** ; Denotes end of locked routes
You can define additional Node commands that are available to your users. These may connect to
applications running on you computer, or be aliases or 'shortcuts' to other node commands.
For example you can define the command "BBS". This can either be set up to connect to a BBS running
on your computer, or to be an alias for a command that connects to a BBS on another system.
You can set up a callsign that if connected to will select the command, and if required cause the
call to be added to your NODES list.
The format is:
APPLICATION n,CMD,New Command,Call,Alias, Quality
n Application Number. You can define up to 32.
CMD The command the user types
New Command (optional) The Node command to be run
Call (optional) The call which directly invokes CMD
Alias and Quality (optional) If specified, causes an entry for Call and Alias to be added to your
NODES table with the specified Quality
APPLICATION 3,DX,C DXCLUS
Associated with each Application number is an applications mask. Most BPQ32 applications can be configured to
use any Application. An exception is AR-Cluster using the OCX interface, which must be Appl 1. Normally an Application Mask is configured in the application, rather than an Application Number. The following table gives
the Application Mask values:
Appl: 1,2,3,4,5,6,7,8, etc
Decimal Mask: 1,2,4,8,16,32,64,128, etc
Hexadecimal Mask: 0x1,0x2,0x4,0x8,0x10,0x20,0x40,0x80, etc
;APPLICATION 2,CHAT,,KD5NJR-11,MECHAT, 255
; In this example no applications are supported.
4) Run FLDIGI and follow the instructions for general configuration. Then configure FLDIGI as shown http://www.cantab.net/users/john.wiseman/Documents/FLDigiDriver.html. Make sure your squelch is set with the appropriate level in FLDIGI. Also turn on KPSQL.
5) Fire up the BPQ32 software and type "ATTACH 5" and return, then "C AE5ME-15" and return from the switch prompt. Make sure your radio is set to 7.036 Mhz USB and the FLDIGI software is set to 1500 Hz center frequency.
You should then get a note that you are connected to the AE5ME-15 node and can type ? to see the commands.
If you have any questions, email me at firstname.lastname@example.org . If you want even more information, be sure to sign up for our November 22nd training session.
Friday, October 31, 2014
PSK (including BPSK, QPSK, PSKR)
Recent tests with PSK on 40m have confirmed 80 mile NVIS contacts with power budgets of as little as 5 watts, making it an excellent narrow-band mode for messages of all types.
There will be hands-on training on the FLDIGI software, along with some demonstrations of its capabilities for messaging and file transfer. We will cover from hardware setup, initial software setup, all the way through good operating practices.
To provide the best learning experience for participants, we have limited the training session to no more than 25 attendees. Please RSVP ASAP to email@example.com to reserve your spot.
Thursday, October 23, 2014
Here's some quick info straight from Wikipedia:
KISS is a protocol for communicating with a serial terminal node controller (TNC) device used for amateur radio. This allows the TNC to combine more features into a single device and standardizes communications. KISS was developed by Mike Chepponis and Phil Karn to allow transmission of AX.25 packet radio frames containing IP packets over an asynchronous serial link, for use with the KA9Q NOS program.
Basically KISS eliminates the old "CMD:" prompt that we all grew fond of in the 1980s and 1990s on packet radio.
An article from 1987 by Phil Karn and Mike Chepponis introduces it by stating:
Standard TNC software was written with human users in mind; unfortunately, commands and responses well suited for human use are ill-adapted for host computer use, and vice versa. This is especially true for multi-user servers such as bulletin boards which must multiplex data from several network connections across a single host/TNC link. In addition, experimentation with new link level protocols is greatly hampered because there may very well be no way at all to generate or receive frames in the desired format without reprogramming the TNC.
The KISS TNC solves these problems by eliminating as much as possible from the TNC software, giving the attached host complete control over and access to the contents of the HDLC frames transmitted and received over the air. This is central to the KISS philosophy: the host software should have control over all TNC functions at the lowest possible level.
The AX.25 protocol is removed entirely from the TNC, as are all command interpreters and the like. The TNC simply converts between synchronous HDLC, spoken on the full- or half-duplex radio channel, and a special asynchronous, full duplex frame format spoken on the host/TNC link. Every frame received on the HDLC link is passed intact to the host once it has been translated to the asynchronous format; likewise, asynchronous frames from the host are transmitted on the radio channel once they have been converted to HDLC format.
Of course, this means that the bulk of AX.25 (or another protocol) must now be implemented on the host system. This is acceptable, however, considering the greatly increased flexibility and reduced overall complexity that comes from allowing the protocol to reside on the same machine with the applications to which it is closely coupled.
KISS quickly became the standard, and even was used by soundcard and other software to simulate a TNC.
WHAT SOFTWARE USES IT?
D-RATS (D-STAR "super" messaging and file transfer)
BPQ32 (Packet switch, messaging, chat, and APRS)
Winlink2000/RMS Express (message handling)
WINAPRS (Old APRS program)
UiView (Old APRS program)
So, as you can see, literally a whole new world of functionality has been opened by providing the "KISS" Port in FLDIGI.
We proceeded with testing at the higher 5 watt power level. PSK-250 was easy to copy. Both signal strengths were reading S9 at the end points (28 miles apart). S/N ratio according to the FLDIGI software was 28-30 db. I have been able to decode below 5 db on S/N ratio, but that usually with somewhere between 20-30% bad characters. From 10 db on upwards, copy is very good and only the occasional character may get lost. So the testing indicates we are a good 18 db above a reasonable cutoff point.
It is worth noting that the testing was conducted the evening after a fairly significant solar storm, so band conditions were fairly unfavorable.
Hopefully we will have additional lower power test data to share over the next few days from KD5NJR for comparison purposes.
All in all, this continues to validate the concept of using groundwave/NVIS on 30m or 40m to establish a network of PSK nodes, with minimal power required at each.
Monday, October 20, 2014
This is an incredible breakthrough for FLDIGI, as it opens up its use for APRS, conventional keyboard to keyboard packet, and even the advanced messaging technologies in the D-RATS software package.
In the case of the TDRC, we were able to successfully interface FLDIGI to our BPQ32 packet bulletin board system. Instead of using the 30 year old technology of 1200 bps packet, we now have the ability to move data using the latest modulation schemes in PSK, FSK, and many, many others.
We have now placed a second HF rig at the TDRC BPQ32 BBS site and will be interfacing it to the FLDIGI software in the next few weeks. An announcement will be made once the system is online. Our plan is to select a band that is easily worked on HF (perhaps 40m or 30m) so that the system will have coverage over NVIS distances (typically 300-500 miles).
If enough of you have interest, we might even put a D-RATS port up for fun. Drop me a line at AE5ME@yahoo.com if you would like to see D-RATS on FLDIGI.
For those of you that were interested, there was another test performed on 30m and 40m to establish additional supporting data. The good news is that we confirmed groundwave/NVIS distance of 28 miles with no problems on either 0.5 watts or 5 watts. The bad news was that the receiving station near Claremore (KC5SHE) was operating using a hand microphone, instead of the traditional rigblaster setup. That posed some challenges with the background noise from the room, so none of the measurements will be posted at this time, as the variances were pretty high.
We are looking to do another test this Wednesday, October 22nd. Looks like KC5SHE will have his Rigblaster running at that time. That should give us results that will be repeatable and worthy of being published.
For those of you that would like to participate, here are the specifics:
6 PM (7036 khz, 1500 hz center frequency)
Wednesday, October 1, 2014
Lack of line-of-sight caused VHF to be unusable at the 28 mile distance, especially with the ridge line between Jeff AE5ME and Scott KC5SHE, which is approximately 20 feet taller than either antenna. Attenuation on the order of 100 db is probably occurring. Situation did not change whether station was running 0.5 watts, 5 watts, or 75 watts. Guessing that usable distance will probably be on the order of 5-10 miles tops at 20 foot antenna elevations. This is common on 2m simplex, so it confirms what we originally believed.
The real magic occurred on ground wave on both 30m and 40m. It one word it was excellent. 30m was a more quiet band, but also a very narrow band to operate within. Easily can obtain good copy of the signal out to 28 miles. The 1.75 mile signal was essentially "full quieting". Ridgeline essentially had very little impact on the signal strength. Similar results on 40m, but also a lot more noisy from other sources, such as DX and shortwave radio stations adjacent to the band.
Between 30m and 40m, I think we are finding a band with decent propagation characteristics, that will keep us from having to use the traditional 250 foot or above tower to build a digital network. That has been the traditional issue that kept traditional 2m packet from being continuous coverage.
All tests were conducted with some version of PSK, whether it be 125, 250, or 500. Did some -1000 in short bursts, as well.
Tuesday, September 23, 2014
If you have equipment, you are welcome to participate. Here are the details:
Saturday, September 6, 2014
I've always wanted to do APRS on a Raspberry Pi. It's low power consumption plus low cost makes it an excellent solution. Most dedicated trackers run $50-100 depending on features. I think the KPC-3 from Kantronics is still over $100 new.
Raspberry Pi is $40. Add a USB sound dongle at $8 and you can see how it is very attractive financially. Not to mention the ability to interface something like the Arduino to it for telemetry work. Write something in Python or C and you have a very customizable box.
The main barrier to running packet/APRS on a Raspberry Pi has been the lack of good experience with sound card modems on it. Conventional wisdom has been that it doesn't have enough horsepower to handle the DSP routines required to decode packet and other modes (like PSK31, etc.)
Step one was getting a USB soundcard. Courtesy of Amazon, I was able to buy a unit pictured below:
Step two was connecting it to the Pi through my USB hub with an ancient Radio Shack scanner tuned to 144.39 (APRS frequency). Audio output from the scanner was connected to the Mic input line on the sound card dongle.
I'll need to make up some more cables to tie to a Baofeng transciever. The Dire Wolf software provides a KISS port on 8001 for most of the popular APRS packages like APRS-IS, Xastir, BPQ32 etc. to use, so that makes it super convenient.
I've been reading about the ability of the Raspberry Pi to generate up to 200 Mhz signals using PWM on the GPIO pins. With a mixer, good filtering section, and a decent amplifier section, maybe the Pi becomes its own transmitter and receiver. Sounds like a good idea for a TDRC "We make it better" project......
Monday, September 1, 2014
Sunday, August 31, 2014
For those of you that didn't make it out, I made a display of using the analog I/O capabilities of the Arduino Esplora to drive a packet TNC to put telemetry and message packets out over APRS. The Arduino and packet TNC were both connected to my laptop computer on the USB ports. Scott KD5NJR then pulled up my information and displayed it on his laptop that was running APRSIS.
While unloading the Arduino today, decided to take the plunge and interface the Raspberry Pi with the Arduino. The Pi is a great computing environment with all of the capabilities of a fully-featured LINUX box-- not to mention the Python environment for programming. However, the inputs and outputs are digital. So, you need to put some type of analog to digital converter between it and traditional analog devices, like resistance thermal devices or temperature sensors.......On the other hand, the Arduino is stricly command line based and not much for graphical user interface or the like. But is has plenty of input and output lines for analog work! Even better, the Arduino Esplora has a light sensor, temperature sensor, joystick, push buttons, leds and even a built-in accelerometer.
So, to leverage the best of best worlds, I connected the Raspberry PI to the Esplora board like this:
You will notice that I used the USB hub between the Pi and the Arduino. The Esplora board is powered off the micro-USB connection, so it's important to have another source of power so that you don't end up rebooting the PI due to excessive current draw. Plus it allows the keyboard, mouse, and wifi USB connections to be made (since the original Pi only has two USB connections).
Once I pulled up Mincom terminal program and told it to go to the ACM0 serial port (which is the first USB com port) running 9600 bps, my APRS data program started streaming across the Raspberry Pi screen.
So, a Python program using the serial library should be easy to talk and listen to the Arduino. That will be my next project.....There is some neat stuff we could do have the Pi do the web serving and the Arduino doing the I/O.........
Tuesday, August 26, 2014
- Located the radio, power cord and whip antenna among the stuff we took on vacation.
- Found the radio / computer interface.
- Started the UZ7HO soundmodem program
- Verified I had UZ7HO set to listen to the external mic jack on the laptop.
- Verified I was getting audio from the radio into the computer by looking for "noise" on the UZ7HO waterfall when I cracked the radio's squelch.
- Verified Windows and UZ7HO agreed with what COM port the radio interface was set to.
- Set the radio to PKT mode. (Yaesu)
- Finally I set the radio to 144.390 Mhz. I also set UZ7HO for 1200 baud. In a moment I saw the text of APRS packets.
It didn't take me long to get UZ7HO talking to the APRSIS32 mapping program. After a while I was satified that APRS was working. So I tuned the radio to 145.01 Mhz.
For "packet radio" I used the EasyTerm program that bundled with Soundmodem ... more on packet later.
- 1. Originally developed in the late 1970s.
- 2. It's an example of a "store-and-forward" network.
- 3. The underlying protocol AX.25 is an adaptation of the old X.25 protocol. ( compare it to the Internet's TCP/IP )
- 4. A TNC connects between your radio and computer. Think of it as a cross between a modem and an Ethernet card.
- 5. Digipeaters receive weak packet and re-transmit it for others to hear.
- 6. A 'node' is a more intelligent digipeater.
- 7. Some TNC firmware contain a small BBS where messages can be left.
- 8. You can leave a message in a distant friend's BBS by using digipeaters and nodes.
- 9. There are still full-service BBSes out there with forums, chat and file transfer capability.
- 10. You can leverage packet radio's infrastructure to communicate with your project at a distance.
Monday, August 25, 2014
CALLING ALL MAKERS!
Tulsa's second annual mini-Maker Faire is this Saturday, August 30th from 10 AM to 6 PM at the Tulsa County Fairgrounds. TDRC will have a display featuring the use of APRS to transmit position and telemetry data. We should have at least one tracker on site and a computer that will display stations on a Tulsa map.
This will be a good opportunity to meet the TDRC crew and ask questions about our projects. We will also have two Raspberry Pi computers as door prizes, so be sure to stop by our booth and sign up!
For more information about the mini-Maker Faire, go to this hyperlink: Tulsa_Mini_Maker_Faire.
- 1. Automatic Packet Reporting System developed by Bob WB4APR for real-time data.
- 2. There is a world-wide network of APRS "digipeaters" that boost the signal of APRS transmitters. ( in North America, the network is on 144.390 MHz )
- 3. Numerous "i-gates" allow APRS messages to cross back and forth from the Internet-based APRS-IS network to the conventional (radio-based) APRS network.
- 4. Several websites provide a convenient interface to the APRS-IS network.
- 5. APRS client software exists for a variety of operating systems.
- (java) YAAC : http://www.findtheater.com/ka2ddo/YAAC.html
- (windows) APRSIS32 : http://aprsisce.wikidot.com/
- (linux) XASTIR : http://xastir.org/index.php/Main_Page
- Android and iOS apps available too.
- 6. APRS has been used for
- SMS-like messaging, http://w5drz.org/sending-a-message-from-the-internet-to-rf-aprs-users/ http://aprs.fi/?c=message&call=
- vehicle tracking, http://aprs.fi/moving/
- weather stations,
- and even telemetry from balloons,
- and space craft.
Monday, August 18, 2014
- We worked about 15 stations including:
- N5TEX Joe in Sand Springs
- WB5VST Ben in Skiatook
- The Emergency Operations Center in Tulsa WT5EOC
Reading between the lines, that means that there is no technology between the two radio users. No repeaters or ways to boost a signal. Just two radio users with a clear line of sight to each other.
So, a couple of us went out to find "high ground" from which we could communicate with many "hams". In the photo, you can see one of many ridges in Tulsa where you can have a good time playing "walkie talkies".
Tuesday, July 8, 2014
- What's "ham radio" ? ...amateur radio operators are interested in the development and use of many different types of radio technology to communicate in all types of environments between both people and machines.
- "Hams" can use much higher power and many different technologies to send and receive digital and analog information over much greater distances.
- An amateur radio operator is part of a group of technology oriented people with decades of experience in solving challenging problems
- They have a burning desire to share that knowledge to help create new solutions.
YOUR NEXT PROJECT or ADVENTURE !!
What can you do with "ham radio" ? ...with the appropriate licenses, hams can transmit analog data (namely speech) in AM or FM formats. Hams can also send in digital ( Morse Code , serial data, etc.) also. This means you can send remote control commands, telemetry, images, speech in your projects and to communicate with other Makers locally and worldwide without commercial communications infrastructure (telco, cell, cable, etc.)
WHO can you talk to with "ham radio" ? ...hams come from all walks of life. Many hams are in the sciences and engineering. Many build their own ("homebrew") equipment. A subset of the hobby, QRPers, focus on small, portable, low power equipment.
WHAT can you talk to with "ham radio" ? ... Model airplanes and gliders (commands up, telemetry down) ... High-altitude balloons (imagery and telemetry down) ... Satellites, the International Space Station (and formerly the Shuttle) ... Ocean buoys
What's next ? ... Robots ? Other kinds of remotely operated vehicles ...
YOUR NEXT PROJECT or ADVENTURE !!