Zyg

About

Username
Zyg
Joined
Visits
489
Last Active
Roles
Member
Points
1
  • Software graphics bug

    The thin black space above "the green / red color" turns white when the AGC threshold value is set under the AGC tab.

    If the the AGC Threshold is set all the way to the left then there is no white line. Slide the AGC threshold to the right and you will see the white line appear.

    Bruiser
  • Typical DRM SNR for decode?

    WINB is using half of their 10 kHz signal bandwidth for DRM. That means, obviously, that their DRM signal is only 5 kHz wide. DRM was designed with a specific number of modes. The only mode where a 5 kHz DRM BW is specified is in the LW or MW bands for simulcast purposes, where an analog 5 kHz wide AM signal is transmitted next to the 5 kHz wide DRM signal.

    WINB uses a combo signal that is non-DRM 5 kHz data together with a 5 kHz DRM signal. This is a non-standard DRM transmission as it is used in the SW bands (DRM specifies simulcast only for LW and MW bands, not SW).

    Now follows a very, very, simplified explanation of DRM and its bandwidth requirements.

    The way DRM was designed is that a default 10 kHz wide DRM signal uses 64-QAM modulation. DRM has an integrated Forward Error Correction (FEC) in the signal. For tougher propagation conditions where a 64-QAM signal may suffer decoding problems, the use of 16-QAM is "permitted". The 16-QAM signal is of a lower audio quality, i.e. uses less information bits, than the 64-QAM but still requires the 10 kHz bandwidth. This is because the 16-QAM signal bit stream now uses a stronger FEC to help fight the poor conditions. The tougher FEC requires more information bits, which are used to occupy the space that has become available with the use of the lower quality audio.

    A DRM 5 kHz BW signal has only enough space for a 64-QAM signal but does not have any space for the more robust 16-QAM type FEC. That is why WINB cannot use 16-QAM on their combo transmission.

    Furthermore, that is why the 64-QAM 5 kHz DRM BW is only meant for simulcast in the LW and AM bands (where the propagation problems for broadcast purposes are not as severe as for shortwave).

    Now why is WINB using this non-standard combo DRM signal on shortwave? The FCC filing, made by WINB, describes a linear amplifier that is fed by a DRM exciter but does not specify another data signal except to show in a block diagram a "data" input. It appears that the use of non-DRM data was meant to be hidden from the narrative.

    It is speculated that this non-DRM data is to be used for latency arbitrage purposes where the ability to send financial trading information faster across to Europe than via fiber optic transatlantic cables is the goal.

    DRM was designed to provide high quality audio and other multi-media broadcast products. We have not had good experience with this system in North America. I do remember listening to my first reception of high quality music in stereo from Germany in 2006 on the 80 meter band. That transmission from Deutsche Welle was using 64-QAM and it was spectacular. The use of 64-QAM wasn't "overly optimistic" provided the reception was in the designed broadcast coverage area. Europe had numerous good examples of high quality reception of 64-QAM transmissions.

    -Zyg- AF4MP
    ka9q
  • New KiwSDR can't access local Browsers [fixed, power quality issue]

    My KiwiSDR now works well even with the long wire antenna on the ground, in several broken pieces, after a recent storm!

    Didn't have to do anything (SSH) to the Beagle just plugged in the power and it immediately started to download the software update.

    The original BeagleBone green has no problems and therefore I will not take advantage of the kind reimbursement offer. I need to find a good deal on a barefoot KiwiSDR board to go with the lonely Beagle!

    Thanks for all the help it has been sincerely appreciated.

    Now I have to go and work on getting my Linux Dream program to decode xHE-AAC just as the KiwSDR does!

    -Zyg- AF4MP
    Powernumpty
  • New KiwSDR can't access local Browsers [fixed, power quality issue]

    Well I just installed the new BEL power module in an old computer ATX power supply case, adjusted the output voltage to 5.2V and plugged in the KiwiSDR.

    When checking 192.168.1.89:8073 I received the following message:



    Beginning to look good!

    73,

    -Zyg-
    Powernumpty
  • New KiwSDR can't access local Browsers [fixed, power quality issue]

    You are correct the thermostat is wireless, glad you pointed that out - I wasn't thinking correctly when I submitted that ping.

    So here is the ping to the wired connection of one of Directv mini-genie client receivers in the house:



    -Zyg- AF4MP
    Powernumpty