AX5043 Receiver Configuration

Hello,

I am trying to tune the AX5043 reception chain but I am getting some weird behavior on the Automatic Frequency Control loop.

In my setup, I am transmitting a GSMK-modulated signal (0101 data) at 2.4kbps to the input of the transceiver, while monitoring the value of the TRKRFFREQ register. I have calculated the value of the MAXRFOFFSET to allow a maximum frequency deviation of ± 600 Hz (bitrate / 4). I am also monitoring the decoded bitstream output using the DATA and DCLK pins of the transceiver with a scope. For this test, I am using only RXPARAMSET 0.

The AFC seems to lock to the incoming signal easily when the transceiver is initialized and configured with the RF signal already at its input. When I vary the frequency of the carrier, I can also see the TRKRFFREQ varying accordingly.

However, when the transceiver is configured and initialized without any RF signal at its input, the TRKRFFREQ goes to its maximum value (~600) and doesn’t really move anymore. When I transmit the modulated signal again, it is not able to track it anymore. The only way I can get the receiver to work again is by sweeping the carrier frequency and forcing (hoping) that the AFC will be able to lock again.

Based on what I read, registers FREQUENCYGAINC and FREQUENCYGAIND can be used to tune the gain of the AFC loop, but I haven’t found specific information about how to calculate them.

I tried to change the values of these registers, and I can clearly see that they have a lot of impact on the AFC, but I am not sure exactly how. Could you help me shed some light on how to compute these registers and how they impact the behavior of the AFC? Also, is there any other possible cause for this problem?

Any help would be appreciated.

Thanks in advance

I did some extensive testing with the MSK demodulator and the AFC few years back, and i can confirm exactly the same behaviour as you describe.
If I start it up with the signal present it works great, but as soon as the AFC has lost track it is not able to come back, or it can even get lock at a false frequency offset.

I went very far to document the issues, and report them but it was during the axsem to onsemi transition, so my requests were probably lost.

Ultimately I gave up using MSK, and took the performance penalty of running only in FSK mode. I would love to share my findings with you and get in contact. But unfortunately the bulk of my work was don’t at another company and I don’t have access to anything other than my memory.

I hope we can try and raise some attention to the MSK problem at onsemi. Becausd right now, it does not work with AFC.

Hi Johan,

Thanks for your reply and sorry for the (very) response. In a way, I am happy to see that more people have problems like the ones I am facing. It means that it’s not just me…

It is really frustrating though, we have developped a whole application/product around this transceiver and I cannot get uplink to work reliable. It would be great if we could get some feedback from ON Semiconductor about this.

Still, about your comments, does the AFC work well with another modulation like BSPK? I haven’t tried, but I think I will do it to see if I get any better results…

Thanks!

We have a reliable link working with this transceiver. But not in MSK / coherent detection mode.

It means a little higher cost in the link budget. You can contact me privately at johan at space-inventor.com we should have a chat and share experiences.

Best regards
Johan.

Hello, I was wondering if you went through this appnote. It does not mention MSK but it does reprogram FREQGAINA/B/C/D in order to receive FM signals https://www.onsemi.com/pub/collateral/and9313-d.pdf.
In particular note that:

  • FREQGAINA/B: Gain of the baseband frequency recovery loop; the frequency error is measured with the phase detector. These registers control the bandwidth of the RF Frequency Offset Loop (affecting RFFREQ register)

  • FREQGAINC/D: Gain of the RF frequency recovery loop; the frequency error is measured with the phase detector. These registers control the bandwidth of the Frequency Offset Loop (affecting FREQ register)

Changing these values will change therefore the loop dynamics and this is why you saw an effect in your measurements. RadioLab will set these values by default with the following,:

MODULATION PHASEGAIN0 FREQGAINA0 FREQGAINB0 FREQGAINC0 FREQGAIND0 AMPLGAIN0
ASK 0 10 10 31 31 6
PSK, MSK, OQPSK 3 10 10 31 31 6
(G)FSK 3 4 10 31 31 6

Hello Giorgi,

Thanks a lot for your help. Yes, I had read this app note and it helped a bit to understand the frequency control loop works, but still, it didn’t really solved the problem…

About your message, registers FREQGAINC and D control the RF tracking loop so changing it would affect the measurements stored in the TRKRFFREQ register, right? It’s not clear to me the difference between registers FREQGAIN A/B and FREQGAIN C/D.