Best way to perform precise timing on uart and timer

[mik3ca]

I have a dilemma but I'll explain what I'm trying to do in order to make the problem easier to understand:

I'm making a lazertag system. I have two IO pins controlling a multiplexer so that the correct sensor from the sensors connected to the multiplexer is chosen as the receiving sensor and that is connected to RXD.

The TXD pin is connected to the output lazer.

I made a similar system for the PC in which it emits lazer for transmit and has a sensor for receive so that I can do testing.

Now, what needs to happen is that once the game starts, I want to transmit only 2 bytes then wait until all the other players had a chance to transmit their bytes. So if I were to make a 50-player system and it took 1ms to transmit 2 bytes for the 1st player, then that player should wait 49ms before he can transmit again. I want the timing to be close to exact as possible to minimize waiting time.

I made a similar system to this in the past but the only way I was able to achieve some success was to resort to incorporating a software UART which takes up a lot of variables and code.

I want to avoid software UART.

Now here's the dilemma...

If I give timer the priority for every player's unit, then waiting time for each player can be minimized however the data transmission may be inaccurate, especially if the timer needs to be called right before the second byte needs to be received.

If I give serial the priority for every player's unit, then the timing could be off and some receivers will receive incorrect data due to data overlapping by say a few hundred microseconds.

The speed of the data is 4800bps or 9600bps. I haven't figured out which one to use yet.

So how do I improve timing and be able to always send correct data without two players sending a bit simultaneously and without resorting to creating a software UART?

Also, this micro I'm programming will also interface with another micro as well and that part I don't need to give priority to.

I have provided a poll as ideas for an answer to this, but the checksum option for me is a bit crazy because if two players are constantly firing at a third player then transmissions will happen at the same time and maybe that will invalidate each shot to the third player thereby making the third player invincible until the dual shooting stops.

 

[Pommie]

Switch it around. Have multiple IR LEDs on each player that transmit a code to identify the player and have receivers in the guns. Don't use RS232 as it will get framing errors. Use some kind of Manchester encoding with a suitable preamble.

Mike.

 

[dknguyen]

I don't understand how your system is set up. It almost sounds like you want the hardware for all 50-players to be synchronized in time, and each player is given a slice of time where their equipment actually shoots. The other players determine who is doing the shooting based on what time slot they are hit in?

But timestamping your messages is the way you send timing information when messages might need to be re-transmitted (which would probably have to be determined via a hash check and/or acknowledge), or arrive late, or at inconsistent intervals.

 

[mik3ca]

Switch it around. Have multiple IR LEDs on each player that transmit a code to identify the player and have receivers in the guns.

But that wouldn't make sense. The transmitter is the actual lazer beam.

Don't use RS232 as it will get framing errors. Use some kind of Manchester encoding with a suitable preamble.

Now what.... I'll have to make more special hardware and a special data format? And here I thought I can pull it off with UART even if the speed is worse than dial-up internet.

It almost sounds like you want the hardware for all 50-players to be synchronized in time and interpret shooting and hits decipher who is doing the shooting based on the time slot of when someone is hit?

Pretty much. Each packet of two bytes identifies the player and information to verify that player makes the shot. The synchronization needs to be made to prevent any two players from simultaneously sending data (aka shooting at the same microsecond).

 

[dknguyen]

But that wouldn't make sense. The transmitter is the actual lazer beam.

It is based on the reasoning that a gun can only shoot one target at a time, but a target can be hit by many guns at the same time. Since you can only process one shot at a time, you don't process whether a target has been hit, you process whether the gun has hit something. That means the receiver is on the gun.

It's also good since you always have more targets than guns and it lets you make you targets stupid (blindly just repeating a message) and your guns smart. The downside is you need a wireless radio system so the gun can let the target know they have been hit.

Laser tag system typically use infrared for this since it's invisible (don't want to see targets shooting outwards in all directions on a player's body), and then they stick a visible laser diode on the gun so the human can see the gun shooting. Some systems don't have this visible laser at all since it's not safe and you don't see much of the laser anyways as shooter or victim. Instead they just use haptic feedback on the gun and targets to inform players of hits.

You don't even need lasers for the IR targets (and you don't want them because not eye safe especially since targets shoot in multiple directions all the time). You just need narrow field of view photodiodes on the guns trying to detect regular or wide FOV IR LEDs on the targets (which also lets you "hit" the target at shallow angles).

 

[dknguyen]

Or you could make muzzle loading or bolt action guns. Slower rate of fire = less shots = less overlap. Means you would need guns with fancier mechanics that make the fewer shots more satisfying to shoot. Like cool loading mechanisms for the player to mess around with, speakers for the gun shot and solenoids or motors for recoil when they shoot. Maybe they have to cock a mass on a sprng back each time before they shoot and shooting releases a solenoid to send the mass flying and slamming against the other side of the gun for recoil. Make people aim before they shoot with satisfying shots.

You could probably 3D print a lot of that.

 

[rjenkinsgb]

I used to service laser tag gear for a local company that ran games, a few years ago.

The actual laser in "real" laser tag systems is a gimmick, purely for show & with no real function!
The whole system works on infra-red LEDs and IR sensors.

Those guns have a single high powered infra-red LED and a single IR sensor, each with their own lenses, in chambers above the barrel.
Both the gun and vest have a number of bare, unfocussed IR emitters and sensors scattered about, mixed in with the visible LEDs that flash when a "hit" is detected.

When the trigger is pressed, if a vest or another gun is in line with the focussed system, the two exchange a burst of data to confirm a hit on the victim and increase the hit counter on the gun.

All the electronics are in the gun, which is linked to the vest (by a multi-way curly cable in the ones I worked on).
(Without the vest, only a direct hit on the gun would be detected).

If you find photos of any commercial "laser tag" guns, you will see there is a barrel - which has the effect laser - and a separate cavity above or below that, which has the functional IR optics. Different makes have different arrangements, but they are functionally fairly similar.

There is no overall system sync or timing, everything happens when a trigger is pressed, if a target is in line.

eg. See these guns laid out - and the head-on shot of the same gun below, you can just see light glinting off the lenses in the chambers over the "barrel" in the one aimed at the camera.

Edit - ps. For info, I've just dug out my spare parts box. The Quasar / Q-zar guns as in the photo run on a 68HC705 CPU. I have a full schematic somewhere but that's presumably copyright and it would not be appropriate to publish it.

Edit 2 - picture of the main board for those guns here:
http://www.meno-store.com/images/source/Gun-PCB-6.3b_1_.jpg
The blue-looking LEDS are the IR emitters, the black ones the IR sensors and clear are visible LEDs.

 

[Dr_Doggy]

Don't use RS232 as it will get framing errors. Use some kind of Manchester encoding with a suitable preamble.

Now what.... I'll have to make more special hardware and a special data format? And here I thought I can pull it off with UART even if the speed is worse than dial-up internet.


IR encoding is different than rs232 check it out:
https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol

its as easy as creating a function in the microcontroller

 

[mik3ca]

Thats different.

I experimented in the past with both lazers and IR emitters and sensors, and I find with IR you need more power for more range. When I tested maximum range between an IR emitter and IR receiver with the best possible gain based on fresh batteries, I'd be lucky to get 20 feet at best. With lazer, a larger range can be achieved.

Now the real question is what kind of speed limitations are there in cheap lazers that I ordered from china? (sample image of them shown below)

Ebay listing URL: https://www.ebay.ca/sch/i.html?_from=R40&_sacat=0&_nkw=5mw+laser+module&_blrs=spell_check

Because one time before I was able to transmit data from my PC over serial with these lazer modules at only 300bps to a PT334-6C phototransistor with a 470k pull-up resistor connected to it. but now I want to try to achieve something higher than that.

Now I just thought of another option that might work with my system. A one-bit window for each player as opposed to a 2-byte window, but if I use that option, then I'll have to depend on timing to determine which player made the shot, and communicate with the server to let it know who made the shot and who got shot.

Then again, I wonder if microcontroller clock drift can affect this badly. I mean I use the largest traces possible on my PCB and other functions in the same microcontroller work as expected but I don't rely on time to use them.

Microcontroller in question is an AT89C4051 and the crystal is no more than 5mm away from the microcontroller. I also use 33pF ceramic capacitors to ground the pins of the crystal but the ground leads are a tad bit long because I need to get the routing to go smoothly. Yes my trace widths are 12mils minimum. I think I'll throw in a picture

 

[mik3ca]

Yes my camera is horrible:

But there is less than a 2mm spacing between the edge of the crystal case and the IC holder that the microcontroller is sitting in. To the right of the crystal are two 33pF capacitors but I have the legs that connect to ground exposed.

So If I tried my new idea of using simple 1-bit shots and time to determine the player that made the shot, would throwing a blob of solder on the exposed ground leads (so they connect together with milliohms less resistance between the points where the leads enter the capacitors and common ground) lower the chances of slight clock drift or is 33pF the wrong capacitor value for the 22.1184Mhz crystal? or do I need a different capacitor type here to minimize chances of drift even more?

Then again, I could add delays in my code but if I introduce too much in delay then the game will overall run slower. so I'd rather make the system as accurate as I can on the hardware level.

 

[rjenkinsgb]

Your laser modules are for "5V" rather than being bare diodes with feedback sensors and presumably have current regulators in them that will have capacitors for stability.
They are not really suitable for high speed modulation.

I've done modulation and demodulation with a laser module and PIN photodiode at 25MHz, but that's a bit of a special case.

You cannot rely on multiple independent units staying in time synch, it needs to be a time-independent system.

Were you running the IR over a 40KHz carrier? There are many good amplified sensors designed for that. Also, having the lens system on the TX and RX in the commercial units drastically increases the range, as well as giving a reasonably fine focus so a single player can be targeted rather than it being a "broadcast" type effect.

That's a thought - with a literal laser, it won't work unless it directly hits a receiver sensor.
Unless the vest or whatever is covered with sensors like a pearly king outfit, you have a rather small chance of hits being registered!
... https://spitalfieldslife.com/wp-content/uploads/2010/09/IMG_7612.jpg

 

[dknguyen]

Thats different.

I experimented in the past with both lazers and IR emitters and sensors, and I find with IR you need more power for more range. When I tested maximum range between an IR emitter and IR receiver with the best possible gain based on fresh batteries, I'd be lucky to get 20 feet at best. With lazer, a larger range can be achieved.

Now the real question is what kind of speed limitations are there in cheap lazers that I ordered from china? (sample image of them shown below)

Ebay listing URL: https://www.ebay.ca/sch/i.html?_from=R40&_sacat=0&_nkw=5mw+laser+module&_blrs=spell_check

Because one time before I was able to transmit data from my PC over serial with these lazer modules at only 300bps to a PT334-6C phototransistor with a 470k pull-up resistor connected to it. but now I want to try to achieve something higher than that.

Now I just thought of another option that might work with my system. A one-bit window for each player as opposed to a 2-byte window, but if I use that option, then I'll have to depend on timing to determine which player made the shot, and communicate with the server to let it know who made the shot and who got shot.

Then again, I wonder if microcontroller clock drift can affect this badly. I mean I use the largest traces possible on my PCB and other functions in the same microcontroller work as expected but I don't rely on time to use them.

Microcontroller in question is an AT89C4051 and the crystal is no more than 5mm away from the microcontroller. I also use 33pF ceramic capacitors to ground the pins of the crystal but the ground leads are a tad bit long because I need to get the routing to go smoothly. Yes my trace widths are 12mils minimum. I think I'll throw in a picture

You're ignoring the problem.

I'm going to say what everyone is thinking: cooperative time slicing in an unsynchronized system (even in a system with synchronized clocks but with code that is not deterministic) is a really bad, unreliable way to go about things. The only place I have ever heard of this being done is GPS satellites and even those just blindly transmit a signal that assumes it's synchronized with all the others rather than cooperate.

Visible lasers (any laser really) are also a problem. The emitter solely being in the gun and the receiver being solely in the target. UART is also a problem. We've pointed all these out and you've acknowledged none of them.

You say range is a problem. But (I assume) you weren't testing with narrow FOV photodiodes and I know you weren't you using proper amplifiers. In fact you seemed to refuse to even try said amplifiers because you did not want to make another PCB. If you were using pre-packaged IR transmitters/receivers then 20ft probably would be the limit since they were probably made for TV remotes and other applications where longer range wasn't needed and needing to aim directly at the receiver is a bad thing.

I don't know if you've noticed, but almost all your threads boil down to band-aid solutions for fundamental/foreseeable issues in projects that try do things in roundabout or ackward ways. That's not really an issue in itself at the beginning of a project, but all your projects seem to be far into development by the time you ask these questions. I do not remember a time where you did not already have a PCB made and I do not remember a time when you were willing to correct that PCB. Do you not research or plan things out before you start?

 

[rjenkinsgb]

GPS satellites and even those just blindly transmit a signal that assumes it's synchronized with all the others rather than cooperate.

But they do each have FOUR! atomic clocks, accurate to one second in 32,000 years...

Even decent communications radios use "crystal oven" [OCXO] stabilisers when frequency accuracy is critical, for narrow channel use etc. as a bare crystal will drift; that's just the way things are. Some use a housing around a conventional crystal, or you can get all-in-one devices.
Examples:
http://g3ynh.info/valves/var/crystals/oven.html

http://uk.farnell.com/abracon/aocjy...7-x-7-5mm-lvcmos/dp/2467699?MER=mktClearanceA


This is a laser module suitable for moderate speed modulation, up to a few KHz.
Note that due to the power all players would have to wear suitable protective glasses and you could be legally liable for any eye damage caused; a 1mW type would be preferred but still dubious power-wise.
http://thepihut.com/products/adafruit-ttl-laser-diode-5mw-650nm-red-50khz-max


Edit; a quick bit of research on IR device ranges..
This pair of devices are specified to have a typical operating range of 35 metres, without any extra optics:
http://www.mikroklub.hu/htm/pdf/tsip520_.pdf
http://www.voti.nl/docs/TSOP17.pdf

They are not exactly expensive, either: **broken link removed**

 

[mik3ca]

Do you not research or plan things out before you start?

Perhaps I get better if google smartens up, because somewhere I read online, search engines behave like 6 year olds at best. Heck, a couple of times I searched for an electronic circuit and the first few matches were about automobiles.

Your laser modules are for "5V" rather than being bare diodes with feedback sensors and presumably have current regulators in them that will have capacitors for stability.
They are not really suitable for high speed modulation.

See this is the thing. There is nothing on the internet that points out to me the capacitance value in such modules in which I could potentially adjust my circuit to meet its needs and achieve OK speed but now that I think about it, yes I'll ditch the UART idea since theres too many bits for the lazer to handle. I also have the radio module available to me as well so somehow I really think time synchronization is in order in the system because without it then there will be data collisions right?

The only place I have ever heard of this being done is GPS satellites and even those just blindly transmit a signal that assumes it's synchronized with all the others rather than cooperate.

The cooperation comes by validating data over the network. For example:

1. Player sends to network that he is making the shot.
2. Network tells player its ok to make a shot.
3. Player's lazer fires
4. Target gets hit and sends player name to network based on time shot was received.
5. Network validates sent data from player and the target to see if they match

 

[dknguyen]

I consider bouncing ideas off other people as a form of research. You can do that.

What kind of radio modules do you have? Point to point? Or networked (i.e. mesh?). Spread spectrum radios (like 2.4GHz) don't time sync. They channel hop and use orthogonal channel coding and fancy math so they can separate each other out. If it gets noisy or collisions happen, they move to another channel and/or re-transmit. That's why you timestamping is important.

But time stamping won't help you receive two messages at the same time if those messages will never be repeated (simultaneous shots on the same target).

 

[rjenkinsgb]

There is nothing on the internet that points out to me the capacitance value in such modules

You research how they are made and what the internal electronics are.
A laser diode, which is similar in some ways to a LED, in a case that also has a photodiode for feedback and stabilising, plus some form of regulation circuit to allow it to work on 5V.

Searching "Laser diode module internal schematic" rapidly took me to this site, which has masses of info and example diagrams of small laser modules & pointers etc.
**broken link removed**

1. Player sends to network that he is making the shot.
2. Network tells player its ok to make a shot.

So then you have to handle radio network data formatting where each burst needs a run-in and error detection codes, collision detection & re-sending any lost data, all with delays involved.

Also, you have not mentioned how a tiny laser beam dot is going to guarantee a hit is registered anywhere within a fairly large body area.

 

[mik3ca]

going to guarantee a hit is registered anywhere within a fairly large body area.

I did make 12 points of reception for each large body plate and I plan to buy some special glass that would help scatter the lazer beam so more light can enter the electronics. I can make my points of reception very sensitive. Even a normal LED light can make the sensor go off.

What kind of radio modules do you have? Point to point? Or networked (i.e. mesh?).

The model is HM-TRP UART radio module because its simple to use. I did transmit data on it between my unit and the computer at 38400bps but at a distance of 10 feet but I didn't test further though the maual to the module claims I can transmit as far a 1km but I wont need that range.

 

[rjenkinsgb]

lazer beam

ps. And note that it is LASER - Light Amplification through Stimulated Emission of Radiation.

If you have been searching for "lazer" that's going to be one of the reasons you do not find much valid info.

 

[dknguyen]

I did make 12 points of reception for each large body plate and I plan to buy some special glass that would help scatter the lazer beam so more light can enter the electronics. I can make my points of reception very sensitive. Even a normal LED light can make the sensor go off.



The model is HM-TRP UART radio module because its simple to use. I did transmit data on it between my unit and the computer at 38400bps but at a distance of 10 feet but I didn't test further though the maual to the module claims I can transmit as far a 1km but I wont need that range.

That is just a regular narrowband radio so it doesn't have the spread spectrum stuff I was talking about. There is nothing there to alleviate collisions.

 

[rjenkinsgb]

In the radio-linked gear we've made, one type was single direction (no handshake) so what I came up with was a kind of exponential decay repeat with several repeats (6 to 8, I can't remember now) with the delay between repeats doubling each time, plus a small randomised delay added to each so two transmissions that started at the same instant did not conflict at every repeat.

As far as I remember each unit was using bursts of nine bytes at 38.4 Kbaud; two run-in, one sync, then a control, address and data byte each sent true and inverse - that gave both DC correction and error checking.

That was a project about 20 years ago for a special education company and it worked flawlessly in a classroom with thirty kids pushing buttons or activating radio-linked toys, all on the same frequency.

The repeats ensure data has a very high probability of getting through, but of course any timing element is lost - each sequence lasted over a second and there was no way of knowing if the first burst would be received or the last.

It does not matter with a remote controlled power switch or a kid throwing a fluffy dice a foot across & waiting for the receiver to speak the number it landed on (some of the things we built the radio link boards for), but definitely not good in a system that needs instant acknowledgement or critical timing.