https://www.pg540.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=PA1RKT 2026-04-23T16:13:26Z Gebruikersbijdragen MediaWiki 1.23.2 https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2020-01-31T15:33:30Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> In the Summer of 2018, the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being: <br /> * GNU Radio (on Linux, Windows) - a multi-purpose, Python based signal processing platform with many ready-built modules<br /> * DATV-Express (DATV transmitter under Windows), covers DVB-S, DVB-S2 and even DVB-T. Works nice with vMix videomixer software<br /> * SDR Angel - a multi-purpose signal processor tool for modulating and demodulating a range of signals, including analog ATV (Linux,, Windows)<br /> * SDR Console (very nice modular SDR receiving software under Windows) also has a nice transmitting section, mainly for phone and some rudimentary CW<br /> * There are some nice, smaller specific tools that might work woth the ADALM-PLUTO (like HackTV?), but as long as they are not in this list I do not have any significant experience nor luck with them ;-)<br /> * Evariste, F5OEO, has produced very nice alternative firmware for the Pluto. It basically implements transmitting software for (D)ATV, SSTV, SSB transmissions - with a streaming server on board so you can stream the actual content to it from various applications under Linux or Windows. For DATV experiments, this currently (January 2020) is my favorite setup. See below for more detailed info.<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> If the GNU Radio software has been installed using Pybombs, there is a specific method to start the software. First, you must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> <br /> In GNU Radio, you now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> <br /> == Transmitting experiments ==<br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm and 23cm amateur bands, preferably on our PG540 'channel 2' frequency of 432.540 MHz (see [[Huisfrequenties]]) for NFM and SSB. For WFM I use 1277.500MHz and for DATV I regularly use the inputs of the PI6HLM repeater that is close: 436MHz or 1252.600MHz for DVB-S. <br /> <br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> For those who like to produce some real nice 'phone' signal (SSB, AM, FM), the recent versions of [https://www.sdr-radio.com SDR Console] contain a very nice transmitting feature. It works quite smooth and clean. Also SDR Angel works out of the box, but its user interface really has some quirks (or I just do not understand the way the author's brain works :-). <br /> <br /> For DATV use, I know of some options i.e. using VLC and some extra Java based applications, or (on Linux) use ffmpeg directly. However, the easiest way to get a DATV signal in the air (to me) is the [https://www.datv-express.com/CustomPage/Downloads Express DVB-S Transmitter] which can produce DVB-S, DVB-S2 and even DVB-T signals. If you use this together with the free version of [https://www.vmix.com vMix] for video/audio mixing you have quite a comfortable interface for live DATV broadcasts.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately - I think it is is less than +6dBm). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome.<br /> <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.<br /> <br /> ''Note: there seems to be a trick to switch off the LO while receiving. Some software (i.e. SDRConsole) manages to switch off the LO. Something to look into...''<br /> <br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> <br /> The signals that the PLUTO produces are not real sinuses. They are a bit blocky and therefore do have a bit phase noise and harmonics. Directly amplifying this signal leads to a messy signal. I managed to destroy our DVB-C signal in the living room quite easy with just a few Watts of unfiltered signal. Putting a band filter in between the PLUTO and the amplifier stage(s) greatly improves signal purity and the efficiency of the amplifier. In some cases, the bandfilter makes a big difference - i.e. no signal at all when not filtered. <br /> <br /> Ideally, you want a bandpass filter after each amplifier stage, but that can be quite costly :-)<br /> <br /> My guess is that there might be structural solutions to this, but I have proven to be too lazy to figure them out yet. I just try to circumvent them. Just be aware. Caveat emptor.<br /> <br /> <br /> '''Earthing / shielding sensitivitiy - the 'pfiew' sound'''<br /> <br /> I found out very early just how sensitive the ADALM-PLUTO is for ripples and other discontinuities in its 'earthing' path - the first night of my experiments, there was a big hazard and sometimes when the lightning stroke, I heard a loud popping 'pfieuw' sound from my speakers and the PLUTO was knock-out, only to be recovered by pulling and re-plugging the USB connection. But also without lightning, the PLUTO proves to be quite sensitive - in very many application scenarios, there is some difference in earthing/grounding between the 'RF' side (usually fed with external DC power) and the 'computer side' (usually some switched USB signal). For the PLUTO, this can be very disturbing. I try to setup the ground before I start the PLUTO and not change it during the experiment. Even connecting a new sound source to my mixer can cause problems....<br /> <br /> <br /> == F5OEO alternative firmware ==<br /> Evariste, F5OEO, has compiled very good firmware as an alternative firmware upgrade to the Pluto. It enhances the functionality of the Pluto itself to become a basic transmitter, with the transmitting software running in the firmware itself, so the Pluto transforms into some kind of semi-standalone transmitter (and maybe even a transceiver in later versions :-).<br /> <br /> I must say semi-standalone because you still need a computer to provide useful content to the Pluto. For DATV I use vMix (on Windows only) or OBS (under Windows or Linux). These applications can provide the Pluto with a stream that then is modulated and transmitted. With the parameters of the stream you can control the transmitter of the Pluto - frequency, the modulation to use, bandwidth, other characteristics are all controlled by parameters in the stream.<br /> <br /> Info on the firmware itself, and the configuration of the stream with all parameters, is on the Pluto itself. Just point your webbrowser to the ip address of your Pluto. Usually this is [http://192.168.2.1]<br /> <br /> <br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2020-01-03T14:52:01Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM (NB: ook repeater kanaal &gt; 29.640 MHz out (global))<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|'''144.540 MHz''' <br /> |Algemeen / oproep kanaal FM - de meest gebruikte 540 frequentie! (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|'''432.540 Mhz'''<br /> |Algemeen / oproep kanaal FM 'kanaal 2' - soms met CTCSS (85.4 Hz)<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1285 MHz<br /> |DVB-S/DVB-S2 DATV experimenten 333-2000 kbit/s<br /> |-<br /> |align=&quot;right&quot;|1292.540 MHz<br /> |Wideband FM experimenten<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |Algemeen / oproep kanaal FM<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2020-01-03T14:46:29Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM (NB: ook repeater kanaal &gt; 29.640 MHz out (global))<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|'''144.540 MHz''' <br /> |Algemeen / oproep kanaal FM - de meest gebruikte 540 frequentie! (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|'''432.540 Mhz'''<br /> |Algemeen / oproep kanaal FM 'kanaal 2' - soms met CTCSS (85.4 Hz)<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1285 MHz<br /> |DVB-S/DVB-S2 DATV verbindingen 333-2000 kbit/s<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |Algemeen / oproep kanaal FM<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2020-01-03T14:36:00Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM (NB: ook repeater kanaal &gt; 29.640 MHz out (global))<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|'''144.540 MHz''' <br /> |Algemeen / oproep kanaal FM - de meest gebruikte 540 frequentie! (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|'''432.540 Mhz'''<br /> |Algemeen / oproep kanaal FM 'kanaal 2' - soms met CTCSS (85.4 Hz)<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1258 MHz<br /> |DVB-S/DVB-S2 DATV verbindingen 333-2000 kbit/s<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |Algemeen / oproep kanaal FM<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2020-01-03T14:34:57Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM (NB: ook repeater kanaal &gt; 29.640 MHz out (global))<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|1'''44.540 MHz''' <br /> |Algemeen / oproep kanaal FM - de meest gebruikte 540 frequentie! (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|'''432.540 Mhz'''<br /> |Algemeen / oproep kanaal FM 'kanaal 2' - soms met CTCSS (85.4 Hz)<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1258 MHz<br /> |DVB-S/DVB-S2 DATV verbindingen 333-2000 kbit/s<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |Algemeen / oproep kanaal FM<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2020-01-03T14:33:03Z

<p>PA1RKT: Kleine tekstwijzigingen, 1258 DATV toegevoegd</p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM (NB: ook repeater kanaal &gt; 29.640 MHz out (global))<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Algemeen / oproep kanaal FM - de meest gebruikte 540 frequentie! (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |Algemeen / oproep kanaal FM 'kanaal 2' - soms met CTCSS (85.4 Hz)<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1258 MHz<br /> |DVB-S/DVB-S2 DATV verbindingen 333-2000 kbit/s<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |Algemeen / oproep kanaal FM<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2019-08-18T10:12:19Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Oproep lokaal / Kennemerland / NH-ZH (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - FM simplex / test - evt. met CTCSS van 85.4 Hz<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |FM oproep / simplex / test<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal Kennemerland NH en ZH algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2019-08-18T10:11:03Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Oproep lokaal / Kennemerland / NH-ZH (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - FM simplex / test - evt. met CTCSS van 85.4 Hz<br /> |-<br /> |align=&quot;right&quot;|1242.500 MHz<br /> |Test frequentie #1 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1277.500 MHz<br /> |Test frequentie #2 PA1RKT/PA0BDC voor TX-pad bepaling (FM, SSB)<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |FM oproep / simplex / test<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal Kennemerland NH en ZH algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> |align=&quot;right&quot;| 10.489.754.000 MHz<br /> |SSB op de Es'hail2 Oscar 100<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2019-08-18T10:03:04Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> In the Summer of 2018, the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being: <br /> * GNU Radio (on Linux, Windows) - a multi-purpose, Python based signal processing platform with many ready-built modules<br /> * DATV-Express (DATV transmitter under Windows), covers DVB-S, DVB-S2 and even DVB-T. Works nice with vMix videomixer software<br /> * SDR Angel - a multi-purpose signal processor tool for modulating and demodulating a range of signals, including analog ATV (Linux,, Windows)<br /> * SDR Console (very nice modular SDR receiving software under Windows) also has a nice transmitting section, mainly for phone and some rudimentary CW<br /> * There are some nice, smaller specific tools that might work woth the ADALM-PLUTO (like HackTV?), but as long as they are not in this list I do not have any significant experience nor luck with them ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> If the GNU Radio software has been installed using Pybombs, there is a specific method to start the software. First, you must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> <br /> In GNU Radio, you now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> <br /> == Transmitting experiments ==<br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm and 23cm amateur bands, preferably on our PG540 'channel 2' frequency of 432.540 MHz (see [[Huisfrequenties]]) for NFM and SSB. For WFM I use 1277.500MHz and for DATV I regularly use the inputs of the PI6HLM repeater that is close: 436MHz or 1252.600MHz for DVB-S. <br /> <br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> For those who like to produce some real nice 'phone' signal (SSB, AM, FM), the recent versions of [https://www.sdr-radio.com SDR Console] contain a very nice transmitting feature. It works quite smooth and clean. Also SDR Angel works out of the box, but its user interface really has some quirks (or I just do not understand the way the author's brain works :-). <br /> <br /> For DATV use, I know of some options i.e. using VLC and some extra Java based applications, or (on Linux) use ffmpeg directly. However, the easiest way to get a DATV signal in the air (to me) is the [https://www.datv-express.com/CustomPage/Downloads Express DVB-S Transmitter] which can produce DVB-S, DVB-S2 and even DVB-T signals. If you use this together with the free version of [https://www.vmix.com vMix] for video/audio mixing you have quite a comfortable interface for live DATV broadcasts.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately - I think it is is less than +6dBm). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome.<br /> <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.<br /> <br /> ''Note: there seems to be a trick to switch off the LO while receiving. Some software (i.e. SDRConsole) manages to switch off the LO. Something to look into...''<br /> <br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> <br /> The signals that the PLUTO produces are not real sinuses. They are a bit blocky and therefore do have a bit phase noise and harmonics. Directly amplifying this signal leads to a messy signal. I managed to destroy our DVB-C signal in the living room quite easy with just a few Watts of unfiltered signal. Putting a band filter in between the PLUTO and the amplifier stage(s) greatly improves signal purity and the efficiency of the amplifier. In some cases, the bandfilter makes a big difference - i.e. no signal at all when not filtered. <br /> <br /> Ideally, you want a bandpass filter after each amplifier stage, but that can be quite costly :-)<br /> <br /> <br /> '''Earthing / shielding sensitivitiy - the 'pfiew' sound'''<br /> <br /> I found out very early just how sensitive the ADALM-PLUTO is for ripples and other discontinuities in its 'earthing' path - the first night of my experiments, there was a big hazard and sometimes when the lightning stroke, I heard a loud popping 'pfieuw' sound from my speakers and the PLUTO was knock-out, only to be recovered by pulling and re-plugging the USB connection. But also without lightning, the PLUTO proves to be quite sensitive - in very many application scenarios, there is some difference in earthing/grounding between the 'RF' side (usually fed with external DC power) and the 'computer side' (usually some switched USB signal). For the PLUTO, this can be very disturbing. I try to setup the ground before I start the PLUTO and not change it during the experiment. Even connecting a new sound source to my mixer can cause problems....<br /> <br /> My guess is that there might be structural solutions to this, but I have proven to be too lazy to figure them out yet. I just try to circumvent them. Just be aware. Caveat emptor.<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2019-08-18T10:00:05Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> In the Summer of 2018, the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being: <br /> GNU Radio (on Linux, Windows) - a multi-purpose, Python based signal processing platform with many ready-built modules<br /> DATV-Express (DATV transmitter under Windows), covers DVB-S, DVB-S2 and even DVB-T. Works nice with vMix videomixer software<br /> SDR Angel - a multi-purpose signal processor tool for modulating and demodulating a range of signals, including analog ATV (Linux,, Windows)<br /> SDR Console (very nice modular SDR receiving software under Windows) also has a nice transmitting section, mainly for phone and some rudimentary CW<br /> There are some nice, smaller specific tools that might work woth the ADALM-PLUTO (like HackTV?), but as long as they are not in this list I do not have any significant experience nor luck with them ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> If the GNU Radio software has been installed using Pybombs, there is a specific method to start the software. First, you must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> <br /> In GNU Radio, you now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> <br /> == Transmitting experiments ==<br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm and 23cm amateur bands, preferably on our PG540 'channel 2' frequency of 432.540 MHz (see [[Huisfrequenties]]) for NFM and SSB. For WFM I use 1277.500MHz and for DATV I regularly use the inputs of the PI6HLM repeater that is close: 436MHz or 1252.600MHz for DVB-S. <br /> <br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> For those who like to produce some real nice 'phone' signal (SSB, AM, FM), the recent versions of [https://www.sdr-radio.com SDR Console] contain a very nice transmitting feature. It works quite smooth and clean. Also SDR Angel works out of the box, but its user interface really has some quirks (or I just do not understand the way the author's brain works :-). <br /> <br /> For DATV use, I know of some options i.e. using VLC and some extra Java based applications, or (on Linux) use ffmpeg directly. However, the easiest way to get a DATV signal in the air (to me) is the [https://www.datv-express.com/CustomPage/Downloads Express DVB-S Transmitter] which can produce DVB-S, DVB-S2 and even DVB-T signals. If you use this together with the free version of [https://www.vmix.com vMix] for video/audio mixing you have quite a comfortable interface for live DATV broadcasts.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately - I think it is is less than +6dBm). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome.<br /> <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.<br /> <br /> ''Note: there seems to be a trick to switch off the LO while receiving. Some software (i.e. SDRConsole) manages to switch off the LO. Something to look into...''<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> <br /> The signals that the PLUTO produces are not real sinuses. They are a bit blocky and therefore do have a bit phase noise and harmonics. Directly amplifying this signal leads to a messy signal. I managed to destroy our DVB-C signal in the living room quite easy with just a few Watts of unfiltered signal. Putting a band filter in between the PLUTO and the amplifier stage(s) greatly improves signal purity and the efficiency of the amplifier. In some cases, the bandfilter makes a big difference - i.e. no signal at all when not filtered. <br /> <br /> Ideally, you want a bandpass filter after each amplifier stage, but that can be quite costly :-)<br /> <br /> '&quot;Earthing / shielding sensitivitiy - the 'pfiew' sound'&quot;<br /> I found out very early just how sensitive the ADALM-PLUTO is for ripples and other discontinuities in its 'earthing' path - the first night of my experiments, there was a big hazard and sometimes when the lightning stroke, I heard a loud popping 'pfieuw' sound from my speakers and the PLUTO was knock-out, only to be recovered by pulling and re-plugging the USB connection. But also without lightning, the PLUTO proves to be quite sensitive - in very many application scenarios, there is some difference in earthing/grounding between the 'RF' side (usually fed with external DC power) and the 'computer side' (usually some switched USB signal). For the PLUTO, this can be very disturbing. I try to setup the ground before I start the PLUTO and not change it during the experiment. Even connecting a new sound source to my mixer can cause problems....<br /> <br /> My guess is that there might be structural solutions to this, but I have proven to be too lazy to figure them out yet. I just try to circumvent them. Just be aware. Caveat emptor.<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2019-03-04T10:13:56Z

<p>PA1RKT: /* Experiments on 70cm (GNU Radio) */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> For those who like to produce some real nice 'phone' signal (SSB, AM, FM), the recent versions of [https://www.sdr-radio.com SDR Console] contain a very nice transmitting feature. It works quite smooth and clean.<br /> <br /> For DATV use, I know of some options i.e. using VLC and some extra Java based applications, or (on Linux) use ffmpeg directly. The easiest way to get a DATV signal in the air (to me) is the [https://www.datv-express.com/CustomPage/Downloads Express DVB-S Transmitter] which can produce DVB-S, DVB-S2 and even DVB-T signals. If you use this together with the free version of [https://www.vmix.com vMix] for video/audio mixing you have quite a comfortable interface for live DATV broadcasts (including a ColorBar test signal).<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately - I think it is is less than +6dBm). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome.<br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm band, preferably on our PG540 'channel 2' frequency of 432.540 MHz (see [[Huisfrequenties]]). <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.<br /> <br /> ''Note: there seems to be a trick to switch off the LO while receiving. Some software (i.e. SDRConsole) manages to switch off the LO. Something to look into...''<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> <br /> The signals that the PLUTO produces are not real sinuses. They are a bit blocky and therefore do have a bit phase noise and harmonics. Directly amplifying this signal leads to a messy signal. I managed to destroy our DVB-C signal in the living room quite easy with just a few Watts. Putting a band filter in between the PLUTO and the amplifier stage(s) greatly improves signal purity and the efficiency of the amplifier. In some cases, the bandfilter makes a big difference - i.e. no signal at all when not filtered. <br /> <br /> Ideally, you want a bandpass filter after each amplifier stage, but that can be quite costly :-)<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2019-03-04T09:55:34Z

<p>PA1RKT: /* Experiments on 70cm */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm (GNU Radio) ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm band, preferably on our PG540 'channel 2' frequency of 430.540 MHz (see [[Huisfrequenties]]). <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:55:31Z

<p>PA1RKT: /* Experiments on 70cm */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm band, preferably on our PG540 'channel 2' frequency of 430.540 MHz (see [[Huisfrequenties]]). <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:50:52Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm band, preferably on our PG540 'channel 2' frequency of 430.540 MHz (see [[Huisfrequenties]]). <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:47:21Z

<p>PA1RKT: /* Experiments on 70cm */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed up by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> I (PA1RKT) prefer to experiment with the Pluto in the 70cm band, preferably on our PG540 'channel 2' frequency of 430.540 MHz (see [[Huisfrequenties]]). <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:45:55Z

<p>PA1RKT: /* Experiments on 70cm */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed up by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> I (PA1RKT) prefer to experiment in the 70cm band, preferably on our PG540 'channel 2' frequency of 430.540 MHz (see [[Huisfrequenties]]). <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:42:41Z

<p>PA1RKT: /* General */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed up by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:39:13Z

<p>PA1RKT: /* General */</p> <hr /> <div><br /> == General ==<br /> The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.<br /> <br /> Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find. <br /> <br /> The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed up by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows &lt;I will find out the name ;-)&gt;<br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:26:33Z

<p>PA1RKT: /* Connecting and detecting / Gnu Radio */</p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / GNU Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:26:15Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / Gnu Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> &lt;to be continued&gt;<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T19:20:57Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / Gnu Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> <br /> '''The local oscillator (LO) is always on'''<br /> <br /> The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way.<br /> <br /> '''Filtering the signal'''<br /> <br /> While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.<br /> <br /> That leads us to the subject of filtering the signal.<br /> <br /> <br /> <br /> <br /> <br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T16:08:47Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / Gnu Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> &lt;to be continued&gt;<br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T16:06:49Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / Gnu Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> <br /> cd gr-sdrplay<br /> <br /> source setup_env.sh<br /> <br /> gnuradio-companion<br /> <br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under &quot;Industrial I/O&quot; in the GNU Radio comapnion UI.....<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> &lt;to be continued&gt;<br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T16:04:15Z

<p>PA1RKT: </p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / Gnu Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> <br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, integrating the PLUTO block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> cd gr-sdrplay<br /> source setup_env.sh<br /> gnuradio-companion<br /> <br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> &lt;to be continued&gt;<br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/Hoofdpagina 2018-12-02T16:03:58Z

<p>PA1RKT: </p> <hr /> <div>__NOTOC__<br /> '''Dit is de project Wiki van de projectgroep .540'''<br /> <br /> Voor de [http://www.qsl.net/pa0sny/vijfveertig.html homepage van de .540 klik hier].<br /> <br /> [[Huisfrequenties]]<br /> <br /> === Activiteiten informatie ===<br /> Om op de hoogte te blijven van de activiteiten van de projectgroep 540, abboneer u dan op de nieuws emaillijst.<br /> Voor instructies zie: [[E-mail]]<br /> == Activiteiten ==<br /> * [[Dag voor de Radio Amateur (DvdRA) 2014]]<br /> <br /> == Projecten ==<br /> * [[Universele Zender Project]]<br /> * [[Nokia Repeater]]<br /> * [[Lima SDR]]<br /> * [[Offset parabool antenne met patch straler voor 13 cm (WiFi) ]]<br /> * [[Stralers voor 23 cm, 13 cm en 3 cm voor in parabool ]]<br /> * [[Opzet DVB-S Print voor Raspberry PI ]]<br /> <br /> * [[SETUP-DATV DVB-S Print for Raspberry PI in the English language ]]<br /> <br /> * [[Grafische interface voor LEANDVB ]]<br /> <br /> * [[DVB-S zender met 1x Raspberry PI3 en RPIDATV ]]<br /> <br /> * [[ Experimenten met parabool antenne's voor ontvangst 10 GHz (D)ATV ]]<br /> <br /> * [[ Het PG540 Spotnik Netwerk ]]<br /> <br /> == Aantekeningen ==<br /> * [[USBTV ruis op monitor]]<br /> * [[LNB overzicht]]<br /> * [[Huisfrequenties]]<br /> * [[FPGA development kits]]<br /> * [[Digilite-ZL]]<br /> * [[Digilite-Raspberry Pi 2x2]]<br /> * [[Software defined radio]]<br /> * [[PLL LNB]]<br /> * [[HackRF notities]]<br /> * [[USRP B200]]<br /> * [[DVB-S]]<br /> * [[DVB-S2]]<br /> * [[DVB-S USB ontvanger Hauppage DEC3000]]<br /> * [[GnuRadio]]<br /> * [[Digitale ingang]]<br /> * [http://www.atv.watch Digitale (D)ATV streams NL en WWW Global * tip!] &lt;--- deze link is dood (2018-11-06)<br /> * [[LimeSDR interface to SVXlink using GNUradio]]<br /> * [[DVB-T 2 Mhz Ham-Mode instellingen op PI6ZDM]]<br /> * [[Yaesu FT-2311 23cm FM]]<br /> * [[RPITX interface to SVXlink using GNUradio]]<br /> * [[ADALM-PLUTO (SDR rx/tx) notes]]<br /> <br /> <br /> <br /> == Andere sites van de 540 groep ==<br /> * [http://www.qsl.net/pa0sny/vijfveertig.html Homepage]<br /> * [http://www.hotforum.nl/forum/index.php?go=showsubject&amp;name=punt540groep&amp;id=123562 Forum]<br /> * [http://www.hotforum.nl/forum/punt540junkbox/ Junkbox forum]<br /> * [http://pg540.blogspot.nl/ PG.540 blog]<br /> <br /> = Hulp =<br /> <br /> Raadpleeg de [//meta.wikimedia.org/wiki/NL_Help:Inhoudsopgave handleiding] voor informatie over het gebruik van de wikisoftware.</div>

PA1RKT https://www.pg540.org/wiki/index.php/ADALM-PLUTO_(SDR_rx/tx)_notes 2018-12-02T16:02:44Z

<p>PA1RKT: Nieuwe pagina aangemaakt met ' == General == == Connecting and detecting / Gnu Radio == '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM...'</p> <hr /> <div><br /> == General ==<br /> <br /> <br /> == Connecting and detecting / Gnu Radio ==<br /> '''Windows''': The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.<br /> Under '''Linux''', my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, integrating the PLUTO block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.<br /> <br /> Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.<br /> cd gr-sdrplay<br /> source setup_env.sh<br /> gnuradio-companion<br /> <br /> <br /> '''Warning:''' the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.<br /> <br /> In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively.<br /> <br /> == Experiments on 70cm ==<br /> Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.<br /> <br /> The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. <br /> However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome. <br /> &lt;to be continued&gt;<br /> <br /> `<br /> <br /> <br /> 73<br /> Rene<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-15T21:58:56Z

<p>PA1RKT: </p> <hr /> <div>[[Bestand:FT2311x2.jpg|600px]]<br /> <br /> <br /> Op mijn FT-2311 zit een Japans stickertje met daarop de originele eigenaar, ik denk dat er met pen 'JN2EFF' op staat.<br /> <br /> '''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-2311 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> * 3 dichtgesoldeerd = 10/20 KHz raster<br /> * 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> '''CR2032 BATTERIJ''' <br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.<br /> <br /> '''FULL 1240-1300 TXRX''' <br /> Soldeerpad 7 bepaalt dit. <br /> * Dichtsolderen == 1240-1300 MHz<br /> * ongesoldeerd == 1260-1300 MHz<br /> <br /> PA0BDC<br /> PA1RKT</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2018-11-15T21:56:31Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Oproep lokaal / Kennemerland / NH-ZH (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - FM simplex / test - evt. met CTCSS van 85.4 Hz<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |FM oproep / simplex / test<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2018-11-15T21:46:38Z

<p>PA1RKT: 1295.400 toegevoegd en wat kleine aanpassingen</p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Oproep lokaal / Kennemerland / NH-ZH (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - FM simplex / test - evt. met CTCSS van 85.4 Hz<br /> |-<br /> |align=&quot;right&quot;|438.775 MHz <br /> |7.6 shift. Experimentele bemande repeater @JO22HI. Operator: pa0bdc / 1750 Hz + 225.7 Hz ctcss.<br /> |-<br /> |align=&quot;right&quot;|1295.400 MHz<br /> |FM oproep / simplex / test<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Hoofdpagina 2018-11-06T14:12:44Z

<p>PA1RKT: </p> <hr /> <div>__NOTOC__<br /> '''Dit is de project Wiki van de projectgroep .540'''<br /> <br /> Voor de [http://www.qsl.net/pa0sny/vijfveertig.html homepage van de .540 klik hier].<br /> <br /> [[Huisfrequenties]]<br /> <br /> === Activiteiten informatie ===<br /> Om op de hoogte te blijven van de activiteiten van de projectgroep 540, abboneer u dan op de nieuws emaillijst.<br /> Voor instructies zie: [[E-mail]]<br /> == Activiteiten ==<br /> * [[Dag voor de Radio Amateur (DvdRA) 2014]]<br /> <br /> == Projecten ==<br /> * [[Universele Zender Project]]<br /> * [[Nokia Repeater]]<br /> * [[Lima SDR]]<br /> * [[Offset parabool antenne met patch straler voor 13 cm (WiFi) ]]<br /> * [[Stralers voor 23 cm, 13 cm en 3 cm voor in parabool ]]<br /> * [[Opzet DVB-S Print voor Raspberry PI ]]<br /> <br /> * [[SETUP-DATV DVB-S Print for Raspberry PI in the English language ]]<br /> <br /> * [[Grafische interface voor LEANDVB ]]<br /> <br /> * [[DVB-S zender met 1x Raspberry PI3 en RPIDATV ]]<br /> <br /> * [[ Experimenten met parabool antenne's voor ontvangst 10 GHz (D)ATV ]]<br /> <br /> * [[ Het PG540 Spotnik Netwerk ]]<br /> <br /> == Aantekeningen ==<br /> * [[USBTV ruis op monitor]]<br /> * [[LNB overzicht]]<br /> * [[Huisfrequenties]]<br /> * [[FPGA development kits]]<br /> * [[Digilite-ZL]]<br /> * [[Digilite-Raspberry Pi 2x2]]<br /> * [[Software defined radio]]<br /> * [[PLL LNB]]<br /> * [[HackRF notities]]<br /> * [[USRP B200]]<br /> * [[DVB-S]]<br /> * [[DVB-S2]]<br /> * [[DVB-S USB ontvanger Hauppage DEC3000]]<br /> * [[GnuRadio]]<br /> * [[Digitale ingang]]<br /> * [http://www.atv.watch Digitale (D)ATV streams NL en WWW Global * tip!] &lt;--- deze link is dood (2018-11-06)<br /> * [[LimeSDR interface to SVXlink using GNUradio]]<br /> * [[DVB-T 2 Mhz Ham-Mode instellingen op PI6ZDM]]<br /> * [[Yaesu FT-2311 23cm FM]]<br /> <br /> == Andere sites van de 540 groep ==<br /> * [http://www.qsl.net/pa0sny/vijfveertig.html Homepage]<br /> * [http://www.hotforum.nl/forum/index.php?go=showsubject&amp;name=punt540groep&amp;id=123562 Forum]<br /> * [http://www.hotforum.nl/forum/punt540junkbox/ Junkbox forum]<br /> * [http://pg540.blogspot.nl/ PG.540 blog]<br /> <br /> = Hulp =<br /> <br /> Raadpleeg de [//meta.wikimedia.org/wiki/NL_Help:Inhoudsopgave handleiding] voor informatie over het gebruik van de wikisoftware.</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2018-11-06T14:03:47Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Oproep lokaal / Kennemerland / NH-ZH (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - simplex lokaal / regionaal / test - nodig om de Spotniks op 430.540 niet te storen<br /> |-<br /> |align=&quot;right&quot;|438.775 MHz <br /> |7.6 shift. Experimentele bemande repeater @JO22HI. Operator: pa0bdc / 1750 Hz + 225.7 Hz ctcss.<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2018-11-06T14:02:04Z

<p>PA1RKT: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Oproep lokaal / Kennemerland / NH-ZH (144.5375 voor 12.5 KHz raster)<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex pg.540 lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - simplex lokaal / regionaal / test - nodig om de Spotniks op 430.540 niet te storen<br /> |-<br /> |align=&quot;right&quot;|438.775 MHz <br /> |7.6 shift. Experimentele bemande repeater @JO22HI. Operator: pa0bdc / 1750 Hz + 225.7 Hz ctcss.<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:58:06Z

<p>PA1RKT: </p> <hr /> <div>[[Bestand:FT2311x2.jpg]]<br /> <br /> <br /> Op mijn FT-2311 zit een Japans stickertje met daarop de originele eigenaar, ik denk dat er met pen 'JN2EFF' op staat.<br /> <br /> '''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-2311 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> '''CR2032 BATTERIJ''' <br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.<br /> <br /> '''FULL 1240-1300 TXRX''' <br /> Soldeerpad 7 bepaalt dit. Dichtsolderen == 1240-1300 MHz, ongesoldeerd == 1260-1300 MHz</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:54:22Z

<p>PA1RKT: </p> <hr /> <div>[[Bestand:FT2311x2.jpg]]<br /> <br /> <br /> '''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> '''CR2032 BATTERIJ''' <br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.<br /> <br /> '''FULL 1240-1300 TXRX''' <br /> Soldeerpad 7 bepaalt dit. Dichtsolderen == 1240-1300 MHz, ongesoldeerd == 1260-1300 MHz</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:53:16Z

<p>PA1RKT: </p> <hr /> <div>[[Bestand:FT2311x2.jpg]]<br /> '''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> '''CR2032 BATTERIJ''' <br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.<br /> <br /> '''FULL 1240-1300 TXRX''' <br /> Soldeerpad 7 bepaalt dit. Dichtsolderen == 1240-1300 MHz, ongesoldeerd == 1260-1300 MHz</div>

PA1RKT https://www.pg540.org/wiki/index.php/Bestand:FT2311x2.jpg 2018-11-05T21:52:21Z

<p>PA1RKT: </p> <hr /> <div></div>

PA1RKT https://www.pg540.org/wiki/index.php/Huisfrequenties 2018-11-05T21:48:15Z

<p>PA1RKT: 432.540 'kanaal 2' toegevoegd</p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| Frequentie<br /> ! scope=&quot;col&quot;| Werk frequenties waar de PG .540 deelnemers te vinden zijn voor QSO algemeen en test kanalen div.<br /> |-<br /> |align=&quot;right&quot;|3.540 MHz<br /> |CW <br /> |-<br /> |align=&quot;right&quot;|3.754 MHz<br /> |LSB <br /> |-<br /> |align=&quot;right&quot;|7.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|7.154 MHz<br /> |LSB<br /> |-<br /> |align=&quot;right&quot;|14.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|14.154 MHz<br /> |USB<br /> |-<br /> |align=&quot;right&quot;|29.540 MHz<br /> |FM NB *ook repeater kanaal &gt; 29.640 MHz out (global)<br /> |-<br /> |align=&quot;right&quot;|51.540 MHz<br /> |Lokaal<br /> |-<br /> |align=&quot;right&quot;|70.350 MHz <br /> |Lokaal / Kennemerland kanaal.<br /> |-<br /> |align=&quot;right&quot;|144.540 MHz <br /> |Lokaal / Kennemerland NH-ZH / 144.5375 voor 12.5 KHz raster<br /> |-<br /> |align=&quot;right&quot;|430.540 Mhz<br /> |simplex pg.540 lokaal / test / porto kanaal &amp; beurzen, ook voor [[ het PG540 Spotnik Netwerk ]] met 88.5 Hz CTCSS<br /> |-<br /> |align=&quot;right&quot;|432.540 Mhz<br /> |'kanaal 2' - simplex lokaal / test - nodig om de Spotniks op 430.540 niet te storen<br /> |-<br /> |align=&quot;right&quot;|438.775 MHz <br /> |7.6 shift. Experimentele bemande repeater @JO22HI. Operator: pa0bdc / 1750 Hz + 225.7 Hz ctcss.<br /> |-<br /> |align=&quot;right&quot;|1296.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|1296.154 MHz<br /> |SSB (USB) / FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;|10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio (?)<br /> |-<br /> |align=&quot;right&quot;|10.368.054 MHz<br /> |CW<br /> |-<br /> |align=&quot;right&quot;|10.368.154 MHz<br /> |SSB (USB)<br /> |-<br /> |align=&quot;right&quot;| 10.368.540 MHz<br /> |FM NB Lokaal kennemerland NH en ZH (hi) algemeen<br /> |-<br /> |align=&quot;right&quot;| 10.369.540 MHz<br /> |FM BB net (kop. met BB FM (D) ATV ?) Lokaal -regio- ATV repeaters chat kanaal (?)<br /> |-<br /> ----</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:33:06Z

<p>PA1RKT: </p> <hr /> <div>'''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> '''CR2032 BATTERIJ''' <br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.<br /> <br /> '''FULL 1240-1300 TXRX''' <br /> Soldeerpad 7 bepaalt dit. Dichtsolderen == 1240-1300 MHz, ongesoldeerd == 1260-1300 MHz</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:30:48Z

<p>PA1RKT: </p> <hr /> <div>'''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> '''CR2032 BATTERIJ''' <br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:29:50Z

<p>PA1RKT: </p> <hr /> <div>'''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> '''STEP/RASTER'''<br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> CR2032 BATTERIJ<br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:29:14Z

<p>PA1RKT: </p> <hr /> <div>'''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> <br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> '''CTCSS'''<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> '''RESET'''<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> CR2032 BATTERIJ<br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:28:33Z

<p>PA1RKT: </p> <hr /> <div>'''STEP/RASTER'''<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> <br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> CTCSS printje FTS-12<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> RESET<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> CR2032 BATTERIJ<br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.</div>

PA1RKT https://www.pg540.org/wiki/index.php/Hoofdpagina 2018-11-05T21:26:09Z

<p>PA1RKT: </p> <hr /> <div>__NOTOC__<br /> '''Dit is de project Wiki van de projectgroep .540'''<br /> <br /> Voor de [http://www.qsl.net/pa0sny/vijfveertig.html homepage van de .540 klik hier].<br /> <br /> [[Huisfrequenties]]<br /> <br /> === Activiteiten informatie ===<br /> Om op de hoogte te blijven van de activiteiten van de projectgroep 540, abboneer u dan op de nieuws emaillijst.<br /> Voor instructies zie: [[E-mail]]<br /> == Activiteiten ==<br /> * [[Dag voor de Radio Amateur (DvdRA) 2014]]<br /> <br /> == Projecten ==<br /> * [[Universele Zender Project]]<br /> * [[Nokia Repeater]]<br /> * [[Lima SDR]]<br /> * [[Offset parabool antenne met patch straler voor 13 cm (WiFi) ]]<br /> * [[Stralers voor 23 cm, 13 cm en 3 cm voor in parabool ]]<br /> * [[Opzet DVB-S Print voor Raspberry PI ]]<br /> <br /> * [[SETUP-DATV DVB-S Print for Raspberry PI in the English language ]]<br /> <br /> * [[Grafische interface voor LEANDVB ]]<br /> <br /> * [[DVB-S zender met 1x Raspberry PI3 en RPIDATV ]]<br /> <br /> * [[ Experimenten met parabool antenne's voor ontvangst 10 GHz (D)ATV ]]<br /> <br /> * [[ Het PG540 Spotnik Netwerk ]]<br /> <br /> == Aantekeningen ==<br /> * [[USBTV ruis op monitor]]<br /> * [[LNB overzicht]]<br /> * [[Huisfrequenties]]<br /> * [[FPGA development kits]]<br /> * [[Digilite-ZL]]<br /> * [[Digilite-Raspberry Pi 2x2]]<br /> * [[Software defined radio]]<br /> * [[PLL LNB]]<br /> * [[HackRF notities]]<br /> * [[USRP B200]]<br /> * [[DVB-S]]<br /> * [[DVB-S2]]<br /> * [[DVB-S USB ontvanger Hauppage DEC3000]]<br /> * [[GnuRadio]]<br /> * [[Digitale ingang]]<br /> * [http://www.atv.watch Digitale (D)ATV streams NL en WWW Global * tip!]<br /> * [[LimeSDR interface to SVXlink using GNUradio]]<br /> * [[DVB-T 2 Mhz Ham-Mode instellingen op PI6ZDM]]<br /> * [[Yaesu FT-2311 23cm FM]]<br /> <br /> == Andere sites van de 540 groep ==<br /> * [http://www.qsl.net/pa0sny/vijfveertig.html Homepage]<br /> * [http://www.hotforum.nl/forum/index.php?go=showsubject&amp;name=punt540groep&amp;id=123562 Forum]<br /> * [http://www.hotforum.nl/forum/punt540junkbox/ Junkbox forum]<br /> * [http://pg540.blogspot.nl/ PG.540 blog]<br /> <br /> = Hulp =<br /> <br /> Raadpleeg de [//meta.wikimedia.org/wiki/NL_Help:Inhoudsopgave handleiding] voor informatie over het gebruik van de wikisoftware.</div>

PA1RKT https://www.pg540.org/wiki/index.php/Yaesu_FT-2311_23cm_FM 2018-11-05T21:21:27Z

<p>PA1RKT: Aantekeningen en belevenissen met de FT-2311 (10W 23cm RXTX uit 1988, Japanse versie)</p> <hr /> <div><br /> STEP/RASTER<br /> Onze Japanse versie (FT-2311, niet de FT-2311R) heeft 10/20 KHz raster.<br /> De EU en USA versies hebben 12,5/25 KHz raster.<br /> <br /> Raster wordt bepaald door kristal in de PLL feedback loop. Dit kristal wordt door 1024 gedeeld en dan wordt de fase vergeleken. <br /> In de FT-2311R zit een 12.8 MHz kristal --&gt; 12.8M/1024 == 12.5 KHz step<br /> In onze FT-233 zit een 10.24 MHz kristal ---&gt; 10.24M/1024 == 10KHz step<br /> De microprocessor stuurt de benodigde getallen.<br /> <br /> Laspadje 3 en 4 bepalen de uitlezing en de getallen die de processor berekent:<br /> 3 dichtgesoldeerd = 10/20 KHz raster, 4 dichtgesoldeerd = 12.5/25 KHz<br /> <br /> CTCSS printje FTS-12<br /> FTS-12 printje, bestaat uit een 8 bits schuifregister dat een 6 bit getal (dus maximaal 64 mogelijkheden) naar een processortje stuurt dat de toon genereert en op TONE lijn zet,<br /> Het schuifregistertje klokt 8 bits getal in (dus serieel op het CLK signaal) en op STB (Strobe) schuift hij het een parallel 8 bits register in zodat het op de uitgangen terechtkomt.<br /> De processor op het printje decodeert ook, het krijgt AF in vanaf de hoofdprint.<br /> Enable/schakel signalen zijn erg spartanisch met schakelende transistors uitgevoerd.<br /> Ook de squelch schakelt gewoon audio uit naar massa via een transistortje.<br /> <br /> RESET<br /> Op control panel (frontpaneel, alle schroeven er uit schroeven :-) zit rechts een RESET mogelijkheid (2 pinnetjes kort verbinden). Heeft me veel geholpen als de processor door slechte batterij weer eens in ongedetermineerde staat opstartte. <br /> <br /> CR2032 BATTERIJ<br /> Zit op het control panel (daarvoor moeten alle schroefjes van de behuizing er uit ;-) - heeft soldeerlipjes.</div>

PA1RKT