Trying to get Synchronous Serial Mode w/ Manchester encoding to work (so far getting only noise)

Hi Richard,

Someone has been assigned to look into this. They will get back to you. 

Regards,
Siddanth

It is absolutely necessary to use SmartRF Studio to generate your settings, as a lot of registers has values found during characterization and cannot be calculated using an equation, as for example is the case for frequency data rate etc.

Alos, it is not possible to use Manchester mode in serial mode. If your data is Manchester encoded and you use serial mode on your receiver, you need to do the Manchester encoding in SW on the received data. This is clearly stated in the data sheet:

Below are SmartRF Studio generated settings for the following parameters:

// Address Config = No address check 
// Base Frequency = 869.199707 
// CRC Autoflush = false 
// CRC Enable = false 
// Carrier Frequency = 869.199707 
// Channel Spacing = 199.813843 
// Data Format = Synchronous serial mode 
// Data Rate = 1.001 
// Deviation = 4.943848 
// Device Address = 0 
// Manchester Enable = false 
// Modulated = true 
// Modulation Format = 2-FSK 
// Packet Length = 255 
// Packet Length Mode = Infinite packet length mode 
// Preamble Count = 4 
// RX Filter BW = 60.267857 
// Sync Word Qualifier Mode = No preamble/sync 
// TX Power = 0 
// PA table 
#define PA_TABLE {0x50,0x00}

static const registerSetting_t preferredSettings[]= 
{
    {CC110L_IOCFG2, 0x0B},
    {CC110L_IOCFG0, 0x0C},
    {CC110L_FIFOTHR, 0x47},
    {CC110L_PKTCTRL0, 0x12},
    {CC110L_FSCTRL1, 0x06},
    {CC110L_FREQ2, 0x20},
    {CC110L_FREQ1, 0x31},
    {CC110L_FREQ0, 0x4D},
    {CC110L_MDMCFG4, 0xF5},
    {CC110L_MDMCFG3, 0x37},
    {CC110L_MDMCFG2, 0x00},
    {CC110L_MDMCFG0, 0xE5},
    {CC110L_DEVIATN, 0x14},
    {CC110L_MCSM0, 0x18},
    {CC110L_FOCCFG, 0x16},
    {CC110L_RESERVED_0X20, 0xFB},
    {CC110L_FSCAL3, 0xE9},
    {CC110L_FSCAL2, 0x2A},
    {CC110L_FSCAL1, 0x00},
    {CC110L_FSCAL0, 0x1F},
    {CC110L_TEST2, 0x81},
    {CC110L_TEST1, 0x35},
    {CC110L_TEST0, 0x09},
};

BR

Siri

Siri said:

It is absolutely necessary to use SmartRF Studio to generate your settings

This is a major problem because I have no Windows machine, and there is apparently no Linux (or Mac) version of SmartRF Studio.

Maybe it is an idea to make an online version of SmartRF Studio, where community members can enter parameters to obtain the necessary register settings?

Siri said:

Below are SmartRF Studio generated settings for the following parameters:

Unfortunately, those settings offer only limited improvement. The clock line now shows a continuous (although very jittery) signal instead of 8-bit bursts, and the data line (top) still only produces random noise:

I noticed one thing, however:

When I power up and initialize the receiver while a carrier signal (869.200000 MHz) is present, these lines remain silent (both low), so the receiver at least responds in a way.

But when I turn the carrier off, the above signals return, and show no response at all when I turn the carrier back on again.

I could reprogram the carrier source to modulate the carrier without switching it off, to see if the modulation shows up on the data channel, but that of course does not change the behaviour that it does not respond if a carrier is not present at power-up.

Would you have any idea what causes this behaviour?

Anyway, thank you for your answers so far!

Best regards,

Richard

After doing some more testing and modifying the transmitter to switch modulation on and off, there is encouraging progress:

• When modulation is active, I see a coherent signal on the Data output, and, somehow
• When the carrier is switched on, the receiver now responds at all times - also after power-up (this is a bit strange, because this didn't appear to work yesterday).

Question: what is the best way to mute the noise that I see when no carrier is present?

I think I can sort out the Manchester decoding next - if I'm correct, I have to double the Data Rate to obtain the correct output (the 1 kHz data rate is specified for the payload stream, not the Manchester-encoded stream).

Thanks for the help so far already!

Best regards,

Richard