|
Post by littlejo44 on Jun 18, 2020 16:29:44 GMT
Hi Keith I know I keep saying it, but I really mean it..Thank you Very much for your time and effort.. Just a thought..I could add an end marker to the gps output, if that would help..But I'll wait till I hear from you.. John
|
|
|
Post by keduro on Jun 18, 2020 16:35:38 GMT
Hi John … actually, an end marker is a better way of doing it. Let me know what you'd like to use as an end marker and I'll code appropriately. Just got the quick GPS nano simulation sketch running. Just about to connect up to a nano running your code. K.
|
|
|
Post by keduro on Jun 18, 2020 17:30:09 GMT
Quick update … have pretty much confirmed my suspicions about parseFloat. Have also coded up non-blocking read of the GPS speed data. Will put together proper reply after dinner (getting my priorities right!). I used a space as the terminator / end marker. I'll point out where in the code to change that should you wish to. More later. K.
|
|
|
Post by littlejo44 on Jun 18, 2020 18:09:40 GMT
😄👍
|
|
|
Post by keduro on Jun 18, 2020 19:25:29 GMT
Hi John, Pretty sure the problem was with parseFloat. If I waited for > 5 chars available then this is what I was seeing: CSV Send Time: 48
Serial Read Time: 6
SpeedMPH: 44.00
CSV Send Time: 48
Serial Read Time: 11
SpeedMPH: 45.00
CSV Send Time: 48
Serial Read Time: 14
SpeedMPH: 45.00
CSV Send Time: 48
Serial Read Time: 14
SpeedMPH: 44.00
CSV Send Time: 48
Serial Read Time: 15
SpeedMPH: 44.00 Now, whilst the Serial Read Time apparently was short, the actual value being read was not correct, nor consistent. Sometimes 44.00, sometimes 45.00. The five characters I was sending were "01.20"!! I haven't figured it in detail but is likely due to the fact that the code was looking for > 5 chars when only 5 were being sent each time. So … next I changed the code to wait for >= 5 chars. This is a log from that: CSV Send Time: 46
Serial Read Time: 1000
SpeedMPH: 1.20
CSV Send Time: 47
Serial Read Time: 1001
SpeedMPH: 1.20
CSV Send Time: 46
Serial Read Time: 1000
SpeedMPH: 1.20
CSV Send Time: 46
Serial Read Time: 1000
SpeedMPH: 1.20
CSV Send Time: 46
Serial Read Time: 1000
SpeedMPH: 1.20
CSV Send Time: 46
Serial Read Time: 1001 Now at least the correct value was being received i.e. 1.20, but here we are seeing the 1000ms timeout. Not good. The above is just by way of a summary and reinforced the oft expressed view in various forum posts and elsewhere that use of parseFloat is to be avoided if any other code needs to be running. I modded the sketch to provide a non-blocking solution - reading a character at a time when available, buffering the characters, and then converting the buffered character string to a float when the terminating character was received. The full sketch is attached, for quick reference the relevant code is: const int receiveBufferSize = 16; // allow up to 16 characters in buffer for speed
static char receiveBuffer[receiveBufferSize]; // buffer to save received characters in
static int receiveBufferIndex = 0; // index into above buffer
while (mySerial.available() > 0) { // while there are received characters to process
char c = mySerial.read(); // read received character from mySerial input buffer
if (c != ' ') { // is it a terminator / end marker?
receiveBuffer[receiveBufferIndex] = c; // not a terminator, so save character in buffer
receiveBufferIndex++; // and increment buffer index
if (receiveBufferIndex >= receiveBufferSize) { // just to be safe, handle potential overflow if no terminator
receiveBufferIndex = receiveBufferSize - 1;
}
} else { // we do have a terminator, so
receiveBuffer[receiveBufferIndex] = '\0'; // mark end of buffer with a null
SpeedMPH = atof(receiveBuffer); // convert buffer contents to a float and assign to SpeedMPH
receiveBufferIndex = 0; // reset buffer index for next time around
if (DEBUG_MODE) {
Serial.print("SpeedMPH: ");
Serial.println(SpeedMPH);
}
}
}
Running with that code this is what I was seeing: CSV Send Time: 46
SpeedMPH: 15.60
CSV Send Time: 48
SpeedMPH: 15.70
CSV Send Time: 48
SpeedMPH: 15.80
CSV Send Time: 49
SpeedMPH: 15.90
CSV Send Time: 48
SpeedMPH: 16.00
CSV Send Time: 48
SpeedMPH: 16.10
CSV Send Time: 48
SpeedMPH: 16.20
CSV Send Time: 48
SpeedMPH: 16.30 The SpeedMPH incrementing by 0.1 each time is as expected - I had modified the sender code to do so. As far as I can tell based on my quick lash up this appears to be working as intended. But, nothing like testing it for real .... the sketch is attached. Do let me know if it works for real :-). Good luck, Keith (p.s. you will note in the code that I have declared the buffer size, buffer, and buffer index variables immediately before the code. This is a bit of a stylistic thing. My personal preference is to declare variables as close to their use as possible. I'm kinda lazy about scrolling back to the top of a sketch to find variable definitions. On the flip side, not all variable definitions are together so sometimes they require a bit of finding. All a matter of personal preference, no way is more right than the other. The use of 'static' in a variable definition means that even though it is declared within a function (in this case loop()) the values are preserved from one invocation of the function to the next.)
|
|
|
Post by Rowan on Jun 18, 2020 19:45:55 GMT
Nice solution there Keith, thank you I was looking for a way to do this without creating your own buffer - as you're essentially duplicating the serial buffer - but there doesn't seem to be a way to unfortunately. Serial.Peek() will return the oldest character in the serial buffer without removing it, but we'd need a way to peek at the newest character That parseFloat() does give rather odd behaviour! Gives the wrong result without timing out, and the right result when it times out
|
|
|
Post by littlejo44 on Jun 18, 2020 20:41:55 GMT
Keith...This must have taken you many hours...so, again, thank you.. I need to thoroughly digest the code you've put together and try and understand what's going on.. Obviously, I'll fire it up asap to see how the throttle behaves..there is so much for me to learn here! Hopefully, I won't bump into you gents in a pub any time soon, 'cos I owe you a both a few beers and it's going to cost me!😃 Cheers for now...and relax for what's left of your evening...Cheers..John
|
|
|
Post by keduro on Jun 18, 2020 21:00:00 GMT
John ... Honestly I only spent about an hour on it. The 'simulator' sketch to generate 2 second speed data was less than 20 lines of code. Receiving serial data a character at a time then processing it on receipt of a separator is a fairly common coding pattern. No risk of bumping into me in any pubs up here in Scotland. We're a bit behind you folks down south in getting anywhere near opening up the hospitality side of things. We are hopeful though that we might get the Banchory Greenpower cars out for some testing soon. Quite a bit to work on with our new car, including the telemetry. Regards, Keith
|
|
|
Post by keduro on Jun 19, 2020 20:10:02 GMT
Quick update for Rowan's benefit (as John and I have been PMing back and forth), the code is up and running, GPS speed data being received on software serial and throttle ramp working smoothly as desired. A glass of wine is in order :-). -- Keith
|
|
|
Post by Rowan on Jun 19, 2020 21:19:43 GMT
Awesome, good to hear
|
|