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] 5 6 7 ... 79
46
« on: October 23, 2022, 02:07:20 PM »
Hi Rongyos. I looked at your snoop file. You're right, it is definitely something that is happening at the very beginning, when the TCB first makes a connection with the receiver. There are several functions it runs right away (MG Stop, turn the light off, set the volume) and these are what we would expect to see as it starts reading the channel values and applying the functions that you have set for your switches based on the position they are in (it is easy to see that you have your MG and light switches in the middle position). So everything is working as we would expect, but it also fires the cannon which means that it believes your cannon switch is in position 2. I know you believe the cannon switch is in position 1. You can try this experiment: instead of starting the TCB with the cannon switch in the "off" position, put it in the "on" position and start the TCB. If the cannon doesn't fire, then it was just a confusion that can be fixed by reversing the channel. If it fires no matter what, then it might be as you say some kind of failsafe setting. Maybe the TCB boots up faster than your receiver can create a connection to the transmitter. If that is the case, the first signals the TCB reads from the receiver are actually failsafe positions rather than the actual positions of the switches on your transmitter. You could see what happens if you press the "Reset" button on the TCB. This will cause the TCB to reboot, but it will not interrupt power to the receiver. So your receiver will already be connected to the transmitter when the TCB starts. Does the cannon behave correctly then? What software are you running on your TX16? If it is OpenTx, here is a video on how to set the failsafe values. I don't know if that is your problem or not, but you could experiment with it anyway. You will want to set the failsafe position of Aux Channel 6 to position 1, so that if the connection between the receiver and transmitter is lost, or hasn't been established yet, the cannon will not fire.
47
« on: October 19, 2022, 04:52:58 PM »
Hi Rongyos, if I understand you correctly, the cannon fire happens when the TCB first starts. And this involves not only the sound, but also the recoil servo. If that is the case, then we can eliminate the sound card as being related to your problem, it is clear that the TCB is the one firing the cannon.
Plug your TCB in to your computer with a USB cable and connect to it with Snoop (on the Firmware tab of OP Config) to see what is happening. Does the TCB report a "Cannon Fire" event when it first starts?
I wonder if maybe you have Aux Channel 6 in Position 2 when the TCB starts?
I see you have Aux Channel 6 set to "Reversed" in OP Config. Maybe un-reverse it in OP Config, and reverse it in your radio's settings. You can also try changing the cannon fire function to a different aux channel.
I can't say what the problem is, but I am confident it is not an error in the code. Somehow the TCB thinks that the cannon should be fired, which implies that your radio is telling it to. You will have to do some more troubleshooting yourself. Even if you don't solve the problem right away, hopefully you can discover a piece of information that will help us solve the problem.
48
« on: October 17, 2022, 01:09:31 PM »
Hi Rongyos, that is a strange problem. What I can say is that the sound card will only play the sound that it is being commanded to play. So there are two basic possibilities:
1. You have a sound file on your SD card that plays the cannon sound, but you gave it the file name for something else (in other words, something other than "cannonf.wav")
2. Or for some reason the TCB is sending the signal to fire the cannon at the same time it sends the signal to start the engine.
For #1, I would put the SD card into your computer and listen to all your sound files once again, just to verify that the cannon sound didn't somehow get named to something else.
For #2, examine all your function triggers in OP Config. Did you maybe link the "Cannon Fire" function to the "Engine Start" trigger by mistake? Did you maybe assign the "Cannon Fire" function to the same switch on your transmitter you are using to start the engine?
You can post your OPZ file if you want me to look at it.
There is something else I noticed in your video, which may or may not be related to your problem. I notice there is a delay of several seconds from the time you flip the switch on your transmitter, to the time when the engine starts. Do you know why that is?
By any chance do you have an engine "Preheat time" specified? (In OP Config on the Motors tab, under the Smoker section, when Type is set to "Separate Heat & Fan").
On your SD card do you have a sound file called "preheat.wav"?
If so, you may want to do a test where you delete "preheat.wav" or set "Preheat time" to 0, and see if that makes any difference.
49
« on: September 05, 2022, 08:22:10 AM »
Hi Rongyos, your connections are correct!
It is easy to get confused with the labels, but another way to be sure is simply to connect ground (GND) to ground, the middle connector from one is connected to the middle connector of the other, and that only leaves one connector on each board which by default will be connected to each other. This is true for the TCB, the sound card, and the Scout ESC.
50
« on: July 11, 2022, 08:20:38 AM »
Hi Rongyos, your questions are not annoying at all!
In fact there are several other Teensy boards that could be made to work with the OP Sound Card firmware, but they would all require significant changes to the code and the physical circuit board. The 3.5/3.6 have nearly the same type of sound output as the 3.2, but they are a physically much larger and would require a complete board redesign. Also the 3.5/3.6 processors are unavailable right now the same as the 3.2, so that is no help.
The 4.0 can also produce sound, but it only outputs the sound digitally. This means that instead of the sound output going straight to an amplifier chip, it would first have to go to a digital-analog converter, and then the amplifier. So again a complete board redesign, and also changes to the firmware.
Unfortunately such a redesign is not something I have the time for. And I can't even say that if someone started on this undertaking there might not be other complications that could arise, as I have not explored in depth all the differences. Even if I had the time, I might be hesitant to take on such a project in the current environment, because who is to say that the 4.0 or other components (amplifers or who knows what) might also be affected by shortages in the near future.
I'm sorry I can't be of more help! But I hope that answers your question.
51
« on: July 09, 2022, 03:26:21 PM »
Hi Rongyos, unfortunately although the Teensy 2.0 can do many things, it does not have the necessary processing power to handle the sound generation. So you will need to use the Teensy 3.2.
I know right now they are not available due to the supply chain mess. The semi-conductor shortage is a real problem, much bigger than I thought it would be when it first started. It does not appear at all close to being resolved. When major car manufacturers in America can no longer make automobiles, I don't know how long it will be before hobby things like the Teensy will be able to return.
52
« on: June 01, 2022, 05:44:41 AM »
Glad you found it! Thanks for letting us know.
53
« on: May 31, 2022, 09:53:12 AM »
It's true, I have observed as well that certain transmitter/receiver combinations do not like to be too close, and when they are there can be connection issues. Thankfully that one at least is a very easy fix!
54
« on: May 30, 2022, 05:27:49 PM »
Flashing red and green alternately rapidly is indeed loss of radio signal. It also typically occurs for a few seconds when you first boot the board, not because the radio signal has been "lost" but simply because it hasn't yet been acquired. This flashing has no pre-determined length of time, it lasts for as long as the radio signal is not detected. After the radio signal is acquired I don't know that I would typically expect any kind of flashing, even slower. When you are connected to the computer the green LED will blink slowly but the red LED remains on. One or the other will blink slowly if you are turning in one direction or the other, but they shouldn't be alternating unless you are turning back and forth quickly or there is some kind of glitch in the radio signal. You can see the full list of LED behavior here. If you are having an issue maybe you can describe more what's happening and we can try to figure it out.
55
« on: May 19, 2022, 06:37:13 AM »
Hi NS, yes a 10uF tantalum would work fine, in fact it is mentioned in the datasheet for the voltage regulator I use. If you use a different voltage regulator then you can check its datasheet for recommendations, but usually a tantalum will be fine.
An SMD-D will take up more space so it will not fit on the original board, but if you are making a new design then it doesn't matter.
56
« on: May 17, 2022, 04:15:50 PM »
Hi Steve, Jürgen is right, this is a pretty standard part and many manufacturers would make an equivalent. I recall you're in the UK. I believe this one should work, available from Farnell UK, but they have others as well: Panasonic EEEHB1V100R
57
« on: May 13, 2022, 02:03:36 PM »
Good work! I'm glad you found the solution, and I hope this will be useful to someone else in the future.
58
« on: May 13, 2022, 10:11:17 AM »
Ok, that is interesting. They say it will work with a brushed speed controller, and that is what the A and B motor outputs are, so I don't know why it wouldn't work. The motor outputs do use a higher frequency than many cheap speed controllers, to cut down on motor whine, but that is the only difference.
You said you have tested the actuator by "directly powering" it. Assuming that means you just connected it straight to a battery, do you have a brushed speed controller you could try? If that doesn't work, maybe the actuator is defective in some way.
One other test is to connect the actuator to the Motor A output, but on the Motors tab of OP Config set the Turret Rotation to "Detached." Next create a function trigger that assigns a switch on your transmitter to the functions "Motor A - On" and "Motor A - Off." Now the Motor A output will operate simply like a switch (full on or full off). Of course you will get movement only in one direction, and at full speed. It will not be useful for your turret but it is a test to see if there is any issue with voltage from the motor outputs (I doubt it).
59
« on: May 13, 2022, 08:25:38 AM »
Hi Mini, I assume you are talking about the A or B Motor outputs? (And not the general purpose I/O ports).
I see there are various versions of the L12, the I, S, R, or P. Can you tell us what version you have? For use with the A or B motor outputs, I think you would have to have the L12-S. If that is what you have and it is still not working, it could be that the actuators only accept on/off voltage (in other words there is no speed adjustment), whereas the motor outputs are variable speed.
If you had the -I or -R version, you could control them with one of the RC outputs on the TCB. I don't think have the -R version because that is limited to 6 volts.
60
« on: May 07, 2022, 06:10:40 AM »
Thanks for letting me know! I'm glad it was something simple. 
Pages: 1 2 3 [4] 5 6 7 ... 79
|
Show Posts