Create a multi purpose RF device

Issue #10 closed
John Sirach
created an issue

A multiple purpose RF device can be seen as an RF transceiver being capable of receiving general purpose RF signals and send them out.

It would be nice if protocol specific implementations are possible.

Comments (5)

  1. Ariel Podżorski

    I've been thinking of creating a new issue but since there is this one, I'd like to share my thoughts about multi purpose RF device.

    There's already an i2c RF controller but it'd be better if the device run on Arduino (nano for instance) plugged in via USB. It's simpler to connect and much simpler to program than AtTiny on i2c bus...

    It'd also be great if there was one device controlling both 2.4 GHz mysensors and 433mhz stuff but I'm also aware of limited memory on Arduinos.

    And, speaking about simplicity, why can't we just make it this way - connect 433mhz transmitter and receiver to i2c and use wiringpi library to connect to it? Is microprocessor necessary?

  2. John Sirach reporter

    The current i2c RF controller on an ATtiny was a personal project even before PiDome existed and we did not want to completely eat up a whole atmega328 chip for only some simple RF. That would be overkill, We also wanted to control some old RF devices we had laying around, next to this we wanted to take a look how small we could make it and control it over an i2c line longer then 16 meter.

    Then came PiDome, and because it's i2c and we support i2c created a common i2c driver able to read and write simple i2c data. And even use it as a extremely long bus for led control (http://pidome.wordpress.com/manual-howtos/pidome-hardware/i%C2%B2c-bus-extender-for-the-raspberry-pi/ combined with http://pidome.wordpress.com/manual-howtos/pidome-hardware/i2c-lts-lc-adafruit-neopixel-digital-led-strip-controller/).

    When I say Arduino i meant the Arduino UNO prototype board in the next part:

    We are aware that for example an Arduino prototype board is much simpler, the only thing with RF is that almost every device is protocol specific, you should then think of timings between blocks of data send, and lengths of these blocks themselfs. An Arduino can just put that much in memory (as wel ram and progmem). To support both 433 and 2.4Ghz would not be that specific to memory, but more due to chip capabilities. Think of timers, interrupts etc.....

    You could connect a single RF transmitter and a single RF receiver to the raspberry pi digital pins, i2c would not be possible due to the fact that the i2c is a protocol, so yeah, this is microprocessor depending.

    We also started thinking to make thing easier and more usable. This is why there is a enhancement for multi-purpose devices. There also is a possibility that this specific device creates a non protocol specific implementation so users can create these them self with PiDome compatibility. There is a RFXCom device which is capable in 433 and 2.4Ghz transceiving. Support for this device is also on it's way.

    I hope to have explained things a little bit :).

  3. John Sirach reporter

    of course this will be a plausible setup, for this I have to pass any good answers to our hardware guy.

    Well, the i2c on the raspberry pi is setup in such a way that the raspberry pi is the only side of the wire that can initiate data transfer. Meaning it can send data to i2c slaves, and request data from i2c slaves. Or i have missed something lately, but it is not possible the other way around. This means the pi has continuously ask a slave it is for example has received data (in this case RF). If the pi would ask for data at the moment an rf signal is being received it will not get all the RF data, and vice verse.

    Despite the above, timing won't be an issue because with i2c there always is a processor involved to interpret the data. I2C works at a fixed speed. Changing speeds while communicating is not according i2c specs (as far as i know) and would thereby confuse the clock pulses used.

  4. Log in to comment