Well-spotted that man !!!!!!!!!

I've copied in an identical page with DUO spelt correctly - both will be accepted now.

Have a look at the PDFs at http://g4jnt.com/FDM-DU0_Notes.htm

(yes, that is a zero)

Neil G4DBN

On 13 Jul 2020, at 02:33, Paul Andrews <pandrews@...> wrote:

Where can I learn.about aliasing products.  I own 2 x FDM Duos.  #1 is on my 432 / 1296 MHz EME system.  I use a 28 MHz IF and transverters.  This is a awesome system for EME.

My #2 Duo is configured for 144 MHz and interconnected to a 10 GHz transverter.

This is my 1st try with 10 GHz so there might be multiple items to optimize.

Is using the Duo at 144 MHz a poor choice for weak signal work?

73 - Paul - W2HRO

On Sat, Jul 11, 2020, 14:57 Andy G4JNT <andy.g4jnt@...> wrote:

When using alias products on receive, ( eg at 144MHz), what does the level meter show when set to dBm ?

ie.  does it automatically take into account the SINC(X) loss

Andy

www.g4jnt.com

When using alias products on receive, ( eg at 144MHz), what does the level meter show when set to dBm ?

ie.  does it automatically take into account the SINC(X) loss

Andy

www.g4jnt.com

The values in the 1024-byte spectrum have a range of 50 to 255 decimal, so you can't get a value lower than 0x32 as part of the spectrum, so the spectrum control block header pattern and parameter control block headers cannot be sent as spectrum values.

The values in the VFO A/B are encoded as 8-byte pseudo-ascii, so can't have a 0x01 or 0xF3 for example.

To guard against sync loss, you read in the number of bytes specified in the header and if any of the ASCII values are out of range, bail out of decoding and look for a new header.

It's a while since I messed with interfacing, but it worked OK and seemed robust, but the test would be to cause some glitches and see if the decoder can recover.  If you read in a 1024 byte spectrum and byte 3 was 0x00 because of a long glitch, then so long as your parser can restart decoding at that point and doesn't have to discard the buffer, you would be able to recover gracefully.  Otherwise just ditch the lot and scan for another valid header frame.

Neil G4DBN

On 12/07/2020 16:48, Andy G4JNT wrote:

Having looked at the EXTIO protocol I'm now a bit confused.

There is an attempt to make a header for Spectrum and  Parameter data  ,   0x00 30 [30 30 34 30]   and  0x01 31 [3F 31 30 30] respectively, but as far as I can see it is not necessarily unique;   there is nothing to stop that series of bytes appearing in either the body of the spectrum data, which is just 8 bit byte values, or in some of the parameter fields.

I feel sure I've missed some point somewhere, as it clearly does work in practice with the Blue Duo etc,  but why doesn't framing go wrong ?

If the frame pattern is unique, then extracting just small amounts of parameter data is merely a case of looking for the frame, then counting bytes until the wanted ones arrive.   A small circular buffer a low as 31 bytes long would suffice for that - and any small processor like a PIC  could do it.

Andy

www.g4jnt.com

On Sat, 11 Jul 2020 at 08:24, Giovanni Franza <gfranza@...> wrote:

[Edited Message Follows]

Hi Andy,
the band of the spectrum is 192kHz and the bins are of 192/1024 kHz, because 192 kS/s is the sampling rate at which the internal SDR operates.
On the spectrum you can see the effect of the windowing as "shoulders" on the ending of the spectrum.
In BlueDUO I use and display only 160 kHz because I prefer not to show the part of band afflicted by the windowing.
Do not trust the spectrum timing. It is computed when the internal cpu has time, not on precise istants, even if the timings are more or less those.
Reards,

Giovanni - HB9EIK

_._,_._,