CC1120: RX Sniff Mode stops interrupt on packet received on frequency change
Part Number: CC1120
So, I'm still searching for answers on a few issues with my CC1120. I have a working custom RX and TX setup (2 similar but different boards) that works in Packet RX mode. I send a packet from the RX, it is received every time by the RX at about -30db. My RX registers are slightly different from the SmartRF registers for Packet RX, but not many. Mostly with a different SYNC and fixed packet length of 10. My TX registers slightly changed from the SmartRF Packet TX. It seems to work well in this mode.
My issue started when I put the RX in RF Sniff mode. It was working, then I discovered that my RX was on 434MHZ and my TX was on 800MHZ (my mistake - I forgot the change the register). I thought that was strange that it worked like that. I didn't do that intentionally. When I changed it so that both were on 434MHZ, RF Sniff didn't work. I've been trying to figure that out, but haven't yet.
So, I stepped back a little and fired up my TRXEB board. It has a 434MHZ daughter board. I set the registers exactly like my RX custom board (except the IOCFG - they work slightly different on my boards). But, the TRXEB is not receiving any packets from my TX board. My RX continues to receive every packet.
I have attached my saved TX and RX configs in case anyone spots anything. Don't know what it could be since those settings work on my boards.
When you "Open CFG" in SmartRF, does it automatically load those settings into the TRXEB? I don't see any indication of that to confirm that. Also, I noticed that the Variable Packet Length field doesn't change when Fixed is loaded.
So, eventually, I hope to figure out the RF Sniff problem, but I want to figure out why the eval board doesn't communicate with my TX with my settings.
My TX and RX boards work well together in continuous mode at 434MHZ. If I load my TX settings into the TRXEB board (434MHZ daughter board) and send packets, my RX does not see any packets. If I load my RX settings into the TRXEB board, my TX packets are not recognized. So, there is definitely something I don't understand about the configuration somewhere. Hope someone can help figure it out.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Sutton Mehaffey:
I am still struggling a bit to get a full overview on what works and what does not work.
It is my understanding that you have both TrxEB with EM s and your custom boards.
Please do the following exercise:
Start with testing the two TRxEBs with SmartRF Studio (Test #1 and #2 below)
Once you have tested this, you know that the settings are OK.
Now you should test the TRXEB on one side and your HW on the other side.
Use exported settings from SmartRF Studio on your HW, and DO NOT CHANGE any registers other than IOCFGx, if necessary. Use variable packet length mode and the default sync word, even if this is not what you want to use in the end. Do first TX on your HW and RX with Studio (Test #3 and #4), and then the other way around (Test #5 and #6).
Finally, test with your HW on both ends (Test #7 and #8).
Fill inn the table below with your results/observations.
Please do not only state that it does not work in the cases where there are issues, but try to give info on what is failing. Do you get sync but have CRC errors, or do you not get sync at all?
In reply to Siri:
Good response. Thanks. I will try your suggestions. The only difference should be is that our custom RX board has GPIO0 tied to the CPU external interrupt, while the TRXEB boards have GPIO2.
How do you tell if you get SYNC or not? Or CRC errors? On my previous tests, with a mixture of my TX and the TRBEX RX, and vice-versa, the external interrupt was never triggered on the RX side. So, how do you troubleshoot if there is no RX interrupt?
It is very useful if you can monitor the GPIOs on both RX and TX siden when running the tests. In addition to output Sync sent/Sync found (IOCFG2 = 0x06) you can monitor PA_PD and LNA_PD (inverted) on GPIO3 to see when the device is in RX and TX mode.
On the TX side: IOCFG3 = 0x59 and on the RX side, IOCFG3 = 0x58.
When running Packet TX and RX Sniff mode it will look something like this:
From this you can verify that sync is found when sync is sent. CRC I guess you check in your SW.
When you are not receiving anything, it would be useful to see if this is because the radio does not go into RX as it should (RX, GPIO3) or if it simply does not find the sync word (RX, GPIO2) when a sync is sent (TX, GPIO2). If everything is OK, the RX_GPIO3 should go high in-between TX_GPIO3 and TX_GPIO2 getting high, and it should stay high until hte end of the transmitted packet (TX_GPIO2 getting low).
Sorry. I got pulled off on another project for a week, but I'm back on this RX/TX problem.
So, The 2 TRXEB demo boards work together in TX/RX and TX/RX Sniff mode perfectly. GPIO2 shows SYNC on both boards on our scope. Only change from Packet RX and Packet TX SmartRF settings is that freq is 434MHZ (FS_CFG=0x14). Works great.
When my TX custom board is loaded with Packet TX settings (again only change is FS_CFG=0x14), it is not received by the TRXEB demo board. GPIO2 on my TX shows sync being sent on our scope, but GPIO2 on the RX demo board is quiet. It is sending packets and my RX custom board receives them, but so far not the RX demo board. Still trying to figure out why.
I assume that even if the RX discards a packet due to any number of things (bad CRC, or whatever), you still should see the SYNC pulse on GPIO2?? Because, I can set up the demo boards to send any number of characters (1-30 random or my own) and it always works and I see both SYNC pulses on the scope. No matter what, my custom TX sends out SYNC and any number of characters (1-30) and the scope always sees the TX SYNC pulse, but the RX demo board never sees it (no pulse on GPIO2). The registers are all the Packet TX, except for FS_CFG=0x14. Any ideas? What reasons could the RX not see a SYNC?
I put the RX demo in Continuous RX mode with the TX demo. See first tall plots. Worked fine. The much lower plots are from my custom TX. No packets received. Why would those plots be so small so that they are not received as packets? The are received as packets on my custom RX board. Is there an amplifier on the demo board?
From what you are describing, it is obvious that you have a problem with your HW. When you do not get a sync signal on the RX side, that means that the demo board is not able to demodulate any of your data.
It could for example be that your custom board has a frequency offset compared to the demo boards. In that case, you might be able to communicate between two custom boards, given that they have the same offset, but not between a custom board and a demo board/LP.
You might also have problems using sniff mode when using your demo boards, if you are sending with poor output power, since the receiver will only receive packets with a certain RSSI in sniff mode (not the case in ordinary RX mode).
I will re-assign this case to our HW team so that someone there can help you further.
Yeah. Not sure at this point. Could be a HW issue, but it was confirmed twice as looking good by your support team. And, I checked again our schematic and it looks the same as the TI schematic. Doesn't mean there is not a wrong part on the board, but we've looked that over too.
I just reconfirmed that my custom HW works together on Continuous Mode at about RSSI = -30. And, our scope sees both SYNC pulses. But, not with your demo board. TX sends one, RX does not receive.
This post was unfortunately lost for some time in the system.
I believe I have taken a look at your schematic but I can't remember if I did. Who look at your schematic last? I want to take a brief look at again with the context of this thread to see if I get some ideas.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.