sm_fast problem/bug?

[jb]

Aproximately two years ago I midified an old analog organ successfully, it worked flawlessly during these years. Now I am adding an extra keyboard and switches. I updated to the new MIOS version, and I am using the 32x32 code of QBAS. I modified the SM_NotifyToggle such that it sends MIDI events accordingo to my situation.

However I encountered a serious problem: when playing more than 1 key at the same time, in some cases extra MIDI events are sent, especially when playing three keys. This never occurred before updating to the new MIOS.

When playing certain chords a continuous stream of extra MIDI events are send consisting of a note on event followed by a note off event, than note on, note off, etc. The extra note always has the same column number as the key I really pressed and a row number that differs +1 or -1.

I removed all manuals and switches, but one (that always worked) en the problem remains, even when I upload the old example code for an 8x8 matrix, the original QBAS code, or the new code sm_example2_v1b (fast with debouncing).

However, with the new code (not fast) of sm_example1_v2b the problem completely disappears, everything works as it always did. So it seems that all fast matrix code with the new MIOS version generate this problem.

[stryd_one]

Sounds like a debouncing issue.

[jb]

The extra midi events are keys, that are not pressed. So it cannot be related to debouncing of my switches (?).

[arumblack]

Do you have diodes on your matrix?

[jb]

I have diodes, in fact the same circuit of diodes connected to the keyboard functioned very well for several years, I did not change anything of it. Since I updated mios I have these problems with the fast matrix driver (not with the simple one).

[TK.]

I'm not able to reproduce this (as I don't have access to your hardware) - I did a quick check on a matrix keyboard, but without seeing the failure symptoms you described.

Is anybody beside of jb using the "sm_fast" variant?

However, one thing you could try is to insert some waitcycles after the SCLK 0->1 edge

search for the SM_BUTTON_HANDLER_SHIFT_Cont label, and change the code below this label the following way:

	;; toggle shift clock to 1
        bsf     SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK
        nop
        nop
        nop
[/code]
If this doesn't help, I'm out of ideas...
Best Regards, Thorsten.

[jb]

Thanks for your attempts to reproduce it. I will try your suggestion.  I suspect the new version of MIOS, since this is the only thing that changed, the hardware did not change and worked fine for years.

The only other possibility I see, is that the update of MIOS/bootloader is faulty. I have no PIC burner so I ordered a new one.

[TK.]

There is no reason why the bootloader should affect the program execution.

I'm also not aware about a compatibility issue with MIOS itself.

Best Regards, Thorsten.

[stryd_one]

the hardware did not change

You didn't disassemble the box/reconnect cables/open it up/move it/anything like that? The only thing you touched was the PC, to upload new firmware?

[jb]

I added a manual, so an additional 8x8 matrix to a DOUT and DIN. Everything worked okay, I could not play the new manual since the program does not support it. Then I upgraded Bootloader/MIOS and got into problems. I removed the new manual from the DOUT/DIN pins: does not make any difference.

[jimhenry]

jb,

I am working on a project based on sm_fast. My objectives are driven by the needs of those MIDIfying organ consoles. My ultimate goal is a matrix of up to 32x32 dimensions with configurability comparable to MIDIO128. The QBAS project, as best I understand it, differs from what I am doing because it provides velocity sensing, does not provide debouncing, and is not pin by pin configurable. I can't promise that I will have project debugged in a time frame measured in less than months. If you'd be interested in testing or collaborating let me know.

[lemonhorse]

hi jb,

I encountered a serious problem: when playing more than 1 key at the same time, in some cases extra MIDI events are sent, especially when playing three keys. This never occurred before updating to the new MIOS.

However, with the new code (not fast) of sm_example1_v2b the problem completely disappears, everything works as it always did. So it seems that all fast matrix code with the new MIOS version generate this problem.

[TK]: Is anybody beside of jb using the "sm_fast" variant?

I use the asm 8x8 sm_fast driver for C64 keyboard interfacing [PIC 18F452, asm, MIOS 1.9f]. In some cases I use two keys simultaneously (F1+ Shift, etc.) with no problems so far.

[stryd_one]

I added a manual, so an additional 8x8 matrix to a DOUT and DIN. Everything worked okay, I could not play the new manual since the program does not support it. Then I upgraded Bootloader/MIOS and got into problems. I removed the new manual from the DOUT/DIN pins: does not make any difference.

That was a very significant detail to leave out! I think you could do with a read of the 'troubleshoot' link in my signature. The sections about 'one thing at a time' and 'giving a full description' apply here, but the rest might be helpful ;)

Speaking of which, there's the one about defining the problem... I don't suppose there's some kind of pattern to the 'extra' notes you see?

While it's still entirely possible that you've found a bug in MIOS 1.9f which noone else has seen or can reproduce, I would say that it is far more probable that something went wrong during that work....

[jb]

Thanks to all for your replies.

Well, I shortly indicated adding an extra manual in the first post. To be precise: I added the manual some months ago, connecting wires to DIN/DOUT. Had no time to update the software  to support the added manual, so kept playing for months without using the extra manual. Everything worked perfect during these months. Last week I had time, and as a first step updated MIOS, from then I have the problem with the already existing manuals. To be absolutely certain to exclude any influence I disconnected the added manual.

As I mentioned in my first post, I do see a pattern: 'the extra note always has the same column number as the key I really pressed and a row number that differs +1 or -1'.

I haven't looked at it for several days now, hopefully a fresh mind will turnout to be helpful...

@jimhenry: I am very much interested in your project, I am certainly willing to test it. Depending on the current state I might collaborate, but I do not have a lot of time available.

[stryd_one]

Well, I shortly indicated adding an extra manual in the first post.

...

As I mentioned in my first post, I do see a pattern: 'the extra note always has the same column number as the key I really pressed and a row number that differs +1 or -1'.

*facepalm* I'm an idiot. I dunno how I missed both of those, my apologies. Had I seen those, especialy this gold:

'the extra note always has the same column number as the key I really pressed and a row number that differs +1 or -1'

I would have responded entirely differently. I'm not sure how though :D Lemme think on it...

To be absolutely certain to exclude any influence I disconnected the added manual.

I'm afraid that does not make it absolutely certain, at all. Sometimes when we do a mod (like adding a manual), we also make an unintentional and unknown mod (say, shorting a cable). When we see a symptom of a problem (extra keypresses), it's sensible to roll back the change (remove the new manual)... But because we didn't know we made that 'other' mod (the short), we don't roll it back. It stays, and continues to cause the symptom. sometimes the mod will cause an unintentional mod which is permanent, like shorting a chip out, or zapping it with static, and frying it. Suddenly, that $2 static strap seems like a solid investment ;)

I wonder.... are you running long cables between the core and the manuals? or are the PCB traces or cables for the rows close together, or near something electronically, uhm, manipulative (a bank of relays or some mains power or transformers or something)? this sounds like crosstalk....Maybe some kinda capacitance in the switches...? Nah, then the rows would always be -1... I like crosstalk for this one. I'd say shorts between the rows, but it happens on all of them at random. It could be noise, but then neighbouring lines would be a pretty big coincidence. I'm still with crosstalk. Have you tested the voltages on the rows? Current? What kind of PCBs are you using?

[jb]

Today I tried a new PIC, made no difference. I checked all cables, improved some connections with only one manual attached, still no difference.

When I use the 'simple' (slow) scanmatrix driver, there is no problem at all. I only have problems with sm_fast and code based on the sm_fast driver. So, it can hardly be a hardware problem (with some of the cables or anything else) since this would also occur with the 'simple' driver, both drivers result in the same DOUT/DIN activity isn't it?

I would like to try the code with an older MIOS (for example 1.8), but only 1.9 is available for download.

[jimhenry]

jb send me a private message with your email address and I'll send you MIOS_v1_5b and MIOS_v1_7 for testing.

[stryd_one]

I only have problems with sm_fast and code based on the sm_fast driver. So, it can hardly be a hardware problem (with some of the cables or anything else) since this would also occur with the 'simple' driver, both drivers result in the same DOUT/DIN activity isn't it?

No, they work differently, so it is just as likely to be a hardware problem. I don't supposed you'd like to answer the questions from my last post? Photos would tell us a lot....

I've got copies of ye olde mios around here too, but looks like jim is on top of it already :)

[jb]

At least some answers to your questions, I will try to make a picture this evening.

will cause an unintentional mod which is permanent, like shorting a chip out, or zapping it with static, and frying it.

I did exchange chips of DIN/DOUT without any result, and reconnected dubious wires.

I wonder.... are you running long cables between the core and the manuals? or are the PCB traces or cables for the rows close together, or near something electronically, uhm, manipulative (a bank of relays or some mains  power or transformers or something)? this sounds like crosstalk....

The cable's of the only manual I now have connected are less then one meter. I use a small adapter as power supply far away from the pcb's. The pcb's come from the MIDI shop in Germany. I use the usual gray computer flatchcable.

I like crosstalk for this one. I'd say shorts between the rows, but it happens on all of them at random. It could be noise, but then neighbouring lines would be a pretty big coincidence. I'm still with crosstalk. Have you tested the voltages on the rows? Current?

The extra keys are consistent, in the sense that some chords are allways accorded with an extra key (continuously being turned on and off). I was thinking about testing with a voltage meter, but to me it seems a bit difficult to interpret when changing over time (I do not have an oscilloscope).

[stryd_one]

You seem to be on the right track.

The extra keys are consistent, in the sense that some chords are allways accorded with an extra key (continuously being turned on and off)

Sounds like an expansion of the pattern you mentioned... Is it always the same extra key with a particular chord? How fast does it turn on and off? Is that strobing regular, or random?

I was thinking about testing with a voltage meter, but to me it seems a bit difficult to interpret when changing over time (I do not have an oscilloscope).

As for the voltage, I was wondering if maybe the voltage or current draw was a bit high, which might contribute to crosstalk. That'll be constant, if it's there...

Photos will probably tell us a lot....

Did you try old mios again? It occured to me, you might need a matching bootloader too... MIOS in recent versions moved it's memory around, and the bootloader makes sure it goes to the right location....