Oh! I didn’t realize there were so many devices, I had had thought there were just 2 setups, one fully functional and one where either or both the Pi and/or RFM2Pi were suspect.
This raises several questions like where is the data coming from? do you have multiple networks? ie on different groups or are all these emonBases listening for the same device(s) eg emonTx or emonTH.
What area do they cover? are they all comfortably within range of the data source(s)?
The no response from the avrdude test is strange and I will think on that, but as for the intermittent updates, I think you should take the best of the bunch and try to establish if theres anything wrong with the source(s), perhaps start with one transmiting device in close proximity to the emonbase you choose to tackle first and determine how often the packets are arriving (or not) and work from there.
Once you have a known good data source you can then gauge the other emonBases performance and finally introduce other transmitters. Trying to debug them all at once will only cause confusion IMO.
If you wanted to send the suspected faulty units back to us, we would be happy to try and resurrect. Please include note, our office address can be found via the contact page on the web shop
There are only two Pis and two RFM2Pis. So two monitoring systems. One is
for home, one is for my office. What I have done is create all the possible
hardware configurations with those two systems to see if it flushed out the
problem.
Will do as you suggest with data sources. Currently there is only one which
is located two rooms away. It is a custom sketch so possible I have done
something wrong.
Think I’ve cracked it. The first node was down the side of the dryer i.e., a big metal screen, which presumably does a good job of deflecting RF. I’ve repositioned it and now getting inputs every few seconds.
Shortlived victory. Got back to the office and plugged in the ‘dodgy’ Pi, with the ‘dodgy’ RFM12Pi. This was working at home, but now I get no inputs.
The avrdude command still returns nothing.
Minicom doesn’t seem to let me do anything.
RFM12Pi LED is not flashing.
The node is an emontx v3.2, onto which I have uploaded the “emonTcV3_2_DiscreteSampling” sketch. The LED is flashing. The serial monitor indicated the sketch was running.
Node groups and frequency match (210, 868). Baud rate is 9600.
Since I got the RFM12Pi working at home, it could be that the node has a problem.
Any thoughts? The inability to communicate using the arvdude command still bothers me.
Avrdude won’t work because the query isn’t reaching the RFM2Pi for it to respond to. That’s also why you get no response when using minicom.
The firmware and default settings are for 433MHz and group 210, without the ability to write to the RFM2Pi enonHub cannot change the frequency to 868MHz.
Since the settings are held in an eeprom you should be able to set the freq and group on the dodgy RFM2Pi using the good Pi and then move it to the dodgy Pi, it should then be able to receive ok if the settings are right as the Rx line is working.
I was busy on-site or driving most of yesterday, but I did see your posts and so I posted very briefly last night to point out the serial Tx issue with the first Pi.
I think debuggiing may have been confused a little by sporadic data from the nodes and that is most likely a different issue. Knowing what sketches you are running and seeing an emonhub.log (when quiet = false set in emonhub.conf using the good Pi) will probably shed more light on why the data is sporadic, debugging that will be harder if you do not have a very good RF signal so I would recommend ensuring you have the unit’s in close proximity to each other while you debug if possible and then relocate (and deal with any further RF type issues) once you have regular and reliable data,
As for the “dodgy” Pi, you could try another image with “no changes”, whilst I’m sure the changes you made shouldn’t effect the serial port it’s not impossible to imaging something gets altered accidentally or as result of something else. The probability is it is not a software thing as the Rx side is ok, but it maybe worth a try.
As it stands my best guess is that you have hit the “update emonbase” button and it has overwritten your rfm12 FW with rfm69 FW and stopped it dead, then during the debugging stages is it possible you have plugged the RFM2Pi on incorrectly at some point which has damaged the Pi’s Serial Tx GPIO? This is the only way I can see the FW becoming incorrect as the Tx line must have been working at that time to upload the wrong FW.
So I thought I’d try wiggling the RFM12Pi board to see if any of the connections were dodgy. It now works! The avrdude command still doesn’t do anything, but minicom gives this;
So I’m thinking the Tx female connector on the RFM12Pi is probably dodgy?
Sorry I went quiet on this, I have been a bit swamped of late.
The “no response from avrdude test” is common to both test setup 3 and 4, both using the same Pi but different RFM2Pi’s, that’s why I suspect the Pi, but if the “v” command works from minicom on that same “dodgy” Pi then perhaps it is at at software level, I recall some timing issues with the “rpi-avrdude” utility some time ago, although I thought that was resolved perhaps that particular Pi is at one extreme of the “correct timing”.
The important thing is that you can update the firmware (shouldn’t need doing again though) on the good Pi and the “dodgy” pi is ok for usual use.
I notice your minicom log shows an abundance of zero’s, we are now aware that if there are long runs of zero’s without any values to provide “1” bits for the stream to be kept synchronized then that will lead to a checksum fail and you will loose many packets to that. I know this is only testing and in real use there will be values so don’t be too concerned about packet loss while there is no data.
However having said that, I can tell this is an early FW in the emonTx as the temperature sensors are not returning a “301” value to say they are out of service (unless of course you have all 6 connected and keep you house at a very constant 0°C), the “301” error codes were introduced to reduce the chance of “bitslip” as I just described, so I would consider updating the emonTx FW’s if you are loosing packets (actually that’s a lie, I would almost definitely update it anyway to be sure I wasn’t loosing packets that way).
