Ps3 rapid fire studying and understanding project open source

[hyper999]

well all i can say is its definitely your install that is the problem,

you should hot glue the PIC somewhere before you start wiring and make sure all your wires are held down somewhere they can get pinched. or maybe try a different ground spot?

[rafaliyo86]

i am using this diagram and exactly the same ground spot

[bigboss59400]

Hi

I have a V3.7 and I had the same problem like you so to fix this bug I have wire the positive pins to the positive vibror.
 

[rockandink]

This is a V3.7...gf's btw.  Wired up the as per pictures/diagrams--she loves it!
As you see, though, I put the button right on top though.

EDIT... forgot to mention that I switched out the red LEDs for pink ones too... LOL

[bigboss59400]

Nice your controller

Where have you buy your stick ?


I have bought news controllers and when I have opened it I was surprised there is new board ... :
http://img842.imageshack.us/g/img0795t.jpg/

So is it an official or not ?

Thanks

[rafaliyo86]

I would say it isnt an official controller but I am not sure

[bigboss59400]

Me too ^^ because there are in official package.

And I have a non official and it is same PCB so ?

[rockandink]

wow... they made it a true counterfeit? I wouldnt mind them making non-official as long as the buyer is informed.  But, when they make a counterfeit and sell as a real one---that gets me so angry.

btw, i bought the sticks from ebay

[bigboss59400]

Hi all,

I want to know where did you buy your controller ?

Thanks

(I know I'm not in the good section but I want an offical board for rapid fire of course)

[rockandink]

Hi all,

I want to know where did you buy your controller ?

Thanks

(I know I'm not in the good section but I want an offical board for rapid fire of course)

The red controller (my gf's) I bought from a game store. GameFix? GameStop?  I just know they recently went out of business--all the brick n mortar stores are gone now.  Paid full price-maybe slightly discounted.

I recently bought a controller from Sears--again, full price.

But, my controller that I installed rf came with my console--a used gunmetal gray....

[bigboss59400]

Hi,

(Sorry for ascend this topic but I think my questions take part of it...)

I try to make my own code (in C), I have read and understand a lot of things thanks to you guys  .
But I'm missed like orko007 was about the refresh rate of the controller (page 2) despite explains of 802Chives and RDC I don't understand these things :

PS3 Rapid fire only works in 10mSec increments... but at its fastest button press is still 50 press/sec

so why the fastest button press it isn't 100press/sec ?

PS3 Rapid fire only works in 10mSec increments

the range of the rapid fire is 0-100hz by level of 1hz ?

On a game like COD, the game has to see the trigger pulled for at least 3 cycles before calling it a pulled.

so the range is now 0-33 by level of 3hz ?


In supplement, how does the "burst fire" works ?

Can somebody explain me, please  ?

Thanks for all

[hyper999]

- The controller reads the state of each button 100 times a second, so your 50sps maximum comes from 50pressed pulses and 50 un-pressed pulses, like on off on off on off etc

- Therefore the range of speeds is 1-50 sps.

- Yes the COD game software requires 3 pressed pulses to actual count as a trigger press so the absolute maximum is around 33sps however the actual playable rate is a fair bit lower.

- Burst works by works by reading the trigger and not rapidfire'ing until a trigger press occurs, then after the desired number of shots have fired it reads the trigger again then returns to the start when the trigger has been unpressed.

[bigboss59400]

OK thanks hyper for your reply I understand better but :

1) So for up the speed we must increment by 1hz ? But in your source code, we can put numbers more precised than that....

2) I don't understand for burst fire, can you details more ?

3) Can we inject some high (and low) state in one dip ? The controller see that or not ?

Thanks for all

[hyper999]

1) Depends on the way you code it, in my code you can increment by ~0.004sps, because I use a 0.5 interrupt with an 8bit counter for my pulse timing. (The interupt routine sets a flag, this then triggers the main routine to switch pin tristate and logic high accordingly)

2) Its really quite simple
Read the com line for trigger press > When pressed set a flag and do rapid fire > when rapid fire complete wait for trigger release > go to start. Short of coding it for you I'm not really sure how I can explain it better.

3) No, the controller reads the button/trigger only once per dip.

[bigboss59400]

Thanks again hyper for your quick reply   

1) I know how you have use interrupt (and you can set a PR2 value to have a more precise timer), I have take a look in your source code...But I'm missed here : the controller look the dip of R1 one time oer 10ms so how you can have a frequency like that ?

2) OK I think I understand : the "normal" rapid fire is sending all the times the "rapid fire" however the "burst" is sending only when the button is pressed, I was wrong ?

Thanks

[hyper999]

1) it reads r1 over a period of 500uS, it reads every button on the comR line in 10mS

2) rapid fire will continue to fire for as long as the trigger is pressed, whereas burst only fires a pre set number of shots every time the trigger is pressed

[jaredb03]

thats what ive got so far but its still not working. i still need to mess with the leds FLASH in this post
it compiles fine but just doenst change modes correctly ive made it 7 modes of fire

I was wondering if you are still working on this? I was looking forward to having a few more modes on my controller.

[bigboss59400]

I was wondering if you are still working on this? I was looking forward to having a few more modes on my controller.

Yes and no, I'm working to just have just rapid fire on R1 because I begin of 0 : all source code that's you see is in ASM however I don't know this language and I hate it because you cannot do a complicated code (here it isn't complicated) so I code in C. And after the code of rapid fire on R1 works, I add a lot of mode, and akimbo etc
And the code that radmiler post is wrong : you can have only 4 states in 2 bytes...


@Hyper, thanks for your reply

1)yes I understand that but that's I doesn't is how you can set a precision like that ? (with the timer I understand that) however if "it reads r1 over a period of 500uS, it reads every button on the comR line in 10mS" so you can have range 0-50 press/sec and to up speed you must up by 1 press only (the comR is read every 10ms)

2) That's I write in other words, no ? So I think I understand but how you can know that the trigger is pressed ?

Sorry if my questions is still apparently the same but if I ask them again that's I haven't understand something...

[hyper999]

And the code that radmiler post is wrong : you can have only 4 states in 2 bytes...

*bits

1) The timer runs independantly of the controller signal. The signal is also not always exactly 10ms long. and yes the adjustments aren't 100% precise, say if the counter reaches 0 half way through a pulse the state of the trigger will not be changed until the next pulse, but the average speed will still be close enough.

2) set the pin to an input and read the state of the common line at the middle of the r1 pulse, using whatever method you prefer (comparator, adc etc.)

[bigboss59400]

*bits

1) The timer runs independantly of the controller signal. The signal is also not always exactly 10ms long. and yes the adjustments aren't 100% precise, say if the counter reaches 0 half way through a pulse the state of the trigger will not be changed until the next pulse, but the average speed will still be close enough.

2) set the pin to an input and read the state of the common line at the middle of the r1 pulse, using whatever method you prefer (comparator, adc etc.)

*sorry it isn't the same^^

1) Yes I know for the signal, it changes when you are on usb or battery, I see in the previous post...I don't know your end of sentence.
But I think you haven't understand my question which is how the controller can see a pulse on R1 whith your precision (0.0005s) if it read only one times every (approximatly) 10ms ?

2) OK I understand now.

And another question how the jitter works ? (apparently it shoots and changes weapon, that's all ?)

[hyper999]

1) say for example you pull the trigger for 1second, not every high and low period in that second will be exactly the same length because the counter decreases every 0.5ms but the trigger is read only every 10ms, meaning that if the counter reaches 0 just after R1 is read by the controller the first state (e.g pressed) will end up being slightly longer than intended and the second state (e.g unpressed) will end up being slightly shorter than intended, therefore over the period of a second (could be any amount of time) we end up with an average speed that can be a non integer sps rate(but won't always be 100% accurate, close but not 100%).

As for jitter all it does is rapid fire the /\ button whenever R1 is pressed, you will have to experiment with speed, I hear 20Hz is a good place to start.

[grizzfu88]

Ok, so i have been studying this topic for two weeks now. I have a VX7 board in my controller and using my arduino as a oscope i can see the dips and timing on com1 and com2. however i cannot get a signal in. if I short the battery + to the com it does crazy stuff but if i try any external source it does nothing. any ideas here? i have been racking my brain trying to figure out what im doing wrong!! any help is appreciated.

BTW thanks everyone here! I have learned alot of different things along this road.

Edit i got it semi working on a attiny85 with arduino bootloader. if anyone is interested in jumping on board with my project please let me know and im posting the basic code i got it to rapid fire with. )

this is just the rcommon and + & -

UDATED WITH BUTTON LIST AND TIMING


void setup()
{
 
}



void loop()
{
  pinMode(1, INPUT);
  if (digitalRead(1) == 0)
  {
  delayMicroseconds(50); //R2 skip
  pinMode(1,OUTPUT);     
  digitalWrite(1,HIGH); //R1
  delayMicroseconds(50);//R1
  digitalWrite(1,HIGH); //X
  delayMicroseconds(50);//X
  digitalWrite(1,HIGH); //O
  delayMicroseconds(50);//O
  digitalWrite(1,HIGH); // /\
  delayMicroseconds(50);// /\
  digitalWrite(1,HIGH); // []
  delayMicroseconds(50);// []
  }
 
}


}

[SethMods]

Man, I think you are going to get erratic results until you switch that input to analog and "read" it either via a comparator or analog-to-digital.

And I'm not even sure the ADC will work. The mod I came up with is running at 16Mhz and it wasn't fast enough to accurately sync to the controller with the ADC. I HAD to go the comparator route. (...described here.)

It's like threading a needle with all the different inputs matrixed onto the one pin. You pick up your signal even 100 uS over or under and you can run into problems.

Do you mind if I ask why you have it set to a Digital Input?

[grizzfu88]

All Digital and it runs like a charm. i added a delay to set the sps.



void setup()
{

}



void loop()
{




 
  delay(2);
    pinMode(1, INPUT);
    if (digitalRead(1) == 0)
    {
    delayMicroseconds(50); //R2 skip
    pinMode(1,OUTPUT);     
    digitalWrite(1,HIGH); //R1
    delayMicroseconds(50);//R1
    }




}

Also if your not powering your chip from the controller itself it wll give you crazy stuff or just nothing. i have a adafruit trinkit im going to mount inside the controller replacing a rumble motor its also attiny85 based and already has usb access.

[gmod]Please click the 'modify' button and edit your posts rather than double posting, thanks.[/gmod]

[SethMods]

I...don't...


You are confusing me.

Each individual input is "switched" for ~500uS not 50uS on the PS3 controller.

And you aren't driving R1 High and Low in your code. You are only driving it High.




...unless I am missing something here.

EDIT:
Ok, I am still confused, but I realize now that I may not have made myself very clear on the Digital vs Analog and the need for exact timing.

So, ultimately when you say "if (digitalRead(1) == 0)" you are essentially synchronizing the Arduino to the PS3 controller's timing. You are getting them in the same time frame. If we can do this then we know that there is a part of the frame for each button where we can first read the value and then second we can drive the button how we want...whether pressed or released. And the PS3 is consistent/exact enough with its timing that we can make statements like "Once you detect the start of the frame wait 70us for the signal to settle. Then take a reading. Then force the signal high or low as needed. Hold that for 270us then stop driving it high or low(switch back to input)..." (...which happens to be the timing that I use for my PS3 mod.) But with Digital Inputs you get a gray area where a voltage could read either High or Low. There are no guarantees because the microcontroller isn't expecting a range. It is expecting either Vdd or Vss for a 1 or a 0. So what happens is in one frame you pick up the start maybe 30uS too early. And then in the next frame you pick up the start maybe 50uS too late. So that your static values of when to do what as far as reading and overriding get skewed and happen too soon or too late missing the critical window. This is the problem that I had that forced me to use a Comparator. Granted I used a Microchip instead of Atmel like the Arduino, but I have mine running at 16Mhz. It looks like the "Due" is the only Arduino that runs faster than that. So I would expect you would have the same limitations that I did.

[RDC]

Do the rest of the buttons on the COM2 line work normally with no ill effects? R2, R1, X, O, [] and /\? because I'll wager they don't, or that pressing one or more of them will throw that all out of wack.

On the subject of connecting the B+ line to the COM line, and powering the Arduino externally with voltages that are even higher than B+ in the controller, no idea where you came up with that, but that can potentially damage the controller. You should use the 2.8v switched source in the controller to power your chip.

[grizzfu88]

Everything works normally except r1 it rapid fires. Idk Iwas just sharing what iI've found that has worked for me everyone else has the microchip versions why not atmel lol

And I distinctly said it has to have power from the controller and. You cannot test it with the arduino at
all . program the  Chip and try it in the sockect wired in the controller.

If anyone has any ideas of a better or more accurate way please and in detail as the is is my first venture  in electronics. I have made a oscope from arduino and could see the voltage drops.
All this is on a vx7 board

[RDC]

What you distinctly said was..

if I short the battery + to the com it does crazy stuff but if i try any external source it does nothing. any ideas here? i have been racking my brain trying to figure out what im doing wrong!! any help is appreciated.

..and that is what I was replying to.


If that works there then great, and this isn't any kind of MC vs AT thing that's been beat to death, it's just from how everyone else has had to get the thing working that really shouldn't work, at least not without some bugs.

The falling edge of the start of the data train, R2 button, is used for the trigger event to start things off. Since that does not go low enough for a Digital IO on the PIC to register (0.8v TTL or 0.2v Schmitt) that's where difference #1 comes from. It seems the chip's Digital IO you're using is far less picky. This is why everyone has had to use either the ADC or the faster Comparator method to tell when that falling edge has begun to start things off, then it's timed up from there to drive the R1 bit Hi for 'x' number of times.

Since you only have a 50us delay after R1, that's where difference #2 is at. That code will start 'looking' at the data train pulse again right after R1 and not skip over the rest of the buttons. Press all 4 face buttons at once and hold them a few seconds, X, O, [ ] and /\, and if one of them doesn't act up with all 4 pressed I'll be extremely surprised.

[grizzfu88]

Went through it and you sir are correct in fact O and R2. Why does this work though I thought the r2 dip went all the way to 0? And I see your point about the delay issue. The b+ was just to see if I could get some kind of interaction.

As far as the avr vs micro its all I have at this point is there a reason I shouldn't use this chip?

[SethMods]

Went through it and you sir are correct in fact O and R2. Why does this work though I thought the r2 dip went all the way to 0? And I see your point about the delay issue. The b+ was just to see if I could get some kind of interaction.

As far as the avr vs micro its all I have at this point is there a reason I shouldn't use this chip?

I think the reason it works is that you are forcing the output high but with inaccurate sync so that sometimes it lands in the right spot and other times it does not...which is simulating Rapid Fire.

And "No" there is no right answer when it comes to what chip you want to use. If Arduino would have been out 10 years ago when I got started I probably would be using it today for all my projects. As it is..."some people have to learn the hard way."

But listen to RDC over me. He's the man.