Posts by G8UGD

    The best I can receive the DATV beacon when completely empty of activity and a good clear sky is 10.4 MER on my 1.05m offset dish, I spent some time checking it for alignment and that was the best I could get. The software I use is Longmynd, I use a POTY feed and a standard crystal'd LNB .

    One extra thing I have in there is a 749 ish MHz is bandpass filter to reduce the front end noise window slightly to the Minitiouner-express. I think that when tested it gave me a 0.5dB improvement in MER with it to without it. One other station on the SAT at present, cloudy sky and I am at MER 10.0. So for my best guess with a similar size dish and standard LNB no filters would be at MER 9.5 and you would have a good RX.


    But if you are using an gpsdo external clock then surely you should not be setting xo_correction as the external clock should be an accurate?


    The code 'fw_setenv maxcpus' worked for me if I remember correctly. Using the command: -

    cat /proc/cpuinfo

    on the command line previously showed just processor 0, after running it showed processor 0 and processor 1, so I had both cpu's running. Do not expect processor 1 and processor 2. Unless that is things have changed with later revisions of Pluto hardware as numbers start with 0

    On the frequency error using 'fw_setenv xo_correction' again I am making assumptions of how I read it all, that the normal clock frequency was 40000000, so if that is what you wanted then you do not put any number in there and just use fw_setenv xo_correction

    fw_printenv prints all the system variables going.

    The way I check this is as follows

    from the pluto command prompt I use fw_printenv | grep correction

    If I get no response then it is running at 40000000 but if I set it to be 39999900 then I get a response.

    So for example: -

    # fw_setenv xo_correction 39999900
    # fw_printenv | grep correction
    # xo_correction=39999900

    or removing the correction.

    # fw_setenv xo_correction
    # fw_printenv | grep correction

    Perhaps someone with more knowledge can confirm what I am saying, I am happy to use this on my Pluto, but asking someone else with their own is a different matter. Caveatt emptor!


    Hi Phil;

    Just suggesting that you use something SDR# initially to pin point what your actual LNB offset is. SDR console needs this to be as accurate as possible to allow for locking to the beacon. I found if I was a couple of hundred KHz off on the offset then I could not find the beacon in the bottom waterfall to lock to. But yes using SDR console as a basic receiver at 740 ish MHz is fine, you should still be able to find it, I would just suggest initially that you get the widest spectrum you can to find it. It can be quite easy to find if you use get an idea from the sat finder page on

    Looking at your first picture I notice you are not using SDR console as I expected, normally I would see a screen with the frequency across the top being in the 10GHz region using a receiver with the prescribed offset, then you have the opportunity to use the beacon lock etc.


    Hello Phil; I think that Ulrich is pointing you in the correct direction, the chances are that you are not on the correct receive frequency. But could be a good few hundred KHz off frequency.

    I use a standard crystal controlled PLL LNB and it does not provide an accurate 9750MHz frequency, mine is around 9749.437MHz so just over 560KHz off and this will still drift over time and temperature.

    Not sure if you are able to try Gqrx on a linux PC or if that would work on Windows, or even SDR# should be able to help you, wind the Sample rate out initially to 2400000 b/s to give yourself the widest receive spectrum and have a hunt around moving up and down in 500 KHz steps until you find it and then fine tune.

    For example is is a current screen shot of mine centred on the middle beacon in Gqrx.

    Once you find the middle beacon knowing that the centre frequency of it is 10489.750 you can then a calculate better the offset of your LNB and then use that within SDR console as your frequency off-set.

    As I said this will change with temperature and sometimes quite quickly, SDR consoles needs to lock on to this to keep things stable.

    Hope this helps get you going.

    Another point give it a little more volts say 13.3 to 13.5 Volts to allow a bit of volt drop down the cable and through the bias T's. I thought the LNB's liked around 13 Volts?


    The above is what I have in mine as well as using the version 0303 F5OEO DATV firmware. So a lot may depend on who's DATV firmware and what version of that you are using. As diferent authors could use different config files?

    As I like to play and test I tend to upgrade/update and try and work out how things work, as said sometimes I end up using the DFU process to get things back to working again.

    Looking at the above I think I am at a later stage official analog devices firmware than yourself, so lets see if anyone with the same as yourself can help.

    In your windows explorer, can you make it so that you see the extensions of the files, i.e. so it does not hide the .txt and make sure that these extensions are as expected.

    As I work from Linux it is difficult to remember all the Windows differences, and I just wish to check that the config file is 'config.txt'


    May I ask what version of Pluto you are using? On mine I have found that the IP address can be found in 2 different locations when using an SSH connection, I use 0303 so how much it differs between versions I am not sure.

    1) is in /www/config.txt This on mine does not show the correct settings in-fact shows, mine operates on

    2) is in /mnt/jffs2/etc/config.txt

    This number 2) is the one that needs to be set on my Pluto for it to work and is the config.txt file that is the original analog device one.

    after connecting to the Pluto via SSH terminal

    cd /mnt/jffs2/etc

    ls this is to list the files and I show: -

    config.txt dropbear settings-datv.txt settings.txt strategy.json

    cat config.txt to display the contents, if you wish to change the USB ETHERNET address this is where I would do it.

    I use nano config.txt and edit the file while is SSH terminal cntrl X and y and y to save the file and exit.

    I think as I have done going through all the updates from one version to another I have left over settings in various places, perhaps I need to do a complete start from scratch using 0.32 firmware and the DFU process, but that is for another day.

    As an aside to this I have just help another user this evening with a corrupt Pluto so had to go through the DFU process to recover it. It was found that if we jump straight in and install version 0201 firmware that we could not use the Windows method of configuring it as you would a USB drive, the config.txt would not hold, we had to back track and go back to the analog devices 0.32 firmware again, then change the ip address within config.txt, which would then stay put when powered off and back on before installing version 0201.

    Sorry this reply is a long one and I hope you did not fall asleep in reading it, hope it helps but make yourself aware of how to recover things with the DFU routine. I have used this 4 or 5 times myself with playing around and messing things up.


    Did you manage to discover the password of the unit prior to the update.

    My device had quite an old firmware version , but thankfully used the same login details, this I checked by doing a Telnet into the encoder prior to performing the update, so it gave me a bit of confidence before doing it.

    I did find a site where firmware was available ENC_V2.38.201216, this being prior to Evariste's patch. I was wondering if after downloading the firmware, one could use the Encoders program to downgrade from V2.41 to V3.38 and then apply the patch. It does recommend using a Windows program of IPCManager to determine firmware and which of two versions to download a D or E version? Mine being a D version found from serial number.


    With thanks to Chris, I can now get the Pluto control spectrum to work with my method of operating, it now talks to my modified G7JTT Linux script to drive Longmynd on a standard PC. Chris has done a patch which he says will be included in future releases. So it gives users more options if wishing to operate under a Linux desktop. Especially if like me one is using the Minitiouner-express.


    Hello Benno.

    For me it is all via ethernet and all on the same local network of 192.168.1.X, gateway of I had a thought that my router did not allocate the IP address as it is set as a static IP so would not be in the DHCP table, but even after adding them had no luck.

    Think I will go back to the previous alpha version and stick to quicktune/livetune for a while. I am just not clever enough.


    OK I am stumped, I have run from a Windows 10 PC both quicktune and the alpha Pluto version and can not get the new pluto version to work, I have tried Microsoft Edge, and firefox browsers.

    On the Linux machine I am running the following script to monitor port 6789. This is the machine that drives longmynd.

    As I say it can see the string from live tune but not the new Pluto firmware. If anyone can suggest something to either assist in finding an error or point out what I am doing wrong it would be appreciated. I can be contacted via email if required.


    I am having similar issues to PA3FBX, but I run everything under Linux, again with a Minitiouner Express, and using a script to drive Longmynd software.

    I believe that it can not be down to using a Minitiouner Express rather than the Pro hardware as you are only sending a message to the software package, Minitiune.

    The first line is from QO-100 WB Multi Quick tune version 0.9b to the Minitiouner software or in this case my script:-


    Unfortunately I am getting no output from the Pluto with the latest alpha software. I am trying to fathom out if this is down to a different operating system or something else such as blocked ports etc. Or my settings.

    I drive direct to the PC's own address, 192,168,1,194 and use port 6789. The gateway is


    Personally I would hope to never reboot Pluto with power to the PA system, but if it gives the options for home use and for portable use then it must be a good option.

    Perhaps the settings.txt could be used to store many configuration options in the future such as the Minitiouner control and other future enhancements.

    Question as I have not used any of the patches, but can I ask do they survive a reboot or power down back up again? Is there a how-to in making a patch, one I looked at had pluto.php saved in the /www directory and all saved in pluto.frm which was all in If that makes sense?

    Again thanks for the hard work.

    And a question where perhaps you need pm me, is there a donation to all contributors, I used to donate to Evariste when he was doing all the work, now there seems to be a team effort?


    I believe that mod to make the unit "On-Air" is a requirement of those wishing to use the Pluto without a computer but putting out a signal when when powered up. So useful for the portable guys. There was a post about it on the forum some time ago, I forget the title of the thread.

    Thanks for the update in the firmware regarding disabling the spectrum, I mentioned that to F5UII a few days ago, if you are using the PlutoSDR for 70cms or for 23cms etc from home you will also be typically connected to the internet some times to arrange comms or use Skype etc as talkback, in these situations the Spectrum is not wanted as it could be a distraction, or simply taking bandwidth from a slow connection etc.

    I am very grateful for the people developing the software and can appreciate that it is generally QO-100 that is driving the updates, modifications and general thinking. The satellite is probably the greatest driver for Amateur TV going at present. So don't mind the gripes every now and then, from this end I really do appreciate the people that can, and are doing the software for it.