I got my TRW-24Gs a while back and finally got a chance to hook them up to a couple AVRs. They work fine I can transmit data and receive data in shockburst mode.
I noticed though that every now and then my receiver gets some data I didnt send. No big deal, I figured its gotta happen once in a while I just turned up the CRC to 16 bits. But I still found during any single minute I get 2 or 3 transmitions I didnt send. So I set one up to receive all the time with no CRC. Wow, the thing always is receiving data. As fast as I can pull it from the buffer, its got another packet. I figured, maybe the channel is crowded, phones, microwaves, blah, blah. So I checked the other channels. Every channel is the same, constant data reception.
I also tested direct mode and found all channels saturated as well.
My question is this, is this normal, or am I just missing something here? The devices work fine, like I said before, I got them communicating and changed settings and what not. I was just a little concerned about this other data that pops up every now and then because the CRC happens to check.
I can solve the problem easy enough with some packet formatting and special characters. But, I was hoping that maybe I am just doing something stupid.
I just read your question. I have a few of these lovely lowcost TRF transceiver devices on my desk, together with the data sheet. I didn’t yet build it together with a MSP430 but I hope that this will happen soon.
Did you try using long address words (40 bits) ? I expect that that has the same effect as adding ‘formatting characters’.
Just reading the data sheet, I think that the following set of parameters will make the most noise-free reception in shockburst mode:
Set address length to 40 bits
Set CRC to 16 bit
Set data rate to 256 kbps
I plan to use it this way. I am curious to your findings!
Hey Marco. From what I have been finding out, this is of course just normal rf noise. It just seemed odd to me for all frequencies to always have that much noise.
I would recommend these to anyone. They are easy to use and work great. As far as my findings, your right, cranking the address helped, the larger CRC helped, and my added encoding has eliminated the problem. I havent really played with the lower data rate because I am trying to keep collision low.
I am working on a wireless mesh network setup. So adding my packet format helped get rid of bogus data. I also preceded the packet with 4 extra characters of my own. 0x00 0xFF 0xAA 0xF0. From watching the noise that was coming through, these four bytes never appeared. Of course I have no scientific evidence that these are the least occurring patterns in noise, but they seem to work for me.
Hope this helps,
Vern
I only have 2 problem with my current setup. The first is that I dont know if I am interrupting an receive when I switch to transmit. So its possible to cut a packet out. Also because of the mesh network is self discovering there are a lot of messages flying around. I would like for the transmitter to wait for a ‘clear’ spot before transmitting. The second problem is that ‘noise’ packets need to be downloaded fully, then marked as noise. It is a waste to have to do that. I now these are asking a lot, but I am going to experiment with direct mode to try and implement these in a dedicated processor.
The receiver will ALWAYS detect incoming RF signals. The sensitivity on the nRF2401 chips (inside the 24G units) is so high, you can look at them funny and get a bit to flip.
But this is a good thing! The nRF2401s can snag good packets out of a horrendously noisy environment. Of course you need some CRC and verification, but that’s par for the course in RF land.
Using 16 bit CRC with 8-bit addresses I get a random valid packet about 1 every couple minutes. So I always transmit the destination address (same 8 bit address taken care of by the hardware) as the first byte in the payload. Compare the first 8 bits of the payload to the address receiver is supposed to be listening for. If they don’t match, the packet is bunk. This has worked great for the SMiRF.
I’ve heard a rumor that increasing the address to 40-bits cuts down drastically on bad packets. Of course it will if you think about it. What are the odds that a good 16-bit CRC packet arrives? - more oft than not given enough time. What are the odds that the packet has the correct 8-bit address? Well pretty decent (I’m no math major - 1 in 256?). What about the odds of a correct 40-bit address? - 1 in 1.1 trillion accord to windows calc.exe.
Trade off time : larger address means less time spent doing checking. But it also means you will have to expend more battery life on every packet transmitted…
Hope this helps a bit. I’d love to hear more about users with the TRF-24G units.
> I only have 2 problem with my current setup. The first is that I dont
know if I am interrupting an receive when I switch to transmit. So its
possible to cut a packet out. Also because of the mesh network is self
discovering there are a lot of messages flying around. I would like for
the transmitter to wait for a ‘clear’ spot before transmitting.
Yes! I was looking for the same thing, and I think it is called a Received Signal Strength Indicator. Using this would make a network node a lot more ‘polite’: it lets the others finish speaking, and then talks. A second benefit would be that you can scan the air for channels where interference levels are lower. BUT just like you I could not find it on the TRF.
Nathan, since there is no RSSI pin, or RSSI register, maybe you can tell us if something useful can be done with the magic bits D143…D136 of the configuration word? (These bits are marked as ‘reserved for testing’… and since we are ‘testing’… we would like to know if they can help us )
> The second problem is that ‘noise’ packets need to be downloaded fully,
then marked as noise. It is a waste to have to do that. I now these are
asking a lot, but I am going to experiment with direct mode to try and
implement these in a dedicated processor.
Wow… I would really first try hard to avoid dedicated error correction hardware/software. Like Nathan mentioned, using long addresses (40 bits) and 16-bit CRC, you keep all processing in the TRF module. But I understand that this is still not good enough for you.
An other idea to increase the reliability of your connection is to add a packet counter, so you can detect if packets were lost, and ask for retransmission. If you keep track of the number of packets that are lost per time period (e.g. each minute), you get an indication of the ‘quality of service’ on the channel.
Maybe you can automatically retry the connection on a different channel if the number of lost packets after one minute is too high.
Hey I am thinking of an other thing… Did you really keep the module’s antenna away from metal? E.g. when mounting the module on a pcb, you must make sure that there is no groundplane or traces under the antenna.
I’m flattered that you think I have any knowledge of the ‘Reserved for testing’ bits. You’d have to ask Nordic Semi - I merely read the datasheet as you do.
I like the idea of monitoring the channel for bad packets. If you take a look at the SMiRF code you see a variable called lost_packets. This variable gets incremented every time a packet transmit fails. A packet is re-transmitted (an abitrary) 30 times before the transmitter gives up. A packet is transmitted, and the remote must respond with a ‘Yes, I got it’ packet. If it does not after 30 tries, the transmitter bails and lost_packets increments by one.
By monitoring lost_packets, you could easily do a channel jump. The problem is this: if the current channel noisy enough that you need to jump channels, then it may be so noisy that the remote never gets the ‘jump to channel x’ command. Hence, you’re stuck on the bad channel. Of course there are ways around this - Blue Tooth and 802.11 obviously have a means to accomplish this. But I had to stop somewhere with the SMiRF firmware so I could get it out there.
I was thinking about adding an SMA conector to the next SMiRF revision. We are currently moving away from the packaged TRF-24G units and implementing the chipset directly onto the board with our own etched antenna. It’s all very new to me, but I can only assume people would want the option to add their own antenna.
One final question : once you guys get up and running passing packets back and forth, can you tell me what your transmit time is?
The specs are: Time on Air (Toa) = 1/ datarate * (#databits + 1)
Toa = 1/1mbps * (7*8 + 1) = 57us (for the 7 byte payload on the SMiRF). I was getting something like 10 times this amount - 600us. I don’t know what the problem was but it will definitely effect the very-low power systems we are trying to build. Every 1ms we have to keep the nRF chip on is lost battery life.
I suppose that the pre-amble and CRC also take time to transmit, so the time-on-air formula is not completely correct. The guys at nordic should be able to tell you the correct formula.
Hey guys. Glad to see a bunch of discussion on these things.
Nathan:
One final question : once you guys get up and running passing packets back and forth, can you tell me what your transmit time is?
I will let you know what my formula is (I am out of town this weekend). I ran into the same problem you did, the data sheet is not correct. I cut mine to the hairy edge.
I have everything working great now. Lost packets is built into my protocol that I based off Mitre’s stuff.
No more noise problems really, but I would still like the transmitter to be “polite”. Guess we cant have it all.
Nathan:
We are currently moving away from the packaged TRF-24G units and implementing the chipset directly onto the board with our own etched antenna.
This is my ultimate goal also, it doesnt really seem like it is going to be that big of a problem. What have been some of your pitfalls so far? Mine is definately going to be antenna design. I would also like an etched antenna, but unfortunately that area is far from my strong point. I am a digital design and software guy. I also noticed on the Laipac module there is an epoxy spill near one edge. The Laipac website picture doesnt show this. Any ideas whats hiding under there?
I’ve done a lot of research into these things. I’ve got two functional layouts. I can offer all I know.
If you cut off the cover, you’ll see their website in the soldermask ‘RF.NET.TW’. Not a great website, but atleast we know where the came from now…
Oh, and they scratch off all the nRF2401 chips. WTF? Who does that?!? The only way I found out the chip type is because a sales rep for Nordic Semi contacted us and said ‘Hey, I think you’re using our chip!’. What an odd world.
So Wenshing is using basically using the nordic semi’s example layout. Not the one in the nRF2401 datasheet, but in the application note. Why? Because it uses like 4 less components. Whoopie. So the range is going to be slightly shorter because the impedance matching network is not as great. But food for thought:
My first design used the Nordic Semi Datasheet recommendation. L1-L4, etc. My layout was pretty crumby. Parts on the bottom of the board. I used long traces because I didn’t know any better (4-5mm between components). I even used a 1/4 wave 30awg wire wrap wire antenna. To my surprise, the darned thing worked! Worked like 30 feet too! But this is important. It was not as good as the TRF-24G etched antenna. So then I switched to a 1/2 wave. Same results. So then I cut the antenna off. Same results. What did this tell me? My board was so horrendous that the entire thing was just emitting RF energy. BUT, the correct data was getting back to the receiver setup - cool!
So the second layout was MUCH tighter. Much finer. I used the Nordic application example, less components. I read up on all the ground plane stuff, adjusted my auto router (yep, it’s an auto routed RF no-no design), and tried out my second design. No go. Didn’t work. I populated three boards (0603, QFN mind you) and spent a day debugging the darned thing. To much avail and pain, I discovered my new oscillator was junk. I thought using a $0.40 SMD tiny CERAMIC RESONATOR was a good thing. +/-0.5% sounds great right? It was the problem. Scraping the thing off and jimming the first designs huge quartz oscillator on there did the trick. I’ve now migrated to a +/-20ppm 16MHz SMD cystal from Abracon. $0.67 is not too shabby!
My second design used an 18x1.5mm etched antenna. Works great! (once I dumped the crumby resonator). I can get it to work almost as good as the TRF-24G unit but for a fraction of the price/size. It works three floors away (in my house), runs off a 3V lithium coin cell, and the entire circuit currently draws 500uA at 10Hz update rate.
If you were really brave, you could incorporate some of the inductors into traces like Wenshing does near the etched antenna. I think you would need high-end network analyzers to test everything. I just go with what works.
If you do time division multiplexing, there is no limit to the number of units. BUT the overall data rate is shared between the units.
If you do frequency division multiplexing, the number of channels, combined with the Rx rejection for adjacent channels, and the maximum range, gives you the number of units.
The overall datarate is much higher in this situation.
If you decrease Tx power, the range is shorter, but interference with other channels should also be lower.
I’m working on a similar project and coming across similar issues
Vern wrote:
I only have 2 problem with my current setup. The first is that I dont
know if I am interrupting an receive when I switch to transmit. So its
possible to cut a packet out. Also because of the mesh network is self
discovering there are a lot of messages flying around. I would like for
the transmitter to wait for a ‘clear’ spot before transmitting.
Firstly what I have is a state machine running (SEND, RECEIVE or SLEEP)
My program is interrupt driven and when a timer overflows I change state to SEND, but the state machine still executes the state it is in. i.e. No packets are cut out by the change. To change to receive I use external interrupts as I am using Shockburst mode.
About waiting for a clear spot. I have’nt actually implemented anything to do this yet. But have you thought about have a Request to Send (RTS) and Clear to Send(CTS) strcuture. basically when a node wants to send, it sends a small RTS packet to the other node, which replies with an short CTS message. All other nodes can see these messages and know then to backoff for a while. Of course there is still a collision problem, but the CTS and RTS packets are very small.
anyway hope this helps, let me know how you get on.
Can u help me configuring my TRF2.4G?? I’m using them with PICs 16F877A and translating the 5V TTL to 3,3V through transistors… I don’t know why but I’m not transmitting… I think I’m using the right configuration word but still DR1 in the Receiver never gets set… I have read some other posts and I’m thinking it could be the speed I’m using through the USART ports (CLK and DATA) , the baud rate is in 9600bps and I think it must be 250kbps… I’m not sure. Plz answer, really need help… I could post my C code if u want
The SFE C code for the 16F88 works OK, you could adapt it quite easily for the 16F877A. It’s easiest to run the whole thing off 3V or so - I used a couple of AA cells for testing.
Hi and thx for your answer. Pardon my ignorance, but what is the SFE C code? or where can I find it? I’m really having trouble with these transceivers and I’m in a little rush due to dead lines…
)
