Home |
Search |
Today's Posts |
#1
|
|||
|
|||
Digital image data over a walkie-talkie?
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 |
#2
|
|||
|
|||
Digital image data over a walkie-talkie?
|
#3
|
|||
|
|||
Digital image data over a walkie-talkie?
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 |
#4
|
|||
|
|||
Digital image data over a walkie-talkie?
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? |
#5
|
|||
|
|||
Digital image data over a walkie-talkie?
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? |
#6
|
|||
|
|||
Digital image data over a walkie-talkie?
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? |
#7
|
|||
|
|||
Digital image data over a walkie-talkie?
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 |
#8
|
|||
|
|||
Digital image data over a walkie-talkie?
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 |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|