Sorry - what is there and screwed it up (the message).

[PingvinOpenTag]

I saw that, yes! Very interesting indeed! Personally, I'm thinking of adding a way to communicate to a smart-phone (via Bluetooth or perhaps via audio (http://www.slideshare.net/Sudar/transfering-data-using-audio-signal-in-android) to send 'scoring' info to the phone which can then send the info about 'where is player' 'how much did he shoot' 'who hit him', etc. to a central server. This central server would allow later game-replay and, of course, total scores, etc. Some of the code for that was already written/designed by the London Hackerspace. Perhaps I can re-use some of that.

Yes!
I want this!
Let's do it!
Transmit data over Bluetooth - no problem!
Just have to play with a wire headband.
You can also make all the settings from smatphone.

That would be wonderful! Let me know prices, etc... and i'll buy enough for 3 - 4 sets

No price!
What the bourgeois manners? :-))

You just printed circuit boards?
You will be able to solder the device?

I would of course appreciate that; but I think I will ask you to 'pull' files from my fork into your repository first so you can test the changes and see i didnt break anything. Also, I only worked on the 3.1 version; none of the other directories have been touched by me. I am thinking about what is best: make a 'main' code-segment and a 'branch' for each 'hardware release' or so... Or support different hardware-releases via IFDEF's in code. Of course 'my' release 3.1 can be used for further development of '3.2+' or '4.0... etc' but it has to be properly tested first. If you have time, could you compile it in your WINAVR and see if everything works well on your hardware ? It compiles well here in my AVR-GCC on Linux; but I cannot test if the project works correctly. NOTE: i have also translated the 'texts' in 'commands.h' to english. I am not sure, but I think this will work because your USART-protocol uses the labels , which I did not change, right ? Would be interesting to see how well/bad that works on your side ;) The next things I will start doing is to work on some things i found in the code that I marked with 'FIXME'. Then I will do code-cleanup. - Add descriptions of all the functions/etc and get rid of double declarations. I believe 'global_variables.c' is corrently not used? Do you want to move all global variable definitions TO that file ? or have you just gotten rid of the file ? ;) Let me know , perhaps I can help with that. - I will try and make all the code 'look nice'; I intend to do 4-space TAB-width and get all the functions properly indented. Then I will start on translation of LCDTEXT messages; probably by creating a 'lcd_texts.h' file that contains DEFINES for all the texts for on the display, with IFDEF LANG=RU, IFDEF LANG=EN... etc.. to choose between languages at compile-time. Does this sound like a good way to do it ? If you have any preferred direction you want to go first, let me know; perhaps I can help with that. Any ideas about what i can do are welcome. Let me know if or when you could try out my fork and see if it works well; that will help me be confident that I did my work well. Will let you know of my progress! Till soon

I will compile your version and give the video report!
Under Linux I have tried Eсlipse and AVR-plugin - it works, the firmware is compiled.
Not quite sure about global variables (due to problems with the language, apparently). They are used. Just put them in a separate file for convenience.
I also thought about using IFDEF, but little know precompiler.
If you can help him to understand - will be grateful.

Still plan to switch to Atmega644 - it has an additional timer. This will generate hardware IR F0, and change the duty cycle - as Miles systems.

[insensitiveclod]

You can reach me, directly, via [email protected] if you'd like. That's perhaps easier than communicating via github issues. But I will reply to the 'mail' here for now ;)

The reason i would like to do it without bluetooth but with some technique (like sound) is that it keeps it all a lot cheaper and easier to connect (no bluetooth-synching blabla). But bluetooth is certainly usable. It will cost a bit more battery.

I would like to have PCB's to work on testing your/my code and any additions, myself. I can etch single-sided stuff myself, but double-sided SMD is just too much work to etch. If you have PCB's spare that i can get/buy/trade, that would be great!

I have the tools and the materials (SMD resistors, atmega32au's, etc) to put parts on the PCB's; this shouldnt be too much of a problem.

I personally havent tried Eclipse ; i use vim/gedit/etc.. but i will try it out!

I will check the global_variables issue myself a bit closer, first. No worries :)

About IFDEFs; i'll try some stuff out and see if it will work and show you to see if you like it ;)

I see the 644 also uses TQFP44 package; is it drop-in replacement or do you need new PCB ? Why not Atmega2560 and have enough I/O ports for... well... anything ;) (ok... TQFP100 is not nice to solder... I know the reason ;)

Also: I contacted the guy who wrote the code in i2c_eeprom on his nagits.wordpress.com forum and asked him about the copyright. He replied that it is public domain; so I will add his name to the comments there and also the license (public domain). I will do that in a couple of days time; the weather here is GREAT and my garden needs some work, first ;)

Hope your summer is also starting nice ;)

Arnd

[PingvinOpenTag]

I would like to have PCB's to work on testing your/my code and any additions, myself. I can etch single-sided stuff myself, but double-sided SMD is just too much work to etch. If you have PCB's spare that i can get/buy/trade, that would be great!

No problem!
Your address?
The only thing - I can not send a lot of sensors (distributed almost everything needs a new order). But I will send 4 pieces - for the test should be sufficient.
Just'll send printed circuit boards 3 release - they are one-sided, a little different from the 3.1 and have JTAG, which is useful for debugging.

I see the 644 also uses TQFP44 package; is it drop-in replacement or do you need new PCB ? Why not Atmega2560 and have enough I/O ports for... well... anything ;) (ok... TQFP100 is not nice to solder... I know the reason ;)

If the solder Atmega644 to the existing circuit board and a little to fix the code (initialize UART - two of them at 644) - will work, but not as much as I want. To use the hardware capabilities of additional timer to generate the carrier frequency IR circuit board to be slightly corrected. But it is not difficult.

Also: I contacted the guy who wrote the code in i2c_eeprom on his nagits.wordpress.com forum and asked him about the copyright. He replied that it is public domain; so I will add his name to the comments there and also the license (public domain). I will do that in a couple of days time; the weather here is GREAT and my garden needs some work, first ;)
Hope your summer is also starting nice ;)

Great!
The weather is still cool, but the weekend promises to 30 degrees Celsius. Also go to our garden (in Russian - dacha). :-)