Electronics What am I going to need for this project?

Ok, http://www.lapz.com
I've been researching what it would take to make something like this. I have yet to find a product like this in the US.

Now, I don't need to be able to have 256 cars, just 2-6. So if there is hardware that is cheaper like using a dipswitch instead of a chip with sometype of eeprom to set the car id that'd be great

First off I am a computer programmer. The software side of this (and possibly learning any PIC assembly if needed) isn;t a problem for me. What I'd like to know is what would be the best approach to making a system like this? What hardware should I look for?

From what I can tell I will need a way to communicate to a serial port on the computer. I hear a max232 is great for this. Is there something simular but cheaper than a max232?

I've been researching what might be needed. It seems to me that on the car you need a transponder that will have an IR transmitter, something to set it's ID (lapz uses an IR receiver and probably eeprom on the pic), and something sending it's ID to the transmitter. I was thinking this could be done with a set of dipswitches, an IR transmitter, and a small pic like an 8 pin pic.

Now, the receiver that goes over the track and what talks to the computer I'd think would need several things. Each receiver would need an IR receiver, some pic to process the signal and send the processed information back to a central PIC or processor. Then that central pic or processor talks to a max232 or equivilant which talks to a computer. The computer could do the timing, I'd think. I don't think you'd have to do the timing on the hardware like Lapz does to save on cost. That's the part I am unsure about. I am also unsure of what and how to transmit the ID (IE do I need a protocol, sync timing somehow, something else I don't know about since I am new to electronics) and how to receive and process that signal into something usable.

Again, I am new to electronics, kinda trying to figure this out on my own. I've always been interested in it. I've been able to do simple project like hook up and use a 20x2 text LCD to my computer. This is a bit more coplicated

I am probably not thinking of something as I am not use to this. What I am thinking is this doesn't seem terribly difficult to accomplish. I think the PC could do the timing. I would think I could just send the ID of the car to the computer and let the computer deal with the timing. That should make this project alot cheaper. I have a 486 laptop I plan on using for this project. I will have to search for an old c++ compiler that will work on it. I think I have borland c++ somewhere around here for win 3.11

I forgot to add unlike lapz I want to support a starting tree. I know some slotcar software does. A starting tree is a simple 5 light progression. 4 red, light up in succession, a pause, then a grean light to go. I will need to have this system not start timing until after green light is go. I'd assume this would be computer controlled to if the timing is done in the computer.

 

On first glance the way you plan to do it should work. You will probably need a protocal to transmit bettween the cars and the base stations. The way I would do it is have the cars constantly transmitting an 8 bit "packet" the first 2 bits are all 1s and the last 2 bits are 0s and the data is placed in the middle. Therefore your base station will be able to work out if it has the whole packet or not.

Its an interesting project. good luck

Lynx

edit: How do you plan to cope with 2 cars going through at once?

 

Yeah, that's another issue. Frankly I don't think it would be that big of a problem. With as fast as pics run I don't think it will be a major issue. It will rarely ever happen. But it can. Note, the receivers over the track are spaced so they barely over lap each other. It would even be more rare that two car transponders cross at the exact same time under the exact same track receiver.
So, if you can handle more than one receiver sending information at once this problem is virtually eliminated. Again, it would be rare but I suppose it could happen. There is another issue with this, will explain later.

The protocol thing is the biggest issue, and that's all software. That's what I am wondering about. Your idea is interesting but I could see where that would fail. Probably just as rare as having two cars go through at the same time. Either way the protocol will have to be fast, some pattern that is easily recognizable that the car is always outputting as it is under the receiver detection area for a short time.

See, there is another issue.the speed at which the car transponder is signalling and the track receivers picking up signals. If thosse are off or not in sync I'd think there would be a problem. Also with the protocol the car could send out the the signal several times while under the track receiver. SO I'd have to have a timeout that after the receiver receivered a valid signal.

Now, the track receiver, I am wondering how that should be setup. What type of hardware/pics should be used? My original idea was each track receiver would get a dedicated I/O pin back to a central processing pic which talks to the max232. However that would mean data transfer between the receivers and the main processor would be completely serial. The good thing about it is I'd think it would be easy to send to the computer then since it is already serialized data, just need to send at the correct speed to the computer. See, then the pics on the receivers would probably just need to be an 8 pin pic.
Or is there a way to have the pics on the receiver send back to the main proc parallel data and not interfere with each other. meaning the ribbon cable that goes out each receiver will be on. Lets say 8 pins are for the receivers to send info back to the central proc. It could be possible to have some other pins on the ribbon cable as I/O lines to do protocol between the central proc and the receivers. With all the receiver being on the ribbon using the same ribbon cable you'd have to have a way to controlling who is getting and sending what info.
I am trying to figure out how Lapz can have you just put as many receivers on the ribbon cable (flexible to your size of track) but there is an upper limit. That is one of the parts I haven't figured out how they did. Or what would be the best way to handle the situation. This would have to be solved with a good setup of software and hardware, I just need to figure out what is the best way of doing this.

It the little details I am not sure about. The overall picture I think I have with all the research I have been doing. And most of these problems are software related like the protocol. I am a programmer, but not a good systems programmer, though I think I'd eventually figure it out with more practice

 

Can you have the cars be on a sort of token ring so that before sending any messages, they listen first and see if the other one is sending a signal.

For keeping sync, you can just have the cars/computer check at set intervals and whenever there is a signal present at the time recieving is considered in clock - it will be valid. That way you can sync up asynced signals, at least that is how buses on my computer run. The async signal and synced clock cycle will overlap and that will register as valid.

The first signal should be an ack and once the signal is recieved a handshack connection is established at the next available valid input (your recieving end knows the clock cycle of your transmitting in via first and subsequent signals recieved - period between bursts). From there you can start transmitting data to and from computer and car.

Instead of pics, you could also utilize Basic Stamps since they have communication modules for things such as this.

 

Xiachunyi, interesting.

"Can you have the cars be on a sort of token ring so that before sending any messages, they listen first and see if the other one is sending a signal."

ok, how do you get by if two things want to send at the same time? When they check no signals will be happening and therefore both will start sending

"For keeping sync, you can just have the cars/computer check at set intervals and whenever there is a signal present at the time recieving is considered in clock - it will be valid. That way you can sync up asynced signals, at least that is how buses on my computer run. The async signal and synced clock cycle will overlap and that will register as valid."

If I use difference PICs they could run at different speeds, therefor one would be sending information faster than another one could receive it? Or am I not understanding something? At least from my understanding while looking at PIC specs. Again, I am new to electronics. I am trying to figure this out as I go

"The first signal should be an ack and once the signal is recieved a handshack connection is established at the next available valid input (your recieving end knows the clock cycle of your transmitting in via first and subsequent signals recieved - period between bursts). From there you can start transmitting data to and from computer and car."

Ugh, that would mean a transmitter and receiver on the car. would processing be fast enough, with IR transmission and receiving, to pull this off in the little time the car is under the beam. Relize these cars can go upto 30mph so they won't be under the beam for that long. Actually, thinking about what Lynx said. If I sent an 8 bit pattern. The first bits being 11 the last bits being 00 it would work. The track receiver would read 8 bits in then just have to rotate bits until the 11xxxx00 pattern is found is found. It's been awhile sinc eI have done this low level stuff. what would be the bit mask for checking for that format? 11000011 or 00111100? Then check for the dec value of 192? That would give me 15 unique IDs for the cars. That's plenty as the R/C cars I race only have 12 different frequencies. I couldn't do it with an 8 bit ID to 256 unique IDs. 11011000000 could be read in as 110000001100 depend on when you started reading in the bits. But it is not possibile to get a mixup with a 4 bit car ID. Of course with 8 bits you'd have to use 4 1s and 0s instead of 2. Depend on if the IR system is fast enough to read that, though that isn't much data.

What is a Basic Stamp? I suppose that is answered in one of the stickied links.

 

Ok the sync problem is easy. Get your receiver sampling at multiples of the transmittion rate (2x or 3x should be enough and the rest is software) Can you explain where my protocol would fail I cannot see how.

edit: Ok you realised that with the way I rigged it (8 bit packet 4 bit data) that it would always work. You are on the right track with the barrel shifting method. that is the way I would do it. Just keep shifting till you get 11 at the start and 00 at the end.

 

Usually when this happens and both signals are recieved, they are both rejected by the recieving end. Each car would wait a certain delay, scan for another transmittion, and send their signal again. This way they would not send their signal at the same time again since they did not recieve an ack from the recieving end. This was done, I think, on old networks before 100 based came out.

In order for different applications to sync up, they have to issue a speed at which they both agree to transmit. Hence modems and so on offer a baud rate which the computer agrees upon and they transmit at that speed regardless whether or not one is faster than the other.

Communication between devices with light is fast enough just as long as the frequency at which the counter frequency, established rate of transmittion, is up to par.

A basic stamp is like a PIC except most of the applications are already provided for you.
This is their main site
Look under the application menu tree on your left and you will see modules for Bluetooth, computer interface, radio frequency, modems, IR, and so on under App Modules and Communication.

 

Don't want to get off topic, or talk from my a**, since I am an electronic neophyte, but I have been reading much regarding RFID. It seems that this is right up your alley. Many RFID manufactures will ship experiment/testing/etc kits. An RFID transmitter will fit in even the smallest car and takes no power. I guess the biggest problem is that it is proximity and may not be “targeted” enough for your application.

 

My local library uses RFID tags for both ID and security, and for the security, the base unit has two large coils on both sides of the doorway.
Indeed, to verify that you want to check it out, the ISBN barcode is scaned; else a book can be accidentally "checked out" just by waving it across the machine!
So, RFID should have enough range. However, I'm not sure if it will still work if the tag is waved at race car speeds!

 

I have seen RF production systems. They are insanely expensive.

Anyway, I have to take time to process all this information Thanks for the help.

 

How would the receiving end know two signals have been sent at the same time? If, on the ribbon cable, two IR receiver modules sent a bit pattern ont he same ribbon cable wouldn;t they OR over each other? like if one sent 11001100 and one sent 11010010 the receiver would see 11011110?

How would you control this? Does the software control this or would I need some sort of timer/clock hardware?

 

That would designate an invalid ID code since the recieving end only expects a certain code, namely something indicating: "Hey I am transmiting now!"

Once that is received, the program steps into establishing a handshake and either ignoring all other transmittions until communication has ceased or what the programmer wants. The transmitter will "hear" for a call-back signal from the reciever or when a stipulated wait duration is reached, re-transmit the signal. Once the recieving unit transmits a handshake and the recieving end accepts and acknowledges - communication begins. From here you could either decide to change the modulation so other signals are ignored or deal with them your own way.

This elucidation is a kind of archaic way of communication but you are only dealing with a limited and known number of objects, from my readings; unlike the world where a program must deal with "who knows what is transmitting what with what".

 

Ahhh, I get what you are saying now. Thanks.

 

Xiachunyi that is going to take to long or is going to be over complex of both. You dont need a handshaking protocol with this kind of system. It is an overelaborate solution to a rare problem.

The way you would sample faster tan the signal is being sent depends on how its implemented. One way it to set how fast you are sampling then divide that by 3 hence getting how fast you must send the data.

The other way is to do it the other way round.

You need to work out how long you have to receive this data based on the distance you can receive the data and how fast these veihicles are moving.

Assuming you are using cars traveling at 10mph (about 5m/s) and say you have a detecting range of 20cm (probably being overly genrous there) that gives you about 0.04 seconds in which to send the data (preferably 3 or 4 times) so say (0.01 seconds per byte) That gives you 800 baud. I doubt you will be able to get handshaking working at that speed as that woudl require much higher baud rates (4, 5x higher at least)

This is just my opinion.

Lynx

 

I have no idea what you just said but if it is easier and faster, then go for it.

 

basically what I said was that you are going to have to send to much info with a handshaking protocol to be garrenteed the transaction will be over by the time teh vehicle has passed through the gate.

I like your method I realy do but I dont think it will work in IR. with RF it woudl work very nicly however.

 

Oh okay, I'm sorry.

I like the idea of information over radio too (Actually I was leaning toward that). With that, they could be on different frequencies and there will be no need to go through all that agreeing - the computer would know automatically who was who.

We'll see what "SirPoonga" says.

 

No need to appologize. You are doing somethign I have tried a few times and have never done with your 4 bit computer I would love to know more about it PM me if you want.

Lets see which one SirPoonga goes for. Yours is more robust mine is a bit more elegant.

 

Actually, I'd love to for an RF solution if it can be done for near the same price as the IR solution. If I wanted to go this route it brings up more question, will get to those in a moment.

Ok, back to a previous question

How would you control this? Does the pic software control this or would I need some sort of timer/clock hardware?


Ok, RF. I am not familiar with how RF works other than the little bit of information I assume is correct based on the fact the controlling an r/c car is RF
What hardware/parts would I be looking for? When I search digikey for RF alot of stuff comes up.
Also, frequency would have to be set. That involves sometype of crystal to set the frequency, right? Is there a way to have an adjustable frequency? I ask this because with the IR method I plan on putting a 4 switch dip to control the ID of the car. As long as each transponder has a different ID we are fine. Can you do something like that for RF or would you have to make each transponder with a specific frequency?

Right now this is an idea of mine to make the hobby easier for me and my friends. I am open to any idea that would be better than what I am doing. The advantage with RF is you could put the transponder inside the car as you wouldn't have to have the lightsource of an IR outside the car. Having someone count their own laps is not an easy task

Right now we use the ol' laser and flag system with slotcar software. But that can only handle 3-4 cars. And since the cars we run have 12 different frequencies ...
Here's an example of what we are doing now.
http://www.schumacher.clara.net/laptimer.htm
But as you see you are very limited in the number of cars you can run, it dpends on how tall the antennas are and how much the antenna moves since you have to leave space for that.
However, this method is hooked through a parallel port. Nothing wrong with that but that means I have to remember to bring my laptop along. If it was serial it wouldn;t matter who brought their computer along. Like one of my friend's laptops don;t have legaco get a com to usb convertor.

 

One problem you will have with RF is having the signal trip as the car crosses the line and not a few meters before or after. What ever happens RF will be more expencive than IR as you will need a lot more electronics.

Are your RC car's bodies IR transparent (quite a few plastics are) if they are then you dont need an external IR light source.

On the smapling rate you will have to do it in software. Just od it by running a timer and when it reaches a certiain point reset it and at the same time see if any data is coming.