I found the idea to move both sides of “TheTasTaTur Mark1” fully independently from each other very appealing. So I first planned wireless communication. Letting every part “talk” itself to the computer was no option. Because I didn’t want to write hardware drivers for the different operating systems – that would be necessary to integrate both key states, for example pressing ‹M3› on the left and ‹N› on the right should produce a ‹(›. I’m not aware of a “syndication” feature in bluetooth. If it exists a link to specific information would be really nice. Nevertheless I planned that the left side should talk to the right and the right side integrates the keys of the left in a single neat bluetooth report and sends that to the host. After studying the wireless buying guide of Sparkfun (back then it looked quite different) and trying to keep the costs low I decided to buy these. With them very basic radio communication – one sends, the other receives, no two-way communication – should be possible. Besides the usual GND and VCC connections you simply connect the sending pin to one of your Arduinos and the receiving pin to the other (using SoftwareSerial or the hardware serial interface on digital pins 0 and 1). On the software side you initialize both with the same baudrate and then you can write one byte on one side and on the other side this byte is received. That’s the theory and almost the reality. As you might have read in some of my previous posts I dismissed RF and used a cable. Because it’s not that simple and easy. At least there is a reason why more sophisticated wireless solutions exist. I got it working though. But not really with the quality or speed needed to be useable in a keyboard. In fact that were the tradeoffs I experienced. Either I got reliable communication and a noticeable delay or instant reactions and missed key presses and garbage. The basic problem – at least I think it is, feel free to correct me if I’m wrong – is that the receiver needs some time to adjust to the signals of the transmitter. This seems quite logical because this devices actually have a quite big range and can accommodate to signals of different strengths. When you don’t send anything the receiver tends to pick up a lot of garbage from the air, because it “thinks” the sender is far away and makes itself more sensitive. When you begin sending it will be “overwhelmed” with the signal strength and “slowly” adjust to the actual strength. After this adjustment phase it works reliable. So basically I had to come up with a decent protocol, that filters the garbage out and initializes the communication properly. I tested two different strategies. The first was to continuously send a keep alive signal or carrier signal to keep the receiver at a certain signal strength. I looked deep in my sketchbook and found the receiving and sending code using this strategy. The functions displayed in the following gist do the actual sending: The next gist shows the receiving code of the right hand side. This version was the one that turned out to be too slow in the end. I guess thats because of the communication overhead and the quite limited baud rate of the devices (4800 baud/s). In addition it seemed – I haven’t tested it though – that I could get problems with the power consumption of this solution. Basically the sender sends either a package from a key press or every five milliseconds (I experimented with different durations) a carrier signal. The receiver waits for a start package, dissects the following packages, does some checking and translates them back to key presses until a stop package is received. The key presses are integrated with the key state of the right side, packaged in a bluetooth report and send to the host. The second strategy was to wake the receiver through a number of pull-up signals before the real keyboard state is send. I couldn’t get this solution to work without error and missing sometimes the first keys. Almost regardless of the amount of pull-up signals. Unless I send really a lot of them, but then it reverts to being to slow. However here is the code for the sender using the second strategy: The next gist shows the code for receiving the key states send using the pull-up technique. I made this exclusively for testing the communication. Maybe the whole solution is a little flawed. For example I could have tried to make a little delay between every pull-up signal. But that would have meant a bigger refactoring (maybe I will try this in a later project). For then, after days of trying to get it work and because around the same time the powering solution didn’t work out so well (read here for my blowing LiPo experiences) I decided to simply use an old USB cable and dismissed RF between the keyboard parts.