Redox Wireless Interference issues

[Slavfot]

Hi! I just built a redox wireless and flashed it and got it working but i have trouble using it due to interference. Especially at home in the apartment, if i press a button it may (if lucky) send a keypress or it may send multiple keypress even though i just pressed once. It does not matter if i have the reciever 1cm from the keyboard or 50cm. I have also tested it at work when i was alone and it worked better, but when my collegues started working i got so much interference that the keyboard was unusable. How do i reprogram the reciever and transmitter to get less interference? I read that you can modify in the gazell firmware and modify the default channel table /components/properitary_rf/gzll/nrf_gzll_constants.h. If i modify (i don't know what channels to use instead) do i need to compile a new hex? (i don't know how to compile a new hex but i am willing to learn) Thanks!

[Slavfot]

I also found these lines in main.c that i suspect that i can add number of channels to?:

ifdef COMPILE_LEFT

static uint8_t channel_table[3]={4, 42, 77};

endif

ifdef COMPILE_RIGHT

static uint8_t channel_table[3]={25, 63, 33};

endif

[Slavfot]

Ok, i got it to work now... First I learned how to make new hexes. (I'm not a programmer, just a really stubborn mechanical engineer) Then i read alot in the nordic pages about Gazell link layer trying to understand things. I tested several things including adding channels and changing channels.

That did not help. The thing that made it work finally was to remove these rows of code: nrf_gzll_set_timeslots_per_channel(4); nrf_gzll_set_channel_table(channel_table,6); nrf_gzll_set_datarate(NRF_GZLL_DATARATE_1MBIT); nrf_gzll_set_timeslot_period(900);

I read an other issue where i believe you and LucidityCrash added this code.

I'm not sure if it was the channel table, the datarate or the timeslot that messed it up for me. I will make some more tests with each option later to see which line of code that messed with my keyboard.

[mattdibi]

Hi Slavfot,

sorry for the late response. I'm having a hard time answering to the issues here right now. I'm glad you found a way around your problem, let me know the results of your tests.

Cheers, Matt

[AltusBaard]

@Slavfot I am having the same issue, just to confirm, you updated only the keyboard firmware, not the receiver?

[Slavfot]

@Slavfot I am having the same issue, just to confirm, you updated only the keyboard firmware, not the receiver?

I updated both the receiver and the keyboards. I can upload my hex files later today.

[AltusBaard]

That would be great, I have only found some of the entries on the receiver and am worried of breaking things even more

[Slavfot]

@AltusBaard Here are the hex to the Nrf51128 modules. They are made with the edits i mentioned above. precompiled fix.zip

[AltusBaard]

Thanks, uploaded them and testing, seems to be working.

Also had a low battery in one, think that also might have had an impact on it.

[Slavfot]

Great to hear that it worked! If you had low battery on one half. Then only that half should have been acting weird. Since each half is talking individually to the reciever. So if you had issues on the keyboard that had good battery that are fixed now, then the firmware update is the thing that fixed it. Atleast that's what I think, please correct me if I'm wrong.

[AltusBaard]

Seems I still have an issue, it does feel better though, a lot less problems.

Will try see if I cant see anything else that I am missing. But thanks for helping anyway.

[Pastitas]

I've been trying the modded version of the firmware and i think that it's a tiny little bit better (might be placebo) but still get this happening every now and then.

I think what's necesary is to do some debugging to figure out who the culprit is, something is mentioned to that end in these two: https://github.com/mattdibi/redox-w-firmware/issues/2 https://github.com/mattdibi/redox-w-firmware/issues/3

I'm gonna go back to the "official" version and see if i feel things to be working differently. Due to the unpredictable way in wich this issue appears i don't know if i will be able to provide any new data, but i'll try my best

[SimonMerrett]

Hi all, I would like to thank @mattdibi for this firmware but when I was just testing out a modified version of it for the aerodox keyboard, I had terrible chatter issues. Without being familiar with NRF51 debug or QMK, I was combing through the code looking for issues I had introduced with my port/edit. I also switched out my Otemu switches for legit Cherry MX blues to make sure it wasn't a dud set of switches. The only thing which worked was:

The thing that made it work finally was to remove these rows of code: nrf_gzll_set_timeslots_per_channel(4); nrf_gzll_set_channel_table(channel_table,6); nrf_gzll_set_datarate(NRF_GZLL_DATARATE_1MBIT); nrf_gzll_set_timeslot_period(900);

To be clear, I left in nrf_gzll_init(NRF_GZLL_MODE_HOST); in the receiver code (there's no nrf_gzll_set_timeslots_per_channel(); in the receiver code - should there be?).

The difference in reliability/sensitivity is night and day - I would recommend a thorough review of this part of the Redox codebase by those who are more familiar with it as I think it could be causing significant issues if my experience is anything to go by.

Thanks for your persistence and sharing @Slavfot

[SimonMerrett]

Having spent aweek getting ttooooooooooooooooknowthis keyboard with the settings above you can see some of the issues I have been experiencing (also long hangs or missed presses altogether). It really gets noticeable when trying to hold down the shift button from the opposite half of the kb while typing a capital letter or the receiver is too close to the transmitters *(but doesnt improve that much when I move further away). Will keep testing.

[Slavfot]

Hi Simon, please keep testing and report with what you find. I still have some small issues, and it's worse at home then at work. My problem now is that it can feel slow in latency and missing keypresses, especially after coming back to work the next day. And I have noticed that if I unplug the receiver and plug it to another USB port it can fix the problem with it being slow and missing keypresses. Maybe that's a pairing issue? .

About this: nrf_gzll_set_timeslots_per_channel(); in the receiver code - should there be?). If it's not on the firmware code then it will add the default value for that variable. You can find the document with default values in the nordic SDK.

[SimonMerrett]

So, my problems got worse and after a while today I couldn't get any response from the right half of the kbd. I checked continuity and my pair of AA battery holders were not soldered properly and the power was intermittently connected. Having resoldered the battery holders I no longer have any issues with holding shift down on the opposite half to create capital letters and I no longer get delays or missed key presses. I'm gaining confidence in the layout now and so I will start using it for longer periods. Hopefully this will let me confirm if I have similar issues to you @Slavfot.

[harshitgoel96]

I am having similar issues with redox-w. I have used it for 10hr, and I have interface, lag, and key drop issues on the right hand. sometime some keys of the keyboards stop working. i have use fresh batteries so its not a battery issue.

is there a pre compiled for transmitter and receiver ?

[SimonMerrett]

I have also noticed things getting gradually worse. Lag and keydrop are more noticeable than before but I can't tell if it is progressively worse or I am just more likely to notice it now that I am used to the keyboard. Alt+tab is the one which goes most wrong, as it just records tab on its own and that often does something different to a window switch. To be clear, I am using an aerodox which is a derivative of the Redox-w control system but not the PCBs. I have tried power cycling all boards and my l/r halves are 2.9V each so should be fine for the nrf's voltage (using a pair of AA nimh rechargables on each half, so internal resistance isn't an issue at that voltage).

Another issue that is related to this is the matrix scanning doesn't allow e.g. shift+key if they are same row - I have to use the opposite shift key and can't do one handed for some keyboard shortcuts. It could be something in my adapted fw but I wondered if this was an issue with the stock hw/fw combo.

@harshitgoel96 I think there is Redox-w precompiled fw - I will link if I find it but keep looking!

Additional note - I have just tried moving my keyboard further away from my Surface Pro 2 and it seems to slightly improve the reliability of the input. Do you have any possible 2.4GHz interference from wifi or bluetooth radios that you could move away from or turn off. It was definitely something I noticed early on in using my keyboard. Make sure you have reasonable line of site (and perhaps not too close) to the receiver and that it is also away from 2.4GHz sources.

[SimonMerrett]

@harshitgoel96 https://github.com/mattdibi/redox-w-firmware/tree/master/precompiled

[harshitgoel96]

this my regular setup. I have wifi 5ft away from keyboard.

I have bluetooth headset, but I have problems even when they are off. Mobiles bluetooth and wifi could be an issue?

Is there any way to reduce the interference ?

[SimonMerrett]

Could you try using a longer usb cable on the receiver? Doing some more testing now, the further from my Surface that the keyboard is, the better the reliability is. Do you have wifi or bt enabled on the laptop? That would seem like the main source of interference to me. And also I can't quite remember where the antennas are in the Redox hw but you could have the left half of the keyboard and the laptop blocking line of sight to the receiver's antenna. Perhaps try the longer USB cable and moving the receiver around (higher and away from the laptop).

[harshitgoel96]

so turning off the laptop and mobile bluetooth does help. But i am curious why this happens ? Is it hardware related issue like the antenna of the BT chip or more of a firmware issue ? Other BT dongle keyboards do not have drops like this, but they are not split either. so just curious.

adding antenna lines on pcb would help ?

[harshitgoel96]

Ok, I did some more playing around, and found that receiver when placed in direct line of sight works good. It makes me wonder is it the antenna of yj-14015 is too weak ?

The yj-14015 does not have option for external antenna.

Does anyone know if mitosis has the same interference issue ?

[SimonMerrett]

Still got issues here. The removal of my phone to a metre away helps. But I'm starting to think about another wireless solution. The redox-w does have different radio settings, as per @Slavfot's report above (I commented out the code he mentions and this improved my performance) but did the timeslots perform a needed function or something? They don't appear in the mitosis main.c

I couldn't say if there are issues with the mitosis keyboard. BTW @harshitgoel96 this is using the gazelle protocol, not bluetooth. I don't know much about bluetooth and I know less about gazelle so I would value any insight @Slavfot or others have gleaned from their research. Perhaps a reduced datarate (down from 1mbit), a different number of retries (100) or action on failed tx would help. The redox-w code also differs from the mitosis wrt the debounce code, so maybe that's worth a look too.

[Pastitas]

I commented in this issue on the firmware repo that somebody optimized the code from the original mitosis keyboard, it seems, based on what they say on this issue that the keyboard gets more reliable and longer battery life. Based on what you are saying the shorter battery life could be related to constant resending due to interference, wich said fork is suposed to help with. I want to get into it an try an port the changes over and it does not seem too complex to do, but i don't have much time lately for this.

[harshitgoel96]

Joric modified the mitosis firmware to add native bluetooth capabilities to the keyboard. I am not technical enough to port it to Redox. Can someone try to do this and check if this has better communication then Gazell protocol.

https://github.com/joric/mitosis

[SimonMerrett]

Can someone try to do this

I had a look but the problem I have is that I have a different layout with aerodox so even if I managed to make it work, it wouldn't help you that much. I'm going to have a look at the link suggested by @Pastitas but don't hold your breath...

---

Update. The main differences I can see, apart from the absence of timeslots per channel etc mentioned above are:

• setting tx and rx power to 4 dBm, instead of 1. This is minimal effort to test as it only requires changing 2 lines of code, marginally.
• using RTC on the Rx to manage timeouts
• stopping the use of RTC1 on keyboard and using RTC0 for all debouncing.
• max retries is doubled to 200. This is probably the least effort.

Next time I have my linux machine fired up, I'll try and test the rf power increase and the retries. I suppose there's a chance that timeouts on the receiver are a cause and probably least likely is the debounce on the keyboard, as a cause of missed keypresses.

@harshitgoel96, I looked at the joric bluetooth stuff but it doesn't support QMK from the looks of it.

[Pastitas]

Can someone try to do this

I had a look but the problem I have is that I have a different layout with aerodox so even if I managed to make it work, it wouldn't help you that much. I'm going to have a look at the link suggested by @Pastitas but don't hold your breath...

If you manage that much i am willing to take it to the original redox layout

[SimonMerrett]

I haven't tried yet with the firmware changes but I have just tried moving the receiver well away from anything - about half a metre to a metre away from the computer and the keyboard. The reception is much better now (definitely still not reliable enough for my taste) so part of the problem may be that the keyboard is too close to the receiver and is swamping it with energy. Even on 0dB it might be. So if you do try to increase the power, bear in mind that unless there's some adaptable attenuation going on in the nrf analog front end, it might be a case of more range between keyboard and receiver also improves things.

[SimonMerrett]

I have just 'upgraded' to 4dBm transmit power on the keyboard transmitters and set them to 200 retries instead of 100. There's still some potential to handle e.g. nrf_gzll_device_tx_failed() with something to resend unsuccessful packets. I also wonder if there's any merit in studying the effects of the rx fifo pipe flush.

It's too early to tell how much difference the power and retries increase has made but I will update when I have spent some more time with the keyboard in this mode. I can say that it does appear to work more fluidly, so you have nothing to lose (apart from battery life) by trying it yourself.

[harshitgoel96]

I have just 'upgraded' to 4dBm transmit power on the keyboard transmitters and set them to 200 retries instead of 100. There's still some potential to handle e.g. nrf_gzll_device_tx_failed() with something to resend unsuccessful packets. I also wonder if there's any merit in studying the effects of the rx fifo pipe flush.

It's too early to tell how much difference the power and retries increase has made but I will update when I have spent some more time with the keyboard in this mode. I can say that it does appear to work more fluidly, so you have nothing to lose (apart from battery life) by trying it yourself.

can you share you compiled hex for transmitters ? i will add them to my keyboard and test it out. also it will be on keyboard or on dongle or both ?

[SimonMerrett]

can you share you compiled hex for transmitters ? i will add them to my keyboard and test it out. also it will be on keyboard or on dongle or both ?

Sorry, as mentioned above I'm using this on a custom layout which is not directly compatible with the redox-w. I will say that I also felt that just changing the power was a little unsatisfactory to I went back and looked at the code that @LucidityCrash added and @Slavfot (and I, on my board) removed to get an improvement in the connection between the keyboard and receiver.

So Lucidity crash was following advice from the nordic support team when they suggested using the channel hopping mode for two transmitters to one receiver. Compared to how I think Gazell is supposed to work, we're using it in a fairly blunt manner. I noticed something in that advice that I don't think LucidityCrash applied in their patch:

You must also keep the PTXs the time slot twice the length of the PRX

So this means we need to nrf_gzll_set_timeslot_period(1800); in the receiver, not 900. Also, I then went to look at the Gazell user guide and see that they have some parameters about whether to use the previous successful channel on the tx and also the sync method used. So I've added those, dropped the bitrate to 1Mbps, kept the power at 4dBm, and will see how things go. So far, I can say it seems way better than when I had channel hopping set up as per the existing repo. But I think there may still be a couple of missed keypresses and I couldn't say it's better than omitting the channel hopping and just leaving the power up high!

As I said, I won't share the whole source for my different columns/rows layout and as I'm editing my version I won't provide precompiled redox-w binaries. But I will post snippets of code for you to insert and compile yourself in a future comment (from my other machine).

[SimonMerrett]

In receiver main.c

// Define channel hoping parameters
#define channel_table_size 6
#define timeslots_per_channel 2
#define GZLL_RX_PERIOD 1800 // supports 1Mbps

static uint8_t channel_table[channel_table_size]={4, 25, 42, 63, 77, 33};

also

    // Initialize Gazell
    nrf_gzll_init(NRF_GZLL_MODE_HOST);

    nrf_gzll_set_timeslots_per_channel(timeslots_per_channel);
    nrf_gzll_set_channel_table(channel_table,channel_table_size);
    nrf_gzll_set_datarate(NRF_GZLL_DATARATE_1MBIT);
    nrf_gzll_set_timeslot_period(GZLL_RX_PERIOD);

then in keyboard main.c

#define GZLL_RX_PERIOD 1800 // supports 1Mbps

// Define channel hoping parameters
#define channel_table_size 3
#define timeslots_per_channel 2

#ifdef COMPILE_LEFT
static uint8_t channel_table[3]={4, 42, 77};
#endif
#ifdef COMPILE_RIGHT
static uint8_t channel_table[3]={25, 63, 33};
#endif

also

// Initialize Gazell
nrf_gzll_init(NRF_GZLL_MODE_DEVICE);

// Attempt sending every packet up to 200 times
nrf_gzll_set_max_tx_attempts(200); // added to tranmitter to see if the link is improved
nrf_gzll_set_tx_power(NRF_GZLL_TX_POWER_4_DBM); // added to tranmitter to see if the link is improved 
nrf_gzll_set_timeslots_per_channel(timeslots_per_channel);
nrf_gzll_set_channel_table(channel_table,channel_table_size);
nrf_gzll_set_datarate(NRF_GZLL_DATARATE_1MBIT);
nrf_gzll_set_timeslot_period(GZLL_RX_PERIOD / 2);
nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*timeslots_per_channel);
nrf_gzll_set_device_channel_selection_policy(NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_SUCCESSFUL);

YMMV. Given that I seem to have repeat offenders in which key I am pressing (r, p - but not redox matrix) then I am as inclined to think that the missed keys are as much the debounce and key reading as it is a wireless comms issue. Good luck.

[LucidityCrash]

So Lucidity crash was following advice from the nordic support team when they suggested using the channel hopping mode for two transmitters to one receiver. Compared to how I think Gazell is supposed to work, we're using it in a fairly blunt manner. I noticed something in that advice that I don't think LucidityCrash applied in their patch:

You must also keep the PTXs the time slot twice the length of the PRX

Damn it ... that was a mistake ... I could have sworn I'd done that :)

[SimonMerrett]

Not to worry, and from my testing so far, all it does is makes the channel hopping on par with the non-channel hopping version. I still get missed keypresses, sadly. I know I have different hardware to everyone else but I may look at the matrix scanning side of things next.

[danielo515]

Hey. I am also experiencing problems on reliability, but they are very intermittent. In some situations, I thought it was a battery problem so I just replaced the battery on the half that was giving me problems, but then after just a couple of weeks, I had the same problems again, and always on the left half. Moving the receiver around helps, but I'm not sure about which positions are best. Right now is in the middle of the two halves, like 10 centimeters away of each other. I also noticed that turning wifi on or having the phone close disturbs it, but my bluetooth mouse doesn't seem to cause any trouble for example.

Is there any known configuration that improves the reliability? Oh, and do you have any guide to flash each halve? Never did it before.

[LucidityCrash]

Another issue that is related to this is the matrix scanning doesn't allow e.g. shift+key if they are same row - I have to use the opposite shift key and can't do one handed for some keyboard shortcuts. It could be something in my adapted fw but I wondered if this was an issue with the stock hw/fw combo.

Just noticed this ... it must be your adapted FW as my shift Z (same row same board) works just fine :)

[LucidityCrash]

So Lucidity crash was following advice from the nordic support team when they suggested using the channel hopping mode for two transmitters to one receiver. Compared to how I think Gazell is supposed to work, we're using it in a fairly blunt manner. I noticed something in that advice that I don't think LucidityCrash applied in their patch:

You must also keep the PTXs the time slot twice the length of the PRX

Damn it ... that was a mistake ... I could have sworn I'd done that :)

Hang on a sec, from that post : " You must also keep the PTXs the time slot twice the length of the PRX " You've made the RX twice the TX haven't you ?

[SimonMerrett]

it must be your adapted FW

Brilliant, thanks for the confirmation - now I can go and feel like time spent addressing this is worth doing.

As an update, I have been using the "correct channel hopping" I mentioned above but the performance is still bad. However, I still think that this could be a function of the debounce settings I have (I think I went down to 5) and number of retries. Often I will have to press a key two or three times before it is registered and when it finally registers I get three of that key appear onscreen. I also get double-typed keys when I only meant to press once, hence my thought that key debounce is not effective with the 5ms setting I'm using (I think - need to check). I reduced the debounce period because I thought that might be contributing to the failure for some key presses to register (mistaking a press and release too quickly for no press at all).

I plan to at least increase the debounce and maybe play with some other things soon to try and make this a more viable keyboard. At the moment I am enjoying cheap lenovo membranes more!

[SimonMerrett]

You've made the RX twice the TX haven't you ?

Yes! it looks like I have. Will swap that round and try it out.

[SimonMerrett]

@LucidityCrash I think I got confused by this when you scroll to the bottom:

/* On Host and Device */
timeslots_per_channel = 2;
channel_table_size = 3;
nrf_gzll_set_timeslot_period(GZLL_RX_PERIOD / 2);
nrf_gzll_set_channel_table(my_channel_table, channel_table_size);
nrf_gzll_set_timeslots_per_channel(timeslots_per_channel);
/* On the Device */
nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*timeslots_per_channel);
nrf_gzll_set_device_channel_selection_policy(NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_SUCCESSFUL)

But this is clearer:

Timeslot periods The Gazell Link Layer supports the following minimum timeslot periods.

600us timeslot period, nRF51 Gazell Device to nRF51 Gazell Host. 500us timeslot period, nRF51 Gazell Device to nRF24Lxx Gazell Host. In addition, the relation between the Device and Host timing parameters should be as follows:

The Host listens to each channel in a GZLL_RX_PERIOD number of microseconds, where GZLL_RX_PERIOD is the heartbeat interval in the nRF24Lxx devices. This Host GZLL_RX_PERIOD must be greater than the time required committing 2 full transmission attempts on the Device (including ACK wait time).

And more details here:

The length in microseconds of a Gazell link layer timeslot.

The minimum value of the timeslot period is dependent of the radio data rate (

See Also

nrf_gzll_set_datarate()). For NRF_GZLL_DATARATE_2MBIT the timeslot period must be >= 600 us. For NRF_GZLL_DATARATE_1MBIT the timeslot period must be >= 900 us. For NRF_GZLL_DATARATE_250KBIT the timeslot period must be >= 2700 us. Parameters period_us The timeslot period in microseconds. Return values true If the parameter was set. false If Gazell was enabled.

[LucidityCrash]

yeah this : nrf_gzll_set_timeslot_period(GZLL_RX_PERIOD / 2); is really confusing the way I'm reading it and the doc for the function https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v4.x.x/doc/html/group__gzll__02__api.html#ga3347094a64c07793c773c4fdf4bc4bff

is that GZLL_RX_PERIOD is the time for 2 attempts but nrf_gzll_set_timeslot_period() sets the time for a single attempt so the boards should be 1800 and the reciever should be 900

[SimonMerrett]

I think what I implemented was "correct" frequency hopping but for a single Tx/Rx pair, rather than a 2*Tx/Rx trio. If the boards are 1800 and Rx is 900, I think that should work because the Tx should come back round to channel x1 after channel x3 at the same time as Rx comes back to channel x1 after cycling through x1, y1, x2, y2, x3, y3...

[karosc]

Hey. I am also experiencing problems on reliability, but they are very intermittent. In some situations, I thought it was a battery problem so I just replaced the battery on the half that was giving me problems, but then after just a couple of weeks, I had the same problems again, and always on the left half. Moving the receiver around helps, but I'm not sure about which positions are best. Right now is in the middle of the two halves, like 10 centimeters away of each other. I also noticed that turning wifi on or having the phone close disturbs it, but my bluetooth mouse doesn't seem to cause any trouble for example.

Is there any known configuration that improves the reliability? Oh, and do you have any guide to flash each halve? Never did it before.

Very weird, I experience the exact same issue. Either my keypresses are not recognized or they come in way after I press the key. Sometimes they come in repeating indefinitely until I try to press another key, which interrupts the repeat. This is always only on the left half. The problem can be resolved for a while by taking out and reinserting the battery (effectively turning the transmitter off and on, but the problem always comes back.

[SimonMerrett]

Either my keypresses are not recognized or they come in way after I press the key.

Very similar to (one of) my issue(s):

Often I will have to press a key two or three times before it is registered and when it finally registers I get three of that key appear onscreen. I also get double-typed keys when I only meant to press once

[LucidityCrash]

Hey. I am also experiencing problems on reliability, but they are very intermittent. In some situations, I thought it was a battery problem so I just replaced the battery on the half that was giving me problems, but then after just a couple of weeks, I had the same problems again, and always on the left half. Moving the receiver around helps, but I'm not sure about which positions are best. Right now is in the middle of the two halves, like 10 centimeters away of each other. I also noticed that turning wifi on or having the phone close disturbs it, but my bluetooth mouse doesn't seem to cause any trouble for example. Is there any known configuration that improves the reliability? Oh, and do you have any guide to flash each halve? Never did it before.

Very weird, I experience the exact same issue. Either my keypresses are not recognized or they come in way after I press the key. Sometimes they come in repeating indefinitely until I try to press another key, which interrupts the repeat. This is always only on the left half. The problem can be resolved for a while by taking out and reinserting the battery (effectively turning the transmitter off and on, but the problem always comes back.

Very strange ... are you using the Firmware in the repo or from the supplier, or did you build yourself ? I've been using this for over a year and had a few issues at the beginning but some related to battery levels I believe but other than that it has been pretty good.

[karosc]

I modified the firmware to allow for an additional column for my build. So somewhat customized. I also tried modifying the channel hopping code according to @SimonMerrett comments and also tried removing it entirely; neither really solved my problem. Interestingly, I find the issue comes up mostly after my PC is been off/sleeping for a while.

[SimonMerrett]

As I'm part of the problem here I thought I'd change the timings and see what happens. Both halves of my keyboard are now

nrf_gzll_set_timeslot_period(GZLL_RX_PERIOD);

with the receiver left as GZLL_RX_PERIOD / 2 So far, so good. I will update further once I have had a bit longer to see if there are any more issues.

[SimonMerrett]

I turned my debounce to 10, from 5 as per original repo, and I am finding far fewer repeated typped keys (although some slip through as you can see!). I may shift this up again, as I am not a particularly fast (= slow) typist and my outemu switches are at the budget end of things and are probably not helping in terms of debounce.

[LucidityCrash]

Often I will have to press a key two or three times before it is registered and when it finally registers I get three of that key appear onscreen

Just a silly question ... what version of the nRF5 SDK are you building against ? I tried to build against a newer version that the v11 one specified and I got some really weird behavior similar to that.

[SimonMerrett]

what version of the nRF5 SDK are you building against ?

Not a silly question. I had to go and check though! Yes, version 11.0.0 release date: Week 10 2016