RFM69Pi implementation using a Moteino

(Kobuki) #1

I’m trying to run the RFM69CW_RF12_Demo_ATmega328.ino sketch on a standard Moteino setup with an RFM69W 433MHz (not CW, but shouldn’t matter) but I receive nothing. It was working for a few minutes yesterday but after a re-plug of the USB-serial interface it doesn’t work any more nothing else changed. Is the mentioned sketch able to run on a Moteino without any change? What should I verify? Did anyone do something similar? I might even have a dead transceiver but I don’t know…

(Robert Wall) #2

That points to two possible areas that you need to investigate further:

  1. A faulty lead or connection.
  2. A change in the software setup / default settings, possibly in the computer you’re using. (Meaning that you’d changed a default setting to make it work, which has now gone back to the original value that does not work.)

I looked at a couple of versions of that sketch, both were far too complicated to understand without doing a lot of work, so if you need to establish whether the radio module itself is faulty, find the simplest possible test sketch that has absolutely no complication and try that. (This is all basic fault-finding: remove as many variables as possible so that there are the fewest possible permutations to try - ideally ONE.)

(Paul) #3

Another possibility is if you are plugging your usb device into a linux box eg a RPi, the kernels allocation of device ids will usually result in a change of id. for example if you have just one usb device it will probably be recognized as /dev/ttyUSB0 the first time it’s plugged in, pull it out and plug it in again it will usually then be recognized as /dev/ttyUSB1 unless you reboot.

(Kobuki) #4

Thanks for the replies. I’m using these devices a lot but this was the first time I used them with one of the Emon series code (fairly complicated for what they do, not counting the EmonLib itself). All the basics are fine, cable is working, sketch is uploading without problems, etc. I concluded that it’s most probably the RFM module that died on me. My own sketches also stopped working with this module after this fault. Unfortunately I don’t have more 433MHz modules but will buy a few tomorrow and replace the suspect. It still could be a problem with the MCU. I will report back later.

(Robert Wall) #5

Are you using the correct, matched, antenna? I have not checked the RFM69W, but the RFM69CW data sheet warns against transmitting at full power without the correct antenna, as the device (output stages of the transmitter) could be damaged.

(Kobuki) #6

I’m using a suitably sized monopole wire. The W and CW variants are functionally the same, but the CW has an RFM12-compatible solder pad layout and uses the same form factor. The Moteino is on the receiving side, and this particular one has only been used for reception. I don’t know if the Emon sketches use acks or not. That would switch it to transmission for sending the acks but I use the recommended antenna wire size, there should be no problem (never had problems with 868 MHz ones using either wire monopoles or factory-tuned rubber ducky ones, send or receive).

(Kobuki) #7

OK, I replaced the faulty RFM69 module and made sure with my existing test sketches that the new one works. It still can’t receive the packets sent by the EmonTX transmitter. I have a simple RSSI monitor for the module and it shows a high RSSI burst of about 7 ms every 10 secs so something’s coming from the transmitter and the module does sense it in some way. Also checked with an RTL-SDR stick that the transmitter indeed transmits something. So both sides seem to work at the basic level, but still no frames are received.

I’m using RFM69CW_RF12_Demo_ATmega328.ino as receiver and emonTxV3_4_DiscreteSampling\src\src.ino as transmitter. I only changed the Vcal value (simple voltage calibration with a multimeter) and uploaded it into the EmonTX 3.4. I compiled both using Arduino 1.6.9. I’m stuck. Please help…

Clamp meter positioning
(Kobuki) #8

Ah, well. I recompiled the EmionTX sketch and uploaded it again to the device. It now works:

OK 8 0 0 0 0 0 0 0 0 124 94 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-35)
OK 8 0 0 0 0 0 0 0 0 236 93 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-36)

Is this the kind serial output that can be interpreted by the EmonHub? If so then using a Moteino in its standard configuration is dead simple for receiving EmonTx packets.

(Paul) #9

Yep, that looks ok!

(Kobuki) #10