thUndeadMod v3.4 - openLRS S**T just got real :)

[papa_lazerous]

Just wondering what the theoretical range would be on 433Mhz with 7Watt booster.........

[Coyote]

If you go off 8km being max range, which it isnt, but for arguments sake, its 4x the power to double the distance, 4x100mw = 400mw 4x400mw = 1.6watts 4x1.6watts = 6.4 watts,

So that 3x each steps range, 8km x 2 = 16km, 16km x 2 = 32km, 32km x 2 = 64km+ ground range

[zitron]

Nope, gopro, plane, video system and tx off during the noise floor scan

Ok, I just did another noise floor scan at where I live using the same settings you did, and attached results.

I have also overlaid your results on top of mine, after scaling. Unless I did something wrong you clearly have a much higher noise floor at 459MHz, 15dB will make a dramatic difference. Just to be sure, the red line on your graph is the maximum right?

Also really interesting how the spectrum matches so nicely...

[Coyote]

Here is an issue, the first system power up on 459mhz firmware shows the RSSI showing full losses at less than 10ft range. Just like Cat`s problem, but I thought I`d video it in case it sheds light for someone

459mhz bootup issue

[Coyote]

Yes it seems so Zitron, I wish Denis could rescale his spectrum graphs with RSSI power Dbm

[Cat695]

Yep Ian thats exactly what mine does when on 459.......

[zitron]

Hmm.. anyone know what frequency deviation (fd) value undead is using? If it's a intermittent packet drop/crc fail increasing fd will help boost signal to noise, it worked for me. Then again I did not have any of the rssi fluctuations your guys seem to be having.

When he changed the frequency maybe he inadvertently changed something else? There are so many settings in the RFM22 module...

[Devonian]

thUndead's frequency deviation in v3.5 is:

_spi_write(0x72, 0x30); // frequency deviation setting to 19.6khz (for 38.4kbps)



Some interesting reading...
http://www.open.com.au/mikem/arduino/RF22/

From that link...

Automatic Frequency Control (AFC)
The RF22M modules use an inexpensive crystal to control the frequency synthesizer, and therfore you can expect the transmitter and receiver frequencies to be subject to the usual inaccuracies of such crystals. The RF22 contains an AFC circuit to compensate for differences in transmitter and receiver frequencies. It does this by altering the receiver frequency during reception by up to the pull-in frequency range. This RF22 library enables the AFC and by default sets the pull-in frequency range to 0.05MHz, which should be sufficient to handle most situations. However, if you observe unexplained packet losses or failure to operate correctly all the time it may be because your modules have a wider frequency difference, and you may need to set the afcPullInRange to a differentvalue, using setFrequency();

Useful files
http://www.open.com.au/mikem/arduino/RF22/files.html

Nigel.

[Splashy]

I am no expert on the RF22M or the Si4432 but I have spent quite a while looking at the data sheets and playing around with the Excel Spreadsheet calculator.

I think that we should be looking at a couple of sections and registers.

//band 435.000
#if (BAND== 0)
_spi_write(0x75, 0x53);
#else
_spi_write(0x75, 0x55);  //450 band
#endif
_spi_write(0x76, 0x7D);   
_spi_write(0x77, 0x00);
}

How has the value in register 0x76 been calculated?
If I use the spreadsheet calculator for 459 then it gives a value of E1 instead of 7D. But I guess that this is overwritten in the next section. It would be good to do a test with frequency hopping disabled and maybe some hard coded values taken from the frequency calculator.


and

void frequency_configurator(long frequency){

  // frequency formulation from Si4432 chip's datasheet
  // original formulation is working with mHz values and floating numbers, I replaced them with kHz values.
  frequency = frequency / 10;
  frequency = frequency - 24000;
  #if (BAND== 0)
  frequency = frequency - 19000; // 19 for 430�439.9 MHz band from datasheet
  #else
  frequency = frequency - 21000; // 21 for 450�459.9 MHz band from datasheet
  #endif
  frequency = frequency * 64; // this is the Nominal Carrier Frequency (fc) value for register setting
 
  byte byte0 = (byte) frequency;
  byte byte1 = (byte) (frequency >> 8);
 
  _spi_write(0x76, byte1);   
  _spi_write(0x77, byte0);

}

In the above section we have 459 sitting right at the top of the 450 - 460 band. Should we not be using a value of 21900 when getting frequency = frequency - 21000

Apologies if I am totally off the ball here.

If the hardware design is correct and we are getting good results on 433 Mhz, and the unit will work to almost the same power output on 459 Mhz then it would indicate that it is the registry settings that are incorrect for 459Mhz. 433 is almost in the middle of the 430–439.9 MHz band, whereas 459 is right at the top of the 450–459.9 MHz band.

The testing done so far has been very time consuming. Could we not produce a testing version of the TX and RX and get it to cycle through some potential registry settings and hopping options. It could go through a cycle of options over say a 1 minute period...

10 seconds on low power output (so we know when the period starts)

and then 10 seconds trying out each option

I realise that we could not really do the same for the RX since we could not coincide these actions without switching on at the same time .. or could we use the button on the TX to change the options that we use and then use the LED to indicate which option has been selected.

We could even use the button and LED combination to try out different frequencies .. say starting at 433, moving to 435 and then 459. It would mean that we could take lots of readings for later analysis while at a set distance. Of course this testing would be made easier if we had a couple of RX to use.

[Devonian]

I agree that it would be useful to have a 'simple' Tx firmware.
No frequency hopping, no telemetry, just hard coded for single channel, i.e. 459MHz at full power.
The spectrum analyzer firmware for the Rx is not a problem for the moment and will allow us to figure out exactly what is going on here.

I've attached the HopeRF Excel spreadsheet if it helps...

Nigel.

[Dennis Frie]

Yes it seems so Zitron, I wish Denis could rescale his spectrum graphs with RSSI power Dbm

I will have another look at it next week (dbm instead of RSSI). It should be 0.5 dB/RSSI, but I wasn't able to confirm it, when I did a quick test with attenauters etc.

[Coyote]

Thanks Dennis, much appreciated :)

[Coyote]

Ill do one more range test, v3.4 with no hopping on 459, that should be the last piece of the puzzle confirmed then, takes the hopping out the equation. If it fails we know its power related I suppose, if the results are good we know its the hopping that needs attention

[zitron]

thUndead's frequency deviation in v3.5 is:

_spi_write(0x72, 0x30); // frequency deviation setting to 19.6khz (for 38.4kbps)

That is used as an example in the data sheet, and I think that is a bit too low. When fd = 19.6 I get dropped packets sitting on my table. I guess it's ok if you want narrow band transmission and don't care about a couple % error, but since no one else is using 459, I quadrupled mine to 76.8kHz and no more dropped packets. However I did not see a significant effect on range.

Interesting note on the AFC, but if you are using something like a 20ppm accurate crystal, you will be off by 0.01MHz in the worst case, well within the 0.05MHz range.

I will have another look at it next week (dbm instead of RSSI). It should be 0.5 dB/RSSI, but I wasn't able to confirm it, when I did a quick test with attenauters etc.

Yes 0.5dB/RSSI is what the data sheet says. I subtracted 130 from the result by looking at the graph, but that maybe open to interpretation.

[thundead]

Indeed I think I need to change the fd for 459mhz but I need to make it smaller not larger as on 459Mhz we got 10khz spacing between channels. If you make it bigger (it is to big already cheers for pointing that out) it will overlap with the other channels. Correct me if I'm wrong. 433 has 60khz channel spacing so the current fd is ok for that band.

Also from teh datasheet, for 9.8 baud @ GFSK the recommended is either 45khz or 4.8khz spacing. ( si4432.pdf page 49)

thUndead's frequency deviation in v3.5 is:

_spi_write(0x72, 0x30); // frequency deviation setting to 19.6khz (for 38.4kbps)

That is used as an example in the data sheet, and I think that is a bit too low. When fd = 19.6 I get dropped packets sitting on my table. I guess it's ok if you want narrow band transmission and don't care about a couple % error, but since no one else is using 459, I quadrupled mine to 76.8kHz and no more dropped packets. However I did not see a significant effect on range.

Interesting note on the AFC, but if you are using something like a 20ppm accurate crystal, you will be off by 0.01MHz in the worst case, well within the 0.05MHz range.

I will have another look at it next week (dbm instead of RSSI). It should be 0.5 dB/RSSI, but I wasn't able to confirm it, when I did a quick test with attenauters etc.

Yes 0.5dB/RSSI is what the data sheet says. I subtracted 130 from the result by looking at the graph, but that maybe open to interpretation.