Posts by G0MJW

    G0MJW: 8PSK modcodes are not supported in version 2.0.10. They were first introduced in version 2.0.12

    But you are right about the UI Design. Many Laptops have 1366x768 as a resolution, but the window is about 947 pixels high. Never thought about high DPI displays. I'll also address this problem soon.


    I'll release a new version (2.0.13) today with a few fixes. In summary these are: 8PSK short frame support, GUI cleanups (and new tooltips), and support for offset tuning by clicking the right mouse button. There is also an overlay showing transponder bandwidth requested by DB8TF.

    There is also a 100% performance update for FIR filtering (atleast on my CPU). These two changes will be useful for future extensions like multi transponder decoding.

    Hi Marko


    Thanks. I have two laptops with 4k screens - they are getting much more common. I found 2.12 shortly after posting earlier. I am having trouble getting anything to lock and I don't know why. The signals are strong enough on my large dish. It's a puzzle.


    What am I doing wrong?






    Mike

    My problem Tony is very simple. It doesn't work. It might work for you but it doesn't work for me.


    Now if we knew why that is the case we might be onto how to solve it.


    For the record the latest version doesn't work for me either. Looking at your screenshots the settings are the same so I think it has to do with CPU or OS.


    The other problem is the application doesn't seem to have the correct high DPI compiler settings enabled so it's quite hard to see what some settings are.


    Mike

    Can Pluto already spend the required frequency for the DATV uplink ??


    I did not read any of you from an upconverter ....


    Greeting Andi

    Andi - the Pluto covers 70MHz to 6GHz TX / RX on its own. There is no need for an up-converter, or indeed down-converter from the LNB IF. The output is quite low, so it's a good idea to include an amplifier with band-pass filtering, on TX to be clean and on RX to avoid overloading by strong out of band signals.


    Mike

    H265 so possible?

    I only tried H265 via UDP, which contains mpeg generated by OBS using my nividia card to save CPU encoding. Sending H265 this way works well from 33ks upwards. H264 can be done via RTMP from OBS with the same firmware.


    Here are the settings I use - some of these depend on the symbol rate. The UDP is captured by a script on the Pluto.



    33ks in 8PSK.



    This is not working reliably yet. This is useful for terrestrial bands, eg 10m, 6m, 4m, 2m where getting good quality DATV into 50kHz bandwidth would enable many things. QO-100 is a fantastic resource.


    I am conscious in the UK we have the 71 MHz and 146 MHz experimental allocations but this is not the case in other countries. To access these bands the regulator was clear that more of the same, FM repeaters, SSB etc were not acceptable. DATV and other experimental modes are demonstrating real innovation. So far, DATV is the only one that has really taken off but I'm sure there are other things to try out on QO-100


    Unless we continue to show innovation we are likely to loose our prime allocations. DXing, Churches, Windmills, Summits, Islands, Lighthouses and Trains on the Air does not impress the authorities.

    I use a pluto for both narrow band and wideband. No need for an expensive up/down converter. PA, dish, dualband feed and locked LNB. That's about it.


    Pluto + SDRConsole for narrow band

    Pluto+ F5OEO firmware and OBS for the DATV

    Minitiouner for RX DATV

    It's not working - not wishing to be too critical but the gui interface is confusing and the fonts do not fit in the boxes. The DPI scaling is all messed up. Quite a bit of work needs to be done on the interface. I have not managed to decode anything yet. 8PSK turns out not to be supported in this version. I thought it was?


    For the dual power meter I used an ADS1115 16 bit ADC on a breakout board. About €3 on ebay etc. These have I2C interfaces and there is a library supporting reading the data. They have their own voltage reference.


    Mike

    Arduino code for power meters is quite easy given the many libraries available. You might want a better ADC for precision but for most applications the built in ADC is fine if properly referenced. Don't rely on the 5V supply as a reference. I bodged this together with an Arduino, a TFT a few resistors and a zener diode in case of accidents with the reference voltage.





    This is an Andrew 2.3-2.4 GHz PA with an Arduino doing status monitoring, protection, PTT sequencing and a small bar graph.



    You can calculate VSWR, drive a real meter and if you want implement things like peak hold or show double the real power to stop people talking it up too much in contests.



    All quite easy as the hard work - hardware drivers, fonts etc. is already done for you. The tricky bit is the gui menus - the above uses a dual Bird coupler and can cope with different power heads, calibration factors etc.


    Mike

    You can and yes the LNB still needs to be modified or some other way to get the IF into the SF8008 tuning range. However, the receiver at the moment will happily capture signals MHz away from the set frequency, so it generally captures the strongest signal of the right symbol rate. There needs to be a further update to prevent this or setting to a finer frequency does not help as much as it could.

    Satellite via QO100 shouldn't count for DXCC because there is no propagation skill. If you build the capability to work one station then you have capability to work them all. Working as many different stations as you can is valid but that's not DXCC. It shouldn't matter where those stations are and all are equally valued, which is the antithesis of DXCC. Let's evolve beyond HF DX.

    I realise you said the camera works.


    I have modified my nanoencode.sh but you should have something like below. If you add a -v to the gst-launch-1.0 command it might be more informative. It looks like it is not capturing the multicast but the debug information is not the same as I see so I don't quite understand. This could be a network issue or it might be a compatibility problem with the HDMI and LKV373A.


    Mike



    case "$CODEC" in

    "H264")

    gst-launch-1.0 udpsrc address=$VIDEOSOURCE_IP_ADRESS port=$VIDEOSOURCE_IP_PORT !

    video/mpegts \

    ! tsdemux name=dem dem. ! queue ! h264parse ! omxh264dec ! nvvidconv \

    ! "video/x-raw(memory:NVMM), width=(int)$VIDEO_RESX, height=(int)$VIDEO_

    RESY, format=(string)I420" \

    ! omxh264enc vbv-size=15 control-rate=2 bitrate=$VIDEOBITRATE peak-b

    itrate=$VIDEOPEAKBITRATE insert-sps-pps=1 insert-vui=1 cabac-entropy-coding=1 pr

    eset-level=3 profile=8 iframeinterval=$VIDEO_GOP \

    ! "video/x-h264, level=(string)4.1, stream-format=(string)byte-stream" !

    mux. dem. ! queue ! mpegaudioparse \

    ! avdec_mp2float ! audioconvert ! audioresample ! 'audio/x-raw, format=S

    16LE, layout=interleaved, rate=48000, channels=2' \

    ! voaacenc bitrate=$AUDIO_BITRATE ! queue ! mux. mpegtsmux alignment=7

    name=mux ! fdsink \

    | ffmpeg -i - -ss 8 -c:v copy -max_delay $PCR_PTS -muxrate $BITRATE_TS -c:a copy -f mpegts -flush_packets 1 -metadata service_provider="QO-100" -metadata service_name=$CALL -streamid 0:256 $ffmpegoutput


    ;;


    "H265")

    gst-launch-1.0 udpsrc address=$VIDEOSOURCE_IP_ADRESS port=$VIDEOSOURCE_IP_PORT ! video/mpegts \

    ! tsdemux name=dem dem. ! queue ! h264parse ! omxh264dec ! nvvidconv \

    ! "video/x-raw(memory:NVMM), width=(int)$VIDEO_RESX, height=(int)$VIDEO_RESY, format=(string)I420" \

    ! omxh265enc vbv-size=15 EnableTwopassCBR=1 control-rate=2 bitrate=$VIDEOBITRATE peak-bitrate=$VIDEOPEAKBITRATE preset-level=3 iframeinterval=$VIDEO_GOP \

    ! "video/x-h265,level=(string)high5,stream-format=(string)byte-stream" ! mux. dem. ! queue \

    ! mpegaudioparse ! avdec_mp2float ! audioconvert ! audioresample \

    ! 'audio/x-raw, format=S16LE, layout=interleaved, rate=48000, channels=1' ! voaacenc bitrate=$AUDIO_BITRATE \

    ! queue ! mux. mpegtsmux alignment=7 name=mux ! fdsink \

    | ffmpeg -i - -ss 8 -c:v copy -max_delay $PCR_PTS -muxrate $BITRATE_TS -c:a copy -f mpegts -pat_period 0.5 -metadata service_provider="QO-100" -metadata service_name=$CALL -streamid 0:256 $ffmpegoutput

    Try a different HDMI source. There seems to be a problem with gstreamer launching. I will check


    Mike


    Here is what I see:


    ./jetson_nano.sh

    I run on Nano

    DVB ShortFrame

    Frame Size=16200

    Net TS bitrate input should be 472949


    VideoBitrate = 272316

    VideoPeakBitrate = 299547

    DVB ShortFrame

    Frame Size=16200

    Net TS bitrate input should be 472949

    Using live mode

    Reference clock 40.00 MHz

    LimeSDR-Mini Library 19.04.0-gae075ca8 Firmware 6 Gateware 1.30 Temperature 45.00

    LMS_GetSampleRate() return : 1331999.983106

    TXLPF set to 5.000 MHz (requested 1.798 MHz [out of range])

    ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers

    built with gcc 7 (Ubuntu/Linaro 7.3.0-16ubuntu3)

    configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/aarch64-linux-gnu --incdir=/usr/include/aarch64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared

    libavutil 55. 78.100 / 55. 78.100

    libavcodec 57.107.100 / 57.107.100

    libavformat 57. 83.100 / 57. 83.100

    libavdevice 57. 10.100 / 57. 10.100

    libavfilter 6.107.100 / 6.107.100

    libavresample 3. 7. 0 / 3. 7. 0

    libswscale 4. 8.100 / 4. 8.100

    libswresample 2. 9.100 / 2. 9.100

    libpostproc 54. 7.100 / 54. 7.100

    Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active

    TX LPF configured

    With Calibration

    Set TX gain to 0.950000

    Calibrating Tx for 2.5 MHz (requested 1.7982 MHz [out of range])

    Tx calibration finished

    sample_rate: 1331999.983106



    CoefBufferSize=2

    Underflow 0/130560

    Underflow 25840/130560

    Underflow 23120/130560

    OK - so with the intuitive command found online

    Code
    (zcat $(ls -tr /var/log/apt/history.log*.gz); cat /var/log/apt/history.log) 2>/dev/null |  egrep '^(Start-Date:|Commandline:)' |  grep -v aptdaemon |  egrep '^Commandline:'

    I find what I have installed manually on the nano


    Commandline: apt-get install -y git g++ cmake libsqlite3-dev libi2c-dev libusb-1.0-0-dev netcat

    Commandline: apt-get install -y libfftw3-dev

    Commandline: apt-get install nano

    Commandline: apt-get install buffer

    Commandline: apt-get install ffmpeg


    and later on


    Commandline: apt-get -y dist-upgrade

    Commandline: apt-get -y install git htop nano

    Commandline: apt-get install v4l-utils


    Commandline: apt-get install -y curl build-essential libpcre3-dev libpcre++-dev zlib1g-dev libcurl4-openssl-dev libssl-dev


    I hope this helps


    - what happens when you run jetson_nano.sh ?

    I can't recall the exact steps I took many months ago now but I recall I stated from a fresh install and ran the dvbsdr code. There was an error but it wasn't a problem. The nano uses gstreamer, not ffmpeg for encoding. If I can find a way to say what I have installed I will post.


    Mike

    To clarify - ffmpeg is not used for encode but it is used to create the transport stream. all this magic is in the nanoencode script in the include directory.

    I can't recall the exact steps I took many months ago now but I recall I stated from a fresh install and ran the dvbsdr code. There was an error but it wasn't a problem. The nano uses gstreamer, not ffmpeg for encoding. If I can find a way to say what I have installed I will post.


    Mike

    I have been travelling this week. I had similar problems but the lime was fine. You might need to reflash the firmware. A good check is with SDRConsole. Don't give up so easily. The cutting edge is always a challenge. That's why we are here.


    Mike