FEATHER RP2040 RFM9X interference with USB at high power

[jerryneedell]

This does not appear to be a CP issue, but an issue with the HW. It was suggested that an issue be opened to discuss it.

Setting the transmit power to 23 on the feather RP2040 RFM9x board causes issues with USB connections. On my M1 Mac, it causes a disconnect of the CIRCUITPY drive and the board resets. In some cases, it will cause the MAC to "freeze" until the USB port is disconnected.

If I use a Rasberry Pi 400, the USB connection (monitored via tio) often disconnects with each transmission. The board appears to keep running most of the time but It occasionally resets to Safe Mode.

Running the board from a wall supply, it transmits normally. Also running the same code on a feather M0 RFM9x, works normally -- no issues.

Of course, the issue can be intermittent - it does not always occur 😦

This is the code I run to create the issue

# SPDX-FileCopyrightText: 2021 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT

# Example to send a packet periodically
# Author: Jerry Needell
#
import time
import board
import busio
import digitalio
import adafruit_rfm9x

# set the time interval (seconds) for sending packets
transmit_interval = 10

# Define radio parameters.
RADIO_FREQ_MHZ = 915.0  # Frequency of the radio in Mhz. Must match your
# module! Can be a value like 915.0, 433.0, etc.

# Define pins connected to the chip.
CS = digitalio.DigitalInOut(board.RFM_CS)
RESET = digitalio.DigitalInOut(board.RFM_RST)

# Initialize SPI bus.
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)

# Initialze RFM radio
rfm9x = adafruit_rfm9x.RFM9x(spi, CS, RESET, RADIO_FREQ_MHZ)

# Note that the radio is configured in LoRa mode so you can't control sync
# word, encryption, frequency deviation, or other settings!

# You can however adjust the transmit power (in dB).  The default is 13 dB but
# high power radios like the RFM95 can go up to 23 dB:
rfm9x.tx_power = 23

# initialize counter
counter = 0
# send a broadcast mesage
rfm9x.send(bytes("message number {}".format(counter), "UTF-8"))

# Wait to receive packets.
print("Waiting for packets...")
# initialize flag and timer
send_reading = False
time_now = time.monotonic()
while True:
    # Look for a new packet - wait up to 5 seconds:
    packet = rfm9x.receive(timeout=5.0)
    # If no packet was received during the timeout then None is returned.
    if packet is not None:
        # Received a packet!
        # Print out the raw bytes of the packet:
        print("Received (raw bytes): {0}".format(packet))
        # send reading after any packet received
    if time.monotonic() - time_now > transmit_interval:
        # reset timeer
        time_now = time.monotonic()
        # clear flag to send data
        send_reading = False
        counter = counter + 1
        rfm9x.send(bytes("message number {}".format(counter), "UTF-8"))

The issue does not occur with the default power setting: tx_power = 13.

I have also reproduced the issue using Arduino with the Radiohead library, so it is not a CP issue.

I did check the power draw via a PPK2. When transmitting: - at tx_power = 23 it draws ~150mA -- at the default tx_power=13 it draws ~ 100 mA.

I tried the same code on feather_m0_rfm9x and cannot reproduce the issue.

I don't recall running into anything like this with rfm9x feathering's or breakouts.

[Rybec]

Is it possible that the actual transmission events are too short for the instrument to detect? If the sampling time is significantly longer than the current spike during transmission, it might register as a small average increase in current, while what is actually happening is a large but extremely short increase that gets averaged across a single longer sample. I'm not familiar with the PPK2, but maybe you need an oscilloscope to accurately view the current change (probably via voltage drop) over time?

Just a thought. The symptoms look exactly like brown out due to excessive voltage drop during peak current draw, and if the PPK2 isn't fast enough to see the full TX spike, it could look like it is drawing far less than it actually is.

[jerryneedell]

The PPK2 is sampling at 100,000 samples/sec so I think it resolves the transmission spike - here is a screenshot

I also tried looking at it with a scope and did not see any voltage drop.

I agree that it sure sounds like a power issue, but so far, I can't come up with any evidence.

[jerryneedell]

Another observation... On the Pi400, I have been using a power USB Hub on the USB2 port. If It connect the RP2040 RFM9x directly to one of the USB3 ports, I do not see any disconnects and it is working fine at tx_power=23 I aslo swapped the hub to the USB3 ports and directly connects to the USB2 port and I and now seeing the disconnects with each transmission ....

and If I connect the RP2040 to the USB hub when it is on the USB3 port, I do not see the disconnects.... so at least on the PI 400, this appears to be related to the USB2 port... I am confused, but hopefully this will make sense to someone.

Edited - to add, there may have been a use with the USB hub I was using in the Pi 400. I have switched to a different hub and it is working OK on both the USB2 and USB3 ports.... So far, I have not been able to reproduce the USB disconnects using the Pi400.

Moving back to the Mac to see if swapping USB ports has any impact.

[jerryneedell]

aargh .. this is extremely frustrating... back on the Pi400, I started seeing disconnects again but after swapping cables and ports, it does appear the such things do matter... I have it working stably with a direct connection to a USB3 port on the Pi400. Connecting directly to the USB2 port results in disconnects when transmitting. It also now seems stable with the USB HUB on the USB3 port as long as I do not use the "mag-tip" cable....way too many variables.

I'm not sure what to think about this now but it still appears that there is something odd with the RFM9x RP2040 board and USB (when using tx_power=23)

Sorry for the confusion...

[Rybec]

Yeah, 100k samples per second should get the transmission, especially given the length of the spike.

I wonder if it's something with the board's power rails. If the rails have too much resistance, that could limit the current draw, and if that limit is lower than the chip needs at the higher power output, that could cause issues. But then, if that's the case, it should have issues regardless of the power supply... Well, I wonder, what voltages do the different power supplies provide? USB power supplies/batteries tend to vary in voltage between 4.8V and 5.2V. If the board power rails are border line on the resistance, a well regulated supply providing exactly 5V might fail where a supply deliberately overvolted to 5.2V to compensate for voltage drop more cheaply might provide just enough to push enough current through the power rails. And of course a supply that provides 5V without a load, that isn't very well regulated could easily drop a point a two under almost any load, and while you wouldn't see a supply voltage drop, the power rail voltage drop after the regulator on the board could be enough to cause a problem. Odds of accidentally landing exactly in the space are very unlikely, but it could happen.

Can you find the power pin in the RF chip and measure the voltage from there, to see if there's a voltage drop on transmit? That seems to me like it would be pretty difficult, but I don't have much experience measuring signals directly on the IC pins (at least, not outside of DIP chips on breadboards...). That could help to narrow down where the issue might be.

(The USB port version differences seems like an odd thing to happen, but maybe if they are using different controllers or something like that, the power output and internal impedance could be slightly different? If so, then insufficiently wide power traces after the on-board regulator might explain that as well.)

[jerryneedell]

Good suggestions. I'll see if I can monitor the voltage to the RF module. Interestingly, I noted that there is a difference in the schematics between the RP2040 RFM and the M0 RFM boards in that the there is a 10microfarad capacitor between 3.3v and GND on the RF module for the M0 board, but it is not shown on the RP2040 board schematic. However, looking at the board and the board layout diagram, it looks like the capacitor is actually in place on both. It appears to just have been omitted from the schematic on the RP2040 board.... @ladyada If you have a chance, can you confirm that?

https://learn.adafruit.com/feather-rp2040-rfm95/downloads https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/downloads

edited to add-- oops -- my mistake, the 10uf capacitor is shown in the power and filtering section of the RP2040 board schematic. It is shown directly between the RF module pins on the M0 schematic.

[jerryneedell]

The 3.3 V on the RF module looks very stable to me. I don't see any dip during transmission.

[ladyada]

post a photo of your antenna setup, the RF is feeding into the USB data lines, not power lines

[jerryneedell]

I'm just using the spring antenna in this cases.

[ladyada]

maybe try uFL to SMA and have the antenna much farther away?

[jerryneedell]

Quick test does seem better on the Mac... I'll run a bunch more tests. Thanks!

[ladyada]

keep that antenna away from data/power cables - it should be away from your computer :)

[jerryneedell]

Is the spring likely to be worse than a simple wire?

[jerryneedell]

With the UFL antenna, the MAC USB does still occasionally freeze but it does seem better and it may well depend on keeping the antenna away. Also. I wonder if the "mag tip" cables are more susceptible. I'm trying different cables...

[bill88t]

Something to note, I also saw usb disconnections with the RFM9x modules and pico at max power. I am pretty sure RFM9x just causes voltage spikes. I moved the module to pimoroni_picolipo_16mb and it no longer lost usb. I blame the regulator, cause the only real difference between the picolipo and pico in terms of power distribution is the regulator.

[bill88t]

The thing is that at max power the module is AUDIBLE when transmitting data. Mind you, I have excellent hearing, but still it should not be audible. I presume the instantaneous current is much much higher than 150mAh. My usb doctor did not measure the spiking at all, reading 0.2A total board use regardless of if it was TX'ing or not. Oh and I should also note, the usb disconnections only occured on the pico + module when I spammed packets, not when sending one or two.

[sdunlap]

I am also struggling with this issue. I have a forum post with details here: https://forums.adafruit.com/viewtopic.php?t=205186

Has anyone come up with a solution/workaround?

[ladyada]

can you use a much longer uFL -> SMA adapter cable to really make sure that signal isn't getting to the board?

[jkadin]

I am also struggling with this issue. I have a forum post with details here: https://forums.adafruit.com/viewtopic.php?t=205186

Has anyone come up with a solution/workaround?

My workaround was to switch from a soldered spring coil antenna to an external antenna using the ufl to sma adapter and just keep the antenna a few inches from the board. No issues since doing that for my project at least. I have about 10 of these set up with the external antenna and max power for an installation

[sdunlap]

Thank you for the recommendations. At least I understand the problem now. I have multiple applications for these boards. In some cases, I won't need USB, so that's fine. When possible, I'll go with the ufl to sma. Where space is an issue, I'll just have to lower the power and deal with the potentially reduced range.

I wish I had found this page earlier. I didn't realize it was an interference issue until after a few days of troubleshooting. Since this is a known issue, adding a note to the antenna options part of the guide might be good. I also recommend starting with minimum transmit power to ensure everything works and then crank it up. The example code starts at max.

[ladyada]

ok we made a page for the guide here https://learn.adafruit.com/feather-rp2040-rfm95/rp2040-usb-radio we really do think that its a RF coupling issue - we saw very similar behavior when we had 'high current drive' on the RP2040 pins for the SCORPIO driver board. and that's not even amplified! please check it out, i'm going to close this issue because we have a few workarounds :)