Difference between revisions of "29 MHz"
| (9 intermediate revisions by one other user not shown) | |||
| Line 5: | Line 5: | ||
These pages are intended cover the experiments, noting they are experiments, that may require significant effort in construction of equipment, development of software and quite a but patience in order to participate. So far, signals have been sent across the Atlantic by several amateurs using very low symbol rates. There is much still to do to improve performance and reliability. If that interests you, you are in the right place. | These pages are intended cover the experiments, noting they are experiments, that may require significant effort in construction of equipment, development of software and quite a but patience in order to participate. So far, signals have been sent across the Atlantic by several amateurs using very low symbol rates. There is much still to do to improve performance and reliability. If that interests you, you are in the right place. | ||
| + | |||
| + | ==Propagation Effects and multipath== | ||
| + | |||
| + | The F2 and E skip that provides good DX on 10m usually comes at the cost of multipath distortion. In practice this means our usual phase modulated signals (e.g. Quadrature Phase Shift keying (QPSK)) of above a few kHz bandwidth can't be decoded. Success so far has used relatively low bandwidth 18ks/s QPSK in a bandwidth of ~20kHz but even this is too wideband and does not deliver particularly good video. Here are three narrow band signals received by a networked radio in Pennsylvania. They are Gareth G4XAT, Rob M0DTS and Mike G0MJW. All were about 100W, with Mike and rob using beams and Gareth a vertical. The multipath distortion is very apparent, as is the difference in propagation paths. | ||
| + | |||
| + | [[File:Multipath1.jpg|400px]] | ||
| + | |||
| + | Despite the good signal strengths, none of these signals were decodable except very briefly whenever a single path became sufficiently dominant. | ||
| + | |||
| + | The solution to multipath for digital audio broadcasting at HF and VHF and terrestrial television at VHD/UHF is to use a modulation mode, called Orthogonal Frequency Division Multiplexing (OFDM) where many narrow bandwidth signals are stacked next to each other. | ||
| + | |||
| + | [https://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing Wikipedia - OFDM] | ||
| + | |||
| + | Each narrow bandwidth carrier is less impacted by multipath and clever algorithms can be used to compensate and even take advantage of the multiple paths to either increase data throughput (as in MIMO) or improve the signal to noise ratio. | ||
| + | |||
| + | Some form of OFDM is likely to be the best technique, but requires software development to enable it. | ||
==Equipment for 29MHz DATV== | ==Equipment for 29MHz DATV== | ||
| − | Generally, we can generate DATV signals in the same way we do for higher frequencies | + | Generally, we can generate DATV signals in the same way we do for higher frequencies using software defined radios (SDR). |
| − | Similarly on receive, the popular minitiouner does not tune down to 29 MHz | + | The popular SDRs that are used to transmit DATV at higher frequencies are the Adlam-pluto and Lime Mini. The pluto does not work below 70MHz and while the Lime Mini does cover 29MHz natively, in practice the spectrum it generates in this region is not sufficiently clean to use on the air. Consequently, to use either device for transmitting it is best to down-convert from a higher frequency, for example with a 2m to 10m transmit downconverter. |
| + | |||
| + | Similarly on receive, the popular minitiouner used at higher frequencies does not tune down to 29 MHz. An upconverter is needed to translate the signal to an IF within the range of the tuner. | ||
| + | |||
| + | A better option for receive may be to use an HF SDR, e.g. an Airspy, RFSpace SDRIQ/CloudSDR or an RTL dongle and decode the signal in a software package like GnuRadio or SDRAngel. Both of these software packages can also be used to transmit. | ||
| + | |||
| + | Information on a simple 2m to 10m frequency transverter is [[29MHz transverter]] | ||
| + | |||
| + | Information on building power amplifiers for 29 MHz DATV is [here] | ||
| + | |||
| + | Information on suitable antennas for 29 MHz is [here] | ||
==Software for 29MHz DATV== | ==Software for 29MHz DATV== | ||
| Line 19: | Line 45: | ||
==Generating a low rate transport stream== | ==Generating a low rate transport stream== | ||
| − | There isn't much bandwidth available on 10m which means relatively low symbol rates are needed, probably occupying no more than 100kHz of bandwidth, ideally less. | + | There isn't much bandwidth available on 10m which means relatively low symbol rates are needed, probably occupying no more than 100kHz of bandwidth, ideally less. This means we need to use the most efficient video compression readily available to us, at the time of writing this is H265 which can produce good video in 100kb/s and fair video in less. The ffmpeg software package can encode video and generate low data rates mpeg transport streams. Using ffmpeg requires a complex set of command line options that must be tuned to get the best quality. For example the following developed by Rob, M0DTS takes input from OBS and uses an Nvidia graphics card to generate a transport stream for a Pluto running Evariste F5OEO's firmware: |
| + | |||
| + | ffmpeg -f dshow -i video="OBS-Camera" -vcodec hevc_nvenc -g 8 -s 213x120 -bf 0 -pix_fmt yuv420p -b:v 10k -bufsize 30k -r 2 -preset fast -profile:v main -rc cbr_hq -rc-lookahead 5 -an -f mpegts -streamid 0:256 -metadata service_provider="YourCall" -metadata service_name="YourName" -max_delay 2500000 -pcr_period 80 -pat_period 0.4 "udp://192.168.2.1:8282?pkt_size=1316" | ||
| + | |||
| + | This is pretty complex and breaking this down is out of scope and might reveal many liberties being taken but it did actually work. Here is an example received trans-atlantic using SDRAngel. | ||
| + | |||
| + | [[File:SDRAngel1.jpg|400px]] | ||
| + | |||
| + | The above parameters need to be tweaked for each required but rate, which will depend on the transmissions bandwidth, modulation and forward error correction. | ||
Latest revision as of 14:44, 19 December 2022
Introduction
The 2022 RSGB band plan http://rsgb.org/main/files/2022/02/220126_2022-Band-Plans_RadCom-web.pdf identifies 29000 - 29510 kHz segment as available for experimental wide bandwidth operation on a non-interference basis to other stations, including the amateur satellite service segment at 29300 - 29510 kHz. In practice, this means we can experiment with reduced bandwidth DATV on 10m. The 10m band opens for worldwide DX around solar maximum, so theoretically and now in practice it is possible to transmit video worldwide.
These pages are intended cover the experiments, noting they are experiments, that may require significant effort in construction of equipment, development of software and quite a but patience in order to participate. So far, signals have been sent across the Atlantic by several amateurs using very low symbol rates. There is much still to do to improve performance and reliability. If that interests you, you are in the right place.
Propagation Effects and multipath
The F2 and E skip that provides good DX on 10m usually comes at the cost of multipath distortion. In practice this means our usual phase modulated signals (e.g. Quadrature Phase Shift keying (QPSK)) of above a few kHz bandwidth can't be decoded. Success so far has used relatively low bandwidth 18ks/s QPSK in a bandwidth of ~20kHz but even this is too wideband and does not deliver particularly good video. Here are three narrow band signals received by a networked radio in Pennsylvania. They are Gareth G4XAT, Rob M0DTS and Mike G0MJW. All were about 100W, with Mike and rob using beams and Gareth a vertical. The multipath distortion is very apparent, as is the difference in propagation paths.
Despite the good signal strengths, none of these signals were decodable except very briefly whenever a single path became sufficiently dominant.
The solution to multipath for digital audio broadcasting at HF and VHF and terrestrial television at VHD/UHF is to use a modulation mode, called Orthogonal Frequency Division Multiplexing (OFDM) where many narrow bandwidth signals are stacked next to each other.
Each narrow bandwidth carrier is less impacted by multipath and clever algorithms can be used to compensate and even take advantage of the multiple paths to either increase data throughput (as in MIMO) or improve the signal to noise ratio.
Some form of OFDM is likely to be the best technique, but requires software development to enable it.
Equipment for 29MHz DATV
Generally, we can generate DATV signals in the same way we do for higher frequencies using software defined radios (SDR).
The popular SDRs that are used to transmit DATV at higher frequencies are the Adlam-pluto and Lime Mini. The pluto does not work below 70MHz and while the Lime Mini does cover 29MHz natively, in practice the spectrum it generates in this region is not sufficiently clean to use on the air. Consequently, to use either device for transmitting it is best to down-convert from a higher frequency, for example with a 2m to 10m transmit downconverter.
Similarly on receive, the popular minitiouner used at higher frequencies does not tune down to 29 MHz. An upconverter is needed to translate the signal to an IF within the range of the tuner.
A better option for receive may be to use an HF SDR, e.g. an Airspy, RFSpace SDRIQ/CloudSDR or an RTL dongle and decode the signal in a software package like GnuRadio or SDRAngel. Both of these software packages can also be used to transmit.
Information on a simple 2m to 10m frequency transverter is 29MHz transverter
Information on building power amplifiers for 29 MHz DATV is [here]
Information on suitable antennas for 29 MHz is [here]
Software for 29MHz DATV
ffmpeg - for generating the encoded video stream SDRAngel - for receiving
Generating a low rate transport stream
There isn't much bandwidth available on 10m which means relatively low symbol rates are needed, probably occupying no more than 100kHz of bandwidth, ideally less. This means we need to use the most efficient video compression readily available to us, at the time of writing this is H265 which can produce good video in 100kb/s and fair video in less. The ffmpeg software package can encode video and generate low data rates mpeg transport streams. Using ffmpeg requires a complex set of command line options that must be tuned to get the best quality. For example the following developed by Rob, M0DTS takes input from OBS and uses an Nvidia graphics card to generate a transport stream for a Pluto running Evariste F5OEO's firmware:
ffmpeg -f dshow -i video="OBS-Camera" -vcodec hevc_nvenc -g 8 -s 213x120 -bf 0 -pix_fmt yuv420p -b:v 10k -bufsize 30k -r 2 -preset fast -profile:v main -rc cbr_hq -rc-lookahead 5 -an -f mpegts -streamid 0:256 -metadata service_provider="YourCall" -metadata service_name="YourName" -max_delay 2500000 -pcr_period 80 -pat_period 0.4 "udp://192.168.2.1:8282?pkt_size=1316"
This is pretty complex and breaking this down is out of scope and might reveal many liberties being taken but it did actually work. Here is an example received trans-atlantic using SDRAngel.
The above parameters need to be tweaked for each required but rate, which will depend on the transmissions bandwidth, modulation and forward error correction.