Open Panzer
Developer's Forum => TCB Dev => Topic started by: Rad_Schuhart on February 17, 2018, 03:49:53 AM
-
Hi Luke, in the OP Config, I think it would be great if we had the posibility of editing the functions and triggers.
I mean, for example, imagine I programed everything from channel 1 to 16, and then suddenly I notice I did a mistake in lets say channel 7. So far the only way is to remove it and introduce it again, but then this number 7 will be at the end of all what I have done. When programming a lot sounds and functions its easier for me to be able to have them in order. (For exampple makes sense to have all the weapons sound together, the custom sounds in other group and so on) Also when experimenting, saves a lot of time just to be able to edit the function itself. So, I dont know, IMHO the way to go would be to select the programmed function, and then to click in a "Edit function" button or something like that.
Also Id apreciate a lot if you add a pop up confirmation window for uploading and downloading the config to the board. I screwed it several times when pressing the wrong button.
EDIT: Also it wont be a bad idea to be able to move the functions with a mouse!
For example, again, I programmed everything for the 16 channels, and the channel 7 is the one that plays a long custom sound. Then I notice I forgot to add the stop sound option! So after adding it to the list, it would be great if I could drag between aux 7 and 8 instead of being next to the 16th.
I guess I am, very organized, sorry. Say thanks to my mom and her slippers, lol.
-
Hi Luke, in the OP Config, I think it would be great if we had the posibility of editing the functions and triggers.
I will consider this, I agree it would be useful. The question is how practical it will be to program, for that I will need some time to experiment.
Also Id apreciate a lot if you add a pop up confirmation window for uploading and downloading the config to the board. I screwed it several times when pressing the wrong button.
I am not excited about this suggestion. In my long experience with software interfaces, pop-up confirmations are useful in the early stages of learning a new program, but become impediments once you have it figured out. You will quickly memorize which button is which and after that the pop-up message would be entirely unnecessary, in fact it will become a bitter annoyance to dispense with every single time you want to read or write. Already if you hover your mouse over the read/write buttons a tool-tip message will appear to remind you what the function is.
However I may be able to add another message in the status area (bottom of the screen) on mouse-hover of these buttons, which might also help.
EDIT: Also it wont be a bad idea to be able to move the functions with a mouse!
Are you aware that the items in the list can be sorted just by clicking the header row (click Function or Trigger to sort by those columns, keep clicking to switch between ascending or descending). I don't know if it will be possible to re-arrange the items manually but I think sorting will address some of your frustrations and is an easy way to see if you have missed some assignments/have illogical combinations/etc...
-
Hi there. My confirming pop up window request comes because I screwed it several times. I know when hovering the mouse over the arrow it says what is going to do and I already know what those buttons do... But you know, shit happens, lol. If a pop up window is annoying for somebody, I guess you can always add a small button with "Ok, dont ask me again" or something like that...
Regarding the header row... I had no idea! One problem less! :D
-
Hello Luke,
Could I make a suggestion for Op Config.
Could you add another button on the left after Firmware called "Test".
After selecting, this would for example, give the user buttons to test all outputs of the TCB. Discretes On/Off, Fwd, Rev, Left, etc. This would need a test config to be downloaded into the TCB, via another button.
This would enable the user to test a TCB without using Tx/Rx, it would thereby eleminate a faulty radio and user programming errors. Useful for existing installations and new TCBs.
A test page for the Scout and Op Sound would also be useful, again this would need a test setup for Op Sound.
Just a suggestion ☺
Best Regards
Neil
-
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 (http://openpanzer.org/forum/index.php?topic=9.0) 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.
-
Hi, this is not an idea but a (hopefully) very easy request.
In the open config I would like to be able to select a 12 pos switch too.
Yes, I know I will be the only soul in the earth using it, but it is very handy for me, for triggering the user sounds.
I programmed the radio in a way that having a 6 pos switch, with some software tweaking it feels and behaves like an 12 pos switch.
So with the rotating switch I select the desired user sound, and with some logic switches and programming, when flicking another switch or pressing a push button I trigger it.
This is the same system I am using for triggering the user sounds in the Benedini´s Mini and Micro.
Another idea, (not request but an idea)
It would be nice to have two different "Max turret toration speed" one with the motor on, and another with the motor off. This has some sense, and means hand cranking the turret makes it turn slower than with the motor.
And that's it for now. :)
-
Hi, this is not an idea but a (hopefully) very easy request.
In the open config I would like to be able to select a 12 pos switch too.
Yes, I know I will be the only soul in the earth using it, but it is very handy for me, for triggering the user sounds.
I programmed the radio in a way that having a 6 pos switch, with some software tweaking it feels and behaves like an 12 pos switch.
So with the rotating switch I select the desired user sound, and with some logic switches and programming, when flicking another switch or pressing a push button I trigger it.
This is the same system I am using for triggering the user sounds in the Benedini´s Mini and Micro.
Well as you know I don't accept all feature requests but this one seems reasonable as the number of functions has increased and people with advanced radios can now create these kinds of multi-position switches. I've added support for all positions up to 12 positions, but I have not tested it! It should work fine since we are just increasing certain parameters rather than creating new functionality but let me know how it works for you. (You will need to upgrade to v0.93.63 for both OP Config and your TCB firmware.)
Another idea, (not request but an idea)
It would be nice to have two different "Max turret toration speed" one with the motor on, and another with the motor off. This has some sense, and means hand cranking the turret makes it turn slower than with the motor.
That is an interesting idea, which I personally would file under the "more complication than is warranted" category. The same effect can be created with your thumb! It is not a bad idea but complication has a cost even for good ideas and I try to only add complication when there is a compelling need.
-
Thanks! I will try to test the 12 positions this weekend. It is indeed very usefull, and lets me use 12 user sounds in only one channel.
I will make a video showing how to trigger all the user sounds with the logical switches and the new 12 positions feature at some point in the future.
I think it brings a lot of new posibilities and also will make everything easier. Now is easier than before to give orders to the rest of the platoon! As I said many times I don't battle, but for those who do it, it can be super cool to be the platoon commander giving the instructions to the others. I do it with my children and is super fun. Everybody should try it!
Also as you point, day by day better and newer radios are popping out. Have you seen the new Jumper T16? Looks like an amazing piece of technology, and has 6 push buttons in the front, so they can be used for triggering those user sounds. If for some disaster my 9xtreme radio dies, that will be my replacement.
-
Regarding the turret rotation speed, well, to be honest my (freak obsesive) idea was even a bit more deep than I stated.
If I had the knowledge and the skills, what I would do is a proportional turret sound, so the more further you move the stick, the faster the turret sound loops. It has some sense, in real life the faster you hand crank the turret, the faster it will turn. And yep, being able to limit the manual turret speed is also cool. For me, the more features and customization, the better!
But as you point, it might be too much work, and thanks anyway for your time and effort!
But if you implement the feature we all will be happier and I will love you even more, and my love is priceless, lol.
-
Ok, I could not wait to test the new 12pos switch.
I flashed the newest firmware, and then flashed my model settings in the TCB.
Then, in the radio menu, AUX 5/order9/digital switch/12
Then functiion menu: Select function/user sound 1 play once
Select trigger source/Aux 5
Select trigger action/ ---------- Here comes the problem, there is nothing I can select.
IF in the in the radio menu, instead of AUX 5/order9/digital switch/12 I put 6, I can select the 6 positions. So I guess I have found a bug...
I tested the aux 5 from 7 to 12, and when doing that, there is no way to select the trigger action.
-
Ok thanks, I knew I would miss something without testing. That is an easy fix and there are a few other changes I need to make anyway so I will release another update to OP Config in the next couple days. Thanks for letting me know.
-
Ok, as I've delved further into this I realized that exceeding 9 positions will be problematic, because I didn't reserve more than 1 digit for them back in the early days when I started writing the firmware. It is possible to expand them but it would be more work than I have time for now. But up to 9 positions should now work and you can test that if you like.
Also as you point, day by day better and newer radios are popping out. Have you seen the new Jumper T16? Looks like an amazing piece of technology, and has 6 push buttons in the front, so they can be used for triggering those user sounds. If for some disaster my 9xtreme radio dies, that will be my replacement.
I saw the T16 earlier this year and was initially quite interested, but my enthusiasm was tempered when I discovered that Jumper is not using the official OpenTX firmware but their own fork of it, which we can assume will not be updated as often or maintained as rigorously. Even worse, the er9x developers have decided not to work with them at all, and that is actually the transmitter firmware I prefer (this was several months ago and things could have changed since, but I don't think so).
It is kind of pathetic, but after almost 15 years a modded 9x transmitter remains the best tank radio in my opinion; unfortunately the best upgrade for it (the 9XTreme board) is no longer available. You'd think some manufacturer would make a suitable replacement for it but while there are new transmitters released all the time, nothing has quite come close to replacing it for the value and features in my view.
Regarding the turret rotation speed, well, to be honest my (freak obsesive) idea was even a bit more deep than I stated.
If I had the knowledge and the skills, what I would do is a proportional turret sound, so the more further you move the stick, the faster the turret sound loops. It has some sense, in real life the faster you hand crank the turret, the faster it will turn. And yep, being able to limit the manual turret speed is also cool. For me, the more features and customization, the better!
Proportional turret sound would be nice, but as you know the Open Panzer sound card doesn't have the ability to change sound pitch or speed, so what we'd have to do is create something like what we do for drive sounds, where we end up with something like 10 turret samples, each one played at a different speed of rotation. So now the burden is on the sound designer to find multiple turret sound samples which I imagine would be difficult, and it's hard to say how good the transitions between each one would sound.
Everything has a cost in time and effort and even when those are reasonable every new addition adds complexity and setup work for the end user. I was told many times by people that they thought the Open Panzer project looked interesting but "too complicated" and they didn't have the time to figure it all out. On the other hand, others want more and more features, options, tabs in the setup program, pages in the Wiki, things to remember, etc, etc... So it is impossible to please everyone.
As a designer I have increasingly become convinced of the need to keep things as simple as possible for a multitude of reasons, but of course the perspective is often the opposite for the client.
The hope really was that developers would be attracted to the project and invest time in creating some of these new features, for that matter much like Jumper did it is entirely possible for anyone to fork the TCB code and take the project in a whole new direction. But it would seem that software developers are as rare as hens teeth in the RC tank modeling community.
Anyway, those are my random thoughts. For now I'm going to leave the turret sounds as they are.
-
Yes, IMHO nothing can beat my radio with 9xtreme. I think I have the honour of having the most modded 9x radio, because I did basically every mod showed in the openrcforum and some more. The only and last part that will finish the radio, is the 7 pos encoder, which I think you already have. I will try to install it at christmas but I am really scared of damaging something. If I blew the 9xtreme I hang myself somewhere.
I dont see any 9xtreme or similar board coming at any moment in the future. 9x radios time seems to be gone, and now there are a lot of alternatives selling cheap radios with most of the mods any mortal would need, already done (I still cant believe I got a turnigy 9xr pro for 25 dollars at hobbyking!)
I also do preffer erskyTX way more than opentx, but it seems the erskytx guys are porting it to the jumper T16. The only thing is they will not support the frsky protocol. Copy and paste from the forum:
"by MikeB » Sun Aug 18, 2019 10:52 pm
I have a version of erskyTx that runs OK on the T16, although I haven't published it yet. I may do so very soon. Note that, as with the 9XR-PRO when it first came out, the use of FrSky 'X' and FrSky 'D' protocols is disabled on the T16 until Jumper reach an agreement with FrSky to allow their use (which HK did for the 'PRO)."
Anyway, plan is to stick with my 9xtreme radio, unless some disaster happens. Include me and my radio in your nocturne prayers, lol.
About the 9pos, thanks for implementing them, it is better than 6!. If you have time in the future it would be great to include the 12, specially for those who have the benedini mini. No rush, I dont have soundcard and it will take me two months to replace it.
And about the turret sound, yes, it might be complicated for some users. Anyway if you implement it, let me know and I will make the turret sounds for the existent sound sets. It should not be toooo complicated.
-
Hi Luke!
I have an idea for the boards (and software) new features. I know there is a hardware solution for 360° turret rotation with sling connectors but I do not trust them at all.
Do you ever consider a "software" 360 rotation which is based on a reed relay case count can be set by the user?
I mean: if I set the turret rotation max count to 3, the PCB will read the cases when the magnet passes 2 times and stop the turning at 3rd case. After that, only changed polarity (stick to other side, opposite direction) triggers the rotation to the opposite side.
Problems in my idea:
1. only the first count should be the user setting, after changing direction the counting should consider the remaining possible turns (if after the first start you turned the turret twice, the max value to the other side should be 5)
2. board must store the actual position and can keep in the memory after battery removal (for defending the cables)
3. users should consider what type of cable are they using and how long are they for set the correct value and not damage their cables, hardwares/hardwires
what do you think of that? Difficult, not user friendly, considerable, wtf?? :)
Thanks
Rongyos
ps.: sorry if my post is in the wrong topic, did not find better
-
Hi Rongyos, first I have to say I admire your creative thinking. I am always impressed with the clever ideas that people come up with.
I understand what you're proposing and I think it could theoretically be possible. From my experience with electronics, I think there are some challenges. One is that turrets move very slowly and electrical switches do not provide what we call "clean" signals to a processor who will be reading them several hundred times a second. So I think the software can easily become confused when the turret passes over the switch. Also a single switch will probably not be enough. If it touches the switch at the limit, it can say "ok, you have to move the other direction now." But how long does it need to move the other direction before it will allow the switch to be hit again? When the switch is touched again, is it because we just moved a little way away and then came back (which we do not want to allow), or did we go all the way around and hit it from the other side (which is ok)? Two switches at least would be required, but even then I think it will be possible to confuse the software if we really try. Three switches would be better, but that gets to be too much for the user to setup.
A rotary encoder would be best. These are like little knobs that can be turned and they count up or down as they rotate one way or the other. However the rotary encoder would need to be geared to the turret ring somehow, we would probably need to design a 3D printed gear. And then also the user would have to know how many revolutions of the encoder equals one revolution of the turret. So some kind of setup routine would need to be run to calculate this. That would be a lot of coding and it would be kind of a pain for the user the first time, but after the setup I think it would work well.
It would work, that is - until they remove the hatch for maintenance on their tank, and now the count is no longer valid! So then we have to provide a way to tell the TCB to reset the count to Zero. In the end I am not sure we have saved the user any work!
I like the general idea and I am of the same opinion as you about the small 360 sliprings, I think they are not great. The wires are very small and do not allow a lot of current, and they are well known to cause problems with sending and receiving IR.
However I think for this to be an idea worth investing time in, it would have to be possible to do it in a much more simple way. Right now I can't think of a very simple and fool-proof approach. It is a clever idea but I think it needs one or two more clever ideas to go with it to really make it effective in practice. Maybe someone will come up with these other ideas in time? I will keep thinking about it.
-
Hi Luke,
First of all, please don't laugh at me because my programming skills are very basic
I have a Beier board and I very like the headlight flickering effect on it but it has some flaws. I generated a basic flickering function which can be (I think) put in LIGHTS.ino
// Duration of the flickering effect in milliseconds
const unsigned long flickerDuration = 5000; //no idea where to put this - that should be cool if the user can set this in the OPCONFIG
void EstartFlickering {
// Check if the flicker duration has elapsed
if (millis() >= flickerDuration) {
// Turn off the LED and exit the loop
digitalWrite(ledPin, LOW);
return;
}
// Generate a random dimming value (0-255)
int dimValue = random(256);
;
}
This function can be put in DRIVING.ino where engine starts (at there there is also a
// Play the engine start sound
TankSound->StartEngine();
there. The duration time should be set by user (easiest way). The beier reads the sound wave signals and flicker the LEDs following the wave spikes which is not realistic when the tank engine finally on and has a revving sound in the "enginestart" sound. In that phase the alternator can put voltage IRL and the headlights are even, but beier lower the dim according to the sound volume, thats what I dont like. The duration should be the time while the tank starting up, ignition or how can I say that in English, hope its understandable :) .
Can you somehow put this function in the codes? (I think mine wont work if i put it with force :) )
-
Hi Rongyos, thanks for the question, and don't worry, your English is very good. I understand clearly what you are asking.
I've made some updates to the firmware to incorporate your suggestion. You will have to update both OP Config and also re-flash the latest firmware to your TCB (the latest version of both is 0.93.75)
To enable this feature there is an option on the "Lights & IO" tab of OP Config that you can select, called "Flicker Headlights during Engine Start."
The length of time that the flickering effect will last is defined by the "Transmission Engage Delay" setting on the "Driving" tab of OP Config. Since this setting should be set to the length of time of your engine start sound, it will also work for the flickering.
The flickering will affect both the headlights and the brake lights, but only if you have them on before you start the engine. In the case of brake lights, probably the only way for them to be on before the engine is started is to select the "Brake Lights On when Stopped" option on the Lights & IO tab.
The headlight output on the TCB is unable to be dimmed, it can only be full on or full off. However the brake lights output can be set to any intensity. I've used a slightly different approach on each one, the brake light will flicker in sync with the headlights but because it is able to be dimmed I've used that to make the flickering a little less harsh.
I don't actually have a TCB to do any tests with, so I can't say exactly how good it will look. I'd appreciate if you could test it both to make sure it works as intended and also to let me know what you think of the flickering.
-
I don't actually have a TCB to do any tests with, so I can't say exactly how good it will look. I'd appreciate if you could test it both to make sure it works as intended and also to let me know what you think of the flickering.
Hi Luke,
First of all, thank you for your quick reply and support.
I downloaded the new firmware and OP Config, managed to set up the build. I faced some bug / error:
- Light toggle on/off function not working properly on headlights (see video) - its working well with toggle on + toggle off functions binded on 2 pos switch
- Start engine flickering not working with toggle on/off function at all
- Start engine flickering has some errors:
- a. only works with 2 pos function
- b. no lights at all during the start engine sequence
- c. random light sound played during the start engine sequence
maybe there are more dependencies than I thought :( I attached a video for better understanding.
The build is up and I am happy to test the upgrades :)
Rongyos
-
Hi Rongyos, thank you very much for doing that test. In fact I see now there were multiple problems with the code I had written. It's always more complicated than it seems, and you're absolutely right, there are more dependencies than even I can remember! ;)
But your test helped me find the problems. Also, in the version I posted yesterday, I hadn't implemented flickering for running lights, only brake lights. But I've added it now for both. And of course we don't want the headlight sound to be playing while we flicker the lights, so I've fixed that as well. Your 2 and 3 position switches should also hopefully now work correctly.
I've posted an update to the firmware. I am keeping the same version name, but you can still download it and overwrite what you flashed yesterday.
It's entirely possible there could still remain some bugs. I apologize I can't presently do any testing on my side, and I appreciate you being the guinea pig!
Let me know how it goes.
-
Let me know how it goes.
Hi Luke,
I thank you that you are dealing with it :)
Now the functions are working fine but a flickering does the led switch on and off randomly. Maybe thats why I wrote you a whole bunch of stupidity in the code.
What about if you can change this? (stolen from candle effect arduino code):
// Generate a random dimming value (0-255)
int dimValue = [i]random(170) + 170[/i]
[i]delay(random(150))[/i];
thanks
Rongyos (the guineaPIG) :)
-
Hi Rongyos, you're right, simply turning a light on and off doesn't make for a very realistic "flickering" effect. I haven't actually seen what it looks like, but I can imagine it is not very good.
Unfortunately, that is the only option we have for the headlights, which is connected to a "digital" output on the ATmega2560 chip. A "digital" output is one that can only have two states, either on or off. There are other pins on the ATmega2560 that are called "analog" outputs and those can be set to any level between off (0) and on (255). But these pins are limited in number and we have had to use them for other things.
The brake light is connected to an analog output which is how we are able to dim it for "running lights." If you set the "Brake Lights on When Stopped" option you will see that it uses a flickering effect similar to the candle effect you found. But when we are flickering the "running lights" I can't be sure what dim level the user specified, and to flicker a dim light it might not be very visible, so in that case I am flickering it only between off and the dim level.
Here is the code I have added which handles the flickering. There is more than this, but this is the important part:
// This effect takes place on engine startup if the user has selected the option to "Flicker Headlights on Engine Start" (Lights & IO tab of OP Config)
// and if they have specified a "Transmission Engage Delay" (Driving tab of OP Config). The effect will last for the duration of the Transmission Engage Delay.
// It applies to both the headlights and the brake/running lights, but only if they were already on before the effect begins.
void FlickerLights()
{
static boolean flickerState;
// Initialize if appropriate:
if (HeadlightsFlickering == false && BrakeLightsFlickering == false) // They will both be false if we have not started the effect.
{ // They will both remain false if neither the headlights or brakelights are on, in which case we won't come back here.
// Only flicker lights that are already on
if (Light1State) HeadlightsFlickering = true;
if (BrakeLightsActive || RunningLightsActive) BrakeLightsFlickering = true;
if (HeadlightsFlickering || BrakeLightsFlickering) flickerState = false; // Initialize light state to false (which has the effect of starting the effect with "on")
}
// Now perfrom the flickering if it has been enabled
if (HeadlightsFlickering || BrakeLightsFlickering)
{
if (HeadlightsFlickering)
{
// The headlight output can not be dimmed, so we simply toggle it on and off.
// We don't use the dedicated Light1Toggle function because that would also call the headlight sound, which we don't want, not to mention the possible debug message.
flickerState ? digitalWrite(pin_Light1, LOW) : digitalWrite(pin_Light1, HIGH);
}
if (BrakeLightsFlickering)
{
// The brake light flickering effect will differ depending on whether we are flickering the running lights or the full brake lights.
if (BrakeLightsActive)
{
// Here we vary the light between some lower and higher dim levels, it can go full off or full on, but also something in-between
if (flickerState) analogWrite(pin_Brakelights, random(100)); // Dimmer - random value between 0 (off) and 100 (not even half brightness)
else analogWrite(pin_Brakelights, random(75)+180); // Brighter - random value between 180 and 255 (full on)
}
else if (RunningLightsActive)
{
// Here we vary the light between full off and whatever the running lights dim level is
flickerState ? digitalWrite(pin_Brakelights, LOW) : analogWrite(pin_Brakelights, RunningLightsDimLevel);
}
}
// Toggle the flicker state, now it will match what we've just done above (which was the opposite of flickerState)
flickerState = !flickerState;
// Now set a timer to come back here after a random amount of time to continue the effect
// We adjust the random delay so that the light "off" time is shorter than the light "on" time
if (flickerState) FlickeringTimerID = timer.setTimeout(random(350)+60, FlickerLights); // On - random time between 60 and 410 mS
else FlickeringTimerID = timer.setTimeout(random(210)+50, FlickerLights); // Off - random time between 50 and 260 mS
}
}
I think the only other option to improve the headlight flickering would be to use the Aux output for headlights instead. The Aux output uses an analog output and therefore could be flickered more realistically. Of course this would require even more changes, and also there is no headlight sound associated with the Aux output (although one could be created with Function Triggers assigned to the same switch).
I'm not sure if the added complexity would be worth it... I may consider it but I need to explore the code some more to remind myself what complications that would involve.
In the meantime, maybe you could attach a white led to the Brake lights, and select the "Brake Lights on When Stopped" option, and then at least let me know if that effect even looks very good?
-
The brake light is connected to an analog output which is how we are able to dim it for "running lights." If you set the "Brake Lights on When Stopped" option you will see that it uses a flickering effect similar to the candle effect you found. But when we are flickering the "running lights" I can't be sure what dim level the user specified, and to flicker a dim light it might not be very visible, so in that case I am flickering it only between off and the dim level.
[...]
In the meantime, maybe you could attach a white led to the Brake lights, and select the "Brake Lights on When Stopped" option, and then at least let me know if that effect even looks very good?
Hi Luke,
I attach a video how it looks. The brake light is on during enginestart sequence and no flickering on it (in the video it looks like it has but its just visual illusion, the blinking headlight effects the camera lens (beleive me pls :) )
Is the Headlight pin is PWM compatible digital pin? (analogWrite = random(150)+170)
How complicated will be to add this effect to AUX outputs if the brake light flickering will successful? It would be very good.
Thanks
Rongyos
-
Hi Rongyos, thanks once again for doing this test. I apologize I'm not able to work out these bugs on my end, I only have a couple TCB boards left to me and they are in a storage box on the other side of the world!
I think I know what was wrong with the brake light effect. I've made a new firmware, this time I'm just attaching it to this message and will wait to update the official one until we have all the problems worked out. Can you test once again with the brakelight and let me know how it looks?
As for the headlight pin, no, unfortunately, that is what I was saying earlier, it is not PWM compatible. It can only be turned on or off, and I agree with you, that effect does not look very good...
It should be possible to flicker the Aux output but let's see if the effect looks good on the brake output first, because it will be the same effect on the Aux output.
-
let's see if the effect looks good on the brake output first, because it will be the same effect on the Aux output.
Hi Luke,
Thanks for your support :) I think "we are almost there". The flickering works in the brake light but I think it only needs a "faderate", because now it changes the dim very fast.
IDK if this helps but I found a code from somewhere with fadein fadeout (it might be useless but trying to "help"):
int brightness = random(256);
// Fade in
for (int fadeValue = 0; fadeValue <= brightness; fadeValue += 5) {
analogWrite(ledPin, fadeValue);
delay(10);
}
// Fade out
for (int fadeValue = brightness; fadeValue >= 0; fadeValue -= 5) {
analogWrite(ledPin, fadeValue);
delay(10);
}
Rongyos
-
I see what you mean about it being a bit harsh. I can't quite use the faderate code as written, but I've tried to soften it some more in the attached.
I think I will need to buy an Arduino and LED to do some testing at home. I've been using an online emulator but it really doesn't provide an accurate representation of what the LED will look like.
-
I think I will need to buy an Arduino and LED to do some testing at home.
You dont need to if I am here :)
Very, very close. I think we can meet the goal if the max flickering dim is below the max dim (255)
Something like this:
// Here we vary the light between some lower and higher dim levels, it can go full off or full on, but also something in-between
if (flickerState) analogWrite(pin_Brakelights, random(100)); // Dimmer - random value between 0 (off) and 100 (not even half brightness)
else analogWrite(pin_Brakelights, [u]random(45)[/u]+180); // Brighter - random value between 180 and 255 (full on)
I dont understand the first row. Why do we need 0 (full off) state?
Here is the video. IRL its mutch better and looks like drop voltage flickering but It will be better with lower max value :)
Thanks
ROngyos
-
Well I'm glad we are making progress!
To answer your question, we don't need to have full off, but that line of code could result in a full off. The random(100) means it will choose a value between 0 and 100, so it was possible that it could choose 0 (off). However the code I posted this afternoon wouldn't go to full off, but you're right, it would possibly go to full brightness.
You can try the attached version, here is the code that I am using this time. For the "dimmer" setting you can see we won't go below 50. For the "brighter" setting I took your suggestion and we won't go above 225:
if (flickerState) analogWrite(pin_Brakelights, random(70)+50); // Dimmer - random value between 50 and 120
else analogWrite(pin_Brakelights, random(45)+180); // Brighter - random value between 180 and 225
If you get tired of all the back and forth you could also try compiling the code in the Arduino IDE yourself, and then you could change it as much as you want until you find the perfect settings. But I'm also happy to keep making adjustments this way.
-
To be honest, I still can not understand the sacred meaning of these changes.
More precisely, I can’t understand what their functionality is, in application, in the construction (revival) of models.
That's what I really get - this is, for example, the functionality of flashing beacons for ships, for police cars, or just cars, so that when turning left, for example, the turn signal turns on automatically - turning left, for example.
-
The idea here is that we would "flicker" the lights (an English word a little differing than flashing or blinking), during the time that the engine is starting. On old tanks (and even old cars) the current draw from the engine starter motor would reduce the battery voltage so that headlights would look dim until the engine started and the alternator began creating current. That is the effect we are trying to create here.
-
Hi Rongyos,
I bought a cheap Arduino UNO and a couple LEDs so I could do some testing on my laptop. Here is yet another update where I've adjusted the flickering effect to be about as good as I can get it.
Other changes:
- I've removed completely any effect on the headlight output since that simply doesn't look good.
- But I did add the effect on the Aux output (Arduino pin 8 ). So you use that for your headlights instead. Of course the Aux output needs to be On when the engine is started or else nothing will happen.
- The flickering effect will apply correctly now to the brake light depending on whether the brake light is on or just the running light.
- When the flickering is finished (the transmission engage delay has expired/your engine start sound has finished), the lights will gradually return to full brightness instead of doing so abruptly all at one.
You can let me know what you think.
-
Hi Rongyos,
- When the flickering is finished (the transmission engage delay has expired/your engine start sound has finished), the lights will gradually return to full brightness instead of doing so abruptly all at one.
You can let me know what you think.
Hi Luke,
Sorry for the late reply I was not near my computer
Honestly, the softness on the end of the flickering is too high and not realistic now. Can you lower (much much lower it) to almost nothing?
Also, the flickering is almost perfect and realistic. Can you add a little bit more softness? Just a little bit :) Unfortunatelly I only have TCB right now and no free arduino :(
Regards
Rongyos[/list]
-
Ok, I've taken your suggestions.
- The fade back to full brightness at the end has been shortened to almost nothing.
- The flickering has been "softened" a little. I have limited how much the brightness can vary between each step so that it doesn't make changes so abruptly.
I hope this looks better.
-
I hope this looks better.
Hi Luke,
Its perfect now :) (the sound doesnt represent the flickering its just test. Flickering is realistic in electric starting not flywheel)
Here is a video of the brake light flickering:
Thanks for your efforts and quick support!
Rongyos
-
Yes, I agree, it looks cool and realistic!
Now I understand what it was about!
-
Thanks again Rongyos for helping with the testing!
I've finalized all the changes and posted a new official release, it is version 0.93.76 (both TCB and OP Config). I've also updated information in the Wiki.
-
Yes, I put a hat on my head, immediately take it off, and put it on my chest.
This is a great addition!