|
Post by Rowan on Jun 11, 2020 13:55:26 GMT
You're fine then, no need to worry about buffers. I'm amazed it's having a noticeable affect on the speed... do you have any delay() calls in there? Sorry - totally forgot to answer the IDE bit. There is the Arduino online IDE: create.arduino.cc/ I've not used it much but it's worked well when I have. Reinstalling the IDE doesn't fix it? There are other desktop alternatives but they start getting more complex. I use Atom as a text editor for coding, but still use the Arduino IDE to do the programming.
|
|
|
Post by littlejo44 on Jun 11, 2020 16:32:25 GMT
again, thanks.. No delay calls..Just that mph figure arriving every two seconds..It's in there immediately after the SS send sequence to our telemetry..as here..
mySerial.print(mosfetTemp, 1), mySerial.println(); //MOSFET temperature
{ if (mySerial.available() > 0) { mySerial.read(); } SpeedMPH = mySerial.parseFloat(); if (SpeedMPH < 1). //syntax might be wrong here..writing it from memory! SpeedMPH = 0; //this stops the 'hunting' from the gps when stationary..It gives random figures up to around 1mph till moving.
} }
If I take it out, the throttle ramp runs fine..If I leave it in, the ramp advances slowly, and pauses noticeably every two seconds..I'll try your code instead..and I thought it would be so easy..J
|
|
|
Post by Rowan on Jun 11, 2020 18:31:22 GMT
Put it at the start of loop rather than in the send function, it might improve matters as it will let it happen between the timed functions...
I'm still surprised it's so slow though!
Try the atoi() and integers rather than the parseFloat, I suspect that's the slowest operation there...
Edit: just re-read that post... Could it be sending your telemetry data that's part of the slowdown? Sending data takes time, especially at low baud rates and could easily cause a slowdown. It's part of the reason the eChook encodes the data into as few bytes as possible and transmits in small chunks rather than all at once.
|
|
|
Post by littlejo44 on Jun 11, 2020 20:57:38 GMT
Hi..I just managed to get the 'Hourly Builds' version of IDE to fire up, so, maybe all is not lostš..Thank you again for your input.. I apologise again for my lack of expertiise with all this, it must be very frustrating for you as an advisor..
I did try the Gps input at the start of the loop, immediately before my SS data output, but it wasn't happy there either..so I need to try your code in other positions to see if the idea is actually going to work.. If it doesn't, I'll abandon it...Not a very scientific approach, I agree, but it's the best I can do..and it seemed like such a good idea at the timeš©
Your point re: my telemetry data, might well be valid...With the basic echook, plus my SS output, and all the echook inputs being fed with appropriate signals, it works perfectly..On the bench, I've run the setup for several hours, varying the inputs, including rotation pulses from spare motors, copying the data via our SS radio telemetry, and it hasn't coughed once, so maybe the SS input from the gps is just tipping the balance....It's as though an interrupt has been tripped every two seconds, and triggered a routine that includes a delay, which you alluded to earlier. Oh well, back to the bench tomorrow, and I'll decide what to do next, as we're running out of time.. I also need to look up 'atoi' as well..It's not a term I've come across...till now.š Many thanks, as always, for your advise..John
|
|
|
Post by Rowan on Jun 11, 2020 21:52:04 GMT
It's no problem at all, I'm happy to help! You've come a long way since the start of this thread which is great!
Good you've got the IDE up and running again. If the send isn't causing any problems the read really shouldn't be.
The atoi function converts a char to an integer. Literally a (ascii) to i (integer). To do more than one digit though you have to add the bytes received into a char array and pass that info the atoi function.
If you're still seeing the slowdown tomorrow pop your latest code here and I'll take another look.
|
|
|
Post by littlejo44 on Jun 12, 2020 8:05:22 GMT
...thanks for your concern and offer of further help..I'll take you at your word if it doesn't play ball over the next couple of days..It really would be a pity to scrap the idea at this stage as we're so close to getting it working ok...J
|
|
|
Post by littlejo44 on Jun 12, 2020 17:59:38 GMT
Hi Rowan.. Well..I tried..but every time I tried to introduce either the existing code in a different location, or your new code, into the sketch, it wouldn't compile, coming up with errors saying, for example, that various interrupts had 'not been declared in this scope'..so, as I stand a good chance of making things much worse, please have a look at the code for me.. If it can't be done, I'll abandon the gps speed idea..
Notes on the sketch.. With the sketch loaded, and with no input at all to SS, the ramp is extremely erratic..for example, when throttling up quickly from (say) 35% to (say) 75%, the ramp advances in definite bursts of around a second with about a second space between the bursts!
Please note...in this sketch, the 'SpeedMPH' value is intentionally duplicated into the rpm value...Our telemetry software has a box to check when using the gps 'speed'. input, that will set it, after entering the gear ratio (obviously only works for single gear car), to calculate the rpm..(again, in the absence of the rpm sensor feed)
Line 656 is where the SSreceive lines are..
I haven't (knowingly!) done anything to the BT part of the sketch..other than put a one after the Debug you mentioned..
Please don't waste too much of your time on this..It's not vitally important, but it would be a big step on that 'learning curve' if I could get it working..thank you..
Could you let me know how to upload the sketch correctly, please..John
|
|
|
Post by keduro on Jun 13, 2020 10:11:09 GMT
Hi John, just catching up on your trials and tribulations. We (Banchory Greenpower) are in the same situation as you ā unable to access and take our cars out for testing. Very frustrating, but we are still hopeful that the Scottish event scheduled for 4th September at Kinloss may go ahead ā itās the first event on the Greenpower calendar that doesnāt show as cancelled.
Re your throttle ramp testing, may I be as bold as to suggest an alternative approach? You may already have thought of this, but just in case not ā¦..
You could use your second Nano as a wheel speed sensor simulator (rather than with a GPS unit). The Nano could generate a pulse train simulating the output from the hall effect speed sensor and that could be fed into the wheel speed sensor pin 6 (digital input D3) in the eChook Nano. This would avoid having to add any additional code to the eChook sketch to obtain speed for testing the throttle ramp operation.
The wheel speed sensor simulator need not be any more complex than the example Arduino Blink sketch (in the Arduino IDE ā¦ File > Examples > 01.Basics > Blink). That sketch blinks the on-board LED which is also on the Nano digital pin D13. Simply connect pin D13 on that Nano to pin D3 on your eChook Nano. You would need to change the delay in the sketch in order to generate a pulse train with the right timings to simulate the wheel speed sensor. For example 20mph is 8.94m/s. If your wheel circumference is say 1.2m then at 20mph the wheel makes 8.94/1.2 = 7.45 revolutions per second. If the wheel has six sensor operating magnets attached (the eChook default) then at 7.45 revs / second (20mph) there would be 7.45 * 6 pulses generated every second i.e. 44.7 pulses per second. The period of each pulse is 1 / 44.7 which is 0.022 second, or 22 milliseconds. This would require changing the delay(1000) in the example blink sketch to delay(11) on each occurrence. Take it one step further and you could connect a potentiometer an analogue input on the simulator Nano and vary the delay period based on the analogue input value. Or alternative, modify the sketch to say decrease the delay over a period of time thus simulating the car picking up speed.
If this approach is of interest and you need help with such a simulator sketch, let me know, Iām also happy to help. Keith Banchory Greenpower
|
|
|
Post by littlejo44 on Jun 13, 2020 11:15:51 GMT
Hi Keith.. sorry...this goes on a bitš© Great to hear from you again..Hope this finds you(as an old timer like meš©)well.. Thank you for trying to assist me here..but your amazing idea suggests to me that I, maybe, haven't explained my issue properly.. As soon as we get a chance, we (obviously) want to get our new car track tested... While other guys work on the car, I've been getting the echook, the motor driver and our radio telem up and running..and in boxes, so that, as soon as we get together we can mate the car with the controller etc..The echook is up and running perfectly, together with the radio telemetry (thank you again for your help with that) I have a spare motor set up with magnets and a sensor to provide simulated wheel and motor pulses, and it all works fine..The flaw in the plan here is that, when the team meet up again,I have to oversee the fitting of the controller, the magnets and the sensors on the wheel and motor...So, I have to spend a lot of time fitting magnets to the wheel and getting the pulse train to work.. As you appreciate, with testing a new car, speed and rpm will be important for the initial setting up, so we need this working for meaningful testing. So..I had this bright idea..š©.. To save time at the test stage, I can stick a nano and a gps unit (which happened to be in the workshop doing nothing) in the car and squirt the mph param (only four characters) every couple of seconds, into the spare SS RX slot in the echook....then 're-squirt' it into the serial send sequence to our telemetry...As our car is single geared, the mph figure is duplicated into the rpm param and in our telemetry receive app, we can enter the gear ratio and the rpm is then calculated and displayed...Simple, eh... ..and it works!...And the serial out to telem with the mph from gps works fine...But ...here's the issue.. When I insert a few lines of code to read the SS RX, It totally screws the throttle ramp! This happens with, or without any serial input.. The frustration here is that I'm finding it (as a noobie) very difficult to try either a different position for the 'read', or different code, coz everything I try comes back with compilation errors.. So...it's a pity, but I'm thinking I'll have to abandon the idea.. Rowan has offered to have a look at the code for me. I'm not sure how to upload the sketch in the correct way.. so if you could tell me, that would be useful.. So..I hope all that makes sense to you.. Again, great to hear from you..and apologies to Rowan for hogging the forum.. It would be good to be able to message you directly.. Cheers..John (keeping a low profile near Bristolā¹ļø)
|
|
|
Post by keduro on Jun 13, 2020 17:08:39 GMT
Hi John ā¦. ah, makes a lot of sense - mea culpa for jumping to the conclusion you were simply trying to test :-). I confess I have always tended to avoid the use of softwareserial - there are many comments out there about its reliability and performance. But then, I haven't actually tried it so shouldn't criticise. Easy to message directly - click on the gear icon/dropdown at the top right of a forum message - there you can select member and then send message. -- Keith
|
|
|
Post by littlejo44 on Jun 13, 2020 17:20:55 GMT
Hi Keith...Maybe it is a problem with SS..it needs someone with a lot more experience than me to decide.....Can you tell me how to upload a sketch please?...John
|
|
|
Post by keduro on Jun 13, 2020 18:15:27 GMT
Hi John ā¦ you should be able to attach a sketch .ino as follows: 1. Click on Reply at the top right hand end of the Quick Reply box - this opens up the Create Post page 2. Click on Add Attachment at the top right of the Create Post panel 3. Click on Add Files in the dialog that is shown, navigate to the file you wish to attach and click 4. Click Done That should do it, at least, that's how I managed to attach the blink sketch to this reply :-) Cheers, Keith Attachments:Blink.ino (1.19 KB)
|
|
|
Post by littlejo44 on Jun 13, 2020 18:27:44 GMT
Thanks..I'm reading up on SS libraries.. I guess I could try a different one and see if it makes a difference..Not a very scientific approach, I admitā¹ļø..J
|
|
|
Post by Rowan on Jun 13, 2020 19:54:58 GMT
Hey, sorry I missed a few notifications there! Attaching it as Keith has should work. If not then linking it from something such as dropbox or google drive etc is probably best It could be an issue with SS but I've used it a fair bit in the past and never really had any issues... I'll have a go at recreating what you're seeing
|
|
|
Post by littlejo44 on Jun 13, 2020 20:18:20 GMT
...Thanks, Rowan.. I'll hopefully sort out a link in the morning..I also have a few seconds of vid showing the ramp pwm on my scope as it advances in steps..Cheers..John
|
|