This allows use of the RF12 driver to receive data from sources that do not implement the RF12 protocol. Includes a sample for the EMT7110 energy meter.
see issue #432
yeah, not a great idea to do it all at once, I know…
intermittent eeprom corruption when updating quiet,, hex and maybe collect flags. Boolean in structures?
- see issue #425 on jeelabs.net - also some comment tweaks and other cleanups
@jcw to review.
Moving the save to eeprom to be after the send ACK has lost the buffer so nothing left to write to eeprom...
Displays (L-C-H) where L is lowest level received where C is current packet value finally H is highest level received
Two questions: 1). With maximum lengths of config.msg there isn't a NUL on the end of the string. 2). With less than maximum lengths the CRC calculation omits NUL's, perhaps they don't influence the CRC calculation.
Possibly rf12_xfer is replaces rf12_control
The dB display always returns a value of 2. Flash commands not tested. ...,<nnn> a & s not tested.
I think I'm stuck in rf12.cpp line 814. Since I commented out 607-678 everything works except there is no transmission happening. I don't know how to deal with header files with optional parameters - 1600 the default frequency.
Reuse of offset 2 in the eeprom causes problems when the new rf12.cpp is used with 'old style' eeprom contents
Still no joy, maybe it relies on the bus speed increases that we haven't moved from RFMODS.
Value 255 changes the frequency direction of change.
I would like to get the dB display of the received signal into mainline code. I have COPIED @tht's code in but I don't yet understand if the output is sensible.
Copy in the dB display from Thomas Mueller. http://forum.jeelabs.net/node/1559