Radio interference?

[kobuki]

I've put together a Moteino transmitter and a receiver with a custom config. The receiver is programmed for either receiving multiple hopping sequences of tx frequencies or a single hopping sequence, and the other is a transmitter alongside an original weather station equipment. Exact parameters are here.

Now the problem is, when I set up the receiver Moteino to listen to only one of the hopping sequences of the 2 transmitting, there is a periodical, long streak of packets lost. But only when the tx frequencies are different. If tx frequencies coincide in the 2 hopping sequences, there's no problem. The bad streak starts when the packets follow each other within a short time frame. If I stop my custom Moteino-based transmitter (or the weather station, I assume, but that's very cumbersome to do), no packet lost occurs. The tx periods are around 2.5 s, they differ by 62.5 ms, and the total time to transmit a packet is about 5 ms. There's a possibility of an overlap but it's way too rare to pose a problem of this kind.

To sum up, the sequence is 868066725 868297125 868527525 868181925 868412325, bitrate is 19200 and Fdev is 4800 Hz, GFSK, AGC auto. I lowered the RSSI threshold to -50 dB.

Does someone have any ideas of what to try?

[Felix]

I have not tried hopping except for wireless programming which takes place at a vastly different frequency than the normal rx/tx channel, and that works very well.
I would suggest leaving the RSSI threshold where it is by default. -50dBm is really too "unsensitive".

[kobuki]

I have not tried hopping except for wireless programming which takes place at a vastly different frequency than the normal rx/tx channel, and that works very well.
I would suggest leaving the RSSI threshold where it is by default. -50dBm is really too "unsensitive".

Thanks for the advice. The -50 dB threshold is fine if the receiver is configured for both transmitters or only one is operating. The AGC takes care of lowering it anyway. I can see bogus packets arriving sometimes with way lower RSSI values after setting it to -50, and this is probably caused by the AGC auto setting. The same happens with the deafult or the only slightly lowered one I linked in the first post. But turning off the AGC by selecting a fixed threshold doesn't help, unfortunately. Nor does it worsen the situation. Though, selecting anything above -50 blocks reception.

I'm at a loss here, as fine a receiver the RFM69 is, there might be problems with crosstalk... But I'm still shooting in the dark.

[Felix]

I would bet that it's something about configuration. The RF experts can interject here and shed the light

[kobuki]

An update. I've done 2 quick experiments:

1. Moved one transmitter to a different room, I see a drop of RSSI to -61..-67 dB on it, while the other staying, with around -40 dB. No problems appear with single-reception config, nor with multiple.

2. Moved both transmitters to 2 different rooms. Now RSSI valueas are both around -61..-67 dB and problems start to appear. No problems with multiple rx config. The same as originally but with weaker signals.

It has to do something with the AGC overreacting but I'm not a radio expert, unfortunately.

[john k2ox]

I'm pretty sure your problem is unrelated to the AGC, unless you are slowly ramping the tx pwr down.

RSSI is measured during two bits of the FSK preamble and if the gain is in auto it adjusts the gain.  The RSSI threshold does NOT change with gain.  'RSSI' and 'RSSI Threshold' are always corrected for the gain setting.

Since the AGC is frequency independent, change your setup so that it doesn't hop.  If it works properly then, that's proof that it is not the AGC.  Changing freq only changes the synthesizer's freq.

I'd be interested in knowing how you synchronize the hops.

john

[kobuki]

Well, one thing I don't understand is that when I set the RSSI threshold to 100 (-50 dB), why did I capture packets with around -100 dB? I print the RSSI for every packet the radio captures.

I can't stop the hopping, the point is I need to follow a specific pattern to be able to send/receive packets of this equipment. The interference only happens when the 2 transmitters are on different frequencies AND their indicated RSSI is similar. When their frequencies coincide or the RSSI values differ significantly (about 20 dB),  then until their transmit frequencies drift away from each other (caused by their slightly different transmit periods), there's no packet loss. Also there's no packet loss when the radio is listening on the freq of the nex packet expected on (that is, the receiver is configured for receiving both transmitters).

BTW, only several pairs of frequencies cause this problem, not all. I'm yet to discover these pairs. Thinking it over, for testing, I could make my transmitter follow the OEM's transmitter with specific hop frequencies and watch what happens.

I'll release the sources so you'll be able to see the hopping sync code. But I'd like to fix this "interference" first.

[john k2ox]

A couple things.

There are two ways to get RSSI measurements.  One during an FSK packet and the other is async.  I use one to meas the other radio's sig strength and async to measure MDS.

On my radio's nothing gets through below the threshold.  If you turn CRC off and set the thres to -128 you will receive a constant stream of random data.  I set it about 5 db above mds and it stops.

Make sure your RXBW is no wider than needed.  You don't want adjacent signals to enter the demod.  BTW the actual BW is two times the RXBW setting because of the zero IF.

Also, because it has a zero IF there aren't any images to be concerned about.

john

[kobuki]

Thanks for the additional info. I can't say I can understand everything, I had to look up what MDS means, for example. What I do seem to gather is that I should up the threshold so much I don't receive unneded noise. It is the case now. The BW is set up according to the HopeRF specs - please see my first post with the link to the config, it will be familiar, I guess. I think that the original author, DeKay configured the BW properly. There are a few things worth noting, looking at the currently running serial log of the test reception.

The RSSI threshold is 170, meaning -85 dB. HW CRC checks are disabled (the protocol uses its incompatible implementation) so I can see packets coming in from both transmitters. I just drop those with a valid CRC but wtih an invalid station ID. Let's call the interesting station S1, and the unneeded one S2.

a) Packet from S2 is received on the frequency the next packet from S1 is expected on. It can be decoded, CRC matches, but based on station ID, it's dropped. In this case, packets arrive with an RSSI of 61..65 dB from both S1 and S2.

b) Packet from S2 is received on a different frequency. It appears as noise, with a bad CRC and is generally undecipherable. But somehow it maintains the same 8-byte structure and apparently passes the preamble+sync filter of the RFM69. The config allows for a 2-bit error on the sync word (setting it to less than that causes valid packets to drop and otherwise doesn't help). I know the packet is from the other transmitter since I have a serial line attached that logs the fact of the transmission and it does exactly at the moment I see the bogus packet appear as noise on the receiver. And the strange thing is that the RSSI values logged for these packets are all below -100, while the code doesn't touch the RSSI threshold value, it's still on 170.

[DeKay]

I guess. I think that the original author, DeKay configured the BW properly. There are a few things worth noting, looking at the currently running serial log of the test reception.

If I remember correctly, the bandwidth is a little wider than it would in a normal case because the frequencies aren't precisely known and I wanted to leave a little room for errors and offsets.  The fact that your signal is coming in 20 to 25 dB over the threshold, which itself is probably at least 15 dB over the noise floor says that your signal to noise ratio is pretty good and shouldn't be the source of the problem.

[kobuki]

IIRC the frequency values are exact since they were sniffed and converted from the SPI communications of the TI CC11xx chip. Sorted from low to high or vv. they follow each other by exactly the same constant (115200 Hz). I tried altering the frequency in both directions until their RSSI started to fall but no increase in the RSSI could be observed even with a single transmitter operating.

For now a workaround could solve this, by always configuring all transmitters and employing an "ignore" flag. It's really only relevant when some "foreign" station needs to be ignored.

[kobuki]

Sorry for the resurrection, but I could find some time since spring to tend to this matter. I've found a simple way to make the multiple hopping frequency reception code pretty robust. I've purchased an original receiver and a standalone anemometer transmitter (Davis weather station components) after all the practice with the Moteinos. Here are my findings in bullet style.

• The receiver needs to set the current frequency (~channel) after every captured packet, regardless of the next frequency, so it needs to be set to the current frequency even if the next packet is expected on the same channel. Till now, I set the freq. to the next expected value right after reading the packet data out of the RFM69 buffer. In this setup I after a Moteino restart I suddenly experienced a very bad reception ratio, down to 65-70%. All I did was adding a 3 ms wait after reading out the packet data. Maybe less would be sufficient but it magically changed reception ratio up to 100%. Though it's slowly degrading but never dips below 98.7%. What gives? There's some internal procedure that needs to finish inside the RFM69 before setting the frequency? The manual doesn't say something like that. Anyway the Moteino receiver now produces better reception ratio than the original equipment All with a small quarter wavelength wire from a cat5 ethernet cable, soldered directly to the Moteino.
• When I put the moteino receiver on a metal surface, like the top of a metal PC case, the RSSI improves by at least 5-6 dB. What causes this? Simple reflection or it behaves like a ground plane? (the Moteino is connected to this PC via USB.)