I have a design with two ICs, one is a 4467 and the other is a 4362. For the purpose of this test, they're both configured as receivers on two different frequencies. The configuration relies on sync word detection because the preamble is neither standard nor long enough for the options available. Direct mode is used for packet handling.

The MCU periodically issues a START_RX to each IC to restart sync word detection. RX performance is normally pretty good, until sometime late at night, after more than 6 hours of continuous operation, when performance degrades for no apparent reason. RX still functions, but with greatly reduced sensitivity. I have reproduced this on two boards with slightly different circuit designs, so it's not a one-off. Resetting the MCU which shuts down and re-initializes both ICs fixes the issue.

Where do I look? Should I take a periodic snapshot of certain registers to see if something is not right? Which registers should I look at?

The application is AIS, so loss of sensitivity is a show stopper.

TIA

I have legacy code on 4463 that I need to update and this is the only tool I use that requires Windows.

I think I'll just set up a Windows VM on Linux using VirtualBox for this.

Thanks, I did try this but it didn't help. I think it requires the packet handler which I can't use. I configured the radio for non-standard preamble with sync word detection.

I ended up sending START_RX with asynchronous completion (processing the CTS response in a subsequent ISR), so now it takes less than 65us.

Is there a way to estimate sync word detection timeout with a non-standard preamble so I can manage the "re-arming" better?

Thanks, I did try this but it didn't help. I think it requires the packet handler which I can't use.

I ended up sending START_RX with asynchronous completion (processing the CTS response in a subsequent ISR), so now it takes less than 65us.

Is there a way to estimate sync word detection timeout with a non-standard preamble so I can manage the "re-arming" better?

Thanks, I did try this but it didn't help. I think it requires the packet handler which I can't use.

I ended up sending START_RX with asynchronous completion (processing the CTS response in a subsequent ISR), so now it takes less than 65us.

Is there a way to estimate sync word detection timeout so I can manage the "re-arming" better?

I need to lower MCU voltage to 1.8V and I'm wondering whether I can do the same thing with the Si4463's VDD pins (to avoid level shifting), while preserving the 3.3V at the PA rail. Is that possible, and is it going to affect output power in any way?

Thanks.

According to the data sheet, the IC ramps up its internal PA before packet transmission begins, then ramps it down after packet transmission ends, using the timings specified in the PA_TC property.

What if I want the ramp up / down to occur during the packet? The AIS specification calls for this explicitly, not only with ramp-up and ramp-down bits, but also with the first couple of bits of the preamble:

Is there any way to do this with the chip, or do I have to manually adjust TX power from the MCU? If it is the latter, are changes in TX power also subject to some sort of ramp control? What kind of delay can I expect?

Thanks.

Currently, I am transmitting AIS packets in direct mode. I always specify TX_LEN as zero, respond to clock interrupts for supplying the bits, then finally switch state after sending the last ramp-down bit. I don't use the packet handler because AIS requires NRZI encoding of HDLC frames and the encoding applies to everything including the preamble, start / stop markers and CRC. 

Unfortunately, in this scenario, my MCU has to change RF state in code. If there is a bug or something gets fried in the logic stage of the unit during direct mode transmission, will the radio stay in a TX state indefinitely? (I think the answer is yes). If so, what's the best way to prevent this? Can I specify a TX_LEN even though I can't use the FIFO/packet handler? Or, perhaps, is there a way to use the FIFO / packet handler to transmit a block of bytes verbatim with no additional preamble/framing/checksum/encoding, so I can automate state transition back to RX and fulfill a key requirement?

(AIS specs require devices to provide a software-independent method for shutting down their transmitter within some period of time)

If you google "stratospheric balloon silabs", you will probably find at least one amateur balloon project that used one of the 44xx chips for reporting telemetry. Their experience might be helpful.