Limitations on this library vs lowpowerlab

[brolly759]

I am currently building an FCC certified module with HopeRF and wanted to know if using the DIO0 pin for interrupt vs what you recommend matters or not. The lowerpowerlab version only uses that pin. Would you recommend anything else connected to the Atmega328P for proper functions? If you would like to discuss on skype, message me: brolly759.

[iwanders]

I am currently building an FCC certified module with HopeRF and

To maximize usability of your module I would breakout all the DIO pins.

wanted to know if using the DIO0 pin for interrupt vs what you recommend matters or not. The lowerpowerlab version only uses that pin. Would you recommend anything else connected to the Atmega328P for proper functions?

Yes, it matters, as you hopefully have read in the readme this library uses a different mechanism to determine whether transmissions are finished or messages have come in. Using the automode system to let the radio control the RF frontend, instead of switching it manually.

You may be able to get away with just DIO0, please see #3 for discussion on this. If you happen to test this, please chime in on that issue.

As said, I would breakout all the DIO pins as that guarantees all flexibility of the original radio module is retained. Remember that DIO2 is used as the data pin in the continuous mode and no other DIO pin can be used for the data in continuous mode. If DIO2 isn't broken out you can never use continuous mode, not a problem for most people, but you do limit the functionality.

[brolly759]

So you basically recommend I disconnect DIO0 from INT and let the user decide. The issue I am finding is the module dimensions are fairly large doing it that way, right now with a U.FL connector I am 18x20mm.

Continuous mode would have issues with FCC as I was told by HopeRF that my max TX time (FSK) is 30ms every 100ms. So far continuous mode is just good for RF testing / antenna tuning / Impedance matching.

The module right now has everything broken out, including a separate VCC rail for RF and MCU. W25X40 Flash chip for ID number and extra storage for OTA and other stuff. RF Reset Pin connected to IO pin on mcu and Radio CS pin exposed to use ISP on MCU.

Am I missing anything or do you have any recommendations?

[iwanders]

So you basically recommend I disconnect DIO0 from INT and let the user decide.

That's what I would do yes, but I can see your argumentation for not doing this. It's a shame the DIO0 pin doesn't have a - connection in the Rx mode, if that existed and the pin would be high impedance in that state you could've connected DIO0 and DIO2 together.

Hmm, I have to admit I don't remember this exact details of #3 when it came up. If the solution proposed there works well it's a non issue. Perhaps you can test that to confirm this library works for DIO0?

Alternatively, a small SMD soldering jumper / cuttable trace doesn't have to take a lot of real estate, that way users who really want to can switch between them. Ah well, just a suggestion. I think this library has significantly less users than the LowPowerLabs or Radiohead ones, because it's younger and doesn't deal with protocol stuff (on purpose), I guess a soldering jumper may be good enough for those who dive down the rabbit hole and want to squeeze performance to a max by using this library?

Continuous mode would have issues with FCC as I was told by HopeRF that my max TX time (FSK) is 30ms every 100ms.

Oh yes, continuous mode can easily violate any RF regulation. But so can packet mode, either way I think you're right in the statement that packet mode will cover most use cases.

The module right now has everything broken out, including a separate VCC rail for RF and MCU. W25X40 Flash chip for ID number and extra storage for OTA and other stuff. RF Reset Pin connected to IO pin on mcu and Radio CS pin exposed to use ISP on MCU.

Cool, including the RFM's reset pin is indeed paramount, that was one of the issues we encountered in #1. I would suggest placing a large capacitor near the radio module's VCC by the way. I've found that the transmissions are much more reliable if an electrolytic capacitor is placed close to the radio module, especially when powered over USB. But you probably already figured that out.

[brolly759]

I use the lowerpowerlab currently in prototypes and it works for what I want it to do but I was hoping to build from the ground up using your RF stack, including custom ways to do OTA.

From my recollection I did try your DIO0 example and it worked. Though according to the datasheet, automode looks to be only available on DIO2? Unsure

Page 48 http://www.orcam.eu/res/Datablad/rf69v12.pdf

Why would others do things manually and not use automode? Would there be a time when automode was not efficient?

RFM Reset is connected directly to a GPIO and not available through external pin.

FCC Module has a metal can on top, a user wouldnt be able to do a solder jump switch sadly.

I am going to try and possibly get working a polling RX sensor, where the sensor can have RX in nanoseconds listening and go back to sleep in case I want to send the radio a message while sleeping... Have you had any experience in this?

[iwanders]

From my recollection I did try your DIO0 example and it worked. Though according to the datasheet, automode looks to be only available on DIO2?

Yeah, automode is only available on DIO2, the DIO0 example works by still using the automode system, but relying on the CrcOk and PacketSent events. This should work just as well.

For the CrcOk the manual states:

if the CRC check fails then the FIFO is automatically cleared and no interrupt is generated

So that means we should be good even if the CRC fails. And for sending the interrupt goes high when the packet is sent completely, which should also be good enough. But given that it hasn't seen a lot of testing I'm a bit reluctant to state in the readme that it works with DIO0.

Why would others do things manually and not use automode? Would there be a time when automode was not efficient?

Good question... I don't remember the exact details, but if I remember correctly the transmit and receive modes were described in reasonable detail in chapter 4 of the datasheet. So the standard way is to load data, and then manually switching to Tx mode, switching back to Idle after the transmission has been completed. This requires more SPI transmissions and will result in the PLL / RF synthesiser being enabled for (slightly) longer than strictly required, same on receive if I remember correctly. I think the main reason comes from the fact that the automode stuff is only described with one paragraph in the datasheet. To get to a working automode system you'll naturally first develop manual state switching, at which point you basically already have what you want; communication.

Using the automodes to modify the states on the radio requires setting up RegAutoModes 0x3B with the appropriate flags, and for transmission you have to set RegFifoTresh 0x3C correctly as well to start the transmission at the right FIFO size. It's not that hard, but it does require a bit more work to figure out than manually switching the radio's mode. The benefits are likely small, unless you are pedantic about power usage or data rates.

RFM Reset is connected directly to a GPIO and not available through external pin.

As long as you can send a hard reset through software, that's good enough.

FCC Module has a metal can on top, a user wouldnt be able to do a solder jump switch sadly.

I see, well, maybe not a problem given that you tested DIO0 and it works.

I am going to try and possibly get working a polling RX sensor, where the sensor can have RX in nanoseconds listening and go back to sleep in case I want to send the radio a message while sleeping... Have you had any experience in this?

Don't have a lot of experience with it, but do remember trying it once. You can probably put one of the DIO pins into a mode where you can see / measure how long the Rx mode is enabled. I remember I implemented the list mode methods to modify the registers associated to it. Those methods and the description in 4.3 of the datasheet should get you started, goodluck! :)

[brolly759]

Thanks for all the input. I use the Atmega328p for this and it does what I need but I was thinking of porting over to the SAMD21 or the SAML21. Have any recommendations?

[iwanders]

I would definitely switch away from an Atmega328p, going towards a 32 bits microcontroller with a lot more RAM than the Atmega328p helps a lot when you want to do more complex computation (oh, and interrupts on ALL pins, not just two). I don't have any recommendations in particular, I've developed this library with the Teensy 3. But the SAMD21 you mention appears very similary to the Teensy LC, which is more then enough for most projects.

[etherfi]

I just submitted a pull request that adds direct support for DIO0-only and high-power modules. I tested it using a SAMD21-based module: https://www.adafruit.com/product/3176

[ramanc51]

I am using this library with esp12f, used minimal interrupt method, communication distance between two modules is very low only 5-10 cm. How to increase this distance?

[iwanders]

I am using this library with esp12f, used minimal interrupt method, communication distance between two modules is very low only 5-10 cm. How to increase this distance?

@ramanc51 , this question is completely irrelevant to this thread. You should have made a new issue. Sounds like an hardware problem, check that power supply and capacitance is adequate, antenna's are the correct size and the configuration is identical on both. Please don't reply to this issue any further, if you have more questions make a new issue.