I've been working on a project which will interface a JeeNode to an AVR connected serially to a wireless router running OpenWrt
I've got the basic RF12Demo sketch running on the JeeNode, which currently just has a thermistor on one of the ports to get some data over, preparing a packet for transfer every 2 seconds and sending it when the air is clear. The problem is that even sitting right next to each other on the table, I don't receive about every 1 in 15 packets. Is that expected?
Sender code is just RF12Demo with this code running every 2 seconds. It relies on the built-in code in loop() to do the send.
cmd = 's';
dest = 1;
++readCnt;
snprintf((char *)testbuf, sizeof(testbuf), "C=%u", readCnt);
sendLen = strlen((char *)testbuf);
Receiver code is pretty basic too:
if (rf12_recvDone())
{
byte n = rf12_len;
if (rf12_crc == 0) {
Serial.print("OK: ");
for (byte i = 0; i < n; ++i)
Serial.print(rf12_data[i]);
Serial.print('\n');
} else {
Serial.print("?\n");
}
}
Is it expected that you will lose some packets, or is it pretty much a sure thing if your code is right and they're sitting right next to each other?
Sounds a bit high, unless your workbench is high energy RF testing zone!
You are running the RFM12B's at their native frequency aren't you?
Yup I just checked. They're both 915MHz modules configured for 915MHz with 82mm antennas.
What speed is your serial connection? I've had problems with serial debugging actually causing a problem because the RFM12 needs very fast responses to the IRQ.
Something which might be worth trying is copying the data out of the RF12's buffer as soon as you get past the recvdone(). Once you have the data copied, and before you start doing the serial comms, call recvdone() again to let the RF12 know you've cleared the data. Then you can get on with reading the data from the second buffer and sending it over the serial link.
This is the loop from the JeePU sketch which implements this technique:
if (rf12_recvDone() && rf12_crc == 0 && rf12_len > 0) { // save msg in buffer and ack right away to keep things going memcpy(doubleBuf, (void*) rf12_data, rf12_len); if (RF12_WANTS_ACK) rf12_sendStart(RF12_ACK_REPLY, 0, 0, 1); rf12_recvDone(); // this may take some time, depending on the command received processmessage(doubleBuf); }doubleBuf is simple defined as byte doubleBuf[66];
For 915 MHz, a 78 mm antenna would be a closer watch - but this is definitely not going to have such a huge impact on range.
Is the send really only sending out every few seconds? Back-to-back packets would explain the occasional loss. Also, it's best to keep calling rf12_recvDone() often, even when sending. IOW, use MilliTimer instead of a delay(2000), if that's what you're doing. Still, I can't quite explain this data loss - odd.
Oh I guess you're right about the antenna length. I forgot to compensate for the velocity constant of a copper wire.
I am certain it is only sending once every 2000ms. It doesn't do a delay it just does
if (millis() - g_LastReading < 2000) return; g_LastReading = millis(); cmd = 's'; dest = 1; ++readCnt; snprintf((char *)testbuf, sizeof(testbuf), "C=%u", readCnt); sendLen = strlen((char *)testbuf);And relies on the code in RF12Demo to do the send for it, which appears to wait for the appropriate clear to send.I'm got the UART on the receiver set to 115200 but I've tried as low as 9600, and the sender is the default 57600.
"call recvdone() again to let the RF12 know you've cleared the data." Iiiii... did not realize this was the case, but I see now that you're right, it only will rf12_recvStart() again once it is called again. I've tried that as well now with the same results. Shouldn't have been an issue though, considering the 2000ms delay between transmissions and the largest loop delay I've been able to measure is under 40ms.
I'm thinking that either the receiver or transmitter is defective in some way, and since the receiver is all custom breadboarded, I'm looking sternly at it.
I appreciate the help because what that tells me is that the dropped packet rate should be way lower than I'm seeing, so there's either a hardware or software problem, not a known loss rate typical of these modules.
When you exhaust all your ideas to decrease the packet loss then try this.
On the left hand side of the RF12b near P4 silkscreen marking count 3 pads down and install a 10K pullup to 3.3 VDC. This pad is pin 9 (FSK input). Note: The pad count numbering is odd. (Refer to the RF12B pdf for clarification) I was told by Hope RF tech support that pulling this pin up will make the module more sensitive and leaving it un-connected will make it less sensitive.
I am keeping my 10K pullups until JeeLabs tells me otherwise. Disclaimer - This is a unauthorized JeeNode RMF12B mod - do it at your own risk.
Ooh good idea. Based on what you've said I found this reference in the data sheet: "Bit el enables the internal data register. If the data register is used the FSK pin must be connected to logic high level"
That to me says in no uncertain terms that this has to be pulled up to VCC, considering the library sets el. I can't wait to check this out when I get home. Thanks!
I hope JCW can chime in on this?
Not much I can say at this point - I haven't tried the pull-up myself yet. Sounds like a good idea, though.
No dice. I still lose about one out of every 20 packets regardless of if the transmitter has the pullup, the receiver has the pullup, or both do. I can say though that on the receiver chip, the interrupt doesn't even fire when I miss a packet (watching from the oscilloscope).
I've got another jeenode and another RFM12B board that just shipped from ModernDevice today so I'll be able to nail down exactly where the problem is. I appreciate all of the suggestions, but if I had to place a bet, I'd say there's something wrong with my implementation on the daughterboard I built.
I'll post back once I get the parts in a couple of days once I've done some experimentation with the new parts and work it out. Thanks again for letting me know this isn't typical.
Quote: regardless of if the transmitter has the pullup, the receiver has the pullup, or both do.
Reply: Just pin 9 (FSK) needs only to be pulled up? What pin(s) are you pulling up?
I think he means he tried the pull up on the sending RFM12B, on the receiving one, and on both.
It's always a bit tricky to know which end has the issue when you only have two, so hopefully he'll be able to get to the bottom of it when he receives the new boards.
I'm not quite sure how you could go wrong with the wiring, I would expect it to either work, or not work. Only thing that comes to mind is the power. CapnBry, I assume you've got a nice regulated 3.3v supply to the ATmega and RFM12B? The RFM12B does do some odd things are you start to approach the upper end of it's operating range or if the supply isn't completely clean.
JC told me of one that he connected to 5v by mistake, and it still worked properly, but that's well out of spec and not the norm. I have one here I can clock at 4Mhz on the SPI without issue, when 3.5Mhz is supposed to be the limit, but it does weird things at anything over 4 volts.
TankSlappa is right. I meant a resistor on the FSK pin on the transmitting RFM12B module or receiving RFM12B module.
The power supply on my custom design is a 3.3V 160KHz synchronous buck converter that feeds into a 330uF electrolytic and a 0.1uF ceramic. The RFM12B itself I've installed another 0.1uF ceramic as a decoupling cap to see if that was the problem but no luck there either (not to mention the module has its own 6.8nF power cap). I'm reading 3.37V +/-0.03 which seems pretty good to me.
The wiring maybe I got right but who knows, maybe I've loosened a surface mount component on the board while attaching wires to the back of it.
The power supply sounds pretty damn good to me... Pity, it would have been an easy fix :-)
If you have managed to loosen a component on the RFM12B whilst soldering, and created an intermittent fault, I salute you, I've only ever managed to totally destroy them with too much soldering, and that was when I was trying (against advice) to remove one from a JeeNode.
Welp, I got my new jeenode in the mail today and 5 songs later I had it all soldered up. Uploaded my code to it and swapped it out with the other jeenode and I've seen the last 1000 packets go through with 0 missing.
I went over my soldering job on broken jeenode #1 and everything looks perfect, and all the surface mount components on the RFM12B look intact so I don't know what is wrong with it but I'll get back to it later and see what is up. Interestingly, if I set its ID to match the receiver it misses packets the other receiver gets and then after a while it just stops receiving. Clearly it is broke broke. FYI the receiver still has the 10k pullup, the transmitter does not.
I appreciate all the suggestions but there's my answer: on the same table, you really shouldn't lose any packets between two nodes.
Hi guys,
As per JC's weblog post, I've done a bit of testing both with and without the 10K pull up, and there is no noticeable difference either way.
I can't find any examples of an RFM12B requiring a 10K pull up on the net. The RFM12 (non-B) certainly did require one, but not the B revision. JC blogged about this back in May 2009. My testing of the RFM12B backs this up. The pull up made no difference in received signal in any of my tests, be it areas of 90% reception or far more marginal 20% (I pushing the data rate up to 114kbs for my tests to decrease the range and make the RFM12B more susceptible to interference.
TankSlappa quote
"As per JC's weblog post, I've done a bit of testing both with and without the 10K pull up, and there is no noticeable difference either way."
Reply: Good that your testing did not find any "noticeable" difference either way BUT when there are docs that shows it is needed and Hope RF tech support also said it was needed (they built the RFM12B chip) then I have to go with Hope RF. (see ref. below)
All JCW has to do is to contact Hope RF and settle this issue once and for all and post what Hope RF tech support has to say on this matter. In the mean time, I will still keep my 10K pullup until instructed otherwise.
References
@CapnBry Ooh good idea. Based on what you've said I found this reference in the data sheet: "Bit el enables the internal data register. If the data register is used the FSK pin must be connected to logic high level" That to me says in no uncertain terms that this has to be pulled up to VCC, considering the library sets el.
@Hope RF Tech support
Question #1 If I am only using the SPI interface should pin 9 (FSK) be pulled up to VCC via 10K ?
It can increase the module's sensitivity if FSK/DATA pin is connected to 10K pull-up resistor.
Question #2 What happens if this input is not pulled up?
The sensitivity will decrease.
On the Hope RF12B pdf V1.2 shows a demo schematic for a PIC to RF12B. They show pin 9 (FSK) being pulled up via 10k. This connection is not being used on the JeeNode and should be also be pulled up to VDD?
Well I can only report my findings, it made no noticeable difference. My hand holding the test receiver box made a noticeable difference. The resistor did not.
Maybe things might be different with the 915Mhz module, I have no way of knowing, as I'm in the UK and I have 868Mhz modules.
I read the weblog post today and as soon as I got home I loaded the TX anr RX sketches and I'm getting some really strange results.
With just the RX pwered up (no TX) I get 5s marching along for about 10 secs then the display resets to xxxxxx and starts again.
With the TX powered up I get varying results from 0%/5S to 30%/5S but mostly 0% and it still seems to reset every 10 seconds.
Both Jeenodes have been used for other non TX/RX related jobs and worked fine.
The count on the lower left rarely displays anything other than xxx.
The TX and RX jeenodes are about 200mm apart.
If you have 915 MHz units, then you'll need to adjust both sketches to run at 915 MHz as well. Could that be it?
The resets are very odd, I have no idea what's happening...
Thanks, I've got 868MHz.
I think I've found the problem.
I run the Jeenodes off these
http://gadjetsblog.blogspot.com/2011/04/5v-from-3v-with-energizer.html
I think that there is possibly noise, maybe conducted interference, that interferes with the RF side of things, when I wired up the receiver to 3 AAs in a holder then everything started working fine, 100%.
Maybe these inverters, used for charging phones, are a bit noisy!
Ah - glad that's solved.
Nice weblog, btw!
Thanks, not as many visitors as yours though.
I took some scope traces of the 3.3V supply when running with the inverter and this is what I found: -
Every few seconds I would get these fast spikes for a couple of seconds - Supply_noise_fast.png
And less often I would get Supply_noise_slow.png, I think this is what causes the reset.
I think its AA batteries from now on or maybe a couple of the Jeelabs AA boards!
Interesting, but nasty!
Time to deploy a bit of inductance and a bit more capacitance me thinks!
Hello jcw, I am using wire (copper without insulated) antenna @868 Mhz wire length 82.3 mm , it hardly support 5-7 meters distance, If more than 8 meters it is lossing the packets . I am using new 3x AA battery. I might wrong when i am selecting the coax cable, does any one using telescopic or whip antenna.
Thanks and Regards, Pravas
The wire is essentially a whip antenna for these frequencies, which are much higher than public radio broadcasts.
Have you set both units to 868 MHz? Your range really is way off - there must be something wrong.
yes both node are set to D i4 g212 @ 868 MHz and E i5 g212 @ 868 MHz I am not confident about cable is 50 ohm impedence. within the one meter distance it is working fine.
Hi, Although this thread is a bit old and problem seems to be solved: Having worked with the RFM12 modules myself for quite some time, I was surprised finding the FSK/nFFS pin floating in the JeeNode designs. As the JeeNodes use the RFM12"B" variant and I was using plain old 5V RFM12s, I did some datasheet comparison. And voila - this is one of the improvements in the "B" variant: "• FSK / nFFS input are equipped with internal pull-up resistor. To achieve minimum current consumption do not pull this input to logic low in sleep mod" [from http://www.hoperf.com/upload/rf/RFM12B.pdf, page 16]
For me this means the RFM12"B" does not require the external FSK/nFFS pull-up which was mandatory for the older RFM12. Hope this clears jcw from any sneaking suspicion not connecting FSK/nFFS pin could be a layout bug.
Cheers bitschubser
Thx - see also this older post: http://jeelabs.org/2009/05/06/rfm12-vs-rfm12b-revisited/