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 ... 35
The random sound feature is one I am currently working on, there might be partial code for it on GitHub I can't remember, but it is not quite done yet. The general approach I am taking for now is to provide two sound "banks" of up to 20 sounds each, then there will be options to play next, play previous, play random, etc... Basically sort of like the same functionality of an MP3 player. If you want to play a specific sound you would use the User Sound option and call that specific sound directly. But if you just want a collection of music that you could cycle through, or call at random, the sound bank will work for that.

As for you other suggestion, if you run the test routine with the sound card connected in Snoop mode it will show the name and duration of each sound file as it is being played. In fact even if you are not in the test routine and you connect in Snoop the sound card gives a lot of diagnostic information. It's not really needed for normal operation but I use it for debugging and such. At present you can't tell it to play a sound from the GUI interface, but you can of course tell it to play a sound from the TCB or from your RC transmitter and then see that displayed in the console.

Open Panzer Help / Re: Radio connection issues
« on: August 18, 2018, 03:48:32 PM »
In that case I'd recommend the FrSky D4R-II, listed as a 4-channel receiver but it has a full 8 channels out the PPM port. It is also very small. The other option is the D8R-XP which is basically the same as your D8R-II but adds PPM (the actual PPM). It's larger and more expensive for no benefit since you won't be using the individual channel outputs anyway.

If you want more than 8 channels you would need to upgrade to a different module, I'd recommend the FrSky XJT and an SBus receiver such as the X4R-SB, but for most people 8 channels is plenty.

All this information and more is already in the Wiki. I know it's a lot but if you want to use this product you really need to read through the entire thing. It will answer a lot of questions and save you a lot of trouble in the long run. Good luck!

Open Panzer Help / Re: Radio connection issues
« on: August 18, 2018, 01:14:29 PM »
Hi Lowryder, the TCB requires a PPM, SBus, or iBus receiver. Although documentation for the D8R-II Plus receiver does mention the word "PPM", they are using the word in a different manner than what is typically meant. In fact as the documentation also makes clear, this receiver only outputs 8 conventional PWM channels, therefore it is not compatible.

FrSky makes many receivers however and some definitely can be used. What module do you have in your 9XR Pro? That will determine what receivers you can choose from.

Those are very interesting devices I had not seen before. Not really practical for the mass market for several reasons as you point out, but certainly for people willing to experiment they give you a lot of capability to play with.

Open Panzer Help / Re: Banggood dual channel motor controllers.
« on: August 11, 2018, 01:00:13 PM »
I would recommend the 20A instead. The listed ratings are often optimistic and 5 amps is already marginal for heavy models.

Open Panzer Help / Re: Banggood dual channel motor controllers.
« on: August 11, 2018, 10:19:43 AM »
Thanks for posting those, I had seen the Scorpion before but the AliExpress controllers seem to be new designs.

Yes, all three should work with the TCB by setting drive motors to RC Output. All three controllers offer BEC, be sure to disable this before connecting to the TCB! This is very easy to do, see instructions here.

The only thing I notice w/ SD card playback is the 'break' during loops. this would happen anytime the stick position is maintained longer than the playback time on accel decel sound files...such as holding mid throttle.  So if stick maintained for (x)millis, you may consider that another track of same level throttle sound is faded in . . . Unless, you can access a file again while it is playing so that the data can be preloaded into a buffer.
Yes, we can read the same file more than once so for a sound that is on continuous repeat we can fade back into itself when it ends, and we always have two slots dedicated to engine sounds for this reason. That is already implemented in several places but I may have missed a place or two as in the case of a repeating mid-throttle position, but it's easy to add it and I'll go back and review and make sure all the cases are covered.

PS: If you want to include code in your post you can wrap it in [code] .... [/code] tags so it formats correctly, I did this for you above.

Taking the 'stepped throttle' approach, the best sound to my ear is by adding a subtle delay/overlap between steps. For example, a  .2 second overlap as you go from one file to the next sound works well.
This is the approach I've already taken, the sound card uses a 0.4 second overlap but it can be adjusted. Either way it needs to remain brief. In my implementation they don't only overlap, but during the brief overlap time the first sound is faded out the same rate the second sound is faded in, this keeps the overall volume level the same.

Not sure how many steps you would plan,  but these engines did not rev too high, so you could get away with 5-10 steps.
There are 10 steps programmed for now.

Also, you may want to add an overall throttle up delay. By this I mean that the engine can only accelerate so fast. So that all throttle steps have to play sequentially (at least for a minimal amount of time) to get to full speed, rather than skipping steps to match stick position. this is more realistic.  Similar delay on throttle down as the stick returns . Only go to decel sound bite if stick returns to center.
Something like this has been implemented, at least on deceleration, but it is actually taken care of on the TCB side. You can see it in action by setting the sound card to type Benedini and then attaching a servo to the Prop1 output. The servo will pretty much mach your throttle stick as you accelerate but when you return the stick to center the servo will take longer to return. In real life you can rev the engine pretty much instantaneously but it doesn't return to idle instantaneously if you let off the gas. Of course the OP sound card doesn't use the Prop 1 output but the TCB logic in this regard is the same no matter which sound card is being used.

As for acceleration, the OP sound card will not strictly require every step to be played sequentially, but unless you gun it all at once it will at least play each step for the length of the fade time discussed above.

I still think you can create a throttle specific sound generator with pitch change just to fill the gap during accel and decel.  And overplay it with good idle and full throttle and decel sounds.
Technically I think this is possible with the hardware we have but it is not something I've pursued yet at this point. I'm not sure if it would detract fro good quality sounds, and also, there is a limit to how many sounds can be played at once.

As for your other comments about using both Flash and SD,etc... the hardware parameters on my design are pretty much settled at this point, but these are all good ideas for others who may wish to develop alternative versions.

This thread is an interesting collection of experiments and not really related to the design I'm working on so I'll quit butting in with comparisons to what I've done. Keep going with your explorations and I'll be curious to see where it leads you.

Open Panzer Help / Re: Movement issue
« on: August 03, 2018, 03:02:11 PM »
Glad to hear it, it usually is something simple.

Open Panzer Help / Re: Movement issue
« on: August 02, 2018, 03:45:26 PM »
You need to do some troubleshooting using the tools provided in order to narrow down the issue. There is no way to solve what will be a very specific issue with a vague description. There are LEDs on the board and for more detail you can open a Snoop connection while you manipulate the controls.

The first process of elimination is to decide whether the TCB is doing what you tell it to do (which would imply the issue could be with your ESCs), or if the TCB is not even getting the correct commands (implying the issue could be with your radio or radio setup).

Off the top of my head, things to check include:
  • ESCs are set to crawler mode (solid LED)
  • Do you have very high levels of acceleration constraint applied? This will cause moving forward and back to be very slow initially, which could appear as if the model is not responding when in fact it is just going to take time.
  • PWM-to-PPM converters - these are really not recommended and I don't think I mention them anywhere in the Wiki. First of all, using a PWM receiver defeats the entire purpose of the TCB which is to accommodate a high number of channels on a single input line. Secondly, they are prone to all kinds of interference and random problems that are impossible to troubleshoot - please read this very recent thread with this exact same issue.
Do some more troubleshooting. Eliminate the things that it is not, and you will be left which a smaller list of things it might be, then we can resolve it. I'm certain in the end it is going to be something very simple, but you have to do the detective work yourself.

Hi Rad, was away for several days but finally getting caught up again on the posts here. Your sound experiments are interesting to follow and I thought your JP sounds were quite nice.

You mentioned the difference between using multiple sound bites for throttle speed compared to a baseline engine sound dynamically adjusted for playback speed and pitch. As you know the Open Panzer sound card is using the individual sound bites approach, because it is difficult for a microprocessor to stream digital sound data from the relatively slow SD card, manipulate the data and then convert it to analog at the necessary speed. Computers can do this easily but computers are running their CPUs at much higher frequencies. Benedini seems to have managed it but his firmware is closed so I don't know what his specific approach is, but there are two things we do know - he stores sound clips essentially in RAM, which while very fast is also very limited in space; so this requires his clips to be very short and of low quality. Although I am impressed at his technical achievements I am not always a fan of the sound that can be generated.

But I agree with you the individual sound bite approach can sound even worse, especially when the sound clips are very brief. This causes the broken-record effect which always makes me want to commit suicide, I'd rather have a completely silent model than hear that.

The best RC models are a combination of technical and artistic elements. Trying to literally re-create the precise sound of a real life engine through an electrical device that is not an engine will be a less effective approach than emulating the "spirit" of the sound creatively. In my view using long samples create a far more believable effect even if there is not much pitch change with engine speed, because the artificiality of the pitch changes we are able to generate with the limitations we have are more likely to break the sense of immersion than something more seamless even if less precisely "realistic." The best modelers create the illusion of reality through more simple means, rather than trying to literally copy reality.

I think your JP sound set, with the addition of a single relatively long running sample (to avoid the broken record effect) would sound one million times better than most anything else on the market today even though in effect it would only have a single throttle speed (apart from idle). Good accel/decel sounds and smooth transitions are more important to realism in my view.

Anyway those are some of my thoughts but I think model sounds are highly subjective and what sounds good to one person may not to another.

Open Panzer Help / Re: Banggood dual channel motor controllers.
« on: August 01, 2018, 01:32:58 PM »
I'm also going to test a few cheap blue tooth modules and I'll get back to you on those.
Our friend Sergey has some information about using a cheap Chinese bluetooth module in his thread here.

At this moment the recommended Bluetooth module from Adafruit is discontinued while they create a new version. When they release the updated product I will update the Wiki, in the meantime you can always use the cheap Chinese ones but they are more difficult to setup and will not support flashing new firmware.

Anyway I don't want to derail this thread so if more discussion of bluetooth is desired go ahead and start a new one and we can keep this one focused on the Banggood motor controllers.

Open Panzer Help / Re: Sabertooth 5A w/KV-2 Taigen Metal edition
« on: July 24, 2018, 07:29:55 PM »
I'm glad we finally solved the mystery and that it turned out to be an easy fix. This may also explain similar behavior that if I recall you experience on your StugIII.

PWM to PPM is not a trivial conversion due to timing constraints, I remember when the ArduPilot team developed the first converter which I suspect Hobby King has copied. Who knows how good a job they did. Having multiple motors running inside a metal box (such as the inside of your tank) is basically the worst possible RF environment imaginable for any kind of receiver but at least the digital ones can tell if the signal is valid or not, whereas the analog receiver just passes on whatever garbage makes it to the antenna.

Show and Tell / Re: XRAD'S Elefant
« on: July 24, 2018, 07:23:49 PM »
Nice work on a complex three-servo mechanism! I think the result looks good.

TCB Dev / Re: Ideas for the OP Config
« on: July 24, 2018, 07:21:35 PM »
Hi Neil, this is indeed a good idea and one which I have thought of myself, but it didn't occur to me until a few years into the project (this has been in development since 2011). Unfortunately the way the TCB firmware was organized from the beginning makes this essentially impossible at the present moment without a major overhaul, or as you suggest some kind of custom firmware to be used only during testing, which however poses its own set of problems and complexities.

Accomplishing something like this for the Scout or sound card would not be as bad since they are by design expecting to receive commands from the serial port anyway. However since neither of those products is even available the benefit/cost ratio of that time investment is not presently very high.

Anyway I'm agreeing with you about the desirability of this feature, especially for the TCB. No one has spent more time testing this thing than myself and I often wished I had thought ahead to incorporate this ability! I've added your suggestion to the public To-Do list but to be honest that list is more a wish-list of things which are not likely to ever get done unless the project attracts further developers.

Relatively straightforward features and bugs never make it to that list, I work on them right away and they get included in routine firmware updates. The To-Do list is stuff that would be nice to have but would take more time than I have available to me.

Pages: [1] 2 3 4 ... 35