Pages: 1 2 3 [4] 5 6 7 ... 10
31
« Last post by Rongyos on January 10, 2024, 03:01:20 PM »
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 :'(
32
« Last post by LukeZ 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" ). 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!
33
« Last post by Rongyos on January 10, 2024, 10:11:55 AM »
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?
34
« Last post by FuzzyJack on January 10, 2024, 02:13:34 AM »
Good morning all, Luke was absolutely correct (as usual  ), it did turn out to be something simple. Using the ibus2pwm example program from the IBusBM library I tried to see if the serial port was seeing anything at all from the receiver and it wasn't. Tried a few other things and nothing. Did some more googling (and I had already done quite a bit before but not found this) and discovered a comment on this forum ( https://www.rcgroups.com/forums/showthread.php?2792377-FS-A8S-help) complaining that to switch the FS-A8S receiver from the default ibus to sbus you had to press and hold the bind button for 2 seconds and it wouldn't remember it (rendering sbus a bit useless). This is in addition to setting the output mode on the transmitter (which was already ibus). In my initial attempts to get things working I had tried a couple of times to rebind the receiver without any obvious success but it looks like in attempting to do that while the receiver had power (which isn't the process for binding anyway) I must have switched it to sbus output and it looks like they fixed it's ability to remember the setting. With the transmitter set to ibus and not having the required reversing circuitry needed for sbus connections nothing was getting through. 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. The receiver came with the transmitter and the manual for the transmitter doesn't contain any information about the receiver at all so knowing you have to actually do something on the receiver to switch between the modes is voodoo at best.  Sorted... 
35
« Last post by FuzzyJack on January 09, 2024, 05:20:43 PM »
Found the section in opsettings.h for tcb diy to switch the pins to 20/21 for MG and Airsoft so will have a play with that too.
36
« Last post by FuzzyJack on January 09, 2024, 05:06:47 PM »
Excellent thanks Luke.
I tried a few permutations of settings but still not detecting the I-bus. Will have a go with that sketch and check if the receiver is outputting anything.
I even hooked up a few LEDs to check the outputs when activating switches and things. 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?
37
« Last post by LukeZ on January 09, 2024, 03:46:00 PM »
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.
38
« Last post by FuzzyJack on January 09, 2024, 03:01:11 PM »
I have been trying to get OP-Config working with an Arduino Mega standard board (well I say standard it’s an “Elegoo” model rather than Arduino) and it fails to read the radio when trying to use I-bus.
I’m using a FlySky i6s with a FS-A8S as per the recommendations on the wiki. I have the output mode set to PPM and Ibus for serial. I connect the ibus cable to pin 15 as per the guide for Arduino but op-config fails to find the radio.
If I connect the ppm cable to pin 3 it finds it ok and can read the data ok. Ppm of course only gets the 8 channels and I was hoping to use ibus to make use of the extra couple of switches.
Before I go trying to diagnose if pin 15 is even getting a signal or if the receiver/transmitter are even talking ibus is there anything I am missing or any known issues/workarounds?
Pretty sure the code on the TCB project is set to subs initially by default and the tries ppm and ibus. Not sure which it tries next but it either isn’t getting ibus or not seeing it on pin 15.
Might have to go and put some diagnostics in the radio class to see if it’s even trying or if the receiver is duff.
39
« Last post by LukeZ 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.
40
« Last post by Rongyos on January 09, 2024, 01:47:23 AM »
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. 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.
Pages: 1 2 3 [4] 5 6 7 ... 10
|
Recent Posts