The base image (Oct2017) and the firmware are completely different things. For the EmonPi, the firmware is what runs on the daughter board attached to the Pi inside, which does have an RFM card on it.
The best thing for you to do is to follow the instructions on the Pinned Post (emonSD-24Jul20 release), get a new SD card with a new image and migrate your settings/data. This will also update the firmware on the EmonPi.
Using PIO may be the “official” recommendation and I’m sure there will be users that can assist you with that should you wish to pursue that. But neither Robert or I (we helped you previously) will use PIO and both of us would recommend the Arduino IDE route rather than PIO, especially as you are not a frequent user and have experience with the latter method already. Plus your notes relate to previously using Arduino and may not be relevent to PIO.
If you use Arduino then you only need to focus on and accommodate changes in the actual firmware and IDE rather than also trying to add to that the learning curve of a new IDE eco-system. But the choice is of course yours.
I’m sure Robert will be able to advise on any progress regards a new continuous sampling FW (potentially in the pipeline, unless I missed the release) for the emonpi that would probably suit your application better than a shop emonpi due to you not having an RFM installed. However, again I would KISs to start with and just try the released latest version as per your initial intention until you are comfy with doing the task and know all the libs etc are in place before attempting to change to a significantly different FW that may not be release ready yet.
Dave is using a “homebrew” emonpi build and has previously had to compile and install his own FW due to NOT having a RFM installed. (and probably should have noted that in his post )
Just one point on this Paul, using pio on a pi is extremely easy and saves the problems of uploading to pi, then flashing as it just all works on the Pi. I did it when fiddling with the serially connected EmonTX. This of course is different to the VSCode/PIO route which I agree can be tortuous.
Yes there is progress, yes it is in the pipeline and no, you haven’t missed the release.
And before we go any further, @DaveC needs to be aware that installing platformio screwed up my system, because it moved libraries etc without warning or notice, and it took several hours to put everything back. I know there are people round here that deny it’s possible, but it happened.
The position with the emonPi is that it will never be “continuous monitoring” while we use JeeLib in its RFM12B compatible mode. The problem is the emonPi is just too busy sampling to handle reliably any other data coming in by radio one character at a time, so we must change to using the hardware buffer inside the RFM69CW that’s absent in the RFM12B. And unfortunately, the message format must be different, so there is an incompatibility with the existing. I have two emonPi’s and an emonBase, two emonTx’s and one emonTH all running with the new format, but it needs Trystan, who’s started work on emonHub to allow it to configure and calibrate the emonPi front end, to complete that work before it can be released.
From that, if Dave wants a non-radio emonPiCM (as I’m calling it for now), it’s really only a case of taking the example sketch from the emonLibCM distribution zip file and stripping it down to 2 c.t. inputs, and I think a pin change or two; and using that in place of the monitoring bits of the original front-end sketch. I actually have that software, thinking it might be an intermediate release, but never did release it.
Thank you for the interesting and concise responses to my query, and you have definitely turned me off using PlatformIO. The only reason I considered using it was what I thought was basically a recommendation in your online guide under the section titled Firmware Modification.
I am still not clear on what I need to do, as without the RFM69CW I thought I was unable to use the standard image and needed to remove RF_Status flag to false and do my own compilation. Anyhow, I will chew over your responses over the next day or so and so how I go.
Thanks and Regards,
You do, Brian was unaware of your bespoke HW when he replied. Even if you do use the emonSD you will still need to modify the FW.
You can use the std images but you just need to be careful not to over write your FW during an update, things have changed since you built your emonPi, the global update can now be run without updating the FW (or IIRC
include updating a custom FW hex) but the FW for your device will need manually editing and compiling. Regardless of IDE used and where.
I’ll look later and try to find it. I can’t check it again because all my hardware is committed. It takes a totally different set of commands, like the 3-phase sketch, to calibrate the front end, and (I think) it will screw up on the “Reverse Polish” configuration that the stock emonHub sends. I can’t remember now the state it was in when I moved on to solving the radio problem.
Yes, it will respond - badly - to old-style commands sent from emonHub. @DaveC, I’m sending you a PM.
The Jee interfacer is basically the serial interfacer with the ability to dish out Jee type commands, so just change the interfacer type to serial to avoid any Jee based hiccups.
There should have been an emonPi interfacer built on the jee interfacer (rather than compromise the jee compatability of the jee interfacer) any non jee based emonpi interfacer should really be built from the serial interfacer not from the jee interfacer.