• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Best way to perform precise timing on uart and timer

What should I do?

  • Give only the timer Interrupt the priority

    Votes: 0 0.0%
  • Poll the Serial line

    Votes: 0 0.0%
  • Poll the Timer

    Votes: 0 0.0%
  • Let transmission happen anytime but transmit long data with checksums

    Votes: 0 0.0%
  • Just transmit a special stream of data on the serial line to use as timing

    Votes: 0 0.0%
  • Configure the serial port to use a special mode

    Votes: 0 0.0%
  • Configure the serial speed at a special rate based on some special math

    Votes: 0 0.0%

  • Total voters
    1

rjenkinsgb

Well-Known Member
Most Helpful Member
I've just been looking at the data for that HM-TRP radio module.

Ignore any claims of "worldwide legality" legality in that, I don't think the frequency and power combinations they say are allowed are actually legal anywhere in the world...

eg. If you are in the USA, the legal transmit power is limited to something like 100 microwatts on anything other than the 915 Mhz band & on that it's approximately one milliwatt into a quarter wave antenna.
The limits are based on radiate power so a combination of transmitter power and antenna gain (or loss).

Transmit too high a level and interfere with any other gear that shares the band and you will have the FCC on your back...

The UK is a bit more relaxed with 433.92 MHz etc., but there are still strict power limits and transmissions must be short burst only.

Yet another thing you need to study _very_ carefully before implementing anything.

Edit - that should have read "radiated power".
 
Last edited:

Nigel Goodwin

Super Moderator
Most Helpful Member
Yet another thing you need to study _very_ carefully before implementing anything.
I wouldn't have thought it's any problem?, his entire project looks to be doomed to failure - he's going about in completely the wrong way and won't take advice from anyone.

You in particular have explained exactly how such systems work, and why it's done that way - but he seems determined to try and make it far more expensive, and non-working.
 

rjenkinsgb

Well-Known Member
Most Helpful Member
To paraphrase the "6 Ps" saying:
Proper Prototyping Prevents P!ss Poor Performance.

(And realising when you are pursuing something in to a dead end & trying a different way before you get there, prevents you bashing your brains out by running in to a brick wall..)
 

Dr_Doggy

Well-Known Member
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


how many back packs do you got?? no need for such complexity , why not something like:
1) Shooter sends 8bit id(for 256 different packs), and 8inverse bits for error checking,
2)Receiver pack gets hit, flashes ... sends a RF string with Sender id &Receiver id to scoreboard PC
3)scoreboard PC takes care of scores, names, and teams

have you seen the zigbee chips? they would be very helpful handling the networks needs , and you can set up different PANs so you could have 2 games going at once, they take care of all the hopping and network protocols for you . they also have this neat feature where radio modules can act as repeaters for other modules that are further away
 

dknguyen

Well-Known Member
Most Helpful Member
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


how many back packs do you got?? no need for such complexity , why not something like:
1) Shooter sends 8bit id(for 256 different packs), and 8inverse bits for error checking,
2)Receiver pack gets hit, flashes ... sends a RF string with Sender id &Receiver id to scoreboard PC
3)scoreboard PC takes care of scores, names, and teams

have you seen the zigbee chips? they would be very helpful handling the networks needs , and you can set up different PANs so you could have 2 games going at once, they take care of all the hopping and network protocols for you . they also have this neat feature where radio modules can act as repeaters for other modules that are further away
The OP us not talking about the central score-keeping system that records valid hits. He's talking about the system that actually determines whether a hit is registered or not.

The problem is that the OP wants the receiver on the target to to be able to register multiple guns firing transmissions repeatedly at a target, at the same time, without blocking each other out causing the receiver to become immune.

So he wants to having all the players be alotted a dedicated, periodic time-slice in which only their gun is actually allowed to fire bullet/transmission. And he wants all other players' hardware to be synchronized so they all agree on whose time slice it currently is such that if shot is received during a particular time slice, then it must belong to to a particular player.
 
Last edited:

Dr_Doggy

Well-Known Member
but such a system will take forever to cycle through , i anticipate it will take a few seconds to do a full cycle, which will make for a lousy game..

its good that he is thinking about how to handle the multiple devices, but the way i mentioned will keep the game at top speed (and handle all the queuing ).
the zigbee RF network will handle much like an i2c one where each device is addressable, plus also the coordinator unit can listen to the line for active data being sent up...

so then it all comes down to the IR emitters and receivers .. he may be able to still pulse the laser fast enough to get a byte to the receiver in the time it takes to shoot by using a modified ir protocol where the pulses are stretched to longer time frames to better suit the discharge times of the laser
 

Latest threads

EE World Online Articles

Loading

 
Top