1
« Last post by LukeZ on September 16, 2024, 10:53:17 AM »
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.
2
« Last post by Rongyos on September 16, 2024, 03:09:03 AM »
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
3
« Last post by LukeZ on September 03, 2024, 05:52:28 AM »
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:
// 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.
4
« Last post by Rongyos on September 03, 2024, 04:54:38 AM »
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: 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 blaSo 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? /*----------------------------------------------------------------------*
* 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
5
« Last post by LukeZ on September 03, 2024, 04:24:00 AM »
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?
6
« Last post by Rongyos on September 02, 2024, 12:11:51 PM »
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
7
« Last post by LukeZ on August 21, 2024, 12:02:35 PM »
Hi Rock, yes, it would be a good idea to make sure the Teensy has the latest firmware. You can update it from the Firmware tab of OP Config, just note that after you click the "Flash" button in OP Config, you also have to press the little physical button that is on the Teensy itself (you have about 10 seconds to push it after the Flash has begun). This tells the Teensy to accept new firmware.
When I look at the Word document you posted I can see that some files were successfully played, although the format of the text looks different that I would expect, I beleive it is also supposed to print the track length for each file that gets played. So that may indicate that your firmware is an old version.
Yes, I think the lack of sound during the test routine is probably because you don't have a volume pot and of course the TCB is not sending any volume commands. So I think you will need to plug in a potentiometer, hopefully you have one.
See if those changes are of any help. If you still have problems, what I would recommend next is to remove all the sound files from the SD card, and add one file at a time and run through the test. Of course you can skip the files that you know already work. Maybe there is one file in there somewhere that is corrupted and causing problems, and in this way, although tedious, you may be able to discover which one it is. But if none of your problem files are playing, even when they are the only file on the SD card, then it probably indicates the file is not formatted correctly somehow. Audacity in theory should work just fine, and it sounds to me like you have saved them in the correct format, but who knows if maybe something went wrong in the conversion.
I'm sorry I'm not able to be of more help, but I hope with some tinkering and exploring on your end we can figure out what is going on.
8
« Last post by rockchuck on August 21, 2024, 10:35:46 AM »
Hi Luke
just thought of something after reading the posts in the sound card section regarding adding sound trigger functions etc. Maybe I need to upgrade the firmware in my sound card. The sound files I have been using that work ok are from this site and are the very first files made. My new files have some of the additional sound files added , and after reading the posts seem to require a firmware upgrade. My TCB has the latest firmware as it prompted me to upgrade it but the sound card doesn't prompt so I never thought to upgrade it.
cheers
rockchuck
9
« Last post by rockchuck on August 20, 2024, 08:50:17 PM »
Hi Luke
thanks for the reply.
OK I did get the sound card to snoop and see attached file for results.
I had to have the serial cable disconnected from the sound card for it to work and use the Teensy usb port as you said.
I had power onto the card however no sound was heard. I assume this is because I had no volume control pot plugged in as I use the radio to control the sound?
So looking at what is happening some sounds do work-- ie turret rotation and elevation, light switch sound on/off and some engine sound when I accelerate.
There is no startup sound or idle sound, machine gun sound ,cannon fire, engine shut down etc.
The sound files I am using are ones that I had to convert to 16bit format. I am using Audacity to modify the sound.
Maybe I need another source file for my sounds and get some sounds from various tank videos etc and try these out.
See attached snoop file.
thanks
rock
10
« Last post by LukeZ on August 20, 2024, 02:37:00 PM »
Hi Rock,
Hopefully we can troubleshoot this one successfully. I should mention that I don't have a sound card of my own anymore, all my equipment was stolen about a year ago. The Teensy 3.2 has since been discontinued so I am unable to build a new one.
You are correct in trying the test routine by placing the jumper on RC input 1. I might not have made this clear in the Wiki, but when you are running this test routine, it is the sound card that needs to be connected to the computer (with a USB cable to the Teensy), and not the TCB. In fact, you don't even need the TCB for this test, and you can leave it disconnected. With the jumper on RC 1, and the sound card plugged into the computer, open a Snoop connection to the appropriate COM port and a baud rate of 115200, and see what happens. Note also that while the USB cable will provide power to the Teensy, it will not provide power to the amplifier, so you also need to make sure the sound card has power from a battery or else you will hear nothing.
Even if the sound files don't play for whatever reason, the sound card should still post some information to the Snoop window, such as whether it was able to read the SD card or not, etc... This will at least tell us whether the sound card is functioning correctly.
So that is the first step, to make sure that the Teensy can communicate with the computer. Hopefully that will give us some more information about what is happening.
I don't think the size of your sound files is an issue, as even 142 MB is not very large.
|
Recent Posts