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!

[karosc]

Currently, the host has a timeslot period of 900ms (GZLL_RX_PERIOD / 2) and two timeslots per channel, making for a total 1800ms of listening on a channel before moving onto the next . The devices have a timeslot of 1800ms and two timeslots per channel, so they try transmit on each channel for 3600ms before moving onto the next; this scheme keeps the channel tables between the host and device in-sync. However, the nordic docs state that:

This Host [period] must be greater than the time required committing 2 full transmission attempts on the Device (including ACK wait time).

If 2 full transmission attempts on the devices happen in 3600ms, then the host must be listing on a channel for that duration, but we currently have it only listening for 1800ms. I think this is our problem. The nordic docs would suggest that you increase the GZLL_RX_PERIOD on the host so it is listening for 3600ms, but the problem with that is our host has twice as many channels and our device and host would fall out of sync with respect to which channel they are transmitting and listing on.

We may be able to solve this by setting both host and device to have timeslot periods of 900ms, but then setting the device to have 4 timeslots per channel. This way the host listens on each channel for 1800ms, which is large enough to capture two transmission attempts from the device (2 times the 900ms timeslot period). But because we set 4 timeslots per channel on the device, it stays on a channel for twice as long as the host before moving on to the next one in the list, allowing the host and device channel heartbeat to stay in sync.

This took me a while to realize, and I know I am not explaining very well here. Maybe diagram it to make things easier.

I have made these changes in my fork, although I did not boost the tx_power and kept the datarate at 2MBIT, so my period is 600ms. Also, keep in mind my firmware is adapted to have one more column than the redox. So far so good, I'll report back after a day or two to let everyone know if things remain synced or not.

[SimonMerrett]

EDIT Ignore my nonsense about nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync() below - it clearly has no effect on the Host!

---

@karosc, thanks for persisting with this. I'm sure we will work it out! I have read a bit more on the Nordic docs, trying to better understand timeslots, channel hopping, transmit durations, ack durations, retransmit behaviour etc, etc.

This Host [period] must be greater than the time required committing 2 full transmission attempts on the Device (including ACK wait time).

Understanding the reason for this is key, which I am only starting to do! The reason is because sync is never perfect and the Device may begin a transmission before the Host is ready (still on previous channel for example), in which case reception will not happen and no ack will be sent. By having the "Host [period]" greater than the time for 2 full transmission attempts, it guarantees that a subsequent transmission will be fully captured if the Host is lagging the Device (in terms of sync). Well that's my latest understanding!

we know nrf_gzll_set_timeslots_per_channel() only applies to in sync device and host. We also know that nrf_gzll_set_timeslot_period() should be >= 600us for 2 MBit/s or >= 900us for 1MBit/s. I cannot yet tell whether this allows for an ack listening period after the transmission period.

After the transmit (and hopefully time to listen for and receive an ack), the transmitter waits until the next timeslot to either retransmit the same packet (if no ack received, until ack received or max retries is reached), transmit the next packet (if ack was received) or change channel (if timeslots per channel has been reached) and then carry out a retransmit or transmit next packet (as per the first two cases).

As we do not know how long each transmission actually lasts, except to use as a guide the minimum duration from thenrf_gzll_set_timeslot_period() documentation. So let's think of nrf_gzll_set_timeslot_period() as the period between the start of transmission, rather than the time taken to complete a transmission (which I was thinking before).

If we have two transmit attempts, 1800 between the start of each, we get 3600 us before a channel change on the Device. But on the host side it is only listening for 2x 900 = 1800, so we are hoping that the beginning of one of the two transmissions for a given channel is in the first 900 us of that total 1800 us receive period (because there may not be time to receive if it begins in the last 900 us?). This is definitely wasting a transmission. I think increasing nrf_gzll_set_timeslots_per_channel() to 4 and reducing nrf_gzll_set_timeslot_period() to 900 from 1800 on the Device is a good idea.

I also wonder if there are too many retries allowed on my Device, which could potentially be blocking the Tx FIFO so subsequent presses are being ignored (FIFO full will not accept more data). So I may try reducing those.

further, moving away from in-sync Device/Host pairs, we should consider the sync process. I wonder if our two-Device-one-Host systems are resulting in the two Devices wrestling the sync of the Host each time they transmit alternately. So we could find the Host out of sync with a Device more often than in a one-Device-one-Host system, but I'm speculating here. I noticed that @karosc increased his nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*(timeslots_per_channel+1)) on the receiver and keyboard. My current code is for nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*(timeslots_per_channel)). However, the Nordic docs say:

This value should be set so that the Device transmits on one channel while the Host goes through a full channel rotation, i.e., channel_table_size*timeslots_per_channel. This ensures that the channels on the Device and Host will coincide at some point. Further increasing the value has been observed to provide better performance in the presence of interferers.

So I believe we are both doing this wrong as channel_table_size = 6 for receiver / Host. 6 channels in the table * 2 timeslots per channel * 900 or 600 us per timeslot * 6 channels (again! to cycle through them all) is 64,800us or 43,200us to complete a full Host receive cycle when not in sync. This equates to 10,800us or 7200us on each of its six channels, remembering that only every second channel will match one Device. So this means that the window for a channel is effectively 10800us / 64800us = 17% duty (although that may not be too bad). I will refer to such a period of reception on a channel when not in sync (before switching to the next channel) as a "sync-period" = e.g. the 10800us referred to above.

On the Device, in the meantime, it has tried transmitting 3 channels in the table * 2 timeslots per channel * 900 or 600us = 5400us or 3600us for each of its three channels. This means if it starts on the channel after the matching one for the current "sync period" then by the time it gets round to the correct channel for the current "sync period", the "sync period" will have ended and it will be at least 10800us before another channel which matches this Device will be listened to again by the Host.

So, I think the Nordic docs, with respect to nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*timeslots_per_channel) is only referring to the Device but that the Host needs to be nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(1) unless this parameter has no effect on the Host (which I cannot see mentioned anywhere so I assume it applies to both Host and Device).

You also see that Nordic recommends an even longer nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync() when in the presence of interferers, so I think I will try doubling this on the Device after I try setting nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(1) on the Host.

Finally (from this round of reading and thinking) I note that a larger channel table can help coexistence with interferers. I think I will consider this too for a future round of testing.

In summary, I will now try:

Device

• nrf_gzll_set_timeslots_per_channel(4)
• nrf_gzll_set_timeslot_period(900)
• nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*timeslots_per_channel*2)
• nrf_gzll_set_max_tx_attempts(20)

Host

• nrf_gzll_set_timeslots_per_channel(2)
• nrf_gzll_set_timeslot_period(900)
• nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(1)

I may implement these individually to identify which had most effect, if any.

[karosc]

So I believe we are both doing this wrong as channel_table_size = 6 for receiver / Host. 6 channels in the table 2 timeslots per channel 900 or 600 us per timeslot * 6 channels (again! to cycle through them all) is 64,800us or 43,200us to complete a full Host receive cycle when not in sync.

I am not understanding why we need to multiply by 6 twice. In my fork nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(channel_table_size*(timeslots_per_channel+1)) was derived from components\properitary_rf\gzll\nrf_gzll_constants.h. The default value is 15 timeslots for a channel table of 5 and 2 timeslots per channel when in sync. Not sure why the default is larger than channel_table_size*timeslots_per_channel, but I upped mine accordingly.

[SimonMerrett]

I am not understanding why we need to multiply by 6 twice

We do not. I made a big error and have placed an EDIT at the top of my post above. In the Synchronisation section of the docs it is clear that the Host does not use nrf_gzll_set_timeslots_per_channel_when_device_out_of_sync(). Sorry for the confusion.

[LucidityCrash]

@SimonMerrett My head just exploded :)

Device

* `nrf_gzll_set_timeslots_per_channel(4)`

* `nrf_gzll_set_timeslot_period(900)`

Host

* `nrf_gzll_set_timeslots_per_channel(2)`

* `nrf_gzll_set_timeslot_period(900)`

but isn't this where we started ... my pull request : https://github.com/mattdibi/redox-w-firmware/pull/7/files note the device is 4 timestlots per channel with a 900 period and the host is 2 timeslots (the default so not explicitly set) per channel with a 900 period

[SimonMerrett]

but isn't this where we started

Yep, probably! Although going "back" to those settings is a huge improvement over what I had been putting up with for a few weeks, I still have the same odd missed / double-tapped keys. I briefly toyed with nrf_gzll_set_sync_lifetime() yesterday but along with a low number of retransmits, it seemed to lose a great deal of keypresses, so I turned it off and increased the retransmits from 20 to 100 (I had been using 200).

I think I will look at a larger channel table next, as that is specified as a fix for interference and we know that these setups are certainly vulnerable to other 2.4 GHz transmissions. I really should get some debug going on this keyboard, to know how many retransmits are attempted for example, how long the loops are taking (does the matrix scanning for the extra column/row on those of us with custom hardware cause race conditions etc?).

[karosc]

I am still having the same problem. I need to start thinking about this a bit more technically I guess. It is very weird that my issue only occurs on the left half and only after a long idle period or after a pc restart. For some reason the left half falls out of sync with the host and cannot seem to get back into it.

I would love to know how to get debug output on this keyboard, I imagine it is possible through the openOCD console?

[SimonMerrett]

It is very weird that my issue only occurs on the left half and only after a long idle period or after a pc restart

You could try swapping the order of the channels in the host list to see if a) different order within the channel table makes a difference and afterwards revert to the original order but change which channels left and right use to check b) whether the channels associated with the left are somehow less effective than the one's allocated to the right.

[SimonMerrett]

I think there is some kind of debug through the qmk app/console but I haven't looked for a while.

[LucidityCrash]

trouble is that is debugging at too high a level ... you really want to see what is going on in the nrf5 code You can use openOCD and GDB together ... Its been a very long time but I seem to remember doing something that just put output in the OCD console.

[karosc]

Its been a very long time but I seem to remember doing something that just put output in the OCD console.

If you could provide some example code, that would be very helpful for me.

[karosc]

So, I swapped the batteries on my keyboards and the issue started happening on the right half. So now this seems to have become a power delivery issue for me. I check the problem battery (a CR2032 coin cell) and found it was giving 2.89v, which is well within the 1.8 - 3.6v spec of the nRF51822.

Now I am wondering if I need a second voltage regulator external to the nRF51822? Or maybe my batteries are just crappy quality, I just changed them last month.....they should not be dead.

[danielo515]

So, I swapped the batteries on my keyboards and the issue started happening on the right half. So now this seems to have become a power delivery issue for me. I check the problem battery (a CR2032 coin cell) and found it was giving 2.89v, which is well within the 1.8 - 3.6v spec of the nRF51822.

Now I am wondering if I need a second voltage regulator external to the nRF51822? Or maybe my batteries are just crappy quality, I just changed them last month.....they should not be dead.

mmm, that is something very similar to what happens to me... not sure if my batteries are crappy, I just bought a bunch some time ago. Like you, it usually happens on left half, and replacing the battery usually helped, but one day I decided that one week of battery life was not normal, specially when I didn't changed the other half in half a year. But I never tried swapping them, that is an interesting experiment.

[SimonMerrett]

I am using 2x AA for each side, just checked and my right side is at 2.54V. AAs should not have any issue with delivering sufficient current for the NRF51 so I don't think power supply really explains this issue for most people. But then again, I'm sure it does not help! Can you hook up to a power supply (or 2x AA) to confirm it doesn't solve the issue completely for you?

[LucidityCrash]

Its been a very long time but I seem to remember doing something that just put output in the OCD console.

If you could provide some example code, that would be very helpful for me.

I wish I could but I can't for the life of me remember what I did and I don't appear to have a copy of the code I was using at the time.

[Pastitas]

So, I swapped the batteries on my keyboards and the issue started happening on the right half. So now this seems to have become a power delivery issue for me. I check the problem battery (a CR2032 coin cell) and found it was giving 2.89v, which is well within the 1.8 - 3.6v spec of the nRF51822. Now I am wondering if I need a second voltage regulator external to the nRF51822? Or maybe my batteries are just crappy quality, I just changed them last month.....they should not be dead.

mmm, that is something very similar to what happens to me... not sure if my batteries are crappy, I just bought a bunch some time ago. Like you, it usually happens on left half, and replacing the battery usually helped, but one day I decided that one week of battery life was not normal, specially when I didn't changed the other half in half a year. But I never tried swapping them, that is an interesting experiment.

This has been plaguing my left half for a while, if the batteries drop below 2.9V aprox the problem manifests, does not matter what the battery quality is, nor the brand or anything else.

This is such a problem for me that i've started (against good judgement) to think about trickle charging those cells to stop having to buy them every 3 weeks

[LucidityCrash]

how bizarre ... I Use my Redox 8 hours a day 5 days a week ... think I've changed the Batteries once maybe twice in 2020.

[mattdibi]

... to stop having to buy them every 3 weeks

... one day I decided that one week of battery life was not normal...

Just dropping by to say that those figures aren't normal. Here I somewhat approximated the expected battery life for the Redox Wireless and, after using 3 different Redox Wireless keyboards during the last 3 years daily, I stand by it. Using it 8 hours a day 5 days a week should result in changing batteries once/twice a year. I can expect something more but once a week or every 3 week is clearly an outlier.

To add to this: lately (last ~6 months) I stopped turning the keyboards off and it doesn't seem to affect battery life much (still running the same pair).

if the batteries drop below 2.9V aprox the problem manifests

This is also what I observed. Even though 2.9V is well within the nRF51822 spec sheet, the connection start having issues around this voltage (double key presses, missing keys, high latency). I think it as to do with the battery not keeping up with the power consumption of the nRF chip. I should point out that this doesn't affect the battery life estimate cited above.

For those of you experiencing problems with battery life I would suggest double checking the boards for shorts. One week for a CR2032 is not nornal.

[harshitgoel96]

... to stop having to buy them every 3 weeks

... one day I decided that one week of battery life was not normal...

Just dropping by to say that those figures aren't normal. Here I somewhat approximated the expected battery life for the Redox Wireless and, after using 3 different Redox Wireless keyboards during the last 3 years daily, I stand by it. Using it 8 hours a day 5 days a week should result in changing batteries once/twice a year. I can expect something more but once a week or every 3 week is clearly an outlier.

if the batteries drop below 2.9V aprox the problem manifests

This is also what I observed. Even though 2.9V is well within the nRF51822 spec sheet, the connection start having issues around this voltage (double key presses, missing keys, high latency). I think it as to do with the battery not keeping up with the power consumption of the nRF chip. I should point out that this doesn't affect the battery life estimate cited above.

For those of you experiencing problems with battery life I would suggest double checking the boards for shorts. One week for a CR2032 is not nornal.

For the battery reason, I am thinking to hook it upto a lipo. With a USB charging ckt and step down converter.

Just to be clear, I am not facing poor battery problem, but bad connectivity. And as you pointed out it's around 2.8v from the cell. Using lipo and a 3.3v regulator, I think it would solve my problem

[relokin]

First of all, @mattdibi thank you so much for this keyboard! Its design and features is exactly what I have been looking for in a keyboard for a long time now.

Just dropping by to say that those figures aren't normal. Here I somewhat approximated the expected battery life for the Redox Wireless and, after using 3 different Redox Wireless keyboards during the last 3 years daily, I stand by it. Using it 8 hours a day 5 days a week should result in changing batteries once/twice a year. I can expect something more but once a week or every 3 week is clearly an outlier.

I've also done some measurements with a multimeter (not as accurate) on my keyboard and they are on the same ballpark as your measurements. With ~2uA power draw at idle state even the nominal capacity of CR2032 should be enough for a long time - the firmwares goes into low power very soon after the last key press (500cycles @ 1kHz or 0.5 sec), if you stopped typing to think and read, chances are that the keyboard is in low power mode waiting for an interrupt.

To add to this: lately (last ~6 months) I stopped turning the keyboards off and it doesn't seem to affect battery life much (still running the same pair).

I agree, switching the keyboard off is not going to make a significant difference. Again at 2uA the battery would last 12.5 years.

I am a little worried about the effect on the peak power draw. Apparently CR2032 is not great at high power draws [1] which can have a significant impact on the effective capacity we use. The report doesn't have the numbers for 5mA peak draw and the duty cycle it assumes is way to high compared to what we would get. In theory, these problems do not seem to be significant, if I read it right we should still have a significant fraction of the nominal battery capacity.

if the batteries drop below 2.9V aprox the problem manifests

This is also what I observed. Even though 2.9V is well within the nRF51822 spec sheet, the connection start having issues around this voltage (double key presses, missing keys, high latency). I think it as to do with the battery not keeping up with the power consumption of the nRF chip. I should point out that this doesn't affect the battery life estimate cited above.

I've also encountered problems close to 2.8V and it might be that at this point while the battery is not drained we can get enough draw to run the radio without noticeable error rates. What is scary though, again if you look at the report, is that the battery voltage drops to 2.8V immediately after it's used. If that's the case, we might be seeing problem well before we reach the battery capacity limits.

[1] High pulse drain impact on CR2032 coin cell battery capacity

[Pastitas]

this sounds similar to what this video talks about https://www.youtube.com/watch?v=s6SAjQYhssk It points to this hackaday article that talks about what problems can come from coin cells and peaky current patterns like ours.

Talking out of my ass here but maybe some capacitors could allow for the power draw on the coin cells to be a bit more filtered?

[SimonMerrett]

I have been seeing progressively worse rf link over the last week or so. I decided to recharge (top up) my 2x AA NiMH rechargeable cells per keyboard half. Meanwhile, I put some non-rechargeable alkaline AA cells in to carry on working while my rechargeables are charged. The difference in reliability is astounding.

The multimeter reports 2S battery voltage at 3.21V (versus ~2.7V last time I measured my rechargeables). I definitely think this could be a key. Several of us are using higher power transmissions so this could be drawing more current in peaks and thereby pulling the voltage lower, faster. When you go to measure the voltage, perhaps the cell has recovered slightly so it appears less significant a drop compared to during periods of transmission (perhaps leave the multimeter attached during typing and see what that shows).

The other thought about capacitors could help but remember that ideal capacitors don't leak current and real capacitors do leak current. So bear that in mind when you select one. I clearly do not need a buffer/smoothing capacitor with AA cells but I will certainly now look into using a 3.3V supply, either boosted from my 2x AAs or add a cell (harder) and use an LDO. If I find a suitable low quiescent current boost converter, I will certainly post details here. Please bear in mind that my aerodox has modular daughter PCBs so swapping out the bare nrf51 module for one with a boost circuit will be easier for me than modifying a Redox-w and my changes may not make your life hugely simpler to convert your keyboards.

I'm very pleased with the improvement and I would urge anyone else who is not sure about their configuration to try and source a reliable 3.3V power supply and replace the battery with it to test whether a stable 3.3V results in similar improvements for them.

[Slavfot]

I have been seeing progressively worse rf link over the last week or so. I decided to recharge (top up) my 2x AA NiMH rechargeablle....

Thanks SimonMerret for keeping us updated with your progress. What about using a 3.3V regulator on the keyboard like one of this: https://www.mouser.se/datasheet/2/268/MCP1700_Data_Sheet_20001826F-737536.pdf

[SimonMerrett]

What about using a 3.3V regulator on the keyboard like one of this:

@Slavfot the link is broken but the mcp1700 is a linear low dropout (LDO) buck converter. Our problem is that we cannot generate sufficient voltage to drive the apparently required current of the nrf during radio operation. This means our batteries at 2.8V, for example, when an LDO is attached will merely be seen as 2.8V minus the dropout voltage of the regulator (say 0.1V ), making our problem worse. What we need, if we are going to stick with the coin cells or 2x AA is a boost converter. I am looking at making a boost circuit to take our 2V - 3V cells up to 3.3V at the nrf power input. I'm thinking how this could be done in a way that would be easy for people to retrofit to their Redox-w keyboards without spoiling the enclosures or having to use a different type of battery. So far I think the MCP16251 could be a good candidate for this application, as it appears to come in a small footprint package, works with small inductors and has acceptably low quiescent current (4uA) to prolong the life of the coin cells.

[Slavfot]

@SimonMerrett Ok thanks for explaining. I'll try using my keyboard with a powersupply at 3.3V and see if my problem disappears. I'm also using my own pcb designed based on the redox-w, and fortunately added breakout points for battery.

[azumafuji]

I'm glad I found this topic because I am also experiencing these issues with my redox-w. I purchased my rather than built but happy to tinker. I'm missing presses on the right side with the shift key and I'm getting multiple stutters with the s key on the left. There is a bluetooth mouse sitting between the two halves and a bluetooth headset is used in the vicinity. I see the issues mostly when I'm using the headset. No problems typing up this message (yet) with the headset off. There are two options discussed here so I'm not sure if either will solve my problems. I just ordered a programmer and I'll try some of the changes discusssed here to see if it improves reliability for me.

[SimonMerrett]

I am going to order an aerodox motherboard with the MCP1640 because it is easier for me to buy than the MCP16251 and is footprint compatible with the MCP16251. The no-load current is significantly higher but if the NRF52 works with this, it will likely work with the MCP16251 for those who want to keep using coin cells.

[Pastitas]

Do you have the schematics for that mod? I am willing to modify the original redox_w pcb to add support for it but i don't have the knowhow to design the circuit you where talking about What about the retrofit board thing, is that still being thought about?

[SimonMerrett]

So my adaptation, the aerodox is totally WIP so I haven't published details except to the team members on the hackaday project. I'll let anyone join the project but I don't want to publish publicly until I'm happier with it. https://hackaday.io/project/171535-aerodox

Here is the schematic for the booster test motherboard. If it works on my aerodox, I'd consider making a converter for the redox-w if someone with a redox-w was prepared to explain what space limitations are for any adapter board. For example, it may be possible to replace the existing battery holder with a low profile PCB with another battery holder and the boost circuit. But if the cases do not allow for this, then another way would have to be found.

[karosc]

As a person with a hand wired keyboard and custom case, I like the idea of a PCB+battery holder unit that I could plop in my case (which has plenty of room) with some hot glue to help regulate the coin cell battery voltage.

[SimonMerrett]

As a person with a hand wired keyboard and custom case, I like the idea of a PCB+battery holder unit that I could plop in my case (which has plenty of room) with some hot glue to help regulate the coin cell battery voltage.

Send photos/dimensions for what you have in the area of the battery holder. Or do you want just a battery holder footprint, boost circuit and two plated through holes for wires to the old battery contacts?

[karosc]

I think have more than enough space. My case is crude and was not designed to be wireless, I retrofitted it afterwards. Because the case itself has tenting, there is a bunch of empty space similar to the manuform.

[SimonMerrett]

Wow, nice dactyl look. Do you ever turn the LEDs on? So you would disconnect (cut the wires?) the CR2032 holder and attach a boost circuit in between?

[SimonMerrett]

My test will look something like this.

[karosc]

Interesting, I assume the battery mounts on the other side?

[SimonMerrett]

Nope, it's mirrored on the other side for the other half of the keyboard. As I said, I use 2x AA for each half, at the rear of the main keyboard. They do the tenting for me, with a single standoff on each side to help. This PCB mounts on the main keyboard PCBs with pin headers, as I knew I was unlikely to get everything right and this would give me more flexibility over microcontroller and radio options in future. See the hackaday project link above for more images if you are interested.

[karosc]

Wow, nice dactyl look. Do you ever turn the LEDs on? So you would disconnect (cut the wires?) the CR2032 holder and attach a boost circuit in between?

I used to turn on the lights when it was wired, and I had the power to run them. Now the strips are 100% disconnected to preserve battery. Instead, I strapped a 4-led strip to my receiver to display layer and caps lock states.

Ideally, I'd like to replace the whole battery holder with a new PCB that has the boost circuit and batter holder built in.

[SimonMerrett]

Do you want 2x AA for longer life or stick with CRXXYY? Presume you are using CR2032?

[karosc]

I'm not sure. Are there any downsides to going AA besides the size?

[SimonMerrett]

I usually think there are more upsides to AAA or AA than lithium coin cells. Capacity, rechargeability, not lethal if swallowed by children and pets, more available. The only risk is if you use a battery holder which allows you to put the battery in backwards without any reverse polarity protection, you may damage your NRFs. I have a mosfet in the return path to the battery to protect my NRF motherboard from reverse polarity mistakes on my part. Easy to add one in to a boost circuit.

[karosc]

Interesting, never considered the child safety. I'd be willing to give AA or AAA shot. I think it might be better to have the boost circuit as its own thing then. It could have GND/VCC in and GND/VCC out with boost and MOSFET between. I could then hook up that PCB to something like these:

https://www.amazon.com/dp/B07TB4HDYH/ref=cm_sw_em_r_mt_dp_C1ARHY7P5AX6G8QAN6RW?_encoding=UTF8&psc=1

[SimonMerrett]

something like these:

Yep, they'd work and you could always switch back to CR2032 in the mean time. I should be ordering my PCBs tonight or tomorrow. Will let you know how the test works out and can make an inline board if successful.

[mattdibi]

I'm also using my own pcb designed based on the redox-w, and fortunately added breakout points for battery.

Dropping by just to point out that the redox-w as is does expose the pins to use with an external power supply (usually the STLinkV2 programmer). Those are on J_PROG_PORT1

@SimonMerrett Thank you for sharing your insight. I'm really interested in what you find out and the result of this.

[SimonMerrett]

The PCBs for my boosted version of aerodox are held up in Germany en route from China, due to bad weather. Will post findings as soon as I have any.

I could make a breakout for J_PROG_PORT1 but you guys with cases need to advise me on whether this is a practical place to put the battery, both from a Z height / void space perspective and access for battery changes (are the cases easy to open up? What slots do they have in the side?).

[mattdibi]

Since this solution is really intriguing me I thought of two possible ways to retrofit a booster to the redox-w.

1) CR2032 booster through switch pins (SW_LEFT1/SW_RIGHT1)

Since the JS102011SAQN pins are directly wired to the battery terminals we can remove the switch (as we said in this very thread its contribute to battery life is almost non-existent) and wire to these pins a step-up converter. The ground connection can be wired from the J_PROG_PORT1 connector.

Surfing around I found this step-up voltage regulator from Pololu which is based on Texas Instruments TPS61201. It is very compact and should fit inside the existing cases by taking the precaution of wrapping it in insulating tape or a shrink wrap to avoid shorts.

The TPS61201 looks very similar to the MCP1640. @SimonMerrett do you think it is a good fit for our use case?

2) AAA booster through J_PROG_PORT1

Alternatively we can use one of those AAA battery holders and wire them through the back opening of the Falbatech's cases to the J_PROG_PORT1.

These battery holders dimensions make them fit almost perfectly inside the "L" shape of the Falbatech's cases, with the added benefit of a easily accessible on/off switch. The downside is that there's no obvious way to mechanically tie the holder and the keyboard.

Adding a booster like the one I linked above to this configuration should be trivial.

[SimonMerrett]

Hi, the TPS61201 is OK but compared to the MCP16251 I think it may be worse for battery life. The TPS61201 claims 55μA at no load while enabled (we would find it too complicated for a modification board to enable / disable the booster) while the MCP16251 claims 14μA for the same condition. I don't know what that difference will do to the battery life.

The Pololu module does have the PS pin pulled low, which is necessary for conversion efficiency at low loads like the nrf51822. So if anyone wants to try the TPS61201, do look out for the PS pin's state.

Because the case has some space, it may be possible to design a small PCB boost that replaces the coin cell holder and the battery would end up where shown in yellow in the picture. Please can you share a picture from the direction of the green arrow? Trying to understand what depth may be available.

[mattdibi]

@SimonMerrett Here you go

The TPS61201 claims 55μA at no load while enabled (we would find it too complicated for a modification board to enable / disable the booster) while the MCP16251 claims 14μA for the same condition. I don't know what that difference will do to the battery life.

That's what I was thinking. Considering that the Polulu module is faily inexpensive (5€/pcs) and I can source it locally I'm considering to give it a try (it's almost time I change batteries on my board).

Digging around some more I found a MCP16251-based booster from Canique. This too can be interesting to try out.

[SimonMerrett]

Photo is great - there's plenty of room to play with.

That Canique board looks great - shame that the shipping is more than the part price to UK (I almost said "within the EU"!).

Regarding the switch for connecting these modules - I would be tempted to see whether you can connect boost Vin to the switch NC terminal, so you can switch back and forth between the boost or direct battery connection. I'm not sure what the tolerance of the boost ICs is to having 3.3V across Vout and Ground but no potential on Vin.

[karosc]

@mattdibi, that bootster from Canique is temping for me with a hand-wired board. Know any vendors in the US that might have something like that?

[harshitgoel96]

If 2xAA battery holder can be used, then what about using A small LiPo with a charging module like this https://robu.in/product/tp4056-1a-li-ion-lithium-battery-charging-module-with-current-protection-type-c/ ? One can quickly charge the battery when required. The cutout for coin battery should allow usb port through.