SpritesMind.Net

I recently bought SEGA IR joypads.

The base: MODEL No. MK-1648
Chipset: SEGA 315-5714 (codes 9338EP713 069 )




The joypads: MODEL No. MK-1629
Chipset: SEGA 315-5713 (codes: 149 338102)





Should I research it?

(oops, didn't see you post before today)

Got exactly the same at home.

What I wanted to trace/understand is how they handled latency ....
Have you any idea how they deal with it ?

Sure. The joypad sends its own state every X time. Always when any button is pressed. The base reads the joypad state and convert it to state of internal joypad, that physically connected to the console. If no state was recieved by IR after X time (plus some time) the internal joypad state force to unpress for all buttons.

The idea is time X must be approximally twice faster than time of polling joypads by console (Y time). Then the lag of input were only 1/2 of Y and player didn't notice it (in fact, X is async to Y and lag mostly will be less than 1/2Y). You may choose X = 1/3Y, but you should remember that IR pad works on batteries and should save them. So some kind of compromise must be choosen (state send speed vs power consumption). This is base knowledge.

More challenge were be when you try to use 2 IR devices (and of course outside interference with remote controls for example). Collisions will happens every time. So, you must to protect your IR packet with some kind checksum (or to monitor the correct timings, depending on the choosen IR protocol) and base must know valid data or not. Then you must set X time for IR joypad 1 and IR joypad 2 slightly different plus they must send own state twice with different delay time between each state packet. So, you will be sure that although one state package will recieved correctly for all IR joypads within time of X.

That what was I saw in these chinese IR joypads that I bought more than year ago without reciever.


In fact they use the same PCB with same IC (some kind black blob) and P1/P2 jumper on it.

I didn't research original Sega IR joypads yet. And don't know that can both P1 and P2 joypads works together at same time or not.

i suspected the first part but the second part, about 2 IR devices, is totally new to me.
Thanks for all these details, very interesting.

I get back to this subject month ago when I was studying if a wireless control was possible on MD.
I was wondering which tech would be the best.
good ol' IR ? bluetooth ? wifi (with the very cheap IC now available everywhere) ? something else ?
(yes, it's a follow up of this project I started on viewtopic.php?f=13&t=1656)

How would you compare IR (and all the collision problem you talked about before) to something else ?
Top points are, of course, lags, power consumption, multi player, signal collision

The IR problem is in unidirectional. So, all emitting devices doesn't to know about each other. If they can be bidirectional, they can be in passive mode and answer only when base unit ask any single device wich will have unique address (callsign). All arbitrage done by base unit and no colisions with other devices. The base unit can even re-ask last state.

Bidirectional media can be not only optical, but radio (bluetooth or ASK/FSK on citizen frequencies). But it is not guarantee of stability: f.e. TmEE said that bluetooth joypads of nextgen consoles bad works in his area with very overloaded ether. So, IR optical is the best, I think.

You may offer "listen before talk" tactics for unidirectional IR, like it does on omnidirectional radio or coaxial ether, but IR is directed and joypad IR reciever must be pointed to other joypad(s) transmitter(s). That is impossible, you know. So only special technics can be used here.

As for element base for build custom IR joypad - yes, nowadays offer rich options for that. Any low power microcontroller can handle all alone. Any custom protocol. PCB can be made with best quality in standard joypad. Etc.

The big problem with infrarred is that if something is covering up the sensor (much easier to do in accident than it sounds) then it just won't work.

And yeah, Bluetooth is crap in general.

Also found this unofficial one.

I was suprised by the rate of sync needed so I check the Menacer one, which should refresh at almost HSync rate.
From Eke doc :

The IR sync pulse is controlled by a RST signal, which in fact have two possible lengths:
· 2 or 3 microseconds: this is the "counter reset" signal, used to reset the above pulse
counter. This is sent after receiving button data, at the end of VBLANK.
· 10 microseconds: this is the "main reset" signal, used to issue the IR sync pulse
described above and start buttons data acquisition. This is sent at the beginning of
VBLANK.
The RST signal is controlled by software using TH and TR pins (bit5 & bit4 of DATA
register)

About Bluetooh, yeah...I know..but it's also the only solution if you want to talk with a smartphone.

I was more looking to RF but, well...we'll see later


And, on a last one, it was fun to learn about this just some days later after reading this thread

KanedaFr wrote: ↑

Sun Sep 03, 2017 11:08 am

About Bluetooh, yeah...I know..but it's also the only solution if you want to talk with a smartphone.

The problem is that Bluetooth is a horrible mess of different technologies and a lot of stuff has awful stacks which means that having things stay connected is extremely hit and miss. Especially with anything that's not a computer (as hardware vendors of peripherals usually don't give a fuck about the software). I guess if you can control both endpoints you'll have much better luck (which is indeed the case here), then you only need to ensure those two can talk to each other and nothing else.

I don't see the issues with Bluetooth getting fixed any time soon sadly. The current trend is to just do everything over wi-fi ._.