Proton BASIC Community

@trastikata thank you, very kind, if I can try it this weekend.
The modules are already mounted with PIC18F25K22,
I saw in your listing that you use the 4MHz clock, is it for some particular reason?
I think perhaps to reduce consumption.

Thanks Very Much for your Kindness and Help Trastikata it is VERY much appreciated. It makes a lot more sense now, I couldn't find the Sync word setup in the Hope Rfm Version 2 Manual as it sits in the greyed FSK/OOK area and shows it as restricted in their Lora section. I went and downloaded the latest datasheet Version 7 from Semtech and Everything is perfectly correct. So my advice to anyone using the RFM's is to ignore their data sheet and just use Semtech's.   

If I have understood correctly the RFM98's use the PA BOOST Pin and Not the RFO, so maybe Les must put this option in the Driver as a note.
Trastikata your Rocket Project looks absolutely Fantastic, well done on an excellent article and project. Just a Quick Question did you use the Standard Flat Aluminum strips that are about 10mm wide x 3mm thick to construct tour Yagi?

Thank you Again.
Regards
Craig

@Giuseppe MPO

the 4 Mhz was just because of the software SPI, if using higher frequency crystals, you might need adding some delays in the software SPI.

By the way my code is set for PA_BOOST pin as  RF output and RFI_LF as RF input.

@Craig

indeed, the Yagi antenna was designed with 15x15 square profile as a boom and 10x2 flat ribbons for the directors and reflector. The Yagi calculator you saw there is actually written by one of our forum members . Anyway, his program works perfectly and the coax Balun calculator which is included there is great addition - saves you a lot of trouble and it is mandatory for the Yagi...

@trastikata perfect, thanks.

IW6MPO

There's another interesting thing I forgot to mention about SX127x chips.

The SX127x datasheet states they are using 32MHz crystals or TCXO's. To really take an advantage of those LoRa chips you will need a TCXO, however 32MHz TCXO's are hard to find and quite expensive, whereas 26MHz 0.5ppm - 1ppm TCXO's are ubiquitous and inexpensive!

SX127x chips, although not mentioned in the datasheet work perfectly well with 26MHz clock sources (TCXO's and Crystals) - the only thing is when you are calculating the frequency integer values for the corresponding RegFrf registers and other clock source related registers, you'll need to use 26MHz instead 32MHz.   

I located the reason for the shorter range with my library code.

It is because I am using the high bandwidth, so that reduces range. When I reduce the bandwidth, the range, and current used, increases. However, the method I am using of sending a single byte within a packet seems to have problems and it has a tendency to loose sync for some reason. I also forgot to add some setup registers that increase the current of the transmitter.

Reducing the bandwidth works, and increases the range, but reduces the flow of bytes tremendously, and it kicks in the timeouts I have within the replacement code, so I'll look into it further. If I increase the packet, it works well, but that will not immitate a USART coms. :-)

Many thanks trastikata. Your code gave me a few clues as to where to look for any issues.

Hello Les
I had a look through your Library and it is as usual Beautifully Written and commented which makes it so easy to follow and will be an Absolute Master Piece when finished. I did see in the include file if I try and select PortD or E on say the Rest pin then it does not accept it as I was using a 18F47K40 Device and you set it up on a 26K40 Device but, I just moved the pin to port B for testing purposes.

Regards
Craig

 

Many thanks Craig. I always take the time to create comments in code, even when it is for my use only. :-) They come in very useful when going over code, months after it is created.

I have just tested the code with a PIC18F47K40 device and altering the ports, and it works OK. See below:

    Device = 18F47K40
    Declare Xtal = 64

    Declare Hserial_Baud = 9600
    Declare HRSOut1_Pin  = PORTC.6

$define SX_MISO_Pin PORTB.3                             '  Connects to the SX1278' s SX_MISO_Pin pin
$define SX_MOSI_Pin PORTB.4                             '  Connects to the SX1278' s SX_MOSI_Pin pin
$define SX_RST_Pin  PORTD.5                             '  Connects to the SX1278' s RST pin  <-------------------------------
$define SX_NSS_Pin  PORTC.1                             '  Connects to the SX1278' s NSS pin
$define SX_DIO0_Pin PORTC.2                             '  Connects to the SX1278' s SX_DIO0_Pin pin (Used as an IRQ for received data)
$define SX_SCK_Pin  PORTC.3                             '  Connects to the SX1278' s SCK pin

$define LED_Red_Pin PORTC.4
$define LED_Green_Pin PORTC.5

Make sure you did set Device to 18F47K40, and not 18F27K40. The SX1278 interface pins are only ever used with the PinLow, PinHigh, PinOutput, PinInput, PinSet or PinClear commands, when using software SPI, so they act just as normal Ports.Pins.

Also, make sure the pin $defines are placed before the Include "SX1278.inc", so the library code can see them. Otherwise, the library will give warning messages that is it using its default pin settings.

Thanks Les Found it, I changed the name of the include file to keep the original apart and that is where the error occurred.
regards
Craig

Hi all,

I had some free time today (mandatory quarantine  )  and wanted to show you one SX1278 feature you should consider, especially if your devices (modules) are using Crystals instead of TCXO's. When using a crystal, the frequency tends to float considerably with temperature changes and consequently the base frequency changes. If you are using higher bandwidths, then this offset doesn't matter much, but higher bandwidths mean shorter range. If the oscillators in your TX and RX devices float in different directions (say one device is heating up, the other is cooling down) the the offset between both could rapidly exceed the maximum allowed 25% of the Bandwidth at which point your devices will no longer be able to communicate. With TCXO this is less of a problem. To demonstrate the drift in frequency I measured it for both Crystal and TCXO based oscillator:



If you take a look in the code that I posted, every time a new packet arrives, I am reading a value called "LoRaFeiValue" from register RegFeiMsb through RegFeiLsb. This "LoRaFeiValue"value represents the offset between the Transmitter and Receiver oscillators.

What does it mean - let's say you set your TX and RX devices to 433.0000 MHz  and you are using a good quality crystal. However the actual frequency in your TX device is say 433.0021 MHz and the actual frequency in your RX device is say 432.9982 MHz. Hence the actual offset between both devices is 3.9kHz. As stated earlier the maximum allowed offset is 25% of the Bandwidth used - or in this case you can't use bandwidth lower than 15.6kHz. In reality with cheap crystals I couldn't get a reliable link using bandwidths lower than 62.5 kHz.

Keep in mind that even if you made a successful initial connection, your crystal will take some heat from the PCB or will cool down from wind draft and you can easily exceed those 25% from the Bandwidth and loose the link. However this doesn't happen so sudden and here comes in help that "LoRaFeiValue" which I mentioned at the beginning.   

So going back to the "LoRaFeiValue" - when a packet is successfully received, the SX1278 measures the offset in frequency between the transmitting and the receiving device and places this offset in RegFeiMsb through RegFeiLsb registers. Now by using this value and the formulae in the datasheet you can calculate by how much you need to offset your receiver's oscillator to match the transmitter's oscillator. This is simple task - all you need is to add or subtract the calculated frequency steps from the frequency registers RegFrMsb through RegFrLsb. And you keep doing this at each packet reception.     

This way, once the link has been established, you can keep the connection alive even when the crystals start drifting. Or if you want some fancy stuff - you can start your link with higher bandwidths, and every say 4 packets you lower the bandwidth to a value that otherwise you might not have been able to use for establishing the initial link.

Down in the code brackets I placed some real values taken from several consecutive packets demonstrating how the correction works. The base frequency is 433.1500 MHz and the bandwidth is 15.6 kHz, using 0.5ppm 26MHz TCXO. As you can see the initial offset is 177Hz (which is not a problem) and then the correction algorithm keeps the actual offset between the TX and RX device below 50 Hz.

Hope this will be of help to people interested in LoRa devices. 

LoRaFeiValue = 6604
FerrorHz = 177.2747
ErrorCorrection = 3

LoRaFeiValue = -2588
FerrorHz = -69.4710
ErrorCorrection = -1

LoRaFeiValue = 52
FerrorHz = 1.3958
ErrorCorrection = 0

LoRaFeiValue = 20
FerrorHz = 0.5368
ErrorCorrection = 0

LoRaFeiValue = 2804
FerrorHz = 75.2693
ErrorCorrection = 1

LoRaFeiValue = -132
FerrorHz = -3.5433
ErrorCorrection = 0

LoRaFeiValue = 444
FerrorHz = 11.9185
ErrorCorrection = 0

LoRaFeiValue = -404
FerrorHz = -10.8447
ErrorCorrection = 0

LoRaFeiValue = -1092
FerrorHz = -29.3131
ErrorCorrection = 0

LoRaFeiValue = -1460
FerrorHz = -39.1915
ErrorCorrection = 0

LoRaFeiValue = -1708
FerrorHz = -45.8487
ErrorCorrection = 0

LoRaFeiValue = -1932
FerrorHz = -51.8617
ErrorCorrection = -1

LoRaFeiValue = 1012
FerrorHz = 27.1656
ErrorCorrection = 0

LoRaFeiValue = 908
FerrorHz = 24.3739
ErrorCorrection = 0

LoRaFeiValue = 812
FerrorHz = 21.7969
ErrorCorrection = 0

LoRaFeiValue = 716
FerrorHz = 19.2199
ErrorCorrection = 0

LoRaFeiValue = 652
FerrorHz = 17.5019
ErrorCorrection = 0

LoRaFeiValue = 596
FerrorHz = 15.9987
ErrorCorrection = 0

LoRaFeiValue = 556
FerrorHz = 14.9250
ErrorCorrection = 0

LoRaFeiValue = 540
FerrorHz = 14.4955
ErrorCorrection = 0

LoRaFeiValue = 468
FerrorHz = 12.5627
ErrorCorrection = 0


Trasticata,

Thank you for the master class you have given us in this thread.

I would like to ask a question that is not clear to me. A couple of years ago I was reading the data sheet of a Microchip Lora module. It detailed a Lora protocol with cryptographic keys that encrypt the message. In this thread this encryption has not been discussed, so I deduce that the SX1278 chip does not perform this function automatically. Therefore this encryption function would have to be done before sending the information to the SX1278 chip. This is my doubt.

Regards,
Gamboa

Quote from: Gamboa on Apr 07, 2022, 07:27 AMI would like to ask a question that is not clear to me. A couple of years ago I was reading the data sheet of a Microchip Lora module. It detailed a Lora protocol with cryptographic keys that encrypt the message. In this thread this encryption has not been discussed, so I deduce that the SX1278 chip does not perform this function automatically.

Hello Gamboa,

the SX127x chips don't have encryption engines and you can't encrypt the data by using the SX127x chips only. The Microchip's R34/R35 LoRa chips are actually ARM Cortex processors and bunch of other peripherals, including encryption engine and LoRa Radio in one micro-controller.

I have not come across any information about Semtech selling know-how to Microchip, so this LoRa radio modem in R34/R35 must be somebody else's development, which is strange because as far as I know it's only Semtech who is designing and selling radio chips with LoRa modulation. So how did Microchip come to use the and market as such the patented by Semtech LoRa modulation physical layer - I have no idea.     

Thanks very much Trastikata for the huge effort that you have made with the Lora and insight into its workings giving such valuable advice. I have been looking at the ST50L chip from https://www.acsip.com.tw which has AES. I am starting to lean away from using the RFM98's which has a standard Crystal in this design as Temperature is going to be a issue, as your article has described so well and rather look at something like the ST50L. I think this will be a much better solution in the long run.
Regards
Craig

Hello Trastikata
Just a Quick Question and some advice please. When you did your design for Lora did you use a 2 or 4 Layer Pcb?
Regards
Craig

Quote from: Craig on Apr 08, 2022, 10:54 AMJust a Quick Question and some advice please. When you did your design for Lora did you use a 2 or 4 Layer Pcb?

Hello Craig,

4L PCB - it's easier to get closer to 75 Ohm transmission lines.
https://spok.ca/index.php/resources/tools/99-cpwcalc

Regards

Thanks Trastikata that's what I thought.
Regards
Craig