Serial one way link with one Rcvr, multiple transmitters

[groundhog1]

I have to start by saying I have mostly an RF circuit design background. I have been asked to do an RF serial one-way data link. I can do that..

Then, of course, the scope gets expanded. Now there are multiple transmitters sending data to the one receiver. The receiver needs to be able to know the ID of each of these senders.

Each of the transmitters is actually a sensor measuring temperature data. The data is gathered and serially output to an RF link module that is commonly purchased nowadays.

At the other end is the receiver module that is connected to a uProcessor. The data is displayed on an LCD.

I need guidance as to what type of circuit to add to the transmitter circuit to add the ID to them.

Also what type of circuits need to be added to the Receiver to decode the ID.

It needs to be cheap as this is very low cost stuff.

App notes??

Thanks in advance,
groundhog1

 

[VisiGoth]

ZigBee is your target concept.

If you want to roll your own the development cost and possibly the parts cost could be higher.

You could look at the traditional Multiple Acesses (MA's)
FDMA, TDMA and CDMA. With your RF background the FDMA would be straighforward. You would actually have multiple IF strips. With TDMA you have less RF hardware but you need to coordinate your transmitters, but since they don;t Rx, that could be out unless they have information about absolute time. Or you could do an ALOHA collision system, but that is complicated.

That leaves CDMA. A simple color code could distinguish the mutliple sources and you will have only one IF strip and one detector. Your digital logic is more complicated, but that type of work is low cost these days.

You specifically mentioned a circuit you could add to the transmite circuit to add the ID. With FDMA that would be just a frequency shift, but your recievers must be tuned, so that might be out. With TDMA you could put a low duty cycle swith on the transmitter. You would only transmit some of the information, but if your information rate is slow youmight be able to afford the slow data rate. You would just hope that the random transmit times of your mutliple transmitters don;t collide too often. You could use a different pulse width for your ID. This is very sloppy but could be the least complicated and cheapest. A CDMA solution would be easy conceptually on the transmitter. You would chop some parameter, like phase, frequency or amplitude. Phase is my favorite choice. you would chop the phase in let's say a psuedo random sequecne based on a gold code. The receiver would have a matching code. You would look up RAKE receivers or CDMA. Making a custom system like this is conceptually simple but has a lot of details to debug. Motorola (freescale) has app notes and there is a good book by Dixon. But if you have to get to that theoretical level you have a lot of work ahead of you.

Do your transmitters transmit all the time now? If not, that is probably will help guide your approach. A random transmit time with a very low duty cycle could make your probability of collision low enough to be OK. You ID could be as simple as a unique pulse width.

 

[groundhog1]

Hi VisGoth,

Yes, the transmitters are sending at random times. Maybe once every 10 seconds or so. The transmissions will not happen any quicker than every 8-10 seconds.

I keep thinking about the lock/unlock circuits used on automobiles. Each has it's own unique ID. If you configure a receiver to just decode each ID, then you can display the data for each sender.

But collisions...
What if each transmitter sent 3 times, randomly spaced within 1 second. If the receiver has already received an identical transmission in the last second, it is ignored and not displayed on the LCD.

Am I reinventing the wheel?

groundhog1

 

[zeitghost]

Worked on a system similar to your proposal about 12 years ago.

Used the licence free 458MHz radio telemetry band in the UK.

 

[VisiGoth]

The coding involved in key fobs would impact both your transmit and receive baseband sides. You had originally requested some way of interfering with only the transmitter output section (or am I reading too much into this?)
If you can keep your transmitters relatively prime in the PRI and can create pair of 2 unique PW, you would reduce your collision % and not erroneously assume the wrong ID when two pulses overlap.

For example, could create PRI of 7, 9, and 11 seconds and use pulse widths of 5, 10 and 30 ms. The PRI and prime under multiplication and the PW are prime under addition (I have no idea if those are the correct terms).

The changes to make this happen might have less impact on your design than alternatives.

 

[groundhog1]

I think there is leeway to define the message format the way you describe. But the transmission times will be random. They just won't occur any more frequently than say every 10 seconds.

But, I don't quite understand what you are saying. For PRI (I assume "pulse rep interval"?) of 7,9, and 11 seconds, are you saying that message transmissions should occur at these times?

How are you defining pulse width? Is this the pulse width of the individual bits sent in the message?

thanks,
groundog1

 

[VisiGoth]

Sorry for the confusion and for not defining terms.
I have assumed that you have a temp. measurement system that continuously transmits its temperatrue. I assumed you did not need this continuous time coverage and you could "poke holes" in the time coverage. I also assumed that your temp. data could be sent in one milli-second. So, I thought you could turn a transmitter on long enough to transmit the data "several" times, but not continuously. I assumed the transmitters did not have access to a common clock. Therefore, if two transmitters happend to transmit at the same time, it would be a one time occurance (for quite a while) if you made their nominal PRI diffeent prime numbers. For example, it would be 7*9 = 49 ms before you had a second pulse collision. My example numbers are very simplistic and you could do myuch better.

A second problem is that when pulses do collide, it would be nice if you knew they collided so you could ignore the information. If your receiver could measure the pulse width (PW) of the transmitted burst of information Here I have assumed that you present modulation method was not ON OFF Keying (OOK), and Amplitude Modulation (AM) method that would mess up the PW ID method I am proposing. If the PW's you choose can not possibly overlap in any manner to from the PW of any one of the other ID PW's then you would have a more robust system.
If you can not cotnrol the transmit PW and PRI or cannot measure PW at the Rx end, then this idea will not work. This idea allows you to add the ID by only modifying the modulation portions of your system and does not require a change to information modulation method or frequency.