Sorry to reach you via this way; but you are hard to get a hold of ;)

[insensitiveclod]

Hi. Sorry top put this as a message in an issue-tracker, but I have been trying to get a hold of you for the last 2 weeks now or so ;)

Your forum (on ltascet.ru) doesnt allow registration of new users; it complains that I have to fill in a CAPTCHA, but there is no CAPTCHA on the registration-page.

Anyway; Perhaps you've received my earlier mail to you already, perhaps not; but I am busy with helping to develop your LTASCET project. I have created a fork under https://github.com/insensitiveclod/LTAscetic and i have translated all the comments in the code of the release_3_1 version.

I am busy with a way to translate the LCD-messages on the screen so that you can choose your language at compile-time.

To test your version, I am looking for PCB's of the main unit and of the sensor-boards. Do you sell any of the ones you might have left over after your last order ?

I am also trying to get a couple of (original) MILESTAG boards to test if your system works with that system perfectly too or not.

Let me know if you're interested in my work/translations. I would love to help make your project easy for english-speaking people too. It's been a lot of fun translating i2c-related EEPROM-transfer code from russian to english; i've re-learned a lot about TWI ;)

Hope to hear from you. contact@sociallife.org

[PingvinOpenTag]

Вторник, 4 июня 2013, 7:12 -07:00 от insensitiveclod notifications@github.com:

Hi. Sorry top put this as a message in an issue-tracker, but I have been trying to get a hold of you for the last 2 weeks now or so ;) Your forum (on ltascet.ru) doesnt allow registration of new users; it complains that I have to fill in a CAPTCHA, but there is no CAPTCHA on the registration-page. Anyway; Perhaps you've received my earlier mail to you already, perhaps not; but I am busy with helping to develop your LTASCET project. I have created a fork under https://github.com/insensitiveclod/LTAscetic and i have translated all the comments in the code of the release_3_1 version. I am busy with a way to translate the LCD-messages on the screen so that you can choose your language at compile-time. To test your version, I am looking for PCB's of the main unit and of the sensor-boards. Do you sell any of the ones you might have left over after your last order ? I am also trying to get a couple of (original) MILESTAG boards to test if your system works with that system perfectly too or not. Let me know if you're interested in my work/translations. I would love to help make your project easy for english-speaking people too. It's been a lot of fun translating i2c-related EEPROM-transfer code from russian to english; i've re-learned a lot about TWI ;) Hope to hear from you. contact@sociallife.org — Reply to this email directly or view it on GitHub .

Hello ! Sorry for my bad English! I am very happy to show interest in the project from your side ! Unfortunately, most do not have enough time sometimes , sometimes the knowledge to build it right . Site ( and forum ) I did not . The site, unfortunately, are in poor slstoyanii , but we will try to rectify the situation soon . Of course, it would be just velekolepno if you help to translate the comments and technical documents in English! The project develops ! Already running a wireless headband via bluetooth modules !

If you need a set of printed circuit boards for assembly of the device - I can send them to you . Only it probably will be for a long time ... I can you open access to the repository and LTAscet

[insensitiveclod]

Content preview: > Hello ! Hi! > Sorry for my bad English! [...]

Content analysis details: (-1.0 points, 5.0 required)

pts rule name description

---

-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP

Hello !

Hi!

Sorry for my bad English!

No problem. My Russian is much worse!

I am very happy to show interest in the project from your side !

Nice! I am glad you might be able to have me be helpful.

Unfortunately, most do not have enough time sometimes , sometimes the knowledge to build it right . Site ( and forum ) I did not .

No problem. I just wanted to tell you about the CAPTCHA problem so that you know why there is no other people on the forum there yet.

The site, unfortunately, are in poor slstoyanii , but we will try to rectify the situation soon .

Take your time. no rush.

Of course, it would be just velekolepno if you help to translate the comments and technical documents in English!

I have just complete all (used) comments today. All are now translated to english, but they will need to be checked. While translating, I learned more about the code and am sure some translations need to be fixed.

I was thinking about writing some documentation about how the system is put together. Which parts to what and so on. LCD, Health-leds/headband/sensor, keypad, TouchMemory key, etc.

The project develops ! Already running a wireless headband via bluetooth modules !

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.

If you need a set of printed circuit boards for assembly of the device - I can send them to you .

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

Only it probably will be for a long time ...

I know; but that is allright.

I can you open access to the repository and LTAscet

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

InsensitiveClod 'Arnd Marijnissen'

— Reply to this email directly or view it on GitHub https://github.com/PingvinOpenTag/LTAscetic/issues/1#issuecomment-18912660.

[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. If you need a set of printed circuit boards for assembly of the device - I can send them to you .

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

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 smatfona

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.

[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.

[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.