redox-keyboard
redox-keyboard copied to clipboard
mattdibi
Redox Wireless Interference issues
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!
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
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.
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
@Slavfot I am having the same issue, just to confirm, you updated only the keyboard firmware, not the receiver?
@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.
That would be great, I have only found some of the entries on the receiver and am worried of breaking things even more
@AltusBaard Here are the hex to the Nrf51128 modules. They are made with the edits i mentioned above. precompiled fix.zip
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.
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.
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.
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
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
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.
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.
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.
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 ?
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.
@harshitgoel96 https://github.com/mattdibi/redox-w-firmware/tree/master/precompiled
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 ?
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).
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 ?
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 ?
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.
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.
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
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.
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
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.
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.
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 ?
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).
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.
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 :)
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.
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.
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 :)
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 ?
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!
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.
@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.
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
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...
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
@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
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?).
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?
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.
I think there is some kind of debug through the qmk app/console but I haven't looked for a while.
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.
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.
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.
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.
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?
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.
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
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.
... 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.
... 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
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
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?
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.
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
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.
@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.
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.
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.
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?
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.
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.
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?
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.
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?
My test will look something like this.
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.
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.
Do you want 2x AA for longer life or stick with CRXXYY? Presume you are using CR2032?
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.
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
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.
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.
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?).
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.
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.
@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.
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.
@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?
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.