Emontx-V3 Upgrade to the last release

Hello Robert
FYI, the radio running on my emontx is a RFM12 not a 69 :frowning:
I have go in deep of the code and the problem appear in the rfm_init function :frowning:
how can we debug this ?
david

That is your problem. The file rfm.ino that you have says at the top: “Interface for the RFM69CW Radio Module” The RFM12B requires a completely different set of instructions.

The best I can offer is this library. It is ALMOST the same as the rfm.ini file that you have, but it adds the ability to control the radio power. There’s documentation (in English - sorry).

The rfm_init( ); function is the same, but the rfm_send( ) function adds the rf power. But you don’t need to specify it, it will default to maximum - which is what you have used until now.

So where you have (2 places)

rfm_send((byte *)&tmp, sizeof(tmp), networkGroup, nodeID, busyThreshold, busyTimeout);

you can reduce that to only
rfm_send((byte *)&tmp, sizeof(tmp), networkGroup, nodeID);
and rf_power, threshold & timeout will use the default values.

To use this in your sketch, you must delete (or move) rfm.ino, and install the library (2 files: rfmTxLib.h and rfmTxLib.cpp) into a directory rfmTxLib in your Arduino libraries directory.

Then, in EmonTxV3CM.ino, you must add
#define RFM12B
and after it
#include <rfmTxLib.h>

and you can delete these lines

#define RFM69CW
#define RFMSELPIN 10
#define RFMIRQPIN 2 
#define RFPWR 0x99 

If enum rfband {RF12_433MHZ = 1, RF12_868MHZ, RF12_915MHZ }; gives you an error, delete it. (It is already in the header file.)

and change “2” to “1” here:
int rf_whitening = 2;

And I think that will work.

rfmTxLib.zip (61.6 KB)

thx a lot Robert :slight_smile: but have you an idea of the previous version ? to restore it ?

The previous version of what?

before the upgade the emontx working well and due at the upgrade 3.4 ko :frowning:(

You want the discrete sampling sketch for an emonTx V3.4 with RFM12B radio?
Don’t you like my library? :cry:

I think it will be this: emontx3/firmware/src at master · openenergymonitor/emontx3 · GitHub
but you must change it for your RFM12B - line 74.

yes i like it :slight_smile: but both option are not working :frowning:

Which options? And how are they not working?

always on rf12_initialize in the setup function and always circle on this function and never arrive in the loop function

Did you change Line 74:
#define RF69_COMPAT 1 // Set to 1 if using RFM69CW or 0 if using RFM12B
to
#define RF69_COMPAT 0

yes done :frowning:

I have suggested two different things, but all you say is it does not work. If you find it easier to explain more in your own language (Francais, Nederlands?), please do so and I will continue to try to help you.

no prob to continue in English

If it gets stuck in there, it is because the RFM is not responding. And there are usually only two reasons for that: (1) the RFM itself is faulty or there is a bad soldered joint, or (2) you are sending the wrong commands to it.

As it did work, unless you have damaged the RFM, it is unlikely to be (1).

It will work on the wrong frequency with very reduced range, so it’s not that.

I think also that the root cause of my prob is the radio part because in all cases (my testing) , the emontx block in the setup process
also my test was failed to enter the loop function with the radio enable … with the radio disable, the loop function is working :frowning: => my conclusion , radio part is defect …

are you aware with my approach ?

next week , I will order a new emontx because needed with a radio … and I will use in serial mode the previous emontx for a next project

david

Yes, your thinking is correct.

It would be a rare coincidence - but not impossible - that the radio has failed just as you changed the software. It might be good to look very carefully at the soldering of the RFM12B, just in case it is a bad joint.

Also, I have read that the “black dot” type of encapsulation of some RFM12Bs is less reliable (this sort: Learn | OpenEnergyMonitor).

Thank you guys for the new firmware version for EmonTxV3CM. :+1:
I loaded V1.9 onto one of my units the other day and noticed that the first call to list_calibration(), which lists the number of temperature sensors detected and if temperature measurement is enabled, is prior to the point where the calls to EmonLibCM set up the temperature sensors. The effect of this is that the first output of the calibration information can inappropriately identify that ‘Temperature measurement is NOT enabled’ when later on it is.
I am not sure how to inject a problem report into the OEM configuration management processes which are clearly there, so I hope you don’t mind it being identified here. I could not locate another suitable thread where the new firmware was being discussed.

The sensors addresses are in fact read first from EEPROM, so the report is factually correct - at the point where that first report is made, temperature measurement has not been enabled, the sensor addresses are yet to be loaded into the library, and until that happens, the temperature measurements can’t be done. So it’s a tail-chasing problem.

I see. Thank you for the clarification.

6 posts were split to a new topic: EmonTx V3.2 - Upgrade to use emonLibCM