ris8_allo_zen0 Posted March 12, 2007 Report Share Posted March 12, 2007 Hello!I've a strange problem using my MBSID step C: the encoders will sometimes skip some values (... 32, 33, 35, 36...), sometimes go back (... 32, 33, 28, 29, 30...). "Less" sometimes, all the interface goes crazy: it's like all the buttons and encoders were pushed/turned randomly in very little time, messing up all my current configuration. And "more less" sometimes this happens for several seconds, until I press something: the effect is quite visually appealing, but perfectly useless... I've made a video during such behaviour, I'll post a link whenever I can.I suppose I have two problems, not just one (one in the encoders and one in the DINs)... but I'm clueless for both! What/where should I check for?Thank you very much for the help!!Enrico Quote Link to comment Share on other sites More sharing options...
ReinerS Posted March 12, 2007 Report Share Posted March 12, 2007 Hello Enrico,the first thing I would check in such a case is the supply voltage. Measure it at the core as well as the DIN modules. If it is +5V +/- some small value that should be ok, otherwise you might have found the problem. If the voltage is ok, then one can think about the next steps.Good luckReiner Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 12, 2007 Author Report Share Posted March 12, 2007 Done. All the voltages measured on each chip go no far than 5.02V...What next? Quote Link to comment Share on other sites More sharing options...
stryd_one Posted March 13, 2007 Report Share Posted March 13, 2007 Check for soldering errors on the DINs and core perhaps, and remove some encoders and DINs if you can. Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 13, 2007 Author Report Share Posted March 13, 2007 I removed all encoders and kept just one DIN, the datawheel encoder and four buttons (revert to Step A). Now it seems to work fine, the encoder only skips by +1 or -1 (*), which is not a great problem when sweeping but it is when selecting menu items... can this problem be solved with some configuration values?Uhm, I just discovered the CS_MENU_EncSpeedSet function... should I tweak its constants to try to solve this?When I'll have more time I'll do some other tries with it, as well as with the other buttons/encoders.(*) Maybe because of a poor quality encoder? I got 50 of them on ebay for 46 AU$, and the "ticks" are of different strength: some are so weak to be considered non-detented >:(Best regards,Enrico Quote Link to comment Share on other sites More sharing options...
stryd_one Posted March 14, 2007 Report Share Posted March 14, 2007 Yeh cheap untested encoders could be a risk. They could be faulty, but encoders support in MIOS needs to be configured differently for different models. Have a search around for info on what to try, this has been covered for other different encoders eg smash and voti encoders Quote Link to comment Share on other sites More sharing options...
TK. Posted March 14, 2007 Report Share Posted March 14, 2007 Maybe the wrong encoder type is selected, you have the choice between three types:http://www.midibox.org/dokuwiki/doku.php?id=encoder_typesThe type can be changed for each encoder individually in mios_tables.incBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 15, 2007 Author Report Share Posted March 15, 2007 Thank you for all the help!Yeh cheap untested encoders could be a risk. They could be faulty, but encoders support in MIOS needs to be configured differently for different models. Have a search around for info on what to try, this has been covered for other different encoders eg smash and voti encodersIn the wiki I've found no mention of my encoders' model, as the Murphy's law says ;)Maybe the wrong encoder type is selected, you have the choice between three types:http://www.midibox.org/dokuwiki/doku.php?id=encoder_typesThe type can be changed for each encoder individually in mios_tables.incBest Regards, Thorsten.I've tried all the NON_DETENTED, DETENTED and DETENTED2 modes, but they behave nearly the same (always some glitch).Now I had a further look at the graph and at the one of the datasheet of my encoders, model AER24C24P-S, found here: http://sales.xonelectronics.com/Stock%20Data/p138.pdf... and it looks like it's similar to the DETENTED one, but mirrored upside down. In the datasheet "ON" is up and "OFF" is down, but which are where in the image in the wiki?(please note that IMHO in the datasheet graph the dashed line is for the "click", not for inc/dec)If the levels are inverted as I suspect, this could be the origin of the problem because the "clicks" are supposed by MIOS to be at wrong places, leading to an unstable reading when the encoder is not rotating. Am I right?Excuse me for the many (and maybe unclear) questions...Best regards,Enrico Quote Link to comment Share on other sites More sharing options...
stryd_one Posted March 15, 2007 Report Share Posted March 15, 2007 If the levels are inverted as I suspect, this could be the origin of the problemI reckon. because the "clicks" are supposed by MIOS to be at wrong places, leading to an unstable reading when the encoder is not rotating. Am I right?it's more the voltage transitions, than the click, which is mechanical (which is good because we can remove them hehehe) But you've got the idea :) Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 15, 2007 Author Report Share Posted March 15, 2007 I reckon.If I really have to do with inverted levels, I think about three ways to solve this:1) connect central pin of each encoder to VDD instead of GND --> impossible, I've already soldered them with the LED cathodes which must be connected to GND!2) modify MIOS to invert all input signals for encoders before using --> working enough to make a "DETENTED3" (or DETENTED_INV ) mode!3) throw away those encoders and buy new ones --> unsolder, pull, glue, resolder... solution 1 is easier!If there are no other simpler ways, I'd prefer the solution 2: I like to code, and it could be helpful to those who bought the same encoders.Please stop me if there's something like INVERT_ENC_INPUTS to be set somewhere :Dit's more the voltage transitions, than the click, which is mechanical (which is good because we can remove them hehehe) But you've got the idea :)That's exactly what I wanted to say :) sorry, my English is far from perfect...Best regards,Enrico Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 16, 2007 Author Report Share Posted March 16, 2007 PANIC!! The 'impossible' happened...I had a look at the MIOS source, found the code that handles the encoders and just added a 'xorlw' to invert data.When I was re-uploading the new code with MIOS Studio, I noticed a checksum error. So I did the upload again, but the errors were more. The more the retries (also starting less than 2 seconds after the upload request), the worse the behaviour. The resulting errors are similar to those of this thread: http://www.midibox.org/forum/index.php?topic=7699.0, with the difference that my board always worked fine until now!Now I see the PIC sending an upload request, then displaying "READY." on the LCD, but it doesn't respond to any MIDI/Sysex event. So I can't upload anything.I don't know whether to re-burn the bootloader (i have to rebuild my DIP40 adaptor) or not...But what makes me worry is WHY all this happened. Bad upload procedure? Bad compile? (I used gpasm on linux with the macro correction script) I'm clueless...Thanks & best regardsEnrico Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 17, 2007 Author Report Share Posted March 17, 2007 I managed to solve the checksum errors: suddenly my Midisport Uno adaptor ceased working (strangely, this happened exactly when I tried to upload the modified MIOS). With my old homebuilt MIDI-to-gameport adapter the communication was now OK; however I had to re-burn with the bootloader because it was somewhat corrupt... After all this mess... the encoders (at least the one of the menu, the only currently connected one) behave exactly as before!!!! I'm quite angry..... Quote Link to comment Share on other sites More sharing options...
TK. Posted March 18, 2007 Report Share Posted March 18, 2007 The waveforms of the encoder pulses are inverted, as the DIN register chains are working with low-active. As you've already noticed, it doesn't make a difference.However, maybe the output signals of your encoders are too unstable when it is rotated. There is no encoder debouncing implemented (would consume too much RAM and too much CPU performance), but you could decrease the update frequency - maybe this helps.So, what does happen when the update frequency (MIOS_SRIO_UpdateFrqSet) is 5 mS instead of 1 mS?Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
ris8_allo_zen0 Posted March 18, 2007 Author Report Share Posted March 18, 2007 So, what does happen when the update frequency (MIOS_SRIO_UpdateFrqSet) is 5 mS instead of 1 mS?Thanks TK for the advice. I tried 5 ms, 10 ms, 20 ms... nothing better.The best result I can achieve is to set CS_MENU_USE_DETENTED_ENCODER to 0... not perfect but surely better: 2 or 3 detents to navigate into menus can be confusing, but at least I have no jumps forth and back!Now it's time to try all the other encoders for the other serious problem...The waveforms of the encoder pulses are inverted, as the DIN register chains are working with low-active. As you've already noticed, it doesn't make a difference.I thought it did... well, I had a good chance to know a little more about MIOS code 8) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.