Homebrew emonTx and emonPi RF problem

Hi
I made emontx v3.4 and emonpi from gerber files and fully assembled them.
I used RFM12B 915MHz and i can’t make tge connection between emonpi and emontx
I changed firmware and used 915 mhz on both firmwares of emonpi and emontx
But nothing changed
I used UART to check if emon tx sends data using RF but it only said POST… wait 10 secs and then nothing printed again

I disabled RF in firmware and uploaded again and serial monitor worked fine and printed 4 ct’s info.

My main question is that
Can i use RFM12B 915MHz in emonPi and emonTx or it won’t work?

I do not know that it works - I have only ever used 433 MHz & 868 MHz. But equally, I do not know a reason why it should not work.

Have you changed the frequency in both emonTx and in the emonPi?

Have you changed the flag to JeeLib in both to tell it to use RFM12B code and not RFM69CW?
#define RF69_COMPAT 0

Have you updated the emonPi since you changed the sketch in the Atmel 328P? Because if you have, then your change has been overwritten and it has gone back to thinking you have a RFM69CW at 433 MHz

In your emonTx, if you see nothing after “POST…wait 10s” then put a print statement each side of
rf12_initialize(nodeID, RF_freq, networkGroup); // initialize RFM12B/rfm69CW
and prove that it is stopping there. If it is, it means that the RFM12B is not completing the initialization process. In addition to the points above, check that the RFM12B connections are correct and good.

Good effort @Amir_SaRad making the emontx and emonpi from scratch! would be great to see some pictures if you’d like to share. Cant add anything further to what @Robert.Wall has said, let us know if you get it to work!

Thanks for your fast response and sorry for my late response
Yes i changed flags and frequency
But you’re right i checked emonpi log and every time it overwrites the changes i made.

i reuploaded emonTx FW and 2 questions:
1- i burned bootloader of Uno , is it ok?
2- in emonTx FW baudrate is 115200 but in emonPi it’s 38400 , is it ok,too?

i also attached emonTx serial monitor after reuploading

two more questions:
can i upload FW and then update using emoncms and then change frequency to 915 and network group to 212 in emonhub.conf?

i want to use 5 emonTx with a single emonPi
how should i set node IDs in FW?
i saw a topic about node IDs in serial mode(https://github.com/openenergymonitor/emonhub/blob/emon- pi/configuration.md), can i just change FW for each emonTx and don’t do this?

i also want to know why this message appears?
i burned bootloader of Uno by arduino itself i didn’t use optiboot.

thanks
of course



1 Like

Please make it clear which device you are talking about.

You need to update your emonPi as an emonBase, NOT as an emonPi. That way, the serial baud rate to the ‘Emon’ board will be wrong, and the update will fail - and your firmware in the ‘Emon’ won’t be overwritten.
[It is a pity that there cannot be a better way to prevent custom firmware being overwritten.]

You have not done this? ! !

I believe that’s what we normally use.

They are different devices. As long as you remember to switch your end to the right speed for whichever you are talking to, everything should work.

I would expect that to be OK.

If you have the DIP switches, you can use those for 4 (as you won’t need the “USA” switch), but you will need to change the NodeID for the 5th.
Alternatively (and this is how I would do it), I would have not had the DIP switches and I would have had 5 different sketches, one for each emonTx. The only difference would be the one line
byte nodeID = 10;
Look at emonhub.conf to see the NodeIDs that are already configured for an emonTx. It will be best to use those - but you don’t have to, you can choose any number 1-30 as long as you don’t duplicate a number. Your Pi will be 5, but you can change that too, if you wish.

It means what it says. The sketch is large, there is little spare memory. The sketch has options to enable us to use the same sketch for most users, but not everybody uses everything. If you are concerned, you can remove parts that you do not need - e.g. the switch and text for USA, the switches and text for RF Frequency, etc.

Thanks for guide
It is really helpfull
Sorry I’m a noob :joy:
I don’t have RFM12Pi so i use just emonPi button.
I will change the sketch and let you know if i could make it work
Thank you so much again :blossom::hibiscus::tulip:

hello
i changed RF configs and then i booted emonpi and emontx at the same time
then it appeared in inputs but just updated once
emonpi updates its values well but emontx stopped
i rebooted emonpi then again checked input but this time emontx was n/a
i rebooted them again at the same time and again emontx updated once.




i have another question:
i edit emonhub config from emoncms but in emongub/conf/emonpi.default.emonhub.conf it didn’t change.

what should i do?
i’m confused.

this is emonhub log:
2017-10-26 17:45:47,819 DEBUG RFM2Pi 21 Timestamp : 1509039947.82
2017-10-26 17:45:47,820 DEBUG RFM2Pi 21 From Node : 5
2017-10-26 17:45:47,820 DEBUG RFM2Pi 21 Values : [0, 0, 0, 198.16, 0, 0, 0, 0, 0, 0, 0]
2017-10-26 17:45:47,821 DEBUG RFM2Pi 21 Sent to channel(start)’ : ToEmonCMS
2017-10-26 17:45:47,821 DEBUG RFM2Pi 21 Sent to channel(end)’ : ToEmonCMS
2017-10-26 17:45:47,912 DEBUG MQTT Publishing: emon/basupi/power1 0
2017-10-26 17:45:47,914 DEBUG MQTT Publishing: emon/basupi/power2 0
2017-10-26 17:45:47,915 DEBUG MQTT Publishing: emon/basupi/power1pluspower2 0
2017-10-26 17:45:47,916 DEBUG MQTT Publishing: emon/basupi/vrms 198.16
2017-10-26 17:45:47,918 DEBUG MQTT Publishing: emon/basupi/t1 0
2017-10-26 17:45:47,919 DEBUG MQTT Publishing: emon/basupi/t2 0
2017-10-26 17:45:47,920 DEBUG MQTT Publishing: emon/basupi/t3 0
2017-10-26 17:45:47,922 DEBUG MQTT Publishing: emon/basupi/t4 0
2017-10-26 17:45:47,923 DEBUG MQTT Publishing: emon/basupi/t5 0
2017-10-26 17:45:47,924 DEBUG MQTT Publishing: emon/basupi/t6 0
2017-10-26 17:45:47,926 DEBUG MQTT Publishing: emon/basupi/pulsecount 0
2017-10-26 17:45:47,927 INFO MQTT Publishing: emon/basupi/rssi 0
2017-10-26 17:45:47,928 INFO MQTT Publishing: emonhub/rx/5/values 0,0,0,198.16,0,0,0,0,0,0,0
2017-10-26 17:45:47,930 INFO MQTT Publishing: emonhub/rx/5/rssi 0
2017-10-26 17:45:52,845 DEBUG RFM2Pi 22 NEW FRAME : OK 5 0 0 0 0 0 0 139 77 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
2017-10-26 17:45:52,848 DEBUG RFM2Pi 22 Timestamp : 1509039952.85
2017-10-26 17:45:52,849 DEBUG RFM2Pi 22 From Node : 5
2017-10-26 17:45:52,849 DEBUG RFM2Pi 22 Values : [0, 0, 0, 198.51, 0, 0, 0, 0, 0, 0, 0]
2017-10-26 17:45:52,850 DEBUG RFM2Pi 22 Sent to channel(start)’ : ToEmonCMS
2017-10-26 17:45:52,850 DEBUG RFM2Pi 22 Sent to channel(end)’ : ToEmonCMS
2017-10-26 17:45:52,941 DEBUG MQTT Publishing: emon/basupi/power1 0
2017-10-26 17:45:52,942 DEBUG MQTT Publishing: emon/basupi/power2 0
2017-10-26 17:45:52,944 DEBUG MQTT Publishing: emon/basupi/power1pluspower2 0
2017-10-26 17:45:52,945 DEBUG MQTT Publishing: emon/basupi/vrms 198.51
2017-10-26 17:45:52,946 DEBUG MQTT Publishing: emon/basupi/t1 0
2017-10-26 17:45:52,948 DEBUG MQTT Publishing: emon/basupi/t2 0
2017-10-26 17:45:52,949 DEBUG MQTT Publishing: emon/basupi/t3 0
2017-10-26 17:45:52,950 DEBUG MQTT Publishing: emon/basupi/t4 0
2017-10-26 17:45:52,952 DEBUG MQTT Publishing: emon/basupi/t5 0
2017-10-26 17:45:52,953 DEBUG MQTT Publishing: emon/basupi/t6 0
2017-10-26 17:45:52,954 DEBUG MQTT Publishing: emon/basupi/pulsecount 0
2017-10-26 17:45:52,956 INFO MQTT Publishing: emon/basupi/rssi 0
2017-10-26 17:45:52,957 INFO MQTT Publishing: emonhub/rx/5/values 0,0,0,198.51,0,0,0,0,0,0,0
2017-10-26 17:45:52,958 INFO MQTT Publishing: emonhub/rx/5/rssi 0
2017-10-26 17:45:57,817 DEBUG RFM2Pi 23 NEW FRAME : OK 5 0 0 6 0 6 0 154 77 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
2017-10-26 17:45:57,820 DEBUG RFM2Pi 23 Timestamp : 1509039957.82
2017-10-26 17:45:57,820 DEBUG RFM2Pi 23 From Node : 5
2017-10-26 17:45:57,821 DEBUG RFM2Pi 23 Values : [0, 6, 6, 198.66, 0, 0, 0, 0, 0, 0, 0]
2017-10-26 17:45:57,821 DEBUG RFM2Pi 23 Sent to channel(start)’ : ToEmonCMS
2017-10-26 17:45:57,822 DEBUG RFM2Pi 23 Sent to channel(end)’ : ToEmonCMS
2017-10-26 17:45:57,912 DEBUG MQTT Publishing: emon/basupi/power1 0
2017-10-26 17:45:57,914 DEBUG MQTT Publishing: emon/basupi/power2 6
2017-10-26 17:45:57,915 DEBUG MQTT Publishing: emon/basupi/power1pluspower2 6
2017-10-26 17:45:57,917 DEBUG MQTT Publishing: emon/basupi/vrms 198.66
2017-10-26 17:45:57,918 DEBUG MQTT Publishing: emon/basupi/t1 0
2017-10-26 17:45:57,919 DEBUG MQTT Publishing: emon/basupi/t2 0
2017-10-26 17:45:57,921 DEBUG MQTT Publishing: emon/basupi/t3 0
2017-10-26 17:45:57,922 DEBUG MQTT Publishing: emon/basupi/t4 0
2017-10-26 17:45:57,923 DEBUG MQTT Publishing: emon/basupi/t5 0
2017-10-26 17:45:57,925 DEBUG MQTT Publishing: emon/basupi/t6 0
2017-10-26 17:45:57,926 DEBUG MQTT Publishing: emon/basupi/pulsecount 0
2017-10-26 17:45:57,927 INFO MQTT Publishing: emon/basupi/rssi 0
2017-10-26 17:45:57,929 INFO MQTT Publishing: emonhub/rx/5/values 0,6,6,198.66,0,0,0,0,0,0,0
2017-10-26 17:45:57,930 INFO MQTT Publishing: emonhub/rx/5/rssi 0

Your emonPi appears to be updating its own voltage and sending it to emonHub, but we don’t know whether it is receiving anything. I suspect that it is not. Normally, we see things like this

2018-08-28 11:32:27,062 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 15 36 226 220 212 10 185 34 152 58 228 23 201 241 93 64 194 101 252 27 86 (-110)
2018-08-28 11:32:28,411 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 17 22 38 202 210 136 129 10 211 24 198 78 7 246 64 128 29 212 234 200 162 (-108)

in the log that are indicative of noise or other transmitters using the band, and I don’t see any of that.

Is your emonTx transmitting every 10 s (or at whatever interval your sketch says)?

The clue is in the name. That is the default file. The file you edited is not that one, it is /home/pi/data/emonhub.conf

Emontx sends data in serial 115200 baudrate.
I checked emonhub.conf and it wasn’t changed neither.
I checked nodename in emonhub and it’s emontx3 but in FW it says
Payload tx emontx
Can this be the problem?

And i had one more question
Can i turn off auto update of emonpi?
It messes up the FW every time.

Do you really mean that? Earlier, you asked about changing the radio frequency to 915 MHz. Is it using the radio or a wired serial connection to send the data?

I thought did not update automatically. However, even moderators don’t get notified of changes, so I might be out of date.

I’m guessing you mean can you update the emonPi/SD without automatically updating the emonpi add-on board firmware. Yes you can, use the “Update emonBase” not the “Update emonPi” button, bit of a backdoor approach but that way it fails to upload new firmware because it tries to use the wrong upload baud.

See Update EmonPi Button or Update EmonBase Button? for a fuller explanation.

[EDIT} Unless…

The only time a “automatic update” occurs is at first boot of a new emonSD image. There is no easy way to stop that from updating as an emonPi since the distinction between an emonPi and emonBase came along later so yes at the very first boot of a fresh emonSD image it will automatically overwrite your FW. There are 3 ways to avoid this, none are ideal.

  1. Remove your emonpi board from the RPi until that first boot update has happened, then after that you can reattach and there will be 2 update buttons (as described above) so you can use the emonBase button going forward.

  2. Do the initial “first boot” on another Pi then move the emonSD card to the emonPi.

  3. Edit the image on another machine and create a blank emonpiupdate.log file in the data directory, this is the flag that starts the “first boot” update, but that will not help you much as that first update needs to happen for you to get the second update button, unless you manually update emoncms (git pull and login to update db) , then click “update emonBase” from within emoncms to get the full update.

no i mean it sends data to serial monitor

no in first boot it updates itself
i disconnected network from internet but next time that i went online it updated automatically in boot.

I was just editing my last post, that first boot update has you by the short and curlies and is not easy to get around.

So do you mean via serial-usb adapter? Obviously it cannot be via the GPIO serial port as the emonPi board is occupying that. Therefore you must have another section in the emonhub.conf that uses an EmonHubSerialInterfacer or EmonHubTx3eInterfacer.

However, looking back at this picture

image

That looks very much like it’s using RF, there is no usb-serial adapter in sight, nothing attached to the 6pin header and it looks like it’s powered via a samsung phone charger. Have you changed it since posting these pictures?

The fact it stopped after you changed the RF settings would make far more sense if it was RF not serial connected.

OR have you just added a serial-usb adapter since the rf stopped working for debugging? It’s a little unclear what you have and what you are trying to do.