Input for the xbox one controller rapid fire

[GrammatonKlerik]

The one from the play and charge kit.  There are 4 little bumper terminals on the board that are only used for the rechargable battery, it's right inbetween the two large tines that normal AA batteries use.

[rapidfiremoddr]

0.5mA measured where exactly?  If you didn't cut any traces and/or remove any components from the board and measured the collector current by putting an ammeter inline then what you measured is Average current which is not what you care about, you want instantaneous current which you can get with an o-scope or simulation.   The average current is going to be very low because most of the time the BJT is off, but the instantaneous current is still in the 28mA range.

The way my code is, the BJT is on 50% of the time when the trigger is held down, so even though its average current it still can't be higher than 1mA. I measured the current from the trigger node (lower right pin of that MCU) to the emitter terminal of the BJT.

[Hazer]

The way my code is, the BJT is on 50% of the time when the trigger is held down, so even though its average current it still can't be higher than 1mA. I measured the current from the trigger node (lower right pin of that MCU) to the emitter terminal of the BJT.

What he means is that the Hall sensor is only on for a short period of time, and then it gets turned off (refer to previous o-scope screens). Your ammeter would average the current over time, not give you the current only during the pulses. So if the pulse is on for only 10% of the time, you are seeing only 10% of the current that happens during the pulse.

Also, I can understand why Grammatonkleriks sensors are broken. Just think about what these sensors are: They drive a specific voltage output related to the magnetic field they are exposed to. Most likely, they are op-amp driven internally. Since the sensors circuit is trying to drive a positive voltage, grounding the output would probably damage that circuit.

Personally, I dont see why anyone wants to even play around with the sensors direct output. What you are trying to manipulate is the MCU input, which (luckily) is on the other side of the RC filter. Keep all modifications there.

[GrammatonKlerik]

What he means is that the Hall sensor is only on for a short period of time, and then it gets turned off (refer to previous o-scope screens). Your ammeter would average the current over time, not give you the current only during the pulses. So if the pulse is on for only 10% of the time, you are seeing only 10% of the current that happens during the pulse.

Yes, exactly that.

Also, I can understand why Grammatonkleriks sensors are broken. Just think about what these sensors are: They drive a specific voltage output related to the magnetic field they are exposed to. Most likely, they are op-amp driven internally. Since the sensors circuit is trying to drive a positive voltage, grounding the output would probably damage that circuit.

The first pair were definitely due to what you just mentioned as connecting directly to the sensor's output pin was the recommended approach on SRK at the time; that has since changed in large part due to this thread.  Shame on me for not doing my due-diligence first.  The second pair I'm going to chalk up to some issue with the PnC pack as there is a direct short on-board between what is normally the VCC pin of the hall sensor to GND; this is with the sensor removed.

In any case I salvaged both boards by effectively removing the hall from the circuit by disconnecting the 100 ohm filter resistor (and cap for good measure.)  I then tied one of the 3.3v test points to a 10K pull-up resistor and then the other side of the resistor goes to the bottom pads of where the RC filter was.  Now I can safely pull the MCU pin to GND to activate a trigger pull just like all the other buttons.  This method will work for you rapid fire modders too if you send the hall sensors output to a comparator pin on the PIC to know when to start rapid fire.

[SethMods]

Guys,
  We are probably going to go round and round on what SHOULD be done. Here's my implementation. Here's what I'll be doing, and aside from somethings like XBox being able to detect a hacked controller because Vout is higher than 1.5V I think this is perfectly safe.

while( trigger > .20V){  //Dwell until hall is being powered
wait 480uS;                   //to allow Vout to settle
readRT();                       //Read and store RT voltage
    if( rt < setpoint ){
        //Execute RF by driving rt high or low for 600uS
       
    }
wait 5ms;                      //This puts us in the dead part of the frame about 2ms before the trigger is powered again

}   //Loop


Here's what the screenshots look like of the trigger being forced high and low.

High.



Low.


Also, I should mention that his was done with a 12f1822. So I've only tested with a 12f683 and a 12f1822, but both seem to have no problem driving Vout as long as you are in between the filter and MCU.

I'll post some open source code when I get around to it.

[rapidfiremoddr]

What he means is that the Hall sensor is only on for a short period of time, and then it gets turned off (refer to previous o-scope screens). Your ammeter would average the current over time, not give you the current only during the pulses. So if the pulse is on for only 10% of the time, you are seeing only 10% of the current that happens during the pulse.

Also, I can understand why Grammatonkleriks sensors are broken. Just think about what these sensors are: They drive a specific voltage output related to the magnetic field they are exposed to. Most likely, they are op-amp driven internally. Since the sensors circuit is trying to drive a positive voltage, grounding the output would probably damage that circuit.

Personally, I dont see why anyone wants to even play around with the sensors direct output. What you are trying to manipulate is the MCU input, which (luckily) is on the other side of the RC filter. Keep all modifications there.

Stupid me! I measured it with an o-scope and it was pulling 50mA- yikes! I tried some different series resistors and 50ohms was the highest I could go and still be able to drive the trigger to sufficient voltage to reliably simulate a release. With the resistor is pulls 25mA. Probably still very high, but unless I figure out a better way, I'm just going to hope for the best with that.



Also, if anyone could point out exactly which pins and where they're referring to with the MCU, resistor capacitor filter, etc. Where are these components and what is connected to what? That would be very helpful

[SethMods]

Kudos to RDC for the great board scans.

It goes something like this.

The MCU powers Vdd on the Hall Sensor through some sort of op-amp. Vout on the Hall Sensor reflects how close the magnet from the trigger is. The signal from Vout goes through the RC Filter and then back to MCU.

[GrammatonKlerik]

Glad to see some empirical  data.  I'm curious, does the XB1 recognize multiple trigger presses within a single frame?  Take the o-scope trace of when you forced it high midway into what I will call the 'active region.'  Since the trace stays at 0.45V for about 0.5ms before being forced high, is that recognized by a pull followed by a release?  My guess is no and the ADC on the MCU samples about 50 - 75% of the way in of the 'active region'.

[Hazer]

Its going to take some trial and error to figure that out. The PS3 controllers did somewhat the same thing with a train pulse (although all the buttons were connected to the same input). On that controller, the first half of the pulse was ignored (made it great for reading button presses physically) and the second half of the pulse was counted for the MCU. This made it so the Pic could read each pulse as an input (using comparator as all pulses are analog) and then you could output your override for the second half the pulse.

This could very well be the same case. Most likely, the MCU only checks the pulse once per pulse. So this could drive the maximum rapidfire rate.

In contrast, one thing never discussed is that the old Matrix controller was actually being 'matrixed' at a rate of 10kHz. So the older controllers could very well have been running at an inefficient rate.