Adalm-Pluto Rev D

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

    Code
    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: -

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

    or removing the correction.

    Code
    # 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!



    Adrian

  • Hi Detlev and Ardian,


    Thanks for your comments.
    It seems to me that I should explain my situation a little more detailed.


    - both cpu are acitve => "fw_setenv maxcups"

    - external reference is activated "fw_setenv refclk_source external"

    - external gpsdo is connected running on 40 MHz


    Using Pluto on QO-100 I realised that there is a shift of approx. 11 kHz between Rx and Tx. Thus, I assumed that there is a correction set for external reference. Due to this I checked this parameter with the following command I found elsewhere in the net

    "cat /proc/device-tree/clocks/clock@0/clock-frequency | xxd"

    => it returns the clock frequency as hexadecimal number and tells in my case that frequency is set to "39999716" which could explain the shift when feeding the Pluto with exactly 40 MHz.


    Therefore I tried to set it to 40 MHz using "fw_setenv xo_correction 40000000"

    After this I checked again with "cat /proc/device-tree/clocks/clock@0/clock-frequency | xxd" which still returned "39999716"


    Now I tried "fw_printenv | grep correction" Adrian mentioned and Pluto returned "40000000"

    Maybe everything is fine now. I tell more as soon as I have tested.


    73 and thanks again for your help.


    Happy Easter,


    Ansgar


    Btw. I checked "https://wiki.analog.com/university/tools/pluto/devs/booting" before but honestly it is not that easy to understand for newcomers.




  • Hi Ansgar,


    you transmit on 2400 MHz and receive on 10500 MHz, where is the 11 kHz shift?


    Detlev


    PS Do you use a Leo Bodnar GPSDO?


    Digital PLL allows main output reference frequency to have almost any value between 450Hz and 800MHz.

    The second output frequency depends on the first output due to a common internal clock, if you need individual flexibility, multiple mini GPS units may be a better choice. If both outputs have the same frequency their relative phase shift can be adjusted. This can be used, for example, to generate two signals with 90° phase shift for use in I/Q mixer.

  • I just have tested my setup of Pluto with Leo Bodnar GPSDO and everything is working fine now and I had some nice contacts via QO-100.


    The shift I was talking about was a shift between Rx and Tx in SDR-Console when both windows were synchronized and show the downlink frequency. Before I changed the setting for reference correction the CW-beacon was at 10.489,495 MHz and rx and tx frequency were not tranceive. My signals were approx. 11 kHz beside expected downlink frequency.


    Now beacon is at 10.489,500 MHz and Tx and Rx are working transceive.


    Thus, my conclusion is:

    - There was a correction set for external reference in my Pluto.
    - "fw_setenv xo_correction 40000000" changes it to 40 MHz

    - everything is perfect now.


    Thanks again Detlev and Adrian you have been of great help in this matter.


    Ansgar

  • Thats the same i have on my Pluto after i feed an external 40MHz Signal into my Pluto.

    This works.
    fw_setenv xo_correction 40000000

    "cat /proc/device-tree/clocks/clock@0/clock-frequency | xxd"

    gives me the old correction in hex which was "40.000.023"

    "fw_printenv | grep correction"

    give me the correct Freuquency

    xo_correction=40000000


    Volker



  • Hi, here you can see how to communicate with your Pluto:

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    The moment you toggle to an extern clock and there is none, the Pluto will stop and will be no more accessible until you connect an extern clock.


    Detlev

  • I have just received my rev D Plutos from Digikey.
    Loading F5OEO's DATV firmware (0303) I realized that some of the functions were not working well. ("On Air" indicator, PTT button on the Controller page)
    It looks that there is some compatibility issue.

    I applied the patch (ver. 1.9) from is0grb - from


    Here


    seems to fix this nasty problem - I think. Please note that the patch have two versions: rev B and rev C-D. Use the rel C-D.



    73 de Béla