AX5031 parameter setting and SDK

I have a DVK-BASE-2-GEVK with MOD5031-868-2-GEVB, but the software development environment, AXGEN2 and AXRADIOLAB, don’t appear to support this combination. Is there a SDK for this combination?

I am trying to come up with a register setup for the AX5031 to achieve the following:

915 MHz carrier
Manchester encoding
ASK modulation, no shaping
1 MBPS data rate
Raw data mode, legacy mode
256 bits to transmit, which equates to 32 off 8 bit bytes
No pre or post amble.

And have come up with the following to work with the MOD5031-868-2-GEVB

CRCINIT[0-3], 0x0
FSKDEV[0-2], 0x0
TXPWR, 0x07
FREQ0, 0x01
FREQ1, 0x00
FREQ2, 0x30
FREQ3, 0x39

Do the above make sense?



Hi Bob,
you are correct, AXGen2-RadioLab (Software: AX5051) is the SDK developed for the AX5051 only and does not directly support the AX5031. For the AX5031, the tool we have available is the AX-ParamCalc (Software: AX5031), a GUI tool that helps generating the correct register settings for your application.

There is a way to make projects generated on AXGen2-RadioLab run on our DVK2c-Main+MOD5031, but it`s more of a hack and full MASTER-SLAVE examples do not fully work (using an AX5051 as receiver, since AX5031 is a transmitter only). Yet for transmitter only debugging purposes, this may be a valuable strategy.

To make the code run on the AX5031 you will need to modify the Easyax5051.c inside the COMMON folder of the project created in AXGen2-RadioLab. As shwon below, comment the lines #1585 and #1586 in the axradio_init(void) function to avoid exiting the code when the AX5031 is used:

    if (ax5051_reset())  //comment to run on AX5031
         return AXRADIO_ERR_NOCHIP;

In addition, there is a bug preventing AXSDB to flash directly the board from AXGen2-Radiolab. (the bug is that the GUI looks for AXSDB within an “AXSEM” folder rather than ”ON Semiconductor”). Therefore use the GUI to generate the projects, but flash via AX-Codeblocks by clicking on “edit MASTER/TEST” (or opening the project folder in Codeblocks).

Hi Georgi

Thanks for the response. I have a follow-up regarding the register settings. The AX5031 data sheet pages 15 and 16 define the AX5031 registers. Using the AxParam tool for the AX5031, it defines a number of registers which are NOT in the data sheet.
These are:
#define AX5031_REG_IFMODE 0x08
#define AX5031_REG_FEC 0x18
#define AX5031_REG_PLLRNGCLK 0x2e
#define AX5031_REG_XTALOSCCFG 0x51
#define AX5031_REG_PLLVCOI 0x72
which are set to 0x00, 0x00, 0x03, 0x00 and 0x04 respectively.
Do these registers exist on the AX5031 and if so are these the correct values?

I am using the AX5031 in raw mode with Manchester encoding, and do not want any preamble; is this possible?



Hi Bob,
in general the AXParamCalc tool provides you with the most optimal register settings for the selected PHY/Framing. This includes application dependent registers, performance registers, and calibration registers. For each class, some registers may not be fully documented in the AX5031 programming manual because they are not meant to be trimmed by the user code, but are rather defined during production and/or automatically calculated by AXParamCalc with no user interaction required.

All the registers from your list are present in the AX5031 and must be programmed as suggested by the tool.

Regarding Manchester encoding, this is not a problem for the AX5031, and if you use raw mode (FRMMODE=0x00) then whatever bit you load into the FIFO and commit will be sent out (without preamble/sync word stuffing).

Hi Georgi
Thanks for the update. I have set the AX5031 registers according to the AxParam tool apart from the data rate which has been increased to 1Mbps (AxParam only allows up to 600kbps) - see attached file which has the register settings. Currently I am seeing 4 zero bits being sent before the data I have loaded into the AX5031 fifo.
For example if I load 4 bytes of data into the AX5031 fifo, say 0xAA, 0x55, 0x88, 0x11 then transmit, the over the air data is 0x0A, 0xA5, 0x58, 0x81. This is seen both in my receiver and on a scope. So the number of bits transmitted is correct at 32, just a leading 4 bits of zero??
I have repeated this test with varying numbers of bits and it is always the same; the number of bits transmitted is correct, with the bit sequence offset by the 4 leading zeros and the last 4 bits in the fifo disappearing.
How do I disable this apparent 4 bit pre-amble which shouldn’t be there in raw mode?


ax5031-registers.c (2.8 KB)

Hi Bob. I am not sure what is causing these 4 bits “leakage” into the air. Have you tried to drop the datarate or to set another modulation schema? Do you see these 4 bits also wen disabling the manchester encoder? Please also be sure that the FIFO is fully emptied before loading your packet (check FIFO EMPTY field in FIFOSTAT register).

Hi Georgi. I am not testing for FIFO empty normally as I am setting the Clear FIFO bit in FIFOCNTL2. I have done a separate test:
set the Clear Fifo bit;
printing the fifo status and the fifo is empty; loading 32 bytes to the fifo via the SPI bus;
printing the fifo status and it is now full with no under/overrun;
reading the fifo back via the SPI bus and all bytes are correct.
I de-select the chip select after each write, but do not leave any specific time between writes.
I have not tried reducing the data rate or another modulation schema as my application has to interface with a legacy system which uses manchester at 1mbps air bit rate.

Hi Georgi
I have done further investigation and it appears that the initial 4 or 5 zero bits are the transmitter going active before the first byte is loaded from the fifo into the transmit buffer. So the sequence is:

  1. setup the ax registers according to the output from axparam
  2. load the fifo with the data to be transmitted
  3. set the pwr register to transmit
  4. then we get the initial zero bits before the fifo loaded data gets sent

So what needs to be set to ensure the transmitter doesn’t go active until the first byte from the fifo is loaded into its buffer?



Hi Georgi

Attached is a scope trace from sending 4 bytes from the AX5031 in raw mode at 1000kbps air bit rate Manchester encoded.

The byte sequence is 0xE1, 0xAA, 0x22, 0x00

You can see from the trace that 5 unwanted and un-programmed leading zero bits are sent and that only 5 of the trailing zero bits are sent before the automatic transmitter cut off based on FIFOCTRL2 bit 0 being set to 1.

I get the same result from an AX5051 with the same settings. I have also tried at half the air bit rate, i.e. 500kbps and the result is the same - 5 leading unwanted zero bits.

This problem is now very urgent as we are required to go into formal testing.