CC2500 Reliability Problem

If the RSSI value is about the transmit power level (suggesting you have the parts right next to each other), if you transmit with too much power you probably are saturating the CC2500.  Try backing off on the power, place the two further apart, or put an attenuator in series with the antenna.

we're actually plugging them right together via a SMA-cable, but with about 40dB attenuators in the line we have an signal strength of -70dBm at the receiver.

should suffice not to saturate the receiver and to remain above the sensitivity of the 500kBaud mode (-83dBm if i remember right). right? :)

Thanks for your response!

Your description of the conducted test should be viable.

Have you tried creating a small gap, say a couple of milliseconds, between transmissions just to see if things start working better?  I'm wondering if the reason things may seem to work sometimes may be simply due to the point in time where the two systems come online.

Jim Noxon

Actually, we're trying to have the FIFO filled at all times - there are always one or more packets in the queue (to get the maximum effective datarate)

We haven't found a detailed description of this...but the time where the GDO (configured to be high on packet start and low on packet end) remains low matches quite good the time needed to transmit preamble and sync, so it takes its time for that.

as a general question: are the CCs designed for this kind of operation (always full-fifo and it transmits the data as fast as it could)?

we'll try your proposal soon, thanks.

kai

ok, we tried that, same issues (allthough we haven't received anything), same thing sending single packets.

same symptoms as stated above, signal strength at expected levels, no preamble detection (with treshhold at minimum), no sync word detection => no GDO-activity at the receiver.

the config is exactly the same, we checked that again.

any ideas will be appreciated :)

thanks,

kai

Do you have access to a spectrum so you can check if the transmitter is actually sending what you expect is to do? If you have a CC2500 EM and set this up as sender or receiver does that help? Or you could use a CCdebugger to control either the sender or receiver. The point of this is to replace one end with know hardware/software to be able to pinpoint the problem.

yes, we have spectrum analyzers...we see a gaussian-shaped signal with two spikes left and right for 2-fsk modulation.

We're trying to get access to a vector signal anylzer to verify it in detail, hopefully this will locate it.

unfortunately we don't have a EM or debugger or any equipment known working as reference.

until now i think we have found it - at least one of a few bugs ;)

i had the CS-pin going high during fifo-read due to an unshielded-spi routine and another interrupt stopping it - which knocked the CC out of balance so only a HARD-reset could get it back to live.

so trying to get it back to work with softresets or switching states didn't work, but the hard-reset made it receiving again and shielding the spi-readout fixed it.

i really hope this was the only issue triggering my problem ;)

for the transmitter we see some anomalys on the spectrum analyser: if the datarate is set too high, the nice 2-fsk spectrum gets modified, only 1 of the peaks is either left, right or in the middle of the gauss-shaped curve. low datarates doesn't generate this.

is there a reason for this? ;)

well, that was too fast. everything the same, no changes - same effects as stated above.

spectrum looks quite good on the spec, preamble ok, no sync and no data found.

kind of strange...