[LukeZ]

Hi Rongyos, I will be happy to share the project. We can create an entry for it on the Downloads page the same way we have with other user designs. In addition to your Arduino code, if you have a schematic, board files (Eagle or Gerber or whatever), and list of parts (what we call a "BOM" for "bill of materials") we can post all that as well.

Even only understanding the subtitles, your video was very clear to me!

[Rongyos]

Hi Rongyos, I will be happy to share the project. We can create an entry for it on the Downloads page the same way we have with other user designs. In addition to your Arduino code, if you have a schematic, board files (Eagle or Gerber or whatever), and list of parts (what we call a "BOM" for "bill of materials") we can post all that as well.

Even only understanding the subtitles, your video was very clear to me!

Hey Luke,

I hope its okay to attach the file to this post.

Regards
Rongyos

[LukeZ]

Hi Rongyos, yes that's ok you posted the files here. I have created an entry for your project on the Downloads page and added all the files there, along with a link to this thread as well as to your YouTube video.

I wrote a short description but if I have said anything incorrect or if you would like to modify it, just let me know!

[Rongyos]

I wrote a short description but if I have said anything incorrect or if you would like to modify it, just let me know!

Hi Luke,

I’ve corrected some values in the BOM. Please reupload the file for clarity. Also, there is a misspelling in the name of the STL file in your post (cse should be case).

regards
Rongyos

[LukeZ]

Hi Rongyos, thanks for double-checking everything. I actually found two typos! But they have been corrected, and I've also updated the BOM file.

[Rongyos]

Hi Luke!

I hope everythings well, long time no see. There is some battle unit around now, working like charm with servo recoil...but... In case of taigen recoil the fire cannon function activated after the whole recoil effects is done (when gun barrel go back to default). I assume thats because of the firing cannon function is looking for the "BACK TO DEFAULT" signal, and - how the taigen works - the board recevies negative signal until the microswitch disconnects the negative pole from battery. Question: why is it important to wait until the pin signal go back to HIGH? Sometimes the battle unit fails and restarts because of this. Is it for safety? How can I solve this problem?

Thanks
Rongyos

[LukeZ]

Hi Rongyos, I'm not sure I know which "Back to Default" signal you are referring to - is this in the Standalone IR code? Where is the code waiting for anything to go back to HIGH?

Are you using the negative signal from the Taigen connected to Pin D4 on the Arduino as the trigger to fire the cannon?

[Rongyos]

Hi Rongyos, I'm not sure I know which "Back to Default" signal you are referring to - is this in the Standalone IR code? Where is the code waiting for anything to go back to HIGH?

Are you using the negative signal from the Taigen connected to Pin D4 on the Arduino as the trigger to fire the cannon?

Hey Luke!

Sorry for not able to provide clear details. Finally I am near my computer so I can provide more details.

As the taigen mechanical recoil works: it gets negativ signal from the airsoft pin from taigen for a short period (you only have to push the transmitter joy up for a short time). The rotary gear releases a microswitch then in the recoil unit which connect the ground from the battery. The cycle is around 3 seconds, and the microswitch being pushed and disconnects the ground pole from the battery. (single banana plug from taigen). The standalone unit gets the shot signal from the airsoft pin (yellow wire) BUT the wire connected to the recoil motor - where the battery ground also connected until the microswitch close the line. (3 sec). So for 3 sec the battle unit receives LOW (because the D4 pin is INPUT_PULLUP in my case).

I checked the code again the loop is waiting for InputButton.wasReleased() then activates the FireCannon function. (I called it BACK TO DEFAULT before, i remembered the thing but not the name) BUT there is an other function you commented on it:

Code: [Select]

case BUTTON_WAIT:               
                if (InputButton.wasReleased())
                {   // A single press (short) of the button will fire the cannon
                    FireCannon();
                }
                else if (InputButton.pressedFor(2000))
                {
                    // User has held down the input button for two seconds (long press)
                    // Wait for them to release the button before proceeding
                    do { delay(10); InputButton.read(); } while (!InputButton.wasReleased());                     
                    ButtonState = BUTTON_WAIT;

 // Now you could take some other action here to occur on long button press
                    // bla bla
So I think the board wants to go to the special menu which is not set and sometimes fails itself. What do you think, is it better to modify the loop to wait for InputButton.isPressed or .wasPressed to solve the problem and force the unit to activate FireCannon function as soon as it receives the LOW signal?

Code: [Select]

/*----------------------------------------------------------------------*
 * isPressed() and isReleased() check the button state when it was last *
 * read, and return false (0) or true (!=0) accordingly.                *
 * These functions do not cause the button to be read.                  *
 *----------------------------------------------------------------------*/
uint8_t OP_Button::isPressed(void)
{
    return _state == 0 ? 0 : 1;
}

uint8_t OP_Button::isReleased(void)
{
    return _state == 0 ? 1 : 0;
}

/*----------------------------------------------------------------------*
 * wasPressed() and wasReleased() check the button state to see if it   *
 * changed between the last two reads and return false (0) or           *
 * true (!=0) accordingly.                                              *
 * These functions do not cause the button to be read.                  *
 *----------------------------------------------------------------------*/
uint8_t OP_Button::wasPressed(void)
{
    return _state && _changed;
}

uint8_t OP_Button::wasReleased(void)
{
    return !_state && _changed;
}
Thanks
Rongyos

[LukeZ]

Ok, I also found that same area of code while you were writing and I agree, I think it is a problem. That code was copied from the TCB which wants to tell the difference between short and long press of the input button, but we don't need that here. And you are correct, the result is that if the airsoft takes a long time, then the Arduino might keep waiting and waiting and never fire the canon.

Try changing that section of code to this and see if this works better:

Code: [Select]

    // PROCESS BUTTON PRESS
    // --------------------------------------------------------------------------------------------------
        switch (ButtonState)
        {
            // The BUTTON_WAIT state watches for a press of the button (or GND signal) on D4.
            case BUTTON_WAIT:               
                if (InputButton.isPressed())
                {
                    FireCannon();
                }
        }

Note that I have changed "wasReleased" to "isPressed" and deleted the "pressedFor(2000)" part and all that comes after it in this statement. All we really want to know here is if a ground signal is received.

I think I might see another problem where the reload delay is not being taken into account properly, but let's test this change first, and if that solves your problem, I will update the code and issue a release with this fix and a fix for the reload delay.

[Rongyos]

I think I might see another problem where the reload delay is not being taken into account properly, but let's test this change first, and if that solves your problem, I will update the code and issue a release with this fix and a fix for the reload delay.

Hey Luke,

Sorry for the long delay, I was working on a new board layout where users can easily connect single relay to activate the taigen / henglong airsoft/recoil microswitch which activates the cannon sound and the irritating gearbox recoil. Also, i want to make a 3d printed case for the relays to store them stacked to save some space. Attached you can see a sample how it looks when two relay modules having an affair
 (sorry for the cable spaghetti)

Regards
Rongyos

[LukeZ]

That's ok, take your time! Those sound like good improvements. When you get to the code testing stage, let me know, but there's no hurry.

[califrag]

Hi all, sorry to post on such an old topic but I've been trying to get this working and having a bit of trouble ...

I am trying to build just a small testing unit for my Tamiya M4 Sherman tank (with DMD\MF and Tamiya Battle System) to verify the working condition of the tank (and possibly make the TankIR arduino project build a standalone "artillery gun" like on WibblyWobbly's thread.

I'm using Arduino Pro Mini, TSAL6200 IR LED and have tried a few different IR Receivers such as TL1838, HS0038B and TSOP4838

So far, the "Fire cannon" switch works perfectly, and my Sherman registers the hits as expected.

However, I cannot get the Arduino to recognize and register hits from my tank cannon fire (attached is some of the serial monitor output, with these lines from Tank.cpp uncommented \ modified as such :

Code: [Select]

            Serial.println(F("IR Detected"));
            // For testing
                //IR_Decoder.decode(BattleSettings.IR_FireProtocol);
                IR_Decoder.decode();
                Serial.print(F("Decoded: ")); Serial.print(ptrIRName(IR_Decoder.decode_type)); Serial.print(F(" Value: ")); Serial.println(IR_Decoder.value);
                IR_Decoder.DumpResults();
I also tested with the "ReceiveDump" sketch of library IRRemote, and it sees some IR being detected when I fire the cannon, but it also seems like it's only detecting 1 bit.

I am compiling the TankIR sketch using Arduino IDE 2.3.7 and AVR Boards 1.8.3 and get the "Low memory available warning"

Low memory available, stability problems may occur.
Sketch uses 25064 bytes (81%) of program storage space. Maximum is 30720 bytes.
Global variables use 1852 bytes (90%) of dynamic memory, leaving 196 bytes for local variables. Maximum is 2048 bytes.

However, I also installed Arduino IDE 1.8.5 and AVR Boards 1.6.20 and while the low memory warning goes away, it still does not register the hits from my tank (same unknown/1bit output detected)

I really appreciate any suggestions or help troubleshooting this, I know it's a pretty old project so I understand if that's not really possible.

[LukeZ]

Hi Cali,

Sorry you're having problems. The IDE stuff is annoying but it sounds like you were able to resolve that by using the older 1.8.5 IDE. Note that we have had some success with certain newer IDEs, just by changing the AVR Boards to 1.6.20 (you changed both the IDE and the Boards, which is also fine). I think the last time we were looking at this we had only gotten up to IDE 1.8.13, and we got the code to compile ok with 1.8.13 just by changing the Boards. Obviously Arduino has gone way beyond that if they're up to 2.3.7 now. Still, you could try 2.3.7 with the older AVR Boards 1.6.20 and see if that resolves the low memory option, if you prefer the newer IDE.

But anyway, whatever you do, so long as you're testing this stuff out, use some combination of IDE and Boards that does not give you the low memory error, because while that is probably not the source of the specific reception problem you're having, it will definitely create other problems if it's compiling with low memory.

Now, as to the actual reception problem. From both the files you attached it does appear that it's not really reading any kind of valid signal from either of the two sketches you tried (TankIR or ReceiveDump). There are several things we need to verify.

First of all, there are two versions of the Arduino Pro Mini floating around, one is 3.3v and the other 5v. The versions from China are not always clearly marked. Although the 3.3v version can accept 5v input on the VIN pin (not the VCC which needs to be 3.3v), and it is even compatible with 5v input signals, which might lead you to believe you have the 5 volt version even though you have the 3.3v, another difference is that the 3.3v version runs at 8MHz instead of 16MHz on the 5.5v Pro Mini. I don't know exactly how this might affect the running of this project, but I don't remember anyone having tested this code on a Pro Mini and it's entirely possible it will not function correctly at the slower clock speed. So one thing you could try is to buy an Arduino Nano which is nearly the same size as the Mini, but only comes in 5v/faster 16MHz. Or if you have a Uno laying around, you could try that for testing.

The second step in troubleshooting is trying to figure out what we know does work, by isolating individual pieces and testing them alone. So for example to test whether your Sherman is really sending correctly as it should be (it probably is), we would to try firing it at another Tamiya or Tamiya-compatible tank, and seeing if that other tank registers a hit. If it did, then we could eliminate your Sherman from the list of things that are potentially the problem. If you are able to perform such a test then please do so, but it's possible you don't have a second tank, in which case we just have to assume for the moment that your Sherman is ok.

On the receiving side, you can load the ReceiveDump sketch on to your Arduino then trying to send it a signal from any kind of TV remote that you might have lying around. If the TV remote works for your TV, then we can assume it is transmitting correctly, but if ReceiveDump still isn't registering the incoming signal, then there's something wrong with your board hardware. The receivers you mentioned should all work; I know for certain that others have used the TSOP4838 with success. It's a simple connection to the Arduino, but it won't hurt to double-check your wiring all the same - make sure you have the correct pins on the receiver connected to Gnd, +5v (and make sure it's really getting 5 volts with a voltmeter), and the signal pin connected to digital pin 2 on the Arduino.

If you can test any of the above then let us know what happens and we can proceed from there.


Luke

[califrag]

Hi Luke thanks so much for the quick replies and I apologize, I should have included this additional information in my last post.

I'm using the Arduino Pro Mini 5V/16MHz, it's just a clone board from ebay but when the board is plugged in by USB (using FTDI),  I tested the VCC with multimeter and it's outputting 4.9V, so I'm fairly confident it is a true 5V board.

I do also have Arduino Nano and I ran all the same tests with IRTank sketch and ReceiveDump on the Nano with the exact same results.

With both the Pro Mini and the Arduino Nano, I used a Sony remote control (for an A/V unit) and fired it at the IR decoder. ReceiveDump received around 32bits on each "shot" and correctly identified the protocol as being from "Sony". In fact, in TankIR sketch, when I also "shoot" the IR decoder, it also sees the IR and identifies it as "Sony" protocol.

I have an Arduino UNO R4 , but I did not test it with that yet but will probably do that next.

Unfortunately I don't have another Tamiya tank at the moment to test my Sherman with, that's why I was wanting to build a little tester.

The Sherman is "brand new" and I just got it a couple months ago and built it, but one other strange thing I noticed is usually with the "IR LEDS" like on the Sony A/V remote, I can point it at the camera of my phone and see the IR beam being transmitted when I push a button. With my Tamiya Sherman, when I point my phone camera at the IR LED of the Battle system and press the Fire Cannon, I don't see the IR beam like I do with just any regular remote control..

I have some extra TSAL6200 IR LEDS do you think these will work with the Tamiya DMD\MF ? If so, maybe I will try wiring one up with a connector and plug it in and see if I have a different result using a different IR LED. I really hope the IR LED from my Tamiya battle system is not dead because it will be a pain to switch it out of the tank at this point

[LukeZ]

Ah ok, this is great information, and it sounds like you've done a lot of troubleshooting already. In fact I think you have found the problem, or anyways, on which side of the equation the problem lies, and of course it's the very thing I thought we could assume must be working (your Sherman).

Using the phone camera to look at the LED is a very good thing to do, and I should have mentioned that. I think the fact that you are not seeing the Sherman LED light up on the camera, and that fact that the TankIR and Receive Dump are both correctly registering a Sony code, lets us conclude that your Arduino board and receiver (and the TankIR code) are all working correctly.

So yeah, the next step would be to figure out what's going wrong on the Sherman side, whether it's just the LED, or (hopefully not) a faulty MFU. Yes, you can wire up one of your TSAL LEDs to the Tamiya MFU and see if that works, if so, then we can conclude your Sherman LED is burnt out. In fact I have heard of Tamiya LEDs burning out before. I don't think it's common but anyway it's not unheard of.

But if that still doesn't work, or if even the TSAL doesn't register on your digital camera, then the problem is probably with the MFU, and in that case I don't know if there's anything you can do other than see if Tamiya will replace it under warranty (I have no idea if they even have warranties), or else you'd have to buy another one, which would suck.

By the way, the IR connector on the Tamiya board is a Molex Micro-Latch 51065 series. The Molex part number for the 2-pin plug is 0510650200 and for the crimp sockets it's 0503728000. You can get them from DigiKey and other places, but I don't know what a good crimper for them would be. Maybe a generic one from Amazon would work. It would probably be easier to just splice into the existing cable.