Difference between revisions of "Custom DATV Firmware for the Pluto"
(41 intermediate revisions by 9 users not shown) | |||
Line 1: | Line 1: | ||
===Forward=== | ===Forward=== | ||
− | This is | + | This is an article originally published in CQ-TV 266, re-published here to promote experimentation. Thanks to Paul M0EYT for writing it. |
− | Before loading the custom firmware, it | + | Before loading the custom firmware, it is necessary to extend the frequency range of the Pluto. The instructions for this can be found on this web page: https://wiki.analog.com/university/tools/pluto/users/customizing. Scroll down to the bottom section "Updating to the AD9364". |
+ | |||
+ | You may also wish to enable the second CPU core as described here: https://www.ph4x.com/pluto-sdr-hack-2nd-cpu-core/ | ||
+ | |||
+ | ===Suitable Pluto Firmware=== | ||
+ | |||
+ | This article was written about a Pluto using F5OEO's "for the brave" Pluto firmware (FIRM2101RC of 5 February 2020). Extract the firmware from this zip file [[:File:FIRM2101RC.zip]] and follow the instructions on this web page '''VERY CAREFULLY''' [https://wiki.analog.com/university/tools/pluto/users/firmware#mass_storage_update Analog Devices Firmware Upgrade Instructions]. The Pluto must already have been modified for extended frequency range, and it is worth enabling the second processor. | ||
+ | |||
+ | There are more recent DATV Pluto firmware versions available with increased functionality, but they may not work as described in this article, or with the Portsdown transmitter. | ||
+ | |||
+ | ===Introduction=== | ||
+ | |||
+ | Firstly, I'm not a DATV expert but have played with a number of SDR's over the years since my first SDR-14 back in 2005. I dabble in GHz stuff so have a rough idea what I'm doing but that’s about it! I like to make sure I learn something new related to technology every day, so both DATV and the PLUTO SDR fulfil this. I got the PLUTO after borrowing one from Jules, G0NZO and being super impressed by it, for the price you really cannot go wrong. It works out of the box, has TX+RX and with a few minutes work, can have its frequency range extended to cover 70MHz to 6GHz, not bad at all, plus it runs Linux internally (Linux pluto 4.14.0-g387d584d434e). The receiver is great and I used the loan unit to listen to all Bell Hill beacons up to 5.7GHz with something akin to a paperclip pushed into the RX port. | ||
+ | |||
+ | [[File:Pluto.png|105px]] | ||
+ | |||
+ | This is the unit in question, shown to the left, it’s very compact at 5"X3"X1" with separate transmit and receive SMA sockets and a pair of micro USB sockets for I/O and power. It draws 400-420mA when idle or transmitting. When the QO100 narrow band transponder was used with PLUTO SDR's for TX, some frequency drift was apparent. It turns out that the integral TCXO wasn’t particularly good, so it's worth replacing it with a decent TCXO such as the ASTX-13-C-40.000MHz-I05-T which you can get from Mouser. This solves all frequency stability issues (well most...). For the ultimate stability, external GPSDO reference is still recommended. | ||
+ | |||
+ | ===First Steps=== | ||
+ | |||
+ | I've built the Portsdown filter/modulator unit for DVBS which performs really well, but was looking for a non-Lime-SDR method (it’s a long story) of generating DVBS28PSK and 16/32APSK DATV. I saw on Twitter that OM Evariste, F5OEO (@F5OEOEvariste) of RPiTX fame was developing replacement firmware for the PLUTO that would provide DATV capabilities as well as some other goodies, so I pinged him a message and asked if I could beta-test the firmware. The firmware arrived quickly.The 'pluto.frm' file is copied into the root directory of the PLUTO mass storage memory, where the configuration files exist. Once copied up, 'eject' the device, don’t unplug the USB but use the software eject. The blue LED1 in the PLUTO will rapidly flash for 3 or 4 minutes then reboot and the mass storage device will reappear. Full details on this process are at https://wiki.analog.com/university/tools/pluto/users/firmware - don't unplug it during the flash process for obvious reasons; you might brick it. With the SDR still plugged into your PC, you can browse to the internal web-server by pointing a browser at http://192.168.2.1 with all being well you should see something similar to the next screenshot: | ||
+ | |||
+ | [[File:Screenshot.png|450px]] | ||
+ | |||
+ | Having updated the firmware and confirmed that it was working, next was the start of a massive learning curve…What would I need to use to generate some 'digital stream' with video in it? What software should be used? How does the stream get from the PC to the SDR? How do you set all the parameters needed to generate DATV? How do I get video from my phone camera into the PC? The list of questions was growing the more I looked into this stuff.... | ||
+ | |||
+ | ===Firmware update over LAN=== | ||
+ | |||
+ | BTW you may be wondering how you update the Plutos firmware if you are running it via a LAN connection, well, its pretty simple. Download WinSCP, configure it to point at the IP Address of your Pluto, copy the pluto.frm file up to /root (root home directory). Once done, SSH into the Pluto (download Putty or similar) then execute update_frm.sh pluto.frm this will extract the firmware and update the internal flash memory. Once done, type 'reboot'. When the Pluto comes back up, it'll be at the firmware level just uploaded; this saves having to plug the Pluto into a PC via USB and using the normal firmware update method. | ||
+ | |||
+ | ===Digital Video Source=== | ||
+ | |||
+ | I know John, GI7UGV, as we work in the same industry and know that he's really into DATV, so had a chat with him and within minutes had VMIX (https://www.vmix.com/) installed – this looked like the easiest initial method of doing what I needed; make a PC generate some stream to control the PLUTO. This was pretty intuitive and within half an hour I had a test card source, spitting out the relevant data to the PLUTO. This was done by setting an external RTMP stream target with the following parameters: | ||
+ | |||
+ | URL : rtmp://192.168.2.1:7272/,437,DVBS2,QPSK,333,23,Pass : ,M0EYT, | ||
+ | |||
+ | The above parameters form part of the URL and are parsed by the F5OEO firmware to set the various DATV transmission parameters: | ||
+ | |||
+ | Frequency in MHz: 437 | ||
+ | Mode (DVBS/DVBS2): DVBS2 | ||
+ | Constellation (QPSK,8PSK,16APSK): QPSK (only QPSK is valid in DVBS) | ||
+ | SymbolRate in KS (33-2000): 333 | ||
+ | FEC (12,23,34,67,78...): 23 | ||
+ | CALLSIGN: M0EYT | ||
+ | |||
+ | It's particularly important to look at the RTMP stream definition syntax, probably best to cut & paste the above URL / pass text and then modify to suite your own requirements. With the PLUTO SDR plugged into the USB port of the PC running VMIX, it worked right away and a QPSK carrier was being generated at 437MHz, receivable on the Minitiouner. I had noted that VMIX was not free, so rather than spending hours with IDA, and having noted what John 'UGV had said, I decided to uninstall VMIX and give OBS (Open Broadcaster Software https://obsproject.com/download) a try. Since this is open source, there are no licensing 'difficulties' and although it's not as polished as VMIX, it's fully functional and just works. | ||
+ | |||
+ | ===OBS Basics=== | ||
+ | |||
+ | In OBS the first thing to do is to define the output stream so it points at the PLUTO SDR, so go to settings, stream, and type in the following; obviously tweaking the IP address, modulation parameters and callsign to suit your own environment: | ||
+ | |||
+ | [[File:OBS.png|606px]] | ||
+ | |||
+ | You will be able to see a 'Controls' box docked at the bottom of the OBS window, this is where you press 'start streaming' to enable the PLUTO's DATV output. A green block should appear in the status bar indicating that streaming to the PLUTO is occurring. | ||
+ | |||
+ | Before you jump in and press 'start streaming', you will need to set the streaming bitrate to avoid any overflows between OBS and the PLUTO. Visit http://www.satbroadcasts.com/DVB-S_Bitrate_and_Bandwidth_Calculator.html type in your DVBS/S2 parameters, press calculate, and make a note of the 'Netto TS bitrate' – you want to set your streaming bit rate to about 65% to 70% of this figure. So if the Net TS bitrate is 440Kbps you will want to set your video bitrate to say 286Kbps, better to set it on the lower side. This means that the video plus transport overheads will not cause overflows when streaming data into the PLUTO. Once you are familiar with the various bitrates, and your favourite settings, you will be able to guesstimate the video bitrate in OBS. It is set via 'settings', then 'output', then under the 'streaming' section type your bitrate. I have my encoder set to x264 compression and my audio bitrate set to 64Kbps. With these settings, there are no interruptions in the audio stream and everything works fluidly. | ||
+ | |||
+ | Next, you will need a picture source, so the easiest method in OBS is to go to the 'scenes' dock, press +, enter a name for your scene, such as 'test card'. Next in the 'sources' dock, press +, select video capture device, create new, type in some name and press OK. You should see a 'colour bar / grey fade / bar' test card appear in the 'Preview' window. Ensure that in the 'Controls' dock, you have pressed 'Studio Mode' so you see Preview and Program windows. | ||
+ | Whatever you see in the 'Program' window is the video that is being streamed to your PLUTO. | ||
+ | |||
+ | You can set a number of 'scenes' so that you can quickly select and fade or cut between them. If you have desktop video files these are easy to add. You can create an additional scene and for example put a JPG/PNG image there, or add some desktop video. I found that my camcorder dumped its video out in a .VRO file, never heard of that, but OBS could ingest it and stream it correctly including the stereo audio tracks. | ||
+ | |||
+ | You can also easily add scrolling text messages to overlay across your images, various analogue and digital clocks, inputs from webcams, RTSP CCTV cameras, dancing chicken / cat overlays etc., there are a lots of choices. You probably want to spend a few hours clicking through the various menus to get a handle on the software options and what it can do. I found it fairly easy to set up sources and to be able to chop and change parameters whilst watching the DVB-S2 stream on another laptop. Within OBS it's also worth looking at the various extensions / add-ons that others have written for the platform, these basically are additional features for you to use. You will end up with something similar to my instance: | ||
+ | |||
+ | [[File:OBS Screen.png|585px]] | ||
+ | |||
+ | In my OBS 'scenes' I have an 'rtmp streamer' input, this allows me to use the camera / microphone in my Android mobile phone, along with software called Larix Broadcaster https://play.google.com/store/apps/details?id=com.wmspanel.larix_broadcaster - what this does is streams the video from the phone, but you cannot ingest this directly into OBS since you need an RTMP streaming server. | ||
+ | |||
+ | You could use this mobile app to directly stream to the PLUTO SDR but then all the nice video processing features of OBS are lost. Luckily there is a thread at https://forum.batc.org.uk/viewtopic.php?f=69&t=6179 detailing what needs to be done to make build such a server, you can drop this onto one of your Raspberry PI's and it consumes very little CPU. Basically it uses NGINX HTTP server with an RTMP streamer plugin and just works. Point your phone and OBS at the PI's IP with the port defined in the configuration file, press the various go buttons and video / audio will be streamed from the phone into OBS. | ||
+ | If you can get away from having any analogue video sources in your setup, your overall stream output will be digital from the sensor through to the display at the other end of your QSO. This means that quality will be maintained and you won't have poor quality audio with earth loops / buzzing or video that suffers from typical analogue artifacts. | ||
+ | |||
+ | If you want to stream from a Windows desktop into the RTMP server, that is also easy to set up. Firstly download FFMpeg from https://ffmpeg.zeranoe.com/builds/ - you will then need the capture drive which you can get from http://www.umediaserver.net/components/index.html search for UScreenCapture and download the appropriate version. Once both packages are installed, open a command shell and execute the following; | ||
+ | |||
+ | ffmpeg -f dshow -i video="UScreenCapture" -r 10 -c:v libx264 -b:v 300k -preset ultrafast -b 300k -s 1280x800 -x264opts keyint=50 -g 25 -pix_fmt yuv420p -f flv "rtmp://1.2.3.4:1936/live1/desktop" | ||
+ | |||
+ | the -b:v and -b parameters are video bitrate. -s is capture size and -r is 10 frames per second, adjust to suite your particular setup. I tested this with 333Ksps QPSK and it renders nicely. In OBS you should set up a steam source pointing to rtmp://1.2.3.4:1936/live1/desktop to be able to see your desktop image. | ||
+ | |||
+ | Obviously set the target RTMP server IP address to the appropriate address. If you are using John GI7UGV's nginx RTMP server, you can add another directive to support multiple streams. Your /etc/nginx/nginx.conf might look as follows; | ||
+ | |||
+ | worker_processes auto; | ||
+ | rtmp_auto_push on; | ||
+ | events {} | ||
+ | rtmp { | ||
+ | server { | ||
+ | listen 1935; | ||
+ | application live { | ||
+ | live on; | ||
+ | record off; | ||
+ | } | ||
+ | listen 1936; | ||
+ | application live1 { | ||
+ | live on; | ||
+ | record off; | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | |||
+ | ===System Integration=== | ||
+ | |||
+ | Having thought briefly about how to integrate the PLUTO into my existing QO100 narrow band system, I decided that it would be better to place all of the needed equipment into the ODU since there are already mains, 10MHz ref, LAN, 70cms IF, etc. connections to the outdoor box. | ||
+ | |||
+ | [[File:Pluto Network.png|313px]] | ||
+ | |||
+ | I found an old USB<>Ethernet adapter and an OTG adapter, plugged it into the PLUTO's USB IO port, and a phone charger battery into the PSU USB port, the PLUTO defaults to DHCP so quickly obtains an IP address once its internal Linux OS has booted. | ||
+ | |||
+ | Network operation really is the way to go as it eliminates lots of USB issues and allows multiple sources to use the SDR without having to continually mess around with USB cables and fragile micro-USB connectors. | ||
+ | |||
+ | Matthias DD1US has written up his PLUTO LAN experiences at http://www.dd1us.de/Downloads/Connecting%20the%20ADALM%20Pluto%20to%20the%20Local%20Area%20Network%20v2.pdf which is worth digesting. | ||
+ | |||
+ | In the final system iteration here at the M0EYT ground station, I'll use a good de-noised 5V PSU, the PLUTO will go in a metal box for mechanical stability purposes, and I'll mount SMA sockets with back to back connectors that have the same hole spacing as the SDR, this should ensure that nothing gets broken. | ||
+ | |||
+ | ===PTT output=== | ||
+ | |||
+ | The PLUTO Firmware now supports a PTT output so that when a valid RTMP stream starts, the PTT pin changes state to allow amplifiers etc to be keyed. PTT comes from GPO0 circled in red below; | ||
+ | |||
+ | [[File:20191023_124122.jpg|400px]] | ||
+ | |||
+ | The logic-level output is 0/1.2V which is just enough to drive an optocoupler or transistor, a optocoupler provides isolation between the PLUTO and whatever it is you are controlling. A transistor can drive a relay. | ||
+ | |||
+ | |||
+ | M0EYT used a '356' opto-coupler recovered off an old PCB. Note: During the PLUTO boot process the GPO0 pin toggled from low to high, stays there for 5 seconds, then toggles back to low. No RF output was seen during this toggle etc. | ||
+ | |||
+ | F5OEO used two transistors to gate the GPIO0 and GPIO1 signals such that there is no false triggering on start up thanks to idead of Sigi dg9bfc | ||
+ | |||
+ | [[File:Sequence.jpg|400px]] | ||
+ | |||
+ | |||
+ | G0MJW used F5OEO's suggestion and produced a PCB which connects to the GPIO header. Here is the circuit and what it looks like. There are two variants, one designed to fit on the GPIO header, the other a more traditional mounting: | ||
+ | |||
+ | [[File:Relay1.jpg|400px]] | ||
+ | [[File:RealRelay.jpg|400px]] | ||
+ | [[File:Relay2.JPG|400px]] | ||
+ | [[File:Image.JPG|400px]] | ||
+ | |||
+ | The 5V supply can be taken from a suitable point in the Pluto power supply. Look at the schematic on the Analog web site for more information. C157 seems to work. | ||
+ | |||
+ | [[File:Plutomod.jpg|400px]] | ||
+ | |||
+ | Don't short this out or you will send your Pluto back to the underworld where it will have to judge it's own demise. https://en.wikipedia.org/wiki/Pluto_(mythology) | ||
+ | |||
+ | The relay contacts can be used to control a power amplifier. This control is your problem, but remember the small PCB relay can only switch 500mA and the optocoupler considerably less. | ||
+ | |||
+ | PCBs are available for sale in the BATC member's shop: https://batc.org.uk/category/projecthw/ | ||
+ | |||
+ | Note that with the originally specified relay becoming scarce, the Celduc D71A2100 relay, available as RS Stock No.178-2573 will also work on the low profile PCB, but will require the diode to be fitted on the PCB> | ||
+ | |||
+ | ===RF Topics=== | ||
+ | |||
+ | The RF output level of the PLUTO is pretty low, about -15dBm at 2.4GHz so clearly this needs some amplification to do anything useful with.I decided to look at some of the random amplifier modules I had laying around and see what each did to the output spectrum, in particular the spectral regrowth / shoulders. | ||
+ | All measurements below are taken with the PLUTO generating DVBS2 at 2409.750MHz centre, 8PSK, 333Ksps, 2/3 FEC. | ||
+ | |||
+ | [[File:6 Avantek.png|400px]] | ||
+ | Avantek SA82-2340 | ||
+ | |||
+ | [[File:7 SPF.png|400px]] | ||
+ | SPF5043 + 10dB Pad on o/p | ||
+ | |||
+ | [[File:8 LNA4.png|400px]] | ||
+ | LNA4ALL + 10dB Pad on o/p | ||
+ | |||
+ | [[File:9 3x.png|400px]] | ||
+ | 3 X amp 30~dB gain (+ 10dB Pad on o/p) | ||
+ | |||
+ | [[File:11 Pluto Direct.png|400px]] | ||
+ | PLUTO direct output 8PSK baseline | ||
+ | |||
+ | [[File:10 Pluto 8.png|400px]] | ||
+ | PLUTO 8PSK baseline | ||
+ | |||
+ | From the tests of LNA's to get the PLUTO output up a bit, it appears the more modern devices do not add significant IMD to the xPSK providing they are not over driven. | ||
+ | My current experimental TX line up is a dual FET pre-amp taking the PLUTO output to +5dBm, a secondary PA rated at 20watts running at 30dBm, and then a Spectrian PA, modified as per the CQ-TV article to deliver 45dBm, about 30 watts. Looking at the PSK constellation shows that its relatively clean, and the shoulders either side of the 8PSK are 35dB down which should just about be acceptable. I will try to find one of the Axis-NT amplifiers as that would solve all power problems. | ||
+ | |||
+ | ===Wrapping Up=== | ||
+ | |||
+ | The PLUTO SDR with the F5OEO firmware certainly does offer a simple way to generate DATV from VHF up to the lower microwave bands. For QO100 with a suitable amplifier chain it is ideal and should result in many more users appearing on the wideband transponder. There are no annoying pre-transmission calibration carriers to spatter over the transponder which is nice. A great amount of credit should be given to Evariste F5OEO for his amazing work on this firmware, and I would recommend you donate to his efforts via https://www.paypal.me/f5oeo - something for a decant bottle of wine or two for example! I'm sure that many hundreds of man-hours have been put in to this project so a bit of support won't go a-miss and might even encourage further enhancements.See you on the transponder! Thanks to John GI7UGV for sanity checking this write up ;-) |
Latest revision as of 11:54, 18 August 2021
Forward
This is an article originally published in CQ-TV 266, re-published here to promote experimentation. Thanks to Paul M0EYT for writing it.
Before loading the custom firmware, it is necessary to extend the frequency range of the Pluto. The instructions for this can be found on this web page: https://wiki.analog.com/university/tools/pluto/users/customizing. Scroll down to the bottom section "Updating to the AD9364".
You may also wish to enable the second CPU core as described here: https://www.ph4x.com/pluto-sdr-hack-2nd-cpu-core/
Suitable Pluto Firmware
This article was written about a Pluto using F5OEO's "for the brave" Pluto firmware (FIRM2101RC of 5 February 2020). Extract the firmware from this zip file File:FIRM2101RC.zip and follow the instructions on this web page VERY CAREFULLY Analog Devices Firmware Upgrade Instructions. The Pluto must already have been modified for extended frequency range, and it is worth enabling the second processor.
There are more recent DATV Pluto firmware versions available with increased functionality, but they may not work as described in this article, or with the Portsdown transmitter.
Introduction
Firstly, I'm not a DATV expert but have played with a number of SDR's over the years since my first SDR-14 back in 2005. I dabble in GHz stuff so have a rough idea what I'm doing but that’s about it! I like to make sure I learn something new related to technology every day, so both DATV and the PLUTO SDR fulfil this. I got the PLUTO after borrowing one from Jules, G0NZO and being super impressed by it, for the price you really cannot go wrong. It works out of the box, has TX+RX and with a few minutes work, can have its frequency range extended to cover 70MHz to 6GHz, not bad at all, plus it runs Linux internally (Linux pluto 4.14.0-g387d584d434e). The receiver is great and I used the loan unit to listen to all Bell Hill beacons up to 5.7GHz with something akin to a paperclip pushed into the RX port.
This is the unit in question, shown to the left, it’s very compact at 5"X3"X1" with separate transmit and receive SMA sockets and a pair of micro USB sockets for I/O and power. It draws 400-420mA when idle or transmitting. When the QO100 narrow band transponder was used with PLUTO SDR's for TX, some frequency drift was apparent. It turns out that the integral TCXO wasn’t particularly good, so it's worth replacing it with a decent TCXO such as the ASTX-13-C-40.000MHz-I05-T which you can get from Mouser. This solves all frequency stability issues (well most...). For the ultimate stability, external GPSDO reference is still recommended.
First Steps
I've built the Portsdown filter/modulator unit for DVBS which performs really well, but was looking for a non-Lime-SDR method (it’s a long story) of generating DVBS28PSK and 16/32APSK DATV. I saw on Twitter that OM Evariste, F5OEO (@F5OEOEvariste) of RPiTX fame was developing replacement firmware for the PLUTO that would provide DATV capabilities as well as some other goodies, so I pinged him a message and asked if I could beta-test the firmware. The firmware arrived quickly.The 'pluto.frm' file is copied into the root directory of the PLUTO mass storage memory, where the configuration files exist. Once copied up, 'eject' the device, don’t unplug the USB but use the software eject. The blue LED1 in the PLUTO will rapidly flash for 3 or 4 minutes then reboot and the mass storage device will reappear. Full details on this process are at https://wiki.analog.com/university/tools/pluto/users/firmware - don't unplug it during the flash process for obvious reasons; you might brick it. With the SDR still plugged into your PC, you can browse to the internal web-server by pointing a browser at http://192.168.2.1 with all being well you should see something similar to the next screenshot:
Having updated the firmware and confirmed that it was working, next was the start of a massive learning curve…What would I need to use to generate some 'digital stream' with video in it? What software should be used? How does the stream get from the PC to the SDR? How do you set all the parameters needed to generate DATV? How do I get video from my phone camera into the PC? The list of questions was growing the more I looked into this stuff....
Firmware update over LAN
BTW you may be wondering how you update the Plutos firmware if you are running it via a LAN connection, well, its pretty simple. Download WinSCP, configure it to point at the IP Address of your Pluto, copy the pluto.frm file up to /root (root home directory). Once done, SSH into the Pluto (download Putty or similar) then execute update_frm.sh pluto.frm this will extract the firmware and update the internal flash memory. Once done, type 'reboot'. When the Pluto comes back up, it'll be at the firmware level just uploaded; this saves having to plug the Pluto into a PC via USB and using the normal firmware update method.
Digital Video Source
I know John, GI7UGV, as we work in the same industry and know that he's really into DATV, so had a chat with him and within minutes had VMIX (https://www.vmix.com/) installed – this looked like the easiest initial method of doing what I needed; make a PC generate some stream to control the PLUTO. This was pretty intuitive and within half an hour I had a test card source, spitting out the relevant data to the PLUTO. This was done by setting an external RTMP stream target with the following parameters:
URL : rtmp://192.168.2.1:7272/,437,DVBS2,QPSK,333,23,Pass : ,M0EYT,
The above parameters form part of the URL and are parsed by the F5OEO firmware to set the various DATV transmission parameters:
Frequency in MHz: 437 Mode (DVBS/DVBS2): DVBS2 Constellation (QPSK,8PSK,16APSK): QPSK (only QPSK is valid in DVBS) SymbolRate in KS (33-2000): 333 FEC (12,23,34,67,78...): 23 CALLSIGN: M0EYT
It's particularly important to look at the RTMP stream definition syntax, probably best to cut & paste the above URL / pass text and then modify to suite your own requirements. With the PLUTO SDR plugged into the USB port of the PC running VMIX, it worked right away and a QPSK carrier was being generated at 437MHz, receivable on the Minitiouner. I had noted that VMIX was not free, so rather than spending hours with IDA, and having noted what John 'UGV had said, I decided to uninstall VMIX and give OBS (Open Broadcaster Software https://obsproject.com/download) a try. Since this is open source, there are no licensing 'difficulties' and although it's not as polished as VMIX, it's fully functional and just works.
OBS Basics
In OBS the first thing to do is to define the output stream so it points at the PLUTO SDR, so go to settings, stream, and type in the following; obviously tweaking the IP address, modulation parameters and callsign to suit your own environment:
You will be able to see a 'Controls' box docked at the bottom of the OBS window, this is where you press 'start streaming' to enable the PLUTO's DATV output. A green block should appear in the status bar indicating that streaming to the PLUTO is occurring.
Before you jump in and press 'start streaming', you will need to set the streaming bitrate to avoid any overflows between OBS and the PLUTO. Visit http://www.satbroadcasts.com/DVB-S_Bitrate_and_Bandwidth_Calculator.html type in your DVBS/S2 parameters, press calculate, and make a note of the 'Netto TS bitrate' – you want to set your streaming bit rate to about 65% to 70% of this figure. So if the Net TS bitrate is 440Kbps you will want to set your video bitrate to say 286Kbps, better to set it on the lower side. This means that the video plus transport overheads will not cause overflows when streaming data into the PLUTO. Once you are familiar with the various bitrates, and your favourite settings, you will be able to guesstimate the video bitrate in OBS. It is set via 'settings', then 'output', then under the 'streaming' section type your bitrate. I have my encoder set to x264 compression and my audio bitrate set to 64Kbps. With these settings, there are no interruptions in the audio stream and everything works fluidly.
Next, you will need a picture source, so the easiest method in OBS is to go to the 'scenes' dock, press +, enter a name for your scene, such as 'test card'. Next in the 'sources' dock, press +, select video capture device, create new, type in some name and press OK. You should see a 'colour bar / grey fade / bar' test card appear in the 'Preview' window. Ensure that in the 'Controls' dock, you have pressed 'Studio Mode' so you see Preview and Program windows. Whatever you see in the 'Program' window is the video that is being streamed to your PLUTO.
You can set a number of 'scenes' so that you can quickly select and fade or cut between them. If you have desktop video files these are easy to add. You can create an additional scene and for example put a JPG/PNG image there, or add some desktop video. I found that my camcorder dumped its video out in a .VRO file, never heard of that, but OBS could ingest it and stream it correctly including the stereo audio tracks.
You can also easily add scrolling text messages to overlay across your images, various analogue and digital clocks, inputs from webcams, RTSP CCTV cameras, dancing chicken / cat overlays etc., there are a lots of choices. You probably want to spend a few hours clicking through the various menus to get a handle on the software options and what it can do. I found it fairly easy to set up sources and to be able to chop and change parameters whilst watching the DVB-S2 stream on another laptop. Within OBS it's also worth looking at the various extensions / add-ons that others have written for the platform, these basically are additional features for you to use. You will end up with something similar to my instance:
In my OBS 'scenes' I have an 'rtmp streamer' input, this allows me to use the camera / microphone in my Android mobile phone, along with software called Larix Broadcaster https://play.google.com/store/apps/details?id=com.wmspanel.larix_broadcaster - what this does is streams the video from the phone, but you cannot ingest this directly into OBS since you need an RTMP streaming server.
You could use this mobile app to directly stream to the PLUTO SDR but then all the nice video processing features of OBS are lost. Luckily there is a thread at https://forum.batc.org.uk/viewtopic.php?f=69&t=6179 detailing what needs to be done to make build such a server, you can drop this onto one of your Raspberry PI's and it consumes very little CPU. Basically it uses NGINX HTTP server with an RTMP streamer plugin and just works. Point your phone and OBS at the PI's IP with the port defined in the configuration file, press the various go buttons and video / audio will be streamed from the phone into OBS. If you can get away from having any analogue video sources in your setup, your overall stream output will be digital from the sensor through to the display at the other end of your QSO. This means that quality will be maintained and you won't have poor quality audio with earth loops / buzzing or video that suffers from typical analogue artifacts.
If you want to stream from a Windows desktop into the RTMP server, that is also easy to set up. Firstly download FFMpeg from https://ffmpeg.zeranoe.com/builds/ - you will then need the capture drive which you can get from http://www.umediaserver.net/components/index.html search for UScreenCapture and download the appropriate version. Once both packages are installed, open a command shell and execute the following;
ffmpeg -f dshow -i video="UScreenCapture" -r 10 -c:v libx264 -b:v 300k -preset ultrafast -b 300k -s 1280x800 -x264opts keyint=50 -g 25 -pix_fmt yuv420p -f flv "rtmp://1.2.3.4:1936/live1/desktop"
the -b:v and -b parameters are video bitrate. -s is capture size and -r is 10 frames per second, adjust to suite your particular setup. I tested this with 333Ksps QPSK and it renders nicely. In OBS you should set up a steam source pointing to rtmp://1.2.3.4:1936/live1/desktop to be able to see your desktop image.
Obviously set the target RTMP server IP address to the appropriate address. If you are using John GI7UGV's nginx RTMP server, you can add another directive to support multiple streams. Your /etc/nginx/nginx.conf might look as follows;
worker_processes auto; rtmp_auto_push on; events {} rtmp { server { listen 1935; application live { live on; record off; } listen 1936; application live1 { live on; record off; } } }
System Integration
Having thought briefly about how to integrate the PLUTO into my existing QO100 narrow band system, I decided that it would be better to place all of the needed equipment into the ODU since there are already mains, 10MHz ref, LAN, 70cms IF, etc. connections to the outdoor box.
I found an old USB<>Ethernet adapter and an OTG adapter, plugged it into the PLUTO's USB IO port, and a phone charger battery into the PSU USB port, the PLUTO defaults to DHCP so quickly obtains an IP address once its internal Linux OS has booted.
Network operation really is the way to go as it eliminates lots of USB issues and allows multiple sources to use the SDR without having to continually mess around with USB cables and fragile micro-USB connectors.
Matthias DD1US has written up his PLUTO LAN experiences at http://www.dd1us.de/Downloads/Connecting%20the%20ADALM%20Pluto%20to%20the%20Local%20Area%20Network%20v2.pdf which is worth digesting.
In the final system iteration here at the M0EYT ground station, I'll use a good de-noised 5V PSU, the PLUTO will go in a metal box for mechanical stability purposes, and I'll mount SMA sockets with back to back connectors that have the same hole spacing as the SDR, this should ensure that nothing gets broken.
PTT output
The PLUTO Firmware now supports a PTT output so that when a valid RTMP stream starts, the PTT pin changes state to allow amplifiers etc to be keyed. PTT comes from GPO0 circled in red below;
The logic-level output is 0/1.2V which is just enough to drive an optocoupler or transistor, a optocoupler provides isolation between the PLUTO and whatever it is you are controlling. A transistor can drive a relay.
M0EYT used a '356' opto-coupler recovered off an old PCB. Note: During the PLUTO boot process the GPO0 pin toggled from low to high, stays there for 5 seconds, then toggles back to low. No RF output was seen during this toggle etc.
F5OEO used two transistors to gate the GPIO0 and GPIO1 signals such that there is no false triggering on start up thanks to idead of Sigi dg9bfc
G0MJW used F5OEO's suggestion and produced a PCB which connects to the GPIO header. Here is the circuit and what it looks like. There are two variants, one designed to fit on the GPIO header, the other a more traditional mounting:
The 5V supply can be taken from a suitable point in the Pluto power supply. Look at the schematic on the Analog web site for more information. C157 seems to work.
Don't short this out or you will send your Pluto back to the underworld where it will have to judge it's own demise. https://en.wikipedia.org/wiki/Pluto_(mythology)
The relay contacts can be used to control a power amplifier. This control is your problem, but remember the small PCB relay can only switch 500mA and the optocoupler considerably less.
PCBs are available for sale in the BATC member's shop: https://batc.org.uk/category/projecthw/
Note that with the originally specified relay becoming scarce, the Celduc D71A2100 relay, available as RS Stock No.178-2573 will also work on the low profile PCB, but will require the diode to be fitted on the PCB>
RF Topics
The RF output level of the PLUTO is pretty low, about -15dBm at 2.4GHz so clearly this needs some amplification to do anything useful with.I decided to look at some of the random amplifier modules I had laying around and see what each did to the output spectrum, in particular the spectral regrowth / shoulders. All measurements below are taken with the PLUTO generating DVBS2 at 2409.750MHz centre, 8PSK, 333Ksps, 2/3 FEC.
3 X amp 30~dB gain (+ 10dB Pad on o/p)
PLUTO direct output 8PSK baseline
From the tests of LNA's to get the PLUTO output up a bit, it appears the more modern devices do not add significant IMD to the xPSK providing they are not over driven. My current experimental TX line up is a dual FET pre-amp taking the PLUTO output to +5dBm, a secondary PA rated at 20watts running at 30dBm, and then a Spectrian PA, modified as per the CQ-TV article to deliver 45dBm, about 30 watts. Looking at the PSK constellation shows that its relatively clean, and the shoulders either side of the 8PSK are 35dB down which should just about be acceptable. I will try to find one of the Axis-NT amplifiers as that would solve all power problems.
Wrapping Up
The PLUTO SDR with the F5OEO firmware certainly does offer a simple way to generate DATV from VHF up to the lower microwave bands. For QO100 with a suitable amplifier chain it is ideal and should result in many more users appearing on the wideband transponder. There are no annoying pre-transmission calibration carriers to spatter over the transponder which is nice. A great amount of credit should be given to Evariste F5OEO for his amazing work on this firmware, and I would recommend you donate to his efforts via https://www.paypal.me/f5oeo - something for a decant bottle of wine or two for example! I'm sure that many hundreds of man-hours have been put in to this project so a bit of support won't go a-miss and might even encourage further enhancements.See you on the transponder! Thanks to John GI7UGV for sanity checking this write up ;-)