Redox Wireless Interference issues #55
Comments
|
I also found these lines in main.c that i suspect that i can add number of channels to?: |
|
Ok, i got it to work now... That did not help. 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. |
|
Hi Slavfot, sorry for the late response. I'm having a hard time answering to the issues here right now. Cheers, |
|
@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. |
|
That would be great, I have only found some of the entries on the receiver and am worried of breaking things even more |
|
@AltusBaard |
|
Thanks, uploaded them and testing, seems to be working. Also had a low battery in one, think that also might have had an impact on it. |
|
Great to hear that it worked! |
|
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: mattdibi/redox-w-firmware#2 mattdibi/redox-w-firmware#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:
To be clear, I left in 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. About this: |
|
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. 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. |
|
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 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. |
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:
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. |
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. 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. |
Yes, correct.
Sort of. My design will work with the MCP1640 but I used the MCP16251 in my implementation because the datasheet promised better no-load quiescent current, which should lead to better battery life, especially for anyone who uses a coin cell to power their keyboard (I use AA cells so less of a concern for me).
I haven't looked closely but the 80uA quiescent current and 60-90% efficiency suggested by the datasheet makes me think your coin cells won't last too long. However, it does look like it would take a lipo cell and provides a regulated 3.3v over the duration of the lipo discharge voltage range. Good find.
I do not recommend using this unless you will guarantee to detach the keyboard from the battery during charging. The reason is that the charger needs to decide when to shut the charging current off (I think during the transition from constant current to constant voltage phase but haven't checked) based on the current passing through it. This means that the keyboard drawing current at the same time will potentially cause issues with the charging profile. While in sleep mode, which is most of the time, this should not be a problem but I don't want to recommend this chip without you understanding that you need to make sure the charging remains safe. There are chips which allow you to charge the battery while supplying current to the keyboard, such as the MCP73871. The main part of the system you propose which I think is missing is any form of overdischarge protection. You should look to add that so that you don't kill your lipo the first time you use it. Ps, for some reason, the hyperlinks for those datasheets seem to link to this repo, for me at least. |
Thanks for the recommendation.
Sorry my bad, fixed. |
I don't know and it will take some reading to understand if any changes need to be made. You should think about what solution you will use for overdischarge protection. Please? JLC must offer something like the DW01. |
If I understand the spec then the MCP73871 has built in overdischarge protection. From the datasheet: |
Brilliant - I had not remembered that. |
|
I've done some more testing regarding plugging the receiver to the usb-hub vs motherboard, Can it be that the LDO on the receiver assembly doesn't have any filtering capacitors resulting in a power source with noise and brief voltage surges? |
|
I'm using a different adapter board for the link between the Pro Micro and the NRF51822 on the receiver. So I haven't paid attention to the regulator on the redox w receiver and whether it implements good values of capacitors. It's possible that there is a power supply noise issue on the USB hub but I would expect the NRF module should have some filtering on it. Have you checked to see if there is any difference between the USB hub voltage and the motherboard? Maybe a difference of 0.5v would make some difference? |
I looked at the datasheet. I think their UVLO does not protect the battery from overdischarge. I think it protects against the battery back feeding a supply that is at a voltage below the battery. This chip will not shut off the battery to the output load when it discharges to a certain level. The best they give you is a low battery output (LBO) on the Stat1 pin. The problem is that this pin is also used to signal when charging. They expect you to attach an LED to this pin. If they had not combined the charging state with this pin you could have used a mosfet to shut off the load when it went logic low (from high Z state) as the low battery voltage occurred. So this probably won't do what you need unless you add more protection to it. Sorry. |
|
I don't know if this design is any good, but there is this pro micro with nrf replacement that has a lipo charger builtin. Maybe that schematic would serve our purposes? |
I've also been looking at migrating to nrf52 based designs. The nice!nano looks quite appealing, gives a lot of flexibility with lipo, adds a usb-c, has a big community and it would allow us to get rid of the custom firmware using zmk. But the nice!nano has been out of stock for quite some time now. The other option would be to get an Adafruite feather nRF52840 or any other nrf52 base micro replacement. Another option would be to update the core module to something similar to a core52840 but soldering is more complicated (needs hot air or reflow oven) and would need to add a lipo charge (and a usb port?) separately. |
Actually we don't need that many PIO and we could ignore the inner pins of the core52840 which would make it easier to solder. |
Neither of these designs appear to use any undervoltage overdischarge protection. Perhaps they rely on performance dropping off when the battery gets too low, which forces you to recharge them. They both use low dropout linear buck regulators but the advertised dropout is negligible at the low currents the keyboards demand.
This would be a good move in the longer term. There are two key advantages I can see with this. Firstly, using the module that Yoric recommends, it appears to be 5V to 1.7V input battery range. Which means you could power from a lipo connected only using the TP4056 + protection modules you get everywhere. The second reason is that you may be able to connect straight to any PC which has bluetooth radio, without needing a separate receiver board and needing to worry about USB hubs spoiling performance. Joric also does NRF51 firmware which removes the need for a receiver but it means you need to get to grips with the QMK running on your NRF51822. |
Actually in the repo you can see joric has made his boards compatible with zmk, so that's interesting point there |
Are lipo batteries susceptible to overdischarge problems? If their capacity degrades then that's a problem and we have to take it into account. If on the other hand, their charge drops quicker when high currents are drown then that's less of a problem, the voltage will quickly drop to something below the operational point.
I am not too worried about the receiver, it would be nice to get rid of it but it's not my primary concern. nrf52 is nice in that it's supported by newer SDKs (I think Nordic stopped supporting nrf51 at around SDK 12) and it's also supported by Zephyr. ZMK seems to be gaining momentum. |
This is the responsibility of each person to research and satisfy themselves of. Opinions are mixed, from my knowledge. Most lithium safety issues related to overdischarge appear to be when attempting to recharge an overdischarged battery at full constant current. Apparently this does present a safety issue. However, the trickle charging feature in many charge controllers is designed to avoid a dangerous situation for an undervoltage cell. So in this case, it will lengthen the time it takes to recharge your batteries. I do not know how it impacts life cycles of the battery. |
|
@SimonMerrett, any word on how the boost circuit is working? |
Yep, great! No issues from the past. Batteries (2x AA per half keyboard) haven't needed changing, so quiescent current must be low enough for my needs. I can still press more than one key in the same column/row and have both detected (which I couldn't before). No need for multiple key presses. Not tested range (my receiver is taped under my desktop, below where the keyboard sits) but I would not hesitate to make this change again if running from lower voltage batteries (ie lower than 3.3v). |
|
Just wanna register my interest in a version of the Redox Wireless that doesn't require a USB dongle (i.e. bluetooth BLE). I don't know anything about how this works (just saw that modules like nice!nano exist, which gives me hope) but it would make me a very happy camper :) If I can help somehow would love to - I'm a pro programmer, just never have touched custom keyboards before besides using them. |
|
You maybe want to look at the https://github.com/joric/bluetosis @osdiab |
|
Hi @osdiab, I think that at this point in time your best bet to convert a Redox to bluetooth (and therefore not need to have a USB dongle) would be to grab a wired Redox PCB, two nice!nanos and write the code to adapt the Redox to ZMK. Here's the tutorial from the official ZMK documentation on how to port a keyboard to ZMK. I would have done it myself but I lack the necessary hardware and time to do it. |
|
Hi guys, I just wanted to let you know that I managed to use the bluetosis code as a basis for converting my Aerodox (based on redox wireless) to bluetooth (no need for a separate receiver). It obviously won't work as-is with redox wireless and there are still some bugs (not as responsive as the receiver based version atm) but I can use a button to switch between different computers which makes my desk waaay tidier now. So if I can do it, I'm sure many of you could. |
|
Just thought I would leave my 2c here. I noticed that the keyboard would start giving issues as soon as my battery voltage went beneath 3v, as noted by some above already. What I have done now is use the same regulator that is used for the receiver and coupled that with a 3.7v 200mah LiPo I had lying around, and so far, I have not had any issues, still need to get a nice charging solution and some kind of indicator to show when the battery is low, but I am very pleased with the fact that it has been working so well. I have not done a proper test from full charge to empty to verify the time it takes to discharge, will report back when I have some numbers on that |
|
Hello, may I ask if the issue with your wireless keyboard has been resolved? |
I have not got my keyboards working reliably even if i used a reliable power source. |
Yes, deleting this code can improve it, but it seems that the battery connection has been changed very quickly. After almost 5 hours, a button battery runs out of battery. Are you the same |
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!
The text was updated successfully, but these errors were encountered: