Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - LukeZ

Pages: [1] 2 3 4 ... 78
1
Show and Tell / Re: WH.TKSZ-16S
« on: February 08, 2024, 12:16:24 PM »
Well "no harm, no foul" as we say in English, though I'm not sure it can be translated to German. Maybe "Hilft nix, schadet nix"?

On the other hand Jürgen is right that it doesn't really fit the subject of this forum, and while the product may be interesting, there would be more discussion if it was posted in one of the other general purpose tank forums (RC Universe, RC Tank Warfare, RC Modellbau, etc).

I was unable to find any instructions or information on this new board. I sometimes wonder if the Chinese have gotten around yet to copying portions of the Open Panzer firmware, since it would be very easy to do. What would be interesting, and also very relevant to this forum, is if we ever found a Chinese board that seemed to have done so, and especially if they released a board with an ATmega processor. In that case it would be possible for us to hack it, and from a hardware point of view, they would probably make something even better than the TCB (given they are likely to include drive motor control and sound all in one board).

For some companies, having the Chinese clone their products is not a happy event, but in the cae of the Open Panzer project it would be welcomed, since otherwise we have no access to hardware. So far I have not seen such a thing, but if anyone notices one please let us know!


2
Other Open Source Projects / Re: Standalone Tank IR
« on: January 26, 2024, 03:23:32 PM »
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.

3
Other Open Source Projects / Re: Standalone Tank IR
« on: January 26, 2024, 11:30:50 AM »
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?

4
TCB Dev / Re: High DPI Issue
« on: January 15, 2024, 02:45:01 PM »
Hi Chris, again apologies for having missed your posts. I've realized that I'm having problems getting forum notifications so I need to check in much more often.

I must admit to knowing absolutely nothing about Macs, having never so much as touched one in my life (a deliberate choice). I really have no idea what would be involved in compiling for Mac, but maybe for someone comfortable with that OS and a bit of programming experience it might be less difficult than I imagine. It awaits someone to try, but be careful also, because once you create something you then have to maintain, update, and support it for life, which we don't always think about at the beginning!


Oh and I would be happy to recommend changes on a pull request from the fork if helpful.   

With regards to the Windows version, yes do feel free to recommend changes using pull requests, though we can also discuss here in advance. The main update to OP Config that would be nice is exactly what you've identified, the issue with High DPI screens. That appears to be an easy fix as you've discovered, but fixing all the things that the fix breaks may prove more tedious. However again I would welcome with gratitude any improvements others want to devote themselve to, and will try to help as I can.


One of the main differences in the later version is the settings in the user file but of course that contains user specific environment variables/paths and aren’t great for inclusion in the source control as it isn’t transferable between different environments.  Might have a think about that too.
I may not know what this file is if it's specific to later versions of Qt, but even in my version there is an OpenPanzerConfig.pro.user file which I believe is the equivalent of what you're talking about, and yes, it's not of much use to share it. I think it could probably be left out and theoretically the environment would create it for whoever is compiling the source.


I would love to build a board specifically or the Heclo hat but I’m starting with a few separate components at the moment just to get my head round it a bit.
That is definitely the right approach to take! The result of your experiments with individual sections will go a long way to informing what kind of board you will ultimately want. Starting with a grand unified design at the beginning will always result in a lot of revision later on, or anyway that's my experience.


5
Other Open Source Projects / Re: Standalone Tank IR
« on: January 15, 2024, 12:22:46 PM »
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 :D 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.

6
Open Panzer Help / Re: OP Panel size
« on: January 15, 2024, 11:08:19 AM »
Congrats on building three boards from scratch, that's an accomplishment! Keep us posted on how you get on with them.

7
Hi Chris, sorry for the slow reply!

A little confused that the MG LED doesn’t have a pin on Arduino but I assume that is just a PIN number allocation in the code and I should be able to tweak that.  I guess the Arduino pin layout is the way it is because you designed the pins were they were convenient on the chip when mounted directly but they are relocated to different places on an ardunio board?
You figured it out, but for anyone else curious, yes, there are a few pins on the ATmega2560 which are not used by the Arduino project, but they are still there and on the TCB board I chose to use some of them. For those using a stock Arduino Mega board, those pins will have to be changed, but this can be done as Chris says by uncomenting the "#define TCB_DIY" line in the Settings.h file, or what is even easier, just flash the "TCB - DIY Version" firmware to your Mega from OP Config where all this is already taken care of.


Pressing and holding the bind button for 2 seconds (while powered and bound to the transmitter) it suddenly started spouting serial data out!   Woohoo!  I now have 10 channels in Op-Config to play with.
Thanks for reporting back! The documentation with these Chinese companies is never great. I've added a link to your post in the Wiki under the Receiver Selection Guide for anyone else who might encounter the same confusion, so thanks again for resolving that and helping out future users!

8
Open Panzer Help / Re: OP Panel size
« on: January 11, 2024, 11:03:59 AM »
Thanks Chris for helping out. And yeah, I apologize Steve for this mess. The reason I never fixed the High DPI issue is that doing so breaks other things which I've never had the time to resolve. Years ago there weren't many people using such high resolution monitors, though today it's obviously more common. Hopefully this workaround gets you by for now.

9
Other Open Source Projects / Re: Standalone Tank IR
« on: January 10, 2024, 02:02:30 PM »
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" :D ). 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!

10
Hi Chris, no, I don't think there's anything you've missed. You have interpreted the schematic correctly as far as what pins go to what. The good news is that if PPM is working that tells us at least that the TCB code is functioning and that your receiver is not completely a duff either.

The FS-A8S was my favorite receiver of the FlySky ecosystem, so I know it can work with the TCB. But it could be that they have updated the firmware on the transmitter with extra settings that I don't know about or remember. If (in the transmitter) you set Serial to iBus that should work, but I don't know, maybe you need to re-bind after a change, or maybe for some odd reason it wants the other setting to be PWM. I'm just making random guesses, I really don't remember what the transmitter settings were.

As for the TCB, yes, it starts off looking for sBus, then iBus, then PPM, but if it fails all three then it starts over again and repeats them all in a loop over and over, so if the iBus signal is there, it will pick it up eventually.

I'm willing to bet the answer will end up being something simple.

You could certainly put some diagnostic statements in the TCB code, maybe something that would be even easier and quicker is to download the IBusBM library. It includes a sample sketch called Ibus_singlemonitor that you can load on to your Mega, connect your receiver as described in the notes at the top of the sketch, and it should spit out the channel values on the Serial Monitor. There is some stuff in there about sensors which you won't need. Anyway at the least it would serve as a sanity check.

11
Other Open Source Projects / Re: Standalone Tank IR
« on: January 09, 2024, 02:44:11 PM »
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.

12
Other Open Source Projects / Re: Standalone Tank IR
« on: January 08, 2024, 02:04:58 PM »
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.


13
Other Open Source Projects / Re: Standalone Tank IR
« on: January 07, 2024, 10:10:47 AM »
No, maybe I was not understandable, sorry if my English is not perfect. For me the "tankdestroyed" notify LED effects were very similar to simple hit notification. I just wanted some longer blinking after destroy to make it more clear for the user that the tank is out. If I modify this can I reach my goal? (More blinking time, significantly longer than simple hit notification, the value was 450ms before thats what your comment also said :) )

Code: [Select]
// Now set a timer to keep coming back here after a short interval so we can blink the lights
        DestroyedBlinkerID = TankTimer->setInterval(450, HitLEDs_Destroyed);     // This is a slow blink, about half a second

Yes, if you want to change the blink rate for the destroyed notification, then you can modify the 450 value that you mentioned above. If you use a smaller number the blinking will be faster, or if you use a larger number the blinking will be slower. Regardless it will continue to blink for 15 seconds (or whatever value you decide to specify for DESTROYED_INOPERATIVE_TIME_mS).


Thanks Luke, my plan was to use the 4th pin of the regular 8pin connector which is the airsoft signal pin. It sends out gnd signal, so thats why I used INPUT_PULLUP function to trigger the cannon fire. I don't need the 5V receiving pin because of this. Achieving my plan will let the users use this unit with older Heng Long and Taigen boards (they just need to extend the 4th wire and connect to relevant connector to the battle unit). I also have 2 Taigens and my test were good except the "phantom firing", but with the simple solution from my friend it disappeared!
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. 

14
Other Open Source Projects / Re: Standalone Tank IR
« on: January 06, 2024, 11:31:16 AM »
Can I ask something? Can you add a simple led blink on HitLeds when cannon reloaded and a little bit longer blinking when tank destroyed?

Hi Rongyos, I've posted an update to the firmware to GitHub, there is now the option to have the apple Hit LEDs blink when the cannon reload time has completed. By default it is off, you can set it to true in the A_Setup.h file near the top. 
Code: [Select]
    // NOTIFICATION LED
    // --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------->>
    //
    #define CANNON_RELOAD_NOTIFY    false                   // << --- SET ME - set to True to blink the IR apple notification LEDs when canon reload time has transpired (CUSTOM_CANNON_RELOAD below)
 


I'm not sure how long the blink should be, and I don't have an Arduino right now to test. Currently it is set to 250mS, which is only 1/4 of a second. If you want to increase the time, modify this function at the very bottom of Tank.cpp:
Code: [Select]
//------------------------------------------------------------------------------------------------------------------------>>
// HIT NOTIFICATION LEDs CANON RELOADED - Short blink to notify  user the canon reload time has completed
//                                        Can be enabled/disabled with setting CANNON_RELOAD_NOTIFY on the A_Setup.h tab
//------------------------------------------------------------------------------------------------------------------------>>
void OP_Tank::HitLEDs_ReloadNotify(void)
{   
    HitLEDs_Blink(250);
}


As for increasing the length of the tank destroyed period, it is set to 15 seconds because that is the Tamiya standard. However if you want to change it, modify this value near the top of the Tank.h tab:
Code: [Select]
// Tanks is dead for 15 seconds
#define DESTROYED_INOPERATIVE_TIME_mS   15000   // How long is the vehicle immobilized after being destroyed. 15 seconds is the Tamiya spec. After this,
                                                // the vehicle will automatically re-generate with full health restored.


Finally, with regard to the "phantom firing" - I probably should have made this more clear, though it is shown in the included sample schematic PDF - but you need to place a resistor between A0 and ground. 10k is shown in the schematic though the value is not important.

What you have done by setting A0 (pin_VoltageTrigger) to OUTPUT will also work, but then of course you would have to change that if you were going to use this pin in the future as an input signal from some other MFU.

I guess you are using the manual pushbutton method to trigger the canon fire? Most people probably use the signal input so I suppose that is why we haven't caught this issue before.

I will update the documentation to make this more clear.

15
Other Open Source Projects / Re: Standalone Tank IR
« on: January 04, 2024, 11:45:37 AM »
Hi Rongyos,

I have a suspicion this is related to the Arduino IDE version issue that was discussed earlier in this thread. With certain versions of the IDE the code will compile but without enough memory available, and the sketch will operate very erratically, if at all.

The solution is listed in that post, or again on this page of GitHub under the "Compiling Firmware" section.

So I would suggest following the instructions of opening the Boards Manager in the Arduino IDE, finding the Arduino AVR Boards section, and then installing boards version 1.6.20 and try recompiling and see if that makes a difference. This could explain several of the problems you're seeing.

An other question. Do you know where can I get constant 5V from the Taigen V3 MFU? It seems the CN2 is only providing around 1.8V
I don't have one to test, but I believe you should be able to find 5 volts from the sound card port, and possibly also the IR port. I can't say which pin is what, but you can use a multimeter to verify. However, I can't say  how clean the voltage will be from the Taigen MFU, and it might be better to use a 5v regulator to power your receiver and Nano.

Pages: [1] 2 3 4 ... 78
bomber-explosion