Reduce range of a RFM70 2.4GHz transceiver

Status
Not open for further replies.
Graham2107 said:
How the heck did you figure that one out as I cannot write to it either !!!
Click to expand...
Well, sometimes you have to be creative, and since the ACTIVATE command with 0x73 activates the W_TX_PAYLOAD_NOACK command, I was thinking mayby it also "activates" the FEATURE register - I had to try SOMETHING cause I wanted the W_TX_PAYLOAD_NOACK command to work.

I haven't noticed this. I did see that the Hope code saves the STATUS content in a variable (UINT8 op_status) but I didn't do the same, I just made a special function for reading the STATUS register. I will check with the FIFO_STATUS register, to see if the STATUS is shifted out with my code.

Graham2107 said:
Perhaps you should add this to the Martin/Graham document "RFM70 for Dummies" or "Getting the RFM70 to Work" and send a copy to Hope RF
Click to expand...
Yeah, we should

When I work with a device like this, where the datasheet is lacking a lot of info, even though it is almost 1½ years old, I really appreciate the completeness and detailed datasheets from Microchip. I love the way they have a step-by-step guide for each feature of the PIC, I really missed this with the RFM70, but at least we had the Hope code to get some inspiration from.

Graham2107 said:
Why did you change this register to channel 0x23 ?
Click to expand...
Dunno, they did that in the Hope code, so I just did the same. The channel should not matter unless you have another 2.4GHz wireless device on the same channel. I actually have a wireless router, I don't really know what channel it is using, maybe I should find out
 
I don't know whether it is my imagination (scratching too much grey matter now ) but it seems that if you read a register <0x11 then you get the STATUS first PLUS the register contents. If you read say 0x11 then you only get 0x11 and not STATUS first. Please check this as I loosing my marbles.....

Upon reading between the lines does "ACTIVATE" + 0x53 have another meaning:

Quote from page-13 under the "ACTIVATE" paragraph, at the bottom of that section:

"This write command followed by data 0x53 toggles the register bank and the current register bank number can be read out from REG7[7]"

Does this actually mean that toggling "ACTIVATE" + 0x53 either allows STATUS ONLY or STATUS + REGISTER ????
 
Last edited:
ACTIVATE + 0x53 toggles between Bank0 and Bank1. I don't think it does anything else. As seen in my function SwitchToBank(), you have to read the STATUS register (or actually just bit RBANK) before changing bank if you want to be sure that you are actually switching to the bank you expect. So reading "REG7[7]" or bit RBANK, you will know what bank you are in right now.

It is possible that if you are in Bank1, you won't get STATUS shifted out, because the register 0x07 in Bank1 is write only (except for bit 7 "RBANK"), and if you are in Bank1, the RFM70 can probably not read the STATUS from Bank0.

I will check this when I get time, maybe tonight, so stop scratching before you scratch a hole in the top ;-)
 
You won't believe this but I swear it read STATUS + REG[x]. This was sometimes a useful feature as it read two at once, sometimes it was a pain. Then I was really getting down to the grey matter and so I changed the position of my CS=1 and CS=0 in my code and now it doesn't do it any more !

Now at least I also have the FIFO_STATUS bit (TX_EMPTY) changing state after dumping 5-bytes of data in the W_TX_PAYLOAD_NOACK. Then I re-read FIFO_STATUS, in debug mode, and the bit is set again Does this actually mean the RFM70 finally did something?

Question - on power-up [applying DC] you initialise BANK-1 but do you have to do this every time or, having initialised once, do you ignore ? Is BANK-1 volatile ?
 
I don't really understand you here. Do you mean CSN (not CS)? The CSN will enable SPI communication. I have learned that you can/should only apply one command (read, write ect.) for every CSN toggle you do.

From the datasheet 5.2 page 10: "After transmission, if the PTX packet has the NO_ACK flag set, RFM70 sets TX_DS and gives an active low interrupt IRQ to MCU. If the PTX is ACK packet, the PTX needs receive ACK from the PRX and then asserts the TX_DS IRQ.".
So if the TX_DS bit is set, the packet has been transmitted.

Graham2107 said:
Question - on power-up [applying DC] you initialise BANK-1 but do you have to do this every time or, having initialised once, do you ignore ? Is BANK-1 volatile ?
Click to expand...
I assumed everything is volatile, but there is really no absolute way to check this when you can't read the registers. Maybe write another value to the RAMP register and see if it is still changed after a new power up? But still, maybe the RAMP is non-volatile and the rest is volatile. I guess the only way to test this is to see if the RFM70 will work without initializing the registers, if not, I think we can assume they are volatile. Another thing I could test

Graham2107 said:
After a TX do you need to clear STATUS TX_DS (as it is set after a TX) or do you leave it ?
Click to expand...
I really haven't got this far, I only sent 1 packet The datasheet says "Write 1 to clear bit." so I guess you need to clear the flag unless the flag is cleared by hardware at some point (loading TX FIFO maybe?).
 
Last edited:
I find this whole concept of getting the RFM70 to work by working with someone who, thankfully is in the same time zone, is on the same "hymn sheet" but across such a distance
 
I started this morning full of the thoughts that I might at least get this IC to work. After yet another 5-hour stint with coding I end up with exactly the same result as before I give up.
 
Try sending me your code to my gmail address, maybe I can see where you take a wrong turn

The devices are in fact a bit hard to kill, I have by mistake supplied it with +5V several times, they still work
 
Email answered.

Try to cook the code down to something simple and leave out all the fancy stuff like writing data from an array and just write it directly like I did - make it as simple and dumb as possible to start with and get the thing to work before doing all the fancy stuff
 
But you also have not said that you have seen any data on the RX module and so, without going back in time and re-doing the Hope code, like I did a week ago without any success, I think I will dump the idea for now and focus on things that actually work
 
Graham, I did indeed see data on the receiver, I have successfully sent 1 byte of random data from one RFM70 configured as PTX to the other RFM70 configured as PRX.

Anyway, your help got me going and you gave me some good directions for getting this to work. If you move on to other projects, I'll just have to write the howto myself, and then perhaps you can get your code working after reading my howto
 
Graham2107 said:
How the heck did you figure that one out as I cannot write to it either !!!

Perhaps you should add this to the Martin/Graham document "RFM70 for Dummies" or "Getting the RFM70 to Work" and send a copy to Hope RF
Click to expand...

is this a existing document? or was it just a joke? otherwise i would love to have it.
 
Status
Not open for further replies.

Similar threads

O
  • Question
Is there any analog radio receiver that prevents fading of the SW reception?
Replies
6
Views
973
Miles Prower
  • Question
IFT alignment of old transistor AM Radio
Replies
5
Views
8K
Tony Stewart
A
  • Question
unexpected behavior of the matching components
Replies
0
Views
4K
AmziSys
A
A
  • Question
HTRC110 long range RFID Reader
Replies
9
Views
18K
Betwixt
B
O
  • Question
Can an audio amplifier be used to transmit or receive radio signals?
Replies
11
Views
972
Miles Prower
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…