[Rongyos]

Ok, I understand now. You're right, these Chinese MFUs often prefer to toggle the ground signal rather than the positive, so you were correct to use the button input D4 (which triggers when held to ground) rather than the 5 volt input A0 (which triggers when brought to 5 volts). Your friend correctly identified the problem with the 5v input which was left floating, and disabled it by setting it to OUTPUT. That works fine. For others reading this, you can do the same, or as mentioned before, add a resistor between A0 and ground if you don't want to change the code.

Hi Luke!

My happiness was not long. Unfortuntely, the phantom firing is not visible on the serial monitor, but still there.  I have another idea with this, can you please put a code which activates the IR emitter pin a little bit later? I mean, the ir pin activated or start to wait the cannon function after 2 secs from bootup.
I put a button state in every initial bootup but its value 1 every time.

IDK why this dump the battle info 3 times after uploading the code ... :/

Code: [Select]

18:27:40.756 -> Button State: 1
18:27:41.021 ->
18:27:41.021 -> ---------------------------------------------
18:27:41.021 -> BATTLE INFO
18:27:41.021 -> ---------------------------------------------
18:27:41.021 -> Is Repair Tank?   No
18:27:41.021 -> Fire Protocol:    Tamiya
18:27:41.021 -> Hit Protocol 2:   Heng Long
18:27:41.021 -> Repaired by:      Clark Repair
18:27:41.021 -> Send MG IR Code:  No
18:27:41.021 -> Accept MG Damage: No
18:27:41.021 -> Damage Profile:   Tamiya Spec
18:27:41.021 -> Weight Class:     Medium
18:27:41.021 -> (6 cannon hits, 5.0 sec reload, 20.0 sec recovery)
18:27:41.064 ->
18:27:41.064 ->
18:27:41.064 ->
18:27:51.406 -> Button State: 1
18:27:51.671 ->
18:27:51.671 -> ---------------------------------------------
18:27:51.671 -> BATTLE INFO
18:27:51.671 -> ---------------------------------------------
18:27:51.671 -> Is Repair Tank?   No
18:27:51.671 -> Fire Protocol:    Tamiya
18:27:51.671 -> Hit Protocol 2:   Heng Long
18:27:51.671 -> Repaired by:      Clark Repair
18:27:51.714 -> Send MG IR Code:  No
18:27:51.714 -> Accept MG Damage: No
18:27:51.714 -> Damage Profile:   Tamiya Spec
18:27:51.714 -> Weight Class:     Medium
18:27:51.714 -> (6 cannon hits, 5.0 sec reload, 20.0 sec recovery)
18:27:51.714 ->
18:27:51.714 ->
18:27:51.714 ->
18:28:27.490 -> Button State: 1
18:28:27.753 ->
18:28:27.753 -> ---------------------------------------------
18:28:27.753 -> BATTLE INFO
18:28:27.753 -> ---------------------------------------------
18:28:27.753 -> Is Repair Tank?   No
18:28:27.753 -> Fire Protocol:    Tamiya
.... cannot copy more lines ----> Rongyos

Referring the reload led notification, unfortunately its not working. If I set it true its on all the time, until it gets a hit, making hit notification effect but reload notification is not active.

MOD: I just realized I can shoot the cannon after being destroyed (during recovery time). It is not desirable, so I just modified the cannon.ino with this simple stuff (tested, working)

Code: [Select]

// CANNON FIRE
// ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------>>
void FireCannon()
{
    if (!Tank.isDestroyed) // Check if the tank is not destroyed
    {
        if (Tank.CannonReloaded()) // Only fire if reloading is complete
        {
            if (Tank.isRepairTank())

[LukeZ]

My happiness was not long. Unfortuntely, the phantom firing is not visible on the serial monitor, but still there.  I have another idea with this, can you please put a code which activates the IR emitter pin a little bit later? I mean, the ir pin activated or start to wait the cannon function after 2 secs from bootup.
I put a button state in every initial bootup but its value 1 every time.

Ok, up to now I have not thoroughly re-acquainted myself with the entirety of this project, and making changes until I've done so is always a mistake. I've spent a good deal of time today looking through everything, and hopefully I have a better idea of what is going on.

Ultimately what your friend did in setting the direction of the positive trigger pin to OUTPUT will not fix the phantom firing issue, though it might have improved it. The problem is we still have an interrupt defined on this pin which is causing the problems.

The solution is to create another setting in A_Setup.h where the user can specify whether they want to use this input or not. I've made it the first setting in that file, and by default it will be false (disabled):

Code: [Select]

    #define USE_5VOLT_TRIGGER       false

When false, the interrupt will not be created and the setup of the pin will be handled appropriately.

There is no need for a setting for the negative-input/pushbutton trigger, that one can always be active. It uses an internal pullup so isn't subject to stray voltages, also it doesn't use a hardware interrupt procedure and should ignore anything other than a very intentional signal.

Referring the reload led notification, unfortunately its not working. If I set it true its on all the time, until it gets a hit, making hit notification effect but reload notification is not active.

This was an error on my part. I've corrected it and it should work now. I also increased the blink time a little bit to 400mS.

MOD: I just realized I can shoot the cannon after being destroyed (during recovery time). It is not desirable, so I just modified the cannon.ino with this simple stuff (tested, working)

Wow, great catch! I can't believe I missed that. In fact the same bug is present on the TCB, I will fix that too.


The GitHub is now updated with all these changes. I hope now everything will work, please let me know your results.

[Rongyos]

The GitHub is now updated with all these changes. I hope now everything will work, please let me know your results.

Hi Luke!

Thank you again for you quick support. Unfortunatelly those mods are not working. The notify led is acting strange, when I shot the cannon some time (usually 4-5 times) the arduino reset itself and stay in a strange state ("L" board led is on, relay is on). You can see the pic what I mean. When I plug in the USB to see on the serial monitor what happens, this issue is not appearing (can it be a power supply issue? If yes, why servo, recoil and hit notification working?) MOD: well, in the pic the notification led is not on (3mm red one). But most of the time it freezed at staying on

When I only tried the 5V trigger mod of yours there wasn't any different operation then before. Phantom firing is still there. BUT I realized 2 things, maybe connected.

1. when I power on the arduino, there is ~20degree turn in the servo, like it start firing then stops. But, it does a firecannon function and everything works fine after that.

Code: [Select]

08:17:47.916 -> ---------------------------------------------
08:17:47.916 -> BATTLE INFO
08:17:47.916 -> ---------------------------------------------
08:17:47.916 -> Is Repair Tank?   No
08:17:47.916 -> Fire Protocol:    Tamiya
08:17:47.916 -> Hit Protocol 2:   Heng Long
08:17:47.916 -> Repaired by:      Clark Repair
08:17:47.916 -> Send MG IR Code:  No
08:17:47.916 -> Accept MG Damage: No
08:17:47.916 -> Damage Profile:   Tamiya Spec
08:17:47.916 -> Weight Class:     Medium
08:17:47.916 -> (6 cannon hits, 5.0 sec reload, 20.0 sec recovery)
08:17:47.916 ->
08:17:47.916 ->
08:17:47.916 ->

2. when the arduino is on and I push the reset button, the "setup" is incomplete (or cannot do the loop, IDK what happens) and relay stays in and you can see the servo do the same thing which I wrote in the point 1. I attached a video, it is showing what happens.

I dont know, but maybe the in the Tank.ino there is code part which is waiting for the initial cannon fire to go to the main loop.

[LukeZ]

Hi Rongyos,

At this point there are so many different symptoms which don't seem to have any relation to each other, that it is hard to say what is going on.

If the board board is reseting/freezing/locking, or just in general acting bizarre (not completing the serial statements, erratic servo behavior, etc...) something is not right, but yet I experience none of these on my end. So there are two possible explanations:

1. Possibly we are still struggling with a compiler issue. I kind of doubt it, but if you want to replicate my setup I am using Arduino IDE version 1.8.13 with the AVR Boards set to 1.6.20. We already discussed changing the boards to 1.6.20, but maybe there is a difference with the compiler itself. You could try downloading and installing 1.8.13 from this link, and again make sure the AVR Boards is set to 1.6.20, and see if that improves anything.

2. The second option, is that you are using modifications to the code that are causing problems, or there are electrical issue with your custom board. Those are things only you can troubleshoot, but through a process of elimination it is still possible to reduce the number of possibilities until you find the culprit.

I think you should try the sketch in its stock form, unmodified, on your Nano without your carrier board, powered by USB. You can attach the LEDs and servo directly to the Nano using jumper cables. It would even be wise to remove the Heng Long or whatever MFU you are using, and instead trigger with a button or just by holding a wire from D4 to ground.

I have even attached a Hex file below that I have compiled on my computer, and it works flawlessly here, at least for firing the cannon (I have no means of testing IR reception right now). All settings in this compiled Hex are at default, meaning the 5v input is disabled. I can fire the cannon time and time again and the servo always responds correctly, the IR is always sent, the reload notification LED always blinks, and all the serial statements are complete and accurate.

It is true that when the Arduino first boots up, the servo may move a little bit. This is normal and unavoidable. But once running, the servo shouldn't do anything unless you fire the cannon.

Honestly, when I watch your video, I don't really see anything out of the ordinary. Maybe the relays are acting strange, but the relays are not part of my sketch, so I don't know anything about that. I don't see the reload notification LED blinking, so either that is not enabled in Setup, or else it is not connected to the Arduino, I don't know. But when you fire the cannon, I do see the recoil servo working, and the IR LED transmitting.

In summary, the only way to solve any technical problem of this kind is to simplify everything down the absolute minimum until you arrive at a state where things work as they should. Only then can you begin to make changes, one at a time, testing at each step, until a problem occurs. Then you know what the problem is.

[Rongyos]

Hi Rongyos,

At this point there are so many different symptoms which don't seem to have any relation to each other, that it is hard to say what is going on.

If the board board is reseting/freezing/locking, or just in general acting bizarre (not completing the serial statements, erratic servo behavior, etc...) something is not right, but yet I experience none of these on my end. So there are two possible explanations:

1. Possibly we are still struggling with a compiler issue. I kind of doubt it, but if you want to replicate my setup I am using Arduino IDE version 1.8.13 with the AVR Boards set to 1.6.20. We already discussed changing the boards to 1.6.20, but maybe there is a difference with the compiler itself. You could try downloading and installing 1.8.13 from this link, and again make sure the AVR Boards is set to 1.6.20, and see if that improves anything.

2. The second option, is that you are using modifications to the code that are causing problems, or there are electrical issue with your custom board. Those are things only you can troubleshoot, but through a process of elimination it is still possible to reduce the number of possibilities until you find the culprit.
[...]

In summary, the only way to solve any technical problem of this kind is to simplify everything down the absolute minimum until you arrive at a state where things work as they should. Only then can you begin to make changes, one at a time, testing at each step, until a problem occurs. Then you know what the problem is.

Hi Luke,

I did some experiment with / without my motherboard; with your hex and with my hex also.
I realized that when I tought the arduino was freezed there were 2 option:

1. It wasn't, but I was 1d10t and did not set the relay pin default as "HIGH". So when I switch on the arduino the relay was always on (led is on) until I shot the cannon. Now, I made a simple digitalwrite HIGH command in the void setup and now, everything is working right

2. there WAS a freeze. But it is a hardware issue. I think during the experiments I burnt out the IR emitter transistor or IDK, but when I try firing now, it fires 1 or 2 and the arduino is freezing. When I remove the IR LED (only the led) there is no issue anymore. Strange, there wasn't this issue before I could make a lot of cannon fire with this PCB.


I have good news (?). The whole phantom firing is caused by the Taigen MFU. Finally I found an 5v BEC, krimped some connector and with this stable power supply (I mean the Taigen probably also stable but not the airsoft pin which I use for activate button firing) there is no phantom firing, only the servo positions itself to its home pos. SO the code was good regarding this (your and mine too). With my board, with relay, with my mods in code etc....

But, when I connect it to the MFU and power it on (via the MFU PSupply) it does a phantom firing. I tried to disconnect the airsoft wire and power it on by the MFU and it was fine, worked correctly without phantom firing (I should probably make a hotkey in windows to write "phantom firing" ). I assume the Taigen "switch on" this pin later. Or (worst case scenario) it is always on LOW? (When I put digitalRead its always said it is 1 (high, right?)

Can you guide me out of this mess?

[LukeZ]

Hi Rongyos,

Now we are making some good progress!

2. there WAS a freeze. But it is a hardware issue. I think during the experiments I burnt out the IR emitter transistor or IDK, but when I try firing now, it fires 1 or 2 and the arduino is freezing. When I remove the IR LED (only the led) there is no issue anymore. Strange, there wasn't this issue before I could make a lot of cannon fire with this PCB.

This is good information. If you damaged your LED, or maybe shorted it, you need to try a new one and see if that fixes the problem. Or like you say, maybe the transistor is damaged and needs to be replaced. At least you know there is a problem somewhere with this part of the circuit. If you want to post your schematic, components list and board design I'd be happy to take a look at it.

But, when I connect it to the MFU and power it on (via the MFU PSupply) it does a phantom firing. I tried to disconnect the airsoft wire and power it on by the MFU and it was fine, worked correctly without phantom firing (I should probably make a hotkey in windows to write "phantom firing" ). I assume the Taigen "switch on" this pin later. Or (worst case scenario) it is always on LOW? (When I put digitalRead its always said it is 1 (high, right?)

You are correct, if digitalRead returns 1 that means HIGH. I'm certain the Taigen MFU keeps this pin HIGH except when the airsoft is fired, at which point it is held to Ground, but that doesn't mean there couldn't be some "noise" or a very brief signal on this pin when the Taigen starts - not long enough to activate an airsoft unit, but long enough for the Arduino to detect it and fire the cannon.

Now that I am thinking about it, it is also likely the voltage of this pin from the MFU, when the airsoft is not active, is greater than 5 volts. Of course the Nano can be damaged with input voltages higher than 5 volts, so this could also be a source of problems. You should try to measure this pin from the Taigen MFU with a voltmeter. If it is greater than 5 volts, there are ways to protect the Arduino, but we need to know what the voltage is.

It would also be good to check some other outputs on the Taigen, there are two more options I can think of: the flash trigger, and the IR port. I don't have a Taigen to test and my memory is not perfect, but I believe the flash pins were 5 volts. If so, that would be a better choice to connect to the Arduino.

So those are some things to try, but already like I say you are making good progress!

[Rongyos]

Hi Luke!

I didn't check the obvious

You are correct, if digitalRead returns 1 that means HIGH. I'm certain the Taigen MFU keeps this pin HIGH except when the airsoft is fired, at which point it is held to Ground, but that doesn't mean there couldn't be some "noise" or a very brief signal on this pin when the Taigen starts - not long enough to activate an airsoft unit, but long enough for the Arduino to detect it and fire the cannon.

So every time at least 1.9V is there in this pin. BUT! When I checked this pin switched off (fortunately my switch is disconnecting the + wire) connecting multimeter to battery +  and airsoft pin it was around 7V visible (not much less then the battery actual voltage *DOUBLECHECKED it was 6,64 - 6,62Volts). When switching on the MFU its dropped from 7V to 1.99V and stayed there until I (I mean, my dear wife who helped me) fired the tank and it was 7.04V again (which is the actual battery voltage)

Now that I am thinking about it, it is also likely the voltage of this pin from the MFU, when the airsoft is not active, is greater than 5 volts. Of course the Nano can be damaged with input voltages higher than 5 volts, so this could also be a source of problems. You should try to measure this pin from the Taigen MFU with a voltmeter. If it is greater than 5 volts, there are ways to protect the Arduino, but we need to know what the voltage is.

I attached a schematic. Please ignore the voltage regulator and any other stuff connected to it because it is my "future" board. I dont have the current one because I overwrote it
Please see the blue ugly stuff, the 5V is supplied by taigen receiver connector (yes it has opportunity to connect aftermarket receivers and therefore TX-es to is. This connector provides 5,02V so I using it)


Unfortunatelly no other pin which provides 5V continuously. According to the schematic the IR connector is 5V but jI didnt get 5 volt from this pin, only 4.3 at max. Servo was not working with this.

It would also be good to check some other outputs on the Taigen, there are two more options I can think of: the flash trigger, and the IR port. I don't have a Taigen to test and my memory is not perfect, but I believe the flash pins were 5 volts. If so, that would be a better choice to connect to the Arduino.

No, those are not activated until receiving a signal from a microswitch (it is located in the airsoft or recoil unit and pushed mechanically by those units). The initial triggering signal is from the airsoft, anyway Or.... maybe that should be solution if I connect the airsoft signal to the microswitch pin and then, the MFU triggers the gun fire function then sends out the 5V to IR. If so, I have to redesign my board again, and order it from pcb manufacturer :'(

[LukeZ]

So every time at least 1.9V is there in this pin. BUT! When I checked this pin switched off (fortunately my switch is disconnecting the + wire) connecting multimeter to battery +  and airsoft pin it was around 7V visible (not much less then the battery actual voltage *DOUBLECHECKED it was 6,64 - 6,62Volts). When switching on the MFU its dropped from 7V to 1.99V and stayed there until I (I mean, my dear wife who helped me) fired the tank and it was 7.04V again (which is the actual battery voltage)

Ok, this is interesting, and I believe explains the "phantom firing" that you experience. On a 5 volt Arduino like the Nano, the documentation says that any signal over 3 volts is considered HIGH (1) and any signal less than 1.5 volts is considered LOW (0). In between 1.5 and 3 volts is where the pin switches from one state to another, and we can't  predict exactly whether the Arduino will read High or Low.

If I understand your description correctly, the Taigen airsoft pin initializes at 1.9 volts when the MFU is turned on, which is right in the in-between range on the Arduino, and sometimes the Arduino is interpreting this as Low and firing the cannon. After the first cannon fire of the Taigen, this pin reverts to +V Batt as we would expect (except at the moment when the cannon is fired, in which case I assume it must be held to Ground. Probably a better test would have been to connect your multimeter black wire to Ground, and the multimeter red wire to the Taigen airsoft pin.)

Anyway, there are two problems here. One is the fact that (at least after the first cannon fire) the Taigen airsoft pin rests at close to +V Batt, which is higher than the 5 volt limit of the Arduino pins. The easiest way to solve this is to use a voltage divider, I have attached a picture below. It is created with only two resistors so is easy to do. The absolute value of the resistors is not as important as is the ratio between them. I chose 3.3k and 4.7k because they are common values and give us a ratio that will cut the input voltage by about 40%, so 7 volts input will become something closer to 4 volts on the output, this will still be read as High by the Arduino, but it won't exceed the 5 volt input limit. This ratio will protect the Arduino even if you use a fully charged 2S LiPo that could be as high as 8.4 volts (will be divided down to 5 volts).

However, there still remains the second problem, which is that on startup the Taigen airsoft pin is basically in a low state, and that causes phantom firing on the Arduino until you fire the Taigen and only then does the Taigen begin to act in a reasonable way. I don't see an easy solution to this problem. It is bizarre that the Taigen acts this way, but I have come to expect bizarre behavior from Chinese electronics, and sadly this behavior is not what we want.

No, those are not activated until receiving a signal from a microswitch (it is located in the airsoft or recoil unit and pushed mechanically by those units). The initial triggering signal is from the airsoft, anyway Or.... maybe that should be solution if I connect the airsoft signal to the microswitch pin and then, the MFU triggers the gun fire function then sends out the 5V to IR. If so, I have to redesign my board again, and order it from pcb manufacturer :'(

You're right, I forgot! The Taigen does require that physical switch to be activated by the airsoft/recoil unit before it will do the Flash and IR. That is annoying. Yes, I suppose you can try your suggestion, and you can certainly at least do a test without a new PCB, just connect some temporary wires. The only thing I am not sure of is what the Taigen MFU expects from the trigger switch - is it expecting a high or low signal? And even if it is expecting a low signal, maybe it too will be confused by the 1.9 volts from the airsoft pin at startup, so you might end up with phantom firing anyway. But I guess you'd get the phantom fire out of the way the instant the Taigen is powered up, and in that case possibly a delay could be added to the Arduino to ignore it.

Only some testing can answer these questions. I'm sorry I don't have any of this to try on my end, but let me know what you discover.

[Rongyos]

Only some testing can answer these questions.

Hi Luke!

I can say that testing went good. In my case R1 = 2.4K; R2 = 10k. Now it has 1,3V at resting state and 5,28 when activated at charged 2cells liion. I think this is now good to go

Thanks
Rongyos

[LukeZ]

Very good! I suppose that does not solve the initial firing of the cannon when the Taigen MFU first powers up. I wonder if you tried your suggestion of connecting the airsoft pin to the airsoft/recoil switch? Or is it just something that will have to be accepted and lived with?

[Rongyos]

Very good! I suppose that does not solve the initial firing of the cannon when the Taigen MFU first powers up.

Yes, it solved the phantom firing.
Also I tried the airsoft-microswitch connect to try before, but somehow thats not worked. I had to wait for the big bunch of resistors I purchased.

Rongyos

[LukeZ]

Ah, well that's interesting. Perhaps the resistors in the voltage divider are acting as a pull-up circuit that is preventing the Taigen pin from floating in a low state on startup. If so, that's great, we've solved two problems with one solution.