TinyCircuits Forum
TinyCircuits Products => TinyTV & Tiny Video Player => Topic started by: RavenWorks on July 05, 2023, 09:47:42 PM
-
Just got my TinyTV2, and it's mostly wonderful, but ever since I added my first custom video, it seems like there's a 10% chance every time I turn the dial that it'll play the little static animation and show the channel number, but will just show the same video and channel as it was just on? Despite it starting after I added a video, this happens when changing between any two channels, not just when changing to/from my custom one. (It's possible that it has nothing to do with my custom video, and I just missed seeing it until that point, as it is still semi rare, although I have absolutely seen it happen multiple times in a row, as in it can take three turns of the dial, and three instances of static, before I see a different channel.)
If I could hazard a guess, it seems like maybe it's accidentally switching up and then immediately back down, or something? (Although it definitely happens when moving in either direction...) Has this happened to anyone else?
-
Hi, thanks for your support of Tiny TV 2! Not sure if this is some firmware bug introduced with the video that was added or maybe the encoder for the channel knob is a tiny bit different from others causing the channel to change one way then the other as you suggest. I think I remember one Kickstarter comment that may have been the same issue where someone mentions having two of the 'same' video after adding a video, or similar, which may be a description of the same issue.
Any chance you have the remote? That would be a way to test changing channels without using the channel knob.
If you're able to upload the video to some file sharing site and PM or email me, I could see if I get the same issue here.
Thanks,
Ben
-
OK, I just tried removing my custom videos, and I can confirm that it is definitely still happening. (I got rid of several of the built-in ones, so it isn't COMPLETELY stock, but there's nothing on there that it didn't come with.)
I don't have the remote, no.
Is there any way I can debug what's coming from the encoder knob?
-
It seems to be getting worse; it happens probably more than half the time now, and typically takes three turns before the static results in a *different* channel rather than the same one...
-
Ok, haven't heard of anything so significant- first of all, we can replace the hardware if you'd like, just email info@tinycircuits.com at any time. Sounds like you're interested in figuring it out/fixing it though based on your other thread. We should be able to in software, I think we just don't have the code quite right for debouncing the encoders. Debug output is disabled on the production build, but you mentioned the Arduino IDE in another thread- if you open the Serial monitor(or any other way of writing data to the USB CDC serial) you can send JSON style strings like {"SET":"channel=2"} to change the channel. This would take the hardware rotary encoder out of the equation, so it could help us determine if that's where the issue is. Let me know.
Thanks,
Ben
-
Faloun, this sounds like an unrelated issue to mine; I suggest you start a separate thread. In my case, the number is distinctly *not* changing unless the video changes as well; the correspondence between video and number never changes for me, the only issue is seeing static during a physical click of the wheel but NOT having the channel change in any way.
-
Faloun, this sounds like an unrelated issue to mine; I suggest you start a separate thread. In my case, the number is distinctly *not* changing unless the video changes as well; the correspondence between video and number never changes for me, the only issue is seeing static during a physical click of the wheel but NOT having the channel change in any way.
Will do
-
Okay, good news and bad news! I can finally build my own firmware for the TinyTV, and I implemented some simple debouncing! The good news is, turning the dial to the RIGHT, now always works perfectly... the bad news is, turning it to the LEFT, has about a 50% chance of going RIGHT instead. Which means turning it to the left tends to pingpong back and forth between two channels most of the time. From looking at the logic in the program, now I'm imagining that what's happening is, both values (channelUp and channelDown) are actually getting set to true on a SINGLE FRAME, which means there's no way to determine which way it was meant to go, without going deeper.
So at this point, part of me is tempted to say "tell me about the logic in the encoderPinChange function", but..... given that no-one else is complaining about this, and this is starting to look like something that there might not *be* a software solution to... most of me is tempted to just take you up on your offer to send me replacement hardware at this point, LOL.
-
Sorry I missed this as well! I agree with your logic- if the high level debounce doesn't work, I think the next step is debouncing per IO pin connected to the encoder. I definitely intended to provide something rather than ask you to dig in that deep. I attached a quick test implementation of that, if you have any interest, let me know what the behavior is on your hardware- 'debounceTimeMS' can be adjusted.
Otherwise, send us an email at info@tinycircuits.com and we'll follow up on the hardware replacement!
Thanks,
Ben
-
Someone's already taking care of it on the email side of things, thanks :)
I'll try this change soon!
-
OK, I just tried your patch -- now the situation is like:
- 25% of the time, it changes channels as it should
- 25% of the time, it changes channels correctly for a split second but then automatically changes back to the previous channel a split second later (so, similar to the original problem, just with a tiny flash of the intended channel first)
- 50% of the time, turning the wheel does nothing, no static or anything.
At this point, I think I'd be willing to drop it, assuming my replacement TV doesn't have the same problem.
-
Okay -- the new one arrived, and it's got the same problem! It's only like 1 in every 6 turns now, which is way better than the old one.... but the old one started that way too, and gradually got worse over a few weeks, so only time will tell if the new one is headed down the same road :/
I'm officially back on team "can we implement any kind of proper software debouncing", then. How does the encoder mechanism work internally, is it switches or what? Are there docs for the drivers that read the values?
-
I thought I responded to your last post, sorry- first of all, thank you very much for all your time testing and the amount of patience with this. Is there any chance you're willing to ship the first one back? I'm extremely surprised you have another one with basically the same issue. I'd like to really figure out the root cause which would be a lot easier if I have it in hand. Let me know if you need our address.
Since you asked, the datasheet is at https://www.mouser.com/datasheet/2/15/EC05E-1370804.pdf , the specific PN is EC05E1220401, but again, I'd like to put the time in here and get you a working product!
Thanks,
Ben
-
Sure, I'm willing to send the old one back if it helps the process. Things are crazy at work right now though so I might not get around to it for a couple of weeks. I will need your address though, yes.
I've got the old one set aside for now (with a little sticker on it so I can tell it apart from the new one) and with the default videos loaded back onto it. Also just mentioning before I forget: at the moment it has your debounce test firmware on it (which causes the wheel to simply be ignored a lot of the time).
-
Good news; I finally got some time off work, and gathered up the executive function to read that datasheet, and I've now got a pull request in that fixes the debounce issue :) So hopefully there's no need for me to send it back in after all, at this point.
-
Well, very cool, sorry you had to put time in on this but I think that's a valid path to let the interrupt states variables run, but only 'keep' the latest change. Did you test this with decreasing timeouts? For example 10ms instead of 20ms? Just out of curiosity as to how much time is needed for your hardware with the more significant issue.
Otherwise, we'll test here and I'll let you know how it goes.
Thanks,
Ben
-
The datasheet said "6ms bounce, 6ms jitter", so I tried 6ms, and had one bounce in couple dozen tests.... then I realised that the datasheet might be trying to tell me to use 12ms total... and then I said, hell, let's be safe, if the frame rate is so low anyway, and bumped it all the way up to 20 like the power button uses..... but then even at that point, I still got a single bounce in a few dozen more tests, so I gave up adjusting anything, lol. So yeah, the exact numbers are a little up for debate (especially since, like I mentioned in the pull request, I realised that there's actually a slight bug, in that it'll wait for the specified duration AFTER the signal settles.... but again, it didn't seem worth worrying about because these amounts are still imperceptibly small, to me.)