I'm building a project based on ATTiny85 low power sensors that transmit to a base station using cheap ASK/OOK 433.9 Mhz modules. I have two main questions for the hive mind:
(1) does anyone know/recommend a good ASK receiver that produces a usable RSSI signal?
(2) is there a recommended transmit/receive library that is more suitable for the ATTiny85 than RadioHead?
Regarding (1), I am using an OmShine RX03 at the moment. This is a good superhet receiver with a crystal LO and ceramic IF filter. It's based on a PT4301-X superhet receiver chip. This chip does provide an AGC gain control output that lets you get an idea of RSSI, but I have to tack a line onto the chip to get the signal out and the module is not designed to give the RSSI output. The gain signal is not ideal anyway, since the state of the internal attenuators can't be sensed. It's a bit of a hack and I would prefer to use a module that produces a documented RSSI output.
Regarding (2), I am successfully using a VirtualWire implementation. Despite the claims of RH_ASK, I find that the RadioHead implementation simply won't fit on an ATTiny85 with the other parts of my project. It also demands to use pins that I don't have for functions I don't need or want. I found someone who had written a bit-bash version of the VirtualWire transmitter that is working well for me and I can receive transmissions using a VirtualWire receiver, but for some reason not with a RadioHead RH_ASK receiver.
I've been looking at alternate TX/RX libraries and some features I would want that RH/VW doesn't have are forward error correction and compact implementations. On my list of things to try out is Andreas Rohner's RFTransmitter library. Are there other options I should be considering?
gardner:
I'm building a project based on ATTiny85 low power sensors that transmit to a base station using cheap
(1) does anyone know/recommend a good ASK receiver that produces a usable RSSI signal?
If you keep the details of you project secret from the forum, how can they possibly advise on what is a 'usable RSSI signal' ?
The project requirement is simply to have the fixed base-station receiver have a reading of signal quality from the senders. This will be desirable when initially placing senders and optimizing antenna orientation and placement, as well as for early warning about link budget issues that could arise due to vegetation or weather.
In the case of what I can get from the OnShine RX03 PT4301 chip, the RSSI is an analogue voltage somewhere in the 0.2Vcc to 0.5Vcc with the higher voltage representing a stronger signal. It is not a documented feature of the module, however. I gathered that the low budget receivers that have this feature use an analogue voltage to express receive signal strength, but I could be wrong.
Unlike the senders, which are battery powered ATTiny85s, the receiver could require more sophisticated software or interface to obtain the RSSI. I think I'm married to 433.9Mhz OOK though, so some of the packet radio and wifi solutions would be a poor fit.
Hi,
The problem you will have with any RSSI you obtain by monitoring the Rx AGC is calibration and linearity, or logiarity in this case.
To get a basic "signal strength" level you would need to measure the AGC until you loose Rx/demod while decreasing Tx level or increasing range.
Use this as your minimum signal strength and then increase signal until you get AGC saturation.
Use these two points as the lower and upper readings.
TomGeorge:
To get a basic "signal strength" level you would need to measure the AGC until you loose Rx/demod while decreasing Tx level or increasing range. Use this as your minimum signal strength and then increase signal until you get AGC saturation.
Use these two points as the lower and upper readings.
Well, that depends on how the RSSI is specified by the hypothetical module that outputs a reading. In the case of the module I am currently using, this is exactly what I am doing. When I put the sender and receiver in the same room with decent antennas, I get some upper reading. Then if I carry the receiver down the road, at the point where the signal becomes almost unusable -- a step or so back from the point where it disappears, then I get some other number. This is approximately 0.5Vcc at the strongest and 0.2Vcc at the weakest usable signal.
This is OK, but it is not ideal. The AGC control voltage that I am reading does not change when the internal attenuators are switched, so somewhere in the middle, there's an overlap between two signal levels that are about 10db apart. Since this is on the super-strong end of the receive signal levels, and I am interested in the signal strength at the weak end, maybe that's okay. It also bothers me that the module does not simply have an RSSI output of some kind, and if I could find a good module that had one, I would use it instead.
Paul_KD7HB:
At 434mHz and carrying the device, you are now part of the antenna or a reflector. Not a good test!
Yes and no. In terms of realistic overall link budget or real world antenna behaviour or range, it isn't. But as a measure of the observed signal strength parameter (AGC gain signal) vs link error rate, I think it is perfectly valid.
gardner:
Unlike the senders, which are battery powered ATTiny85s, the receiver could require more sophisticated software or interface to obtain the RSSI. I think I'm married to 433.9Mhz OOK though, so some of the packet radio and wifi solutions would be a poor fit.
An Arduino PRo Mini and Si4432 radio module.
Si4432, direct register read of current RSSI, adjustable frequency.
srnet:
Si4432, direct register read of current RSSI, adjustable frequency.
Thank you. That looks like a good bet. The base station will be an ATMega1280p I think, but yeah. The RH driver does OOK/ASK, presumably in RH_ASK format. Thanks for the pointer.
Okay, to answer my own question, I ran into these modules that do plain old OOK but have an RSSI output as a documented feature. They are orderable on Mouser
The RH support for the Si4432 does not, as it happens, work with RH_ASK since the Si4432 ASK modulation scheme is peculiar to that part. It makes it impossible to use it to recieve an arbitrary data encoding scheme sent by something other than an Si4432.
