Universal wireless controller for SNES, Saturn, N64, etc....

[kendrick]

Welcome to GamesX, Abduct. You want to read this portion of the current thread:

http://nfggames.com/forum2/index.php?topic=4393.msg30973#msg30973

The idea of a wireless power activation switch was previously discussed, and at the moment the equipment that has been built does not accommodate the capability as far as I know.

[abduct]

Welcome to GamesX, Abduct. You want to read this portion of the current thread:

http://nfggames.com/forum2/index.php?topic=4393.msg30973#msg30973

The idea of a wireless power activation switch was previously discussed, and at the moment the equipment that has been built does not accommodate the capability as far as I know.

Hi and thanks for the link I've read the posts concerning it and I agree with some points and others I do not. I don't have the wireless transceivers so I can't test this, but I would imagine that you can do something like this.

1) wire player1 transceiver to constant dc current before the switch
2) replace the 8pst switch (or what ever it was) with a matching relay set
3) wire in a transistor from the constant current to the relays to power then, and wire the gate opening side of the transistor to voltage output of the wireless transceiver.

In theory, the transceiver will be always on with constant power, which means when the controller is turned off, it will enter a low power state so the datasheet says. When a controller syncs to the transceiver it enters a higher power state. If tapping into this high and low power states you could potentially trigger a transistor to open open the relays to turn the console on. And since the transistor closes with a low power state of the transceiver (closing the relays as well), and the transceiver itself in low power mode, you will be drawing minimal power.

The only downside I see is if the code for the mcu's do not have a keep alive packet, and the controllers are in an idle state (paused game and not playing for a while) the transceivers may go into low power mode causing undesirable power loss to the console. Another option is to keep the same setup (transistors, relays and constant power to the transceiver), but modify the controller to include a spst switch to send an awake packet to the console whos transceiver would be awake because your controller would be connected. I would believe it would be as simple as rewriting the application a bit, and setting one of the controllers mcu's GPIO pins to input mode and use the spst switch to set the high/low state of the GPIO pin to send the packet and then setting one of the consoles mcu GPIO pins to a high/low state to trigger the transistor. Another option would to use a keypress combo to send the packet eliminating the need for the spst switch.

Anyways that is my thinking for this, hopefully micro will reply and release the source code to his project so I can take a deeper look at it. I did some looking around and one person used a simple receiver and remote with a single button to power on/off his console with pretty much the same method (minus these 2.4ghz transceivers, he used some all in one package for a car alarm or something).

[micro]

Well I guess it's possible. But it seems to me you got a few things wrong:

Where does the datasheet say it goes into low-power mode after a certain time? The transceiver inside the receiver (or inside your console) is in RX mode and it will stay in that mode all the time.
The controllers don't send a keep alive packet and they also don't send a special package when they're turned off. (You just flip the switch and cut power to the whole circuit inside the controller)

Also I'm not sure if I got this right:
You want to use the internal digital supply output pin (DVDD) of the NRL24L01+ to switch the relay? I don't think the purpose of the pin is to switch external stuff
I think the best way would be to change the program of the MCU inside the receiver. Watch for a special button combination to toggle the state of an output pin. And with that pin you could close or open the relays.

Regarding the source code:
I haven't released the source code yet and I'm not sure if I will. It's pretty messy. Comments are in german and english. Also the RF protocol I used in this version is pretty stupid and not that stable at all. And most of all: It's asm and not c.

Would you really want to dig into the old fugly code? I certainly wouldn't, for the next version of the wireless mod I've started from scratch...

[abduct]

Where does the datasheet say it goes into low-power mode after a certain time? The transceiver inside the receiver (or inside your console) is in RX mode and it will stay in that mode all the time.

I could of swore I found it in the data sheet but after quickly skimming through it, I can't find it. The only things I found are near the beginning mention a "power down mode (900nA)" and two different standby modes (22uA and 320uA). I would need to reread the documentation again more thoroughly. It sounds like you can force the module into a low power standby state after certain conditions are met.

You want to use the internal digital supply output pin (DVDD) of the NRL24L01+ to switch the relay? I don't think the purpose of the pin is to switch external stuff
I think the best way would be to change the program of the MCU inside the receiver. Watch for a special button combination to toggle the state of an output pin. And with that pin you could close or open the relays.

Yea the thing about using the power down voltage and high voltage of the receiver was a silly idea, but I later mentioned using the MCU and GPIO pins to switch the transistor/relays. Which would be better overall. Along with watching for specific button combinations to send the start/power off commands.

Regarding the source code:
I haven't released the source code yet and I'm not sure if I will. It's pretty messy. Comments are in german and english. Also the RF protocol I used in this version is pretty stupid and not that stable at all. And most of all: It's asm and not c.

That's fine by me. I don't mind rewriting from your base if it is needed. I am also pretty proficient in assembler/c/ruby (and other unrelated languages), so it shouldn't be that much of a problem. Also I don't mind if it's messy, you should see some of my thrown together projects lol. But it's up to you if you do not want to release the source I'll respect your decision, but having a base to work from or modify would be more helpful to me than starting from scratch. Also if I did obtain the source code if you wished, any stable modifications I made could be posted to this thread, or to a new thread for others to use (either source code or compiled flashable files.)


Thank you for replying to me.

[micro]

The 900 nA low power mode can only be selected by disabling the NRF24L01+. You have to clear the power-up bit of the configuration register. But it really works


I've uploaded a new version of wireless mod containing the source files (see first post). I hope it will help you to achieve your power-switching feature 
Hopefully I've also fixed the issue with some PAL SNES systems (missing pull-up resistor on P/S).

[abduct]

The 900 nA low power mode can only be selected by disabling the NRF24L01+. You have to clear the power-up bit of the configuration register. But it really works


I've uploaded a new version of wireless mod containing the source files (see first post). I hope it will help you to achieve your power-switching feature 
Hopefully I've also fixed the issue with some PAL SNES systems (missing pull-up resistor on P/S).

Thank you very much!!!!

I'll be taking a look at them after I get back from my trip. I've been jotting down notes on a scrap paper for this project for a while and I've figured out some efficient ways for this to work better and some problems with my previous assumptions in this post.

Thanks again!

edit:: just read through the n64TX assembly. German comments translate fairly well to English and the code (after looking up some instructions on the atmel website) reads very smoothly. Few spots could be rewritten and optimized, but overall I was pleasantly surprised. I guess it pays off having a few years of x86 assembler knowledge though, I wouldn't expect any newbie to understand this. Even noticed that when translating the n64 buttons you translated them into a cross compatible scheme that works with other controllers (n64_1 -> buttons1, n64_2 -> buttons2). When I get around to rewriting this myself I'll make a thread and release it.

One thing I am confused about is the purpose of removing pin 30 of the controllers micro controller. What does this change/prevent/accomplish?

[micro]

IIRC then the idea was to place the whole wireless circuit into the rumble pak. I think I used pin 18 of the memory card connector for the controller data line. And pin 18 of the memory card connects to pin 30 of the Nintendo IC on the controller PCB. So I suggested to cut/break off pin 30

[ours1011]

I've uploaded a new version of wireless mod containing the source files (see first post). I hope it will help you to achieve your power-switching feature 
Hopefully I've also fixed the issue with some PAL SNES systems (missing pull-up resistor on P/S).

Hi there !

Can this maybe solve my problem ? (reply #200) ?

My bad, I still haven't ordered spares to check what went wrong, i've been busy with an another project

[micro]

Maybe it actually does. But I can't tell for sure if I don't get feedback...

And c'mon, you don't need to make an extra parts order to try out a pull-up resistor. Just add a 10k (or 20k or 5k..) resistor between +5V and P/S and see if it works...

[abduct]

IIRC then the idea was to place the whole wireless circuit into the rumble pak. I think I used pin 18 of the memory card connector for the controller data line. And pin 18 of the memory card connects to pin 30 of the Nintendo IC on the controller PCB. So I suggested to cut/break off pin 30

Ah, makes perfect sense. You didn't want to feed the data line back into the IC so you cut pin 30 and since you were not going to be using the expansion port you didn't need that pin.

I just got back from my trip, but my parts haven't came in yet so this project is on hold for now. I may re-comment the entire source and reorganize it into more manageable modules so code isn't all over the place while I wait. It shouldn't take long seeing how these are fairly small applications.

What assembler are you using/did you use for this project? I am using atmel studio 6.1 and I got a fair bit of duplicate macro errors for the radio related macros (set_ss, reset_ss, set_ce, reset_ce) (duplicate macros located in nrf24l01.inc and n64_tx2.asm). After commenting out the duplicate macros though it compiles fine so it isn't that huge of a problem.

[mdn15]

Hi All!

I have been trying to get this to work with my SNES for a while and still no luck.  I have rebuilt the circuit multiple times (with a slight variant of the 3.3V regulator). 

When I plug the SNES_RX into the SNES, I see random wavy bars on the screen, when I unplug it from the SNES, the SNES boots.  I have checked the wiring on both the Transmitter and Receiver and the wiring seems to be ok.  I have just reflashed the firmware and I have tried new MCU's. 

Can anyone help me determine what is going on?  I can post pictures if needed.

Regards

[mdn15]

I managed to fix the wavy line issue by replacing the atmega8.  However.. the TX/RX still does not work.  I tried a 10K pullup on the strobe pin on the Rx but still no luck.  The firmware I have flashed is the SNES_RX3.hex on the atmega8 with the low fuse set to 0xd4 and the high fuse set to 0xdf.  The transmitter (attiny 2313) has the SNES_TX2.hex with the low fuse set to 0x64 and the high fuse set to 0xdb.  Both circuits are on breadboards and can easily be manipulated.

Any help would be greatly appreciated.

[micro]

@abduct: At that time I've been using AVR Studio 4. I wanted to include the whole project files but some of them included folder paths of my PC (which I don't want to publish).  So instead I've just included the .asm files + one .inc file.
It seems you're right. Some of the .asm files already include the macros that are defined in the .inc. But it's no big deal to delete all the duplicates just as you did... 

@mdn15: Yes, you can make some good & sharp pictures of your circuit(s). There are infinite reasons why it doesn't work. Have you set the right channel on both devices? It's also possible that one (or both) transceiver modules are broken. They tend to die very fast & easily if you apply the wrong voltage (5V instead ov 1.9 - 3.6V).

It's possible to check if the receiving transceiver is actually receiving data. If you measure the voltage on IRQ line you should see about 5V. Now if you press some buttons on the wireless controller then you should see a clear decrease of voltage on the IRQ line.

[mdn15]

@micro - Thanks for the help.  I will see if my camera can take sharp pictures to send this to you.  I do have some spare transceivers that I can try.  I will also check the voltage on the VCC pin on the transceivers (Should be 3.3).  I also have a logic16 that I can hook up to the SPI pins and the IRQ pins to see what is going on (but I'm not too sure what I can make of it).  What is the correct method to set the 'right channel' (or matching channels) on the transceivers?

Thanks

[SnoopKatt]

I'm building a second NES controller (with hopefully better craftsmanship), and this time I wanted to include the charging circuit in the controller so I just need a USB cable. I found this: http://www.fasttech.com/product/1453504-tp4056-1a-li-ion-battery-charging-module
and I like it since it has a really small footprint (and it's super cheap!). However, before trying it out, I have a couple questions:
1. I noticed that you set the charger to charge at 4.1V. This is fixed at 4.2V; that should still work, right?
2. The website claims it can be programmed to charge with 100mA, but on the datasheet, I only see 130mA. Is 130mA still safe?
Thanks!

[mdn15]

@micro Thanks again for your help!

Alright. So I was able to snap some pics of the breadboards.  I have not been able to take the Logic 16 to them or verify the voltage on IRQ or the transceiver.

Each board has wiring for a Sparkfun isp breakout board (breakout board not shown in pics)

I removed the transceiver from its breakout board, but orientation is that the ground pin (pin 1) is on the top left of the breakout.  This would orient the transceiver with the antenna pointing to the right.

The Console and the Controller are connected via a split SNES extension cable.  The pinout is the same as the SNES port.

Please let me know if there are any questions about how I have this wired. (Sorry for all of the Red wires).
On the RX.. The pin connected to the channel select was left floating

The pics were too big.. so..

SNES_RX_1 - http://imgur.com/a/NWK6Z#0
SNES_RX_2 - http://imgur.com/a/NWK6Z#1
SNES_TX_1 - http://imgur.com/a/NWK6Z#2
SNES_TX_2 - http://imgur.com/a/NWK6Z#3

Dropbox Archive - https://dl.dropboxusercontent.com/u/9832887/snes_wireless_bb_pics.zip

[micro]

Thanks, these are some good and sharp pictures indeed! 

Your RX circuit looks good although I don't know what kind of voltage regulator you've used.

But on your TX circuit it seems you've switched NRF's MISO and MOSI
Let's hope it'll work if you switch both wires... 

I remember that someone else also switched these two wires. The problem might be that the MISO wire connects to pin 17 (MOSI) and the MOSI wire connects to pin 18 (MISO).
The pin descriptions in brackets only apply when you're programming the MCU with the ISP adapter. If you want the Attiny2313 to be a SPI master and to communicate with other devices over SPI (just like NRF24L01+), then you got to use different pins.... (Read the datasheet if you really want to know).

[mdn15]

Thanks for the quick response!
The Vreg used on the RX circuit is the LD1117V33 (Datasheet: https://www.sparkfun.com/datasheets/Components/LD1117V33.pdf) Purchased at sparkfun.  I have used these in the past and they put out a nice 3.3V rail.

Flipping the MISO and MOSI as you point out is most likely the problem.  I connected it as a standard SPI bu.  I will try flipping these when I get home this evening. 

How do I select the channel the the TX circuit should use?
Also, How did you program the RX circuit.  I attempted to do this myself (prior to finding the project) and I could not get the timing correct (using interrupts).  I used C to write my program.  Did you use some assembly?  (Just curious)

Thanks again!

[micro]

The problem is that the Attiny2313 doesn't have a full hardware SPI module. Instead you got to use the DI (data in) and DO (data out) pins which also happen to be the MOSI and MOSI pins. An that's the reason why it's so confusing: Same names but the function is flipped.

Setting the channel on the wireless controller is done by turning on the controller while holding either A or B button.

Just as I announced a few posts ago, the source files are now included. In this version I've used assembly language exclusively. But in the new version of my mod which I'm currently working on, I'm also using C. It can be done in C with the MCU running at 16 MHz. Have a look at the .asm files, that's also how I've done it in C. I tried to mimick the behaviour of the 4021 IC inside the SNES controller. It's really not that hard, just two ISR's for each Clock and Latch interrupt


@SnoopKatt: 4.2 V should be ok. But since most mobile phone and Ipod batteries don't come with a data sheet you can't tell for sure what the rated charging voltage is.
Charging the Ipod shuffle battery with 130 mA also shouldn't be a problem for the battery itself. But you can only draw up to 100 mA from a PC's USB socket without further communication with the USB host. I think it's possible to set the charging current to 100 mA on your charging IC. Unfortunately I haven't found a decent and comprehensive data sheet for your charging IC yet...

[SnoopKatt]

The data sheet is pretty barren :/
If it was plugged into a cell phone or tablet charger, it could pull the full 1A though, right?
It looks like most of the boards are pre configured for 1A output, so I guess changing that resistor to 12K would do it? It sucks that it's an SMD resistor haha.
I ordered a couple of them, not too much to lose if they don't work out.

[micro]

I'm afraid 1 A is way too high... It's a rule of thumb that Li-Ion batteries can be (safely) charged at 1 C.
(See also:
http://en.wikipedia.org/wiki/Lithium_polymer_battery
https://sites.google.com/site/tjinguytech/charging-how-tos/the-variable-c)

So for that tiny Ipod Shuffle battery with its capacity of 250 mAh I wouldn't use a charging current higher than 250 mA.

[SnoopKatt]

Gotcha...good thing that a different charging current can be used by just changing the resistor on the board.

[micro]

This is the data sheet that I've found: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Prototyping/TP4056.pdf

On page 2 under "Prog (Pin 2)" they explain how the charging current is set. For some reason they keep writing "ISET pin" instead of "Prog pin". Very poor...
Anyways, the formula to calculate the resistor's value is:  R_PROG = 1200 V / I_CHARGE

So if you want to have a charging current of 100 mA you need a 12 kOhm resistor. (1200 V / 100 mA = 12 kOhm). It shouldn't be hard to desolder the old SMD resistor. Just add enough solder to your tip and heat both terminals at the same time until it goes off

[SnoopKatt]

Gotcha, thanks! Looking at the board, they put a 1.2k resistor in that spot, so the 1A charging current makes sense. I'll switch it with that 12k resistor. I'll let you know when they arrive.

[mdn15]

Flipping MISO and MOSI on the TX side fixed my issue and I how have a working (bread boarded) SNES Wireless controller!

Thanks micro!

I will be taking a look at the source code (for fun) as well as creating a final version for myself (with the latest fw).  Thanks again!

[Palya]

Thank you for such a wonderful information, I apologize for the clumsy language, I use a translator because I'm from Ukraine ...
All acted according to your diagrams, and everything works just amazing:







Wanted to ask you, if you have a similar scheme on SEGA Dreamcast, Megadrive 2, Panasonic 3DO?

Once again, THANK YOU!

[public-pervert]

Nice boards! Congrats on this one 

[micro]

Yes, that's a nice PCB, good job! 

I won't add support for other systems to this "old" code. (But the source files are available)

[SnoopKatt]

That's super clean, awesome job! It seriously looks like Nintendo could've made it.Is the power button where the cord was?

[Palya]

That's super clean, awesome job! It seriously looks like Nintendo could've made it.Is the power button where the cord was?

Yes, where there was a cord, there is a power button, just did not make a separate charger for each joystick controller integrated and charge through the mini USB, USB from any source. Just red charge indicator right on the joystick.

It is a pity that there is no other under the console, I want to make wireless joysticks for all consoles that I found in the collection.

[Palya]

That's super clean, awesome job! It seriously looks like Nintendo could've made it.Is the power button where the cord was?

Yes, where there was a cord, there is a power button, just did not make a separate charger for each joystick controller integrated and charge through the mini USB, USB from any source. Just red charge indicator right on the joystick.

It is a pity that there is no other under the console, I want to make wireless joysticks for all consoles that I found in the collection.

Another couple of pictures)))

[eitnot]

Anyone have a problem with range of their controllers?  I built 2 SNES receivers and controllers.  I also built 2 NES controllers.  If my receiver is 10 feet away I'll intermittently have problems where it will stop responding for a second.  For example while playing Kung Fu for NES all of a sudden I won't be able to Kick or Punch and my character will just keep walking.  Then after a second or two control comes back.  Tried with both receivers and different controllers and it did not make a difference.  So then I moved the receiver closer so that it was only 5 ft away and the problem went away.  Controllers are fully charged.

[abduct]

Anyone have a problem with range of their controllers?  I built 2 SNES receivers and controllers.  I also built 2 NES controllers.  If my receiver is 10 feet away I'll intermittently have problems where it will stop responding for a second.  For example while playing Kung Fu for NES all of a sudden I won't be able to Kick or Punch and my character will just keep walking.  Then after a second or two control comes back.  Tried with both receivers and different controllers and it did not make a difference.  So then I moved the receiver closer so that it was only 5 ft away and the problem went away.  Controllers are fully charged.

Not sure if it is the problem, but I've read people having corrupted packets/packet loss if their transceiver is to close to the MCU. I haven't experienced this so I can't say if the statement is legitimate. Although 10 feet is a bit short of a distance for packet loss problems to be occurring. People have gotten more than 10+ meters (32ft) before packet loss happens for line of site transmissions. Not sure if it will help but try to test the controller with the transceiver antenna out of the case facing the receiver unit.

[Grambo]

Anyone have a problem with range of their controllers?  I built 2 SNES receivers and controllers.  I also built 2 NES controllers.  If my receiver is 10 feet away I'll intermittently have problems where it will stop responding for a second.  For example while playing Kung Fu for NES all of a sudden I won't be able to Kick or Punch and my character will just keep walking.  Then after a second or two control comes back.  Tried with both receivers and different controllers and it did not make a difference.  So then I moved the receiver closer so that it was only 5 ft away and the problem went away.  Controllers are fully charged.

Yeah, the range is not fantastic. I certainly experienced the issue too and it very well may have to do with packet loss, as abduct says. No problems with micro's new full v2 PCB solution though; the range is fantastic.

[eitnot]

Abduct: I'll try to test this out tonight when I get home.  I attached a picture of my receiver so you can see how I laid it out.

Grambo: Is v2 PCB already out and I missed it?

[abduct]

Abduct: I'll try to test this out tonight when I get home.  I attached a picture of my receiver so you can see how I laid it out.

Grambo: Is v2 PCB already out and I missed it?

No v2 PCB isn't out and may not be for a while. There is a development thread though. If I recall correctly Micro is currently doing more developing on the snes version as well as has a saturn version in the works. No schematics or other information has been released because this PCB is more complicated and can't really be easily replicated at home. He sold a few but at the moment I believe he does not have any to sell.

You can find his work log (sorta) here:

http://nfggames.com/forum2/index.php?topic=5180.0

I am also currently working on a revamped version micros v1.2 release. I wont release any specs or details until I at least have a working breadboard version to show (waiting for some IC's and new breadboards to come in). I will most likely release the schematics and bill of materials like Micro did, but I wont sell these unless micro okays it. After all it was his project/idea in the first place.

[eitnot]

Got a chance to mess around a little tonight and it does seem that if I crack open the case of the receiver so that the antenna is facing me that the controls are more reliable.

[abduct]

Got a chance to mess around a little tonight and it does seem that if I crack open the case of the receiver so that the antenna is facing me that the controls are more reliable.

Does distance effect it at all? I think you are just suffering from packet loss causing the controls to seem to stick. Although depending on the controller your using, normally a packet lost here or there wouldn't make the controls stick for 1-2 seconds. In example the n64 controller is polled every 60hz (16ms iirc) for button statuses. This would be about 62 status updates sent to the receiver per second. So unless you are getting massive packet loss I am not sure what might be happening.

Maybe I am wrong and someone else could give some insight.

[eitnot]

The 1-2 seconds is a bit of an exaggeration on my part.  Usually it is very short hiccup where it just misses a button press or a couple quick presses in a row.  The time of unresponsiveness is probably under a quarter second but when you're getting beat up it feels longer.

If I move the receiver so that it is 1.5 meters away I don't have any problem.  If it is 3 meters away then I start having problems but it is pretty intermittent.  Sometimes I can play a whole level and it will only happen a couple times.

Side note I look forward to hearing more about your revamped version.

[sazyario]

How is version 2 coming of this project?