MCP23017 and NRF24l01

I have a adafruit RGB LCD shield shield with 5 buttons from adafruit which uses an MCP23017 and i2c to comminucate with arduino.

I want to try make it wireless using this:

I have two nrf24l01+ modules.

My question is will it work to just plug and play? What will the latency be like when pushing buttons etc?

This sounds like something that would be easiest to determine by a simple test.

What response time do you require (or what latency would be too much)?

Why do you think there would be any significant latency?

...R

I can't really test it until I get the i2c converter. But I'm guessing even with the converter it must interface with an arduino. Otherwise how will the nrf24l01 get the data from the MCP23017?

I am trying to make a wireless menu system, using buttons and holding them down to select and change values etc. I am thinking that the latency will be too much to accurately detect button presses/releases. If its only a second or two that's OK for selecting values, but to change values by holding down the buttons might be annoying. I could rewrite it so when you change a value you have to change each digit and that would eliminate most of the button-holding lag time.

Otherwise I could use two arduinos, one to control the menu/lcd shield and another to receive values from the former. But I am not experienced with nrf24l01 so it seems like alot of hard work.

syphex7:
I am thinking that the latency will be too much to accurately detect button presses/releases. If its only a second or two that's OK for selecting values, but to change values by holding down the buttons might be annoying.

I have no idea what latency you have in mind, or what you think may cause the latency. You need to explain that if you want useful advice.

I have a simple nRF24 system that sends data every 100 millisecs - and it could be much more frequent.

...R

The latency issue I have in mind is say I want to change a temperature value from 20 C to 24 C by holding down one of the buttons. I see it reach 24 C and let go, but because of latency it might go to 28 before it gets the signal that the button isn't being held down anymore. Then I have to go the other way but it might go to 22 before it registers a button release etc...

What would cause this latency? I assume it would be inherit to the nrf module itself and the environmental conditions at the time, like I said I have no idea what kind of performance to expect which is why for now I'm asking a very general question about whether it is a feasible idea to send the data that normally goes through i2c, through nrf instead with respect to what I have described (5 button lcd shield communicating to arduino via i2c).

I guess all the lcd-shield side has to send is a byte or so of buttons being held down, and it needs to receive everything a 2x16 lcd screen needs, and it needs to do this at least every second reliably. Distance isn't so much of a concern as obstructions. At times there could be a brick wall between the nrf modules so again I don't know what kind of performance I can expect so I'm trying to get a general idea about which route to take.

If possible id like to avoid having an arduino on the lcd end as it seems like a hack. I need to know how I can get the data from the mcp shift register and send it via the nrf module

syphex7:
The latency issue I have in mind is say I want to change a temperature value from 20 C to 24 C by holding down one of the buttons. I see it reach 24 C and let go, but because of latency it might go to 28 before it gets the signal that the button isn’t being held down anymore. Then I have to go the other way but it might go to 22 before it registers a button release etc…

Each process that takes input, sends it somewhere somehow, receives something back and displays that, imposes some latency.

If your receiving side is on the moon, it will add up to more than 2 seconds, no way around it.

Better adjust the values local and send the adjusted results.

syphex7:
What would cause this latency? I assume it would be inherit to the nrf module itself

I'm still at a loss to know why you think the nRF24 would introduce an amount of latency that would matter.

As I said in Reply #3 I am sending data every 100 millisecs - would that meet your requirement?

If not, what is the maximum that you would consider acceptable?

...R

Robin2:
… I am sending data every 100 millisecs …

but from what you 've read and experienced with this NFR240l did ever happened to lose signal ?

aditzas:
but from what you 've read and experienced with this NFR240l did ever happened to lose signal ?

That has absolutely NOTHING to do with latency.

My experience is very limited, but the straight answer to your question is that my nRF24s have not lost signal.

However I would not rely on that. No system can be 100% reliable. You need to design resilience into it. For example my receiver (which controls a model train) is designed to halt the train if it stops receiving data - and I have tested that by switching the transmitter off.

...R

I understand , thank you.

I should have said in Reply #8 that my receiver does not stop the train unless it receives no messages for 1 second. That allows it to ignore occasional failures in the reception of data.

...R

Robin2:
I'm still at a loss to know why you think the nRF24 would introduce an amount of latency that would matter.

As I said in Reply #3 I am sending data every 100 millisecs - would that meet your requirement?

If not, what is the maximum that you would consider acceptable?

...R

A maximum of 1 second between sending button states and receiving LCD states would be acceptable. The reason for this is because when you hold down a button to change a value, it increments/decrements by 1, then a few seconds later 10, then 100. I don't want to accidentally change a value by a few 100, because then I have to go in the opposite direction where the same error might occur.

e.g. starting at 1, say I want a value of 455:

1 // button held down
2
3
4
5
15
25
35
45
55
155
255
355
455 ////////button released
555
655
755 ///// 3 seconds lag

I am now at 755 instead of 455, so now I have to go the opposite way:

755
754
753
752
751
750
740
730
720
710
700
600
500
400 // button released
300
200
100 // 3 seconds lag

The LCD shield I am using is this: adafruit RGB LCD shield, sorry I didn't post it before - I thought I had.

On one hand it seems like the addition of a pro micro (I have one lying around) to the LCD/buttons shield could simplify things, as I don't have much experience coding from datasheets etc. But on the other hand it seems a bit like an overkill.

I just don't understand how you would operate the nrf24L01 module and its ce, csn, sck, mo, mi, irq inputs on the LCD/buttons side without an arduino. I only know that sck is a clock signal, and I forgot what mosi and miso do. Obviously its possible but I am wondering if its too difficult with my current skill set.

Basically the LCD/buttons shield uses i2c to comminucate with an arduino, I want to make this wireless. What is the best/simplest way to achieve this? I am assuming that it is to add an arduino (pro micro for example) to the lcd shield and have the two arduino's communicate button/lcd states to each other.

If lag causes the undesirable scenario above then I might as well have the pro micro handle the menu/lcd/buttons system and send "commands" to the main arduino? But that might get complicated/annoying aswell. So then what approach should I take?

Lets return to the beginning:

syphex7:
I have a RGB LCD shield with 5 buttons from adafruit which uses an MCP23017 and i2c to comminucate with arduino.
I want to try make it wireless using this:
http://www.elecrow.com/nrf24l01-wireless-shield-spi-to-i2c-interface-for-arduino-p-737.html

The nrf24l01-wireless-shield-spi-to-i2c-interface-for-arduino does not help you in making the LCD shield wireless,
it is merly an I2C to SPI converter + 3.3V regulator. All NRF24L01 drivers I have seen use SPI directly, so...

Where shall the button presses be sent to and who is to write (wireless) to the display?

You could use nearly any Arduino and your NRF24L01, or a NRF24LE1 which combines a NRF24L01 with a 51-microcontroller.

Or you could drop the NRF24L01 (for this project) and use ESP8266 NodeMcu Lua ESP-12E and WiFi.

I have no experience with these alternative chips yet, both types are still on their way from the east.

I was hoping that the spi to i2c converter meant that I could do something like this:
('-' means communicated through, or something along those lines)

instead of:

lcd shield - i2c - arduino

to:

lcd shield - i2c - i2c to spi - nrf - ##wireless transmission## - nrf - spi to i2c - arduino

But it seems this is not the case. Because it seems like there needs to be something to manage the nrf on both sides, like an arduino. Is that what the "NRF24LE1 which combines a NRF24L01 with a 51-microcontroller" could do?
In the wired case, I'm guessing its the arduino that "pulls" and "pushes" the data to and from the mcp port expander chip via i2c.

Whandall:
Where shall the button presses be sent to and who is to write (wireless) to the display?

Well at the moment (no nrf) I guess the button presses get stored in the port expander chip, and the arduino reads them, then the arduino sends the lcd states to the port expander chip, and the lcd shield reads them. Please look at Adafruit RGB LCD shield with buttons for more information, as I have simply used their library to read the buttons and write to the lcd.

All I want to do is replace the i2c communication between the lcd shield and the arduino board with a wireless communication. I want to stay away from wifi because id like it to be more independent.

syphex7:
All I want to do is replace the i2c communication between the lcd shield and the arduino board with a wireless communication. I want to stay away from wifi because id like it to be more independent.

I assume that the Arduino uses I2C to communicate with the LCD shield. I don't understand your diagram

lcd shield - i2c - arduino

because in my mind the I2C stuff happens inside the Arduino (at one end) and inside the LCD shield (at the other end). If you actually have a 3rd device in the middle please post a link to its datasheet.

For communication using an nRF24 you need an Arduino at each end so you have a system like

lcd shield - arduino - nRF24 ---- nRF24 - arduino

...R