DATA transmission/receiving using SCR Radio modules.

[ericgibbs]

hi C,
It loads a program that resets ALL your passwords every time you go online, also loads countless cookies.
Do not click the link for the LoRa.

E

 

[camerart]

hi C,
It loads a program that resets ALL your passwords every time you go online, also loads countless cookies.
Do not click the link for the LoRa.

E

Hi E,
Good job, I hadn't got round to clicking on any of the pages in this link.
Cheers, C.

 

[camerart]

Hi,
I'm still trying to understand how the FIFO works.

When receiving DATA 'say' via an aerial. Does each BYTE get loaded into the FIFO like a pack of cards, while counting (NUMBER) till the last BYTE has been received?

When READing the FIFO, is it READ from the bottom, until the NUMBER reaches '0', then SENT to 'say' a terminal?
C.

 

[sagor1]

Hi,
I'm still trying to understand how the FIFO works.

When receiving DATA 'say' via an aerial. Does each BYTE get loaded into the FIFO like a pack of cards, while counting (NUMBER) till the last BYTE has been received?

When READing the FIFO, is it READ from the bottom, until the NUMBER reaches '0', then SENT to 'say' a terminal?
C.

A lot depends on the size of the FIFO. Some PIC UARTS, for example, have a 2 or 3 byte FIFO. But, if receiving 8 bytes into that FIFO, one has to read the bytes as they come in (before the FIFO gets full), else it will overflow. Usually there is a flag for FIFO overflow. Small FIFO are to allow the program some time to respond to an interrupt or "receive" flag and read the fifo until empty (like you assume). Then, if more data comes in, it simply starts adding to the FIFO again and sets a flag that there is data received again.
If the FIFO is bigger than the expected received data, you don't need to worry about overflow. But, this is not common, most FIFO are simply limited buffers to allow time for processing of data without losing a byte or two.
Every byte that goes into the FIFO increments the FIFO counter, and every byte you read from the bottom decreases the FIFO counter. One reads the FIFO until the counter hits zero. Before reading anything, always check the overflow flag, because if that is set, it is too late, you missed data

 

[camerart]

A lot depends on the size of the FIFO. Some PIC UARTS, for example, have a 2 or 3 byte FIFO. But, if receiving 8 bytes into that FIFO, one has to read the bytes as they come in (before the FIFO gets full), else it will overflow. Usually there is a flag for FIFO overflow. Small FIFO are to allow the program some time to respond to an interrupt or "receive" flag and read the fifo until empty (like you assume). Then, if more data comes in, it simply starts adding to the FIFO again and sets a flag that there is data received again.
If the FIFO is bigger than the expected received data, you don't need to worry about overflow. But, this is not common, most FIFO are simply limited buffers to allow time for processing of data without losing a byte or two.
Every byte that goes into the FIFO increments the FIFO counter, and every byte you read from the bottom decreases the FIFO counter. One reads the FIFO until the counter hits zero. Before reading anything, always check the overflow flag, because if that is set, it is too late, you missed data

Hi S,
From the DATA sheet [See post#1] it says the FIFO is 64 BYTES. It's possible that this is split in two TX RX so 'say' 32 BYTES. For testing I can keep everything to less than 32 to save overflowing.
From the notes, I'm following, I get the feeling that the DATA is being emptied from FIFO at the same time as it is coming in from the aerial, is this true, or does it fill the FIFO while counting the BYTES, then sends it out to 'say' a computer serial port while counting them out?

Do you know how the DATA is stored for outputting and inputting? I'm trying to understand how the DATA transitions to/from the radio module to/from the radio module.
C.

 

[sagor1]

Fifo is stored until it is read by some routine. Fifo does not empty on its own, it has to be read, or have some DMA/Interrypt code (complicated...). In 99% of the cases, FIFO has to be read in order to empty it.
For transmit, the transmit fifo empties on its own, as the hardware sends a byte, it reads the fifo on its own (usually) and decrements the counter. As a program puts another byte into the TX fifo, the fifo counter should go up by one. In some cases, one would put data in the fifo first, then trigger the transmit. How much data on puts in depends on fifo design. For TX, there is usually a fifo "full" flag, that when clear means you can then put another byte into the register (which is part of the internal fifo hardware).

To test to/from radio modules, I would suggest minimal messages at first, to make sure all bytes are transferred properly. That ensures all the flag checking is done properly, both on RX and TX uarts and fifo registers.

EDIT: Looking at the datasheet, this device seems to use memory locations as a fifo with thresholds and of course registers to flag status. This is not the same as a UART fifo where one just reads the same register until the "empty" flag comes on. For this RF device, one has to read the memory locations based on address and number of bytes, etc... This system is beyond my skills with simple PICs...

 

[camerart]

Hi S,
Thanks for looking at the DATA sheet, it's quite a task.

For clarification when testing TRANSMIT:
[Computer USB serial port TX]>>[PIC RX>>FIFO>>TX (DATA PIN)]>>[SX1278 RX (DATA PIN)>>FIFO>>TX (aerial)]

The questions here refer to the SX1278 FIFO, I will set up another thread for the PIC FIFO, HERE: https://www.electro-tech-online.com/threads/understanding-a-pic-fifo.151261/
EDIT: You say "This system is beyond my skills with simple PICs..." Me too!!

Thanks, C.

 

[camerart]

Hi,
A puzzle!
When writing to SPI there is a MASK BIT 10000000
I am looking at TX and TX READ WRITE and am puzzled by these. How are there WRITTEN and READ from?
C

 

[camerart]

Hi,
Here is the 'finished' program, in that it has all been written and it compiles.
I'm sure there are mistakes!
I can now put it on a PIC in circuit and work through it.
C.

 

[ericgibbs]

hi C,
Initial look shows these are incorrect, crossed over.??
E
Dim set_regopmode_lora_access0_res_low_moderxcontinuous As Byte
set_regopmode_lora_access0_res_low_moderxcontinuous = %10001101 '8b 139
Dim set_regopmode_lora_access0_res_low_modetx As Byte
set_regopmode_lora_access0_res_low_modetx = %10001011 '8d 141

 

[camerart]

hi C,
Initial look shows these are incorrect, crossed over.??
E
Dim set_regopmode_lora_access0_res_low_moderxcontinuous As Byte
set_regopmode_lora_access0_res_low_moderxcontinuous = %10001101 '8b 139
Dim set_regopmode_lora_access0_res_low_modetx As Byte
set_regopmode_lora_access0_res_low_modetx = %10001011 '8d 141

Hi E,
Yes, they're in the wrong order, but I think they are the correct settings. do you agree?
EDIT: I've put them in the correct order.
C.

 

[ericgibbs]

hi C,
I mean the conversion decimal to binary bits is wrong.
%10001101 '8b 139 is 8d not 8b
%10001011 '8d 141 is 8b not 8d.

E

 

[camerart]

hi C,
I mean the conversion decimal to binary bits is wrong.
%10001101 '8b 139 is 8d not 8b
%10001011 '8d 141 is 8b not 8d.

E

Hi E,
I see now, thanks, corrected
C.

 

[camerart]

Hi,
Some amendments to the program at #149:
On the 'Const r_regpayloadlength = 0x22' line [Change comment to EXPLICIT HEADER MODE]
On the 'Dim addr As Byte' line change ADDR to [fifoaddrptr]
At LCD: change 'addr' to [fifoaddrptr]

There need to be RX and TX connections to the PIC, and serial code added.

C.

 

[camerart]

Hi,
I am trying to set up HSERIN and HSEROUT for program #149. I have previously used it in my Tracker program, but that was complicated in that it included an NMEA sentence with lots of different types of information.
I would firstly like to test HSERIN using the simplest DATA possible so I can test to see that the radio module transmits.
For example, does all DATA transfer start with a $ sign?
Any help please.
EDIT:I used a $ at the beginning of random numbers, and the expected Variable changed, early result
C.

 

[camerart]

Hi,
The #149 program simulates in Oshonsoft, but so far nothing is appearing on the LCD apart from rubbish. I have added start up indicator LEDs at the start of the program, which flash, also a red on inside the receive loop and a yellow one onside the transmit loop, occasionally the yellow one comes on, but that's all I've managed to get out of it so far, no radio transmission.
I'll now try to proof read the program.
C.

 

[ericgibbs]

hi C,
Such nice weather to be indoors...

I usually add a simple 'Ready' msg to the LCD, close to the program start as possible, keep it ON for say 2 secs.
If you are using RS232/serial a 'Ready',crlf msg will confirm that the modules are wired correctly and are working.

E

 

[camerart]

Hi

hi C,
Such nice weather to be indoors...

I usually add a simple 'Ready' msg to the LCD, close to the program start as possible, keep it ON for say 2 secs.
If you are using RS232/serial a 'Ready',crlf msg will confirm that the modules are wired correctly and are working.

E

Hi E,
I've just come in for a cool
I did something like that in a circuit test, and the LCD works ok.
C

 

[NITIN RAJE]

hi, i am using lora ra-01 module with pic16f689, but i dont know how its configure, please send me c code

 

[camerart]

hi, i am using lora ra-01 module with pic16f689, but i dont know how its configure, please send me c code

Hi N,
This is an old thread, and I didn't finish getting my radio to work.

Also I don't program in ' C ' as I use BASIC, sorry.

C.