Testing The RFGateway (M4)

[johnpoole]

I purchased two RFGateway (M4) in April, 2022.  I'm finally getting around to using the product.  I successfully uploaded and ran via the ftdi the MotionMote Kit.  Now I wanted to set up a receiver using the RFGateway.  I saw there was a ready-for-Raspberry-Pi solution, but I wanted to keep it simple and simply test the hardware and see if I could see incoming payloads from the MotionMote.

I soldered onto the board a connector and connected a Dipole antenna.  I then connected the RFGateway to a USB (Sabrent powered extension).  In Arduino, I have the interface configured for the "RFGateway M4" and had to select a port from Tools->Port->[I don't remember].  My workstation is an Intel processor running Gentoo Linux.

So I successfully compiled and then installed the software from PiGateway_Basic.ino from https://github.com/LowPowerLab/RFM69/blob/master/Examples/PiGateway_Basic/PiGateway_Basic.ino.

After the upload, I did not see anything in the serial console.  (I previously used the Arduino's serial console window to monitor output from the MotionMote.)  I clicked the reset button on the RFGateway, a green light flashed on the board.)  Now the board does not show up in the results from the command: lsusb.  The command "dmesg -T"  has:

[Wed Sep 10 15:27:19 2025] usb 2-2.2.4.4.2: new full-speed USB device number 27 using ehci-pci
[Wed Sep 10 15:27:35 2025] usb 2-2.2.4.4.2: device not accepting address 27, error -110
[Wed Sep 10 15:27:35 2025] usb 2-2.2.4.4.2: new full-speed USB device number 28 using ehci-pci
[Wed Sep 10 15:27:50 2025] usb 2-2.2.4.4.2: device descriptor read/64, error -110
[Wed Sep 10 15:28:04 2025] usb 2-2.2.4.4.2: new full-speed USB device number 29 using ehci-pci
[Wed Sep 10 15:28:19 2025] usb 2-2.2.4.4.2: device not accepting address 29, error -110
[Wed Sep 10 15:28:19 2025] usb 2-2.2.4.4.2: new full-speed USB device number 30 using ehci-pci
[Wed Sep 10 15:28:35 2025] usb 2-2.2.4.4.2: device descriptor read/64, error -110
[Wed Sep 10 15:28:50 2025] usb 2-2.2.4.4.2: device descriptor read/64, error -110
[Wed Sep 10 15:28:51 2025] usb 2-2.2.4.4-port2: attempt power cycle
[Wed Sep 10 15:28:51 2025] usb 2-2.2.4.4.2: new full-speed USB device number 31 using ehci-pci
[Wed Sep 10 15:29:02 2025] usb 2-2.2.4.4.2: device not accepting address 31, error -110
[Wed Sep 10 15:29:02 2025] usb 2-2.2.4.4.2: new full-speed USB device number 32 using ehci-pci
[Wed Sep 10 15:29:13 2025] usb 2-2.2.4.4.2: device not accepting address 32, error -110
[Wed Sep 10 15:29:13 2025] usb 2-2.2.4.4-port2: unable to enumerate USB device

I've tried turning on/off the button associated with the RFGateway socket on the Sabrent extension, still nothing.  I do have a USB-A to USB-A extension cable that is probably 30".  I therefore tried inserting the unit directly into the Sabrent extension; there was no difference.  I returned to the cable, and when I click the RESET button, the green light blinks on then off.  As I did this, and afterward, "sudo dmesg -Tw" [T= human time, w = watch] started another cycle as shown above.

I suspect by loading the software, I have cut myself off as perhaps the software is designed for a Raspberry Pi system and possibly responding to other events?  I would have at least expected the command "lsusb" to show its presence.  I've worked a lot with Raspberry Pi (I run Gentoo Linux on some of them) and cannot think of anything that might cause the RFGateway to behave differently, e.g. not registering itself in the USB bus.

So, what should I do or test with?  I want to be able to verify the RFGateway is receiving in an Arduino serial console.

[johnpoole]

For what it is worth, here's ChatGPT's analysis.  I tried it's suggested double-tap and now I have a board that registers on the USB bus.

Got it

[Felix]

Yes, a double tap would put it in bootloader mode and emulate it as a disk drive (with 3 files, Current.uf2 being the current firmware running on it). In this mode it is ready to accept a skech/Arduino IDE upload at a serial port that it also generates. Or a drag-and-drop UF2 file to replace the Current.uf2 that's running on it, as well as backup the current firmware before dropping a new uf2 file to it.