Posts by G0MJW

  • Octagon SF-8008 with low SR

    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.

  • Split mode operation

    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.

  • Jetson Nano and Lime SDR mini

    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

  • Jetson Nano and Lime SDR mini

    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

  • Jetson Nano and Lime SDR mini

    OK - so with the intuitive command found online

    Code
    1. (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 ?

  • Jetson Nano and Lime SDR mini

    Quote from G0MJW

    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.

  • Jetson Nano and Lime SDR mini

    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

  • Jetson Nano and Lime SDR mini

    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

  • Jetson Nano and Lime SDR mini

    No - that look OK. But need to see the next part about multicast really.


    Can I check you are using this software ? https://github.com/F5OEO/dvbsdr and you are running ./jeston_nano.sh from the scrips directory and not another script?


    Also you have:


    #Could be VIDEOSOURCE_PICAMERA, VIDEOSOURCE_USB_CAM , VIDEOSOURCE_IP

    VIDEOSOURCE=VIDEOSOURCE_IP

    VIDEOSOURCE_IP_ADRESS=239.255.42.42

    VIDEOSOURCE_IP_PORT=5004




    Mike

  • Software DVB-S demodulator

    Claudio I was asked that question before and I had thought I had made it clear that I do not measure the phase noise directly. I measure it by its effect. I am sorry but it is all I can manage at the moment without access to an RF test lab. There is a well known relationship between the phase noise and the error rate but there is also white noise present. To a very rough, no warranty given or implied, usual disclaimers apply, approximation you can assume the effect of phase noise on a QPSK demodulator is just like that of amplitude noise. This is so rough and wrong that many RF engineers will be at this point shouting "YOU CAN'T DO THAT". Which to be fair is true but the approximation close enough for telling if something is adequate, bad or really bad. The constellation is also useful as if the points look randomly distributed around the ideal phase noise probably is not the problem but if they are in arcs around the points it probably is.


         


    However, you can measure Phase noise directly by analysing the baseband spectrum of a pure carrier that the LNB has down-converted to IF. The problem is you end up measuring the weakest link, and from the satellite, the signals are just not strong enough to get the dynamic range needed to differentiate between the oscillator phase noise and the white noise (unless the LNB is really bad). Therefore a local very pure reference signal is needed, e.g. a good crystal oscillator multiplied up to 10.5 GHz. Even then, with an IF around 1 GHz an SDR is probably not good enough so this IF would need to be mixed down to baseband with another good oscillator. Then look at the output amplitude and phase with a direct sampling RX like a CloudSDR, SDRIQ etc. Spectravue would be a good tool I think.


    This is complicated and needs careful calibration and attention to detail to make the measurement setup as clean as possible.


    Fortunately, there is an easier way to infer the phase noise degradation, measure it and minimise it. Basically, if the MER does not meet the expectations of the SNR, the difference is probably the phase noise.

  • TCXO Performance issues

    Quote from PA3FYM

    G0MJW Mike, changing the LO to 9.5 GHz results in a higher IF, lying more into the spec band width of the chip. Couldn't that be the 1.6 dB MER difference ?

    No I don't think so as I also found other things that worked, even just a few Hz from 25 MHz made a difference, which makes me suspect it is related the Leo Bodnar reference division ratios. I also tried 24 MHz but that was not very good. The PLL multiple is 390 for 9.75 GHz (424 for 10.6 GHz) so if you wanted a 430MHz If you would want about 25.79MHz. I tried 23.59 MHz which puts the transponder on 23cms but it wasn't very good. Best for me seems to be 9.5 GHz.


    Other LNBs may be and probably are different.


    Mike