Yes, quite possibly.
The UWB signal is a very weak signal, so weak it fits under the unintentional radiation line allowed for general noise.
Another radio source can disrupt this signal quite easily if it is strong enough, and being on the same PCB, 868 MHz and BT can do it. What happens is that when the 868 MHz or BT transmit, the RF energy getting into the UWB front end is high enough to saturate it and the UWB signal is basically blown away and not received. In technical terms, the strong interferer has exceeded the linear range of the UWB front end.
This is fairly easy to check. Perform your tests with the 868 MHz and BT disabled in your code. If the UWB packet reliability rate goes up markedly, then you have a correlation and the RF from those devices is damaging your ability to receive UWB. Even if they don’t transmit, they may generate “spurs”, RF noise from their internal circuits. As an ultimate test, you can depop the board of the 868 MHz and BT circuits to make sure they aren’t the issue.
If you are unable to disable them in the code or remove the circuits, you can remove the antennas from the 868 MHz and BT systems, but this is only a partial test. RF energy can radiate through the PCB traces, particularly the voltage rails, so it doesn’t require actual radiation through the air to cause problems.
If you are getting 868 MHz and BT damaging your UWB packets, there are a number of things you can do. First, you organize your system so that 868 MHz and BT don’t transmit when you want to receive UWB. This is usually pretty complicated and often not an option. Second, you can put a filter on the UWB antenna input which cuts out signals below your band of interest, say a 5 to 6 GHz high pass for channel 5 operation, which will knock down BT and 868 MHz pretty effectively. This will help with radiated signals, but won’t help with PCB coupled signals, though. Third, you can design your board with better signal isolation between sections to reduce PCB coupled signals. This means things like isolated ground islands, ferrite beads on power rails, and RF clamp capacitors (say 5 to 10 pF) on digital signals. The exact treatment to solve this problem is very application specific.
The packet drops could also be from another interferer not on your board. Suggest you test at a remote site away from all other transmitters. If you get 100% there, but not in your normal setting, then there is something “in the air”. Again, a front end filter can help.
In addition to radio interference, there are many other ways to achieve less than 100% packet reliability. Most of these are related to power supply noise and filtering, or clock stability. The DW1000 is quite sensitive to power supply design and clock source.
Lastly, there are numerous ways you could have setup your software that cause less than 100% packet reliability. For example, not trimming XTAL_TRIM to keep your boards close together in frequency, not properly handling LDO trims, misconfiguring various setup registers, and so forth.
Another aspect is that you shouldn’t necessarily think this is only a receive side problem. There are plenty of ways to damage DW1000 transmissions that result in less than 100% reliable reception. The best way to test this is to setup an experiment with one transmitter and multiple receiver boards (with BT and 868 MHz off, to be sure). Send a bunch of serial numbered packets and record which packets you get at each of the receiving nodes. If the same serial number packet is being lost by most or all of the receivers, then it becomes some evidence the transmission was damaged.
Damaged transmissions come mostly from power supply and clocking issues. VDDPA1/2 are very noisy during transmit and need ample decoupling caps and it is nice to isolate them from other voltage rails. Any noise into XTAL1 is a problem. That’s not usually an issue for a crystal, but for a TCXO or other external source, it can be. The voltage at VDDBAT needs to be clean, hence the LDO guidance Decawave suggests for it when using a TCXO.
On additional thought, in your code, keep track of how many receive events/errors you get as well as how many good packets. Those bits are in the SYS_STATUS register are:
RXPRD (preamble detect)
RXSFDD (SFD detect)
LDEDONE (LDE done)
RXPHD (PHY header detect)
RXPHE (PHY header error)
RXDFR (data frame ready)
RXFCG (FCS check good)
RXFCE (FCS error)
RXRFSL (RS sync loss)
LDEERR (LDE error)
By comparing the number of the above events to the packets you are getting will tell you something about what is failing. For example, if all the numbers are the same, then you are not receiving bad packets, but simply not receiving the missing packets at all (maybe they aren’t being transmitted, or you aren’t listening at the right time?).
I’ve only touched briefly on a number of possibilities, there are other things that can cause this I haven’t mentioned. Hope this helps.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408