Multiple problems w. EmonTx and RFM69Pi

Getting Started
1

Good morning!

I was going to roll my own energy monitoring, but instead I thought I’d buy a ready made solution expecting it to be a lot easier and quicker. Sadly this has not been the case so far. And I’m struggling to work out what’s going on, and I’m kind of wishing I’d stuck with the original plan, as at least I’d have some understanding of what I’d done, and be better able to diagnose it, having built it.

Anyway… I got my EmonTx V3, 3x CTs, flash pulse sensor, and RFM69Pi through and tried to make it all work last night and this morning.

I will try and split this post into two pieces, though they somewhat overlap :-

1st, I think my EmonTX may be faulty.
2nd I think my RFM69Pi may be faulty.

I am flummoxed and surprised at how unlucky and unlikely this is, but I think I’ve done the necessary due diligence to rule out other possibilities.

EmonTX

My EmonTX is connected up, appears to be doing the expected lights-flash sequence on boot, and then flashes once every 10s approximately. So it feels like that is OK. The antenna is firmly attached. All looks well, visually.

(RFM69Pi)

I initially tried receive the EmonTX’s transmissions on the Pi using the RFM69Pi. This did not go well. I initially thought that a screen I’d had on the GPIO pins might be causing a conflict, but I did do the necessary to remove support for the screen and switch back to HDMI. Still no joy. I also wondered if If somehow I’d been supplied a board that had not had its firmware loaded, so I followed the instructions to try and re-flash the firmware using avrdude. This did not appear to work. Oddly the board does flash its LED from time to time. So it seems “somewhat alive”.

Essentially minicom using the relevant parameters shows nothing. And flashing the firmware gives strace broken pipe errors.

So thinking I’d try another route, and figuring perhaps I had a faulty RFM69Pi, I thought “I know what I’ll do, I’ll use rtl_433 to receive it”. If you’re wondering why I bothered with a RFM69Pi at all, knowing I had the SDR option, it’s because I want to use the SDR to receive my 868 MHz weather station.

Here is where it gets weird.

I cannot see the EmonTX on rtl_433 either. And I KNOW my SDR is fine, because I can see several of my 433 MHz temperature sensors dotted around. So that is “known good”.

I moved my SDR and Pi to be within 2ft of the EmonTX. Still nothing seen on rtl_433. Re-tested with the RFM69Pi board. Still nothing.

So the TL;DR version is:-

  1. I think maybe my RFM69Pi may be faulty.
  2. I am pretty sure my EmonTX is faulty; having now tested it with a receiver that is ‘known good’ for other 433 devices.

Am I just really unlucky? I don’t want to think that OEM is a pile of junk, but having spent £ on this, I can’t help feeling disappointed. If it had been one thing, I think I’d have felt “oh well, just unlucky” but (and again I’d be delighted to be proved to have been doing something stupid and everything is fine) I feel I’ve done the necessary to narrow down the location of at least one fault, and it feels like the EmonTx is not Txing.

Any thoughts?

2

Welcome to the forum, Bloor.

I’m sorry you seem to be having a bad experience. I’ll do my best to help, but I’m not an expert on the RPi, so it might need someone else to chip in there.

I assume you don’t have a programmer to connect between the FTDI and your computer?

I think I’d agree there. Normally, if there’s a problem with the RFM69CW radio in the emonTx it doesn’t get past the initialisation stage. The fact that it has doesn’t prove all is OK, it has been known to get that far and still not transmit, but it does show it’s not the usual fault.

How much of the 433 MHz band did you check? As far as I know, the frequency we use is 434 MHz exactly, I would have thought you would have seen something if you were 1 MHz away, but it’s something to look at.

Can you receive the RFM69Pi with your SDR receiver? (Beware, this is where I start to struggle.) I think it accepts the JeeLab commands which you send as serial data (I think it should be at 38400 baud), which are:

  <nn> i     - set node IDs (standard node ids are 1..30)
  <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
  <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
  <n> c      - set collect mode (advanced, normally 0)
  ...,<nn> a - send data packet to node \<nn>, request ack
  ...,<nn> s - send data packet to node \<nn>, no ack
  v          - Show firmware version
  <n> q      - set quiet mode (1 = don't report bad packets)

[Node ID isn’t relevant to you.]

3

Thanks! It’s cool to find such a resource! This is a mega win with OpenSource stuff.

And thank you for replying!

Regrettably I don’t think that I do :frowning:

But I was hoping to not need to delve that deep by just buying it ready made haha.

Hmm, I think that’s reassuring. Sort of :slight_smile:

I simply ran rtl_433 and watched. I think almost everything normalises on 433.920 doesn’t it? Leastways, literally everything I’ve intercepted using rtl_433 has been before; and I mean everything; car tyre pressure monitoring systems, temperature/humidity sensors, etc. etc. etc.

You’ve made me think though… In another life I am a radio ham, so I could just see what one of my 70cms handhelds does when scanning through. The issue being I’d ideally like the emonTx to ‘key up’ for a bit more time than a single burst of data. Hmmm. Or I could buy a cheap frequency counter, which arguably I ought to have anyway…

Ok, well now I’m flummoxed again, as I had no idea RFM69Pi was a transceiver!! I assumed that it was a receive only module! I don’t think this was expressly said anywhere in the docs, though I do feel a bit silly for not realising.

I’m not sure how I could make the RFM69Pi transmit; especially as I cannot seem to connect to it (or, leastwise get anything out of it) via the GPIO TTY. Or at least, I may be sending it stuff, but is it supposed to respond? I guess I need to issue it a command, and should it respond somehow, like “OK”?

I try and do that on the minicom, and I get nothing back whatsoever. And then usually minicom locks up and I have to actually disconnect my ssh from the pi. It definitely doesn’t feel like the board is talking serial properly anyway.

One other piece of the puzzle; I’m nearly sure the LED on the RF module does flash its LED almost in sync with the flash of the LED on the emonTx. So that also is suggestive that on the RF side something is working. BUT makes it even more mysterious that I cannot see the emonTx via rtl_433.

Thanks for your thoughts! Much appreciated!
B.

4

What baud rates have you tried to talk to the RFM69Pi?

If you say “v” to it at the right baud rate, it should answer.

N.B. As you didn’t mention it, I’m assuming all along that you’re not using our SD Card (or emonCMS download) in your RPi.

5

I think perhaps I should download the SD image and try that - just in case something is screwy with my Raspian.

I am running minicom with the command :

sudo minicom -b38400 -D/dev/ttyAMA0

so 38400baud, I think.

One interesting thing I’ve noticed, for sure now, and even videoed for my own sanity. Hopefully posting this link is not outside the rules :

It does seem as though, adjacent to one another, the emonTx and the RFM69Pi are both blinking LEDs almost in unison. Which, I think, implies that at an RF level, they’re working happily?

If that does mean that the emonTx is … er … TXing, then that still doesn’t really explain why my rtl_433 isn’t seeing it, other than perhaps it’s on the wrong frequency.

It also doesn’t provide an answer to why I cannot seem to serial to the RFM69Pi, but it is indicative that the board, for at least some definition of “functional” is functional…

Hrmmmmm… thanks again for your replies.

B

6

I should also add I’ve googled to try and find the frequency, and it is only ever expressed as 433. Nothing in the decimal places. I’m pretty sure it won’t be on 433.0… And think 433.92 is most likely, as that is what literally everything else I’ve ever handled is on. But, no emonTx seen on that frequency…

7

This is the output when I run up rtl_433; as you can see it’s definitely receiving my cheapy room temperature sensor quite happily.

pi@raspberrypi** : ~ $ rtl_433
rtl_433 version 18.12-71-gb8578dc branch master at 201901231237 inputs file rtl_tcp RTL-SDR
Trying conf file at “rtl_433.conf”…
Trying conf file at “/home/pi/.rtl_433/rtl_433.conf”…
Trying conf file at “/usr/local/etc/rtl_433/rtl_433.conf”…
Trying conf file at “/etc/rtl_433/rtl_433.conf”…
Registered 96 out of 120 device decoding protocols [ 1-4 8 11-12 15-21 23 25-26 29-36 38-60 62-64 67-71 73-100 102-103 108-116 119 ]
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
me : **2019-05-18 22:59:20
del : Fine Offset WH5 sensor ID : **246
mperature: 21.2 C Humidity : 50 % Integrity : **CRC
^CSignal caught, exiting!

8

You can just run emonhub on it’e own without emoncms to interface to the RFM board.

@pb66 just uses node-red serial node to interface IIRC.

9

I’ve told you the frequency, but I would have thought that 80 kHz away you would have seen something. And note that the emonTx doesn’t flash its LED as it transmits, it flashes it immediately after it has completed the transmission. (This is to save current, as the power supply is strictly limited.)

1 Like
10

Stupid question: does the device get created/made to work by emonhub?

Am I missing a big point here? I.e. that the device /dev/AMA0 needs emonhub to exist/work at all? I’d assumed it was nearer the hardware layer than that.

11

Sorry - I interpreted “As far as I know, the frequency we use is 434 MHz” as something I needed to do further research on :slight_smile: I have tried forcing the rtl_433 onto 434.0MHz and, indeed, still see nothing.

Cool. That’s a very sensible design decision.

12

The RFM board simply takes the RFM signal and sends received messages out via the serial interface.

emonhub is simply a python script to decode that serial data and send it onwards.

However, if the firmware is no longer stock (as delivered), determining the issue is more difficult to solve (and not my area of expertise).

13

BTW have you disabled bluetooth on the Pi?

1 Like
14

I have not! I am sure the ‘getting started’ instructions didn’t tell me to do so.

I did disable the serial console, though

$sudo rpi-serial-console status
Serial console on /dev/ttyAMA0 is disabled

Do I need to disable bluetooth also then?

15

I did write “434 MHz exactly”, i.e. 434.000000 MHz. It came from my stand-alone transmit code that was cribbed directly from JeeLib:

	#else // default to 433 MHz band
		writeReg(0x07, 0x6C); // RegFrfMsb: Frf = Rf Freq / 61.03515625 Hz = 0x6C8000 = 434.00 MHz as used JeeLib 
		writeReg(0x08, 0x80); // RegFrfMid
		writeReg(0x09, 0x00); // RegFrfLsb
	#endif

And I assume JeeLib has the multiplier constant right, as it is given in the RFM69CW data sheet as FOSC / 219, and FOSC is 32 MHz.

1 Like
16

HOLY COW. THAT WORKED. Disabled bluetooth. Bingo.

A thousand thanks.

Welcome to minicom 2.7

OPTIONS: I18n 
Compiled on Apr 22 2017, 09:14:19.
Port /dev/ttyAMA0, 23:29:16

Press CTRL-A Z for help on special keys

OK 8 178 1 189 1 86 254 0 0 194 96 184 11 184 11 184 11 184 11 184 11 184 11 196 53 0 0 (-26) 
OK 8 174 1 169 1 88 254 0 0 203 96 184 11 184 11 184 11 184 11 184 11 184 11 197 53 0 0 (-26) 
OK 8 197 1 198 1 61 254 0 0 127 96 184 11 184 11 184 11 184 11 184 11 184 11 198 53 0 0 (-26) 
OK 8 192 1 197 1 50 254 0 0 178 96 184 11 184 11 184 11 184 11 184 11 184 11 200 53 0 0 (-26)
1 Like
17

Yes as it is a shared UART.

Which instructions did you use?

1 Like
18

I’ve got that T-Shirt in the wardrobe.

19

https://wiki.openenergymonitor.org/index.php/RFM69Pi_V3 (doesn’t mention disabling bluetooth)

Thanks so much, again. I literally never would have thought of that.

20

@alexbloor, from what you have posted I think both the emonTx and the RFM2Pi were fine, providing you have flashed the right FW that should still be the case.

You can ignore the strace errors, that is just a quirk of the avrdude-rpi wrapper.

We do not know anything about your RPi image so an easy check would indeed be to download and install either a stack Raspbian image or a emonSD image for testing so we know what we have.

However there are 2 main differences between a stock raspbian image and the emonSD and we do not know if either of these have been altered in your image.

  1. is the serial console needs disabling BUT without disabling the GPIO serial port altogether.
  2. The GPIO and Bluetooth are remapped by an overlay so that the GPIO is using the better serial port (normally mapped to the bluetooth on a Pi3)

You can get around the mapping just by using /dev/serial0 instead of /dev/ttyAMA0 or /dev/ttyS0.

If you are confident about using the gpio pins directly, then a good test would be to wip off the rfm2pi and link the rx and tx pins of the gpio serial port together. Then when you use minicom, everything you send should be echoed back to you. This proves you are using the right address and minicom is working ok. Then remove the link and refit the rfm2pi, it should work providing the baud is 38400 and it is set to the right freq and group (the defaults are correct) which can be changed by using the instructions posted by Robert earlier.

[edit - I have just edited the formatting in Roberts post as it wasn’t displaying quite right, so hopefully it makes better sense now]

1 Like