Hmmm,    not the range I was hoping for,  I had a LED toggle on and off when a valid length message arrived ( sent every 500ms )

 I got 150m solid signal, but after that it would skip a flash, but never actually stopped receiving even up to  250m, it just missed flashes more often.

OK I will be using a yagi at the TX, and perhaps a dipole at the RX, so it could work, but its got to be reliable.

The fact that it still received at over 250m seems to suggest that the RF strength isn't the problem, perhaps its a signal/noise bandwidth issue (   I hate RF , even when I was a radio ham 50 years ago ! )    

The fact that the range went from 7 meters to 150 just with my library pot luck twiddles makes me think that perhaps I am a quarter of the way to the answer, but don't know enough about the software.

I used SIM20 modules last year on a project, but the  documentation is atricious, so I dont think I can get that working in a  semi-duplex mode.
I got 500m range with them, also with a 170mm antenna wire.

These RFM22Bs are a third of the price, so I would like to get them going properly,  and perhaps use the diversity combiner mode with 2 antennas to avoid dead spots.

I have just found this on a picaxe forum  

  "I was just doing some long range LOS tests with the 434Mhz tuned RRM22, I got 100% reception reliability at 4.3Km with 25mW output, 50% reliability at 12mW. This was using 5khz deviation and 250bps data rate with Manchester enabled. "

Anyone know how to set these parameters ( OK perhaps not that slow  ) up with the RFM22B  , there is a spreadsheet thing to calculate it, but as I said it doesn't work on my Openoffice :-

http://www.hoperf.com/upload/rf/RF22B%2023B%2031B%2042B%2043B%20Register%20Settings_RevB1-v5.xls


I basically want to send 10 bytes every half second,  and receive similar from the robot, so its not  a lot of data.

Well the range test with the reliable datagram was hardly worth me putting some sandals on, it faded out at about 7m range !

I had looked at the data to the module, and it looked so fast compared to my normal projects.

I couldnt find a way to change the data rate, so I delved into the RF22 library cpp file, and changed the power to 17 dBm, and the baud rate to the one I used on the simplex mode.  (  i have no idea what it means ! )

There is a  spreadsheet to calculate the set up , but it doesn't work in openoffice :-(
 My changes :-

   // setModemConfig(FSK_Rb2_4Fd36);     
    setModemConfig(GFSK_Rb2Fd5);
  //  setTxPower(RF22_TXPOW_8DBM);
    setTxPower(RF22_TXPOW_17DBM);/

I can now walk 50m to the end of my road with it still working, and I am going to take them out on a straight road to test.
It did fade through 3 buildings, but my appication is in the open air...

Looks like we are on a similar course agaIn  with this project.

I don't know how you were testing the RFM22B modules, but I have them hooked up to the 3.3v of the Arduino, and I found I need a 4700mFd cap on the 3v3 supply line to take the pulse when it transmits at full power.

I also want to monitor the SSR reading every second or so, at both ends, and display it on the LCD with a warning light if either drops below a  certain level.

I am thinking of having the robot send its housekeeping data every second, so as to monitor the comms, and hold back when receiving " driving" data from the remote.

I am going to add a LED flash ( can't use pin13 as its  SPI ) and take a walk with the one arduino on a battery tomorrow, I will try it with the 170mm whips both ends.

Have you got the RX and TX tied to the GPIO pins ?   

I will post the range results tomorrow.

I have only got these modules hooked up accross the bench at the moment , but I want to test the range tomorrow.

I had over 150m range with the modules in the simplex mode ( I didn't check further as I was at the end of the road and only needed 100m ! )

I don't know your setup there, but I use a lot of LED display projects, and the main cause of odd behaviour is poor grounding on the LED returns, ( and evidently people using several Arduino/similar , poor grounding between the sections )
I just thought I would mention it as a thing to tick off,

  Good luck

You have got the grounds all connected together I suppose ?

Thanks Paul,   I shall move on now then

[while (1)]

For my next project, which is a remote control and telemetry link to a very large robot,  I want to have a safe wireless link with a range of at least 300meters.  I can use a decent antenna at the control centre, and a dipole on the robot, so range should be no problem.

I have used the RFM22B modules before, but only in the basic simplex mode,   I now have 2 of them hooked up on the bench and using the RF22 libraries "reliable datagram"  example from Mikem , with 2 Duemilanova boards for now ( they will have embedded chip pcbs in the final units ).

It worked first time, and I have found how to simply read the temperature and signal strength etc.

Now I am looking at how to structure my data, (  which is joysticks and switch data going to the robot, and a few oil pressure, fuel guage, temperature , signal strength and GPS position data coming back )

I was planning to collect the data and put it in a buffer to send, all in the main loop as usual.

In Mikes example below, he has defined the data and datalength between the setup and loop sections ?
Is there significance to this ?
I guess thats the same as having them at the top with the definitions if they are not going to change ?  

and I can find no reference to        while (1)  ?  and why    // Dont put this on the stack:

Code:

// rf22_reliable_datagram_client.pde
// -*- mode: C++ -*-
// Example sketch showing how to create a simple addressed, reliable messaging client
// with the RF22ReliableDatagram class.
// It is designed to work with the other example rf22_reliable_datagram_server
#include <RF22ReliableDatagram.h>
#include <RF22.h>
#include <SPI.h>
#define CLIENT_ADDRESS 1
#define SERVER_ADDRESS 2
// Singleton instance of the radio
RF22ReliableDatagram rf22(CLIENT_ADDRESS);
void setup()
{
Serial.begin(9600);
if (!rf22.init())
Serial.println("RF22 init failed");
// Defaults after init are 434.0MHz, 0.05MHz AFC pull-in, modulation FSK_Rb2_4Fd36
}
uint8_t data[] = "Hello World!";
// Dont put this on the stack:
uint8_t buf[RF22_MAX_MESSAGE_LEN];
void loop()
{
while (1)
{
Serial.println("Sending to rf22_datagram_server");
// Send a message to rf22_server
if (!rf22.sendtoWait(data, sizeof(data), SERVER_ADDRESS))
Serial.println("sendtoWait failed");
else
{
// Now wait for a reply from the server
// Serial.println(rf22.lastRssi(), HEX); // of the ACK
uint8_t len = sizeof(buf);
uint8_t from;
if (rf22.recvfromAckTimeout(buf, &len, 2000, &from))
{
Serial.print("got reply from : 0x");
Serial.print(from, HEX);
Serial.print(": ");
Serial.println((char*)buf);
}
else
{
Serial.println("No reply, is rf22_datagram_server running?");
}
}
delay(500);
}
}

Huha   Thanks Michael,

I think I have run foul of a couple of those gotchas along the way, and had to Mgyver my way out.

I will keep a note of these for next time.

Thats why I was curious ...

Forget trolls,     

  If its declared globally,  isn't it declared for EVERY scope?

    is this true or not?

Its actually a shame he gave up, I would like to have seen what the cause of the problem was.....

I did a search and havn't found this on the forum before, it looks interesting -  delete this post if its old hat


http://www.domusweb.it/en/design/a-visit-to-the-arduino-factories/

Thats something I was going to ask about Paul,  the pro just means higher Tx power ?  everything else is the same then.

I will be working on a telemetry and remote link in a week or two that has to be uber safe ( it moves heavy stuff that could kill )  I will be asking advice later, but I am looking at the pro Xbee,  perhaps I should be looking eslsewhere ?

I have limited knowledge of all the systems, but this waveform seems to go against the idea of Manchester encoding. 

If you look at the first dozen bits of the preamble, they are all nicely symetrical around the zero volts, which makes data slicing easy ( the data is fed to one input of an opamp/comparator directly, while the other is smoothed to take the average )

If you look at about time 0.848, the signal has crept up on the data line, so the mark to space ratio of the comparator output will be  distorted. 

Perhaps it is a system that detects the top of the pulses, and measures the interval between them ?