DIY chrono

[Maekl]

I am desiging a chronograph for airsoft from scratch. The sensors havent arrived yet, so I had to improvise and make a some kind of program to it. At this moment it just measure the time between the switch1 and switch2 when they are pressed at different times. Once I get the sensors, I will make it calculate the speed of the bb. When its done and working, I will upload all the project files so that anyone who wants can make one, and make some differences to it if they like to. : )

 

Heres some pics what I have done so far.

 

 

 

Here's the program I made. It's far from ready right now, but give ideas if you like! Sorry the comments are in finnish : D

#include <tiny2313.h>

 

#asm

.equ __lcd_port=0x18 ;PORTB

#endasm

#include <lcd.h>

#include <delay.h>

#define START !PIND.0

#define STOP !PIND.1

 

void main(void)

{

unsigned int counter; // laskurin määritys

unsigned char kt; // kymmenet tuhannet

unsigned char t; // tuhannet

unsigned char s; // sadat

unsigned char k; // kymmenet

unsigned char y; // yhdet

 

#pragma optsize-

CLKPR=0x80;

CLKPR=0x00;

#ifdef _OPTIMIZE_SIZE_

#pragma optsize+

#endif

 

 

PORTA=0x00;

DDRA=0x00;

 

 

PORTB=0x00;

DDRB=0x00;

 

 

PORTD=0x03;

DDRD=0x7F;

 

 

ACSR=0x80;

 

lcd_init(16);

 

lcd_gotoxy(0,0);

lcd_putsf("Welcome to DIY chrono prot.1"); // alku esittelyt

delay_ms(4000);

lcd_clear();

lcd_putsf("Made by Lauri Maeki");

delay_ms(4000);

lcd_clear();

 

 

 

while (1)

{

lcd_gotoxy(0,0);

lcd_putsf("Fire one shot");

 

 

counter=0;

while(!START) // odottaa kunnes START arvo on 1

continue;

while(!STOP) // seuraavaa lausetta toteutetaan kunnes STOP arvo on 1

{

counter++;

#asm("NOP")

#asm("NOP") // lisää counterin arvoa yhdellä kerran 2 mikrosekunnissa

delay_ms(1); // viive manuaalista testausta varten

}

 

{

lcd_clear(); // satojen, kymmenien yms erottelu lasketusta ajasta näyttöön kirjoittamista varten

kt =counter/10000;

counter -= (kt*10000);

t = counter/1000;

counter -= (t*1000);

s = counter/100;

counter -= (s*100);

k = counter/10;

y = counter%10;

 

lcd_gotoxy(0,0); // nopeuden ilmoittaminen näyttöön

lcd_putchar('0'+kt);

lcd_gotoxy(1,0);

lcd_putchar('0'+t);

lcd_gotoxy(2,0);

lcd_putchar('0'+s);

lcd_gotoxy(3,0);

lcd_putchar('0'+k);

lcd_gotoxy(4,0);

lcd_putchar('0'+y);

lcd_gotoxy(5,0);

lcd_putchar('m');

lcd_gotoxy(6,0);

lcd_putchar('/');

lcd_gotoxy(7,0);

lcd_putchar('s');

lcd_gotoxy(0,1);

lcd_putsf("Please wait");

 

delay_ms(3500);

lcd_clear();

}

}

}

 

And a video.

 

01000 is 1 second in the vid.

[Hakkon]

Very interesting. Ima keep watching this topic with interest.

[wilfire]

Nice idea. Looks like a good choice of micro controller too. (more of a pic man my self but looks like it should have the features needed )

 

Are you considering using the timers on the chip or going to stick with the while/count/wait method? Would imagine the timers would give better resolution but would also be harder to program.

 

Damn your making me want to break out my programming kit

 

 

 

[Maekl]

I considered using the timers but I ended up with this simplier solution. This is btw the sensor that I will be using, the omron ee-sx1140

https://www1.elfa.se/data1/wwwroot/webroot/...TA/07540610.pdf

[ertgunner]

very nice . i shall be watching this if it works well i shall try it also

[madwelshman]

that is VERY impressive! good work fella! I wish I knew about electronics, slowly teaching myself with basic kit projects, very basic stuff!

[Caparsso]

Hi. (I'm so sorry for my english)

Maekl, your design is good looking! Bravo!

 

I'm working in a selfmade chronograph too.

My prototype works with two light-sensitive LEDs from a ripped computer ball-mouse.

It consist in a thin pipe, with 2 little holes in each side, separated a known length, to plug a light-sensitive LED oppossing to a light LED. The idea is to iluminate the sensitive LED till one BB cross betwen the both LEDs. When that happens, a basculant circuit, bascule to a circuit which generates pulses with a known frequency. It starts, and it stops when the BB pass across the another pair of LEDs in the other side of the pipe. A counter circuit can check the number of pulses (in binary).

 

Knowing the frequency of the pulses and the number of pulses, we calculate the time which the BB empleased to cross the pipe. With the length wich separate the 2 pairs of LEDs, we caculate the speed.

 

In addition, we could plug a decoder to pass from binary to hex and show the numbers on a display.

The operation of divide distance/time it's so hard to design in a circuit for me

 

Maekl, your prototype is 1000 times better than mine, but I hope at least, you could consider my idea of light-sensitive LEDs.

[Inventor]

Wich C language do you use?

 

I would use 7 segment displays just for readability (LCD's tend to have low contrast sometimes) but looks good. If it was my circuit, i'll change the layout a little bit:

 

Signal line from pin2 (PD0) could use a little more clearance with R5 pad (no need to such a tight fit).

Ground line from bottom sensor, could use a little more clearance with said signal line, and about the same with ground line going "under" signal pins on the LCD. (just to make etching easier).

 

 

 

Caparsso: He's already using infrared sensors.

[wilfire]

Inventor: The only problem with 7 segment displays is he would need a driver circuit for them as well. While he has a few spare io pins on the micro controller it would make circuit a lot more complex with a much higher part count. Also he couldn't do the funky text on start up or the units on the number output

 

Caparsso: that sounds like a hellishly complex way to do it. Good luck with the divide logic

[Inventor]

wilfire: I disagree with the driver circuit problem, each pin can output 40mA, plenty enough to drive three multiplexed displays (I have done it with a PIC whose port can only output 100mA or 12mA per pin) , also, he has plenty of I/O pins to control each display's common cathode.

 

BUT

 

Yes, the display has the coolnes of the text option wich can say terrible things to "too hot" gun owners ^^.

[Maekl]

Thanks for the comments! : ) Im using codevision, but I dont know which c language it is. I thought there is only one? o_o At first I was going to use 7 segments but they are a lot harder to program and they need a buffer.

[wilfire]

Inventor: My apologies, I think I may have confused things, by driver circuit I meant the multiplexing of the outputs to the displays, rather than the circuit to provide enough current for the display, I know the chip should be able to output enough current, seven segment displays are really only a bunch of LEDs in a fancy package after all

 

I like the idea of rude messages to hot gun owners that's made me chuckle, "the chrono with personality"

 

"Hahahaha You've got to be joking if you think you can use that!"

"Ouch ouch ouch, are you trying to kill me?"

 

Maekl: Please keep us updated as to how you get on, its looking good.

[renegadecow]

Sweet! If this pans out, I'd be able to stop using my gut as a chrono being too cheap to buy one. You wouldn't be able to make this available as a build-it-yourself-kit could you, because all that programming talk makes my stomach upset.

[Maekl]

I hope the sensors will be fast enough to detect the bb's. For the bb to travel a distance of 5cm which is the distance between the sensors, at the speed of 100m/s (328fps) takes 0,0005s. So it takes about 0,00002s for the bb to pass one sensor : D Thats not a long time, but I hope its enough.

[Inventor]

Since the attiny2313 can run up to 20 Mhz, that gives you 0,00000005 per instruction (assuming it is like PIC's) so, whenever the first sensor detects a signal (should be done with interrupts for max precision) aven at max speed (600fps, 0.00025s) that gives you time to do 50.000 instructions, plenty of time to calculate.

 

Remember, it doesn't mater the time it takes the BB to cross the sensor, only mathers when does the BB activate it.

 

Here is a little program that shows display multiplexing, as you can see is not that hard to do it. ^^

 

 

[Maekl]

Nice, but you can wiew numbers only with those. ; )

[wilfire]

The sensors should be fine according to the data sheet you posted before it should be good up to 4micro seconds.

 

An idea to potentially get the part count down (and thus even cheaper) would be to measure the length of time the sensor is blocked, an input to select between 6mm and 8mm and you know the distance travelled. Only problem I can see would be how much of the bb has to be in front of the sensor before it changes state, which would reduce the distance travelled and thus the amount of time to measure. As Inventor pointed out you can do a bucket load of instructions in the amount of time it takes to travel that far.

 

Any way getting into the realm of silliness now so I'll stop.

[Maekl]

Alright. The sensors I'm using for some reason dont detect the bb's when I shoot them but when I drop the bb past them it works correctly. I'm using a aep with .25g bb's so the bb's arent even travelling very fast. The problem may be in the program itself but I cant find it. Here's the code if anyone could help.

 

Chip type : ATtiny2313

AVR Core Clock frequency: 8,000000 MHz

Memory model : Tiny

External RAM size : 0

Data Stack size : 32

*****************************************************/

 

#include <tiny2313.h>

 

#asm

.equ __lcd_port=0x18 ;PORTB

#endasm

#include <lcd.h>

#include <delay.h>

#define START PIND.0

#define STOP PIND.1

 

void main(void)

{

unsigned int counter; // laskurin määritys

unsigned char kt; // kymmenet tuhannet

unsigned char t; // tuhannet

unsigned char s; // sadat

unsigned char k; // kymmenet

unsigned char y; // yhdet

 

#pragma optsize-

CLKPR=0x80;

CLKPR=0x00;

#ifdef _OPTIMIZE_SIZE_

#pragma optsize+

#endif

 

 

PORTA=0x00;

DDRA=0x00;

 

 

PORTB=0x00;

DDRB=0x00;

 

 

PORTD=0x03;

DDRD=0x7C;

 

 

ACSR=0x80;

 

lcd_init(16);

 

lcd_gotoxy(0,0);

lcd_putsf("Welcome to DIY chrono prot.1"); // alku esittelyt

delay_ms(4000);

lcd_clear();

lcd_putsf("Made by Lauri Maki");

delay_ms(4000);

lcd_clear();

lcd_putsf("Use 0,2g BB for correct results");

delay_ms(4000);

lcd_clear();

 

 

 

while (1)

{

 

 

counter=0;

while(~START) // waits until START signal comes

continue;

while(~STOP) // Adds 1 to counter per 2 microseconds untill STOP signal comes

{

counter++;

#asm("NOP")

#asm("NOP")

}

 

{

counter*=2; // calculating the speed

counter=5000000/counter;

 

 

kt =counter/10000;

counter -= (kt*10000);

t = counter/1000;

counter -= (t*1000);

s = counter/100;

counter -= (s*100);

k = counter/10;

y = counter%10;

lcd_clear();

 

 

{

lcd_gotoxy(0,0);

lcd_putchar('0'+kt);

lcd_gotoxy(1,0);

lcd_putchar('0'+t);

lcd_gotoxy(2,0);

lcd_putchar('0'+s);

lcd_gotoxy(3,0);

lcd_putchar(',');

lcd_gotoxy(4,0);

lcd_putchar('0'+k);

lcd_gotoxy(5,0);

lcd_putchar('0'+y);

lcd_gotoxy(6,0);

lcd_putchar('m');

lcd_gotoxy(7,0);

lcd_putchar('/');

lcd_gotoxy(8,0);

lcd_putchar('s');

}

}

}

}

 

[wilfire]

From the video its clear that while the code works its for some reason its being missed when fired horizontally, two things to check with the hardware if you haven't already, that the bb has to pass between the sensors, if its just missing them it might be enough that its not quite causing enough of a change to register. The second one, I cant quite tell from the video if the tube is opaque (It looks like it might be a metal tube or clear plastic covered in shiny tape) if it lets light in then cover it in some thing black to keep the light out and potentially interfering with the sensors.

 

If you can rule those two out then on to the code. There are two points it can go wrong, 1. if while looping around that first tight while loop you some how miss the start trigger (Unlikely but you never know) 2, you miss the end trigger for the same reasons, now this one is going to be a pain in the *albatross* with your code as there doesn't appear to be any time out to reset every thing back to normal, if this happens your code is stuck until some thing trips it.

 

I guess the way to see which of these is happening is to fire a couple of shots through it and then drop a bb down it, if you register a really (even by dropping its standards) slow shot then its getting the first gate but not the second one. if you just get a normal falling bb speed then its probably a case of the first.

 

It looks like one of the sensors isn't registering correctly and I would guess its the stop sensor, because of the range of speeds you were getting out of the drop tests at the start, the same bbs from the same height should be travelling at close to the same speed.

 

As for what you can do to fix it I am not sure, have you tried removing one of the NOPs? If that doesn't help at all you may need to look into interrupts to start and stop the clock.

 

Good luck

 

Wil

 

Ps sorry for the ramble.

[Maekl]

It is an aluminium tube and there's really no light going in. I'm going to test it in a dark room if that helps. Yes in the video you can see some funny readings, but I believe they are explained by the fact that the bb's bounce back up after dropping them in and the STOP sensor senses them and screwes up the counter. When I hold the tube in the air and then drop the bb's it very rarely happens. I have tried to blow the bb trough the barrel and it seems to register it up to 5 m/s

 

I confirmed that at least the START sensor misses the bb. I tried that I shot trough the tube and after that I blocked the STOP sensor, and nothing came to the screen.

 

The NOP's should not affect it, they are basicly short delays (0,25us) to make the speed calculation simplier.

 

But thanks I will try to make some changes to the program and see if it helps..

[Maekl]

Got this thing to work : ))

 

 

You can find the discussion here.

http://forums.airsoftmechanics.com/index.php?topic=2323.0

[Maekl]

Here is some pics.

 

 

 

 

 

 

 

This is the 2nd circuit board but its basicly the same as the last one.

[SteevoLS]

Excellent work! If you don't mind my asking, what was the final price of the parts you needed? I like the concept of mounting the sensors on the barrel of a gun instead of holding the gun up to a stationary system. 'Seems like it would be more consistent.

[Maekl]

Thanks, about 30 euros or so. : )

 

 

[wilfire]

Sweet nice work Maekl.

 

Glad to see you got it working in the end.