Possible intermittent reception issue? about rf433recv

[sebmillet]

Hello

this is odd, never seen it. The fact that it gets received 50% of the time obviously means, the sender/decoder timings do match.
Is it constantly a "reception 1 time out of 2" (extremly regular), or is it sometimes "randomly received 50% of the time"?
According to your feedback we are in the first case and it sounds as if the decoder would have a "remanent stateful" condition (between two receptions) where only a secondary (partial) reception would reset it.
Could you send me the exact code you are using, on both sender and receiver side?
I'll test if I can reproduce it, in both simulated context and real context.

Thanks, Sébastien Millet

[HattonLe]

(My code progressed since posting the issue so I have created new Test Tx and Rx sketches to minimise the code down to show the problem). Find attached TransmitTest and ReceiveTest. Also attached screenshot of serial output from ReceiveTest; the Rx: mSec value is the duration since last RF message received... currently showing approx 10499mSec, with TransmitTest sending at 5 Sec intervals. Occasionally I get mSec durations of 5831, 6207, 14791, 13497, so its mostly skipping alternate messages, occasionally getting sequential messages and sometimes missing multiple messages. Both Tx and Rx ends are using 5v 16Mhz Arduino Pro Mini boards. Tx board powered from big bench PSU. Rx board powered by a USB TTL serial dongle. Test setup pictured, scope on both Tx and Rx digital signals. Thought you might like to see the scope traces... attached photos. Top trace is Tx data to the RF433 Tx board. Bottom trace is the digital output signal from the RF433 Tx board. "Scope Delta" middle trace is (channel 1 - channel 2) - A quick method of comparing the transmitted data against received data. It shows the receiver is getting the transmitted data ok, subject to slight signal latency (to be expected), and slight differences in signal voltage and rise\fall times. The receive code is quite complex so it will take me a while to get up to speed on it but luckily you are around :o) haha.  One thing I have read so far on  line but not yet investigated is micros() can go wrong when used inside interrupt handlers. It was mensioned on the arduino website but also listed here   >> stm32duino/Arduino_Core_STM32#1680 Attached screenshot of Teraterm serial Rx running whilst I was typing this email... shows what happened over the last 3 minutes or so.

[HattonLe]

Hiya, Forgot to add, https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/ About half way down the page "About interrupt Service Routines" where is talks about micros(). Oh and I'm using Arduino IDE 2.0.3 (clean install). After a long time running, it seems to be roughly speaking approx   93% receptions 10499 mSec     3% receptions 5800-8400 mSec     3% receptions 12000 mSec  Looking at the scope, transmits occur regularly every 5.22 seconds. :o)

[HattonLe]

Me again :o) Note that my Transmit code is set to send radio packets only once (i.e. no repeats). Testing with a Transmit sketch loop() delay of 1 or 2 seconds appears to completely kill radio reception. (On the scope my packet transmit takes roughly 78mSec). One thing I have noticed using the Decode sketch - It doesn't output serial data the instant it has received a radio packet. Instead it seems out wait for at least 4? radio packets and then it outputs all 4 decodes to the serial port in one go. (it always outputs 4 decodes, never a single decode). I have also tried setting transmit repeats to 2, but that didn't seem to make any difference to any experiments so far. (inter packet repeat gap appears to be around 67mSec which tallies with the sequence duration of 65535, (it takes 10mSec for 10000, so that is working nicely). With seq duration set to 10mSec, Interestingly the decode output generated for 4 packets (see below) lists the sep values as 10164, 65535, 10172, 65535.  so the 2nd and 4th packet dumps don't match up. Received: 40485 mSec elapsed: Data: 03 41 42 43

…

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_MANCHESTER, // mod 65535, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 1196, // lo_short 2382, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long  (0 => take lo_long) 1176, // lo_last 10164, // sep 32  // nb_bits ); -----CODE END----- Received: 32 mSec elapsed: Data: 03 41 42 43

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_MANCHESTER, // mod 0, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 1196, // lo_short 2382, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long  (0 => take lo_long) 1140, // lo_last 65535, // sep 32  // nb_bits ); -----CODE END----- Received: 35 mSec elapsed: Data: 03 41 42 43

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_MANCHESTER, // mod 0, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 1196, // lo_short 2382, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long  (0 => take lo_long) 1168, // lo_last 10172, // sep 32  // nb_bits ); -----CODE END----- Received: 36 mSec elapsed: Data: 03 41 42 43

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_MANCHESTER, // mod 0, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 1196, // lo_short 2382, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long  (0 => take lo_long) 1140, // lo_last 65535, // sep 32  // nb_bits ); -----CODE END-----

[HattonLe]

I don't think github pulled in my emailed attachments from my comments, so here they are... again...
(I had to rename the .ino files because github couldn't handle them!).



![TestSetup](https://user-images.githubusercontent.com/17553260/212682038-37e74951-2e86-493e-b97d
teraterm.log
-dee4a9e49878.jpg)
DecodeTest.ino.txt

![Intervals](https://user-images.githubusercontent.com/17553260/212682045-0e780840-d5d2-4731
ReceiveTest.ino.txt
TransmitTest.ino.txt

-931d-f28c468974b3.jpg)