Re: DUO up/down band change


Andy G4JNT
 

AH-HA____
Missed that.     192 + rssi etc.   or 0x32 + ....
and just checked the vol. settings and other bytes and yes, it's all been carefully thought-out to avoid 0x01 31 and 0x00 30 sequences - neat. 

As I never use dual VFO, I failed to appreciate my keypad only changes VFO-A.  If I read the status,  it could be arranged to change whichever VFO is in use.  But not really worth it for  microwave and VLF operations 



On Sun, 12 Jul 2020 at 17:28, Neil Smith G4DBN <neil@...> wrote:

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.



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
_._,_._,

Join EladSDR@groups.io to automatically receive all group messages.