Before I purchase the hardware mentioned in the subject, I thought I'd solicit the wisdom of the forum to see if what I'd like to do is even possible. Over on AdaFruit, the documention of their RFM69HCW breakout board (which I believe uses the same underlying SX1231 transceiver chip) says it supports "Raw" mode, but they don't give any details or examples. Also if one reads the data sheet for the RFM69HCW, it discusses "Continuous Mode" in which "data from the demodulator is directly accessed by the uC on the bidirectional DIO2/DATA pin". This seems like what I may want/need to do in my application (see my background information below).
Some questions up front:
HARDWARE Questions:
1) Can the RFM69HCW successfully receive, and decode, a 433mhz, ASK modulated, Manchester encoded, signal, and return the decoded data packet?
2) Is the RFM69HCW DIO2/DATA pin connected to a digital pin on the Moteino M0, so that it can be directly read? I looked at the Moteino M0 schematic drawing, and it doesn't look like it does.
SOFTWARE/LIBRARY Questions regarding the LowPowerLab RFM69 Library:
3) If I know the signal is Manchester encoded, and I know the number of header bits (eleven '1's), the sync bit ('0'), and the data bytes (5 data bytes followed by 1 checksum byte), is there a way to specify this via library calls, so that the transceiver itself decodes the data and returns the decoded data packet?
4) If (3) is not possible, can I use/put the transceiver in "raw" mode, where I sample the raw analog signal (as I do on the Arduino), and have the Moteino M0 processor do the decoding?
For those interested, a good description of Manchester encoding (in the context of weather station sensors) is here (https://github.com/robwlakes/ArduinoWeatherOS/blob/master/README.md (https://github.com/robwlakes/ArduinoWeatherOS/blob/master/README.md)).
Background: I have some Ambient Weather Temperature/Humidity sensors which transmit on 433mhz, using ASK modulation (I think) and Manchester encoding. I currently have a cheap 433mhz receiver interfaced to an Arduino UNO R3, and have a sketch which successfully receives, decodes, processes, and prints the data (to the IDE Serial Monitor) from multiple such sensors. The sketch directly samples the waveform from the receiver (Receiver Data pin is connected to Digital Pin 8 on the Arduino), decodes the Manchester bit waveforms, and moves the bits into a byte buffer as appropriate. The Manchester encoding for these sensors have bit waveform has a total period of ~960us (that is the waveform time for a single bit).
The sensors have 3 DIP switches which allow 1 of 8 "channels" (IDs) to be specified. The sensors transmit new data at a nominal period of 60 seconds. Depending on the sensor's channel setting, the period is increased/decreased some number of seconds from the nominal value of 60. This ensures that even if two sensors are transmitting over-top of each other at some point in time, resulting in a garbled/failed reception for one or both sensors, several cycles later the transmissions will have shifted in time relative to each other, and a valid reception will occur. The transmitted Manchester-encoded data has a sequence of initial 1's (allowing the AGC to stabilize). To sync with the data packet, a valid header must be identified, which is defined as 11 sequential '1' bits, followed by a '0' sync bit. After the sync bit has been received, there are 5 bytes of data, followed by a 1 byte checksum. The transmittion takes about 58msec from the start of the 11 bit header to the end of the checksum byte. In addition, the sensors transmit the same complete data packet 3 times in a row, seperated by ~2-4 ms. For the Arduino's speed, things seem to be right on the "edge", meaning I often only successfully receive one of the 3 repeated transmissions, and sometimes miss all 3 (for a given 60sec transmission cycle). This becomes more frequent the more sensors I'm trying to receive (not surprisingly). My sketch code has extensive #defines which allow me to add/remove various debugging code and prints to the Serial Monitor. I also have a #define which allows me to switch between calls to digitalRead() and direct port manipulation. And a #define which allows me to disable checking of the checksum. The Serial Monitor baud rate is set to 500000, which seems to be the limits of reliable printing on my system. Even with eliminating all except about 4 characters of output, disabling the checksum check, and using direct port manipulation instead of digitalRead(), I still, more often than not, "miss" 2 out of 3 of the repeated packets.
So I'm thinking a faster processor(Moteino M0 clock speed is about 4X the Arduino Uno's), and/or offloading the Manchester decoding to another processor (or the transceiver), might allow me to recieve a greater percentage of the packets, especially when I have 7 sensors operating, and give more time for processing the data after it's been sucessfully decoded. Hence the questions at the top.
Thanks,
Doug
I believe all these answers can be found with more accuracy in the sx1231h datasheet (https://www.mouser.com/datasheet/2/761/sx1231h-1277666.pdf).
The RFM69 Library by LowPowerLab does not enable encoding and is by default in FSK mode with optional encryption. You can write to registers directly using the library and set the transceiver in whatever supported mode. So yes you could enable encoding and set the chip to custom settings but that departs from the library's defaults which are most commonly used and recommended.
Are you stuck using those ASK transmitters? 960us per bit is a very slow bitstream. I would recommend looking at something faster. Or just go straight to FSK and defaults and use some other sensors if you can.
Thanks Felix. In answering your last question. I'm kind of stuck with my existing 7 sensor/transmitter modules. They interface to a companion Ambient Weather display module, and that is working fine. I'm trying to independently capture their transmissions so I can log/plot the data over time.
After posting my original post last night, this morning, with the benefit of additional sleep, I dug into the documentation a bit more. Some partial answers to my posted questions are as follows:
- While the RFM69HCW (SX1231) supports Manchester encoding (see section 5.5.8.1 of the SX1231H datasheet: https://www.mouser.com/datasheet/2/761/sx1231h-1277666.pdf (https://www.mouser.com/datasheet/2/761/sx1231h-1277666.pdf)), it evidently will not work with these Ambient Weather sensor/transmitter modules. The key is how the RFM69HCW (SX1231) implements Manchester decoding vs how the Ambient Weather sensor/transmitters implement it. According to section 5.5.8.1
QuoteManchester encoding and decoding is only applied to the payload and CRC checksum while preamble and Sync word are
kept NRZ.
The Ambient Weather sensor/transmitters, however, apply Manchester encoding to the entire message, including the preamble and sync, before the payload. - The SX1231 chip has 5 GPIO bits, DIO0 to DIO5, and all of these are brought out to edge pads on the RFM69HCW module, with the same signal names. See section 1.2 in both the SX1231H data sheet (link above) and the RFM69HCW datasheet: https://www.hoperf.com/data/upload/portal/20190307/RFM69HCW-V1.1.pdf (https://www.hoperf.com/data/upload/portal/20190307/RFM69HCW-V1.1.pdf)
When the SX1231 is operated in Continuous Mode, each raw bit to be transmitted or received is accessed at the DIO2/DATA pin, as described in Sections 5.1.2 and 5.4.1.
However when the RFM69HCW module is soldered to the backside of the Moteino M0 board, only DIO0 is soldered to the Moteino M0 board. I think I would have to solder a jumper wire between the DIO2 pad on the RFM69HCW module, and one of the unused/undedicated Moteino M0 digital input pins. Any reason this wouldn't work? Having done that, then, per Felix, I would use the Library to directly write to SX1231 registers in order to configure it for Continuous Mode operation, and I would do the Manchester decoding, preamble and sync detection, checksum check, etc. on the Moteino M0 processor.
- Even if the Library supported Manchester encoding (which it does not), the SX1231 implementation of Manchester encoding is not compatible with the implementation on the Ambient Weather sensor/transmitter, as described in (1) above. So using Packet Mode to return the Payload and checksum data is not possible.
- With the installation of a jumper wire and direct configuration of the SX1231 by writing to its registers, as described in (2), then I should be able to process the raw received data signal on the Moteino M0, much as I currently do on the Arduino.
The SX1231 has such flexibility when configuring it for Packet Mode, it's unfortunate that the Manchester encoding portion is not just a bit more configurable.
Despite that, I think I may just give it a try. ;D
Doug