Engine Keeps stopping - Multiple I2C errors w/ PWM above 5 - Due to RF interference

[chrkov]

I cant keep the Engine running. I was seeing I2C errors and I have swapped and tested cables. Tried a cable without the PWM cable at all. Below is the log with excessive logging.

Tested on both fresh installs of FPP 6.3.2.2 and 7.4. Same results.

07:47:21 INFO --- 2023-12-21 07:47:21 DEBUG Lock created 07:47:21 DEBUG Setting up read side of fifo /home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_FIFO 07:47:21 DEBUG Fifo already exists 07:47:21 DEBUG line INIT 07:47:21 INFO Processing init 07:47:21 INFO Config {'DynRDSEnableRDS': '1', 'DynRDSPSUpdateRate': '4', 'DynRDSPSStyle': 'Merry|Christ-| -mas!|{T}|{A}|[{N} of {C}]', 'DynRDSRTUpdateRate': '8', 'DynRDSRTSize': '32', 'DynRDSRTStyle': 'Merry Christmas!|{T}[ by {A}]|[Track {N} of {C}]', 'DynRDSPty': '2', 'DynRDSPICode': '819b', 'DynRDSTransmitter': 'QN8066', 'DynRDSFrequency': '90.7', 'DynRDSPreemphasis': '75us', 'DynRDSQN8066ChipPower': '120', 'DynRDSQN8066AmpPower': '25', 'DynRDSQN8066Gain': '0', 'DynRDSQN8066SoftClipping': '0', 'DynRDSQN8066AGC': '0', 'DynRDSStart': 'FPPDStart', 'DynRDSStop': 'Never', 'DynRDSCallbackLogLevel': 'INFO', 'DynRDSEngineLogLevel': 'EXCESSIVE', 'DynRDSmpcEnable': '1', 'DynRDSQN8066DigitalGain': 0, 'DynRDSQN8066InputImpedance': 1, 'DynRDSQN8066BufferGain': 1} 07:47:21 INFO Using i2c bus 1 07:47:23 DEBUG RDSBuffer init 07:47:23 DEBUG RDSBuffer updateData 07:47:23 INFO PS [' '] 07:47:23 DEBUG RDSBuffer init 07:47:23 DEBUG RDSBuffer updateData 07:47:23 INFO RT [' \r'] 07:47:23 INFO New RDS Data 07:47:23 DEBUG RDS Values {'{T}': '', '{A}': '', '{N}': '', '{L}': '', '{C}': ''} 07:47:23 DEBUG RDS Data [Merry Christ- -mas! ] 07:47:23 DEBUG RDS Data [Merry Christmas! ] 07:47:23 DEBUG QN80xx updateRDSData 07:47:23 DEBUG RDSBuffer updateData 07:47:23 INFO PS ['Merry ', 'Christ- ', ' -mas! '] 07:47:23 DEBUG RDSBuffer updateData 07:47:23 INFO RT ['Merry Christmas! '] 07:47:23 INFO Starting QN80xx transmitter 07:47:23 EXCESSIVE I2C read at 0x06 of 1 byte(s) returned 0x34 07:47:23 EXCESSIVE I2C write at 0x00 of 0xe3 07:47:23 ERROR write_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 64, in write self.bus.write_i2c_block_data(self.address, address, values) OSError: [Errno 121] Remote I/O error 07:47:23 EXCESSIVE I2C write at 0x02 of 0x10 07:47:23 EXCESSIVE I2C write at 0x07 of 0xe8 0x0b 07:47:23 EXCESSIVE I2C write at 0x19 of 0x22 07:47:23 EXCESSIVE I2C write at 0x1b of 0x66 07:47:23 EXCESSIVE I2C write at 0x01 of 0x41 07:47:23 EXCESSIVE I2C write at 0x00 of 0x0b 07:47:24 EXCESSIVE I2C write at 0x24 of 0xff 07:47:24 EXCESSIVE I2C write at 0x24 of 0x7f 07:47:24 EXCESSIVE I2C write at 0x27 of 0x3a 07:47:24 EXCESSIVE I2C write at 0x6e of 0xb7 07:47:24 EXCESSIVE I2C write at 0x28 of 0x11 07:47:24 DEBUG Setting up PWM 07:47:24 DEBUG Setting PWM period to 18300 07:47:24 DEBUG Setting PWM duty cycle to 1525 07:47:24 INFO Enabling PWM 07:47:24 DEBUG Processing mpc 07:47:24 INFO New RDS Data 07:47:24 DEBUG RDS Values {'{T}': 'Piano Guys - Angels Have Heard on High', '{A}': '', '{N}': '', '{L}': '', '{C}': ''} 07:47:24 DEBUG RDS Data [Merry Christ- -mas! Piano Guys - Angels Have Heard on High ] 07:47:24 DEBUG RDS Data [Merry Christmas! Piano Guys - Angels Have Heard on High ] 07:47:24 DEBUG QN80xx updateRDSData 07:47:24 DEBUG RDSBuffer updateData 07:47:24 INFO PS ['Merry ', 'Christ- ', ' -mas! ', 'Piano Gu', 'ys - Ang', 'els Have', ' Heard o', 'n High '] 07:47:24 DEBUG RDSBuffer updateData 07:47:24 INFO RT ['Merry Christmas! ', 'Piano Guys - Angels Have Heard o', 'n High '] 07:47:24 DEBUG line UPDATE 07:47:24 INFO Config {'DynRDSEnableRDS': '1', 'DynRDSPSUpdateRate': '4', 'DynRDSPSStyle': 'Merry|Christ-| -mas!|{T}|{A}|[{N} of {C}]', 'DynRDSRTUpdateRate': '8', 'DynRDSRTSize': '32', 'DynRDSRTStyle': 'Merry Christmas!|{T}[ by {A}]|[Track {N} of {C}]', 'DynRDSPty': '2', 'DynRDSPICode': '819b', 'DynRDSTransmitter': 'QN8066', 'DynRDSFrequency': '90.7', 'DynRDSPreemphasis': '75us', 'DynRDSQN8066ChipPower': '120', 'DynRDSQN8066AmpPower': '25', 'DynRDSQN8066Gain': '0', 'DynRDSQN8066SoftClipping': '0', 'DynRDSQN8066AGC': '0', 'DynRDSStart': 'FPPDStart', 'DynRDSStop': 'Never', 'DynRDSCallbackLogLevel': 'INFO', 'DynRDSEngineLogLevel': 'EXCESSIVE', 'DynRDSmpcEnable': '1', 'DynRDSQN8066DigitalGain': 0, 'DynRDSQN8066InputImpedance': 1, 'DynRDSQN8066BufferGain': 1} 07:47:24 EXCESSIVE I2C write at 0x27 of 0x3a 07:47:24 EXCESSIVE I2C write at 0x6e of 0xb7 07:47:24 EXCESSIVE I2C write at 0x28 of 0x11 07:47:24 EXCESSIVE QN80xx sendNextRDSGroup 07:47:24 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 07:47:24 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xcc 07:47:24 EXCESSIVE Transmit 0x81 0x9b 0x08 0x40 0x81 0x9b 0x4d 0x65 - Send Bit 0 - Status Bit 1 07:47:24 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x40 0x81 0x9b 0x4d 0x65 07:47:24 EXCESSIVE I2C write at 0x01 of 0x43 07:47:24 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:24 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:24 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:24 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:25 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:26 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:27 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:29 ERROR read_i2c_block_data error Traceback (most recent call last): File "/home/fpp/media/plugins/Dynamic_RDS/Dynamic_RDS_Engine.py", line 81, in read retVal = self.bus.read_i2c_block_data(self.address, address, num_bytes) OSError: [Errno 121] Remote I/O error 07:47:31 ERROR failed to read after multiple attempts 07:47:31 DEBUG Cleaning up fifo 07:47:31 DEBUG Stopped PWM 07:47:31 INFO Disabled PWM 07:47:31 INFO Exiting

[chrkov]

After reading some other things on here, I am pretty sure this is an RF issue causing the problem. I dropped the power to 0 on the amp and the problems go away. I can recreate the issue by turning the Amp back up to anything above 5. I do have this on a bench testing with a cheap 50 Ohm antenna. I have another dipole antenna on the way and will retest with a remote antenna when it arrives.

Here is a snip of the log with amp power at 0. Looks pretty normal now.

08:59:40 EXCESSIVE QN80xx sendNextRDSGroup 08:59:40 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:40 EXCESSIVE Transmit 0x81 0x9b 0x08 0x43 0x81 0x9b 0x21 0x20 - Send Bit 0 - Status Bit 1 08:59:40 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x43 0x81 0x9b 0x21 0x20 08:59:40 EXCESSIVE I2C write at 0x01 of 0x43 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:40 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:40 EXCESSIVE Transmit 0x81 0x9b 0x20 0x53 0x6d 0x61 0x73 0x21 - Send Bit 1 - Status Bit 0 08:59:40 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x53 0x6d 0x61 0x73 0x21 08:59:40 EXCESSIVE I2C write at 0x01 of 0x41 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:40 EXCESSIVE QN80xx sendNextRDSGroup 08:59:40 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:40 EXCESSIVE Transmit 0x81 0x9b 0x08 0x40 0x81 0x9b 0x20 0x20 - Send Bit 0 - Status Bit 1 08:59:40 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x40 0x81 0x9b 0x20 0x20 08:59:40 EXCESSIVE I2C write at 0x01 of 0x43 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:40 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:40 EXCESSIVE Transmit 0x81 0x9b 0x20 0x54 0x20 0x20 0x20 0x20 - Send Bit 1 - Status Bit 0 08:59:40 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x54 0x20 0x20 0x20 0x20 08:59:40 EXCESSIVE I2C write at 0x01 of 0x41 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:40 EXCESSIVE QN80xx sendNextRDSGroup 08:59:40 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:40 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:40 EXCESSIVE Transmit 0x81 0x9b 0x08 0x41 0x81 0x9b 0x2d 0x6d - Send Bit 0 - Status Bit 1 08:59:40 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x41 0x81 0x9b 0x2d 0x6d 08:59:40 EXCESSIVE I2C write at 0x01 of 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x20 0x55 0x20 0x20 0x20 0x20 - Send Bit 1 - Status Bit 0 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x55 0x20 0x20 0x20 0x20 08:59:41 EXCESSIVE I2C write at 0x01 of 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE QN80xx sendNextRDSGroup 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x08 0x42 0x81 0x9b 0x61 0x73 - Send Bit 0 - Status Bit 1 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x42 0x81 0x9b 0x61 0x73 08:59:41 EXCESSIVE I2C write at 0x01 of 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x20 0x56 0x20 0x20 0x20 0x20 - Send Bit 1 - Status Bit 0 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x56 0x20 0x20 0x20 0x20 08:59:41 EXCESSIVE I2C write at 0x01 of 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE QN80xx sendNextRDSGroup 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x08 0x43 0x81 0x9b 0x21 0x20 - Send Bit 0 - Status Bit 1 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x43 0x81 0x9b 0x21 0x20 08:59:41 EXCESSIVE I2C write at 0x01 of 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x20 0x57 0x20 0x20 0x20 0x20 - Send Bit 1 - Status Bit 0 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x57 0x20 0x20 0x20 0x20 08:59:41 EXCESSIVE I2C write at 0x01 of 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE QN80xx sendNextRDSGroup 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x08 0x40 0x81 0x9b 0x20 0x20 - Send Bit 0 - Status Bit 1 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x40 0x81 0x9b 0x20 0x20 08:59:41 EXCESSIVE I2C write at 0x01 of 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x20 0x50 0x4d 0x65 0x72 0x72 - Send Bit 1 - Status Bit 0 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x50 0x4d 0x65 0x72 0x72 08:59:41 EXCESSIVE I2C write at 0x01 of 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE QN80xx sendNextRDSGroup 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x08 0x41 0x81 0x9b 0x2d 0x6d - Send Bit 0 - Status Bit 1 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x41 0x81 0x9b 0x2d 0x6d 08:59:41 EXCESSIVE I2C write at 0x01 of 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x20 0x51 0x79 0x20 0x43 0x68 - Send Bit 1 - Status Bit 0 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x51 0x79 0x20 0x43 0x68 08:59:41 EXCESSIVE I2C write at 0x01 of 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE QN80xx sendNextRDSGroup 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x08 0x42 0x81 0x9b 0x61 0x73 - Send Bit 0 - Status Bit 1 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x42 0x81 0x9b 0x61 0x73 08:59:41 EXCESSIVE I2C write at 0x01 of 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x43 08:59:41 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xe8 08:59:41 EXCESSIVE Transmit 0x81 0x9b 0x20 0x52 0x72 0x69 0x73 0x74 - Send Bit 1 - Status Bit 0 08:59:41 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x20 0x52 0x72 0x69 0x73 0x74 08:59:41 EXCESSIVE I2C write at 0x01 of 0x41 08:59:42 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:42 EXCESSIVE QN80xx sendNextRDSGroup 08:59:42 EXCESSIVE I2C read at 0x01 of 1 byte(s) returned 0x41 08:59:42 EXCESSIVE I2C read at 0x1a of 1 byte(s) returned 0xec 08:59:42 EXCESSIVE Transmit 0x81 0x9b 0x08 0x43 0x81 0x9b 0x21 0x20 - Send Bit 0 - Status Bit 1 08:59:42 EXCESSIVE I2C write at 0x1c of 0x81 0x9b 0x08 0x43 0x81 0x9b 0x21 0x20 08:59:42 EXCESSIVE I2C write at 0x01 of 0x43

[ShadowLight8]

@chrkov Thanks for posting the 2 sets of logs. Trying with amp power (PWM) set to 0 was one of my next questions :)

Can you run cat /boot/config.txt | grep i2c? I'm currently testing with dtparam=i2c_arm=on,i2c_arm_baudrate=400000 with PWM set to 10 and am not seeing issues.

Also, confirm cat /boot/config.txt | grep audio has the dtparam=audio=on lines commented out. Seems like there is more than one typically.

Any pictures of your hardware setup and cables could help. Which model Raspberry Pi are you running? I'm currently testing with a 3B+.

Hopefully, we'll be able to get to the bottom of this!

[chrkov]

fpp@FPP-TEST-RDS:~ $ cat /boot/config.txt | grep i2c

dtparam=i2c_arm=on

dtparam=i2c_arm=on,i2c_arm_baudrate=400000

I do have all the dtparam=audio=on lines removed from the config.txt. Two of those did exist.

I am running on a RPI 4. I do have a 3b+ i could test with also.

I dont have a picture handy, but its just the Pi and transmitter on the bench with a 7 section BNC antenna (yes, 50 ohm). I am going to test moving the antenna further away and see if the problem goes away. Just waiting on the cable to get here.

[ShadowLight8]

Testing with either dtparam=i2c_arm=on or dtparam=i2c_arm=on,i2c_arm_baudrate=400000, I've seen about the same results. ~2 errors for 20000 lines of debug logging.

When I pull down my Christmas Light show in a few weeks, I'll have a RPI 4 and I'll start testing with that as well.

For the cable/wires between your RPI4 and the QN8066, how long are they? Are they single wires or are they in a ribbon like That's also the cable I'm using. For routing the lines it goes Brown - SCL Red - SDA Orange - GND Yellow - 3.3V Green - PWM With Green staying next to 3.3V and GND until the last 3/4" of the cable.

Looking over the cable info in README.md, it needs some clean up to show things more consistently.

[chrkov]

Here is a picture of my test unit.

I am using a ribbon, but I completely separated the PWM cable so it is more stand alone. About as short as I can get it.

I am really still thinking this is RF injecting into the I2C buss. I did some reading and it seams it has been a problem for others. I am going to get a metal enclosure for this setup and earth ground it. That should help protect the I2c buss and the PI from RF. Not that I really plan on taking this much higher for power than 30 anyways, but still want to see how it reacts...

I also found a antenna cable I had laying around and moved the antenna away from Pi and transmitter. With that now about 6 feet away, I am able to bump the power up to 30 without any major errors (one here and there). If I go to 35, then I start to constantly see them.

[ShadowLight8]

Nice setup! Looks like your cable is shorter than what I'm using. Based on what you described, I tried a few different settings for Chip Power and Amp Power to see if I could get i2c failures as I increased the power.

With the Chip Power at 120, I was able to get to 80 Amp Power before I started seeing i2c failures. If I lowered the Chip Power to 100, I could go up to 90 Amp Power.

The interesting thing was that if I was running higher Amp Power and just barely touched the ribbon cable, I could get errors to appear on demand. At first, I though it was a bad connection or short, but at lower power it wouldn't do it. That feels like it matches up with an RF noise issue. It seems like there is a setup-dependent amount of power that can be used before issues start appearing. Time-wise, these were all pretty quick tests. I'll setup for some longer runs.

First results is if I let things run as is, second results is if I barely touched the ribbon cable Chip Power 120 Amp Power 100 - failed - failed Amp Power 90 - failed - failed Amp Power 80 - passed - failed Amp Power 70 - passed - passed

Chip Power 100 Amp Power 100 - failed - failed Amp Power 90 - passed - failed Amp Power 80 - passed - passed Amp Power 70 - passed - passed

[chrkov]

I believe when you touch the cables, your body is acting like a big antenna and pumping in more RF to the cable. I also know a sure way to block RF is to enclose everything in an earth ground box. I am going to try that. I am getting a metal box that I am going to mount everything in to anyways. Once I have that, I will get it all mounted and grounded and see what the results are.

BTW. I have been looking for a small radio with RDS like you have in the picture. Any info on that on you have? Tired of running out to the car constantly.

I love this plugin! Its exactly what I was looking for to match up with a better transmitter than those little things. I need to cover about a block, so this is going to work perfectly.

Send me something I can donate to for you.

I have a bunch of neat ideas for the plugin also if you want to hear them. I can submit them as enhancements if you want.

[ShadowLight8]

@chrkov That totally makes sense. It dawned on me to unwrap my antenna's cord and move it across the room. Suddenly I could run Chip Power at 120 and Amp Power at 100 with no issues, even if I touched the ribbon cable. I bet you're spot on with using an earth grounded box to cut down the RF and improve things. If nothing else, I'll add a note to the troubleshooting page about moving the antenna away from the transmitter and Pi. Looking forward to hearing about your results.

I know your pain of trying to find a small RDS radio. About 3 years ago I searched a ton and couldn't find anything reasonable. I stumbled across the Arduino compatible Wio Terminal with its i2c FM/RDS receiver. Ended up coding up what you see in the picture. I also picked up the chassis battery so it could be portable, but you can save the money since any usb power brick works just fine. https://github.com/ShadowLight8/WioTerminal_Radio https://www.seeedstudio.com/Wio-Terminal-p-4509.html https://www.seeedstudio.com/Grove-I2C-FM-Receiver-v1-1.html (Out of Stock at the moment) https://www.seeedstudio.com/Wio-Terminal-Chassis-Battery-650mAh-p-4756.html

I appreciate the donation offer, but I'm just happy to contribute back to an awesome hobby where I've benefited from so many others having already contributed :)

YES - I'd love to hear ideas for enhancements, so please submit them!

[TomasRa1]

Try to use ferrite bear around flat cable connector transmitter with RPi. It can help but not solved at all. It needs higher quality ferrite eg. 3M, china's poor quality does not affect. Problem is that RPi has very low EMC EMI immunity. RPi needs to be shielded from RF radiation and RPi could be also isolate from RF transmitter, because when we have not ideal matched transmitter antenna than RF interferency is also going via connection cable from transmitter board to RPi board. I would like to use i2c galvanic isolator for SDA and SCL signal, but I did not find finished module. I both ICs and PCB ordered in China. They sent me 15pcs but our Czech post did not delivered this package. They requested from me 2x more money than price of package (incl. shipment). I cannot support such thieving practices. Due to this solution were stopped and delayed. I informed Nick that original chinesse driving module of transmitter has not problem with i2c data errors as RPi has. It is valid also when high RF noise is measured on SDA and SCL interconnection wires: SDA+SCL signals generated by original China's CPU board with RF noise - still reliable communication

SDA+SCL signals generated by RPi (by SMBUS) - communication with errors

I proposed to use different protocol for RPi i2c communication. I hope that Nick will try to implement it. It is already described here on some different page - https://github.com/ShadowLight8/Dynamic_RDS/issues/13 - Update: sucessfuly REALIZED with this measurement output: Rpi is able to comunicate with Transmitter module (QN8066) under very hard radio-interferencies. It did not function when we use SMBUS for this i2c communication:

Nick, it seems that you use transmitting antena for 433MHz band, for FM band could be length of elements around 2x 70cm = 2x 27inches (instead of these shorts one's on the picture). Please, Nick, send me your email, I can also send you a few money. Kind regards Tomas

[TomasRa1]

For FM RDS tests I am using radio receiver Sencor SRD 6400 with price around 32USD. You can try to find some DAB+/FM receiver with LCD on your market.

[ShadowLight8]

@chrkov I just pushed #27 to main. One of the features is you can easily enable software i2c at the bottom on the plugin config page, then reboot. You might give that a try to see if you get better results.

[chrkov]

I can verify that software I2C does improve stability. With my current setup, I can now get up to 65 power before I start to see I2C errors. This is in a lab with a dipole antenna sitting 10 feet away. I think getting the antenna further will help (which the permanent install will be) and also the metal enclosure grounded (which will be here next week) will be the final things to get me to 100 without errors. So just switching over to Software I2C I went from about 30 to 65 without errors. Major improvement!

[TomasRa1]

Hello friends, It is great information regarding improvement of i2c stability! I am also testing this new configuration now. I uninstall plugin and install again for to have new changes. But I am using HiFiBerry DAC and due to I must also change PWM pin from PWM0 to pin11. I simply replaced (unchanged) file "Dynamic_RDS_Engine.py" with my previously updated file (from my backup) where I already moved PWM to pin11. Plugin is transmitting now audio and RDS sucessfuly I also see improvement. I would like to make longer tests and measurement of i2c SDA+SCL signals with osciloscope and public as 3. picture for comparision (1.picture is with original china's CPU, 2.picture is with SMBUS and I hope 3. will be with "software i2c"). I will try to measure tomorrow. I hope that galvanic isolation of i2c bus and grounded RF shield for RPi will cause 100% reliable i2c communication, we will see after i2c isolator modules will be delivered from China.

[chrkov]

So I got my enclosure that everything is going to be mounted in. Once I got it everything inside the box, I am now able to put the Chip power to 122 and the Amp power to 100 with no I2C errors showing up! So, as I expected, enclosing the transmitter and PI in a metal box that is earth grounded was the big key. I tested both using Software I2C and without with the same results.

[ShadowLight8]

@chrkov That's awesome news! If you're willing to share a picture of your new setup, I'd like to include it on the main readme as a way to handle the RF interference.

[chrkov]

I need to finish doing some cleanup on it first. I just tossed everything in to test. Should be done in the next day or two.

[TomasRa1]

So I got my enclosure that everything is going to be mounted in. Once I got it everything inside the box, I am now able to put the Chip power to 122 and the Amp power to 100 with no I2C errors showing up! So, as I expected, enclosing the transmitter and PI in a metal box that is earth grounded was the big key. I tested both using Software I2C and without with the same results.

Thank you very much for this great test! I could be carefull with to use SMBUS because timing/synchronisation of SDA and SCL with SMBUS is on edge of endurance. In "SOFTWARE I2C" are time sync between SDA and SCL much better as we can see above on records of SDA and SCL signals from osciloscope. Edges of SDA pulses are in the middle of SCL pulses and not on leading edges of SCL pulses. I think we must make everything for long term reliability of operation and treat all possible operating conditions in advance for to be sure with maximal possible long term reliability. Because in operation it can appeare some special bad conditions and we must predict them and also tread them in advance. Than is necessary to do long term (eg. min.10 days) test under all possible operating conditions. Than we can say that our equipment is reliable. I think that for clear reliable connection and operation of Rpi and Transmitter module is also needed i2c galvanic isolator, because it is not correct to connect 2 independent (not voltage-synchronised) DC supply outputs (+3V3 from RPi and from TX module) to one a common point. It can function sucessfuly during some first short tests but after longer time of operation may occur voltage drift of both independent voltage outputs and it increases current draw and it may lead to the destruction of the DC stabilizers or DC converters. Thank you for your understanding.

[chrkov]

@chrkov That's awesome news! If you're willing to share a picture of your new setup, I'd like to include it on the main readme as a way to handle the RF interference.

Hey Nick,

Here are pictures of the new box. Pretty much done and ready to be installed in the next couple weeks. There is a lot going on in this box, but the top row is pretty much the main pi (running off SSD), the DAC, Transmitter and a relay board for power control.

Thanks for all your work!

[ShadowLight8]

Hey Christopher! @chrkov Thanks for sharing the images of your setup in the ground, metal box. Very nice, clean work with an impressive amount of devices in a small area!!

In PR #43, I've added a new section to the readme with a few of your images to help show what can work. I'll push that to main shortly and close this item out.