Simultaneous multi peripheral support

[MorGuux]

Requires some bandwidth testing on:

• Serial communication for relaying led/screen data (should be more than adequate)
• Wireless data transmission capacity

Speeds highly depend on the type of devices used. For example, a dozen button boxes require very little transmission bandwidth, as data is only sent on button presses. A few screens and LEDs would use much more bandwidth, so this needs some testing.

Full duplex isn't possible without two nrf modules per device. Thus there are two ways of enabling half duplex support:

• Switch module from RX to TX, send message, then switch back (can be slow and miss messages during inactivity)
• Use ack payloads to achieve call response, so no switching of module

The second method seems to be the most suited way currently, as if a screen/LEDs is used, and s button is pressed, a response can be returned within 1/60th of a second (since the data is 60hz).

There may be issues when multiple peripherals are used, with noticeable lag / delay, but this will have to be tested. For now, button boxes should function fine, screen/led units should function fine, but mixing both input and output into one device might cause slowdown.

[drouij67]

Hello, i used your button matrix code to successfully setup a wireless button plate. I planned to run a second set of pro micros to run led's and Nextion but was unable to get it working. Were you ever able to get it working for nextion and WS2812?

[MorGuux]

Hi. I'm glad to hear you got it working. I abandoned the project when I discovered that setting up the hardware, I could not get it stable and instead thought of switching to bluetooth. If it works for you though, then great!

In the master branch, I did get the WS2812 LEDs to work, by encoding the RGB data as a string (with 8 LEDs and 3 bytes per LED equaling 24 total bytes) and sending it. I never tried the nextion part, but it would be a similar process where you'd send data and parse it on the receiving end.

You may wish to try and modify the master code to change what the nextion method sends (I just duplicated the LED code). Maybe sending a struct of data like rpm, speed, fuel etc that you can parse. Updating the nextion on the receiving end is pretty simple, the protocol is quite basic.

Let me know if you need any info, I'm happy to help.

Morgan

[drouij67]

Any chance you could send the sketch you had working for RGB? im a novice at best and it helps when i can work off examples. Any info is appreciated. Thanks a ton.

…

On Jul 15, 2021, at 8:16 PM, Morgan Gardner ***@***.*** ***@***.***>> wrote: Hi. I'm glad to hear you got it working. I abandoned the project when I discovered that setting up the hardware, I could not get it stable and instead thought of switching to bluetooth. If it works for you though, then great! In the master branch, I did get the WS2812 LEDs to work, by encoding the RGB data as a string (with 8 LEDs and 3 bytes per LED equaling 24 total bytes) and sending it. I never tried the nextion part, but it would be a similar process where you'd send data and parse it on the receiving end. You may wish to try and modify the master code to change what the nextion method sends (I just duplicated the LED code). Maybe sending a struct of data like rpm, speed, fuel etc that you can parse. Updating the nextion on the receiving end is pretty simple, the protocol is quite basic. Let me know if you need any info, I'm happy to help. Morgan — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU3TSX2UIQ4HJR6Y6IN6ODDTX526NANCNFSM4UAGZBQQ>.

[MorGuux]

It's the code in the master branch. You can see the LED implementation there, and the broken nextion implementation (but with methods present that just need populating).