Multiple transmitters and ONE receiver

[matheuslps]

Hello people.

I am developing a project that I need to send a ID to another PIC via wireless.

This part is easy and it is working. I found one code here on the forum and modified to my needs.

So, I need some ideas how can I face one problem:

In this project I need to send a maximum of 100 diferents IDs with 100 diferents transmitters to one single receiver. Each transmitter has only one ID on a total of 100 transmitters. I did not decide the PIC I will use, but a small one. Now, I am doing tests with the 16F877A.

So, for now I configured only 3 PIC transmitters. Every 5 seconds they transmits their IDs and the receiver collect it. It is working.

BUT, if 2 or more transmitters send on the same time, the receive will collect wrong ID values.

How can I face this incovenient?

This project is to put the transmitters on some animals and monitore their positions ON a field. The goal is if the animals (cows) get near the receiver, it will get the cow ID and keep on a database made on a PC that is already done. I use the USB comunication with C# and 18F4550 and it is working very fine.

The other incovenient is that the wireless chip that I am using can send the IDs over 100m on a open field. This distance is too far. The field is not so big and I need to reduce the operation of the transmitters. I am using the cheap 433Mhz pair modules that are available all over the world.

PIC1------>MASTER RECEIVER
PIC2------>MASTER RECEIVER
PIC3------>MASTER RECEIVER
PIC3------>MASTER RECEIVER

And so on....

Thanks and sorry for my english mistakes.

PS: If someone is interested on my USB link using the C#, take a look at the video below (IT is not a CDC conection):

http://www.youtube.com/watch?v=GjACB0RiuBQ

Matheus Lopes
From Brazil

[John P]

What might make this work would be to have each unit transmit very briefly and at long intervals. Then the chances of interference would be reduced--but then would the system be useful? You will need to do some mathematics to calculate how often a clear transmission from each unit is likely to get through. It will be a statistical question.

A way to deal with it might be to use a dual oscillator, with a 32KHz crystal attached to each processor. Some PICs can accept this to operate Timer 1--I know the PIC16F877A can. This would give you much better timing accuracy than the regular crystal. Maybe that would let you synchronize the processors so they would each transmit at separate times, but again it would depend on how long the transmissions are, and how often they need to occur. And obviously, after some period you would need to round up the herd and re-synchronize the processors.

If you had 2-way radio then you could call for a transmission from each unit in turn. It might the only way to do it.

[matheuslps]

Thanks for the reply.

I agree the use a 32Khz crystal. This will consume less power.

The idea you gave to use a 2-way radio is very good. In this way I can make the MASTER receiver call each of the transmitter in turn like you said. BUT, then all the transmitters will operate from batteries because it will be on the cows. Only the receiver can operate from a power supply because it will be near a computer to link with the USB.

Yes, I can make the intervals long enough but with 100 transmitters, some time they will send data together and that is where my problem begins.

bye

[temtronic]

It'd be a lot easier to 'reverse' the overall design.
The 'master' would be the unit connected to the PC, the 'slaves' the units on the cows.
The master would have a database of cow-ids and poll each one in sequence,either getting the data or timing out(loss of signal,try again).
I know this will work for 24 head of cattle,did it a few years back.

By doing it this way there is no problem of multiple transmitters corrupting data.

[gpsmikey]

You might want to take a read through the TCP/IP information on how they handle collision avoidance and detection. While you don't want a receiver added to the cows, one of the tricks you could use to help keep the collisions under control (sort of) is to use a time delay between transmissions that is a function of the ID of the transmitter - this will mean each one uses a different delay so you don't end up with them getting in sync and continuously stomping on each other. Also, send a checksum/CRC/whatever on each packet - if the checksum doesn't match, discard the packet as corrupted. Without a receiver on the cow side, it is tough to blindly send data and hope it gets received correct (how about a methane powered fuel cell for the receiver/transmitter on the cow - just run a hose from the cow to the fuel cell :-) )

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[John P]

What I meant about the 32KHz crystal was that it runs the processor's Timer 1, not the entire processor. But I believe that timer would then be super-accurate, to the standard of a digital watch. That would keep all your transmitters in sync, at least for a while.

And regarding the concept of brief, occasional transmissions, suppose each one broadcasts 1% of the time, but you need to keep them separated so that the interval before and after the transmission window is also clear. In other words, if a transmitter broadcasts for 1msec 10 times a second, you'd require a 3msec window for a good reception. Then the chance of getting a good signal would be .97^99, or .049. A chance in 20 of getting a good result--that probably won't work. So what if the units brodcast for 1msec once a second? Then you'd be calculating .997^99, which is .74 . Maybe that's good enough? Of course then you need to calculate the chances of 2 or 3 or some-number of bad transmissions in succession.

If part of the design involves a range beyond which you don't want to receive your radio signals, maybe you could use an ultrasonic beeper at the master unit. Every slave within range would hear this and would respond with a radio packet (spaced in time, of course) but otherwise they wouldn't broadcast. I think a sound-based system would give you better control of range than radio, but perhaps I'm wrong about that.

[SherpaDoug]

I think keeping 100 transmitters all synchronized is going to be impossible.

Instead of a 32kHz crystal I would use a 32kHz RC oscillator to time between transmissions. The oscillators will drift in random directions at random rates so no two will consistently interfere. Use a checksum so you can discard corrupted packets, but also try to keep the packets short. Transmit often enough so that you can lose a few packets without harm, but not so often that there is little space between them.

The exact timing will depend on the behavior of your radio circuits. Work on the range problem first by reducing the antenna size or starving the transmitter of power. Then see what your message timing will be.

John P's idea for an ultrasonic interrogator is also a good idea if the cows can carry the equipment.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[matheuslps]

Thanks all of you with the ideas.

Fow now, I will try the simply one. The checksum.

Like, imagine I send the ID 123456, my checksum will be the sum of the algarisms....

So on the receiver I just do:

[arunb]

A token ring like topology could work here, the transmitters can pass a 'token' to each other, the transmitter that has the token would have the permission to communicate with the receiver.

thanks
a

[SherpaDoug]

The token ring idea would be good except now each cow has to carry a receiver as well as a transmitter. Due to being ON all the time, receivers usually require more batteries than transmitters. Is there any way you could harvest energy from a cow?
_________________
The search for better is endless. Instead simply find very good and get the job done.

[dorinm]

simply, there's no solution to this problem ...sooner or later (most probably sooner ;) ) there will be for sure at least 2 transmitters overlapping and as far as you're using a single radio frequency the receiver would never receive a valid block of data , even a simple serialnumber.
So you might consider the receiver-trans. pair, I think this time is the only reliable way.

[gpsmikey]

I don't think it has to receive the data each time, just most of the time since you want to know if they are in the area (and they typically don't move around that fast). So the occasional collision should not be an issue (especially if you use the idea of each transmitter using a slightly different delay between transmissions (based on the ID for example) to keep them from repeatedly colliding). As for the possibility of having a receiver, I still like my idea of a methane powered fuel cell with a hose plugged into the cow :-)

If you decide you really need a receiver, another approach would be to have the transmitter and receiver power up, send the data burst and listen for an ACK from the main unit. If it gets the ACK, it goes back to sleep (both trans and receiver). If not, it sends again - repeat up to 3 times possibly ? That would minimize the power required for the receiver although I still think getting the data most of the time should be sufficient (and the shorter the receiver range on the master, the less collisions you should be getting although the "area of interest" is smaller)

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[mutthunaveen]

Hi your project is very interesting.

My suggestion may help you... just add a RTC to your transmitting kits. Schedule the perfect timing for each kit and you can receive without any collision.

%of drift for a RTC is very low and no more collisions.
Give appropriate intervals .... (drifts may not exceed some +-10 seconds per year) use timeouts for the availability of cow.

I hope this will the best solution for your problem if you don't want to add some more rx to your circuits..... hope it helps.

[ckielstra]

[matheuslps]