How to Configure MC12311 Transceiver in Packet Mode?

[vahidelc86]

Hi all,

I'm trying to configure the Freescale MC12311 sub-1 GHz Transceivers to work in packet mode. I have studied the datasheet and the reference manual several times, but I just don't understand how to set/configure the preamble, sync word, payload, etc.

To put it simply, I do the following procedure:

• Transmitter: enable the TX mode, enable packet mode, set Freq., BW, BitRate, etc. and finally write data to FIFO
• Receiver: enable the RX mode, enable packet mode, set Freq., BW, BitRate, etc. and finally read data from FIFO

However, this doesn't work! The PacketSent interrupt flag sets successfully in the transmitter, however, the PayLoadReady interrupt flag in the receiver doesn't get set!

Nevertheless, I have already tested the device in continuous mode to send/receive stream data. The connection was successful, however, the range was limited to 30 meters, despite enabling the internal power amplifiers and increasing the RX sensitivity threshold. The circuit results in noisy signals over 30 meters, and I don't know why!

Anyway, I would be thankful if anybody helps me figure out the minimum necessary steps to configure the MC12311 transceiver to send/receive data in packet mode.

Your time and help would be highly appreciated.

I look forward to hearing from you.

[georgepeterson]

It's been quite an interesting journey getting the MC12311 to function as my TPMS receiver. The transmitter I'm using is the FXTH87 and, unlike the FXTH87, the MC12311 requires an intermediate codebase to interface between the RF transceiver and application code. I'm not a software guy and I can't speak in depth but I can say that SMAC is one of these intermediate codebases.

Writing a SMAC interface would be a very big task if you had to do it yourself, so Freescale provides BeeKit to do it for you. The task of writing the SMAC code is complicated by the task of making it compatible with several different hardware platforms and, further, several different operating modes on each hardware platform. This last task of making it cross-compatible is, I believe, somewhat incomplete.

The MC12311 has two main packet modes, variable length and fixed length. Each packet mode requires slightly different information to be contained in the packet that is being received over the air. When in variable length packet mode, the received packet must contain a length byte which tells the receiver how many bytes of data are in the packet. In fixed length packet mode this length byte is not needed, however, payload length must be programmed into the PayloadLength configuration register.

The problem with the SMAC code is that the RxPacket typedef is hard coded to always need a length byte regardless of which packet mode is being used. Further, the RxPacket is also hard coded to always need a destination address byte even if you are not using address matching. After being received, the RxPacket is processed by several PHY functions that are part of the SMAC and if the length byte and destination address are not present, in  precise locations within the packet, the RxPacket is processed in such a way that the RxStatus bit becomes corrupted. There are functions that need a "success"  indicator for RxStatus and if it is corrupted, "success" is not indicated and packets are no longer received.

As far as I can tell, there is no easy way to eliminate the need for a length byte and a destination address byte. In battery operated applications like TPMS where every ounce of power is desired to be conserved and used wisely, it's inefficient to force the transmitter to send two extra bytes that are not needed or wanted.

Cesar | Jason | Luis (or anyone who knows),

Is my description accurate?

Is there an easy way to remove the need for length and address?

From what I see, the SMAC code will essentially need to be re-written in order to use the MC12311 fixed length packet mode; otherwise variable length with destination address must always be used.

[georgepeterson]

I'm still not clear if the MC12311 can truly be used in Fixed Length Variable mode due to the way the SMAC RX packet is hard coded to always need a length and address byte, however, I've put the address byte to good use. As it turns out... it works beautifully as the tire location address :-)

The length byte I guess will need to remain as an extraneous inclusion in the data packet; I don't see how this can be recommissioned for other uses if the SMAC code needs it to accurately describe the payload length. The RF module in my transmitter is by far the most power hungry module and it would still be nice to not have to transmit unneeded bytes. I haven't worked out this portion of the power budget but in the grand scheme of things over the life of the transmitter battery, I'm hoping this doesn't degrade battery life by more than a month or two.

[georgepeterson]

After playing around with the settings I take back anything bad I said about this tool. I assumed the default settings out of the box would be fine but not so, they need some tweaking. After getting the TX board and RX board properly aligned, they work fantastically with no hiccups. I can send 1,000 packets and receive 1,000.

I do have some other comments about the tool, however, since this thread seems to have been resolved and\or died out I'll start another.

[CesarM]

Hi George,

First of all, great news that you were able to get the tool working. Sorry to hear that it was not a straight forward process.

I would like to try to reproduce the behavior you observed with the tool and the board, in order for me to do this, could you please share with us the configuration parameters that you used for the Radio Utility GUI.

I have attached a video on how to get the configuration files. Once you have saved the configs, please share the .ncfg files.

This video has been deleted

[georgepeterson]

Hi Cesar,

Unfortunately my code has progressed and I no longer have the setup that was producing the behavior I mentioned above. I still don't fully understand exactly what the problem was but I kinda think the UART data for the USB link was getting corrupted or not working right with my hub.

I removed the Radio Utility GUI and now monitor packet reception directly in CodeWarrior. The MC12311 has been flawlessly receiving everything my FXTH87 has been transmitting.

-george

[CesarM]

Hi George,

Perfect :smileyhappy: good to hear.

Good luck with your development.

[georgepeterson]

Maybe the MC12311 is not as bad as I was starting to think. At 915 MHz it does NOT like a 5kHz deviation frequency; when increased to 100 kHz it now shows a 1:1 reception of transmitted packets (for each one transmitted, one is received). However, the MC12311 receiver now shuts down at seemingly mysterious times. When 1,000 packets are transmitted, it'll receive up to a point. Sometimes the receiver shuts down after ~500 packets, other times at ~900 packets. Maybe the SPI bus is being overrun? When I restart the receiver using the operation mode and start buttons it begins receiving the packets again.

In any event, try adjusting your deviation frequency.

It would be nice to hear some feedback from Freescale regarding their experience with packet reception robustness.

[georgepeterson]

Vahid, you said you studied the datasheet and reference manual several times. I think maybe you're not looking at the right reference manual. The MC12311 ref manual (MC12311RM) will tell you how to configure preamble and sync word.

My experience so far is that packet mode is intermittent at best. Sometimes I can send 1,000 packets and none are received... and sometimes 3 or 4 are received. Most times, however, the receiver indicates that no packets are present even though I know the packets are configured correctly and are being transmitted.

My experimentation is currently using the Radio Utility GUI on both the TX and RX sides. I have a suspicion that this tool is occasionally placing the MC12311 in weird undocumented modes. For example, some times the TX will not stop transmitting after I press the stop button. I have a Software Defined Radio nearby that is monitoring transmissions and this is how I know the TX is still going. On other times the GUI will grey-out the operation mode buttons even though it tells me that connectivity and functioning is fine.

At this point I have no idea if the problem is the GUI or the MC12311 itself. The answer to this question requires a deep dive into the software... and for the first time I'm wondering if I chose the right hardware vendor. Having a flaky receiver in such a critical application as tire pressure monitoring is troubling.

[luisburgos]

Hello Vahid,

I have some answers and suggestions for you:

1) In TX device set operation mode to Packet Mode before enabling TX.

2) Please check SetDefaultValues function to verify the configuration of preamble, sync word, payload, etc.

3) In regards of the RX sequence I recommend to put a breakpoint in PhyRxHandleSyncAddresEvent function (in PhyISR.c file) and check if your RX device application enter to this function when a message is received, if not it could be a an RX parameters configuration issue, but if the application is running until this point, please then put a breakpoint in the line:

gpfPendingRxEvent = PhyRxHandlePayloadReadyEvent;

in PhyRxHandleFifoLevelEvent function, and check if this function is been called.

4) Also i recommend to refer Simple Range Demo for TX and RX procedures.

Best regards.

[jasonchiang]

Hi Vahid,

     What is the frequency, bit rate and deviation you are setting ? DccFreq and RxfilterBW needs to be cared and they are related to your setting.

[vahidelc86]

Dear jasonchiang

The following is a pseudo-code of our program in packet mode, which doesn't work !!

1. Configure settings :

Freq. = 433 MHz

BitRate = 4.8 kbps

Freq. Deviation = 2.4 kHz

BW = 10.4 kHz

Dcc Freq. = %4 of BW

OpMode_Sequencer_On

OpMode_Listen_Off

OpMode_StandBy

DataModul_DataMode_Packet

DataModul_Modulation_Fsk

DataModul_ModulationShaping_BT_05

PaLevel_Pa0_On

PaLevel_Pa1_Off

PaLevel_Pa2_Off

PaRamp_40

Lna_LnaZin_50

Lna_LnaGain_Agc

2. The main program:

for(;;)

{

write data to FIFO          // in TX

read data from FIFO          // in RX

}

Is there any mistake I'm making? Or am I missing something?

How is the preamble and sync word bytes handled? Does the program sends them automatically? Or I should write them to the FIFO manually?

Would you please help me find where the problem is!?

(I would be thankful if you provide me, if possible, the c files or project files of the TPMS receiver, which will help me find the answers to my questions.)

Thank you very much for your help and time.

I look forward to hearing from you. :smileyhappy:

[jasonchiang]

Hi Vahid,

    I already sent project file to you through your yahoo email.

[georgepeterson]

jasonchiang,

Will you please send the project files to me too? Thanks.

[jasonchiang]

Hi Vahid,

    I already sent project file to you through your yahoo email on 08/15.

Haven't you received it ? Please check your yahoo email box.

[georgepeterson]

Hello Tzyy-Hong Chiang,

I'm not Vahid, I'm George. Sorry to bother you but can you share the C files with me also?

My email is george_peterson@jabil.com

[jasonchiang]

Heorge,

         I sent you C file already.

[georgepeterson]

Thanks THC. It must have went to my work email; I've been out of office on vacation and holiday. I'll be back this Monday and will check for it. I was finally able to get everything working though.

[jasonchiang]

Hi Vahid,

     I have sent you simple range demo code that output data to terminal today.

[vahidelc86]

Thank you very much, Dear jasonchiang for your response.

Actually, I set these parameters as the following:

Freq. = 433 MHz

BitRate = 4.8 kbps

Freq. Deviation = 2.4 kHz

BW = 10.4 kHz

Dcc Freq. = %4 of BW

You can also find out more about other settings in my attached codes.

I just don't know how I should write the preamble, sync word, and payload data to the FIFO.

Would you please provide more help?

I look forward to hearing again from you.