Hi All,
I have uploaded a new library for interfacing with HopeRF RF22, RFM22 and compatible radio transceivers.
It is very flexible and can be used in a wide range of applications.
It has been extensively tested and its rock solid and very fast.
This library provides functions for sending and receiving messages of up to 255 octets on any frequency supported by the RF22, in a range of predefined data rates and frequency deviations. Frequency can be set with 312Hz precision to any frequency from 240.0MHz to 960.0MHz.
Up to 2 RF22 modules can be connected to an Arduino, permitting the construction of translators and frequency changers, etc.
This library provides classes for
RF22: unaddressed, unreliable messages
RF22Datagram: addressed, unreliable messages
RF22ReliableDatagram: addressed, reliable, retransmitted, acknowledged messages.
The following modulation types are supported with a range of modem configurations for common data rates and frequency deviations:
GFSK Gaussian Frequency Shift Keying
FSK Frequency Shift Keying
OOK On-Off Keying
Support for other RF22 features such as on-chip temperature measurement, analog-digital converter, transmitter power control etc is also provided.
Example client and server programs are provided.
I've tested it a little bit and it works, great work!!
Is the structure library able to use a point-multipoint scenario? I think I've to use reliable datagram version. I'm planning to have more clients and one server. I'll play meanwhile a little bit
Thank's a lot!!!
mikem:
Im thinking about making a network mesh router class with this, al-la XBee. Any interest?
Cheers.
If you could give me a little bit more details I could...
At the moment if I bring work 3 rfm22 is a great goal for me, but with this library it's most done
One of the nice things about the zigbee/xbee radios is that you can set up a mesh network of them and they will arrange to route messages from hop to hop across the network to deliver messages between radios that cant directly hear each other. They are self healing networks that discover the best route between nodes and if intermediate nodes disappear or go off the air, a new route will be discovered.
Thats pretty cute but more than most people need. Still it sounds like an ionteresting challenge.
This is really interesting! I don't think I need it for now, but btw its a nice feature. In real I've no idea where to put these radios also could be possible some are not in range from the server. In this case that would be a solution.
A kind of repeating system. The modules should act as bridge if the packet is not for himself... sounds really cool!
Im making good progress with this. Now have reliable multi-hop message delivery with hardwired routing.
Biggest problem at this stage is lack of RAM in the Arduino. Running out of room for buffers etc.
New version 1.2 has now been uploaded with 2 new classes:
RF22Router: multi hop delivery from source node to destination node via 0 or more intermediate nodes
RF22Mesh: multi hop delivery with automatic route discovery and rediscovery.
These allow support of some of the features of ZigBee and XBee,
(such as mesh routing and automatic route discovery),
but with a much less complicated system and less expensive radios.
Hi Mike!
Are you using frec hopping or only a conventional frec at the library?
Other thing is, how do you do when you ask at mesh for other node to send his beacon and two nodes can send the beacon, how them know that one must Tx before other?, have some order for this? the node Id for example?
At router's table, it use RSSI as variable to decide how will be the next node to send the packet?
I will write an encription library for the data payload
Have you all the network operation theory writed in some document?
The only thing that i can't understand about MESH is if each node repeats each datagram, how this datagram first reach the destination node after jump several times, and how the destination NODE respond to this datagram. I think that in both cases they will not use the same node. I think that the route have different direction.
I mean, if the server wants to send a command to the last node in the network, at the firts node that repeat the datagram it will be send back to the same node that generate this datagram, how the node send to others nodes and not go back to the server?
Actually another question: From what I can make out of the RFM22 documentation you need to control the TX_ANT and RX_ANT pins to switch the antenna to the right pins on the chip depending on if transmitting or receiving. There seems to be no mention of this in the code or docs AFAICT - I guess this is because the package isn't assuming a particular module, just the RF22 chip.
However the RFM22 module is probably rather dominant in the RF22 market, it would be good to support it... Or have I missed something here?
Ah, I'm wondering if this is a difference between the DIP and SMT versions of the RFM22. The SMT version I have definitely have an antenna switch chip (6 pin near ANT) that must be driven correctly. However I suspect all the RFM22 modules have this as the chips RX side can't survive the full output power from the TX side (17dBm) without a switch according to the documentation. By contrast the lower powered RFM23 doesn't have one.
If the pins are left floating its unlikely you'd get any appreciable power off the device (limiting the range greatly) - there's also a risk of generating harmonics that splatter over other bands, which is not a good thing. There is also the risk of burning out the PA at full power since the VSWR will be badly off.
The ones Im using are identical to the one in the picture at:
If it really needs tx_ant and rx_ant pins to be controlled externally, then I will need to make some changes to the library.
But... surely the controller chip on board knows when it want to transmit and recieve and should be controlling the antenna switch itself? Why would it expect an external processor to control the antenna switch for it?
