Wireless image transmission over walkie-talkie; has this
been done? Clearly the camera cell phones have the
option of transmitting images, I am curious if you can modify a
toy walkie talkie radios for general digital data transmission
in a similar way?

Ben

wrote:
Wireless image transmission over walkie-talkie; has this
been done? Clearly the camera cell phones have the
option of transmitting images, I am curious if you can modify a
toy walkie talkie radios for general digital data transmission
in a similar way?
I am sure you could

legal note make sure it is low powered toy if you want it legal
but something like a rig blaster should do it if you have jacks on the
wt even just plug cord off the sc with the software if you do the PTT
keying by hand

Ben

Its EASY! Been done for years!
wrote in message
ups.com...

Wireless image transmission over walkie-talkie; has this
been done? Clearly the camera cell phones have the
option of transmitting images, I am curious if you can modify a
toy walkie talkie radios for general digital data transmission
in a similar way?

Ben

Hi Ben

Modifying the walkie talkie itself is probably way too cost prohibitive.
It is much cheaper to use a PC (eg laptop or maybe PDA) to do the
necessary encoding/decoding of digital information. I'd suggest a
soundcard interface rather than purpose built hardware like a TNC. You
can even acoustically couple but you may have to lower the data rate some.

Your next hurdle will be the much lower data rate of an essentially
voice bandwidth radio and thus the slower transfer of images/data.
Without a huge amount of trouble you may get 1200-2400 bits per second
on a voice FM circuit. This works out at around 100-200 characters per
second which for an average 640x480 lowish quality JPG image (say 30K
bytes) as taking quite a while to transmit. (Say 3-5 mins)

Cell phones have a much higher data rate and in fact encode audio into a
digital stream. I'll admit I dont know what the rate is but think 3G is
around 2MBit/sec max!

You could no doubt modify the walkie talkie modulation method and
bandwidth to get better rate but I doubt it would be worth it. I'll not
mention the legal implications of doing this! If you really want to play
have a look at the ISM bands like 2.4GHz. In the US at least you can
even build your own equipment that conforms to this "unlicensed" band.
There are even chips available to make it easier.

There is lots of GPL software around that will encode/decode an audio
stream to/from data and even key the TX. If you want some names/refs pls
post your request.

Cheers Bob VK2YQA


wrote:


Wireless image transmission over walkie-talkie; has this
been done?

Bob:

I agree, its not worth modifying the walkie talkie if a
data-to-voice encoder and voice-to-data decoder exist
that can reasonably transmit over a walkie talkie's
channel. Would love to review some of references on
software or studies done already. Thanks so much in
advance.

Ben

Bob Bob wrote:
Hi Ben

Modifying the walkie talkie itself is probably way too cost prohibitive.
It is much cheaper to use a PC (eg laptop or maybe PDA) to do the
necessary encoding/decoding of digital information. I'd suggest a
soundcard interface rather than purpose built hardware like a TNC. You
can even acoustically couple but you may have to lower the data rate some.

Your next hurdle will be the much lower data rate of an essentially
voice bandwidth radio and thus the slower transfer of images/data.
Without a huge amount of trouble you may get 1200-2400 bits per second
on a voice FM circuit. This works out at around 100-200 characters per
second which for an average 640x480 lowish quality JPG image (say 30K
bytes) as taking quite a while to transmit. (Say 3-5 mins)

Cell phones have a much higher data rate and in fact encode audio into a
digital stream. I'll admit I dont know what the rate is but think 3G is
around 2MBit/sec max!

You could no doubt modify the walkie talkie modulation method and
bandwidth to get better rate but I doubt it would be worth it. I'll not
mention the legal implications of doing this! If you really want to play
have a look at the ISM bands like 2.4GHz. In the US at least you can
even build your own equipment that conforms to this "unlicensed" band.
There are even chips available to make it easier.

There is lots of GPL software around that will encode/decode an audio
stream to/from data and even key the TX. If you want some names/refs pls
post your request.

Cheers Bob VK2YQA


wrote:


Wireless image transmission over walkie-talkie; has this
been done?

Bob:

I agree, its not worth modifying the walkie talkie if a
data-to-voice encoder and voice-to-data decoder exist
that can reasonably transmit over a walkie talkie's
channel. Would love to review some of references on
software or studies done already. Thanks so much in
advance.

Ben

Bob Bob wrote:
Hi Ben

Modifying the walkie talkie itself is probably way too cost prohibitive.
It is much cheaper to use a PC (eg laptop or maybe PDA) to do the
necessary encoding/decoding of digital information. I'd suggest a
soundcard interface rather than purpose built hardware like a TNC. You
can even acoustically couple but you may have to lower the data rate some.

Your next hurdle will be the much lower data rate of an essentially
voice bandwidth radio and thus the slower transfer of images/data.
Without a huge amount of trouble you may get 1200-2400 bits per second
on a voice FM circuit. This works out at around 100-200 characters per
second which for an average 640x480 lowish quality JPG image (say 30K
bytes) as taking quite a while to transmit. (Say 3-5 mins)

Cell phones have a much higher data rate and in fact encode audio into a
digital stream. I'll admit I dont know what the rate is but think 3G is
around 2MBit/sec max!

You could no doubt modify the walkie talkie modulation method and
bandwidth to get better rate but I doubt it would be worth it. I'll not
mention the legal implications of doing this! If you really want to play
have a look at the ISM bands like 2.4GHz. In the US at least you can
even build your own equipment that conforms to this "unlicensed" band.
There are even chips available to make it easier.

There is lots of GPL software around that will encode/decode an audio
stream to/from data and even key the TX. If you want some names/refs pls
post your request.

Cheers Bob VK2YQA


wrote:


Wireless image transmission over walkie-talkie; has this
been done?

Hi Ben

Okay well there are a few basic possibilities here;

- Packet or AX25
More use in a multi station environment with interactive keyboarding
going on. It was probably the most serious attempt at a data mode that
happened to amateur radio - back in the late 1980's. (excluding CW ,
RTTY etc) Not great for file/image xfers as TX/RX times for fixed TX
lengths and frame retransmit error correction means lots of time is
spent in T/R switching and resending entire frames. The "original"
packet standards were 1200 and 300bits per second or about 85 characters
per second at the high end. Can be optimised to get around 110cps if you
play with packet lengths etc. It used FSK which by todays standards is
not a very efficient use of bandwidth. There is a LOT of software
available for it. Early work tended to use external hardware (A TNC or
modem hanging off a PC port) Nowadays there is a lot of s/w that relies
on the PC soundcard to do the DSP work in encoding/decoding whatever
mode you want. My perosnal favorite is Tom Sailors "soundmodem" code
that creates the "modem" in software and then talks to (or supplies) the
stack above that to talk vanilla AXC25 connect mode or TCP/IP etc. This
code is available for both Linux and Windows platforms. Lookup "Flexnet"
or "soundmodem". Good start point might be http://www.baycom.org. There
are other software packages (eg MixW?) that use the soundcard but their
names escape me at the moment.

- Narrow digital modes
These tend to occupy less than (say) 1khz b/w and work well with low
power/low s/n situations. Pretty slow for file xfers many indeed not
even allowing it without lots of user intervention. You may want to
lookup PSK31, MT63, Olivia and so on. I also note someone has modified
some PSK63 code and i/f to talk email through the normal clients. PSK31
for example is only 31 bits per second! I would not recommend any of
these modes for file xfers unless you were fighting low signal levels. I
for example am going to try some low rate beaconing of GPS data some
day, hoping to get reliable info over maybe 100-200 miles on 2m SSB.

- RDFT Wyman encoding
This was originally touted as a "perfect" SSTV mode but in reality it
sends any form of digital data. The code can be run both under Linux and
Windows as a command line utility. There are a few front ends that make
use of the underlying code (eg Digtrx). The code itself comes in two
parts. One encodes the binary data to a wav file that can then be played
with any media player through the PC speaker port to the radio input.
The other takes a wav file as an input and converts it back to the
binary data. The front end programs tend to make this part easy as it
recognizes the start of the stream to start recording said wav file. In
its original form the RDFT code was made to work over SSB bandwidths
with varying degrees of forward error correction (ie it doesnt need to
retransmit because of errors) Data rate is in the region of about 85cps
which is real good compared to SSB on the original FSK packet. I have
personally played with the code and managed to get a 50% higher data
rate over a FM voice channel. There was a rumour that the author was
looking to make a faster executable for that purpose but I havent heard
anything for a while. The original code description (at
http://www.kiva.net/~djones/digmodes.htm - only Wyman 11-13 have been
released) talks about character rates in the order of 250/sec. There are
of course some limitations to this code. Maximum binary data size that
can be sent in one session is 64Kbytes. No drama really as you could
break files up before sending. It also requires a lot of CPU and memory
grunt to decode. We are talking humungous memory use here, so much that
it is often worthwhile decreasing binary filesize to less than (say) 20K
chunks so that the OS doesnt swap RAM to disk and slow the whole
process. From memory a full 64K file uses in the order of 800MB-1GB of
RAM. What I am trying to get at is that it would be real difficult on
older PC equipment or a PDA.

I should point out by the way that RDFT is also available as a modem
inside of packet and can supposedly do 2500bits/sec on HF/SSB. This is
available in the soundmodem/flexnet package. It is called Q15X25 or NEWPSK.


It would take me a lot of time to assemble all references to software so
I am hoping the above will steer you into a specific direction. If you'd
like to expand on your possible usage I might be able to steer you
better. I'd need to know what kind of radios you are talking about (eg
FM vs AM, VHF, HF, intended use/range).

Cheers Bob VK2YQA

wrote:

Bob:

I agree, its not worth modifying the walkie talkie if a
data-to-voice encoder and voice-to-data decoder exist
that can reasonably transmit over a walkie talkie's
channel. Would love to review some of references on
software or studies done already. Thanks so much in
advance.

Ben

Bob,

Thats very insightful. Its going to take me a while to go
through it. I will post my findings. Thanks a lot.

Ben

Bob Bob wrote:
Hi Ben

Okay well there are a few basic possibilities here;

- Packet or AX25
More use in a multi station environment with interactive keyboarding
going on. It was probably the most serious attempt at a data mode that
happened to amateur radio - back in the late 1980's. (excluding CW ,
RTTY etc) Not great for file/image xfers as TX/RX times for fixed TX
lengths and frame retransmit error correction means lots of time is
spent in T/R switching and resending entire frames. The "original"
packet standards were 1200 and 300bits per second or about 85 characters
per second at the high end. Can be optimised to get around 110cps if you
play with packet lengths etc. It used FSK which by todays standards is
not a very efficient use of bandwidth. There is a LOT of software
available for it. Early work tended to use external hardware (A TNC or
modem hanging off a PC port) Nowadays there is a lot of s/w that relies
on the PC soundcard to do the DSP work in encoding/decoding whatever
mode you want. My perosnal favorite is Tom Sailors "soundmodem" code
that creates the "modem" in software and then talks to (or supplies) the
stack above that to talk vanilla AXC25 connect mode or TCP/IP etc. This
code is available for both Linux and Windows platforms. Lookup "Flexnet"
or "soundmodem". Good start point might be http://www.baycom.org. There
are other software packages (eg MixW?) that use the soundcard but their
names escape me at the moment.

- Narrow digital modes
These tend to occupy less than (say) 1khz b/w and work well with low
power/low s/n situations. Pretty slow for file xfers many indeed not
even allowing it without lots of user intervention. You may want to
lookup PSK31, MT63, Olivia and so on. I also note someone has modified
some PSK63 code and i/f to talk email through the normal clients. PSK31
for example is only 31 bits per second! I would not recommend any of
these modes for file xfers unless you were fighting low signal levels. I
for example am going to try some low rate beaconing of GPS data some
day, hoping to get reliable info over maybe 100-200 miles on 2m SSB.

- RDFT Wyman encoding
This was originally touted as a "perfect" SSTV mode but in reality it
sends any form of digital data. The code can be run both under Linux and
Windows as a command line utility. There are a few front ends that make
use of the underlying code (eg Digtrx). The code itself comes in two
parts. One encodes the binary data to a wav file that can then be played
with any media player through the PC speaker port to the radio input.
The other takes a wav file as an input and converts it back to the
binary data. The front end programs tend to make this part easy as it
recognizes the start of the stream to start recording said wav file. In
its original form the RDFT code was made to work over SSB bandwidths
with varying degrees of forward error correction (ie it doesnt need to
retransmit because of errors) Data rate is in the region of about 85cps
which is real good compared to SSB on the original FSK packet. I have
personally played with the code and managed to get a 50% higher data
rate over a FM voice channel. There was a rumour that the author was
looking to make a faster executable for that purpose but I havent heard
anything for a while. The original code description (at
http://www.kiva.net/~djones/digmodes.htm - only Wyman 11-13 have been
released) talks about character rates in the order of 250/sec. There are
of course some limitations to this code. Maximum binary data size that
can be sent in one session is 64Kbytes. No drama really as you could
break files up before sending. It also requires a lot of CPU and memory
grunt to decode. We are talking humungous memory use here, so much that
it is often worthwhile decreasing binary filesize to less than (say) 20K
chunks so that the OS doesnt swap RAM to disk and slow the whole
process. From memory a full 64K file uses in the order of 800MB-1GB of
RAM. What I am trying to get at is that it would be real difficult on
older PC equipment or a PDA.

I should point out by the way that RDFT is also available as a modem
inside of packet and can supposedly do 2500bits/sec on HF/SSB. This is
available in the soundmodem/flexnet package. It is called Q15X25 or NEWPSK.


It would take me a lot of time to assemble all references to software so
I am hoping the above will steer you into a specific direction. If you'd
like to expand on your possible usage I might be able to steer you
better. I'd need to know what kind of radios you are talking about (eg
FM vs AM, VHF, HF, intended use/range).

Cheers Bob VK2YQA

wrote:

Bob:

I agree, its not worth modifying the walkie talkie if a
data-to-voice encoder and voice-to-data decoder exist
that can reasonably transmit over a walkie talkie's
channel. Would love to review some of references on
software or studies done already. Thanks so much in
advance.

Ben