The problem is on this line in the readThrottle() function:
tempThrottle = (int)(tempThrottle / CAL_REFERENCE_VOLTAGE) * 100; // Gives throttle as a percentage
It needs that (int) removing:
tempThrottle = (tempThrottle / CAL_REFERENCE_VOLTAGE) * 100; // Gives throttle as a percentage And then works as intended!
The (int) converts (or casts) the value that follows it into an integer variable. In this case I had intended to convert the output of the calculation to an integer value as we didn't need the accuracy of the decimal point, however what I actually did was just convert the output of the division within the brackets to a round number before multiplying it by 100. As that division is always going to give a value between 0 and 1, rounding it to a whole number will either give 0 or 1 - hence the 0 to 100 jump!
It can also be fixed by encompassing the entire calculation in another set of brackets after the int:
tempThrottle = (int)((tempThrottle / CAL_REFERENCE_VOLTAGE) * 100); // Gives throttle as a percentage That will now convert the percentage to an integer value as I'd originally intended...
As ever with programming, the error is normally a missed bracket or a semi-colon!
Hi Rowan.. Thanks again for the new code..It's running nicely on my 'breadboard' as I write..
I wonder if you could give me your take on a couple of observations on the scope that may, or (more likely😊) may not, be relevant..
When slowly opening the throttle, nothing appears to happen...then the PWM jumps to around 30% or so before (brilliantly😊) ramping up....(I understand your explanation re: not starting the ramp till 30%, but should the throttle still function, with no ramp, from zero to 30%..?)
The other thing I noticed on the scope is that the trailing edges of the PWM pulses appear to be 'fluttering' by a small amount at a few Hertz..This isn't present with the original code..
I'm guessing that neither of these observations would make a big difference in practice...I'm just curious, so I would be grateful if you could have a look for me when you have time..
Definitely no rush, Rowan...The car is nowhere near finished yet.. J
There are dead zones for the throttle in the code - anything under 1v on the input will be read as 0, anything over 4v will be read as 100%. It doesn't actually map between these zones, as voltage goes from 0 - 5v, the output goes 0 - 20% .... tracks throttle input .... 80% - 100%. The dead spots are excessive, but should cover any type of throttle that gets plugged into it and can be tuned from there. This is the initial jump you're seeing.
Regarding fluttering of the PWM, the way the output is being written to hasn't changed, my first suspicion would be some parasitic capacitance on the output affecting things. Does it still do it unplugged from the breadboard?
Thanks Rowan.. Aaah!...You could have rightfully said "Read the program!"... 'cos, even with my lack of knowledge, it's there to see☹️, so thank you for explaining... It's fascinating watchng the throttle/PWM ramp working on the scope..(I need to get out more😊)
The flutter on the PWM is a strange one..I guess it's only a couple of percent at most of the mark/space ratio, a few times a second, but, on the same rig, it's not there when running the original program...I'll try running it off the breadboard, as you suggest....but I have a feeling that, even with the flutter, it would not have a significant effect when driving the car... Cheers John
Ah, I'd mis-understood what you meant by flutter - I thought you meant a voltage flutter rather than pulse width flutter.
Speculating, but I can hazard a guess at what's happening. If the input request is 1% above the current output, the ramp function will add 2% to it. In 100ms, the next time it's checked, the Input is now 1% below the output so it drops again. With a constant throttle that will stabilise there, but with a slightly varying throttle - even a little noise on the input - it could make the output jump around by 1%. Changing it to something along the lines of "if(tempThrottle > currThrottle+1)" might solve it?
Hi Rowan.. Re: the jitter...I'm not too concerned about the effect on the car in a race as there is so little time spent with the throttle in mid-range, but I'm still curious as to the cause...and I'm trying to 'get to know' the nano better.. As you suggested, I took the nano off the breadboard, fed it with a stabilised 10 Volts, and input approx. 2.5V to the throttle input from between a couple of fixed resistors from the nano's 5 V out to ground.. oh yes...and shut off the fluorescent lights.. The nano's 5 V out and the throttle input Voltage appear rock steady on the 'scope...but the mark/space jitter is still there.. Is there a possibility that the floating inputs and outputs on the rest of the nano could cause some instability?.. However, as my nano isn't the one that will be in the controller for the car, I think we'll wait till the team has put the controller together and see how that nano is 'fully loaded'.. I haven't tried your extra line yet as I'm not absolutely sure where to insert it and I didn't want to make things worse..☹️ Off to sunnier climes now 'till mid-March, so I'll leave you in peace for a while😊.. Thanks.. John
Sounds like the test should have ruled out the inputs being the issue. As the flutter is on the pulse width I still think it is most likely induced by the new ramp code. I'll have look at it when I get a chance
Hi Gentlemen.. Although languishing in hot places, I'm taking time out to (try and) learn things Arduino☹️..
My team intend to use the eChook board almost as you describe, but there is one mod that, for us, would be the 'icing on the cake', as it were...
Before I spend lots of time trying to work out how we might do it, it occurred to me that perhaps I should check with the 'Gurus' (yes, you guys😊) as to whether as not it is going to be possible..
'Out of the box', you send the data via BT.. We would also like to, either simultaneously, or, depending on the circumstances, alternatively, use our direct radio link to our existing telemetry software..
Do you think it would be possible to also send the serial data string (at the same speed and format) to a second output pin...or even tap into the BT feed via a buffer.(even another Nano, or a couple of back to back max232s, perhaps).to provide a feed for the transmitter?
We only need the relevant sensor info from the car, but any irrelevant characters/data could possibly be discarded at the receiver with our telemetry software..
Looking at the code, I'm guessing there is chatter between the eChook and the BT module....It would be great to access the live data as a csv string, (much as you describe the Log File), to 'squirt' it to the transmitter.. The input to our telemetry TX doesn't need any flow control..
What do you think, guys?...I hope that doesn't come under the 'silly question' category?..☹️
Thank you for your time.. John.. Chipping Sodbury..
Hi John - hope you're enjoying the sun! It's a little bit wet here....
Perfectly possible to do. You could tap into the data going to the bluetooth module but it is all encoded. There is example code for the decoding on our github site, but it's not the most intuitive process. There is no two way communication between them though, the Arduino just outputs serial and the Bluetooth module converts it to the bluetooth serial protocol and sends it straight through to the phone
Probably the easier way would be to use a software serial library and point it to pins on the expansion header. A little code to generate a CSV type output squirted to the software serial should work well.
Thanks Rowan.. That's encouraging.. Lots of research still to do though.. If I get totally lost with the software serial library, do you think you would you be able to come to my rescue and point me in the right direction?...please..