Add "quiet mode" to the emonPi "RF" firmware #34
Conversation
Reintroduces the "quiet mode" seen in the rfm2pi firmwares to allow debugging of RF issues. Via serial "1q" sets quiet mode (default) and "0q" removes quiet mode for a more verbose output including bad packets that have failed crc checks. In emonHub it can be set with "quiet = true" or "quiet = false" in the interfacer settings.
|
This is only tested "in theory", since I do not seem to have any bad packets currently within range, so I have only tested this by reversing the "if (rf12_crc == 0)" to "if (rf12_crc != 0)" so that every good packet was classed as bad, the logic, option switching and printing all seems to work ok though. I just haven't seen any true "bad packets" to test with. |
|
So to turn on the verbose output, set quiet = false in the config for emonhub. Does the emonPi need to be rebooted or emonhub service need to be restarted (i.e.,
|
|
Hi Jon There should never really be any need to restart emonhub unless something goes wrong or to load recently updated source code, all the runtimesettings are picked up instantly in normal running and any change to init_settings will result in the interfacer (or reporter) being deleted and recreated with the new settings (in the case of original emonhub, any buffered data is also transferred to the replacement). |
|
Nice, thanks a lot for the PR. Just tested. I was able to disable quite more via minicom, this worked great. However, I was not able to see any bad packets like I'm used to seeing with the RFM69Pi with the ??? packets. Maybe I just don't any bad packets here! I'll do a more detailed test and compare with RFM69Pi in the lab tomorrow. |
|
Paul/Glyn - I tried the PR. I think I am missing the obvious! If quiet = false, should I see the rfm2pi verbose output in the emonhub.log file? or somewhere else? |
|
Yeah I was surprised to see no bad packets too! But I did check my live rfm2pi and even tried my JeeLink, neither of those reported any bad packets either, both were loaded with an rfm2pi sketch but my JeeLib is up to date and I have not had any need to check for bad packets in quite sometime so I cannot say if somethings amiss or not. I have just rechecked my live rfm2pi tonight and still no bad packets in sight. As I posted above I have tested the functionality and if any packets are received and reach this point in the code, if the crc is "0" it will print as usual and if it's not "0" it will go through the additional "quiet mode switch" code. I have tested this and if any traffic reaches this point with a crc of anything other than "0" it will print or not, as expected depending on if "quite mode" is true or false. If no "bad packets" (non-zero crc) are getting to that point then obviously they won't be any shown. I think the best way to test it is in a known noisey environment side by side with a rfm2pi/rfm69pi. Perhaps even load a test sketch to a emonT? that just sends a packet consisting of a dozen ints all set to zero, that will most likely cause some bitslip and they will fail the crc checks, but with a valid group id. @JonMurphy I don't think you are missing anything, either there is a fault or you have no bad packets being received, in this instance "more verbose" just means any discarded packets (if there are any) are passed though to emonhub with a "?" prefix so emonhub knows to discard them rather than being discarded silently by the emonPi firmware. Any other time than while trying to test this code, no bad packets is a good thing. This is just a tool that can be turned on if users are missing packets, to see if they are getting corrupted etc. It is with this function on the rfm2pi's that we found the bitslip on emonTx's caused by the 6 zero temp values and the extra bit being added when the rfm was not woken in time to settle before a send in the emonTH etc Hopefully @glynhudson tests will confirm things, if not I will set up some tests or recompile with a much older JeeLib. I have just noticed some indentation errors had crept in, probably different tab sizes on different machines, I have just tidied that up but I do not think it will effect anything other than the code's readability. |
|
Been merged as V2.8.1 firmware, this has been released as an emonPi FW update. https://github.com/openenergymonitor/emonpi/releases/tag/2.8.1 |
|
@glynhudson did you manage to confirm non-quiet mode works as expected? |
|
Yes, I believe so. Although I have not done any further testing.
…On 7 December 2016 at 23:18, Paul ***@***.***> wrote:
@glynhudson <https://github.com/glynhudson> did you manage to confirm
non-quiet mode works as expected?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAuUPGSOrd1j-ubOHuHU8hKdN7jiiP9_ks5rFz7HgaJpZM4K3S0t>
.
--
Glyn Hudson
http://megni.co.uk
http://adventuresplusnorthwales.blogspot.com
|
Reintroduces the "quiet mode" seen in the rfm2pi firmwares to allow
debugging of RF issues.
Via serial "1q" sets quiet mode (default) and "0q" removes quiet mode
for a more verbose output including bad packets that have failed crc
checks. In emonHub it can be set with "quiet = true" or "quiet = false"
in the interfacer settings.