Show Posts
Pages: [1] 2 3
1  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: July 28, 2012, 10:50:36 am
It would only take one more resistor to add a switch (the safety switch electromagnetic relay), correct?

The safety switch relay does not connect directly to the ATtiny44.  Instead, the relay controls the power to the chip Vcc (Pin 1).  To simulate this on the breadboard, I just plug and unplug the power source.

What functions were you thinking of, more firing modes or more refined logic?

A mixture of both.  The stock board has the ability to detect low voltage from the battery and indicate that the battery is low to the user.  I have not finished researching this, but I don't really have the space for it on the chip either.  It was that or presets.  For firing modes, I don't have any ramping.  I would like to include some version of it.  I'm trying to optimize the code a bit (without going to assembly) and might be able to make room for one more firing mode (fingers crossed).

Originally, I envisioned an I²C library to have it connect to other devices such as a display and scroll wheel. Crazy, I know. I shelved the idea when I realized it would probably severely impact battery life and reliability.

Crazy?  Absolutely!  But we're all a little crazy.  We've had similar ideas about adding peripherals (kill counter, ammo counter, ...).  For this, I think we would include a separate enclosure with a picatinny mount so it could store a separate battery for itself, and link up to the stock board with a cable tied to the pinouts (drawing as little current as possible to get the job done).  I'm not a hardware guy, but I think this is possible.
2  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: July 27, 2012, 09:59:57 am
Yeah, I'm sorry about the wiki.  I was trying to switch over the source code repository, but apparently google does not auto transfer what was already on the site.  I'll attempt the switch again eventually, but not for a while.

I've attached a schematic of a test breadboard that should work with our programming for the Phenom.  I need to make a few changes to it for the original Tippmann chip (it requires more pins to be pulled-up/pulled-down than my firmware), but this test breadboard should work just fine for our firmware.

The ATtiny84 is a drop in replacement for the ATtiny44 (pinouts are the same, clock is the same, etc.).  The ATtiny84 provides 8k of memory versus the 4k on the ATtiny44, but other than that, it's the same chip.  I would love to grow the firmware with additional options that I'm currently unable to fit on the ATtiny44 due to the smaller memory, but I want to keep the firmware small enough so people can use it on stock versions of the board (no soldering required).

If you do plan on soldering in a new ATtiny84, perhaps we should branch the source code for this firmware and start adding features.
3  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: July 26, 2012, 07:49:19 am
Thank you for pointing this out.  There was a problem with the google code source repository.  I've repaired the issue and the wiki should be back.
4  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 29, 2012, 06:16:39 pm
I used a different program called Fritzing.  It uses highlights on the breadboard for easy reading:

http://fritzing.org/

I especially like the auto routing capabilities between the breadboard and Schematic modes.
5  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 29, 2012, 05:47:24 pm
I tried to create a picture representation of my test board.  I think I got all the connections right.  smiley-grin

6  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 29, 2012, 11:36:37 am
The 98 pro / A5 board is not nearly similar to the x7 / Phenom family.  I disassembled it and recognized absolutely zero major components.

I agree.  My neighbor has an eGrip for the A5 and it didn't seem to be powered by a Atmel chip.  I wasn't able to get too close, but I would guess by the switches used to modify the firing modes, that it is not powered by a microcontroller.

The hardest challenge would presumably be swapping the mechanical mode on the Phenom eGrip with a semi-auto mode (or another slot for programmable firing modes, like on the APE board). Without modifications, I presume the board will either default to the programmed setting, not function on semi-auto, or not function at all. Murphy's Law tells me it's the latter...

In the Phenom board, there are three electromagnetic relays that are used to turn on the board, and sense when the trigger is pulled.  I may have been wrong in how I'm using them (it has been a burning question in my head since I started).  Out of the 3 relays, I'm utilizing 1 of them.  2 of the relays appear to be identical; they sense when the trigger is pulled.  The other relay does not appear to connect directly to the micro controller (it is used to power the board).

On the Phenom, there is a rare earth magnet in the safety switch.  When the switch is rotated to full auto, the magnet activates a relay to power on the board.  I'm not sure how an APE board is powered on for the x7.  It's possible that their board has another relay to sense the mechanical safety-switch position as well as full auto.  In other words, this may not be possible for the x7 or Phenom without modifying the hardware on the board.

I'll take another look at the relays on my board to see if one of the relays could be used to sense the mechanical safety-switch position.

As for modifying the software, it all depends on the pin-outs of the board:
Pins 5 and 7 connect to the relays for the trigger.  (their voltage goes LOW when the trigger is pulled).  I'm only using pin 5 to sense for trigger pulls.  Hopefully this matches the x7 classic.  As far as I could tell, there is no pin to control the relay that powers on the board.  It's probably connected directly to the voltage regulator to supply power to the chip.


7  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 28, 2012, 10:10:06 pm
Excellent!  Welcome aboard!

I do not have any experience with the x7 classic.  I would not recommend using this software on the x7 classic eGrip.  I'm not sure if it uses the same chip as the Phenom, so the programming here may be useless.  If you can, please take a picture of the board (as detailed as possible - all sides of the board) and we might be able to figure out if it will work.  Is your board from Tippmann, APE, or another manufacturer?

If it does use the same chip, you can buy new chips to test with at several vendors (digikey, mouser, ...).

This is the chip that goes in the Phenom:
http://www.digikey.com/product-detail/en/ATTINY44A-SSU/ATTINY44A-SSU-ND/1914708

Since the chip is rather small and difficult to test with, you can get the same chip in DIP format to fit in a standard breadboard (warning: this chip is only for testing the programming, this chip will not fit in the marker):
http://www.digikey.com/product-detail/en/ATTINY44A-PU/ATTINY44A-PU-ND/1914707

8  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 09, 2012, 09:42:04 am
Abbility to Change RATE OF FIRE (betwen 2 rates, 15 and 25 for example) directly by pressing program button

The new version 0.6 now supports Presets which will accomplish this.  The new programming allows you to configure 3 complete seperate firing configurations (firing mode, firing rate, and burst size).  To toggle through the presets, you press the tactical button when the gun is on.  The LED will flash green indicating which preset you are in (one flash for preset #1, two flashes for preset #2, and three flashed for preset #3).

Instructions for configuring the presets are on the wiki:
http://code.google.com/p/phenomx7-etrigger/wiki/Home
9  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 07, 2012, 01:59:41 pm
Wow, good catch.  I didn't think of that.  The multimeter is probably sending some voltage through to get from point A to B that might cause damage.  What about measuring Ohm's?  Would that do the same?
10  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 07, 2012, 01:41:57 pm
If you put the negative multimeter lead on the negative battery terminal, and the positive multimeter lead on the GND pin of the chip on the board, I would think the multimeter would show continuity.

I'll try this at home tonight and let you know if it works for me.
11  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 07, 2012, 12:38:23 pm
Programmable Rate Of Fire-
1 to 30
We currently support a rate of fire between 5 and 40 (as of version 0.3)

Programmable Burst-mode-
2 to 8
We currently support a burst between 2 and 10 (as of version 0.4)

Safe Burst mode –
Pulling the trigger three times in less than one second results in an X-shot burst on the third trigger pull. Each pull of the trigger in less than one second after this, results in another X-shot burst (X= 2 to 8 ).
If more people request "safe" firing modes I will implement them, however, this was the reason behind the whole project (to remove the "safe" feature).

Safe Full-Auto mode-
Pulling the trigger three times in less than one second results in full-automatic firing. Holding the trigger down on the third pull sustains this full-auto mode.
Same as above.

Auto-Response mode –
The marker fires on the pull and on the release of the trigger.
We currently support Auto-Response (as of version 0.3)

Turbo-mode –
Pulling the trigger three times in less than one seconds results in full-automatic firing at rate of 15 BPS. To sustain this rate of fire the trigger must be pulled at least once a second.
Similar functionality can be achieved by increasing your Rate Of Fire setting on Full Auto firing mode.  We do not require pumping the trigger to keep the gun firing.  If more people request this feature, I can implement it.

Semi-Auto –
This mode is the same as selecting the F firing mode with the selector switch (one pull/release of the trigger fires one time).
This is the same functionality as switching the selector switch to the F firing mode and therefore has not been implemented.  If more people request this feature, I will implement it.

Burst mode –
The marker fires an X-shot burst on each trigger pull (X= 2 to 8 ).
We currently support a burst between 2 and 10 (as of version 0.4).  To configure, select three round burst firing mode and adjust the burst size between 2 and 10.

Full-Auto mode –
Pulling the trigger results in full-automatic firing. Holding the trigger down on the first pull sustains this full-auto mode.
We currently support Full Auto (as of version 0.3).

X mode –
Pulling the trigger results in full-automatic firing. Holding the trigger down on the first pull sustains this full-auto mode. The Rate of fire (ROF) will gradually increase depending on how long the trigger is held (10 to 25bps).
We do not currently support full auto ramping.  If more people request this feature I will implement it, however, I have a few design changes I would implement instead.  I did not like the YouTube demo of this feature.

Super Response mode – aka A.D.A.M. mode
The marker fires an X-shot burst on each trigger pull and on the release of the trigger (X= 2 to 8 ).
We do not currently support Auto Response Burst firing mode.  My opinion on this is the trigger would start to feel heavier latency as the gun would be in the middle of firing while you either pull or release the trigger.  It is incredibly easy to fully saturate your gun's mechanical limit of rounds per second with 3 round burst alone.  However, if more people would like this feature, I will implement it.

Abbility to Change RATE OF FIRE (betwen 2 rates, 15 and 25 for example) directly by pressing program button
I definitely like this idea.  I will put this on the list to implement.

Thank you for your ideas!  Keep them coming!
12  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 07, 2012, 09:14:32 am
...is there a way to backup original firmware?

Unfortunately, there is no way to backup the original firmware.
13  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: June 06, 2012, 01:36:47 pm
Hello mikedehaan, any news about your firmware?

Yes!  I post updates for the firmware at the google project wiki.  A new version was uploaded last night.  Check it out here:

http://code.google.com/p/phenomx7-etrigger/wiki/Home

What things I need to flash my phenom with your firm?

Correct me if I'm wrong:

1) ATTINY44A-PU
http://www.ebay.com/itm/2x-8-bit-Microcontroller-ATTINY44A-PU-/221023275589?pt=LH_DefaultDomain_2&hash=item3376038a45

You do not need to buy a chip (unless you want to develop for the project).  The instructions on the wiki (the link above) will show you how to apply the new firmware directly to the chip inside your eGrip without desoldering.



This programmer looks like it will do the job, but it quite a bit more expensive than what you will need.  The programmer I used was:

http://www.amazon.com/SainSmart-Programmer-ATMEL-ATMega-ATTiny/dp/B0051SRZWC/ref=sr_1_1?ie=UTF8&qid=1338268631&sr=8-1

Though you can find cheaper (eBay).  Just make sure it support ISP, is supported by AVRDUDE, and is supported by your Operating System.  It would be nice if it supplies 5v power.

3) Your HEX File

New versions of the program are uploaded to the following link:

https://code.google.com/p/phenomx7-etrigger/downloads/list

I need desolder the original chip from my board? or exist the posibility to program it directly in the board? Or is read only?

No, you do not need to desolder the chip from the board.  You can directly program the chip on the board.  The chip is writable, but must first be erased.  There is no way to backup the existing manufacturer's program, so USE AT YOUR OWN RISK.  There is no turning back once you install this software.

Good luck, and keep asking questions if you have trouble.
14  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: May 27, 2012, 03:03:45 pm
Hahaha, well...my plans were foiled.  I just tested out the new build in the full system and found that you cannot hold the trigger down and switch from the "F" position to "FA" (to turn on the board).  So I switched the programming to use the pushbutton rather than the trigger to enter programming mode.

Other than that, I made some tweaks to Auto-Response and the new build mostly works.  I say mostly because successBlink is not working for some odd reason.  I'm baffled why it is not working on the board when it does on the testbed, but I'll figure that out later.  successBlink is supposed to blink green + red three times to indicate that your changes have been saved to the EEPROM.

I'm starting a google code project with everything I do.  I expect to put documentation, pictures, videos, etc up there.

http://code.google.com/p/phenomx7-etrigger/

If you'd like to contribute to some of the documentation etc, let me know.  I think all I need is an email address of yours to set you up.

From this point forward, new code and builds will be posted there.
15  Topics / Device Hacking / Re: Dumping firmware/software...and/or reflashing?? on: May 27, 2012, 11:47:36 am
I have a Phenom X7.   I decided to change the programming around a little because I don't want to have to whip out a special tool to get to programming.  I was planning on using the button for "reset to factory default" (e.g.  on startup, hold the button for 5 seconds to reset the board).

Also, just a warning, I have not tested this latest code on the actual board yet.  I hope to get to that this weekend.  I'm mostly worried about the red LED.  Everything else has already been proven.
Pages: [1] 2 3