Hello!
I almost finished building an energy monitor setup using an emonTx v4 and an RFM2Pi.
I still need to work out the correct burden resistors for my CTs and do some calibration. But other than that the Tx v4 seems to be working fine and can communicate with emoncms via a direct USB connection.
The issue I am having atm is no matter what I do I cant seem to get the RFM2Pi to receive data from the Tx. The RFM2Pi seems to be working. I can connect to it and access its config settings via serial but just does not seem to receive any valid packets.
At this point I’m suspending an issue with the RFM2Pi because if I turn off quiet mode I see that it is receiving a continuous stream on invalid packets at a rate of about one every second or two. That continues even if i turn off the Tx and i can’t think of anything else in my area that would be transmitting on 433MHz.
So far I have tried both of the pre-compiled binaries for RFM69 and i also tried manually compiling and uploading via the Arduino ide.
I have tried the supplied optiboot bootloader as well as the one that ships with the DIY Avr board package.
Finally, I also tried building a second RFM2Pi using an atmega88 which is pin compatible with the 328.
No matter what I do I get the same behaviour. So at this point, I’m suspecting it’s one of two things. Ether aliexpress sent me junk RFM69 modules.
Or the stream of invalid packets is completely normal and the Tx4 just isn’t sending data.
It’s also possible I have completely overlooked something obvious.
I’m just running low on ideas so I figured it couldn’t hurt to ask for help.
Ok so it seems it was option 2. My emonTx v4 simply wasn’t sending any data.
I was using the EmonTxV4CM_rfm69n firmware, I switched to the regular EmonTxV4CM firmware and now it seems to be working.
Now I just need to figure out why the emontx v4 goes haywire when I try to manually compile its firmware. Everything works fine when I use the pre-compiled binaries but if I compile it myself it acts as if the system clock is misconfigured or something. Instead of sending a data packet to serial every 10 seconds, it spams them at an inconsistent rate of around 1-2 per second and the data is garbage.
If I turn on “showCurrents” many of the current readings are nan.
I am using the avrdb branches of EmonLibCM, emonEProm and rfm69nTxLib as instructed in the firmware instructions. The only unknown was OneWire which isn’t included in DxCore so I am using
https://github.com/SpenceKonde/OneWire
It seems unlikely the OneWire library would cause this. But then I really don’t know what could cause this… The only thing I can think of is maybe some step or setting was accidentally left out of the firmware instructions. I also tried compiling on both windows and linux but that didn’t change anything.
Have you read the release Topic for the emonPiCM? You need to, because that explains the differences between the ‘classic’ and ‘native’ radio packet formats.
Ok. Based on a quick glance at the change log I assumed the rfm69n variant was just removing unneeded bloat but was functionally the same. I see now that assumption was incorrect.
Thank you for pointing that out.
Any thoughts on why my self compiled tx v4 firmware might be acting up?
All I can say is what I published on this forum worked for me. I don’t know, and haven’t checked, what has been put on Github.
I’m afraid I’m having to concentrate on getting emonLibCM working properly on the -DB Atmel variant, so much as I’d like to help, I can’t afford the time to work on a private and parallel endeavour.
That’s fair enough. I appreciate the help you have already given me.
Would it be worth opening an issue on github? I’m sure this has to be something simple. I just need to figure out how the binaries on github were compiled so I can figure out what I’m doing wrong…
If your issue is with emonLibCM, you should download my released version from the forum, along with the examples, and start from there.
I have the absolute minimum engagement with Github, I don’t understand it, and every time I go near, it ends up as a big waste of my time.
If I’m not mistaken you have not released the avrdb version yet.
I think I just figured out what the problem is. I started looking into EmonLibCM and I noticed in the documentation it specified it supports up to 5 CTs. So having run out of other ideas I tried nuking the 6th CT channel and BINGO! it is now working.
The precompiled firmware works fine with all 6 CT channels so I guess someone must have updated EmonLibCM to support 6 channels. But it seems the update was never pushed to github.
Edit:
And there it is…
A full day of troubleshooting boils down to a single character fix xD
I think the moral of the story is, read the documentation.
The '328P has 6 ADC channels - one is used for voltage and that leaves 5 available for current, hence the limit of 5.
I’m looking to support 3 voltage and 12 current channels with the -DB version of emonLibCM.
I think you’ve found another reason to ignore Github.
I guess also just don’t assume the published code actually works xD
I think GitHub is an incredibly useful tool, especially when paired with a good intuitive client like GitKraken. I use it for a lot of different projects. But it really only works well if all collaborators are actively using it and are able to communicate and stay on the same page so they don’t end up tripping over each other.
As long as all of your development is done inside a git repository you can always see every single change you have made, and you can ensure they are all correctly documented and pushed to github. It also makes it incredibly easy to track down exactly what changes were made and by who in the event something breaks.
Trying to manage a project outside of git only to sometimes upload changes to github could easily open the door for important changes to get lost.
p.s. sorry for the slight rant. It’s just as someone who uses git every day I find it hard to imagine trying to maintain a project like this without it. Or at least some form of version control.