Hi Robert,
First, I want to say great work - specifically on joining all the dots on the radio formats. It’s great to be able to use RFM69 in it’s native mode which gives so many benefits. It was also fantastic to read all the information on how RF12 can be made to use the same RFM69 packet format, allowing us to have a mixed network of old & new with simple firmware update.
The great thing was you’ve provided a way to update all the OEM devices including GLCD to be able to continue to function. It really is an amazing effort, never mind the benefits of CM.
The little atmel chip can breath a nice sigh of relief now sending and receiving is offloaded to the RFM69… although I’m sure it is now sweating more doing CM instead!
However, I am confused as to why you moved away from the established command format , (reverse polish) to the extent you lock it out when you see it on the input stream.
I was looking at the code making sure I could still transmit data, and instead of being able to send ‘bytes’ as previously, it seems to send alphanumeric strings which is likely not what most applications need, nor is it compatible with the previous raspberry-atmel interface, making this not ‘plug and play’ with current emonhub send functionality.
Previously, we would send by sending decimal numbers between 0-255 , comma-separated, followed by ,s eg. 12,122,244,33,7,s would send a 4 byte packet to node 7.
I was looking at submitting a patch to put this functionality back so EMONGLCD (and other sending tools) could run without changes to emonhub or how they send, but I thought I’d ask first as it seems to have deliberately broken this backward compatibility and not sure the rationale why.
I use emonhub as my RF hub for sending and receiving to lots of JeeNodes, so this functionally is very useful (it saves me have yet another node connected for TX to the RF network when the emonpi is perfect for it).
Looking forward to understanding your thinking on this, and again, GREAT work… your research and fantastic explanation has helped me start to figure out how to get STM32 talking to my RF network in a compatible way.
Alan