DIO0 Only

[etherfi]

First off, let me thank you for producing this library. It is much cleaner and more efficient than the others out there.

I know this might be a big request, but I figured it couldn't hurt to ask. There are a number of Arduino boards out there that are readily available using the RFM69 module. The problem is that they only have DIO0 connected. The other digital IO pins are unused. Some even lack a wire connecting the reset pin, relying on a full board powercycle for a clean slate.

I'd love to see this library more widely used, but having to make physical changes to the existing off-the-shelf solutions makes it impractical.

Would you consider creating a version that uses only the DIO0 pin? I'm aware that the same interrupts are not available there, but other libraries manage, so there must be a way.

Thanks in advance!

[iwanders]

First off, let me thank you for producing this library. It is much cleaner and more efficient than the others out there.

Thanks, that's what I set out to do!

There are a number of Arduino boards out there that are readily available using the RFM69 module. [...] I'd love to see this library more widely used, but having to make physical changes to the existing off-the-shelf solutions makes it impractical.

Totally agree, you've probably seen #1, which discusses the Moteino and use of this library on that hardware. The hardware modification is indeed a major show-stopper to wider adaptation.

Would you consider creating a version that uses only the DIO0 pin? I'm aware that the same interrupts are not available there, but other libraries manage, so there must be a way.

Good to see that you did your research and took the time to look up the datasheet. I did the same and noticed the CrcOk and PacketSent fields in the DIO0 packet-mode Tx and Rx fields. I'm currently short on time so I didn't check this; I believe the other libraries use this to check whether there is a packet or it has been sent. These flags should also be raised when the AutoMode system is used according to the datasheet.

So, I thought I'd give it a go using these flags to detect new packets or successful transmission. I did a very short test with this; all I changed was the following line:

// tell the RFM to represent whether we are in automode on DIO 2.
rfm.setDioMapping1(RFM69_PACKET_DIO_2_AUTOMODE);

To:

// tell the RFM to set DIO0 when the CRC is ok and when a packet has been sent.
rfm.setDioMapping1(RFM69_PACKET_DIO_0_RX_CRC_OK | RFM69_PACKET_DIO_0_TX_PACKET_SENT);

That was basically all that was needed, in my very very short test this actually worked. Unfortunately I do not have the time to do extensive testing (although during the writing of this post it didn't get stuck (3000+ messages sent and received).

I know this might be a big request, but I figured it couldn't hurt to ask.

No, it never hurts to ask. @bloever actually asked it in #1, but the question was answered when he soldered a wire to DIO2. So I didn't really investigate whether it would be possible back then.

I don't really see a way around the reset wire though, on the Moteino a reset was really required. There doesn't seem to be a way to issue a reset via a register, perhaps this is different for other hardware?

I've created a new example in commit a5040471daa50868b1be4cf9953a969a7c403639, please give MinimalInterruptUnoDIO0 a try and let me know if it works.

[stvkrfhg]

Greetings "iwanders" and thanks for the library.

Having had some issues using the LowPowerLab RFM69 library with a Moteino, I found this while looking around for alternatives while researching how to write my own. I was about to start working on the SX1231 drivers source code (also on github) and found this library. It is unfortunate that the Moteino version doesn't send all the pins out, especially reset.

While evaluating your library, I found a couple minor errors and submitted corrections on a fork.

So, I modified the MinimalInterruptUnoDIO0.ino example to work with my 915Mhz Moteino board and removed the dependency on the reset and sender_detect also since I don't have those. I just made it hardcoded to be either a 'sender' or 'receiver'.

It seems to work, at least with my rudimentary check but will have to do some additional testing to get an idea of what error rate it will have. On the LowPowerLab library I ran a bi-directional ping pong test and was getting between 3% and 5% packet errors -- and the devices are less than 5 feet apart.

The project I'm using it with sends button presses to multiple receivers and there were occasional times where it looked like the button was "stuck". I first blamed it on not having good de-bouncing and/or bad buttons but some experimentation showed the packet loss was causing it - that's when I started running the ping pong test to see what was going on.

My application isn't doing error detection or retransmit but just sends all of the packets twice... Not great but should have worked much better in my simplistic application than it did. I'm trying to get near real-time button press response but not sure how well that will work out. I was trying to keep it simple without having to code up a protocol for error detect and retransmit.

This library looks like its working better, so may have something to work with. Consider it preliminary - I'll still have to modify the example to do my faster ping pong for a more direct comparison.

Do you have a ballpark idea of what kind of bit error rates you are expecting and experiencing? I'm looking for any guidance to obtain quick device response without complicated software protocols (nor delays).

-- Thanks

[iwanders]

It seems to work, at least with my rudimentary check but will have to do some additional testing to get an idea of what error rate it will have. On the LowPowerLab library I ran a bi-directional ping pong test and was getting between 3% and 5% packet errors -- and the devices are less than 5 feet apart.

Considering the distance, I'm surprised by those error rates, they're really high from what I remember when I worked on this. Especially with just a few meters distance. One thing that is important is to have a large capacitor (electrolytic) as close as possible to the radio module. I found that helped significantly. Also you get more bit errors as your bitrate goes up, if you lower it I expect the bit error rate to decrease as well (and range to go up). I'm not sure which baudrate you are using, but consider the lower ones from the baud setup functions. It may help a lot depending on your circumstances.

The maximum ping pong example prints correct and incorrect pingpongs. If you look at the readme's section on performance you can see that in the simple test I did for the readme I pingponged 123468 messages with zero incorrect or missed transmissions. In the maximum speed example I send 101600 messages, it shows one incorrect message, but in fact that's the one from the startup when we sync the timers.. So 3% to 5% is definitely too high. Those tests were done with the examples unmodified, with radios close to each other.

The project I'm using it with sends button presses to multiple receivers and there were occasional times where it looked like the button was "stuck". I first blamed it on not having good de-bouncing and/or bad buttons but some experimentation showed the packet loss was causing it - that's when I started running the ping pong test to see what was going on.

Hmm, I would definitely not use two packets for the 'depress' and 'press' event. I would just use one for 'button pressed', or one message that sends 'button pressed for x ms'. That way you can do all the debouncing locally and the receivers can't get into a incorrect state if they missed a packet. (Don't do the sending from the button press interrupt, of course.)

I was trying to keep it simple without having to code up a protocol for error detect and retransmit. Yeah, well, in my opinion it should 'just work'. Especially given the fact that you have multiple receivers that should detect the button press it would likely not be trivial to conceive a simple protocol that does what you need.

I would try the capacitor and lower the baud rate as first steps to resolving your packet loss.

[etherfi]

I wanted to let you all know that the Adafruit Feather M0 RFM69 module (and possibly other AdaFruit boards) connects the RST pin and breaks out the DIO 2, 3, and 5 pins. This makes the addition of a short jumper to enable those pins a trivial modification.

https://cdn-learn.adafruit.com/assets/assets/000/032/914/original/feather_schem.png?1465421956

[iwanders]

Thanks for adding that information @etherfi, that's useful information for people who just want things to work without lots of soldering. :+1:

[Bharat0796]

i want to measure the ping of rfm69 hcw ....please can anyone give ping library so that i can check the network response speed of rfm69

[etherfi]

This is an old, closed thread. If you want help, please start a new thread.