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 ... 31 32 33 [34] 35 36 37 ... 78
496
Open Source Sound Dev / Re: Sound ideas
« on: May 09, 2019, 03:38:43 PM »
And now, another idea that I had today while creating sounds:
A rev up sound when stopped. Some people might like to be able to rev up their tanks when stopped... Currently we can play a rev up user sound, but the motor idle is still  there... So I dont know, it might be cool to be able to play that sound, and muting the idling motor sound at the same time.
Actually I don't think there is a way to play the rev sound manually, unless you create one and add it as a User Sound, in which case I agree that would sound odd with the idle sound in the background.

However, this is why the transmission disengage function was included since the earliest days of the TCB. Disengage the transmission, and then you can use the throttle stick to rev the engine all you want without the tank moving. When you want to drive again, re-engage the transmission.

Have I understood correctly?

497
Open Source Sound Dev / Re: Sound ideas
« on: May 07, 2019, 03:57:52 PM »
Hi Luke, another thing that I dont know it it exist right now... When using custom sounds (long music files for example) could you add the option for stopping all the sounds?
I mean, lets say I have 12 long ambient music, I think it would be cool to have an option like "User sound ALL (Instead of a number)  - Stop. That would be easier to program and will take less outputs.

Hi Rad, this has been added in the latest release (0.93.49). You will need to update the sound card firmware, the TCB firmware, and OP Config. The new function is called User Sounds - Stop All.

I will mention a few other changes here that you requested in a PM, which are also included in 0.93.49:

Quote from: Rad_Schuhart
Transmision engage delays: I am using a long cold start sound. (longer than those 20 seconds) Could it be rised longer? 45 secs should be OK, but I dont know, 99 might be even better just in case some people wants to add an commander speech or something.
I have increased the maximum time to 60 seconds. I can't go beyond that without changing the variable data type and involving some other complications. I'm not sure how often one wants to wait a full minute before they can start driving their tank, so hopefully that is long enough.

Quote from: Rad_Schuhart
Smoke: There is "smoke on" "smoke off" but unlike the rest of options, there is no "Toggle smoke on/off" could you please add that? It will save one switch and makes sense to have everything in the same switch.
To be clear, there actually was a toggle smoke function but only for the automatic smoker. You are correct there was no toggle function for the smoker output when under manual control. I have added one.

Quote from: Rad_Schuhart
Some delay when playing user sounds: I am using a rotary 6 pos switch for selecting the sounds. If I rotate it fast to play a sound, it plays all the sounds on its way. I mean, if the user sound I want to play is the sixth and I have the switch in position one, when I rotate it, it starts playing all of them. If it is complicated or might cause problem to other users, just tell me, I think I can program the radio to have a slight delay in that rotary.
I understand what you are trying to accomplish, but I could not conceive of a good way to implement this. For those triggering user sounds via a switch, you would not want a delay and a delay would in fact be a nuisance. We could then add a user-option to introduce a delay or not, which is more effort, but even then, we aren't asking it necessarily to "wait a moment before playing this sound," we are asking it to "wait a moment and see if I decide to play another sound first." That is even more complicated. So I have decided not to pursue this.

Even if you introduce delays in your transmitter you will have the same problem. I think what you actually want to do is have the rotary knob do the selection, but not actually trigger the signal until you flip another switch (select sound with knob, send selection with switch). I have seen this same arrangement used in other applications so I know it is possible to program your transmitter in such a way if you are using a programmable transmitter. I believe it only requires a basic channel mix.

498
Open Source Sound Dev / Re: Sound ideas
« on: May 07, 2019, 03:31:51 PM »
Luke, i have the idea that i asked this before (and you probably answered) but is it possible to have different "reloaded" sounds?

My commander yells "Gun reloaded" all the time, this gets boring in time.. Maybe there can be multiple sounds like "next target" that can be chosen randomly?

Hi John, this has been added in the latest release (0.93.49). You only need to update the sound card firmware for this one. Previously the reloaded sound was called "reloaded.wav" but that has changed. Now there are 5 possible sounds and the file names must be:
- reload_1.wav
- reload_2.wav
- reload_3.wav
- reload_4.wav
- reload_5.wav

You don't have to specify all 5 if you don't have that many, just omit the ones you don't need.

As always the full list of sound file names can be found in the Wiki. Here is the link to the TCB list. The list is different when used in RC mode, the page for that is here.

499
Open Source Sound Dev / Re: Open Source Sound Files
« on: May 04, 2019, 04:00:45 PM »
Good work Johnny, glad to see someone working on this!

The throttle is using stepped sounds which I know is the way most do it. It does create a sound that is responsive to throttle so that is the advantage of it, but to my ear the pitch changes also sound synthetic. That is not a problem with your sound files specifically so much as with the approach in general.

The alternative is to have a long, relatively consistent sample play with little throttle responsiveness, it sounds more natural but doesn't give the user much satisfaction when he moves the stick. So it's kind of a trade-off either way, and regardless it's a difficult task and I salute anyone who takes the time to create something.

Jurgen's sample is also a very good one, for the right editor!

500
Open Source Sound Dev / Re: Sound ideas
« on: May 02, 2019, 09:20:23 PM »
It is possible, if I do it! I will add it to my list and let you know when I can get it done.

501
Show and Tell / Re: 1/6 Metalbox Luchs project
« on: May 02, 2019, 09:17:46 PM »
The tank looks great on an overcast day! Your photography is obviously as good as your detailing skills. Well done.

502
Scout Dev / Re: Home Build
« on: May 02, 2019, 05:11:21 PM »
Since you now mention using Fast PWM,  am I correct in assuming the Phase Corect was only chosen so that you could more precisely set the PWM frequency?
Yes that's correct. Either type of PWM will work fine for driving the motor but we can have different frequency options with each one. My goal was to get to 20Khz or above because the whiney-motor phenomenon really bothers me.


I noticed the Motor_PWM_Top definition but I have commented this out as you only seemed to use this for setting ICR1 and as this is not used with Timer0 and the value of TOP is predefined as 255.
Am I correct with this?
Actually MOTOR_PWM_TOP is also used in the function "getSpeedCommand_fromRC" on the INPUT_RC tab and your sketch shouldn't even compile if you commented out the definition, but maybe you have re-moved all the RC code I don't know. If you intend to leave the RC stuff in then you need to leave that defined (and set it to 255) because that is used to auto-scale the signal from the RC radio to an accurate PWM speed command.


The multiplcation of the speed I did change to 2 but I am confused with the code you have shown.
I had changed the code as below ...

You have an extra line which is not in the code from Github and checks for the max value
if (val == 127) return 255;

Is it necessary?
Right, I did add a little bit there. You can just multiply it by 2 as you have done, but note that 2*127 = 254 so you will never actually be able to get to full on which is 255. I doubt you'd notice it but that is why I threw in that extra line.

We didn't need to do any tricks like that in the stock code because I picked a custom TOP value that is exactly 3*127 (381). To do the equivalent thing here we'd want to pick a custom TOP value of 254 instead of 255, but when using the 8-bit Timer 0 the options for custom TOP values are not as convenient so just set it to the fixed value of 255 (WGM0 2:0 = 3, this requires setting bits in both TCCR0A and TCCR0B).

Actually, here is what I have for the new 8-bit setup, you can compare with yours and see if we match:
Code: [Select]
// TIMER 0 - MOTOR PWM
// ---------------------------------------------------------------------------------------------------------------------------------------------->   
    // We use Timer 0 to generate ~7.8KHz PWM on Arduino pins 5 & 6 (PD5 and PD6). Ken Shirriff has a good tutorial on the various types of PWM possible: http://www.righto.com/2009/07/secrets-of-arduino-pwm.html

    // We want:
    // - Waveform Generation Mode bits (WGM0 2:0) - split across TCCR0A and TCCR0B. These set the PWM modes, we want Mode 3 - Fast PWM with a fixed TOP value of 0xFF (255). See page 109
    // - Clock Select (CS0 2:0) - last three bits of TCCR0B which set the prescaler, we want prescaler of 8. See page 111.
    // - Compare Match Output A & B bits (COM0A, COM0B): Two bits each, in TCCR0A register, these enable/disable PWM on the associated pins. See page 107.
    //   The pins we are using are Arduino pins 5 & 6 or in other words, Atmega port D pin 5 and 6.
   
    // To control the duty cycle (set the motor speed), we write to OCR0A or OCR0B a value between 0-TOP (0-255)
    //OCR0A = 0-TOP;    // To set duty cycle on Arduino pin 6
    //OCR0B = 0-TOP;    // To set duty cycle on Arduino pin 5
   
    // The frequency is determined by the PWM mode (Fast PWM mode in our case), the clock frequency, the prescaler, and our TOP value.
    // Formula for Fast PWM is (Clock/Prescaler/TOP) = 16,000,000 / 8 / 255 = 7,843 Hz
    // Low frequencies result in "motor whine" which is annoying and doesn't sound realistic on a model. The VNH2SP30/VNH5019 motor drivers used on this device have a maximum PWM frequency input of 20Khz, though this
    // is not absolute. Higher frequencies cause less efficient operation and create more heat. Human hearing typically extends to about 20Khz, so above that the PWM should be inaudbile.
    // When using the 8-bit Timer 0 the best we can do is ~7.8KHz, which will still be audible but not terrible.
    // When controlled via serial the speed is passed as a 7-bit speed number (meaning values from 0-127), so we must multiply them by 2 to scale them to the PWM range of 0-255 for OCR0A and OCR0B.

    TCCR0A = 0xA3;              // COM0 A1:A0, COM0 B1:B0 = 10 (connect non-inverted PWM to pins), WGM0 2:0 = 011 (Mode 3, Fast PWM with TOP = 0xFF)
    TCCR0B = 0x02;              // CS1 2:0 = 010 (Prescaler = 8)
    TIFR0 =  0x07;              // Start off with all Timer 0 flags clear (by setting bits to 1 in TIFR0 register)
    TIMSK0 = 0x00;              // Disable Timer 0 interrupts (by clearing TIMSK0 bits). PWM is generated in hardware and we won't need interrupts enabled for it.
    TCNT0 = 0;                  // Reset TCNT0
    OCR0A = 0;                  // Start off with duty cycle for both motors at 0 for safety.
    OCR0B = 0;                  //


Note we won't be doing anything with ICR1 in this case, because TOP is fixed and anyway our 8-bit Timer 0 doesn't have a corresponding ICR0.


It takes a while for me to understand code but I normally get there, however writing from scratch is a complete no no.

Going through all the routines is interesting as I am learning quite a bit.
Frankly I learned everything I know from looking at what others had done, I don't have a degree or training in programming or electronics. Eventually you see enough you can put the pieces together yourself in new ways, and you also get pretty familiar with component data sheets, but still, the original foundation of everything came from somebody else. That's why open source is so great, none of us have to start from square one. Your project is a perfect example!

503
Glad to hear someone having success with reflow, it's fun when it works.

Feel free to upload your images to the forum rather than link them to an external site, although I know the one drawback of that is that the forum doesn't do inline attachments.

504
Scout Dev / Re: Home Build
« on: April 30, 2019, 02:35:06 PM »
It's true. The Monster Moto Shield (and Chinese clones) route the two VNH2SP30 PWM lines to pins D5 and D6 on the UNO, which are mapped to the 8-bit Timer 0 on the ATmega328. The Scout hardware uses pins D9 and D10 which are mapped to the 16-bit Timer 1. The 16-bit timer allows us greater flexibility in the selection of PWM frequency. On the Scout the frequency is set to ~21KHz which is ultrasonic.

With the 8-bit Timer 0 you have fewer options but you can do better than 4KHz. I assume you derived 4KHz by using Phase-Correct PWM with a prescaler of 8 and a TOP value of 255 (the max that you can go with an 8-bit timer). However, you can use Fast PWM mode instead, again with a prescaler of 8 and a max TOP of 255 and you will end up with ~7.8KHz. That is still well within the range of human hearing but the motor whine will not be quite so annoying as 4KHz. I'll let you look at the datasheet and figure out the registers, but also make sure to change the MOTOR_PWM_TOP definition to 255.

Note that you will also have to change the function that translates the serial commands to speed commands, this is at the bottom of the INPUT_SERIAL tab. With the 16-bit Timer 1 we use a custom TOP value of 381 which we selected both because it gave us a perfect PWM frequency but also because it is exactly 3*127 and our speed signal comes in as a value from 0-127. So we multiply the incoming value by 3 and use that to set our pulse-width.

If you use an 8-bit timer with a max TOP of 255 you will have to scale the incoming value by 2 instead of 3.

Code: [Select]
int16_t getSpeedCommand_fromSerial(uint8_t val)
{
    // Serial speed commands should be 0 to 127.
    val = constrain(val, 0, 127);

    // MODIFIED VERSION FOR 8-BIT TIMER
    // Multiply by 2 to scale our speed value (from 0 to 127) to our PWM duty cycle range (0 to 255)
    if (val == 127) return 255;
    else            return val * 2;
}

As for RC the code will adjust automatically.

Anyway you are getting a good look under the hood, and it becomes clear why certain design decisions were made. I too looked at the motor shields early on but sadly the way they are wired is not ideal for our purposes.

505
Open Panzer Help / Re: Motor Noise
« on: April 28, 2019, 05:00:54 PM »
Great! Thanks for letting me know. Always feels good to make progress and we have done quite a bit in this thread.

506
Open Panzer Help / Re: Motor Noise
« on: April 27, 2019, 07:19:02 PM »
A small issue did pop up though, not related to this, so perhaps I should start a new thread?  When Airsoft is disabled, all is good, but after enabling, and shooting with it while moving only, the track recoil will no longer coordinate with the sound and the airsoft shot when sitting still, but instead the track recoil timing changes and occurs initially, when you hit the cannon fire switch. 

It won't reset to the proper coordination unless you turn the tank power off and on, then it will coordinate again.  Very repeatable, so that is really good....Apparently something changes when the tank is moving and you fire the airsoft, setting the timing for the recoil to occur initially on cannon fire instead of waiting for the airsoft switch to open?
Thanks Jerry, your clear description did make it straightforward to identify the bug that was causing this. I've posted a TCB firmware update that should fix it. I actually haven't tested it so let me know if doesn't work, but it should. 

507
Glad to see you making progress. Noise issues are definitely a challenge on these circuits and it gets worse the higher the amplification, 15 watts is a lot.

The PAM8610 does have a MUTE pin, but I don't know if it is broken out on the board you bought or not. If you can access it, connect it to Pin 14 of the Teensy. The mute pin on your PAM operates in the same manner as the amp we are using on the official OP design (V2 and later hardware), which is to say, a logic level HIGH on the pin mutes the amp and a logic level LOW enables sound. The firmware is already written to keep the amp muted during boot-up for the reasons you mentioned, and it also automatically mutes the amp anytime a sound is not playing which eliminates noise during static moments. You may want to also add a resistor to that mute line pulling it up to VDD (+5V) so that even before the microprocessor has time to get started the MUTE line will be held high (see the schematic for the OP sound card for how I've done it).

That will help, but as for the rest you are right, you need to keep the wires/traces as short as possible and away from wires/traces that carry other signals. One thing I noticed a big problem with was two-way receivers like the FrSky and others, in those cases you want to keep the RC antenna as far away from the amp as possible.

I have 15 TCB units that I want to make sound cards for. . .
Good heavens! I think you set the record. I should have been so forward thinking.

508
Open Panzer Help / Re: Motor Noise
« on: April 24, 2019, 03:59:26 PM »
Great! Keep me posted but hopefully this does put an end to this pernicious problem.

As for the rumor - since HK discontinued the TCB I have had so far 4 commercial entities express "interest" in the project, although in a few cases that might be too strong a word, maybe just "curiosity" would be more accurate. But none have expressed a clear "intent" let alone a "plan" or "commitment" to produce.

For whatever reason, some operating in the RC tank space enjoy saying and predicting all sorts of things of which little may ever come true or else be years away. I have never understood the business logic behind this approach and I suspect there is none. Whether that tendency is related to this rumor or not, I don't know. I'm not familiar with the user in question and I don't know who he's been talking to.

My policy is to attempt to avoid predictions or saying anything of which I am not absolutely certain. This is so that over time my word may hopefully be taken to be something valuable and trustworthy. But as cautious as I am even I got burnt when Hobby King under-delivered on what I had felt safe to promise the public. So it is difficult for one to be too cautious with their words.

While I certainly do hope we can get the TCB re-started again, not to mention the other OP products, the honest truth from the horse's mouth is that I am not aware of a clear path forward at this moment. If the RCTankWarfare rumor is accurate even in its general impression then somebody knows something I don't.


509
Open Panzer Help / Re: Motor Noise
« on: April 23, 2019, 05:58:25 PM »
Ok I've added enable/disable/toggle functions for IR. I also enabled the internal pull-up resistor on the receive line, which may in itself possibly solve your problem (it has the same effect as holding the receive line to +5 volts). If you want to test, the first thing to do would be to update the firmware (0.93.47) but leave the rest of your setup the same - keep IR enabled, and leave your mushroom unplugged. Drive around, move the turret/whatever, and see if you get a false hit again. If not, then that takes care of that.

But if you do still get false hits, then you'll want to utilize the enable/disable IR functions through some switch or channel on your transmitter. I've added visual confirmation through the hit LEDs, you can see this illustrated towards the end of the video below.

As another confirmation, if you are connected in Snoop and fire the cannon it will now specify whether the IR signal was also sent as part of the cannon fire event or not.

Let me know if you have any issues!


510
OP Config gives you 10 seconds to push the button on the Teensy, the flash operation doesn't actually start until it detects the button press. But anyway, you have figured it out.

I deduce that you are using the Sound card with the TCB rather than in RC mode. If you get no sound, it could be a wiring issue with your amp, or you might also want to double-check that your sound files are named correctly and saved in the right format (16 bit and 44,100 Hz WAV).

Some users have developed some sound sets for the OP Sound Card which you can download here, if that helps with testing. At least then you know the sound files are not the problem.

Pages: 1 ... 31 32 33 [34] 35 36 37 ... 78