Posts by G0MJW

    All I did was run the two executables on the git hub, then Droidcam appears in the OBS tools menu. If you run it, there is a virtual webcam with the names "DroidCam Video" and "Microphone (DroidCam Audio)"

    I run a script which I have coped above. You can't use DATV Easy as it seems to have the source names wired in, but it will only be a matter of changing those and re-compiling so the developer won't have too much to do. The only difference is it is necessary to set the resolution and audio rate required or Driodcam won't know what to send it and will default to probably 640x480. This is what the command segment above does. It requests 1280x720 video and 48kHz audio.

    droidcam works fine with the phone webcam, but virtualcam on obs 27.2.4 is used to transmit the whole screen of obs to pluto!

    there are 2 different functions, or at least with obs 28 it is not possible to communicate between OBS and DATV Easy!

    Please look at the actual link! IF you were to do so you would find that Droidcam does both these things., with different applications. DATV easy will need to be updated, but it is a very minor update to the name of the sources.

    Even so, people will need to upgrade eventually. The built in MPEG Transport Stream Generator and H264/5 codecs are not really suited to our means. It would be so much better if we could find someone able to develop a DATV plugin for OBS that would generate a transport stream. This would save messing about with OBS Record or RTMP streaming or Virtual cameras and would probably fix the lip sync issues that also often occur.

    Incidentally, DroidCam has a virtual camera output, with audio, that works with OBS. It is quite easy to use.

    For those with intel CPUs of recent vintage, a batch script like this may prove useful.

    c:\ffmpeg\bin\ffmpeg -f dshow -video_size 1280x720 -rtbufsize 100M -i video="DroidCam Video" -thread_queue_size 512 -f dshow -i audio="Microphone (DroidCam Audio)" -vcodec hevc_qsv -bf 0 -pix_fmt nv12 -b:v 220k -r 15 -preset slow -profile:v main -acodec aac -aac_coder twoloop -ar 48000 -ac 1 -b:a 32k -f mpegts -muxrate 325k -streamid 0:256 -streamid 1:257 -metadata service_provider="YOURCALL" -metadata service_name="YOURNAME" -max_delay 2500000 -pcr_period 40 -pat_period 0.4 "udp://"

    once suitably edited for name, callsign and IP address might be useful. As usual edit muxrate and video rate to suit the symbol rate. The above assumes 325kb/s which would work with 250ks 2/3 FEC.

    The video size parameter is important as it instructs Drodcam what to send to the codec. You may get away with a smaller buffer but RAM is cheap. Attached an image of it working, sending to VLC, slightly earlier script.

    [Blocked Image:]


    It occurs to me some people may not know how to do this. You need an OTG Ethernet adapter and a Y-cable for power. Don't try to power from the Pluto, it may work but often doesn't, at least not reliably. Pluto will use DHCP to get an IP address from your router. Find out what it is and enter it in SDR Console. Set up will look something like this highlighted:

    The difference is the IP address.


    Of course. Just use a Pluto on your network and connect with WiFi at 5 GHz. I do this all the time. If narrow band, best limit the bandwidth. If DATV lower SRs are better, but in 2021 there is really no need to run 1Ms/s.


    Old thread but there is no lens supplied. The POTY feed is a design, it is not a product. There are people selling implementations of the design and sometimes with lenses that may or may not suit the dish being used. It is necessary to make/buy something that suits the dish focal length. Typically the lens from a Rocket Type LNB works well with satellite TV dishes but these are getting hard to find. The HB9PZK lens in Rexolite is good performer.

    The other common mistake is not understanding the feed and lens needs to be at the focus and simply clamping the LNB with the original clamp and with the POTY sticking 6 inches out in front. That's never going to work and I honestly never thought anyone would make such a mistake, but I was mistaken..


    That's interesting as I appear to be getting full HD out of the OBS camera plugin, at least according to VLC and it certainly looks full HD. However I tend to use lower symbol rates so the limit becomes the channel.

    Using OBS camera is a fudge though, as it record, RTMP etc. The internal (non-plugin) OBS camera didn't include an audio channel, when I asked it hadn't even crossed their minds that this might be useful.

    It would be good if someone could get inside OBS and get it to produce a TS on it's own, the DATV plugin... the developers seem rather against this whenever I have asked about anything like that though you would think there would be a demand outside amateur use. Maybe it just needs a lot of people to ask.


    Well I did wonder. I am not aware it doesn't allow that. It could be Evariste does is automatically. I think you just use the standard commands. If that's actually the case it's simple enough to load the earlier version via the USB drive and eject and apply the standard command. Google should have found this as the top hit, at least it did for me

    Adalm Pluto -New official firmware 0.32

    Advice - use 0.31


    Yes - that's expected if the reference is not of very high quality or it's not being fed in at the right level. Incidentally that LNB looks more like a DRO based one than a PLL based one but I assume it is a PLL. The quality of the 25MHz is critical. Any noise on it is multiplied many times. For DATV use you are often better with a standard unmodified PLL LNB. This often shows up in the MER on the beacon.


    Here is my Bat file for 160kb/s. I see several differences.

    c:\ffmpeg\bin\ffmpeg -f dshow -i video="OBS-Camera" -thread_queue_size 512 -f dshow -i audio="OBS-Audio" -vcodec hevc_nvenc -s 1280x720 -bf 0 -pix_fmt yuv420p -b:v 80k -r 10 -preset slow -profile:v main -rc cbr_hq -rc-lookahead 5 -acodec aac -aac_coder twoloop -ar 48000 -ac 1 -b:a 24k -f mpegts -muxrate 160k -streamid 0:256 -streamid 1:257 -max_delay 2500000 -pcr_period 40 -pat_period 0.4 "udp://"

    You have that extra buffer and a very different network address. I tested this to VLC, it took a good while to appear but worked OK. So then I tried yours, modified to send to It also worked fine. So is it the IP address? Firewall maybe?


    When I do DATV reception using a POTY feeder the MER drops to about 4 vs 10 without POTY. The same poty feeder receive NB fine. I have test various LNB and POTY feeders with out a conclusion. Any proposals or ideas?

    What lens are you using. Do you have it at the focus. The usual reason for this is the wrong lens for the dish or not having it as the focus by trying to reuse the existing LNB mount but not understanding the lens needs to be at the focus, not at some mechanically convenient point dictated by the original LNB holder.

    The reason it works for NB is the transponder noise floor is much higher so what you are losing on receive is not apparent. For DATV, the same effect applies, but only for dishes larger than 1.2m with efficient feeds. Therefore it is much much more critical to adjust the feed correctly. Beacon MER is a good indicator, but bear in mind it depends on transponder loading.

    Very interesting - but the focus of the POTY is not in the same place as the reflector but in the middle of the lens, so it needs to move a few mm back. This is probably why it is worse. That's a challenge mechanically with that feed arm because the reflector gets in the way. The Rocket lens might be better. did you measure the F/D ?

    Well OK - but the POTY was never intended for long focal length dishes so it's not surprising a helix does better. What is the F/D of that dish? It looks like 0.7-0.8 which makes sense for a 4.5 turn helix.

    I see have a VNA so why show VSWR ? It only gives you part of the picture. It simply perpetuates the myth popular amongst HF operators that VSWR is all that matters. It's a parameter but not the only one and not even the most important. We are better than that. From the VSWR I can't tell if the patch is tuned correctly, which will make up to 3 dB difference in the uplink it it's linear instead of circular. The other thing about that POTY is the reflector is not the recommended 105mm circle. It might be OK. I don't know.

    What is surprising is the difference on receive. The Helix should be worse but given that's not the recommended Lens on the POTY. I have never recommended anything like that, I can't see how it could work. If you don't follow the instructions, it won't work so well. HB9PZKs design is several dB better, as it the originally recommended Rocket Lens. If it really is so very many dB worse there is something not right - like the focal position or the wrong lens, or both. The feed looks too far forwards but that's not easy to tell from the Photo. The gain of LNBs varies widely so it's signal above noise that matters. A number in dBm is meaningless without knowing the gain. Was there some gain calibration done here?