Adapter board RFM69W radio for Teensy 3- Also diagnostic software...

Status
Not open for further replies.

stevech

Well-known member
Adapter board RFM69W radio for Teensy 3- A how-to build and use. See PDF file enclosed.

Also diagnostic software for RFM69 on Teensy 3 with OSH Park adapter board designed and shared-out by PJRC. Diagnostic also runs on AVR mega32, e.g., Anarduino's miniwireless.
Diagnostic software is small program to help bring-up RFM69 -or- RFM22 on Teensy 3 or Mega32.
Diagnostic is small, straightforward. Uses RadioHead library - just download the library and store in the Arduino main library folder. No changes to it needed for either radio type or either MCU type.
The diagnostic checks SPI and interrupts and uses the raw packet mode of RadioHead - none of RH's protocol options are used, to simplify the diagnostic and hardware checking.

Steve

Edit: Replaced 1st version of PDF enclosure
 

Attachments

  • README.txt
    124 bytes · Views: 476
  • RFMxx_diagnostic.ino
    4.4 KB · Views: 483
  • Teensy3 RFM69_OSH plus RFM69-RFM22 diag softw.pdf
    1.3 MB · Views: 6,189
Last edited:
Very well done tutorial! Thanks!
I am assuming that this also is going to work on a Teensy 3 and not just the 3.1
 
Yes, I've run it on the Teensy 3.
Mike of RadioHead has run it on the RFM22.

Thanks

What I don't know is how long it takes Osh Parks to run more boards. I just ordered and waited like 3 weeks for them to do a run of some panels. So someone else is ordering them too, I guess.
 
Does anyone know any good analog transmitter/receiver boards or chips that work in these same ranges (433 MHz and above)? Something similar to what's used in baby monitors or wireless microphones.
 
The RFM22 has a mode and input to take an arbitrary signal and transmit it as FM. And vice-versa. I haven't used it, but you might read the data sheet and see if it'll do. These radios are up to 100mW, lots of range. And $4.

But an analog signal in 433MHz and the 902-928MHz band may not be permitted in your regulatory region as unlicensed. My amateur radio license (US) allows these radios to be used in the 70cm and 900MHz bands without restrictions.

A high transmitter-on time, near 433MHz, jams out the two wireless thermometers in our house, hence the regulations. Most garage door openers are at 315MHz.

see enclosed data sheet. -- OOPS, PDF is 5MB and this forum won't allow that large. So you'll have to look for the RFM22 spec at HopeRF.com (It's a SiLabs chip).
 

Attachments

  • RFM69W-V1.0.pdf
    1.1 MB · Views: 809
Last edited:
I've been working with the RFM69 and Ethernet for the last few days, and I've run into a lot of problems where SPI activity from Ethernet interferes with the RFM69's ability to receive.

At this point, I'm still not sure exactly what's causing the trouble, but today I built a digital circuit to force the SCK signal low when the RFM69 chip select is high. Somehow, that makes things start working! Here's a more detailed explanation.

http://www.dorkbotpdx.org/blog/paul/rfm69_wireless_spi_bus_sharing_feedback_wanted

I'm really starting to wonder if the RFM69 has some sort of hardware issue, where SCK activity while NSS is inactive causes trouble?
 
I've been working with the RFM69 and Ethernet for the last few days, and I've run into a lot of problems where SPI activity from Ethernet interferes with the RFM69's ability to receive.

At this point, I'm still not sure exactly what's causing the trouble, but today I built a digital circuit to force the SCK signal low when the RFM69 chip select is high. Somehow, that makes things start working! Here's a more detailed explanation.

http://www.dorkbotpdx.org/blog/paul/rfm69_wireless_spi_bus_sharing_feedback_wanted

I'm really starting to wonder if the RFM69 has some sort of hardware issue, where SCK activity while NSS is inactive causes trouble?

The Anarduino boards have an SPI flash chip on them. They've been used extensively with SPI Flash chip I/O, I've been told. I will soon be doing that in my own software for those boards. At the moment, the RFM69/RFM22 are used by my software to run RadioHead protocols and send reprogramming data files (binary versions of .hex files).
The RFM69 (HopeRF) uses the radio chip of Semtech: SX1231. It's been out since 2009.
http://www.semtech.com/wireless-rf/rf-transceivers/sx1231h/

I plan to put the radio in idle mode during flash chip I/O so that the radio cannot interrupt and conflict in the ISR with the use of the SPI port.

I'll keep an eye out for this - but I doubt it's an issue due to the size of the installed base of Anarduino Miniwireless (many 100's, he says). But this is the mega328P, not a USB AVR, or a Teensy, if that would matter.
RadioHead gets an interrupt at transmit complete and receive complete, on the RFM69. On the RFM22, interrupts can be more frequent due to FIFO refilling on the fly. Not done with the RFM69.

For now, sans SPI management, just be sure the radio is in idle mode before using some other SPI device, if you're using RadioHead or any other software that uses interrupts from the RFM69.
 
Last edited:
Yes, today, making sure the radio is idle is the safe approach.

But of course I'm interested in exactly the opposite. I'm seeking examples or applications that have needed to use both simultaneously. I'd really like to get to the bottom of whether this strange problem is a bug somewhere in my code, or a genuine limitation of the RFM69 hardware.
 
Paul, I tried the below and did not get anomalies.
I don't have a ready to go ethernet device for the T3 - I do have some wiznet 812MJ modules but I'd have to breadboard wire one to the Teensy 3.
So here's what I did..
I have two very large/complex programs for the RadioHead stack and thus it does run the RFM69W.
One program is a throughput tester/logger for a pair of RadioHead compatible radios - called pingpong. It is also a passive packet sniffer at the RF level. Displays packets, ACKs, from/to, etc.
It has an interactive command line so one can reconfigure the radio(s) on the fly.
I added to it a PJRCSPI test command.

So, I have a Teensy 3.1 with the Osh board and an RFM69W running the program above.
It's exchanging packets with an Anarduino mega32P based board with an RFM69W. Also running the same software as above.
Both using 8MHz SPI clock. The T3 is using Teensyduino's SPI emulator code, unchanged.

I run, they exchanges zillions of packets, like 5 or 10 per seconds times 2 for ACKs. All's fine.
Then, on the T3 board I enter through the serial terminal the command 'PJRCSPI'
This causes the following code, added to handle that command, to run:
Code:
else if (strncmp(text, p = "PJRCSPI", 7) == 0) {
	Serial.println(F("PJRCSPI receiver to idle; SPI transfers; reenable receiver"));
	driver.setMode(RHGenericDriver::RHModeIdle);
	delay(5000);
	for (int i = 0; i < 100; i++)  {
		SPI.transfer(0); // no chip select on
		delayMicroseconds(10);
	}
	delay(100);
	protocol.available(); // reenable receiver
}
So this puts the radio in idle mode so its ISR cannot be invoked because the receiver is disabled. This avoids SPI port contention collisions.
The for() loop does dummy SPI transfers to cause SCK to pulse a great deal while the radio's SS/Chip select is false.
Then the available() call reenables the receiver by sending the radio a mode change command via SPI.

Now I see that the T3's radio resume normal operation. It resumes exchanging packets with the Anarduino board.

I looked at the SCK with a scope. I did a single-sweep during the 5 second delay in the code. The long batch of SCK clocks do show on the scope.


Conclusion
So though I didn't do exchanges with the ethernet board, I did pulse SCK a lot and it didn't cause the RFM69 to require reset/reboot and reconfigure.

I hope this helps a bit.
I can try other tests that you might suggest, and can provide you with the RFM69 modulation mode vs. throughput test program as a .hex or source (but the source is quite large).
The radios I use are for the 433MHz band. You are using 900MHz. The SX1231 chip used on the RFM69 board is identical for these two bands - just some outboard L/C filters differ.

It is possible that this is chip rev. number specific. The SX1231 I used is marked (HopeRF branding):
RFM69
1337
W?938.00 where ? is illegible
I'd be surprised if there are SPI interface changes; most changes are in the RF sections.



steve
 
Steve, do you have any source code I can copy into Arduino and run?

I modified my test to not use Ethernet at all. It simply sends a 0x00 byte on the SPI (no device connected), then calls RadioHead rf69.recv(buf, &len), until either a reply is received or a 40 ms timeout. Normal reception takes only 3 ms.

The other board running rf69_server blinks, so I'm sure the other radio is receiving the request and sending a reply.

With the 4 SPI signals connected directly to the RFM69W, it fails. With the NOR gate circuit, the RFM69W receives the response.

Here's the full test code. Just copy into Arduino. I'm building with this SPI and this RadioHead.

Code:
#include <SPI.h>
#include <RH_RF69.h>

// comment this out to make things work...
#define DO_OTHER_SPI_ACTIVITY

RH_RF69 rf69(15, 16);

void setup()
{
        pinMode(10, OUTPUT);
        digitalWrite(10, HIGH);
        pinMode(15, INPUT_PULLUP);
        delay(100);
        Serial.begin(9600);
        while (!Serial) ;
        delay(100);
        Serial.println("RF69 & Ethernet Test Begin");
        if (!rf69.init()) {
                Serial.println("RF69 init failed");
                while (1);
        }
        // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
        // No encryption
        if (!rf69.setFrequency(915.0)) {
                Serial.println("RF69 setFrequency failed");
                while (1);
        }
        Serial.println("RF69 init ok");
        // If you are using a high power RF69, you *must* set a Tx power in the
        // range 14 to 20 like this:
        //rf69.setTxPower(14);
        // The encryption key has to be the same as the one in the server
        uint8_t key[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
                0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
        rf69.setEncryptionKey(key);
        delay(100);
}


void loop()
{
        uint8_t buf[RH_RF69_MAX_MESSAGE_LEN];
        uint8_t page[1024];
        int page_index;
        bool doingradio = true;
        elapsedMillis msec;
        uint32_t prevdot=0;
        uint32_t preveth=0;

        Serial.println("---------------------------------------------------");
        Serial.println("Sending to rf69_server");
        // Send a message to rf69_server
        uint8_t data[] = "Hello World!";
        rf69.send(data, sizeof(data));
        Serial.println();
        Serial.println("waiting rf69 send");
        rf69.waitPacketSent();
        Serial.println("rf69 sent");

        msec = 0;
        doingradio = true;
        while (doingradio && msec < 30) {
#ifdef DO_OTHER_SPI_ACTIVITY
                SPI.beginTransaction(SPISettings(12000000, MSBFIRST, SPI_MODE0));
                digitalWrite(10, LOW);
                SPI.transfer(0x00);
                digitalWrite(10, HIGH);
                SPI.endTransaction();
#endif
                if (doingradio) {
                        uint8_t len = sizeof(buf);
                        if (rf69.recv(buf, &len)) {
                                Serial.print("RF69: got reply in ");
                                Serial.print(msec);
                                Serial.print(" ms, len=");
                                Serial.print(len);
                                if (len > 0) {
                                        Serial.print(": \"");
                                        Serial.write(buf, len);
                                        Serial.print("\"");
                                }
                                Serial.println();
                                doingradio = false;
                        }
                }
        }
        if (doingradio) {
                Serial.println();
                Serial.println("ERROR: radio did not receive reply");
        }
        delay(1000);
}
 
The weird thing is sometimes, maybe 1 in every 5 to 10 tries, the RFM69 does hear the reply. When I comment out "DO_OTHER_SPI_ACTIVITY", all replies are heard. I have the 2 boards and their wire antennas only about 6 inches apart on my desk.

The good news is the SPI transaction code appears to be working. Here's a scope screenshot.

attachment.php


The blue trace is the RFM69 interrupt. Here you can see it requested the interrupt while the DO_OTHER_SPI_ACTIVITY code has its chip select asserted. That SPI code in loop() was able to complete and de-assert pin 10. Then RadioHead asserts its chip select (yellow trace) and begins SPI communication with the RFM69. RadioHead configures a slow SPI clock, and you can see each section of code is getting its requested clock speed.

At this point, I believe I'm going to stop working with the RFM69, and at least for now conclude there's some sort of hardware problem with this chip, unless someone sends me a test case.
 

Attachments

  • file4.png
    file4.png
    40 KB · Views: 4,428
RadioHead's SPI clock is configurable.. I use 8MHz. You may have taken the default for the RadioHead class constructor which is 1MHz.

Do you want my code? All I'm doing is disabling the receiver via a mode change, so that the SPI port can be used for other purposes. Avoids the condition. That's simple, and is what I plan to use until shared SPI is mature.

Versus what I sent you, above, the difference seems to be that I did the SPI transfers without an interrupt request pending from the chip. I can do that in the sample code snippet I sent above - I think, by forcing the added condition that the RFM69's interrupt request is true but not taken, when the SCKs occur, and with CS false. If you like, I/we can try this by transmitting something with the radio, which leads to an interrupt request, and arrange to have the pin interrupt disabled. As you've done, but in a simpler case. It would seem that the radio or any other SPI device just sits with the interrupt request on, waiting for CS to go true.

Odds are this isn't a chip bug, due to it being in widespread use since 2009. But, stranger things have happened.

Here's one thought though.. Mike of RadioHead setup his radio driver for the RH69 to trigger on the RISING edge of the interrupt. I would have used "HIGH" rather than "RISING" - as RISING relies on the K20 chip to latch the rising edge and keep it pending, even if the interrupt is masked. By using HIGH instead, I'd worry less about adding complexity to how the interrupt hardware in the K20 works, with masking and unmasking while a race condition might happen with RISING. Or not.
 
Last edited:
RadioHead's SPI clock is configurable.. I use 8MHz. You may have taken the default for the RadioHead class constructor which is 1MHz.

I've been using RadioHead's default. Do you believe 1 MHz vs 8 MHz makes any difference?

Do you want my code? All I'm doing is disabling the receiver via a mode change, so that the SPI port can be used for other purposes. Avoids the condition.

No, I don't want *that* code. My goal is not to build one project that works, using workarounds.

My goal is to build a platform that always works and never needs any workarounds. So the code I want is some "proven" application or example that does simultaneous SPI usage in a way that doesn't mess up the RFM69's ability to receive messages.

I currently have a hardware workaround for what's starting to look more and more like a hardware bug in the chip. I don't want ANY workarounds. This still could be a bug in my code. If there is ANY code which does significant SPI activity while the RFM69 would receive over the air, and it works, then that would prove the hardware works fine. If any such code exists, I want it!

However, it's also quite possible most people have written fairly simple applications that don't talk to other SPI chips (or don't do it with any significant duty cycle) during the time the RFM69 is expected to receive over the air. It's quite possible the small percentage of people who may have tried to build such programs encountered problems and used workarounds, much like you're doing, because all they wanted was to get their single project working.

I'm building a platform for everyone, not a single project for myself. I want to truly get to the bottom of these problems and eliminate the need for workarounds. That's why I want want to find any existing code (if any exists) which does other SPI activity while the RFM69 receives.

Odds are this isn't a chip bug, due to it being in widespread use since 2009. But, stranger things have happened.

This is really starting to look like one of those stranger things. That's why I'm hoping to find ANY code that anyone has used with these modules which talks to another SPI device while the module might receive incoming data over the air. Has anyone written and published such code?

Look at my code on reply #12. All it does is repetitively call rf69.recv(). If that extra code is added, which merely does SPI.transfer(0) while the RFM69 isn't selected, the RFM69 will usually not generate any interrupt when the other radio sends a message.

Running that same exact code with the logic gate circuit to force SCK low at the RFM69 makes it work. That's really starting to look like a hardware bug in the RFM69.


Here's one thought though.. Mike of RadioHead setup his radio driver for the RH69 to trigger on the RISING edge of the interrupt. I would have used "HIGH" rather than "RISING" - as RISING relies on the K20 chip to latch the rising edge and keep it pending, even if the interrupt is masked. By using HIGH instead, I'd worry less about adding complexity to how the interrupt hardware in the K20 works, with masking and unmasking while a race condition might happen with RISING. Or not.

Interrupt edge detection is very reliable. It's implemented in hardware on both AVR and ARM, with proper pending bits that cause the interrupt to later be service if the edge occurs while interrupts are masked or disabled.

But in this case, the RFM69 clearly is not raising the signal at all, so HIGH vs RISING would may no difference. It stays low the entire time when the problem occurs. HIGH might be better than RISING in other cases (or it might be worse), but in this case, neither would do any good, since the scope clearly shows the signal is staying low the entire time.
 
Last edited:
I doubt 1 vs. 8MHz affects anything, unless some chip specs re setup time or some such, but 1MHz would not be worst case of course.

Offering of code... Offered not for the work-around, but as tool you might use or adapt, for testing.


do you mean that the radio's interrupt request was prematurely taken false by the radio? I apologize, but could you please clarify what doesn't work correctly with the transaction test? Post #13 shows the interrupt request true (a logical 1 at the I/O bit). (Many of the other radios have a logic 0 for interrupt==true).

As to edge detection for interrupts... I recall LPC2106/ARM early versions had a bug w/errata on conditions where the interrupt was lost, along the lines of - if triggering on rising edge and the port bit enable was toggled while the bit was changing to the opposite state.. etc. If you wish to try to see if it affects anything, the RISING could be changed to HIGH easily. May not cure, but simple to test. It's line #85 in RFM69.cpp.

Also, please know that for me, and others, most of the higher speed radio configs of the RFM69 cause a packet error rate far too high. And some modulation orders don't work at all. We hope these are just errors in the config coding tables in RFM69.cpp and .h.
4800bps in a 5KHz channel is most often used in operational settings. Using reliable datagrams (error corrections via ACKs and retransmissions), 9600bps and a bit higher work OK. The RFM22 radios (different silicon vendor) didn't have this problem. So I suggest keeping this failure to receive packets even at ideal signal strengths - separate from the SPI symptoms. Perhaps the anomalies you see with radio operation aren't showing this symptom. I recommend that you add a line of code to change from the RFM69's default modulation enumeration of 250Kbps to 4800bps just to take that possibility out of the picture - if you observe packet exchanges as a measure of proper operation.
In the example: rf69_reliable_datagram_clinet.pde in setup() you can add
Code:
manager.setModemConfig(RH_RF69::FSK_Rb4_8Fd4_8);    // which is the value: 3
for the conservative 4800bps. Or alter the class instance params to specify the above.


Sometime next week I will try to reproduce what you've seen. I need a couple of days to get to a milestone on current work.

Regards,
Steve
 
Last edited:
could you please clarify what doesn't work correctly with the transaction test?

If you run the code from reply #12, with another board running the rf69_server example within close range, it works perfectly when DO_OTHER_SPI_ACTIVITY is commented out. In that case, it's pretty much the same as RadioHead's rf69_client example.

Adding the DO_OTHER_SPI_ACTIVITY causes it to send a single byte on the SPI bus between each call to rf69.recv(). You don't actually need any other SPI chip connected. It just transmits an extra byte on the bus that isn't heard by any chip. The RFM69 should ignore it, since its chip select is high (inactive) while that byte is sent.

But if you run this test, you'll see that extra SPI activity impacts the RFM69 pretty hard. It rarely receives data. If you watch the SPI with a scope or logic analyzer, you'll see the RFM69 generates 2 interrupts in the working case, one which indicates transmit complete, the other indicates data reception. In the DO_OTHER_SPI_ACTIVITY, the RFM69 simply does not raise the pin again for reception. It's not a matter of the SPI communication failing to read the data, because the RFM69 simply never generates the 2nd interrupt to tell RadioHead to read the data.

Post #13 shows the interrupt request true (a logical 1 at the I/O bit). (Many of the other radios have a logic 0 for interrupt==true).

RadioHead uses attachInterrupt(interruptNumber, isr0, RISING); in RH_RF69.cpp, near line 100. I didn't write this library. I do not know why Mike used RISING instead of FALLING.

As to edge detection for interrupts... I recall LPC2106/ARM early versions had a bug w/errata on conditions where the interrupt was lost

Freescale's chip does not have this errata.

Even if it did, watching with an oscilloscope clearly shows the RFM69 isn't sending a rising edge when the data should be received, in the case where DO_OTHER_SPI_ACTIVITY is used.

Also, please know that for me, and others, most of the higher speed radio configs of the RFM69 cause a packet error rate far too high. And some modulation orders don't work at all. We hope these are just errors in the config coding tables in RFM69.cpp and .h.
4800bps in a 5KHz channel is most often used in operational settings. Using reliable datagrams (error corrections via ACKs and retransmissions), 9600bps and a bit higher work OK. The RFM22 radios (different silicon vendor) didn't have this problem. So I suggest keeping this failure to receive packets even at ideal signal strengths - separate from the SPI symptoms. Perhaps the anomalies you see with radio operation aren't showing this symptom.

None of the pages selling RFM69 modules or products mention this!!!

I'll give this a try when I use the RFM69 again. Unless you or someone else sends me a test case or other really useful info, I'm setting the RFM69 stuff aside for a few days.

My ultimate goal is improving the SPI library. I've spent the last 5 days digging into the RFM69 problem. At this point, I've pretty throughly investigated what the software and hardware are doing.

Unless you or someone else sends me a new test case or other useful info, I really don't see how pouring more time into the RFM69 and RadioHead is going to be useful for wrapping up this work on SPI transactions.
 
RadioHead uses attachInterrupt(interruptNumber, isr0, RISING); in RH_RF69.cpp, near line 100. I didn't write this library. I do not know why Mike used RISING instead of FALLING.
Indeed. I had suggested that instead of RISING, using HIGH would lessen the chance of issues. FALLING wouldn't work, as the interrupt service has to be triggered when the request goes HIGH, in order for the ISR to run, at which time it will read the status thus causing the interrupt request to be set false (LOW). Changing this is grasping at straws, indeed. But simple to try, in a process of elimination of causes.
 
Very interesting discussion. I am starting to implement an nRF24L01+ 2.4 GHz radio add-on for Teensy 3.1 and I expect to encounter many of these same issues. I'm glad you guys are blazing the path!
 
Paul... Today I beat the bureaucracies at HopeRF and Semtech and got to a very smart and cooperative guy at Semtech (chip vendor for the RFM69 of HopeRF, chip is SX2131.) He provided good software tool to help us in the radio configuration issue to hopefully correct the modulation modes that don't work, and ones with high packet error rates, in RH.

He and I also discussed if there is errata on the chip, and if anyone has seen an issue as you've seen. He said not, but he would inquire around and see if anyone has heard of such, in the 7 years the chip has been produced for many applications. Should hear back in a few days.
 
Very interesting discussion. I am starting to implement an nRF24L01+ 2.4 GHz radio add-on for Teensy 3.1 and I expect to encounter many of these same issues. I'm glad you guys are blazing the path!

If you read the threads on the RadioHead forum, you'll see people complaining that the really-cheap Nordic nRF's lack RSSI reporting (received signal strength). That's a deal buster for many wirless uses cases. I'd say the lack means it isn't practical for multiple node networks, and no RSSI means you need few nodes, excess signal strength, and so on. And 2.4GHz has the big propagation loss (from physics) versus the sub-GHz radios that most of us are concentrated on for low volume data networking. Compounded by the low power of the Nordic chips. But it can work for some situaitions.
This is why most are using 868MHz (EU) and 902-928MHz (No. America) and the 433MHz band in most countries. Also, the 433MHz radios tune to the 70cm Ham band and were restrictions are few, if you are licensed.

so If this is a new start, I urge you to take a second look. I've been using the Anarduino Miniwireless boards for AVR, and with RadioHead. And the same RadioHead stacks run on the Teensy 2, and Teeny 3 with a variety of radio types, and RadioHead's stack of optional protocols. Osh Park offers a PCB permitting the RFM69 modules to mate with a Teensy 3.

This thread on PJRC is about the thrust to get to a managed shared-SPI port no matter radios or whatever the SPI devices are.
 
This thread on PJRC is about the thrust to get to a managed shared-SPI port no matter radios or whatever the SPI devices are.

This what is interesting to me since I expect collisions between the radio and SD card reader and/or bluetooth and all of which "require" hardware SPI. I have been using nRF24L01+ radios for local point-to-point commo and they are easy to use and fairly reliable. My goals is to transition to the nRF51822 bluetooth smart/2.4 GHz rf radio/microcontroller all-in-one chip which also uses SPI. It does have RSSI reporting and a bunch of IOS and Android apps already written for it. It is backward compatible with the nRF24L01+ (not the same pinout though), is as easy to design and build a board with, but a little more difficult to program. It is possible to program and transceive with the bare chip without a microcontroller IIRC, but I plan to run it from a Teensy 3.1 (or 3.1 ++!)

I know TI and ST Microelectronics have similar chips and I just "ordered" a free sample from ST to try out.

The attraction of the cheap nRF24L01+ boards available from Amazon for a few dollars is that all the software can be developed and the application breadboarded before (or during) the custom pc board development.

Anyway since you asked (sort of!) I thought I would say more about my plans...
 
I spent 8 years on a project using IEEE 802.15.4. Not Zigbee. Those DIgi XBee's are a great solution since they do all the '15.4 protocol and have very flexible built-in firmware for digital I/O, A/D sampling, a UART, some or all of which you can use to wirelessly do a lot. Many cases, the field-side of the system with an XBee needs no code on an added microprocessor.
Of late though, I've bee working with RadioHead and the sub-GHz radios supported by RH.
I always begin with a module, not a chip, and like the XBee's, some modules are very smart.
 
The application I have in mind would require bluetooth; most iPhones don't do rf radio! RF radio is just the stopgap for now since I know it well and it's fine point-to-point indoors. On the otherhand, I did spend an hour at the Anarduino site and was very tempted to try out their Pro Mini clone and the radios, especially after reading your fine tutorial. This discussion might have just pushed me over the edge.

Ready made breakout boards or modules are fine, but for a custom application (and what application isn't?), one needs to be able to recreate the capability in the required form factor. The nRF24L01+ radios, for example, can be jumpered or soldered to a breadboard and that's fine for testing and working out protocols. In anything close to an end product, the chip not the module must be integrated into the system. This is the part of design I find the most challenging and rewarding; it's even better when the end product actually works as expected!

In any case, I think you've convinced me to expand my experience with rf radios to include the SX2131, and I'll probably start as you suggest with the ready-made module.
 
On the long project I spoke of, with Xbee 802.15.5 non-Zigbee, we used an FTDI USB/Serial to get the XBee powered by and communicating with an Android phone and a big Java app on the phone. Essentially, the phone became a bridge between 802.15.4 and cellular. Web browser talked to distant host via cellular and that host sent commands to the phone to bridge back to 802.15.4 wireless. The double path was so that there was user access authentication by the web server, and end to end application layer encryption, rather than man-in-the-middle vulnerable link by link encryption.
Bluetooth just isn't designed to work with a multi-node star network. It's fine for a one-to-one link, but the range is limited by its low power and high (2.4GHz) freq.

Teensy 3 with Osh Park board for RFM69 makes a great combo - and you're not stuck with the 2K RAM on the mega32.
The HopeRF RF69W and RF69HW use the SX1231.

We're beginning to work with the RFM69 (SX1231) software tool for testing optimal error rate settings for various tools. To replace the ones now in use in RadioHead.
 
Status
Not open for further replies.
Back
Top