[aprssig] APRN news from Dayton!

[Stephen H. Smith]

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