I solved the problem. It turns out that I soldered the wires for the right-side buttons onto the pins of the PICAXE in reverse order. I did the same thing on the first prototype circuit. >_< It was a simple fix that took all of thirty seconds.

Now it works perfectly. Except that the circuit takes too much power which is causing some problems - for example: if I have two or more of the LED keyboard lights on (or all of them off), then it overloads and spazzes out. So, I programmed it to constantly have the caps-lock light on. Another problem I'm having is that if you press the delete key more than about twice in a row, it draws too much power and freaks out requiring you to disconnect the controller unit for a bit. Other than that, it works great. But it's not a problem I hadn't anticipated; in fact, I was expecting it.

A potential solution for this is to add a 5V power regulator to the circuit. I'm not going to bother doing that for this prototype unit as it would be a real pain to desolder then resolder it. I'm just going to spend a bit more time on it then call it finished.

I'll probably drill the hole for the PS\2 jack tomorrow, and then this prototype for the Kupid will be done.

Here is Kupid, all in the case:
What's the next step? Even though this prototype was supposed to be the "final" one, I'm not happy with it for various reasons (not the least of which is the power draw problem). So what I'm going to do is finish this imperfect model up, then start designing the next one.

The next prototype will hopefully be the final one. I'm planning to design & make a custom circuit board for it, and enclose the circuit board in a plastic box enclosure that will plug into the PS1 controller using a 10-pin ribbon cable. The enclosure, about the size of a pack of cigarettes, will contain all the electronics and the keyboard will plug into that. Doing this will give me lots of room for electronics, reduce the amount of time it takes to make a single unit by very significant amount (just plug components in, solder and rejoice), will make everything so much easier, and increase the quality of the final unit.

Now, as I said before, this will push back Kupid availability back a couple months. I need to design the circuit board, and order it, test it, take orders for Kupid, then order more, and then make the units. It takes time for the circuit board to be manufactured and shipped to me from China, too.

Kupid is very much alive and will be available for sale within the next several months. Most of that time will be spent waiting for the circuit boards to arrive. But I just don't feel that the current prototype is representative of my vision for Kupid and I don't believe that its level of quality would satisfy anyone who would buy it. So you're just going to have to wait a little while longer.

I'm very disappointed by this, Kupid is way overdo as it is. I want to make the best product possible, within reason, and the current model doesn't meet my standards.

Just keep at it Mose. It is better to delay something then release something you are not happy with.

Thanks, face.

Now that I've had some time to think, I'll work a bit more on this prototype. Though, it will largely have to wait until I get paid; no telling when that will be thanks to the district screwing up, making my paycheck nearly a month over-do.

I'll try putting in the power-regulator (de-soldering and re-soldering *sigh*).

Will post updates later on.

I just got paid. I'm ordering some electronic stuff now. I'm getting myself a logic analyzer. ^_^

Once I get everything, I'll be able to really start work back up on the Kupid prototype.

I'm highly excited for this. Be sure to keep us updated.

I'm sure you'll hyper-ventilate when I post pics from my new logic analyzer hooked up to Kupid. Doesn't everyone get excited by time-graphing circuit logic?

I just got my logic analyzer; I wasn't expecting to get it so soon, being as I ordered it yesterday. ^_^

I still need to learn how to use it, without breaking it. But, once I do, I'll begin doing extensive testing of Kupid, trying to figure out how I can make it better.

I'll post some of the graphs/charts and whatever else I generate during the testing so you all can see. I don't know when that will be, but, as always, I'll post updates as soon as I have anything to post.

I've got the logic analyzer hooked up to Kupid and have started doing some basic testing. Pictures below.

The LA hooked up to Kupid:
The letter/character preceding the d-pad press indicator show what character I had typed on the keyboard. Each pulse (represented by a vertical line) is shown over time; so you can see how the duration of d-pad presses differ from the duration of button presses (d-pad presses are shorter than button presses), as well as how much time passes in between pulses. You will also see the extra pause (shown as a larger gap between d-pad pulses) that I put in long sequences of d-pad presses to help prevent misses. The below takes place over 30 seconds. It's Kupid as you've never seen it before:
I still have work to do on it. Wish I could afford a 32 channel LA, but this 8 channel one is still awesome. ^_^

I've finally managed to record a missed button press. The cursor was on "W" then I presses "1" on the keyboard. As you can see below, all the proper pulses were sent with the correct timings. However, the last LEFT pulse was missed, typing in a "2" instead.



Thanks to the LA, now I know for certain that the pulses are all being sent, and that it isn't my program or circuit that causes the problem; not directly, anyway. The next step in figuring out what causes the missed presses is to monitor the signal being sent from the PS1 MCU along with monitoring the signals sent from the Kupid circuit and seeing what happens on the data lines when a button pres is missed.

I'll need to take a look at the schematics of the PS1 controller to figure out which lines carry which info, so I know what to monitor.

Looking good. And it's also looking like it might all actually fit in the controller too. Also, I didn't think you'd be able to actually look into the missing button press so deeply.

Yeah, it fits. But soldering everything together is a real pain. I'm still planning to make a custom PCB and put it in an external enclosure for the final unit that I'll sell. Doing it all manually creates too many potential failure points; having Kupid stop working because a connection came loose would not be good.

Yeah. That issue really bothers me. Odds are there is nothing I'll be able to do about it, but I still want to take a look.

Made some good progress. It has become clear that the way the PS1 controller transmits data, at regular intervals, poses a potential problem for my Kupid design. I'm not certain yet, mind you, but I'm beginning to get a grasp on the possible reasons behind the button misses.

I've figured out the protocol that the PS1 controller uses to transmit data to the PS, and am looking at the bit-level data transmitted to try and work out what is really going on inside Kupid.

Below is a picture of the bit-level logic graph of a single PS1 data transmission, which takes place over a time span of 299 microseconds. The white text the hex value of the data being transmitted.Basically, the PS sends out a signal that it is ready to communicate with the controller by bring the Attention line LOW. Then it sends out $01 then $42 saying it's ready to receive data. The controller sends out $5A, telling the PS that it's about to send the button press data. The button press data is sent in two bytes, with each bit corresponding to a certain button. In this case, the button presses is X, so the controller sends the first byte, $00, then the second byte $BF.

I'm still working on breaking down the signals, and trying to record a missed button press along with the PS1 data lines.

While this may tell me a bit about why buttons may be missed, it doesn't mean that I'll be able to use that knowledge to improve Kupid. So, for the time being, I'll just say that we'll see how it goes.

I thought about the problem some more, and think I may have figured out why the button presses are being missed - it has to do with signal timings, which turned out to be quite a lot smaller than I had figured (i.e. on the microsecond scale). I won't go into the details, as it's just a theory at this point. I still need to collect and analyze more data to see if it really is the reason.

If so, then I think I may have come up with a way of potentially solving the problem. Basically it involves monitoring the ATTN line on the PS1 controller, and using that signal to control the timing of the button presses. However, we're dealing with a timespan of a couple dozen microseconds at most, so this solution may not work out. If it does work out... well, I'm loathe to say anything. Suffice to say that if it does work out, then the problems with both accuracy & speed will be a thing of the past. Just don't get your hopes up quite yet.

In short, my new LA has opened up all kinds of new possibilities for me to improve Kupid. Whether or not those possibilities will pan out, I can't say. Regardless, I'll post more detailed info with, no doubt, more charts & pictures as the testing/analysis progresses.

That sounds very promising. I wish you the best in your search.

My theory was correct. I've recorded several missed button presses and figured out what's going on.

Every 1.8 seconds, the duration of time which exists in between each ATTN signal pulse of the PS1 controller doubles from 16 milliseconds to 33 milliseconds for three to four pulse cycles. The extra long in-between time on the ATTN line is time when the controller will not read any button signal at all - so, the signals are being sent by my PICAXE, but the PS1 controller isn't listening.

In my earlier testing, I set the d-pad pulse time to 17 milliseconds in duration, and the button-press pulse to 70 milliseconds. The button presses are never missed, but the d-pad presses are. 17ms turned out to be very close to the natural pulse cycle of the PS1 (I didn't know that then, but basically stumbled upon it even before I had my LA), so it worked really fast 90% of the time, but missed 10% - now I know why.

This is because any d-pad pulse duration less than the maximum potential gap between the PS1 ATTN pulse cycles (33ms) will sync most of the time, but will fall into an extra long gap between the ATTN signals if the pulse from the PICAXE just happens to be sent during that short period of time that the ATTN pulse cycle spacing has doubled. This period of time when the d-pad press will be missed lasts for 100ms every 2 seconds. This would have been utterly impossible to figure out without a logic analyzer.

Okay, so.... you probably didn't understand that. In a nutshell, I've figured out why the presses were being missed. I've adjusted the button signal timings, and made a few other modifications to the program to sync it up to the ATTN signal to counter-act the odd timing issues.

AND.... I believe I have completely eliminated missed button presses. Kupid is now 100% accurate! (barring any noise on the line, circuit wonkiness, loose wires, etc.)

All I have to do now is fix the power issue (which is not a small problem), and my design for Kupid will be done!

That's wonderful news! I'm very excited to here that, man. Does that mean you know the final speed that Kupid will achieve?

OH MY FREAKING MOD!

My pants are leaking happy things.

Yep. It's not blindingly fast, but I think it's more than adequate.

I'll post a vid when I get the chance. But, due to the power issue, I am unable to type in a full sentence before it draws too much power and overloads. I need to get that problem fixed before I can really show what Kupid can do.

I just got the new step-up board. I'll be doing some soldering and whatnot for a bit, soon. Once it's in & tested, the Kupid prototype will be done.

Once that's done, I'll do a bit more thinking about Kupid, then start designing the PCB and get the first production model built.

Supposedly.