search

mattdibi / redox-w-firmware

Firmware for nordic MCUs used in the Redox wireless keyboard
MIT License
77 stars 42 forks source link

drop outs/repeated key-presses diagnostic ? #3

Closed LucidityCrash closed 5 years ago

LucidityCrash commented 5 years ago

Not sure if this belongs in here or in the redox-keyboard repo but given its presentation I'm gonna go with here ... I've got an issue with my left hand board were it stops registering key-presses for a time and then when it starts registering them again a key gets stuck on till I press something else. I'm not using the board much at present as I'm having to relearn typing on it so I can't be certain of the exact conditions each time but I've not noticed it when I'm actively typing, it seems more like it is after the board is coming out of sleep after not having a key pressed for a while. Obviously there isn't much to go on here but the fact that so far I've only seen it on the left board seems a bit strange.
I'm going to order a replacement wireless card on the off chance it is a hardware issue but in the mean time do you have any thoughts about how can I go about getting some more diagnostic information ?

Edit : did some more research (should have done this first :) ) ... I've installed hid_listen and will run that with matrix debugging on and see if I can see anything that will help. But is their a way of getting what is being sent and received by the wireless cards using the ST-Link debugger ?

mattdibi commented 5 years ago

Hi, can it be a pairing issue?

I encountered the same behaviour at work when I listen music with my bluetooth headphones. The Redox wireless and the bluetooth share the same bandwidth and this can make it hard for the two halves to communicate with the receiver. It's strange that the behaviour manifest on only one half but (I'm guessing here) maybe is the furthest from the receiver?

My solution is to turn the Redox off and on and they're good to go again.

LucidityCrash commented 5 years ago

Surely if it was a pairing issue it would only be when you first turn on the keyboard ? This seems to be more like a wake from deep sleep issue.

I've had the same kind of drop out in 2 different locations one is certainly more RF noisy than the other but given Bluetooth Wifi and Microwaves all live on the same band even a bog standard home is kinda noisy :) In the first 2 instances the receiver was smack in the middle of the 2 boards and less than 30 cm from either, in the 3rd instance the receiver was closest to the left board (the one with the issue) and probably less than 1m from it.

My gut feel is it is something to do with the RF side of things as when I was testing for range I could get similar behaviour by going out of range and then bringing the keyboards into range while pressing keys.

The puzzler is that I've only seen it on the left board, I've got a couple more yj-14015's coming, I'll probably swap out the left one on the off chance it is a bad board.

mattdibi commented 5 years ago

Keep me updated!

LucidityCrash commented 5 years ago

As requested :) So slightly different presentation today. I was getting missed keypresses on the left board while typing today. Power cycled the board and was still seeing the same. I brought the receiver closer and the missed keypresses stopped, moved it further away again and didn't get any further dropouts for the next 5 minutes.

I started up hid_listener and there the missed keypresses were definitely not being seen by qmk (or at least not enough to show up in the debug console). But I wasn't getting quite the same behaviour of the stuck key on return to service so still not 100% proven. The fact that it is always the left board suggests a hardware issue ... sudden thought strikes me as I'm typing would a low battery also present as these kind of symptoms ? - it was new but it is possible it could be flat ... I'll check tomorrow

mattdibi commented 5 years ago

I suppose that would be the symptoms even though I have never actually seen them IRL. Speaking of which, I doubt that would be a flat battery. The expected battery life is pretty high (l have the same battery since last September and use my keyboard daily) it would strike me as odd such a short battery life. I could be wrong though. Let me know your findings! :)

LucidityCrash commented 5 years ago

This is really weird. Only been doing small sessions each day as I need to get my speed back up for work, but I didn't have a battery tester at work and kept forgetting to take one in so I changed my batteries round and haven't had any lockups for 3 or 4 sessions. Based on prior experiences I'd have expected at least 1, I'll keep trying and updating if you want.

Do you have any tips on doing debug at the nRF level using the ST Link ? I think I can work out debugging at the QMK level, the built in debug is already pretty good I think, but being able to see what is being sent from one hand and what is being received by the receiver (looking for dropped packets etc) could be useful.

mattdibi commented 5 years ago

For debugging your only option is to tinker with the firmware and the OpenOCD server. Here you have some instructions on how to set up the toolchain. Hope this helps.

LucidityCrash commented 5 years ago

And it's back again ... Didn't need to power cycle board or anything to get it working again it just sprang back to life ... The fact that it is only the left side really makes me believe it is a hardware issue with the wireless module or my soldering of that wireless module to the PCB. Still waiting on replacement wireless boards but might try reflowing the solder soon.

Very frustrating as I want to like this board but just can't rely on it as it is.

mattdibi commented 5 years ago

Good news everyone, I found something promising. The Gazell protocol does support frequency hopping which can be actually useful in this situation.

I only need to find some time to implement it... don't keep you breath, it may take some time.

LucidityCrash commented 5 years ago

I'm probably misunderstanding things but I thought the Frequency Hopping was always in use but since nothing has been explicitly configured the defaults will be in use.

I'd have thought modifying the selection policy, channel table and the timeslots should be all that is required. this is also interesting: https://devzone.nordicsemi.com/f/nordic-q-a/4427/advice-for-optimizing-multiple-device-gazell-system though the conclusion didn't seem to be satisfactory, it suggests that the 2 TX's should use different channel tables and the RX should use a channel table that covers both of the TX channel tables.

mattdibi commented 5 years ago

Mmmmh I think I was too tired and jumped to the wrong conclusion. I should dig through the documentation some more.

Anyway thanks for the link! It will be useful for sure.

LucidityCrash commented 5 years ago

I've implemented the interleaved frequency channel table as suggested and dropped the data rate to 1MBit ... still seems to work, I think the range is a little better but that may be a placebo effect. No how to test the current draw with the new settings, and I don't type fast enough to know if there is a lag. And not used it long enough to tell if it helps with the dropouts Code is Here: https://github.com/LucidityCrash/redox-w-firmware/tree/freq

mattdibi commented 5 years ago

Nice!

I'll try to test current draw tonight, if I have time. As for range and lag I can think of something. I'll let you know the results.

Thanks for your help!

mattdibi commented 5 years ago

Hey!

I tested your fork on my keeb. Current consumption looks exactly the same old new

Didn't have the time to throughly test it for lag, but I didn't notice anything strange.

As for range I really can't tell. To me it seems it stayed the same, but my experiments lacked of repeatabilty and planning.

Since you had some trouble with repeated key-presses try your code for a couple of days and tell me if it improved with your problem. Once you're confident there's a tangible improvement we can merge your fork on master. What do you think?

LucidityCrash commented 5 years ago

Sounds good - I'll report back. My range testing was similar to yours, a very unscientific comparison to the rough testing I did when I first got the board.

LucidityCrash commented 5 years ago

In the last 27 days I've been increasing my usage of my Redox board ... I still can't type well enough on it for it to be my main work board. Since making this change I've had on day when I had multiple sync issues ... or at least I think they were, I work in ssh terminals for about 90% of my day and it is conceivable it was network issues. To be fair before I'd made the changes I'd not had too many disconnects for a couple of weeks either

So I'd say that my changes make the code match the documented best practice for the SDK, and at least don't make the connection any less stable :)

mattdibi commented 5 years ago

Nice! Merging https://github.com/mattdibi/redox-w-firmware/pull/7