I did ask for some information regarding the IR signal at slotforum.com and a member gave me a link to this thread, which pointed me to Electricimages.co.nz, a site I had seen several times but didn't find it any helpful as it seemed broken. The site had some kind of history and through that I could reach different pages otherwise not available. That site had all the information needed to build a simple circuit to read the signals coming from these slot cars and how to decode them. Luckily I were in no need for my very (very!) bad oscilloscope skills.
As I had an Arduino laying around I wanted to make use of it in this project rather than using the circuit and assembly code found on the site linked above. I ended up with this schematics for my Arduino Uno, which is capable of reading one IR sensor. Good enough for a start.
Regarding the Car IR LED the site states
The car generates its signal with a nominal bit time of 48µs, where a 1 state is LED on.
- The time between the start bits defines the car id.
- Padding bits are placed after the start bit, meaning that Car #1 is about 190µs ((1 +2 +1) * 48µs)
- Nominal cycle time for Car #6 is about 530µs ((1 +2 +6) * 48µs)
- The LED signal is inverted when the lane change button is pressed
Note that the timing of the car id output is not perfect nor exact. There is a small amount of jitter present (approx ±500ns) on the LED, which any detector circuit must take into account.In an attempt to understand the signal a little better I created a simple Arduino sketch using PulseIn() and see the actual pulse time. The bit time is said to be around 48µs and I found that the time was around 57 - 63µs with PulseIn, and the calculated time were roughly between 220µs to 240µs for car ID 1, it should have been around 192µs. This is around the same time as Car 2 should be identified as... ((1+2+2) * 48 = 240)
Example output from sketch reading Car 1's signal.
High: 58, Low: 165, Sum: 223I am not quite sure the reason for this but I have seen several posts while researching decode IR signal in earlier experiments that using various functions (digitalRead) often is too slow for decoding IR signals... And as it polls each pin instead of interrupting if something happens I could easily miss car running over IR sensors.
High: 57, Low: 180, Sum: 237
High: 58, Low: 179, Sum: 237
High: 57, Low: 179, Sum: 236
High: 57, Low: 171, Sum: 228
High: 57, Low: 180, Sum: 237
High: 58, Low: 172, Sum: 230
High: 58, Low: 175, Sum: 233
High: 57, Low: 180, Sum: 237
High: 61, Low: 161, Sum: 222
At this thread at slotforum.com a user posted an Arduino circuit and link to a sketch which could decode the car id and lap-time as far as my understanding. It makes use of Arduino Interrupt capabilities but I got a lot of weird output. A little snippet of the output is seen below (Car #1):
6:0
6:2
5:680
5:2020
5:1393
5:583
5:1577
5:1494
I stripped down the sketch to just make use of the algorithm to calculate time between each high pulse and found the results to be a bit more accurate (between 180 - 192µs) but if I could replace the call to digitalRead() by using raw pin reading instead I might get even more accurate readings. Anyways, I were able to identify cars although the timing is inaccurate. The sketch I found use two external interrupts but I were in need of a LOT more interrupts if I were to create sensors before and after each corner on the track.
According to arduino playground the UNO unit support two different kinds of interrupts, external and pin change interrupts. With pin-change interrupts I could enable interrupts on all 20 of I/O ports on my Arduino Uno. I found a library which made it easy to both set up and use pin-change interrupts.
In my sketch I ended up with horrific "if else" statements to identify the car as the timing were inaccurate, but it seemed to work as I tied everything together this weekend and tested the concept with four IR sensors on a tiny bit of the track I intended to use. It all worked perfectly together and the timing from sensor was read and the cars speed were set did not seem to be an issue, which was one of many concerns I had before testing. Although i am not quite sure how this setup would compete against an skilled slot car racer, I would call the test an success. The setup seemed to have a lot of potential and it would be easy to control the car in a very precise manner.
Now it's time to clean code, implement a handler for active handsets so humans can drive with ruby interface active and a lot of circuits to build.
Resources
Slotforum DigitalCar Signal Format
Car ID Decoder
Github Repo
Ingen kommentarer:
Legg inn en kommentar