Troubleshooting

Anyone tried this with RFM69HCW? I got it compiled on Arch Linux ARM with the aarch64 linux-rpi kernel after editing ./configure and hal/transport/RFM69/driver/new/RFM69_new.h as described above. [root@alarm git]# cat /proc/cpuinfo | grep Model && uname -a Model : Raspberry Pi 4 Model B Rev 1.4 Linux netberry 6.1.11-2-rpi-ARCH #1 SMP PREEMPT Tue Feb 14 06:34:59 MST 2023 aarch64 GNU/Linux It runs, but doesn't communicate with the radio properly: [root@alarm MySensors]# ./bin/mysgw Feb 16 13:20:45 INFO Starting gateway... Feb 16 13:20:45 INFO Protocol version - 2.4.0-alpha Feb 16 13:20:45 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=1,VER=2.4.0-alpha Feb 16 13:20:45 DEBUG TSF:LRT:OK Feb 16 13:20:45 DEBUG TSM:INIT Feb 16 13:20:45 DEBUG TSF:WUR:MS=0 Feb 16 13:20:45 DEBUG RFM69:INIT Feb 16 13:20:45 DEBUG RFM69:INIT:PIN,CS=24,IQP=22,IQN=25 Feb 16 13:20:45 DEBUG RFM69:PTX:LEVEL=5 dBm Feb 16 13:20:45 DEBUG RFM69:DUMP:Registers Address | HEX value Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x01 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x02 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x03 Value=0x1a Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x04 Value=0x0b Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x05 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x06 Value=0x52 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x07 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x08 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x09 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0a Value=0x01 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0b Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0c Value=0x02 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0d Value=0x92 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0e Value=0xf5 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0f Value=0x20 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x10 Value=0x24 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x11 Value=0x9f Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x12 Value=0x09 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x13 Value=0x1a Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x14 Value=0x40 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x15 Value=0xb0 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x16 Value=0x7b Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x17 Value=0x9b Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x18 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x19 Value=0x86 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1a Value=0x8a Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1b Value=0x40 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1c Value=0x80 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1d Value=0x06 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1e Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1f Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x20 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x21 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x22 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x23 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x24 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x25 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x26 Value=0x05 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x27 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x28 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x29 Value=0xff Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2a Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2b Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2c Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2d Value=0x03 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2e Value=0x98 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2f Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x30 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x31 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x32 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x33 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x34 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x35 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x36 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x37 Value=0x10 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x38 Value=0x40 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x39 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3a Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3b Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3c Value=0x0f Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3d Value=0x02 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3e Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3f Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x40 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x41 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x42 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x43 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x44 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x45 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x46 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x47 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x48 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x49 Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4a Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4b Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4c Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4d Value=0x00 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4e Value=0x01 Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4f Value=0x00 Feb 16 13:20:45 DEBUG !RFM69:INIT:SANCHK FAIL Feb 16 13:20:45 DEBUG !TSM:INIT:TSP FAIL Feb 16 13:20:45 DEBUG TSM:FAIL:CNT=1 Feb 16 13:20:45 DEBUG TSM:FAIL:DIS Feb 16 13:20:45 DEBUG TSF:TDI:TSL Feb 16 13:20:45 DEBUG RFM69:RSL I have built commit aa520cea, the latest from the development branch, using this config: ./configure --my-gateway=ethernet --my-transport=rfm69 --my-is-rfm69hw --my-rfm69-frequency=868 --extra-cxxflags="-DMY_DEBUG_VERBOSE_RFM69 -DMY_DEBUG_VERBOSE_RFM69_REGISTERS" My hardware should be fine, i didn't change anything and it was working with the 32-bit kernel before.

Yes, comment #define MY_DEBUG and in setup() add Serial.begin(115200);

Dual Transport (dual bus) Hello Yes a Gateway with several buses or a Node with two different buses would be a good thing. You may have seen the post and the version of @tekka https://forum.mysensors.org/topic/11135/something-s-cooking-in-the-mysensors-labs?_=1674118354490 . maybe not a problem for you "tekka's personal fork from the MySensors 2.4 branch and has not been updated" https://github.com/tekka007/MySensors/tree/UpdateMultiTransport

@KenKrick - did you ever resolve this? Seeing exactly the same thing on my Sensebender GW.

Hello @Konrad-Winiarski and best wishes for 2023 if you have time you can tell us more about the architecture you have chosen. the part mysgw (485) : gateway USB? Mqtt : Mosiquitto ! Node Red : flow exemple? yes examples for a small test installation thanks https://forum.mysensors.org/topic/11513/corrupted-data-from-rs485-sensor-node/3

OK that's embarrassing. It seems I connected interrupt / DIO0 to gnd. But i've reconnected the entire thing several times, including swapping... Anyway thanks for pointing it out. I still get some NACKs and the mqqt is not working anymore for some reason, but I'll figure that out, and do another post if necessary. Thanks for pointing it out!

Welcome to the forum @StefanH I took the liberty to edit your post to mark your sketch as code. This makes the code mich easier to read. You can use the </> button on top of the edit area next time. Have you looked at https://github.com/mysensors/MySensorsArduinoExamples/blob/master/examples/DallasTemperatureSensor/DallasTemperatureSensor.ino ? It has support for multiple sensors. In any case, please post the debug output of your sketch. It will make it 10-100x easier to troubleshoot. If you haven't already, see https://forum.mysensors.org/topic/666/read-this-first-it-could-save-you-a-lot-of-time/ for how to enable debug output.

I thought I'd give an update. I added four .470 capacitors in paralel, but the gun was still turning itself off. Then I added the diode, and.. it worked! The gun remains stable. ...at least.. while it was on a beefy lab power supply. It indicates that when firing the gun uses about .6 amps, and it prefers to be around 8.5 volts (6 AA batteries). 9 volts seems to be too much. I tried to switch it to the intended portable design, with a USB PD decoy feeding into a 4A up-down adjustable buck converter. But then it crashes again. For example, I tried this: 55W steam deck USB-C PD power supply -> adjustable decoy set to 15 or 20 volt. down-converting that to 8.5v with the buck converter. Maybe all this power converting means that it can't provide the sudden increases in power when the motor spins up? Perhaps using a linear DC-DC converter work better? Or maybe the USB-PD decoy just can't handle it? It's a mystery.

Thats what I think, a really simple thing, Thank You, it works! resp_sleep=sleep(INTERRUPT,CHANGE,SLEEP_TIME); and then hust a simple if resp_sleep.... Thanks!

hange of direction, we forget the problems mentioned above, another bookstore. The project : reading of the values of an Electric meter with sending of the values on the bus RS485, from Node To Node. . ATmega328 (uno) / TIC demodulator / RS485 shield . ATmega328 / OLED / RS485 shield (DFRobot_RS485_Shield_SKU__DFR0259) [image: e76024d01dad44a91f66f84cd9c60187f8411d35.jpeg] video wiring diagram 2 sketches in txt file the latest version of the MicroQuettas LkyRx_10e.zip (9.4 KB) ... functional project :nail_care:

Nice work @Keichi, thanks for reporting back!

Hi, and thanks for the quick response. I tried the roll back but found that the Lolin S2 Mini was not an option in that version. I tried the Wemos D1 ESP32 and it would compile but the upload failed "Chip is unknown ESP32". I am going to try and use an external FTDI to avoid issues with USBCDC. If that does not work I will just use the D32 module. Thanks for the great body of work and support. I cannot even imagine how much work it must be to try and cover all the different chips and modules. The integration with Home Assistant makes this a breeze!

Nice work @Igor-Vinograd, thanks for reporting back.

@Doubletop Thanks for that. I haven't range limited the readings on this version (ie ignore bad results) but do check for two consecutive readings, thus far no bogus readings recorded. In my own case, the 3v node had no spare pins, so had to expand anyway to avoid using to a second dedicated node. Having read on the 5v returning stable results, went with a second pro-mini at 5v controlling the v3.0 (also enabling further expansion) running off a PSU, talking I2C to the Node. My principal problem was winter condensation on the transducer head due to the pipe used, aside that the v2.0 ran two years before finally dying. This time it's on plastic pipe and the v3.0 is socketed for easy swap should it go faulty, fingers crossed for a trouble free winter.

Still, there seems to be 'someting rotten in the state of Network' where my LAN is concerned. Although the Arduino serial monitor says: 13:03:55.821 -> connected with XXX, channel 6 13:03:55.868 -> ip:192.168.178.4,mask:255.255.255.0,gw:192.168.178.1 13:03:55.915 -> ip:192.168.178.4,mask:255.255.255.0,gw:192.168.178.1 13:04:04.826 -> pm open,type:2 0 when I ping the IP-address I get: Pinging 192.168.178.4 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.178.4: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), When I use the tool 'Wireless Network Watcher' I do see that a device is connected at 192.168.178.4 with the correct MAC address. However, when I look at the management page of my FritzBox 7490 modem/router no device is mentioned at 192.168.178.4. I remain at a loss here.

@DeepCore not wrong frequency no. But it looks like the feather doesn’t come with the antenna pre-soldered. Since the devices should be identical otherwise, the antenna could be what differs. But if it was, the rssi would probably have been different as well.

Try using the Neopixel library. https://learn.adafruit.com/adafruit-neopixel-uberguide/arduino-library-use https://sbaronda.com/2020/09/20/sk6812-with-arduino-using-neopixel-library/ Those should get you started. Basically, instead of having your code directly turn a pin on or off, you tell it to set a color in the library and then run the show() command and the library will do all the pin toggling needed to actually control the LEDs.