GUN4IR - The Ultimate 4 Points Lightgun System

[JayBee]

That is something no other lightguns in the market can achieve at the moment, especially not with levels of accuracy also beating CRT guns
But you don't need to believe me on that, I'm preparing some videos to show that off, since I'm getting tired of people getting skeptical when I talk about my system performances 

I'd definitely be interested in seeing a video backing up that claim .  I have a dedicated 36" CRT and a PS2 with GunCons connected to it via RGB.  Speed and accuracy are at least "arcade quality" with this setup, but it's limited to the PS libraries.  FWIW, my interest in all of this is to turn that into a "gun system" which is capable of playing all of the light gun games with one gun and the same speed and accuracy as a GC2.  So, I'd be a happy camper if that is truly the case, and the minimum distance wasn't further than the 5 or so feet away I normally play from it.

Haven't had time to work on the vids lately, and not sure I will have time soon, so I made a quick side by side comparison of the native guncon 1 (connected with SNAX on the mister fpga, so as native as on a real ps1) vs the usb gun4ir, on a ps1 guncon game calibration screen.

I let you draw the conclusions you want with it

[RandyT]

I let you draw the conclusions you want with it

My conclusion is that your system is as fast as a stabilized (i.e. over-sampled) cursor in the calibration screen.   Unfortunately, no other conclusion can be really be drawn when using that screen as a basis for comparison. 

For purposes of calibration, the console averages the heck out of the cursor position data to find the mean position, as this will likely be a relatively stable representation of where the gun is actually pointing when not being averaged during the course of normal play.  That way, any deviation which occurs will be small and usually within the pre-defined hit-box set up in the game code.  If the code is acting on, for example, 50 of the GC's samples and only 10 of yours (not saying this is the case) you will not see it here.

In other words, that screen is a poor test for the purposes you most likely had in mind and probably doesn't demonstrate what you think it does.

[JayBee]

I let you draw the conclusions you want with it

My conclusion is that your system is as fast as a stabilized (i.e. over-sampled) cursor in the calibration screen.   Unfortunately, no other conclusion can be really be drawn when using that screen as a basis for comparison. 

For purposes of calibration, the console averages the heck out of the cursor position data to find the mean position, as this will likely be a relatively stable representation of where the gun is actually pointing when not being averaged during the course of normal play.  That way, any deviation which occurs will be small and usually within the pre-defined hit-box set up in the game code.  If the code is acting on, for example, 50 of the GC's samples and only 10 of yours (not saying this is the case) you will not see it here.

In other words, that screen is a poor test for the purposes you most likely had in mind and probably doesn't demonstrate what you think it does.

No, that means the latency of my gun system, with a PS1 60Hz game (in that case PS1 NTSC Point Blank), is as good as the original native PS1 gun connected to the native PS1 port (not USB).

The aim smoothing isn't working at all in the way you think it works
The in-game sample logic is always the same no matter the gun here. In this setup, the game sees both guns as guncons and so treat them equally.
One is a real native guncon with native direct ps1 connection, and the other uses a conversion from gun4ir usb data to guncon ps1 protocol.
In that calibration screen, on similar motion, the total added latency by the smoothing will always be the same on every gun.
For instance if you average the aim over a constant sample of 4 frames, then the added latency on equal motions will always be equal, allowing you to compare each of the guns on equal ground over the course of a few motions. It's very basic math.
It doesn't magically change the smoothing sample depending on the gun like you believe, ps1 wasn't that modern and has no way to differentiate the guns here
I even used a music metronome for that video to reproduce the same matching rythm, trajectory and speed of motion with both gun.
So in short if a gun had more latency than the other one, it WOULD be very visible.

And this video is in no way to show the aim accuracy, as the accuracy was already shown extensively in the previous videos.
The only reason I use that calibration screen is because it's the only one that has native IN GAME crosshair tracking with constant (non variable) aim smoothing/latency, that allows me to have precise comparison of the motion latency between guns.
But I though all that was pretty obvious and everyone understood it.

I don't know exactly what I did to you or why you decided to be so anti gun4ir, but it is very clear now that no matter how good my proofs are, you won't believe them and will always find convoluted excuses not to. So I'm done losing my time trying
If you have something against me or my system, stop fooling around with the passive agressitivy, be brave and say what you have to say right to my face, here or in pm
Assume your point of view whatever it is. Meanwhile, believe whatever you want about it. You do you bud 

[RandyT]

Not sure if it's intentional, but it seems like you totally missed what I wrote.  I'm not sure how it's possible, because I even took the time to explain it.  No-one ever implied that the code treated one gun different from another.  Just the opposite, in fact.

The calibration screens average a bunch of samples before displaying a position on the screen, which is the reason why the cursor lags behind the gun position when it's moving.  Therefore, it cannot show how fast EITHER system is.  With that screen, we know that it is acting on every authentic sample from the real GC, because it is programmed to work at the limits of that technology.  In the case of emulated controls, the sample rate of the code will be the same, but the rate at which that data changes in whatever temporary buffer in which it is stored, cannot be discerned.  i.e. if a non-GC gun is used, it just plucks data from the buffer at the rate it is expected to have been updated, and if it is unchanged due to a difference in actual reporting rate from the device, it doesn't care.  It will happily collect duplicate reports and average them into the position.  How much or if any differences will be visible is extremely dependent upon the speed at which the gun is moving, the number of samples taken and the amount of deviation in each respective group of samples.  i.e. variables which are virtually impossible to control. 

No-one is implying that your system doesn't do what you claim.  But I am stating as a matter of fact that the method you are attempting to use to demonstrate that claim, is terribly flawed.  But if this test is the one you used to come to your conclusion, you may wish to find a different method, because this one is incapable of showing you what you appear to want it to.

But in the end, there's no need to make grandiose claims or worry about backing them up.  Either the system works well-enough or it doesn't.  Everything in-between is academic.  Attempting to villainize someone who points out discrepancies in what is a technical discussion seems equally unnecessary.

[JayBee]

Not sure if it's intentional, but it seems like you totally missed what I wrote.  I'm not sure how it's possible, because I even took the time to explain it.  No-one ever implied that the code treated one gun different from another.  Just the opposite, in fact.

Oh I read everything carefully, english isn't my native language obviously but you don't write anything hardly difficult to understand.
Somehow you continiously miss the point and lose youself in pointless overthinking/overanalysing. You misunderstand how that tech and how the MiSTer FPGA input handling work, or what I am showing here.

The calibration screens average a bunch of samples before displaying a position on the screen, which is the reason why the cursor lags behind the gun position when it's moving.

No kidding, sherlock.

Therefore, it cannot show how fast EITHER system is.  With that screen, we know that it is acting on every authentic sample from the real GC, because it is programmed to work at the limits of that technology.

Yes, it doesn't measure how fast either of the gun are, it shows the latency difference, on a big enough sample with similar enough gun motion to be significative, with the limit of the tech in mind.

In the case of emulated controls, the sample rate of the code will be the same, but the rate at which that data changes in whatever temporary buffer in which it is stored, cannot be discerned.  i.e. if a non-GC gun is used, it just plucks data from the buffer at the rate it is expected to have been updated, and if it is unchanged due to a difference in actual reporting rate from the device, it doesn't care.  It will happily collect duplicate reports and average them into the position.

The sample rate of the emulated controls is totally irrelevent here.
The PS1 reads the guncon input only once a frame obviously, so in the best case scenario, the gun4ir itself + conversion of the HID data to the guncon data will take less than that and there will be no difference with the original guncon.
And in the worst case it's slower than a frame, missing the mark and adding one (or more) frame of latency compared to the guncon.

How much or if any differences will be visible is extremely dependent upon the speed at which the gun is moving, the number of samples taken and the amount of deviation in each respective group of samples.  i.e. variables which are virtually impossible to control. 

Again, duh.
You completely ignored the part where I explained my methodology.
Oh sure it's not super ultra precise to the 10th of ms or 2mm motion between each gun, but it doesn't need to be, the motion is similar enough to be usable.
As I explained if the gun input + conversion isn't fast enough it will add one or more frames of latency, 16ms each, even with the smoothing.
No matter the minor differences of speed and acceleration between each gun motion, any difference that big would be very visible on the vid I show here, despite the small duration of the vid (trying to avoid harming epileptic people with long vid of blinking lights).
Just take any as many points of reference in the video as you want and see how many 60Hz frame it takes for each gun crosshair to reach the passing position of the gun aim.
It's all a balance between precision of the test, and what we want to show, while keeping it simple and readable.

No-one is implying that your system doesn't do what you claim. 

You did, more than a few times, in your usual way

But I am stating as a matter of fact that the method you are attempting to use to demonstrate that claim, is terribly flawed.  But if this test is the one you used to come to your conclusion, you may wish to find a different method, because this one is incapable of showing you what you appear to want it to.

No "matter of fact" here, just your own opinion, that has absolutely no more value than anybody else.
Having a good english semantic and claiming you know your stuff doesn't make you right.
You don't seem to have any real interest in using my system, or contributing to it, so I have no clue what's your issue with me and my work and why you keep going at it like that
Anyway it's my thread so obviously I feel obligated to answer, but man what a massive waste of time.

But in the end, there's no need to make grandiose claims or worry about backing them up.  Either the system works well-enough or it doesn't.  Everything in-between is academic.

No grandiose claim here, just doing my job to inform my users.
By saying everything in between is academic, or that backing up the claims isn't useful, you are basically saying the users are too stupid to want to know the real specs and performance of the product.
I don't know about you, but that isn't how I treat my users.
If I did we both know my system wouldn't be as popular as it is now.

[RandyT]

We are just talking past each other at this point, and your defenses seem to be in overdrive.  When a claim is made that X is as good or even better than Y relative to a certain specification, it should probably be expected that the claim will be called into question, and in cases where it doesn't seem plausible, the methodology used to come to that conclusion as well.  I've stated why, from a technical standpoint, the test you showed can't really affirm your claim.  You can accept that or not.

But as you stated, the "proof is in the pudding".  Obviously, the system has very good accuracy and quite possibly better than the original when dialed in, especially in the X direction where jitter is more of an issue with the original technology.  Interestingly, that increase in accuracy is precisely what can mask a possible difference in speed when the positions are averaged, as they are in that calibration screen.  Again, this is academic and related specifically to the claims you have made, and isn't intended to reflect poorly on the overall performance or quality of your system.

A more accurate lightgun system will trump a one or two frame difference in reporting speed all day long, for what good is more data if a larger percentage of it is incorrect?  Not much, and that doesn't seem to be the case with yours, so why so defensive?

Showing that a controller is as fast as the host system and software will ever allow is mind-numbingly simple, provided you have a few cycles to spare.  All it takes is adding a couple of lines of code to your firmware to toggle a spare pin, at the precise location where changes in your position calculations are "set in stone" and will be transferred, and then measuring the frequency of the signal on that pin with an oscilloscope.  So long as you aren't working from buffered data, it will paint a very clear picture as to timeliness of the updates.  If you are sending accurate updates 60 times a second and the host/software isn't able to act on those updates in near real-time, there's nothing you will ever be able to do about it.  In other words, even if it's not as timely as the original hardware and methodology, it's not on you, and the increase in accuracy will probably make up for it "in spades".

[JayBee]

We are just talking past each other at this point, and your defenses seem to be in overdrive.  When a claim is made that X is as good or even better than Y relative to a certain specification, it should probably be expected that the claim will be called into question, and in cases where it doesn't seem plausible, the methodology used to come to that conclusion as well.  I've stated why, from a technical standpoint, the test you showed can't really affirm your claim.  You can accept that or not.

You are the only one who actually don't agree with my methodology here, with your logic as broken and wrong as you think my methodology is.
Funny the way you always consider everything you say as THE absolute truth and clearly never consider you could ever be wrong. What makes you so sure you are right here?
In reality what you say is just your own opinion, just words on the internet, and has nothing else to show off, it has no more value than anybody else's opinion at that point.

But as you stated, the "proof is in the pudding".  Obviously, the system has very good accuracy and quite possibly better than the original when dialed in, especially in the X direction where jitter is more of an issue with the original technology.  Interestingly, that increase in accuracy is precisely what can mask a possible difference in speed when the positions are averaged, as they are in that calibration screen.  Again, this is academic and related specifically to the claims you have made, and isn't intended to reflect poorly on the overall performance or quality of your system.

No, the CRT guncon at that distance does not exhibit more jittery than my gun, and no, averaging the aim won't make any significative difference on FAST motion. It's very basic math bud

A more accurate lightgun system will trump a one or two frame difference in reporting speed all day long, for what good is more data if a larger percentage of it is incorrect?  Not much, and that doesn't seem to be the case with yours, so why so defensive?

Again, guncon and gun4ir are equally accurate in that setup, and no, it doesn't have any incidence on the speed of fast motions. For instance a jittery of 2~3 pixels (which is about what we get on the guns at that distance) is simply changing nothing when the gun moves at a speed of 20 pixel or more on each frame over the course of several frames. If one of the guns had a constant extra latency of one frame, in that theorical case it would always drag 20+ pixel behind what the other gun does, and be clearly visible in the video.
Averaging wouldn't hide that, as during the motion the lag would propagate to every single position.
When every single position data has the same offset, averaging them will NOT remove that offset, that's the opposite, it would actually show it more clearly and reliably without the jitter.
Again, very basic math. I can't believe I even have to explain that. Your point is totally irrelevent at best, very insulting at worse.

Showing that a controller is as fast as the host system and software will ever allow is mind-numbingly simple, provided you have a few cycles to spare.  All it takes is adding a couple of lines of code to your firmware to toggle a spare pin, at the precise location where changes in your position calculations are "set in stone" and will be transferred, and then measuring the frequency of the signal on that pin with an oscilloscope.  So long as you aren't working from buffered data, it will paint a very clear picture as to timeliness of the updates.  If you are sending accurate updates 60 times a second and the host/software isn't able to act on those updates in near real-time, there's nothing you will ever be able to do about it.  In other words, even if it's not as timely as the original hardware and methodology, it's not on you, and the increase in accuracy will probably make up for it "in spades".

Once again you have no clue how things work, and what I wanted to show.
Your suggestion is a very basic and widely used method to measure digital state change like with button, but won't work here because you are completely ignoring the latency of the sensor itself, so even if you measure the speed at which the sensor or the gun send data (which I did already, it's ~4ms for the sensor itself, ~5ms for the sensor+the rest, over several thousand samples) in comparison to the speed the host hardware handles it, it won't give you squat for the total latency.
Your methodology here is completely useless in this context, and doesn't show anything valuable I don't already know.
Even if I measure the latency of the sensor itself, it wouldn't show much valuable information for my end users, as it wouldn't be a real world case.

What I am showing here is how the gun can match the native guncon on the MiSTer fpga PS1 core, nothing more, nothing less.
It's not supposed to be a very technical video, just showing the MiSTer users what they can expect from it in real world use, which is what it is all about here.
When I said the gun4ir was doing as good as CRT guns at their own game few messages ago, you said you'd be curious to see a video that shows it.
Which is what I clearly did. Now that you accept it as proof or not it's totally on you. I know my methodology and the result of it are sound, especially after all the research and consulting I did, no matter what you think you might know better.
Some of us just don't make claims without actually thoroughly studying and testing that claim by themselves
And I accept any criticism, but only when they actually make sense in the context.

But you clearly won't change your mind anyway, so let's agree to disagree and keep it that way, I wasted way too much time on this already.

[RandyT]

If you want to boil it down to what you stated, what you showed was that it keeps up in the averaged calibration screen, not in actual use.  I don't think that's a better way to think about it.  And the math you are using includes a lot of assumptions, like the error being a constant.  "Jitter' is by it's nature, specifically not that, rather a small error in timing. Timing errors can manifest themselves as both over-runs and under-runs.  The composite cable of GCs provide a tighter timing reference over earlier lightguns, but it's not digitally perfect, due to the analog parts and signals, and still subject to these timing errors. This would be much more apparent on a screen which is not averaging/oversampling the cursor position.  But I get that there aren't really any options in available software to view it in that form.

But I will admit that I do not know what MiSTer does with an original GC.  It could be very different from how it interacts with an original console.

As for the method I stated not being valuable, it was very specific that it included accurate data.  I.e. the latest data available from the camera module, so it's factored in.  I don't believe that there is currently a better sensor or method (reasonably) available for this type of controller, so what the camera module is doing is somewhat moot, so long as it is faster than 60 fps (which it easily is and then some) with enough margin left for processing overhead to meet the 60fps of the original control.  That total timeframe is exactly what would be measured at the point in which the data is to be transferred to the host.  Or do you believe otherwise?  If so, I'm interested to know why, because that's where the "rubber meets the road" and anything beyond that is not in your control.

[JayBee]

If you want to boil it down to what you stated, what you showed was that it keeps up in the averaged calibration screen, not in actual use.  I don't think that's a better way to think about it.  And the math you are using includes a lot of assumptions, like the error being a constant.  "Jitter' is by it's nature, specifically not that, rather a small error in timing. Timing errors can manifest themselves as both over-runs and under-runs.  The composite cable of GCs provide a tighter timing reference over earlier lightguns, but it's not digitally perfect, due to the analog parts and signals, and still subject to these timing errors. This would be much more apparent on a screen which is not averaging/oversampling the cursor position.  But I get that there aren't really any options in available software to view it in that form.

As for the method I stated not being valuable, it was very specific that it included accurate data.  I.e. the latest data available from the camera module, so it's factored in.  I don't believe that there is currently a better sensor or method (reasonably) available for this type of controller, so what the camera module is doing is somewhat moot, so long as it is faster than 60 fps (which it easily is and then some) with enough margin left for processing overhead to meet the 60fps of the original control.  That total timeframe is exactly what would be measured at the point in which the data is to be transferred to the host.  Or do you believe otherwise?  If so, I'm interested to know why, because that's where the "rubber meets the road" and anything beyond that is not in your control.

I've taken all parameters into consideration and none of what you are saying here have any relevance or is any significant for the current case.
You are trying to find issues when there is none, just to desperately trying to make your point.
The analog sync and CRT gun sensor are precise down to a few micro seconds, and are very consistent, else it won't even work the way it does. The main cause of those jitter we get with these CRT guns isn't even the analog/digital imprecision. And again, for fast motion, in the course of several frame, none of the inaccuracies or errors are significative enough to actually cause issues and prevent a good analysis of the data. If it was the case it would also be very visible even with the limits of the hardware.

And the rest of your message again completely misses the point and the argument you are trying to make it totally empty in relation to the video and what it's showing.

But I'm done wasting my time arguing here, at that point you totally lost yourself in convoluted explanations that have no purpose or end.

Fine by me, but please stop wasting both of our time and polluting that thread, and go doing something else, more useful, like spending time with your friends or family for the new year celebrations.

[RandyT]

Of course it has to be in the microseconds.  The raster is moving extremely fast and if the timing wasn't reasonably precise, the cursor would bounce around so much you probably wouldn't see it. But that doesn't mean it is without error, as it would be if a similar system were possible in the purely digital realm (which it is obviously not.)

But no matter, you are correct that neither of us will likely see eye-to-eye on this.  It doesn't truly matter anyway, as the current best approach to this problem on modern displays is the one you, and a couple of others have taken, and no other approaches compare.  At least in my opinion.  None are going to be a perfect analog to the original technology, nor does it need to be, so long as it works well.  Yours obviously must to have so many happy users.

Hope you have a nice New Years celebration.

[JayBee]

Of course it has to be in the microseconds.  The raster is moving extremely fast and if the timing wasn't reasonably precise, the cursor would bounce around so much you probably wouldn't see it. But that doesn't mean it is without error, as it would be if a similar system were possible in the purely digital realm (which it is obviously not.)

But no matter, you are correct that neither of us will likely see eye-to-eye on this.  It doesn't truly matter anyway, as the current best approach to this problem on modern displays is the one you, and a couple of others have taken, and no other approaches compare.  At least in my opinion.  None are going to be a perfect analog to the original technology, nor does it need to be, so long as it works well.  Yours obviously must to have so many happy users.

Hope you have a nice New Years celebration.

Thanks, you too 

[_Gioacchino_]

I bought one the TC4 gun clones from Aliexpress and they are great quality. I did successfuly convert it to GUN4IR but there wasn't enough room for everything. I was a tight space to put the Pro Micro board and the camera had to stick out

i will plan for a double pair of tc 3 or 4 guns...
i have many question about it so:

1) main difference is a good fit for dfrobot cam and rumble motor for tc3 but hte are a lot expensive (200 € shell+solenoid) instead of tc4. right?

for money reason however i'm gonna to buy tc4 guns+solenoids


2)SOLENOIDS they wants a 24 v power supply but what is hte value of current

Inviato dal mio RMX2170 utilizzando Tapatalk

[Gate_001]

Salut JayBee,
Il est très bien ce projet.

I was DIYing the SAMCO lightgun, when I came across your project. I think I'll change for your lightgun project 

I'm going to use an Arduino Pro Micro that I already have. From what I understand, you have to choose between the DPad and the RGB led. What is this LED for?

[ben_r_]

This looks awesome and I can't wait to get started. Sent JayBee a $20 donation a few days ago via PayPal, but I guess it's waiting to clear? Haven't heard anything back yet.

JayBee: PM me if you happen to see this and I can let you know the transaction details.

[1amgoingin]

Hi, I donated 20 dollars for the project , I am waiting for my license for GUI, thank you.

[JayBee]

Salut JayBee,
Il est très bien ce projet.

I was DIYing the SAMCO lightgun, when I came across your project. I think I'll change for your lightgun project 

I'm going to use an Arduino Pro Micro that I already have. From what I understand, you have to choose between the DPad and the RGB led. What is this LED for?

Merci 
So the RGB is one of the optional feedbacks you can have, to either use as basic fire/reload or synchronized with in game feedback.
Yes you will need to choose between this and the dpad, as the pro micro doesn't have enough pins.
If you want to have everything (dpad and all feedbacks) at the same time, then you can use a full size micro board or a modded teensy 2.0.

This looks awesome and I can't wait to get started. Sent JayBee a $20 donation a few days ago via PayPal, but I guess it's waiting to clear? Haven't heard anything back yet.

JayBee: PM me if you happen to see this and I can let you know the transaction details.

Hi, I donated 20 dollars for the project , I am waiting for my license for GUI, thank you.

I sent everything already, if you haven't received anything yet please check your email box spam folder. If it's still not there, feel free to contact me in pm.

[Gate_001]

Salut JayBee,
Il est très bien ce projet.

I was DIYing the SAMCO lightgun, when I came across your project. I think I'll change for your lightgun project 

I'm going to use an Arduino Pro Micro that I already have. From what I understand, you have to choose between the DPad and the RGB led. What is this LED for?

Merci 
So the RGB is one of the optional feedbacks you can have, to either use as basic fire/reload or synchronized with in game feedback.
Yes you will need to choose between this and the dpad, as the pro micro doesn't have enough pins.
If you want to have everything (dpad and all feedbacks) at the same time, then you can use a full size micro board or a modded teensy 2.0.

If I find a way to release 3 pins, will you make another version? 
My idea is the following:
I don't need Bluetooth HID, so 2 free pins. For the third pin we can combine the right and left DPad on the same pin A10 and read this pin in analog. 0V is left, 5v is right and 2.5V neither are on.

[JayBee]

Salut JayBee,
Il est très bien ce projet.

I was DIYing the SAMCO lightgun, when I came across your project. I think I'll change for your lightgun project 

I'm going to use an Arduino Pro Micro that I already have. From what I understand, you have to choose between the DPad and the RGB led. What is this LED for?

Merci 
So the RGB is one of the optional feedbacks you can have, to either use as basic fire/reload or synchronized with in game feedback.
Yes you will need to choose between this and the dpad, as the pro micro doesn't have enough pins.
If you want to have everything (dpad and all feedbacks) at the same time, then you can use a full size micro board or a modded teensy 2.0.

If I find a way to release 3 pins, will you make another version? 
My idea is the following:
I don't need Bluetooth HID, so 2 free pins. For the third pin we can combine the right and left DPad on the same pin A10 and read this pin in analog. 0V is left, 5v is right and 2.5V neither are on.

I am not doing custom versions on demand, for optimisation purpose and because I use a lot of the pins special functions, everything is hardwired in each version.
Resistor ladders are also very unreliable, have far more cpu and memory overhead, slowing down the code and adding latency, and would require me to rewrite my whole input management code around it.
Doing a custom version like that would cost me way more in work than it would cost you to buy a full micro board that has everything integrated already 
That being said, if you are not interested in RGB led out, you already have everything you need there.

[Gate_001]

Salut JayBee,
Il est très bien ce projet.

I was DIYing the SAMCO lightgun, when I came across your project. I think I'll change for your lightgun project 

I'm going to use an Arduino Pro Micro that I already have. From what I understand, you have to choose between the DPad and the RGB led. What is this LED for?

Merci 
So the RGB is one of the optional feedbacks you can have, to either use as basic fire/reload or synchronized with in game feedback.
Yes you will need to choose between this and the dpad, as the pro micro doesn't have enough pins.
If you want to have everything (dpad and all feedbacks) at the same time, then you can use a full size micro board or a modded teensy 2.0.

If I find a way to release 3 pins, will you make another version? 
My idea is the following:
I don't need Bluetooth HID, so 2 free pins. For the third pin we can combine the right and left DPad on the same pin A10 and read this pin in analog. 0V is left, 5v is right and 2.5V neither are on.

I am not doing custom versions on demand, for optimisation purpose and because I use a lot of the pins special functions, everything is hardwired in each version.
Resistor ladders are also very unreliable, have far more cpu and memory overhead, slowing down the code and adding latency, and would require me to rewrite my whole input management code around it.
Doing a custom version like that would cost me way more in work than it would cost you to buy a full micro board that has everything integrated already 
That being said, if you are not interested in RGB led out, you already have everything you need there.

No problem, I'll buy a new board or ditch the DPad.
By the way, the Teensy 2.0 is a discontinued board. Have you thought about porting your code to more recent Tennsy?
I just sent you $20

[JayBee]

Salut JayBee,
Il est très bien ce projet.

I was DIYing the SAMCO lightgun, when I came across your project. I think I'll change for your lightgun project 

I'm going to use an Arduino Pro Micro that I already have. From what I understand, you have to choose between the DPad and the RGB led. What is this LED for?

Merci 
So the RGB is one of the optional feedbacks you can have, to either use as basic fire/reload or synchronized with in game feedback.
Yes you will need to choose between this and the dpad, as the pro micro doesn't have enough pins.
If you want to have everything (dpad and all feedbacks) at the same time, then you can use a full size micro board or a modded teensy 2.0.

If I find a way to release 3 pins, will you make another version? 
My idea is the following:
I don't need Bluetooth HID, so 2 free pins. For the third pin we can combine the right and left DPad on the same pin A10 and read this pin in analog. 0V is left, 5v is right and 2.5V neither are on.

I am not doing custom versions on demand, for optimisation purpose and because I use a lot of the pins special functions, everything is hardwired in each version.
Resistor ladders are also very unreliable, have far more cpu and memory overhead, slowing down the code and adding latency, and would require me to rewrite my whole input management code around it.
Doing a custom version like that would cost me way more in work than it would cost you to buy a full micro board that has everything integrated already 
That being said, if you are not interested in RGB led out, you already have everything you need there.

No problem, I'll buy a new board or ditch the DPad.
By the way, the Teensy 2.0 is a discontinued board. Have you thought about porting your code to more recent Tennsy?
I just sent you $20

It's discontinued but you can still find plenty of clones online 
I use it because it's the same chipset as the micro and pro micro, it allows me to still use the same AVR Studio (I'm not using arduino IDE).
Same issue, if I wanted to port the code to a more recent teensy, I'd have to rewrite the entire firmware from scratch to make it compatible.

[vd2021]

JB, I'm refreshing my cab and have discovered your project. I used these, in the cab, with the CRT. I believe they are ps guncon2. Do these have the space for your kit? I also plan to go rumble/vibration.  I also see you nolonger include the solenoid. Is the kit still priced the same as it was with it? Thanks.

[TimeCrisis]

@JayBee what do you think of the people selling your Gun4IR custom mod in china

[Link removed by saint]

the buttons seem cool, maybe the arcade guns are a better option than the guncon 2 shell.

[JayBee]

JB, I'm refreshing my cab and have discovered your project. I used these, in the cab, with the CRT. I believe they are ps guncon2. Do these have the space for your kit? I also plan to go rumble/vibration.  I also see you nolonger include the solenoid. Is the kit still priced the same as it was with it? Thanks.

Are you referring to the kits Ray is selling? if that's the case you'd have to ask him directly

@JayBee what do you think

the buttons seem cool, maybe the arcade guns are a better option than the guncon 2 shell.

What do you believe I think of people using my work to make money without even crediting me or giving me anything in return?
Please do not share that kind of links here if you care about my system, bad advertisement is still advertisement 

[talem84]

Can't wait to use this !

[Marsupial]

No problem, I'll buy a new board or ditch the DPad.

I'd simply ditch the rgb led.

I installed it when building mine, and find it distractful. Might simply disconnect it. I know it's a preference thing but I'd rather have more inputs than the blinking LEDs. That said, I don't "change mode" ever with this system, those who do may want status output.

Envoyé de mon SM-S901W en utilisant Tapatalk

[JayBee]

No problem, I'll buy a new board or ditch the DPad.

I'd simply ditch the rgb led.

I installed it when building mine, and find it distractful. Might simply disconnect it. I know it's a preference thing but I'd rather have more inputs than the blinking LEDs. That said, I don't "change mode" ever with this system, those who do may want status output.

Envoyé de mon SM-S901W en utilisant Tapatalk

Yeah I always put mine in a non direct lighting configuration, and reduce the power a lot, to just see them but not be distracted by them.

[ZTylerDurden717]

[deleted comment]

[Daniel B.]

I'm not seeing the option to buy the license and stuff on the website. What is the best way to do so? Does it also include a BOM or do I need to sort through this thread?

Can't wait! Looks amazing!

Edit- I read the first post, thanks!

[Daniel B.]

I've completed the donation! I look forward to receiving the information!

[grotesque]

Hi everyone,

I'm in the process of designing an arcade cab, with the build stage hopefully starting soon, and want to integrate the Gun4IR LEDs into it. I have a few questions I would really appreciate some guidance with. I searched this long thread plus read the Gun4IR manual but didn't find the same questions but apologies if this has already been explained.

• Will it be an issue that the panel is tilted backwards about 12 degrees rather than being exactly vertical? That's just the way the cabinet design is. Should I try to mount the LEDs to point exactly horizontally at the player or just perpendicular to the display will be fine?
• Does it make much difference to have the LEDs mounted in a small triangle pattern vs a straight line? I've seen examples of both but not sure if either is preferable. Is there any recommendation on the distance between the LEDs in the clusters?
• I will probably be standing 1-2m from a 32" screen but my guns only have Fish Eye lenses. Would I be better suited with Wide Angle lenses? If so, is there a recommended place to get them from?

Thanks!

[JayBee]

Hi everyone,

I'm in the process of designing an arcade cab, with the build stage hopefully starting soon, and want to integrate the Gun4IR LEDs into it. I have a few questions I would really appreciate some guidance with. I searched this long thread plus read the Gun4IR manual but didn't find the same questions but apologies if this has already been explained.

• Will it be an issue that the panel is tilted backwards about 12 degrees rather than being exactly vertical? That's just the way the cabinet design is. Should I try to mount the LEDs to point exactly horizontally at the player or just perpendicular to the display will be fine?
• Does it make much difference to have the LEDs mounted in a small triangle pattern vs a straight line? I've seen examples of both but not sure if either is preferable. Is there any recommendation on the distance between the LEDs in the clusters?
• I will probably be standing 1-2m from a 32" screen but my guns only have Fish Eye lenses. Would I be better suited with Wide Angle lenses? If so, is there a recommended place to get them from?

Thanks!

Hi,
To answer your questions:

• no issue, 12 degrees isn't much and should still work nicely
• it all depends on your LEDs specs. If using powerful and good angle ones, in line it's fine, else in triangle (with each bent a bit on they side) is a bit better. You should keep them as close as possible from each other.
• 2m seems good for an optimal playing distance with either fish eye or wide lens. You probably won't need wide lens tho.

[grotesque]

Thanks JayBee, much appreciated. For question #2, I'm using the high power LED kits from RPEG Electronics. The LEDs will be mounted behind a layer of perspex (this is going to cover the whole screen/front panel of the cabinet) so I assume it's safer to put them in a triangle shape to have the best output. When you say to bend them a bit, is that so that each LED is pointing more towards the player? Just want to be sure I'm bending/aiming them correctly! Thanks

• no issue, 12 degrees isn't much and should still work nicely
• it all depends on your LEDs specs. If using powerful and good angle ones, in line it's fine, else in triangle (with each bent a bit on they side) is a bit better. You should keep them as close as possible from each other.
• 2m seems good for an optimal playing distance with either fish eye or wide lens. You probably won't need wide lens tho.

[Bambam1963]

I am a huge fan of this tech.  I got my old PS1 Namco Guncon 45 up and running.  It works and tracks great.  I do, however, need two fish-eye lenses as I currently have to sit quite far back from my monitor for the gun to track properly. I am unable to find any fish-eye lenses to finish my project. Can someone point me in the right direction? Thank you.

[Daniel B.]

Is there a recent BOM for the current "best way" to accomplish all this? I want to start putting together my parts list and get any overseas ordering done as soon as possible. I'll admit, I made it about 12 pages through before I sent jaybee the donation so I may be out of touch lol.

[JayBee]

Thanks JayBee, much appreciated. For question #2, I'm using the high power LED kits from RPEG Electronics. The LEDs will be mounted behind a layer of perspex (this is going to cover the whole screen/front panel of the cabinet) so I assume it's safer to put them in a triangle shape to have the best output. When you say to bend them a bit, is that so that each LED is pointing more towards the player? Just want to be sure I'm bending/aiming them correctly! Thanks

• no issue, 12 degrees isn't much and should still work nicely
• it all depends on your LEDs specs. If using powerful and good angle ones, in line it's fine, else in triangle (with each bent a bit on they side) is a bit better. You should keep them as close as possible from each other.
• 2m seems good for an optimal playing distance with either fish eye or wide lens. You probably won't need wide lens tho.

If it's the black LEDs points we made together, then no need to bend anything, it should work as is. The leds have enough angle to work nicely.

I am a huge fan of this tech.  I got my old PS1 Namco Guncon 45 up and running.  It works and tracks great.  I do, however, need two fish-eye lenses as I currently have to sit quite far back from my monitor for the gun to track properly. I am unable to find any fish-eye lenses to finish my project. Can someone point me in the right direction? Thank you.

Any cheap smartphone fish eye lens will work.

Is there a recent BOM for the current "best way" to accomplish all this? I want to start putting together my parts list and get any overseas ordering done as soon as possible. I'll admit, I made it about 12 pages through before I sent jaybee the donation so I may be out of touch lol.

Yes the full bom is the doc I send you with the license.

[TimeCrisis]

I noticed your website shows New slim IR LED points

are these the same as the ones I've already seen or are they new SLIM ones, i would like to see them.

[JayBee]

I noticed your website shows New slim IR LED points

are these the same as the ones I've already seen or are they new SLIM ones, i would like to see them.

Yes they are brand new, I haven't uploaded any image yet.

[KlausR]

Hi JayberH
Donation is done. Could you please send license, appreciate

[teozan]

Hello Everybody and to JayBee of course.
Few months ago (its one year almost) I had in mind to build this fantastic toy and purchased the license. I'm still at the license phase and one day will build my phisycal piece of gun

Recently I was thinking about the use of this gun with a PS3/PS4 console but unsure about the results becuase I'm probably missing some info:

- I suppose that any system which can recognize a mouse/keyboard is potentially recognizing the gun as a mouse/keyboard too?
- the initial setup (done on a compatible system/windows) is done just once; means the parameters are stored inside the internal micro/teensy?
- the usb connection to the host (PC / console) is for the power (5v) as well as the info exchange (mouse/pointer position/keys pressed/) and to let the host system recognize there's a new device (mouse/keyb) connected? or is there any "driver" that is running inside the host? I suppose this is the main question on whether a PS3 (for instance) may or may not recognize the device being a standard mouse....

At the end, it the above makes any sense, adding a XIM APEX to the PS3 and then this gun will make a KILLER to anything else!

Thank you

Rgds
Matteo

[JayBee]

Hello Everybody and to JayBee of course.
Few months ago (its one year almost) I had in mind to build this fantastic toy and purchased the license. I'm still at the license phase and one day will build my phisycal piece of gun

Recently I was thinking about the use of this gun with a PS3/PS4 console but unsure about the results becuase I'm probably missing some info:

- I suppose that any system which can recognize a mouse/keyboard is potentially recognizing the gun as a mouse/keyboard too?
- the initial setup (done on a compatible system/windows) is done just once; means the parameters are stored inside the internal micro/teensy?
- the usb connection to the host (PC / console) is for the power (5v) as well as the info exchange (mouse/pointer position/keys pressed/) and to let the host system recognize there's a new device (mouse/keyb) connected? or is there any "driver" that is running inside the host? I suppose this is the main question on whether a PS3 (for instance) may or may not recognize the device being a standard mouse....

At the end, it the above makes any sense, adding a XIM APEX to the PS3 and then this gun will make a KILLER to anything else!

Thank you

Rgds
Matteo

To answer your questions:
- technically yes it will be recognized, but the gun aim input isn't a standard mouse input and won't work properly if the OS/software doesn't support that specific kind of input.
- yes stored inside the gun
- I see where you are going here, but it's like I explained on the first point, any system that isn't specifically made to work with hid mouse lightgun input will not work 

PS3 lightgun games don't support generic mouse input (at least not in the lightgun way), and if you are talking about FPS games, lightgun aren't made of FPS and won't work with them.
No matter the machine, mouse aiming and lightgun aiming are too different to work in a playable manner.
It requires a game that is especially made for aiming devices (afaik only the wii and a few PS Move titles ever did that).