[aprssig] APRN news from Dayton!
Stephen H. Smith
wa8lmf2 at aol.com
Mon May 23 17:55:55 EDT 2011
On 5/23/2011 12:39 PM, Rud Merriam wrote:
>
>
> A further thought is to take damage pictures with cell phones or cameras.
> They would be transferred to a laptop / net book and sent back to the EOC.
>
> I haven't looked into how to do the picture transfer. One possibility is
> EasyPAL on 70 cm to attain a higher transfer rate.
The biggest problem is the vile and obnoxious locking down, by cellular
carriers, of cell phone capabilities built-in by the phone's manufacturer.
Most cell phones have the capabilities to transfer pics taken by their cameras
to a computer via a USB cable. However the carriers disable this feature in
the phone's operating system to force you to email/transfer the pics
over-the-air using expensive (and profitable) MMS (Multimedia Messaging
Service), and to force you to buy ring tones over-the-air from their store
(rather than uploading your own sounds directly from your own computer). On
some phones, it's a fairly easy hack of the phone firmware to re-enable local
transfers to/from a computer (an activity known to cell carriers as
"side-loading") On others, not so easy.
Of course, you won't have this problem with a "real" digital camera.
EasyPal's built-in TWAIN support will let you pull pics directly out of a
camera's flash memory, if it supports WIA (Windows Image Acquisition), a
standard feature of Windows XP and later. Most cameras made in the last 5
years or so do support WIA. You normally DO NOT need to install the camera
maker's massive, clunky and sludgy support software usually provided on a
CD-ROM with the camera. Just plug the cam into a PC with a mini-USB cable,
and the camera's memory contents will "automagically" appear as a new virtual
disk drive at the bottom of the Windows File Explorer tree.
The transfer rate won't be determined by band - rather it's an issue of:
1) Downsizing the original multi-megapixel image to something like 600x800
SVGA or 640x480 standard VGA.
2) Choosing how to trade off image quality vs level of JPG compression.
EasyPal offers both options each time you load a pic for transmission. There
is actually a slider control under the TX image window that lets you choose
how many seconds of transmission time the image should use. As you pull the
slider, you get a WYSIWYG preview of the image degradation caused by more
compression for shorter transmit times.
About a year ago, I had several rounds of email correspondence with the author
of EasyPal and broached the idea of integrating APRS into the program.
My concept was that since the program already transmits meta-data (i.e. it
embeds the call of the sending station, sending mode, source file name and
free-form text comments in digital form in the container holding the file
image), it should be quite simple to have the program also parse GPS data from
a local com port and embed an APRS-format position report in the meta-data.
At the receiving end, EasyPal could extract the position report and present it
to an IP port or virtual COM port, ready to be passed to a normal APRS mapping
application. Since EasyPal already contains a quite sophisticated built-in
FTP system that can automatically upload received pics and text comments to a
web site, it would be a small additional step to have it screen cap a map image
from an APRS app and FTP that too as a second image.
At the time, he seemed quite intrigued by the possibilities but then apparently
forgot about it while dealing with more immediate problems arising in the
program. Perhaps I should bring this thing up with him again.
One should also be aware that operation with EasyPal is not the same effortless
"jam-audio-into-the-mic-jack and go" undertaking that classic analog SSTV is.
Conventional analog SSTV uses a single frequency-modulated
constant-amplitude audio tone. The send level is not critical for the most
part. Even if you insert the tone into the mic jack at a level that massively
saturates the radio's deviation limiter, the resulting distortion has little
effect except to make the transmitted signal a little wider.
The EasyPal system uses 16 or 64 SIMULTANEOUS QAM audio subcarrier tones. The
send audio level is critical, similar to operating on PSK31. Too much audio
will create massive inter-modulation distortion if the deviation limiter starts
clipping, resulting in high bit-error rates and failure to receive anything at
all.
I have done a lot of testing with EasyPal on different radios and sound card
devices, and find that you have to work to keep IMD down at every step in the
TX-to-RX chain for the best and most reliable results.
1) The sound card should be outputting at about 2/3rds of it's maximum output
level to optimize the SNR and to swing the waveform over a large number of
D-to-A converter steps to minimize distortion of the synthesized audio waveform.
2) Whatever this level winds up being, it then needs to be padded down at the
sound card interface or mic jack so that the TX deviation is about 2.0 to 2.5
KHz on most radios (assuming a normal 5KHz peak NBFM radio) for the most
reliable results.
[Many TX modulators in FM radios start becoming surprisingly non-linear as you
raise the deviation above about 50% of max -- not noticeable much on voice but
disastrous to complex data waveforms. At the receive end, the same is true of
many FM discriminators. Further, if you are going to pass these transmissions
through repeaters, the original level needs to be set low to allow for possible
mis-matched repeater RX-->TX audio levels that cause the outgoing audio to be
higher than the original input levels. Again, you have to avoid hitting the
dreaded deviation limiter in the repeater TX.]
3) At the RX end, the audio recovered from the discriminator or speaker needs
to be padded/attenuated/boosted/adjusted to a level that will allow the RX
sound card to be running at about 2/3rds of max gain, again to maximize the
resolution of the A-to-D converter.
It's not difficult to set, IF you have a deviation monitor and scope, but it's
not something you will be doing at the last minute in the field.
Further many of the brain-dead el-cheapo motherboard-based sound
systems in cost-reduced PCs are very mediocre performers for this more
demanding mode. Often, you will need to use an external USB-based sound
system such as I review here:
<http://wa8lmf.net/ham/imic.htm>
Bottom line: You have to mate up AND TEST TEST TEST computer sound systems,
sound card interfaces and specific radios (and set audio levels) in advance.
It just won't be the kind of ad-hoc cludge that analog SSTV lets you get away.
Typically in commercial & public safety mobile-data systems, you are
dealing with fleets of hundreds of identical model radios mated to identical
model modems. In the ham environment, you most likely will be dealing with a
dissimilar hodge-podge mix of computers, sound cards and radios.
-------------------------------------------------------------------------------
--
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: WA8LMF or 14400 [Think bottom of the 2M band]
Skype: WA8LMF
Home Page: http://wa8lmf.net
===== Vista & Win7 Install Issues for UI-View and Precision Mapping =====
http://wa8lmf.net/aprs/UIview_Notes.htm#VistaWin7
*** HF APRS over PSK63 ***
http://wa8lmf.net/APRS_PSK63/index.htm
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths
More information about the aprssig
mailing list