Will it be possible to use the RFM69 in packet mode with the expansion module?

[brandon3055]

Good Afternoon.

I have been experimenting with adding an expansion module to my DIY emontx4. But I quickly discovered that the existing rfm_send function
https://github.com/openenergymonitor/emontx4/blob/main/firmware/EmonTxV4CM/EmonTxV4CM_rfm.ino#L122
has a maximum payload size of 56 bytes which is far exceeded when trying to expand to 12 channels.

I would just like to know if this is something that can be fixed. or do I need to switch to the RFM69 native format if I want 12 channels?

Edit: on further investigation, it seems rfm69nTxLib has the same 56 Byte limit. Is it even possible to expand this limit?
I think for now I will just try splitting the data across two separate node ids.

[TrystanLea]

Hello @brandon3055 yes both have the limit as you observe and the 12 channels would need to be split. Robert Wall is developing new firmware for the emonTx4 from scratch to try to cater for the wider set of requirements, both single and 3 phase, plus up to 12 channels, it's likely to be available further down the line. Id be interested to hear how you get on expanding to 12 channels with the existing firmware though!

[brandon3055]

Success!
The config system has been expanded to support the additional channels, And the extension module can be enabled/disabled,
The amount of repetition in the code was kinda bothering me, especially when expanding to 12 channels. So reconfigured everything to be loop-based.
This also includes support for a second pulse input.

https://github.com/brandon3055/emontx4/blob/main/firmware/EmonTxV4CM/EmonTxV4CM.ino
https://github.com/brandon3055/emontx4/blob/main/firmware/EmonTxV4CM/EmonTxV4CM_config.ino
brandon3055@f8f613d#diff-1e5dcabf60786003c0b0e32726c4e0b173f27a7a9cb7b377d76256f4ba6b7f2d

I spent way too long trying to figure out how I broke the calibration command only to discover that EmonLib's EmonLibCM_ReCalibrate_IChannel simply does not work correctly when using this many channels.
I guess that would explain why parts of the config were disabled.
https://github.com/openenergymonitor/emontx4/blob/main/firmware/EmonTxV4CM/EmonTxV4CM.ino#L158
Fortunately, calibration still works. It just takes a reboot to load the new values.

I do have one question. It relates to my post on the forum. https://community.openenergymonitor.org/t/avr-db-emontx-v4-new-hardware-in-progress/20209/171
I based my extension board on the old circuit because I mistakenly assumed that was a new/improved design.

Is noise enough of an issue that I should consider switching to the new design? Or will it most likely be fine?

[TrystanLea]

Great to see the above @brandon3055, impressive! and I like the 3d printed fascia.

Did you see my commit here relating to EmonLibCM_ReCalibrate_IChannel? I had not mapped these correctly
bf63ca4

Nice work with the loop based approach!

Is saving to EEPROM working for you?

Regarding noise, how do your zero current readings compare between the two types? Do you notice any difference if the CT is clipped around the wire (with no load) or on the work bench? The difference may not be significant enough to make it worthwhile your effort to change?

[brandon3055]

Did you see my commit here relating to EmonLibCM_ReCalibrate_IChannel? I had not mapped these correctly
bf63ca4

Ahh! I wondered if it might be that. Good to know!

Saving to EEPROM works fine. The only thing stopping it from working in the existing firmware is the fact that load_config(true); and readConfigInput(); are commented out. But i suspected that was because of the calibration issue which it seems you have now solved in the rfn69n version.

As far as noise. I'm not sure how i missed it before but i do see current readings fluctuating between around 20 and 400ma.
So yea. I guess i will just have to add the new board to my next jlcpcb order.

[TrystanLea]

Great thanks, happy to send you the CT extender PCB, I have a few spare (all partially assembled). If that's useful feel free to send me a PM via the forum. It's great having your input testing this!

[TrystanLea]

Got the EEPROM to work here. I had to make the following changes to the emonEProm library to get it to work. Is there a chance it wasn't actually saving for you?

openenergymonitor/emonEProm@ce8aa27

I've also put together a little web-serial tool to make configuration easier, this is going to be nice! :)
https://openenergymonitor.org/serial/

It requires a web-serial compatible browser e.g Chrome

[brandon3055]

Great thanks, happy to send you the CT extender PCB, I have a few spare (all partially assembled). If that's useful feel free to send me a PM via the forum. It's great having your input testing this!

It's all good. I have already ordered new boards. It's so nice being able to just order 5 professionally made PCBs for like $10 delivered!

Once those and my extra CTs arrive I can do more testing. When prototyping you never order just enough components for one board so I ended up building a second monitor for a friend and a third just to play with.
I decided to include the expansion module so he would have the option to expand once the 12CT firmware was available.
But it seems I lack the ability to leave something unfinished so here we are xD

Got the EEPROM to work here. I had to make the following changes to the emonEProm library to get it to work. Is there a chance it wasn't actually saving for you?

Dont know what to tell you. Its definitely working for me without those chances. All I had to do was uncomment the load_config line. My firmware is based on the old EmonTxV4CM not the new EmonTxV4CM_rfm69n firmware if that makes any difference.

The config for my emonMicro is based on the same code and I didn't notice any issues with those either.

I've also put together a little web-serial tool to make configuration easier, this is going to be nice! :)

That looks nice! I can't wait to test it out!
Though that reminds me. I noticed you changed the default lead from 1.5 to 3.2. But as far as I could tell the power factor readings were already pretty much perfect. Usually around 0.999~ for a resistive load.

Edit: Just took a quick look at the configurator. I definitely like the look of it! Sending commands does not seem to work though I suspect that's just because it's a WIP.
I notice there is no way to fine-tune the calibration. Is that planned? or is calibration not an issue with the CTs you use?
I have been using cheap ali 100A/50ma CTs. I just open them up and install a 22R1 burden resistor to convert them to theoretically 30.153A/333mv (They are usually out by a few percent)
I figure CTs are such simple devices that even a cheap CT properly calibrated should be pretty accurate.
https://www.aliexpress.com/item/32231707642.html

[TrystanLea]

Dont know what to tell you. Its definitely working for me without those chances

How strange, I was getting all sorts of issues due to an E2END not being anything like the right value. The EEPROM format would then just clear the signature with the overflow..

Might be interesting to check what the value of E2END is on your system? Perhaps we are running different versions of DxCore or something..

I noticed you changed the default lead from 1.5 to 3.2. But as far as I could tell the power factor readings were already pretty much perfect.

The phase calibration only becomes noticeable on loads with large phase differences between voltage and current. The power supply on my heat pump controller board is a good example or connecting up one of these unloaded: https://www.screwfix.com/p/carroll-meynell-3000va-intermittent-isolation-transformer-230v-230v/320hv

Sending commands does not seem to work though I suspect that's just because it's a WIP

It should work, it's working here for me on Chrome.. can you see anything in the serial window? is it loading the config values from the emontx into the input boxes?

I notice there is no way to fine-tune the calibration. Is that planned? or is calibration not an issue with the CTs you use?

Im sure it will be something people will want, though I expect most will use the standard values. Il probably do a custom entry in the dropdown that then provides a input box..

[brandon3055]

On my system Serial.println(E2END); returns 5631. I'm pretty sure that's not correct...

It seems the console does work. Bit it does not let you send +++ to enter config mode.

[brandon3055]

Oh... I know why config works.... EmonTxV4CM does not use emonEProm. It just writes a config struct using the arduino EEPROM lib.
EmonTxV4CM_rfm69n uses emonEProm.

[TrystanLea]

Aha, ok that's useful to know. Are you staying on EmonTxV4CM for compatibility with existing devices?

[TrystanLea]

On my system Serial.println(E2END); returns 5631. I'm pretty sure that's not correct...

Thanks I get the same here.

[brandon3055]

Are you staying on EmonTxV4CM for compatibility with existing devices?

Actually, now that I think about it. It's possible the reason I initially avoided rfm69n was that I couldn't get the config working.
I also use Atmega88s in my RFM2Pis But I don't think they can handle emonBase rfm69n.
Though that's not really an issue. I'm sure I have some 328s floating around.

[TrystanLea]

E2END returns 1023 for the ATmega328

It's defined for the avr128db48 in the file:
packages/DxCore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/avr/include/avr/ioavr128db48.h

#define EEPROM_END (EEPROM_START + EEPROM_SIZE - 1)
#define E2END EEPROM_END

though EEPROM_START and EEPROM_SIZE definitions above it seem to be commented out...

[brandon3055]

Sorry, it took me a while to get back to this.

I have done some testing with the new board and I am still noticing some odd behaviour. But only on channel 12.
With no load, I was randomly seeing currents as high as 300ma on channel 12.

So I did some more testing. Due to the new board no longer pulling the CT pin to the ground when a CT is disconnected. You can remove a CT and the channel will remain active. The result should be the same as having a CT connected with no load. But also no chance of interference. Turns out I still see the random 100-300ma readings even with no CT connected to channel 12. Or any channel for that matter.

It actually seems the interference is somehow coming from the v-sense board because disconnecting that and running on USB only completely stops the random readings.

These are some of my readings.
Vsense connected, no CTs connected (This matches what I see with all CTs connected)
https://ss.brandon3055.com/3b549
Running without Vsense connected (Though I did connect it near the end)
https://ss.brandon3055.com/b9509
And this is with all CTs connected, running on USB power, with a load test halfway though.
It works perfectly except for the fact that it's not using the vsense board.
https://ss.brandon3055.com/5e016

I don't really have time to continue digging into this right now but I thought I would let you know what I found.
Its possible this is an issue with the changes I made to get 12 channels working. And I have not had a chance to
go through the changes you have made. It could also be an issue with my board. The soldering on the AVR128 is far from my best work. though the input pin for CT12 is nowhere near the VSense inputs.

The other thing that is obvious from my readings is every channel has a 15ma offset. Though I think this is easy to explain. My one relatively cheap meter that can read 3.3 volts with three digits of precision shows that my VCC is 3.306v
If my math is correct a VCC of 3.307v would result in a 15ma offset. (With my Ical being 90.495)

[TrystanLea]

Thanks @brandon3055

Does reducing the sample rate perhaps:

ADC0.CTRLC = ADC_PRESC_DIV32_gc;

or

ADC0.CTRLC = ADC_PRESC_DIV64_gc;

make any difference? adusting timing in the EmonLibCM_setADC(12,sample_time); appropriately

do you have one-wire temperature sensing enabled? what happens if you turn that off?

[brandon3055]

Disabling temperature had no noticeable effect.
DIV 32 with temperature enabled had no noticeable effect.
DIV 32 with temperature disabled had no noticeable effect.
DIV 64 with temperature enabled seems to have resolved the issue.