|
Post by Rowan on Apr 15, 2020 17:59:01 GMT
Had a look through and can only echo what Keith has said above
|
|
|
Post by littlejo44 on Apr 15, 2020 18:18:38 GMT
.....It's now 'Serialising' away merrily...😃..Thanks Keith/Rowan..I've also realised that I've been making incorrect assumptions about Pin numbers and 'D' numbers☹️....'Bring back valves' I say😄 Thank you.. Stay safe.. John
|
|
|
Post by keduro on Apr 16, 2020 9:57:48 GMT
Great news John. Hopefully should be fairly easy to modify what's included in the CSV output should you require anything different :-) -- Keith
|
|
|
Post by littlejo44 on Apr 16, 2020 12:30:44 GMT
It's certainly great news for me, Keith..😄...but there's still a fair way to go yet...I need to put in your 'jitterbug' fix (not the dance😊)..then I need to fire up BT to see if it's all going to run together.....then there's the calibration...also, I need to couple the serial feed to the transmitter....and supply received data samples to the guy who wrote our telemetry code.(who lives in Australia!)...phew!! One question though (for now☹️)
Re: if(tempThrottle > currThrtlOut && currThrtlOut > 30){ // This could be if(thrtlIn > thrtlOut && speed < threshold) to make it low speed only. Speed and threshold are undefined in this example!
If I want to define the threshold, what units would that be in....simply mph as a whole number?also....Your comments seem to imply that 'speed' would have to be defined...have I read that correctly? Thanks.. John
|
|
|
Post by Rowan on Apr 16, 2020 17:12:47 GMT
Hi John, You have a few options for this. Around line 150 in the code there are the global variables that are continuously updated with the sensor readings:
float motorRPM = 0; float wheelRPM = 0; float wheelSpeed = 0;
You could use any of these for the threshold. Motor and Wheel RPM are self explanatory, wheelSpeed is in meters per second.
If you replace 'speed' with one of those variables and choose a suitable threshold value you should be good to go
As for supplying the data output from the serial, would it be easier to match the output from the Arduino to your current system in order to keep backwards compatibility?
Cheers,
Rowan.
|
|
|
Post by littlejo44 on Apr 17, 2020 10:10:35 GMT
Hi Rowan..and as always.thank you for the information...and, there's a bonus.. Not only have you fixed the 'jitterbug' perfectly..but you have also fixed the 'brief drop to zero at max throttle' bug..I tried very hard to reproduce it, but there's no sign of it on the scope at all since adding that jitter fix!!😃😃 There's more 'waffle' to follow, Rowan..just wanted to let you know now re: the bugs...😊. J
|
|
|
Post by Rowan on Apr 17, 2020 12:15:11 GMT
Excellent, glad it worked - and that explains why I wasn't seeing the drop as I was testing post jitter fix
|
|
|
Post by littlejo44 on Apr 17, 2020 14:37:17 GMT
Re: the received data...and backward compatibility.... The echook will provide several more parameters than our existing system, so the existing four different selectable user interfaces on the laptop, and the way the params are modified and displayed will have to be re-coded to allow for more fields and rolling charts.. The old controller will probably be phased out soon (virus allowing😡) so backward compatibility won't be an issue...(We'll probably keep the existing Motor Driver stage for future use, though..'cos it's proved to be extremely reliable over the last few years, so, with another car, no need to 're-invent the wheel' as they say) Until then, the existing telemetry program can be kept as a separate app and just 'fired up' when required when the old controller/car is in use.. The plan is that our old car is just going to be used for 24+, till being phased out, and the new one, just for F24.. I appreciate how versatile your BT system is, but I think it will be worth the effort to also preserve our direct radio link if possible, which will give us an alternative or additional way of obtaining feedback which is independent of mobile phones, phone networks, BT, or internet links.. besides providing the kids with basic knowledge of how radio comms. work...Thanks again for the fix! Cheers Watch this space😊....John
|
|
|
Post by Rowan on Apr 17, 2020 15:42:15 GMT
That all makes sense I agree with the value of keeping the radio link too - Bluetooth and mobile data aren't without their issues but we picked them as they are by far the cheapest way to get data to the pits (assuming teams don't buy a phone specifically for it) and it's also very versatile.
|
|
|
Post by littlejo44 on Jun 9, 2020 18:48:44 GMT
Hi Rowan.. Hope this finds you well.. Would you mind having a look at your ramp code again for me in the attached sketch.. I've been having a closer look at the operation, and I'm not sure that the ramp is working as intended.. eg..if I turn the throttle to max, it will usually go straight to 100%..While testing it, the speed is zero, so I guess the ramp should be in play all the times..It doesn't appear to work as it did originally, so I've done something silly, for which I apologise in advance! There is a variable, SpeedMPH, which is derived (line 1298)from the wheel speed and is used to feed my serial output to the radio.. The Ramp code begins around line 1077.. Thank you.. John. XPOD_Ramp_Test_forum.ino (49.46 KB) ROWAN...FORGET THIS POST!...I'LL UPDATE SHORTLY...😩...sorry..
|
|
|
Post by littlejo44 on Jun 10, 2020 18:30:55 GMT
Ok..Take 2.. As a temporary measure and to save some time,(we have no access to our new car at present to attach and set up wheel and rpm sensors) I've set up a gps using a second nano to 'inject' the speed, in mph, to one decimal place, into the echook, via the software serial rx port every two seconds..( For me, it would be a 'step to far' to try and integrate it into the echook nano!!..and I'm also thinking there might not have been enough capacity..) I tried various lines of code to read the incoming data and assign it to a variable (SpeedMPH) before then simply re-sending it, along with all the other parameters, to our telemetry.. if (Serial.available() > 0), with Serial.parseFloat() worked, but it 'chokes' and interferes significantly with the timing of everything else..☹️
My question is, can you please advise me as to the best lines of code to read the data from the software serial port with the minimum amount of interruption to the echook, and where in the loop you think would be the best position to insert it? I thought it was running ok till I looked at the pwm on the scope, and the incoming serial really chokes your throttle ramp operation.. This was why I thought I had a problem with it..(previous post)..
I can't show you the actual code I used as my PC has literally just updated and IDE no longer runs on it☹️..Thank you in advance for any advice.. John
|
|
|
Post by Rowan on Jun 11, 2020 8:55:26 GMT
I've never really compared times for parsing inputs from serial... sounds like it's slow!
Sticking to the serial route, I'd try using a high baud rate such as 115200 instead of 9600. This will greatly increase the communication speed.
Put the receiving function in the main loop, not in any timed function. This way it can process any new data as it comes in. If you're checking it periodically you risk a buffer of data building up then when check if serial is available you have a backlog of numbers to process.
I'd also limit the values you send to integers rather than floats and use the atoi() function to convert to integers which should be pretty fast.
This bit of code is untested - just written it here - but should indicate my thinking.
void loop()
{ if(mySerial.available()){ char temp = mySerial.read(); if(isDigit(temp)){ //Check if the data is a number - if not ignore it. speed = atoi(temp); } } }
An alternate way of doing it would be to have the eChook arduino generate its own speed values. Depending on what you want to do this ranges from simple to rather difficult, but you could comment out the readSpeed function and add in a number generator. Either random numbers (speed = random(max_random_value)) or a sawtooth (speed ++; if( speed > x) speed = 0;).
|
|
|
Post by littlejo44 on Jun 11, 2020 11:34:23 GMT
Sorry for delay...there was no notification of your reply..I just happened to check the forum...
..thank you for your thoughts, Rowan..I'll (maybe, if possible ) give it a try..
I'm limited to 9600 as the TX part of the echook SS has to be 9600.(is it possible to have a second SS running faster?)..
Re:The buffer... Is the data being stored in the buffer after it's been read?
I'm thinking I'll probably have to abandon this idea, though, as, since my Win10 pc updated yesterday, IDE no longer works☹️..so I can't really try anything...
Could you let me know if, during this process, the buffer is storing the data, and if so, is there a way of stopping that happening...Thank you..John
|
|
|
Post by Rowan on Jun 11, 2020 12:10:26 GMT
You could start a second software serial with a higher speed. It would use extra memory but you should be fine.
By default the software serial buffer is 64 bytes. It's a first in first out buffer that holds any incoming data. When you use read, the oldest byte in the buffer is returned then deleted from the buffer. to clear the buffer use:
//If there is any data available, reading it into a temp variable removes it from the buffer. Doing this until there is no data left in the buffer clears the buffer. while(mySerial.available()){ char tmp = mySerial.read(); }
If you think you are sending data faster than you're reading it and want to keep the data fresh you can run that snippet after you read the data. If you're reading in a function called in loop I'd be surprised if there was any data to clear though.
|
|
|
Post by littlejo44 on Jun 11, 2020 12:44:09 GMT
Thanks, Rowan.. ...it's only four characters or so, every two seconds...so not a huge amount of data...
Is there an alternative to IDE, or am I totally snookered here? It no longer works on my Desktop or my Laptop...J
|
|